El documento describe tres modelos de desarrollo de software: el desarrollo en cascada, el desarrollo en espiral y el modelo de prototipos. El desarrollo en cascada sigue un enfoque lineal y estricto con fases secuenciales como análisis, diseño, codificación y pruebas. El desarrollo en espiral es un modelo iterativo que evalúa riesgos en cada bucle. El modelo de prototipos construye versiones tempranas del software para obtener retroalimentación del cliente y refinar requisitos.

1. ING. DE SOFTWARE Desarrollo en cascada

3. Desarrollo en cascada De esta forma, cualquier error de diseño detectado en la etapa de prueba conduce necesariamente al rediseño y nueva programación del código afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metáfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases más avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el ámbito académico y la industria, sigue siendo el paradigma más seguido al día de hoy.

11. ING. DE SOFTWARE Desarrollo en espiral

12. Desarrollo en espiral El Desarrollo en Espiral es un modelo de ciclo de vida desarrollado por Barry Boehm en 1985, utilizado generalmente en la Ingeniería de software . Las actividades de este modelo son una espiral, cada bucle es una actividad. Las actividades no están fijadas a prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando por el bucle interior.

18. Modelo de prototipos Modelo de prototipos

19. Modelo de prototipos En Ingeniería de software el desarrollo con prototipación , también llamado modelo de prototipos o modelo de desarrollo evolutivo , se inicia con la definición de los objetivos globales para el software, luego se identifican los requisitos conocidos y las áreas del esquema en donde es necesaria más definición. Entonces se plantea con rapidez una iteración de construcción de prototipos y se presenta el modelado (en forma de un diseño rápido). El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo.

22. Método en V Método en V

23. Método en V El Método-V define un procedimiento uniforme para el desarrollo de productos para las TIC . Es el estándar utilizado para los proyectos de la Administración Federal Alemán y de defensa. Como está disponible públicamente muchas compañías lo usan. Es un método de gestión de proyectos comparable a PRINCE2 y describe tanto métodos para la gestión como para el desarrollo de sistemas. La versión actual del Método-V es el Método-V XT ( http://www.v-modell-xt.de ) que se terminó en Febrero del 2005 . No es comparable con CMMI . Mientras que CMMI solo describe "qué" se ha hecho, el Método-V describe el "cómo" y el "cuándo" y "quién" es el responsable de haberlo hecho.

24. Método en V El Método-V fue desarrollado para regular el proceso de desarrollo de software por la Administración Federal Alemana. Describe las actividades y los resultados que se producen durante el desarrollo del software. El Método-V es una representación gráfica del ciclo de vida del desarrollo del sistema. Resume los pasos principales que hay que tomar en conjunción con las correspondientes entregas de los sistemas de validación. La parte izquierda de la V representa la corriente donde se definen las especificaciones del sistema. La parte derecha de la V representa la corriente donde se comprueba el sistema (contra las especificaciones definidas en la parte izquierda). La parte de abajo, donde se encuentran ambas partes, representa la corriente de desarrollo.

25. Método en V La corriente de especificación consiste principalmente de: Especificaciones de requerimiento de usuario Especificaciones funcionales Especificaciones de diseño La corriente de pruebas, por su parte, suele consistir de: Calificación de instalación Calificación operacional Calificación de rendimiento La corriente de desarrollo puede consistir (depende del tipo de sistema y del alcance del desarrollo) en personalización, configuración o codificación.