Title: Análisis Body: Entrada Conocimiento del dominio de la aplicación, actividades de los usuarios, mercado, etc. Actividades Identificar las necesidades del usuario Análisis de viabilidad Determinar los requisitos de la aplicación Salida Documento de requisitos del software 
Title: Diseño Body: Entrada Documento de requisitos del software Actividades Establecer una(s) estrategia(s) de solución Análisis de alternativas. Formalizar la solución Descomponer y organizar la aplicación Fijar descripciones de cada módulo Salida Documento de diseño del software
Title: Diseño de Software Body: Un diseño de software es un modelo de un sistema del mundo real que tiene muchas entidades participantes y relaciones entre ellas. Debe ser posible visualizarlo a diferentes niveles de abstracción. Traduce los requisitos del software a un conjunto de representaciones (gráficas, tabulares, basadas en lenguajes) que describen la estructura de datos, la arquitectura, el procedimiento algorítmico y las características de la interfaz.
Title: El diseño del SW Body: El diseño debe actuar como base para la implementación. Es un medio de comunicación entre los diseñadores de subsistemas Provee información para el mantenimiento, a cerca de la intención original.
Title: El proceso de diseño involucra: Body: Describir el sistema como un número de diferentes niveles de abstracción. El diseño es descompuesto y se va refinando, errores y omisiones en etapas tempranas son descubiertos. Las etapas que se muestran a continuación son arbitrarias pero muestran el proceso y permiten la administración del proceso:
Title: Capas del diseño Body: El diseño se enfoca sobre cuatro atributos distintos del programa: La estructura de los datos La arquitectura del software El detalle procedimental y La caracterización de la interfaz.
Title: Principios del diseño Body: El proceso de diseño no debe sugerir de "visión de túnel" El diseño debe ser rastreable hacia el modelo de análisis El diseño no debe "reinventar la rueda" El diseño debe "minimizar la distancia intelectual" entre el software y el problema como en el mundo real. El diseño debe exhibir uniformidad e integración. El diseño debe estructurarse para soportar el cambio. El diseño debe ser estructurado para acoplarse, aún cuando datos aberrantes, eventos o condiciones de operación se presenten. El diseño no es codificación, codificar no es diseñar. El diseño debe establecerse para calidad como será creado, no después de contruir el software. El diseño debe ser revisado para minimizar errores conceptuales (semántica).
Title: Diseño orientado a objetos Body: Descomposición y organización en partes Partes = clases o abstracciones Organización: estructura del conjunto Relaciones entre clases Agregación: objetos que contienen otros objetos Uso: clases que utilizan otras clases Herencia: clases especializadas Otras relaciones: modelo de datos. Ejemplo: paciente padece enfermedad
Title: Diagramas de clases Clase Atributos Métodos Herencia Uso Agregación
Title: Descomposición modular Body: Módulo: agrupación de elementos Clases, tipos, constantes, objetos, etc. Acoplamiento Ligaduras o interferencias entre módulos Deseable bajo acoplamiento (independencia) Ejemplo: No usar variables globales por su nombre Cohesión Relación entre los elementos de un módulo Deseable alta cohesión Ejemplo: Módulos que sean clases o TADs
| Página siguiente |