La fase de diseño en la ingeniería de software es un proceso iterativo que traduce requisitos en un plano para construir software, integrando calidad a través de principios de diseño modular y arquitectónico. Se enfoca en la creación de modelos de diseño que abordan aspectos como funcionalidad, usabilidad y eficiencia, asegurando que la solución sea comprensible, mantenible y cumpla con los estándares de calidad. Además, incluye metodologías para asegurar la calidad del software mediante revisiones formales y control de calidad en cada etapa del desarrollo.

1. FASE DE DISEÑO

2. ¿QUE ES?:
Es un proceso iterativo por medio del cual se
traducen los requerimientos en un “plano” para
construir el software
IMPORTANCIA:
El diseño es el sitio en el que se introduce
calidad en la ingeniería de software.
EL DISEÑO EN LA INGENIERÍA

4. UN DISEÑO CON CALIDAD DEBE
POSEER
• Debe implementar todos los requerimientos
explícitos implícito.
• Debe ser una guía legible y comprensible para
quienes generan el código y para los que lo
prueban y dan el apoyo posterior.
• Debe proporcionar el panorama completo del
software, las funciones y el comportamiento desde
el punto de vista de la implementación.

5. LINEAMIENTOS DE LA CALIDAD
1. Debe tener una arquitectura
2. Debe ser modular
3. Debe contener distintas representaciones
de datos
4. Debe conducir a estructuras de datos
5. Debe llevar a componentes
6. Debe conducir a interfaces
7. Debe representar con eficiencia los
requerimientos

6. ATRIBUTOS DE CALIDAD
Los atributos de calidad FURPS representan el
objetivo de todo diseño de software:
• Funcionalidad
• Usabilidad
• Confiabilidad
• Rendimiento
• Mantenibilidad

7. CONCEPTOS
• ABSTRACCIÓN
- por Niveles:
En el mas alto la solución generalizada y el mas bajo mas
detallada
- de Procedimientos:
Una secuencia de instrucciones que tiene una función
especifica y limitada
- de Datos:
Es un conjunto de éstos con nombre que describe a un
objeto de datos.

8. • ARQUITECTURA:
Es la estructura de organización de los componentes de
un programa la forma en la que éstos interactúan y la
estructura de datos que utilizan.
- Propiedades estructurales
- Propiedades extrafuncionales
- Familias de sistemas relacionados

9. • PATRONES:
Describe una estructura de diseño que resuelve un
problema particular del diseño dentro de un contexto
específico y entre “fuerzas” que afectan la manera en la
que se aplica y en la que se utiliza dicho patrón.
• DIVISIÓN DE PROBLEMAS:
Sugiere que cualquier problema complejo puede
manejarse con más facilidad si se subdivide en
elementos susceptibles de resolverse u optimizarse de
manera independiente.

10. • MODULARIDAD:
El software se divide en componentes con nombres
distintos y abordables por separado, en ocasiones
llamados módulos, que se integran para satisfacer los
requerimientos del problema.
¿Cómo descomponer una solución de software para
obtener el mejor conjunto de módulos?

11. • OCULTAMIENTO DE LA INFORMACIÓN:
Sugiere especificarse y diseñarse módulos, deforma que
la información (algoritmos y datos) contenida en un
módulo sea inaccesible para los que no necesiten de
ella.
Para que la modularidad efectiva se logra definiendo un
conjunto de módulos independientes que intercambien
sólo aquella información necesaria para lograr la función
del software.
Al quedar ocultos la mayoría de los datos y detalles
minimiza la probabilidad de propagación de errores al
dar mantenimiento al software.

12. • REFINAMIENTO:
Es un proceso de elaboración, La abstracción y el
refinamiento son conceptos complementarios.
La primera permite especificar internamente el
procedimiento y los datos, pero elimina la necesidad de
que los “extraños” conozcan los detalles de bajo nivel.
El refinamiento ayuda a revelar estos detalles a medida
que avanza el diseño. Ambos conceptos permiten crear
un modelo completo del diseño conforme éste
evoluciona

13. CLASES DE DISEÑO
Pueden desarrollarse cinco tipos diferentes de clases de
diseño, cada una de las cuales representa una capa distinta
de la arquitectura del diseño
• USUARIO: interacciones humano-computador
• DOMINIO: atributos y servicios
• PROCESO: administración de dominio
• PERSISTENTES: almacenamiento de datos
• SISTEMAS: administración y control del software

14. Definen cuatro características de las clases de diseño
bien formadas:
- Completa y suficiente
- Primitivismo
- Mucha Cohesión
- Poco Acoplamiento

15. MODELO DE DISEÑO
• Diseño de la arquitectura: Daniel L y
Cristian A
• Diseño en el nivel de los componentes:
Gordillo y marlon
• Diseño en la interfaz del usuario: Jarod y
Sergio G
• Diseño en patrones: Nicolas y Jairo
• Técnicas de revisión: Wilfran y Karen

16. ACTIVIDAD

17. DISEÑO ARQUITECTÓNICO
Dominio del modelo
de análisis
• Dominio de datos
• Dominio de funciones
• Dominio de comportamiento
DISEÑO DEL
SOFTWARE
Sintetiza
representacio
nes de datos
Sintetiza
estructura de
datos
Detalles del
procedimiento
Estructura del
programa
Consolida la
interfaz
METODO DEL
DISEÑO

18. Representa la estructura
de datos y de los
componentes del software
 El diseño de datos (estructura o
arquitectura del software)
 Analiza alternativas, estilos y patrones.
 Realiza la arquitectura mediante el
modelo de diseño.
1. Analizar la efectividad del diseño
2. Construir alternativas en etapas donde se
puedan hacer cambios
3. Reduce riesgos asociados a la construcción
del software
 QUE PERMITE?
 COMO HACERLO?
 QUE ES?
 IMPORTANCIA
Muestra el panorama general y se
asegura que sea el correcto.
Tres razones claves :
Permiten la comunicación
entre todas las partes
(participantes)
interesadas en el
desarrollo de un sistema.
Resalta las primeras
decisiones que tendrán
un efecto profundo en
todo el trabajo de
ingeniería de software.
Constituye un modelo
pequeño y asequible sobre
cómo está estructurado el
sistema y la forma en la
que sus componentes
trabajan juntos.
1 2 3

19. Géneros Arquitectónicos
El que dicta el enfoque específico para la estructura que debe
construirse e implica una categoría específica dentro del dominio
general del software.
 Inteligencia Artificial
 Comerciales y no lucrativos
 Comunicaciones
 Contenido de autor
 Dispositivos
 Entretenimiento y deportes
 Financieros
 Juegos
 Gobierno
 Industrial
 Legal
 Médicos
 Militares
 Sistemas Operativos
 Plataformas
 Científicos
 Herramientas
 Transporte
 Utilidades

20. Taxonomía de estilos
• Arquitecturas centradas en los datos: promueven la integridad,
el centro de esta arquitectura se halla un almacenamiento de datos (como
un archivo o base de datos) al que acceden con frecuencia otros
componentes que actualizan, agregan, eliminan o modifican los datos de
cierto modo dentro del almacenamiento.

21. • Arquitecturas de flujo de datos
Se aplica cuando datos de entrada van a transformarse en datos de salida a
través de una serie de componentes computacionales o manipuladores.

22. • Arquitecturas de llamar y regresar.
Este estilo arquitectónico permite obtener una estructura de programa que
es relativamente fácil de modificar y escalar.

23. • Arquitecturas en capas
Se define un número de capas diferentes; cada una ejecuta operaciones
que se aproximan progresivamente al conjunto de instrucciones de
máquina.

24. Patrones Arquitectónicos
Se abocan a un problema de aplicación específica dentro
de un contexto dado y sujeto a limitaciones y restricciones.
El patrón propone una solución arquitectónica que sirve
como base para el diseño de la arquitectura.
• Debe describir una organización de sistema que ha
tenido éxito en sistemas previos.
• Debe incluir información sobre cuándo es y cuándo no es
adecuado usar dicho patrón, así como sobre las
fortalezas y debilidades del patrón.

25. Organización y el Refinamiento
Se usan para evaluar el diseño arquitectónico obtenido mediante,
CONTROL:
• ¿Cómo se administra el control dentro de la arquitectura?
• ¿Cómo transfieren el control los componentes dentro del sistema?
• ¿El control está sincronizado o los componentes operan en forma
asincrónica?
DATOS:
• ¿Cómo se comunican los datos entre los componentes?
• ¿El flujo de datos es continuo o los objetos de datos pasan al sistema
en forma esporádica?
• ¿Cuál es el modo de transferencia de datos?

26. Arquetipos
Los arquetipos son los bloques constructivos de un diseño arquitectónico.
Es una clase o un patrón que representa una abstracción fundamental de
importancia crítica para el diseño de una arquitectura para el sistema
objetivo.
Representan elementos estables de la arquitectura, pero que son
implementadas en muchos modos diferentes con base en el
comportamiento del sistema.

27. ACTIVIDAD

28. Proceso eficaz de software que se aplica de manera que
crea un producto útil que proporciona valor medible a
quienes lo producen y lo utilizan.
• Reduce costos por repetición y mejora entrada al
mercado
Que es Calidad del Software?
TRASCENDENTAL:
Se reconoce pero
es difícil de definir
USUARIO: Cumple
los requerimientos
y funcionalidad
FABRICANTE:
Cumple las
especificaciones
originales
PRODUCTO:
Implementación de
funciones y
características
VALOR: Lo que el
cliente esta
dispuesto a pagar
David Garvín en 1984

29. Atributos de calidad ISO 9126
• FUNCIONALIDAD: Adaptabilidad, exactitud, interoperabilidad,
cumplimiento y seguridad
• CONFIABILIDAD: Madurez, tolerancia a fallas y robustez
• USABILIDAD: Entendible, intuitiva y operable
• EFICIENCIA: Comportamiento del tiempo y de los recursos
• FACILIDAD DE RECIBIR MANTENIMIENTO: Analizable,
cambiable, estable y susceptible de someterse a pruebas
• PORTABILIDAD: Adaptable, instalable, conformidad y
sustituible

30. Test de comprobación de atributos
Prototipo de la interfaz del usuario ¿Es de alta calidad?
INTUITIVA
• ¿Todas las operaciones son fáciles de localizar e iniciar?
• ¿La interfaz usa patrones esperados de uso?
EFICIENCIA
Localizar información o iniciar operaciones
• ¿Economía de movimientos para entrada de datos y operaciones?
• ¿Datos de salida están presentados para facilitar su legibilidad?
Para cada factor de la calidad que se desee evaluar se desarrollaran
preguntas similares.

31. Costo de la Calidad
Costo de corrección de un error en función del tiempo de detección

32. Lograr la Calidad del Software
Métodos de la ingeniería del Software
 Análisis de requisitos para entender el problema a resolver
 Diseño adecuado al problema y que cumpla con las
dimensiones, atributos y factores de calidad estudiados
Técnicas de administración de proyectos
 Estimaciones para verificar que las fechas pueden cumplirse
 Dependencias de las actividades programadas
 Planificación del riesgo

33. Lograr la Calidad del Software
Control de calidad
 Acciones de ingeniería de software que ayudan a asegurar que
todo producto del trabajo cumpla sus metas de calidad
• Técnicas de revisión de modelos para ver si son consistentes y
completos.
• Inspección de código para detectar errores, manipulación de datos
y comunicación con la interfaz.
• Métricas de calidad con retroalimentación para mejorar el proceso
de desarrollo.
Aseguramiento de la calidad del Software
 Infraestructura de apoyo a métodos de ingeniería del software,
funciones de auditorias de informes.

34. Técnicas de Revisión Formales
OBJETIVO
Descubrir los errores en
funcionamiento, lógica o
implementación de cualquier
representación del Sw, se centra
en una parte especifica y
pequeña del sistema.
Al reducir el alcance se tiene mayor probabilidad de detectar errores!!
Ejemplo:
• Una parte del modelo de
requerimientos
• El diseño detallado de
un componente
• El código fuente, etc.
PROCEDIMIENTO
Cada técnica de revisión formal se realizara como una Reunión y
tendrá éxito solo si se plantea, controla y ejecuta de la manera
adecuada

35. Técnicas de Revisión Formales
1. El día previo
 Individuos:
o Desarrollador del Sw
o Líder del proyecto
o Líder de revisión
o Revisores
 Escenario de preparación previa:
1. El productor informa al líder del proyecto que ha terminado y
requiere hacer una RTF
2. El líder de l revisión expone las principales conclusiones en cuanto
al producto, genera copias de los materiales del producto y los
distribuye a los revisores
3. Los revisores dedicaran hasta 2 horas para familiarizarse con el
trabajo
4. El líder del proyecto revisa el producto y establece una agenda
para la reunión de revisión del día siguiente

36. Técnicas de Revisión Formales
2.1 El día de la RTF
 Individuos:
o Líder de la revisión
o El productor
o Revisores
 Escenario:
o Se analiza la agenda del día
o El productor describe detalladamente el producto del trabajo
a revisar
o Los revisores hacen comentarios en base a la preparación
que hicieron
o Cuando se descubren los errores se toma nota de ellos

37. Técnicas de Revisión Formales
2.2 El día de la RTF
 Al terminar todos los asistentes deben de decidir:
o Aceptan el producto sin modificaciones
o Rechazarlo debido a los errores graves (una vez corregidos
se realiza otra revisión)
o Aceptar el producto de manera provisional (se detectaron
errores menores que deben corregirse pero no se necesita
otra revisión)
 Se firma el acta para cerrar la revisión

38. Técnicas de Revisión Formales
3. Productos de trabajo tras la RTF
 Reporte técnico formal (1 pagina)
o Que se reviso?
o Quien lo reviso?
o Cuales fueron los hallazgos y las conclusiones?
o Se entrega al líder del proyecto
 Reporte Técnico formal (anexo: lista de pendientes)
o Identificar áreas de problemas en el producto
o Sirve como lista de verificación de acciones que guie al
productor cuando se hagan las correcciones
o El líder del proyecto dará seguimiento a la corrección de
todos los elementos indicados en la lista

39. Aseguramiento de la Calidad del Sw
Administración y actividades especificas del proceso del Sw para
garantizar UN SOFTWARE DE ALTA CALIDAD
ETAPAS:
1. Definirse calidad del software en varios niveles de
abstracción
1. Identificar Un conjunto de actividades de ACS que filtren los
errores antes de que se conviertan en defectos
1. Desarrollarse el control de calidad y las actividades
1. Usarse métricas para desarrollar estrategias a fin de mejorar
el proceso de software

40. Elementos / Actividades del ACS
 Estándares:
IEE, ISO. Una organización de Sw los adopta voluntariamente o
los impone el cliente.
• El ACS asegura que los estándares se sigan para todos
los productos
 Revisiones y Auditorias
Revisiones técnicas permiten detectar errores
• El ACS comprueba que se sigan las buenas practicas en
el proceso de revisión técnica del Sw
 Pruebas:
Función de control de calidad para detectar errores.
• El ACS garantiza que las pruebas se planifiquen de
manera adecuada y se realicen con eficiencia.

41. Elementos / Actividades del ACS
 Colección y Análisis de errores:
Para mejorar hay que medir como se esta haciendo algo
• El ACS reúne y analiza errores y datos acerca de los
defectos para entender como se cometen y que
actividades son adecuadas para eliminarlos
 Administración del cambio:
El software puede cambiar
• El ACS asegura que se hayan seguido practicas
adecuadas para la admón. del cambio
 Educación:
La formación de los participantes mejora las practicas del ISw
• El ACS lleva el liderazgo en la formación y ha de
proponer y patrocinar programas educativos

42. Elementos / Actividades del ACS
 Administración de los proveedores:
Tipo externo del Software.
o Paquetes en una caja (office Microsoft)
o Shell personalizado: esqueleto de Sw que se adaptar y
configurar a las necesidades del comprador
o Software contratado: diseña y construye Ad Hoc a partir de
las especificaciones del cliente
• El ACS garantiza que el proveedor proporcione Sw de
alta calidad y se establezcan clausulas de calidad de
contrato con el proveedor
 Administración de la seguridad:
Delitos cibernéticos, privacidad, cortafuegos en webapps, etc.
• El ACS garantiza que para lograr la seguridad del Sw se
utilice el proceso y tecnología adecuada

43. Elementos / Actividades del ACS
 Seguridad:
La consecuencia de defectos ocultos en Sw critico (aplicaciones
automotrices o aeronáuticas) puede ser catastrófico
• El ACS Evalúa el efecto de los defectos de Sw e indica los
pasos requeridos para disminuir el riesgo
 Administración de riegos:
Análisis y mitigación de riesgos es responsabilidad de los Ing de Sw
• El ACS garantiza que las administraciones de riesgos se
efectúen de manera adecuada y que se diseñen planes de
contingencia adecuados

44. ACTIVIDAD

45. Trabajar duro para diseñar casos de prueba a fin de
ROMPER O REVENTAR el software.
Prueba de Aplicaciones
Convencionales
Una vez generado el código
fuente, el software debe
probarse para descubrir y
corregir tantos errores como sea
posible antes de entregarlo al
cliente
Como?? Cual es la meta?
Diseñar una serie de casos de
prueba que tengan una alta
probabilidad de encontrar errores