a&d control de calidad fis

Luffi

Luffi

[Seleccione la fecha]

Anlisis y Diseo CONTROL DE CALIDAD DE SOFTWARE

INTEGRANTES: HUASASQUICHE TORREALVA ERIKA

HUAROTO BARRIOS JOSE MUOZ CISNEROS LUIS

DOMINGUEZ MENDOZA DELFOR VILLENA CANDELA DANNY

FACULTAD DE INGENIERA DE SISTEMAS UNIVERSIDAD NACIONAL SAN LUIS GONZAGA

Anlisis y diseo

Control de calidad del software Pgina 1

DEDICATORIA

Quiero dedicarle este trabajo

A Dios que me ha dado la vida y fortaleza

para terminar este trabajo de investigacin,

A nuestros Padres por estar ah cuando ms

los necesitamos; en especial a las madres por

su ayuda y constante cooperacin y

A al Docente por ensearnos sus

conocimientos adquiridos y en base de ello

hacer de nosotros grandes profesionales.

Anlisis y diseo


Contenido 1.- ANLISIS Y DISEO ................................................................................................................. 6

1.1.- ANLISIS .............................................................................................................................. 6

1.1.1.- LO QUE NO ES EL ANLISIS DE SISTEMA ......................................................... 6

1.1.2.- EN QUE CONSISTE El TRABAJO DEL ANLISIS DE SISTEMA ...................... 6

1.1.3.- CALIDAD EN EL ANLISIS ....................................................................................... 9

1.2.- DISEO .............................................................................................................................. 10

1.2.1.- ETAPAS DEL DISEO DEL SISTEMA .................................................................. 11

1.2.2.- CRITERIOS TCNICOS PARA UN BUEN DISEO ............................................ 14

1.2.3.- PRINCIPIOS DEL DISEO: ..................................................................................... 14

1.2.4.- SIMPLICIDAD EN EL DISEO ................................................................................ 15

2.- ESTRUCTURA INTERNA DEL SOFTWARE ....................................................................... 16

2.1.- DEFINICIN ARQUITECTURA DE SOFTWARE ........................................................ 17

2.2.-ARQUITECTURA DE SOFTWARE EN EL PROCESO DE DESARROLLO ............ 17

2.3.- CARACTERSTICAS DE UNA ARQUITECTURA DE SOFTWARE EXITOSA ....... 17

3.- CONSIDERACIONES DEL DISEO DEL SOFTWARE .................................................... 22

3.1.- DISEO DE SOFTWARE ................................................................................................ 22

3.1.1.- DISEO PRELIMINAR .............................................................................................. 22

3.1.2.- DISEO DETALLADO .............................................................................................. 24

3.2 DISEO DE SOFTWARE INTERNACIONALIZADO .................................................... 25

3.2.1.- UNIFORMIDAD DE TERMINOLOGA EN LA DOCUMENTACIN DEL

SOFTWARE: ........................................................................................................................... 25

3.2.2.- EXPANSIN DE INTERFACES GRFICAS: ....................................................... 25

3.2.3.- DISEO INTERNACIONAL DE INTERFACES DE USUARIO: .......................... 25

3.2.4.- SEPARAR LA CAPA DE DATOS DE LA CAPA DE PRESENTACIN: ........... 26

3.2.5.- OPTIMIZAR LOS ESQUEMAS DE LA BASE DE DATOS PARA QUE

SOPORTEN LA INTERNACIONALIZACIN: .................................................................... 26

3.3.- FUNDAMENTOS DE DISEO .................................................................................................. 27

3.3.1 MODULARIDAD ................................................................................................................ 27

3.3.2 ARQUITECTURA DEL SOFTWARE ...................................................................................... 27

3.3.3 JERARQUA DE CONTROL ................................................................................................. 29

3.3.4 ESTRUCTURA DE DATOS. .................................................................................................. 29

Anlisis y diseo


4.- BUENAS PRACTICAS DE DISEO ................................................................................................... 29

4.1.- CONCEPTOS. .......................................................................................................................... 29

4.2.- QUE LAS ESTRUCTURAS DE DATOS DEBEN ESTAR OCULTAS EN UN

SISTEMA SOFTWARE. ............................................................................................................ 32

4.3.- Y QUE HAY INCLUSO LISTAS DE MALOS OLORES QUE TE PUEDEN DAR

PISTAS DE QUE PROBLEMAS DE CALIDAD SOFTWARE TE PUEDES

ENCONTRAR. ............................................................................................................................ 33

5.- CONCLUSIONES ..................................................................................................................... 38

6.- RECOMENDACIONES .................................................................................................................... 39

7.- BIBLIOGRAFIA ............................................................................................................................... 40

Anlisis y diseo


Tabla de Ilustraciones

Ilustracin 1: Diseo y su Importancia .............................................................................................. 10

Ilustracin 2: Diseo de los datos ..................................................................................................... 11

Ilustracin 3: Diseo Arquitectnico ................................................................................................. 11

Ilustracin 4: Diseo de Interfaz ....................................................................................................... 12

Ilustracin 5: Diseo de Procedimientos .......................................................................................... 13

Ilustracin 6: Intangibles de estructura Interna ................................................................................ 18

Ilustracin 7: Investigacion y Desarrollo ........................................................................................... 20

Ilustracin 8: Modularidad - Fundamentos de diseo ...................................................................... 27

Ilustracin 9: Arquitectura del software Evolucion de la Estructura ............................................. 28

Ilustracin 10:Arquitectura del software - Diferentes Estructuras ................................................... 28

Ilustracin 11: Estracto de la Clase ................................................................................................... 35

Ilustracin 12: Reemplace el mtodo con el mtodo de objeto ....................................................... 35

Ilustracin 13: Reemplace el cdigo Type con la estrategia del Estado ........................................... 35

Anlisis y diseo


INTRODUCCIN

La esencia del diseo del software es la toma de decisiones sobre la organizacin

lgica del software. Algunas veces, usted representa esta organizacin lgica

como un modelo en un lenguaje definido de modelado, tal como UML y otras

veces usted simplemente utiliza notaciones informales y esbozos para representar

el diseo.

Por su puesto raramente empieza desde cero cuando toma decisiones sobre la

organizacin

del software sino que basa su diseo sobre experiencias de diseos anteriores.

El proceso de diseo de un producto o servicio es una fase crtica, probablemente

la ms crtica para el mismo. Un proceso de diseo y desarrollo adecuado

garantizar que la organizacin est en disposicin de poder dar respuesta a las

necesidades del cliente traducindolas en especificaciones concretas

(dimensiones, prestaciones, tiempo de respuesta...).

Un proceso de diseo inadecuado supondr un lastre que el nuevo producto va a

cargar desde su nacimiento y que har que no se consigan los objetivos deseados

de satisfaccin del cliente. En el momento en que una organizacin establece

comunicacin con un cliente real o potencial, ste manifiesta unas expectativas

que desea que se cumplan, y lo hace con un distinto grado de definicin, en

funcin del tipo de cliente (normalmente mucho ms definidas en el caso de un

cliente industrial que en el caso del pblico en general) y del tipo de producto o

servicio del que se trate. El proceso de diseo y desarrollo trata de conseguir

transformar esas necesidades del cliente en especificaciones de diseo, de

productos o servicios que les den respuesta; se trata, por tanto, de conseguir que

la organizacin ane sus capacidades con el fin de conseguir la satisfaccin del

cliente

Anlisis y diseo


ANLISIS Y DISEO

1.- ANLISIS Y DISEO

1.1.- ANLISIS

Para que el desarrollo de un software concluya con xito, es de importancia que

antes de la codificacin de los programas que constituirn el software completo, se

tenga una plena y completa comprensin de los requisitos del software.

Distincin y separacin completa de las partes de un todo hasta llegar a conocer

sus principios o elementos, sus caractersticas representativas, as como sus

interrelaciones.

1.1.1.- LO QUE NO ES EL ANLISIS DE SISTEMA

Efectuar diseos que no cumplan con los requisitos de los anlisis de sistema

como:

El observar un sistema sin tener en cuenta todas sus partes o

componentes.

El considerar el anlisis sin evaluar todos los procedimientos.

El evaluar conceptos sin tener en consideracin la uniformidad de los

procesos y no establecer su viabilidad.

El Olvidarse o de realizar un Anlisis Tcnico y econmico.

El No establecer restricciones de presupuestos y planificacin

temporal o definitiva.

Divagar en una definicin del sistema que no forme el fundamento de

todo el trabajo de Ingeniera.

1.1.2.- EN QUE CONSISTE El TRABAJO DEL ANLISIS DE SISTEMA

Una definicin puede presentarse como:

Un conjunto o disposicin de procedimientos o programas relacionados de manera

que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas

clasificadas y dispuestas de manera ordenada mostrando un plan lgico en la

Anlisis y diseo


unin de las partes. Un mtodo, plan o procedimiento de clasificacin para hacer

algo. Tambin es un conjunto o arreglo de elementos para realizar un objetivo

predefinido en el procesamiento de la Informacin.

Esta rea se encuentra muy relacionada con la Investigacin de operaciones.

Tambin se denomina anlisis de sistemas a una de las etapas de construccin de

un sistema informtico, que consiste en relevar la informacin actual y proponer

los rasgos generales de la solucin futura.

Los sistemas en relacin con el anlisis de sistemas estn relacionados con

cualquier campo tales como: procesos industriales, administracin, toma de

decisiones, procesos, proteccin al medio ambiente, etc.

En sistemas informticos se deben observar ciertos principios:

Debe presentarse y entenderse el dominio de la informacin de un

problema.

Defina las funciones que debe realizar el Software.

Represente el comportamiento del software a consecuencias de

acontecimientos externos.

Divida en forma jerrquica los modelos que representan la

informacin, funciones y comportamiento.

El proceso debe partir desde la informacin esencial hasta el detalle

de la Implementacin.

La funcin del Anlisis puede ser dar soporte a las actividades de un negocio, o

desarrollar un producto que pueda venderse para generar beneficios.

Para conseguir este objetivo, un Sistema basado en computadoras hace uso de

seis (6) elementos fundamentales:

Anlisis y diseo


Software, que son Programas de computadora, con estructuras de

datos y su documentacin que hacen efectiva la logstica

metodologa o controles de requerimientos del Programa.

Hardware, dispositivos electrnicos y electromecnicos, que

proporcionan capacidad de clculos y funciones rpidas, exactas y

efectivas (Computadoras, Censores, maquinarias, bombas, lectores,

etc.), que proporcionan una funcin externa dentro de los Sistemas.

Personal, son los operadores o usuarios directos de las

herramientas del Sistema.

Base de Datos, una gran coleccin de informaciones organizadas y

enlazadas al Sistema a las que se accede por medio del Software.

Documentacin, Manuales, formularios, y otra informacin

descriptiva que detalla o da instrucciones sobre el empleo y

operacin del Programa.

Procedimientos, o pasos que definen el uso especfico de cada uno

de los elementos o componentes del Sistema y las reglas de su

manejo y mantenimiento.

Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos

en mente:

Identifique las necesidades del Cliente.

Evale que conceptos tiene el cliente del sistema para establecer su

viabilidad.

Realice un Anlisis Tcnico y econmico.

Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema.

Establezca las restricciones de presupuestos y planificacin

temporal.

Cree una definicin del sistema que forme el fundamento de todo el trabajo de Ingeniera.

Anlisis y diseo


Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del

Hardware y el Software, as como de la Ingeniera humana (Manejo y

Administracin de personal), y administracin de base de datos.

1.1.3.- CALIDAD EN EL ANLISIS

1.1.3.1.- Calidad de atributos

Varios atributos son generalmente considerados importantes que

permiten obtener un diseo de software con alta calidad, existen

algunas caractersticas que son ( mantenible, portabilidad, probable)

y (correctos, robusto). Cabe destacar que existen diferencias entre

calidad de atributos que son (rendimiento, seguridad, funcionalidad y

usabilidad), y los que son (portabilidad, reutilizacin, integralidad y

pruebas), y las caractersticas relacionadas con la arquitectura

(integridad conceptual, correcto, completo).

1.1.3.2.- Calidad en anlisis y evaluacin de tcnicas

Varias tcnicas y herramientas pueden ayudar a mejorar la calidad

de diseo de software:

Diseo de software.- Para este tipo se puede aplicar al diseo

de software informal y semi informal tomando un grupo base,

tcnicas que permiten verificar la calidad de diseo de los

artefactos que pueden ser (vista de la arquitectura, diseo -

inspeccin, tcnicas y requerimientos).

Anlisis esttico.- Para este tipo se puede aplicar al diseo de

software informal y semi informal que permite evaluar algo

simple utilizando anlisis automticos de casos de pruebas.

Simulacin y prototipos.- Son tcnicas dinmicas que permiten

evaluar un diseo la caracterstica de simulacin, o la

flexibilidad del prototipo.

Anlisis y diseo


1.2.- DISEO

La calidad del software se puede observar en una caracterstica o atributo. Como

un atributo, la calidad se refiere a caractersticas mensurables, es decir cosas que

se pueden comparar para conocer estndares, como longitud, color, propiedades

elctricas y maleabilidad. Sin embargo, el software que es una entidad intelectual,

tiene la complejidad de caracterizar los objetos fsicos. No obstante, existen

mediciones que nos permiten evaluar las caractersticas de un programa. Dichas

propiedades incluyen complejidad psicosomtica, nmero de puntos de funcin,

lneas de cdigo, etctera.

Cuando se examina un elemento sus caractersticas mensurables se pueden

encontrar dos tipos de calidad:

Calidad de diseo; la calidad de diseo se refiere a las caractersticas que

los diseadores especifican para un elemento.

Calidad de concordancia; la calidad de concordancia es el grado en el que

las especificaciones de diseo se aplican durante la fabricacin.

El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios

con el propsito de definir un dispositivo, un proceso o un Sistema, con suficientes

detalles como para permitir su interpretacin y realizacin fsica.

Ilustracin 1: Diseo y su Importancia

Anlisis y diseo


1.2.1.- ETAPAS DEL DISEO DEL SISTEMA

La etapa del Diseo del Sistema encierra cuatro etapas:

1.2.1.1.- El Diseo de los datos

Trasforma el modelo de dominio de la informacin, creado durante el

anlisis, en las estructuras de datos necesarios para implementar el

Software.

Ilustracin 2: Diseo de los datos

1.2.1.2.- El Diseo Arquitectnico.

Define la relacin entre cada uno de los elementos estructurales del

programa.

Ilustracin 3: Diseo Arquitectnico

Anlisis y diseo


1.2.1.3.- El diseo de la Interfaz.

Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean.

Ilustracin 4: Diseo de Interfaz

1.2.1.4.- El Diseo de Procedimientos.

Transforma elementos estructurales de la arquitectura del programa. La

importancia del Diseo del Software se puede definir en una sola palabra

Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El

Diseo es la nica manera de materializar con precisin los requerimientos

del cliente.

Anlisis y diseo


Ilustracin 5: Diseo de Procedimientos

El Diseo del Software es un proceso y un modelado a la vez. El proceso de

Diseo es un conjunto de pasos repetitivos que permiten al diseador describir

todos los aspectos del Sistema a construir. A lo largo del diseo se evala la

calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas:

El diseo debe implementar todos los requisitos explcitos contenidos en el

modelo de anlisis y debe acumular todos los requisitos implcitos que

desea el cliente.

Debe ser una gua que puedan leer y entender los que construyan el cdigo

y los que prueban y mantienen el Software.

El Diseo debe proporcionar una completa idea de lo que es el Software,

enfocando los dominios de datos, funcional y comportamiento desde el

punto de vista de la Implementacin.

Anlisis y diseo


1.2.2.- CRITERIOS TCNICOS PARA UN BUEN DISEO

Para evaluar la calidad de una presentacin del diseo, se deben establecer

criterios tcnicos para un buen diseo como son:

Un diseo debe presentar una organizacin jerrquica que haga un

uso inteligente del control entre los componentes del software.

El diseo debe ser modular, es decir, se debe hacer una particin

lgica del Software en elementos que realicen funciones y

subfunciones especficas.

Un diseo debe contener abstracciones de datos y procedimientos.

Debe conducir a interfaces que reduzcan la complejidad de las

conexiones entre los mdulos y el entorno exterior.

Estos criterios no se consiguen por casualidad. El proceso de Diseo del Software

exige buena calidad a travs de la aplicacin de principios fundamentales de

Diseo, Metodologa sistemtica y una revisin exhaustiva.

Cuando se va a disear un Sistema de Computadoras se debe tener presente que

el proceso de un diseo incluye, concebir y planear algo en la mente, as como

hacer un dibujo o modelo o croquis.

1.2.3.- PRINCIPIOS DEL DISEO:

Los principios del diseo ayudan a los diseadores a explicar y mejorar su trabajo.

Tienen su origen en la teora, la experiencia y el sentido comn. Cuando se ponen

en prctica para evaluar productos o prototipos se les denomina principios de

usabilidad o heursticos.

Los descritos por Don Norman (1998) son:

1.2.3.1.- Visibilidad

Cuanto ms visibles sean las funciones, ms probabilidad hay de que

los usuarios las vean y usen.

Anlisis y diseo


1.2.3.2.- Retroalimentacin

Cada accin con el sistema debe tener una clara reaccin. Se puede hacer

con sonido, de forma tctil, verbal, visualmente o combinadas.

1.2.3.3.- Restriccin

Es la limitacin de la interaccin del usuario en un momento determinado.

Las limitaciones pueden ser de tres tipos:

Fsicas. Ej.: Una clavija que no encaja.

Lgicas. Ej.: Si pulso un botn, espero una reaccin.

Culturales. Ej.: El significado de un color no es igual en todo el

mundo.

1.2.3.4.- Mapeo

Es la relacin entre los controles y su efecto.

1.2.3.5.- Consistencia

Consiste en disear usando operaciones y elementos similares.

1.2.3.6.-Claridad

Es el atributo que permite a las personas saber cmo usar un diseo.

Puede ser de dos tipos:

Percibidas, en el caso de una interfaz de un programa, que es virtual.

Reales, en el caso de los objetos fsicos.

1.2.4.- SIMPLICIDAD EN EL DISEO

La simplicidad es una caracterstica del diseo de calidad.

La simplicidad, que no la simpleza ni la simplificacin, se basa en el entendimiento

profundo del asunto que se quiere transmitir y en la capacidad de hacerlo de una

forma clara y concisa.

Los buenos diseos estn ah, pero no se ven.

Los diseos complicados nos obligan a un esfuerzo de adaptacin y a la

incorporacin de elementos que nos son artificiales y forzados.

Anlisis y diseo


1.2.4.1.- La simplicidad se fabrica

La simplicidad ni se inventa ni es producto de la intuicin, sino del trabajo:

Proximidad: Los diseos sencillos son ms fciles de entender y

favorecen el uso inmediato y la exploracin exhaustiva de los

recursos del diseo.

Reconocibilidad: Son ms fcilmente reconocibles y asimilables, ya

que presentan menos informacin superflua.

Inmediatez: Los diseos sencillos tienen un impacto mayor

precisamente porque su facilidad de comprensin los hacen

inmediatamente reconocibles con un esfuerzo consciente mnimo.

Usabilidad: Por todo lo anterior suelen ser tambin los ms fciles

de usar.

2.- ESTRUCTURA INTERNA DEL SOFTWARE

As como la esencia del ser humano no est en su cuerpo sino en su algo

abstracto llamado alma, es un elemento intangible llamado software que radica la

mayor parte de la magia que ha convertido al computador en la herramienta ms

poderosa de nuestro tiempo.

Los computadores estn formados por hardware, que ya aparece explicado y

relacionado en el acpite anterior, y el software. Lo nico tangible del software es

el sitio en el que se almacena: disquetes, discos compactos (CD ROM), disco

duro., etc

El sistema operativo es el programa ms importante porque controla el

funcionamiento del computador y el de los dems programas. Las aplicaciones,

por su parte, son todos los programas que permiten al usuario realizar tareas:

Anlisis y diseo


procesadores de palabra para escribir, juegos para divertirse, hojas de clculo

para trabajo financiero, browsers para navegar por la red.

El sistema operativo establece las reglas y parmetros para que el software

aplicativo interacte con el computador. Si no existiera el sistema operativo, cada

desarrollador de software tendra que crear su propio mtodo para que sus

aplicaciones grabaran archivos en el disco duro, para desplegar textos y grficos

en la pantalla, para enviar texto a la impresora e infinidad de funciones ms. Pero

en lugar de hablar directamente con el hardware las aplicaciones hablan con el

sistema operativo y este acta como interprete ante el hardware.

2.1.- DEFINICIN ARQUITECTURA DE SOFTWARE

Una arquitectura de software describe los componentes bsicos de un sistema de

software y su combinacin interna.

2.2.-ARQUITECTURA DE SOFTWARE EN EL PROCESO DE

DESARROLLO

En el marco del desarrollo de software, la arquitectura de software representa la

decisin de diseo ms temprana. Es determinada bsicamente por criterios de

calidad como la modificabilidad, mantenibilidad, seguridad y el rendimiento. Una

arquitectura de software una vez establecida es modificable ms tarde solo con

gran esfuerzo. La decisin acerca de su diseo es por eso uno de los puntos ms

crticos e importantes en el proceso de desarrollo de un software.

2.3.- CARACTERSTICAS DE UNA ARQUITECTURA DE

SOFTWARE EXITOSA

Para poder funcionar con xito, la arquitectura de software debe ser sintonizada

con los restantes factores del proyecto de software. Una arquitectura de software

bien configurada facilita a los usuarios y desarrolladores la comprensin del

sistema. Factores importantes que influyen la aptitud de la arquitectura de

software son la planificacin de proyectos, el anlisis de riesgo, la organizacin, el

Anlisis y diseo


proceso de desarrollo, los ciclos de trabajo, el hardware, la garanta de calidad y

los requerimientos.

2.4.-ACTIVOS INTANGIBLES DE ESTRUCTURA INTERNA:

2.4.1 INVESTIGACIN Y DESARROLLO

La investigacin y desarrollo es tambin un activo intangible para la empresa. Es

uno de los que ya se recoge en la contabilidad, aunque desde la perspectiva del

capital intelectual se critican sus normas de valoracin. Se incluyen tambin los

activos intelectuales de propiedad intelectual como las patentes, copyrights,

diseos, secretos. Se pueden obtener bastantes indicadores como el nmero de

patentes y su coste de mantenimiento, el porcentaje de recursos que destina la

empresa a I+D o su incremento, el porcentaje de I+D dedicado a investigacin

bsica, etc.

2.4.2 ALGUNOS ACTIVOS INTANGIBLES DE ESTRUCTURA INTERNA Y SUS

INDICADORES

La siguiente figura ilustra un ejemplo de sistema de medicin del rendimiento de

los centros de I+D, un cuadro de mando informatizado con indicadores sobre

temas de patentes, nuevos productos, etc

Ilustracin 6: Intangibles de estructura Interna

Anlisis y diseo


Investigacin y desarrollo

Para quienes tienen una imagen de investigacin asociada a laboratorios de

cientficos vestidos de delantal y con guantes blancos, esto de la investigacin en

la industria del software suena un poco extrao. Incluso quienes saben que

existen industrias que, en sus departamentos de I+D, realizan prototipos de sus

productos para probar su factibilidad tcnica, tambin se suelen sentir

contrariados.

Sin embargo, para quienes consideramos que la ingeniera del software es una

ingeniera como la que ms, no es tan raro. Al fin y al cabo, la industria del

software genera productos (productos intangibles, si se quiere que haga la

aclaracin, pero productos al fin). Y hacer I+D para evaluar factibilidad de un

producto de software no debera tener nada de raro. Tampoco debera tenerla la

investigacin en ciencias de la computacin, como se hace investigacin en la

matemtica, por ejemplo para determinar mejores algoritmos.

Por lo tanto, una primera clasificacin de las investigaciones relacionadas con el

software sera:

I+D relacionada con ciencias de la computacin: algoritmos, lenguajes,

estructuras de datos, paradigmas, etc.

I+D orientada a desarrollo de software: prototipos de procesos y productos.

Lo que es importante entender de cualquier proyecto de I+D, es que debe

necesariamente tener varios hitos de evaluacin y posible interrupcin. Esto puede

ser as en muchos proyectos de desarrollo, pero muy especialmente si se trata de

I+D.

Efectivamente, como ya dije, la misin principal de I+D, en cualquiera de sus

variantes, es analizar factibilidad. Esto, obviamente, no siempre tiene un resultado

positivo; me atrevera a decir que muy pocas veces lo tiene. En este sentido, es

importante poder interrumpir un proyecto de I+D apenas se lo vea como no

factible.

Anlisis y diseo


Y de hecho, es preferible contar con un rea de I+D, de la cual no se esperan

resultados econmicos directos, para probar factibilidades que, si no, costaran

dinero de proyectos puntuales.

Intangibles vs Indicadores

ACTIVOS INTANGIBLES INDICADORES

Capacidad de innovacin de la

organizacin

Creatividad

Investigacin y desarrollo

Organizacin de sus sistemas de

informacin

Uso eficiente de tecnologas de la

comunicacin

Tipo de direccin

Grado de descentralizacin de la toma

de decisiones

Nivel de burocracia interna

Capacidad para trabajar en grupo

Porcentaje de recursos que destina la

empresa a I+D

Nmero de patentes

Proyectos de investigacin en los que

participa la empresa

Premios o reconocimientos a la innovacin

Grado de automatizacin de las tareas

administrativas

Nmero de documentos que han dejado de

procesarse en formato papel

Porcentaje de personal con acceso a la

Intranet y grado de utilizacin

Ilustracin 7: Investigacion y Desarrollo

Anlisis y diseo


2.5.- ESTRUCTURA INTERNA (SOFTWARE) DEL PC:

Sistemas operativos: es el software bsico de una computadora que provee una

interfaz entre el resto de programas del ordenador, los dispositivos hardware y el

usuario.

Software aplicativo: son los programas que nos permiten trabajar despus de

tener el sistema operativo ya montado

Free Software: es la denominacin del software que respeta la libertad de los

usuarios sobre su producto adquirido y, por tanto, una vez obtenido puede ser

usado, copiado, estudiado, modificado y redistribuido libremente.

Open Source: se define por la licencia que lo acompaa, que garantiza a cualquier

persona el derecho de usar, modificar y redistribuir el cdigo libremente

Licencia GPL: Licencia creada por la Free Software Foundation y orientada

principalmente a los trminos de distribucin, modificacin y uso de software libre.

Software de dominio pblico: no est protegido por las leyes de derechos de autor

y puede ser copiado por cualquiera sin costo alguno.

Freeware: Cualquier software que no requiere pago ni otra compensacin

(como adwares) por parte de los usuarios que los usan.

Sharware: Un tipo de software que es distribuido gratuitamente exclusivamente

para ser probado, pero posee restricciones en su funcionalidad o

disponibilidad. Por lo general son limitados a 30 das de uso, pero tambin algunos

desactivan opciones como Guardar, o tienen limitado el nmero de veces que

pueden ejecutarse.

Anlisis y diseo


3.- CONSIDERACIONES DEL DISEO DEL SOFTWARE

3.1.- DISEO DE SOFTWARE

El diseo es la primera fase del desarrollo de cualquier producto. El objetivo del

diseador es producir un modelo o representacin de una entidad que ser

construida ms adelante.

Esta etapa se suele dividir en dos:

3.1.1.- DISEO PRELIMINAR

Se centra en la transformacin de los requisitos de los datos y la

arquitectura del software. Consiste en desarrollar una estructura funcional y

modular del sistema, definir interfaces entre los mdulos y establecer

estructuras de datos.

Una actividad importante de esta etapa es el diseo de interfaz, que

establece los mecanismos para la interaccin hombre-mquina.

El diseo preliminar consta de tres partes:

3.1.1.1.- Diseo de Datos:

Es la primera de las cuatro actividades en la que se proponen los

siguientes principios para disear los datos.

Aplicar a los datos los mismos principios sistemticos de

diseo que se aplican a la funcionalidad del sistema.

Identificar todas las estructuras de datos y operaciones a

realizar sobre ellas.

Establecer un diccionario de datos para definir el diseo de

datos y programa.

Una estructura de datos slo debe ser conocida por los

mdulos que lo utilicen directamente.

Anlisis y diseo


Desarrollar y utilizar, si existe, una librera de estructura de

datos de forma que se puedan reusar en el desarrollo de la

aplicacin.

El diseo de software y el lenguaje de programacin deben

soportar la realizacin y especificacin de tipos abstractos

de datos.

3.1.1.2.- Diseo Arquitectnico:

Su objetivo es desarrollar una estructura modular del software y

representar las relaciones de control entre los mdulos. El diseo

arquitectnico mezcla la estructura del programa y la de los datos, y

define las interfaces.

3.1.1.3.- Diseo de la Interfaz Hombre-Mquina:

Su objetivo es disear una interfaz para el usuario que le

proporcione una comunicacin bidireccional con el sistema software

durante su ejecucin. Debe tener en cuenta:

Los diseos de datos y arquitectnicos, que ayudan a

establecer las caractersticas y restricciones que debe tener la

interfaz.

El modelo de usuario, que define el perfil de los usuarios

finales del sistema.

Producir mensajes de error significativos.

Utilizar ventanas para modularizar los diferentes tipos de

informacin.

Protege al sistema de los errores del usuario que puedan

causar algn fallo.

Anlisis y diseo


3.1.2.- DISEO DETALLADO

Se ocupa del refinamiento de la representacin arquitectnica que conduce

a una estructura de datos detallada y la representacin algortmica del

software o diseo procedimental.

Diseo Procedimental: Define los detalles algortmicos de cada uno de los

mdulos producidos durante el diseo arquitectnico, es decir produce de

diagrama de cada mdulo as como especificaciones procedimentales.

Durante esta etapa es aconsejable un modelo de interfaz de usuario (diseo

preliminar) para que la evale el usuario y modificar su diseo conforme a

esta evaluacin.

El resultado de esta etapa es un Documento de Diseo Detallado que

incorpora un diseo detallado a los datos, del diccionario de datos, de la

interfaz hombre-mquina y de la arquitectura modular del sistema,

configurando todo ello el Documento de Diseo Final.

R.S Pressman aconseja usar el siguiente esquema de Especificacin de

diseo del Software:

a. mbito.- Incluye los objetivos del sistema, hardware, software e

interfaces de usuario, principales funciones del software, base de datos y

restricciones de diseo.

b. Documento de Referencia.- Incluye documentacin de software

existente, del sistema, referencias tcnicas.

c. Descripcin de Diseo.- Se desarrolla durante el Diseo Preliminar,

incorpora descripcin de los daos, estructura del programa e interfaces

dentro de la estructura.

d. Mdulos.- Incorpora para cada mdulo un texto explicativo, una

descripcin de interfaz.

Anlisis y diseo


3.2 DISEO DE SOFTWARE INTERNACIONALIZADO

El diseo de software se describe como el proceso de definir la arquitectura,

componentes, interfaces de un sistema. El rea donde se analizan los

requerimientos para producir la descripcin de la estructura interna del software.

3.2.1.- UNIFORMIDAD DE TERMINOLOGA EN LA DOCUMENTACIN

DEL SOFTWARE:

Se debe garantizar que los autores de los textos incluidos en men, dilogos,

botones, etc. y de la documentacin (manuales, ayuda en lnea, etc.) mantengan

una terminologa consistente en el tema y las secciones del software. As mismo la

presentacin de la documentacin al usuario fina es vital para garantizar que el

software tenga calidad. Es inaceptable la utilizacin de ciertos trminos y que en

otra seccin del software se utilice otra palabra para hacer referencia al mismo.

Para cumplir con sta recomendacin, se debe considerar la creacin de un

glosario terminolgico relacionado con la aplicacin del software.

3.2.2.- EXPANSIN DE INTERFACES GRFICAS:

Se debe garantizar que las interfaces grficas de usuario admitan una expansin

para permitir que el texto incluido en ellas se adapte correctamente una vez se

haya localizado, de manera que no se afecte la presentacin ni la funcionalidad de

dichas interfaces.

Esta recomendacin es necesaria cuando el software ser utilizado a nivel

internacional, se debe considerar el espacio adicional debido a la traduccin del

programa de un idioma u otro, ya que hay casos de duplicidad de caracteres,

afectando el diseo de las interfaces por el desborde del texto de sus posiciones

iniciales.

3.2.3.- DISEO INTERNACIONAL DE INTERFACES DE USUARIO:

Todas las interfaces de usuario deben ser diseadas para que tengan aceptacin

por parte de un pblico internacional.

Anlisis y diseo


Las interfaces de usuario son el medio principal mediante el cual el usuario final

interacta con el software; si un usuario percibe que la interfaz tiene cierta

predisposicin cultural no se puede afirmar que el software est

internacionalizado.

3.2.4.- SEPARAR LA CAPA DE DATOS DE LA CAPA DE

PRESENTACIN:

La capa de presentacin es la que define cmo se va a mostrar la informacin al

usuario final.

Desde la fase de diseo del software se debe definir una estrategia clara para

lograr separar la capa de presentacin de la de datos, ya que en el proceso de

localizacin generalmente slo es necesario adaptar la capa de datos y no se

modifica la capa de presentacin en las interfaces.

Para cumplir con sta recomendacin se debe considerar o definir si se puede

usar un patrn de arquitectura de software que permita separar las capas.

3.2.5.- OPTIMIZAR LOS ESQUEMAS DE LA BASE DE DATOS PARA

QUE SOPORTEN LA INTERNACIONALIZACIN:

Para disear una base de datos que soporte el almacenamiento de contenido

localizado se debe identificar qu valores se deben almacenar de forma

dependiente de la cultura y cules valores se deben almacenar en una

representacin uniforme que posteriormente se pueda convertir por la lgica de la

aplicacin.

La representacin de datos contenidos en la base de datos debe ser

independiente del local y la conversin de datos a partir de la presentacin original

debe ser realizada sin que haya prdida de informacin.

Anlisis y diseo


3.3.- FUNDAMENTOS DE DISEO

3.3.1 MODULARIDAD

El software se divide en componentes con nombres determinados que se

denominan mdulos. Un programa compuesto de un solo mdulo no puede ser

fcilmente manejado intelectualmente. Es ms fcil resolver problemas complejos

cuando se descomponen en trozos ms manejables. Puede concluirse que si

partiramos el software indefinidamente el esfuerzo para desarrollarlo sera

insignificantemente pequeo. Sin embargo existen otros factores que hacen

invlida esta conclusin. Debemos modularizar, pero debemos evitar tanto una

excesiva modulizacin como una pobre.

3.3.2 ARQUITECTURA DEL SOFTWARE

La arquitectura del software se refiere a:

1.-La estructura jerrquica de los componentes procedimentales, y

2.- La estructura de los datos.

La arquitectura del software se obtiene mediante un proceso de particin, que

relaciona los elementos de una solucin de software con partes de un problema

del mundo real definido en el anlisis de requisitos.

Ilustracin 8: Modularidad - Fundamentos de diseo

Anlisis y diseo


Usando alguna de las metodologas de diseo del software se producir un

determinado tipo de estructura del software.

Ilustracin 9: Arquitectura del software Evolucion de la Estructura

Ilustracin 10:Arquitectura del software - Diferentes Estructuras

Anlisis y diseo


3.3.3 JERARQUA DE CONTROL

La jerarqua de control, tambin denominada estructura del programa, representa

la organizacin de los componentes del programa (mdulos). Esto no representa

aspectos procedimentales del software, tales como la secuencia de procesos, la

ocurrencia u orden de las decisiones o la repeticin de operaciones.

3.3.4 ESTRUCTURA DE DATOS.

La estructura de datos es una representacin de la relacin lgica existente entre

los elementos individuales de datos. Debido a que la estructura de la informacin

afectar invariablemente al diseo procedimental final, la estructura de datos es

tan importante como la estructura del programa en la representacin de la

arquitectura del software.

4.- BUENAS PRACTICAS DE DISEO

4.1.- CONCEPTOS.

Buena Practica:

Una buena prctica es un mtodo bien definido que contribuye al xito de una

determinada actividad dentro del proceso de desarrollo de software, y que ha sido

probada a travs de la experiencia e investigacin.

Buena Prctica de Desarrollo de software:

Las buenas prcticas son un conjunto de prcticas definidas por un proceso o una

metodologa para obtener mejores resultados cuando se desarrolla software.

Por qu se desarrolla mal?

Falta de tiempo.

Falta de conocimiento.

Falta de motivacin.

Acudir a las Fuentes equivocadas.

Anlisis y diseo


Fallos en las etapas iniciales de desarrollo de Software (anlisis, requisitos,

etc.).

Etc.

Es muy frecuente en entornos tecnolgicos que por "diseo" se entienda

nicamente al diseo grfico. El diseo visual es el aspecto que mayor credibilidad

aporta a un producto, pero DISEAR UN PRODUCTO implica ms aspectos, slo

con ingeniera no se cumplen objetivos.

Tambin es diseo:

- Conocer a los usuarios y sus necesidades.

- Hacer test de usuarios.

- Crear prototipos.

- Definir correctamente requisitos.

- Establecer un proceso adecuado de desarrollo.

- Una buena interfaz de usuario.

- Contenidos adecuados.

Por qu buenas prcticas?

Establece reglas y convenios.

Aporta higiene al cdigo.

Estandariza el desarrollo.

Fcil lectura = Fcil mantenimiento.

Facilita la escalabilidad del cdigo.

Facilita la reutilizacin y la integracin de manera

Homognea.

Anlisis y diseo


Por qu es necesario hacer pruebas?

La labor de desarrollar software en una empresa (ya sea como producto o

herramienta interna) trae consigo la necesidad de asegurar que el trabajo

realizado se acerca (en lo posible) a la perfeccin en cuanta calidad y desarrollo

seguro. Evidentemente, esto redunda en la satisfaccin del equipo que logra los

objetivos como por parte del cliente que obtiene el mayor beneficio de un producto

finalizado.

Adems, como toda buena inversin, ahorra tiempo a largo plazo. Si trasladamos

por ejemplo los conceptos al entorno mvil, para asegurar el correcto

funcionamiento de las aplicaciones en cada tipo de terminal y sistema operativo, el

equipo de pruebas debe realizar diversos test a diferentes niveles (como veremos

en siguientes entregas). Excepto Google Play, las grandes compaas de

distribucin de apps (AppsStore y Microsoft Marketplace) suelen someter a

diversas pruebas las apps candidatas, para comprobar que se encuentran dentro

de unos umbrales mnimos de calidad. Este proceso puede ser de varios das

antes de recibir el visto bueno o el rechazo, con lo que el proceso debera volver a

comenzarse. Esta es una de las razones por las que someter cualquier aplicacin

a una buena batera de pruebas de forma interna.

En lo que refiere a buenas, o malas, prcticas de calidad software, existen

numerosos catlogos y guas. No obstante, me pareci interesante resumir las que

ms frecuentemente se observan y que suelen tener el mayor impacto,

normalmente disparando los costes de mantenimiento.

Anlisis y diseo


A nivel de cdigo o diseo, no olvides que:

4.2.- QUE LAS ESTRUCTURAS DE DATOS DEBEN ESTAR OCULTAS EN UN

SISTEMA SOFTWARE.

La ocultacin de la informacin o encapsulacin, sin entrar en tecnicismos

(le dejo eso al artculo), trata la idea de que los mdulos software (bien

sean clases, paquetes, sistemas, etc.) deben ocultar su informacin interna

al resto, ocultar sus estructuras de datos, incluso su diseo, para evitar as

que a otros mdulos se les ocurra depender de estas estructuras de datos

internas, accediendo a ellas directamente para obtener informacin. Para

evitarlo los mdulos deben proporcionar una interfaz y que sea slo a

travs de ella, a travs de mtodos, la nica forma de obtener informacin

de un mdulo software. De ah, por ejemplo, la buena prctica de que una

clase debe declarar sus atributos o estructuras de datos como privadas,

para que ningn objeto pueda acceder directamente a las mismas y slo

pueda obtener informacin por medio de un servicio.

Como todo en esta vida, esto tambin tiene una razn, o varias. Si un

mdulo pudiera acceder, leer atributos o estructuras de datos de otro,

entonces principalmente ocurriran dos cosas

A Si un da queremos cambiar las estructuras de datos nos ser muy

complicado.

Porque tendramos que modificar a todo aquel mdulo al que se le permiti

acceder a ellas. Pongamos un ejemplo, imaginemos que un mdulo o un

objeto tiene un dato edad, que est almacenado en una estructura simple

(un atributo tipo entero), pero tiempo despus nos da por querer almacenar

las 10 ltimas edades y para ello sustituir el entero por un array de

enteros tendramos entonces que buscar a todos aquellos mdulos que

accedan directamente al dato simple edad y modificarlos para que ahora

lean un array.

Anlisis y diseo


B El mdulo externo que acede a la estructura de datos de otro

podra leer datos no actualizados.

Por ejemplo, un mdulo podra guardar el dato edad y no tenerlo

actualizado. Si se accede directamente a una estructura de datos nadie se

responsabiliza de que lo que lee est actualizado. Pero si accedemos a

travs de una interfaz, de un servicio, un mtodo, un getEdad, este puede

asegurarse de actualizar el dato en el momento en que se pide. Adems de

que una cosa son las estructuras de datos y otra la informacin que un

mdulo nos puede proporcionar, que es sus estructuras de datos o atributos

+ los clculos que puede hacer con ellos.

4.3.- Y QUE HAY INCLUSO LISTAS DE MALOS OLORES QUE TE PUEDEN

DAR PISTAS DE QUE PROBLEMAS DE CALIDAD SOFTWARE TE PUEDES

ENCONTRAR.

Aqu una relacin de algunas cosas que no se deberan hacer a la hora de

disear o programar un sistema software. Los siguientes son un extracto de uno

de los catlogos ms interesantes sobre buenas prcticas a nivel de diseo

software y que los autores llamaron malos olores o cosas que vindolas me

pueden hacer pensar que algo va mal:

Mtodo Largo. Los programas que viven ms y mejor son aquellos con mtodos

cortos, que son ms reutilizables y aportan mayor semntica

Clase Grande. Clases que hacen demasiado y por lo general con una baja

cohesin, siendo muy vulnerables al cambio.

Lista de Parmetros larga. Los mtodos con muchos parmetros elevan el

acoplamiento, son difciles de comprender y cambian con frecuencia.

Anlisis y diseo


Obsesin Primitiva. Uso excesivo de tipos primitivos. Existen grupos de tipos

primitivos (enteros, caracteres, reales, etc.) que deberan modelarse como objetos.

Debe eliminarse la reticencia a usar pequeos objetos para pequeas tareas,

como dinero, rangos o nmeros de telfono que debieran muchas veces ser

objetos.

Clase de Datos. Clases que slo tienen atributos y mtodos tipo get y set. Las

clases siempre deben disponer de algn comportamiento no trivial.

Estructuras de agrupacin condicional. Lo que comentamos en un case o

switch con muchas clausulas, o muchos ifs anidados, tampoco es una buena idea

Comentarios. No son estrictamente malos olores, ms bien desodorantes. Al

encontrar un gran comentario se debera reflexionar sobre el porqu algo necesita

ser tan explicado y no es auto explicativo. Los comentarios ocultan muchas veces

a otro mal olor.

Atributo Temporal. Algunos objetos tienen atributos que se usan slo en ciertas

circunstancias. Tal cdigo es difcil de comprender ya que lo esperado es que un

objeto use todas sus variables.

Generalidad Especulativa. Jerarquas con clases sin utilidad actual pero que se

introducen por si en un futuro fuesen necesarias. El resultado es jerarquas

difciles de mantener y comprender, con clases que pudieran no ser nunca de

utilidad.

Cadena de Mensajes. Un cliente pide algo a un objeto que a su vez lo pide a otro

y este a otro, etc.

Clase Perezosa. Una clase que no est haciendo nada o casi nada debera

eliminarse.

Anlisis y diseo


Cambios en Cadena. Un cambio en una clase implica cambiar otras muchas. En

estas circunstancias es muy difcil afrontar un proceso de cambio.

Duplicacin de Cdigo. Lo que contamos en duplicar, o copy pegar, cdigo no es

una buena idea

Ilustracin 13: Reemplace el cdigo Type con la estrategia del Estado

Ilustracin 11: Estracto de la Clase Ilustracin 12: Reemplace el mtodo con el mtodo de objeto

Anlisis y diseo


Una de las razones para refactorizar es ayudar al cdigo a mantenerse en buena

forma, ya que con el tiempo los cambios en el software hacen que este pierda su

estructura, y esto hace difcil ver y preservar el diseo. Refactorizar ayuda a evitar

los problemas tpicos que aparecen con el tiempo, como, por ejemplo, un mayor

nmero de lneas para hacer las mismas cosas o cdigo duplicado.

Existen incluso posturas, como a la que comenta la metodologa gil XP, que

afirman que la refactorizacin puede ser una alternativa a disear, codificando y

refactorizando directamente, sin ms. Sin llegar a extremos tan radicales y poco

recomendables, s que es cierto que una buena refactorizacin cambia el rol del

tradicional del diseo planificado, pudiendo relajar la presin por conseguir un

diseo totalmente correcto en fases tempranas, buscando slo una solucin

razonable.

Otro aspecto importante es que ayuda a aumentar la simplicidad en el diseo. Sin

el uso de refactorizaciones se busca la solucin ms flexible para el futuro, siendo

estas soluciones, por lo general, ms complejas y, por tanto, el software resultante

ms difcil de comprender y por ello de mantener. Adems, ocurre que muchas

veces toda esa flexibilidad no es necesaria, ya que es imposible predecir qu

cambiar y dnde se necesitar la flexibilidad, forzado poner mucha ms

flexibilidad de la necesaria (sntoma de esto es la sobrecarga de patrones). Con la

refactorizacin en lugar de implantar soluciones flexibles antes de codificar se

hace despus, tratando con diseos ms simples sin sacrificar la flexibilidad.

En lo que refiere al proceso de refactorizacin, existen algunos consejos y buenas

prcticas a tener en cuenta:

4.3.1.- NO AADIR FUNCIONALIDAD MIENTRAS SE REFACTORIZA.

La regla bsica de la refactorizacin es no cambiar la funcionalidad del

cdigo o su comportamiento observable externamente. El programa debera

comportarse exactamente de la misma forma antes y despus de la

Anlisis y diseo


refactorizacin. Si el comportamiento cambia entonces ser imposible

asegurar que la refactorizacin no ha estropeado algo que antes ya

funcionaba.

4.3.2.- UN USO RIGUROSO DE LAS PRUEBAS.

No se debera comenzar un proceso de refactorizacin si no se dispone de

un buen conjunto de pruebas. Las pruebas son necesarias porque permiten

comprobar que una vez refactorizado el software mantiene su funcionalidad.

4.3.3.- REFACTORIZAR EN DIFERENTES MOMENTOS DEL CICLO DE VIDA. Se aconseja refactorizar antes de aadir nueva funcionalidad (haciendo

ms fcil aadirla) o despus (simplificando el cdigo una vez introducida),

cuando se necesita reparar un error o al revisar el cdigo.

4.3.4.- USAR LOS BAD SMELLS (MALOS OLORES). Los bad smells pueden ser una buena ayuda a la hora de detectar dnde

aplicar refactorizaciones.

Por otro lado, hay que considerar que llevar a cabo la refactorizacin manual

supondr una tarea larga y tediosa. Tokuda y Batory presentaron un caso de

estudio en el que se aplicaron 800 refactorizaciones a un programa de 500k lneas

de cdigo y que llevo dos semanas de trabajo hacindolo de manera manual y

dos das de manera automatizada. Por ello, desde hace aos se ha estado

trabajando en herramientas de refactorizacin, siendo Smalltalk Refactoring

Browser de 1999, desarrollada bajo del marco de la Tesis de Roberts, la que se

considera primera herramienta de refactorizacin. Pero, sin embargo, an hoy, el

problema de automatizar la refactorizacin sigue siendo complejo, ya que aunque

hay refactorizaciones que apenas necesitan analizar la estructura del software,

como, por ejemplo, aquellas que se encargan de renombrar, pero la mayora debe

analizar y manipular el rbol del programa, y en ocasiones esto es complejo, por lo

que an queda camino por recorrer en la automatizacin de la refactorizacin.

Anlisis y diseo


5.- CONCLUSIONES

En una organizacin o Empresa, el anlisis y Diseo de Sistemas, es el proceso

de estudiar su Situacin con la finalidad de observar como trabaja y decidir si es

necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el

analista de sistemas.

Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio

de Sistemas para detectar todos los detalles de la situacin actual de la empresa.

La informacin reunida con este estudio sirve como base para crear

varias estrategias de Diseo. Los administradores deciden que estrategias seguir.

Es sabido que el software no facilita la vida de muchas maneras entre ellos

resalta el SO que es muy importante ya que controla el funcionamiento del

computador y el de los dems programas.

La estructura interna de un software es un activo intangible como las licencias, la

creatividad, patentes, etc. La estructura interna es regida por pasos secuenciados

para su ejecucin, tambin se incluyen conceptos como el funcionamiento del

computador y el de los dems programas. Y saber que es Activos intangibles e

investigacin y desarrollo

En las buenas prcticas de diseo al momento de desarrollar un software o

sistema tenemos que tener en cuenta los requisitos de los usuarios o para quien

va dirigido el software.

Anlisis y diseo


6.- RECOMENDACIONES

El Anlisis y diseo de software es de demasiada importancia, dado que sin ello,

sin el arte de analizar y plasmar ideas, objetivos de lo que se quiere lograr no

llegaremos al objetivo general.

Un buen anlisis nos ayuda a poder entender el entorno de la cual se est

realizando un estudio, obteniendo como resultados lo requerimientos,

entendimiento de sus procesos, etc. para luego hacer un diseo donde

plasmaremos todo ello tanto sus requerimientos como sus procesos, funciones y

todo que nos lleve y sirva para lograr los objetivos del software que se desea

implementar.

Sin un buen anlisis y diseos obtendremos como resultado un mal software, que

no cumple las expectativas del cliente.

En las buenas prcticas de diseo de software nos daremos cuenta que tan

necesario es hacer pruebas en lo que se est desarrollando para ver si tenemos

brechas en nuestro sistema o producto si vamos por buen camino hacia el objetivo

del software o sistema que tiene que tener calidad y eficiencia etc.

Anlisis y diseo


7.- BIBLIOGRAFIA Calidad de diseo: http://www.eumed.net/tesis-doctorales/2014/jlcv/calidad-software.htm Etapas del diseo de sistemas: http://eduardoummma.galeon.com/cvitae1770705.html Criterios tcnicos del Diseo:

http://eduardoummma.galeon.com/cvitae1770707.html Principios del Diseo: http://albertolacalle.com/diseno/principios.htm Simplicidad en el Diseo: http://albertolacalle.com/diseno/simple.htm Calidad de atributos y calidad en anlisis y evaluacin de tcnicas: http://www.monografias.com/trabajos73/diseno-software/diseno-software2.shtml Estructura Interna del Software http://www.voigtmann.de/es/desarrollo-de-software/arquitectura-de-software/ http://redes.webs.uvigo.es/ffi/complementos/perifericos/Partes%20de%20un%20computador.htm http://es.slideshare.net/jcfdezmx2/cadena-valor-de-los-intangibles-presentation

https://books.google.com.pe/books?id=rXU-

WS4UatYC&pg=PA441&lpg=PA441&dq=QUe+es+la+Estructura+interna+de+un++software&source

=bl&ots=vvtKw64p2U&sig=YQhhi73jI2xPCyrboVjSfytt-

Us&hl=es&sa=X&ved=0CCYQ6AEwAmoVChMIrfDAy4aCyQIVBCQmCh2jYQvh#v=onepage&q=QUe

%20es%20la%20Estructura%20interna%20de%20un%20%20software&f=false

https://joshdead.wordpress.com/2011/11/01/estructura-internasoftware-del-pc/

http://www.monografias.com/trabajos94/sistema-informacion-gerencial-estrategico/sistema-

informacion-gerencial-estrategico.shtml

https://es.wikipedia.org/wiki/Activo_intangible

Consideraciones del diseo del software http://indalog.ual.es/mtorres/LP/FundamentosDiseno.pdf

Anlisis y diseo


Buenas prcticas de diseo: http://www.javiergarzas.com/calidad-software https://prezi.com/pe4mkalxy9yr/buenas-practicas-de-desarrollo-de-software/ http://docplayer.es/3182121-Buenas-practicas-en-diseno-de-software-albertolacalle-com-esi.html

a&d control de calidad fis

Documents