A&D Control de Calidad Fis

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
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.
Control de calidad del software
Pgina 1
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
Pgina 2
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
Pgina 3
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
Pgina 4
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
Pgina 5
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
Pgina 6
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:
Pgina 7
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
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
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,
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.
Pgina 8
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.
Pgina 9
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
Pgina 10
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
Pgina 11
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.
Pgina 12
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.
Pgina 13
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.
Pgina 14
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.
Pgina 15
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:
Pgina 16
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
Pgina 17
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
Pgina 18
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.
Pgina 19
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.
Ilustracin 7: Investigacion y Desarrollo
Intangibles vs Indicadores
ACTIVOS INTANGIBLES
Capacidad de
organizacin
innovacin
INDICADORES
de
la
Porcentaje de recursos que destina la

empresa a I+D
Creatividad
Nmero de patentes
Investigacin y desarrollo
Proyectos de investigacin en los que

participa la empresa
Organizacin
informacin
de
sus
sistemas
de
Premios o reconocimientos a la innovacin
Uso eficiente de tecnologas de la

comunicacin
Grado de automatizacin de las tareas

administrativas
Tipo de direccin
Nmero de documentos que han dejado de

procesarse en formato papel
Grado de descentralizacin de la toma

de decisiones
Nivel de burocracia interna
Porcentaje de personal con acceso a la

Intranet y grado de utilizacin
Capacidad para trabajar en grupo
Pgina 20
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
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.
Pgina 21
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.
Pgina 22
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.
Pgina 23
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.
Pgina 24
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.
Pgina 25
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
predisposicin
cultural
no
se
puede
afirmar
que
el
tiene cierta
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.
Pgina 26
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.
Ilustracin 8: Modularidad - Fundamentos de diseo
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.
Pgina 27
Anlisis y diseo
Ilustracin 9: Arquitectura del software Evolucion de la Estructura
Usando alguna de las metodologas de diseo del software se producir un

determinado tipo de estructura del software.
Ilustracin 10:Arquitectura del software - Diferentes Estructuras
Pgina 28
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.
Pgina 29
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.
Pgina 30
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.
Pgina 31
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.
Pgina 32
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.
Pgina 33
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.
Pgina 34
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 11: Estracto de la Clase
Ilustracin 12: Reemplace el mtodo con el mtodo de objeto
Ilustracin 13: Reemplace el cdigo Type con la estrategia del

Estado
Pgina 35
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
Pgina 36
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.
Pgina 37
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.
Pgina 38
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.
Pgina 39
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.ht
m
http://es.slideshare.net/jcfdezmx2/cadena-valor-de-los-intangibles-presentation
https://books.google.com.pe/books?id=rXUWS4UatYC&pg=PA441&lpg=PA441&dq=QUe+es+la+Estructura+interna+de+un++software&source
=bl&ots=vvtKw64p2U&sig=YQhhi73jI2xPCyrboVjSfyttUs&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/sistemainformacion-gerencial-estrategico.shtml
https://es.wikipedia.org/wiki/Activo_intangible
Consideraciones del diseo del software
http://indalog.ual.es/mtorres/LP/FundamentosDiseno.pdf
Pgina 40
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
Pgina 41

A&amp;D Control de Calidad Fis

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

A&amp;D Control de Calidad Fis

Încărcat de

Drepturi de autor:

Formate disponibile

Anlisis y Diseo

CONTROL DE CALIDAD DE SOFTWARE

Control de calidad del software

Control de calidad del software

Control de calidad del software

Control de calidad del software

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

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

Control de calidad del software

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

Control de calidad del software

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

Debe presentarse y entenderse el dominio de la informacin de un

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

Control de calidad del software

proporcionan capacidad de clculos y funciones rpidas, exactas y

herramientas del Sistema.

descriptiva que detalla o da instrucciones sobre el empleo y

Control de calidad del software

Varias tcnicas y herramientas pueden ayudar a mejorar la calidad

Control de calidad del software

Cuando se examina un elemento sus caractersticas mensurables se pueden

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

Ilustracin 1: Diseo y su Importancia

Control de calidad del software

Ilustracin 2: Diseo de los datos

1.2.1.2.- El Diseo Arquitectnico.

Ilustracin 3: Diseo Arquitectnico

Control de calidad del software

Ilustracin 4: Diseo de Interfaz

1.2.1.4.- El Diseo de Procedimientos.

Control de calidad del software

Ilustracin 5: Diseo de Procedimientos

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

Control de calidad del software

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

Control de calidad del software

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

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

Control de calidad del software

Proximidad: Los diseos sencillos son ms fciles de entender y

Reconocibilidad: Son ms fcilmente reconocibles y asimilables, ya

Inmediatez: Los diseos sencillos tienen un impacto mayor

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

2.- ESTRUCTURA INTERNA DEL SOFTWARE

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

El sistema operativo es el programa ms importante porque controla el

Control de calidad del software

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

2.1.- DEFINICIN ARQUITECTURA DE SOFTWARE

2.2.-ARQUITECTURA DE SOFTWARE EN EL PROCESO DE

2.3.- CARACTERSTICAS DE UNA ARQUITECTURA DE

Control de calidad del software

2.4.-ACTIVOS INTANGIBLES DE ESTRUCTURA INTERNA:

Control de calidad del software

Control de calidad del software

Ilustracin 7: Investigacion y Desarrollo

Porcentaje de recursos que destina la

Proyectos de investigacin en los que

Premios o reconocimientos a la innovacin

A&D Control de Calidad Fis

A&D Control de Calidad Fis