1. Propósito de la Fase de Diseño

La fase de diseño busca incorporar la tecnología a los requisitos esenciales del usuario, proyectando lo que se construirá en la ejecución. Esta fase se centra en buscar la mejor solución entre las distintas alternativas identificadas que cumplen con los requisitos. Mientras que el análisis se centra en identificar el dominio del negocio, el diseño define cómo se construirá una solución específica. En este punto, el análisis de las tecnologías y el entorno disponibles es crucial, ya que define el camino a seguir para adoptar una tecnología específica.

2. Proyectos Generados en la Fase de Diseño

• Diseño arquitectónico del software
• Diseño de interfaces
• Diseño de datos
• Diseño de tareas (procedimientos)

3. Requisitos para un Proyecto Modular

• Abstracción: Representar el sistema completo a construir.
• Enfoque: Guiar la construcción de cada detalle.
• Perspectivas: Ofrecer diferentes visiones del sistema.
• Flexibilidad: Considerar enfoques alternativos basados en los requisitos del problema, los recursos disponibles y los conceptos del proyecto.
• Trazabilidad: Remontarse al modelo de análisis.
• Reutilización: Reutilizar componentes existentes («no reinventar la rueda»).
• Conexión con el mundo real: Minimizar la brecha conceptual entre el software y el mundo real.
• IMPORTANTE: Un proyecto modular debe estructurarse en módulos o componentes cohesivos y débilmente acoplados.

4. Requisitos para un Proyecto Confiable

La confiabilidad se refiere a la preservación de la disponibilidad del sistema y la integridad de la información almacenada. Se deben considerar las restricciones de integridad, el control de concurrencia y la recuperación ante desastres. Además, en cuanto al modelo de análisis, se debe:

• Completitud: Contemplar todos los requisitos explícitos del modelo de análisis y los implícitos deseados por el cliente.
• Claridad: Ser una guía fácil de leer y comprender para quienes codifican, prueban y mantienen el software.
• Visión completa: Proporcionar una imagen completa del software, abordando los aspectos funcionales, de comportamiento y de datos.
• Adaptabilidad: Estar estructurado para adaptarse a los cambios.
• Manejo de excepciones: Acomodar circunstancias inusuales y, si es necesario abortar el proceso, hacerlo de forma controlada.
• Abstracción: Mantener un nivel de abstracción por encima del código fuente.
• Calidad: Ser objeto de una evaluación de calidad.
• Revisiones: Revisarse para minimizar los errores.

5. Visión Arquitectónica

Las vistas arquitectónicas capturan las decisiones de diseño importantes, mostrando cómo la arquitectura del software se descompone en componentes y cómo estos se conectan mediante conectores. Buscan separar las diferentes áreas en vistas separadas para gestionar la complejidad del sistema. Cada vista describe diferentes conceptos de ingeniería, reduciendo la cantidad de información que el arquitecto de software debe manejar en un momento dado.

Vistas Arquitectónicas Comunes:

• Vista de Casos de Uso: Contiene los casos de uso y escenarios que cubren comportamientos significativos en términos de arquitectura, clases o riesgos técnicos. Es un subconjunto del modelo de casos de uso.
• Vista Lógica: Contiene las clases y su organización en paquetes y subsistemas, y la organización de estos en capas. Contiene algunas realizaciones de casos de uso. Es un subconjunto del modelo de diseño.
• Vista de Implementación: Contiene una visión general del modelo de implementación y su organización en módulos y paquetes en capas. Describe la asignación de paquetes y clases (Vista Lógica) a paquetes y módulos. Es un subconjunto del modelo de implementación.
• Vista de Proceso: Contiene la descripción de las tareas (procesos e hilos), sus interacciones, configuraciones y la asignación de objetos y clases a tareas de diseño. Solo se utiliza si el sistema tiene un grado significativo de concurrencia. En RUP, es un subconjunto del modelo de diseño.
• Vista de Despliegue: Contiene la descripción de los nodos físicos, las configuraciones comunes de la plataforma y la asignación de tareas (Vista de Proceso) a nodos físicos. Solo se utiliza si el sistema es distribuido. Es un subconjunto del modelo de implementación.

6. Factores para Aumentar la Economía de un Proyecto

• Reutilización: Código parcial, módulos, bibliotecas de módulos, proyectos.
• Herramientas CASE
• Documentación
• Entorno (hardware, software y personal)
• Arquitectura de software alineada con el modelo de negocio

7. Cómo Incrementar el Mantenimiento del Software

El mantenimiento se centra en la facilidad de cambio. Para mejorar el mantenimiento, se deben establecer normas y estándares para interfaces de usuario, informes, mensajes, codificación, nomenclatura de archivos y módulos; documentar el código; y modularizar el sistema.

8. Controles para la Tolerancia a Fallos

• Archivos: Registros de encabezado y fin de archivo.
• Copias de seguridad
• Archivos de registro para deshacer o rehacer transacciones
• Replicación de datos (grabación simultánea en dos discos)

9. Ejemplos de Tipos de Errores

• Humanos: Errores de escritura o del sistema operativo.
• De operación: Desbordamiento en tiempo de ejecución, división por cero, etc.
• De sistema: Problemas de hardware, falta de energía, etc.
• De comunicación: Caída de la línea, etc.
• De software: Errores de desarrollo.

10. Limitaciones a Considerar en el Diseño

Limitaciones de la Tecnología:

• Costo
• Capacidad de almacenamiento
• Velocidad de procesamiento
• Posibilidad de fallo tecnológico

Impactos de la Tecnología Imperfecta:

• Uso de diferentes procesadores/distribución/comunicación
• Redundancia: Repetición de actividades y datos
• Inclusión de datos derivados (ej. totalizadores)
• Nuevas actividades para mitigar la imperfección tecnológica (ej. auditoría)

Estudio de Requerimientos Tecnológicos con los Usuarios:

• Ubicación geográfica de los usuarios/Transporte de datos
• Problemas operativos en las actividades de los usuarios

Definición del Hardware y Software de Producción:

• Frecuencia de las actividades
• Volumen de datos (estimación inicial y política de crecimiento)
• Tiempo de respuesta
• Restricciones técnicas (¿nuevo entorno?)
• Restricciones ambientales (temperatura, etc.)
• Requisitos de fiabilidad (tiempo mínimo entre fallos)
• Restricciones de seguridad (clases de usuarios y accesos)
• Interfaz de usuario