Actividad 2. Métodos de desarrollo de software.
Modelo Incremental
Modelo en Cascada
Modelo DRA
Modelo en Espiral
Definición
Características
Ventajas
Desventajas
Diferencias
Fases
Definición
Características
Ventajas
Desventajas
Diferencias
Fases
Definición
Características
Ventajas
Desventajas
Diferencias
Fases
Definición
Características
Ventajas
Desventajas
Diferencias
Fases
El modelo de proceso incremental se centra en que en cada incremento se entrega un producto funcional. Los primeros incrementos son versiones básicas del producto final, pero proporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación. El desarrollo incremental es útil en particular cuando no se dispone de personal para la implementación completa del proyecto en el plazo acordado con el cliente. Los primeros incrementos se desarrollan con pocos desarrolladores. Si el producto inicial es bien recibido, entonces se agrega más personal
El modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse de forma similar a los incrementos producidos en un flujo de proceso evolutivo.
Los usuarios participan activamente en el desarrollo.
Dado que en esta metodología se proporciona un modelo de trabajo del sistema, los usuarios obtienen una mejor comprensión del sistema que se está desarrollando.
Los errores se pueden detectar mucho antes.
Los comentarios más rápidos de los usuarios están disponibles y conducen a mejores soluciones.
La funcionalidad faltante se puede identificar fácilmente
Se pueden identificar funciones confusas o difíciles.
Validación de requisitos, implementación rápida de una aplicación incompleta pero funcional.
Necesita buena planificación y diseño.
Necesita una definición clara y completa de todo el sistema antes de que se pueda desglosar y construir de forma incremental.
El costo total es más alto que la cascada
El Modelo Incremental es particularmente útil cuando no se cuenta con una dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se añadir• personal, de ser necesario. Por otro lado, los incrementos se pueden planear para gestionar riesgos técnicos.
Requerimientos: son los objetivos centrales y específicos que persigue el proyecto.
Definición de las tareas y las iteraciones: teniendo en cuenta lo que se busca, el siguiente paso es hacer una lista de tareas y agruparlas en las iteraciones que tendrá el proyecto. Esta agrupación no puede ser aleatoria. Cada una debe perseguir objetivos específicos que la definan como tal.
Diseño de los incrementos: establecidas las iteraciones, es preciso definir cuál será la evolución del producto en cada una de ellas. Cada iteración debe superar a la que le ha precedido. Esto es lo que se denomina incremento.
Desarrollo del incremento: posteriormente se realizan las tareas previstas y se desarrollan los incrementos establecidos en la etapa anterior.
Validación de incrementos: al término de cada iteración, los responsables de la gestión del proyecto deben dar por buenos los incrementos que cada una de ellas ha arrojado. Si no son los esperados o si ha habido algún retroceso, es necesario volver la vista atrás y buscar las causas de ello.
Integración de incrementos: una vez son validados, los incrementos dan forma a lo que se denomina línea incremental o evolución del proyecto en su conjunto. Cada incremento ha contribuido al resultado final.
Entrega del producto: cuando el producto en su conjunto ha sido validado y se confirma su correspondencia con los objetivos iniciales, se procede a su entrega final.
El modelo de cascada fue el primer modelo de proceso que se introdujo. También se conoce como un modelo de ciclo de vida lineal-secuencial. En un modelo de cascada, cada fase debe completarse completamente antes de que pueda comenzar la siguiente. Este tipo de modelo de desarrollo de software se utiliza básicamente para el proyecto, que es pequeño y no hay requisitos inciertos.
En este modelo, las pruebas del software comienzan solo después de que se completa el desarrollo. En el modelo de cascada, las fases no se superponen.
Este modelo es simple y fácil de entender y usar.
Es fácil de administrar debido a la rigidez del modelo: cada fase tiene resultados específicos y un proceso de revisión.
En este modelo, las fases se procesan y se completan una a la vez. Las fases no se superponen.
El modelo de cascada funciona bien para proyectos más pequeños donde los requisitos están claramente definidos y muy bien entendidos.
Una vez que una aplicación se encuentra en la etapa de prueba, es muy difícil regresar y cambiar algo que no se pensó bien en la etapa de concepto.
No se produce ningún software que funcione hasta el final del ciclo de vida.
Grandes cantidades de riesgo e incertidumbre.
No es un buen modelo para proyectos complejos y orientados a objetos.
Modelo deficiente para proyectos largos y en curso.
No es adecuado para proyectos donde los requisitos tienen un riesgo de cambio moderado a alto.
Este modelo se usa solo cuando los requisitos son muy conocidos, claros y fijos.
La definición del producto es estable.
La tecnología se entiende.
No hay requisitos ambiguos.
Amplios recursos con la experiencia requerida están disponibles libremente
El proyecto es corto.
Requisitos del software: En esta fase se hace un análisis de las necesidades del cliente para determinar las características del software a desarrollar, y se especifica todo lo que debe hacer el sistema sin entrar en detalles técnicos. Hay que ser especialmente cuidadoso en esta primera fase, ya que en este modelo no se pueden añadir nuevos requisitos en mitad del proceso de desarrollo.
Diseño: En esta etapa se describe la estructura interna del software, y las relaciones entre las entidades que lo componen. Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseño del Software), que contiene la descripción de la estructura relacional global del sistema y la especificación de lo que debe hacer cada una de sus partes, así como la manera en que se combinan unas con otras.
Implementación: En esta fase se programan los requisitos especificados haciendo uso de las estructuras de datos diseñadas en la fase anterior. La programación es el proceso que lleva de la formulación de un problema de computación, a un programa que se ejecute produciendo los pasos necesarios para resolver dicho problema.
Verificación: Como su propio nombre indica, una vez se termina la fase de implementación se verifica que todos los componentes del sistema funcionen correctamente y cumplen con los requisitos. El objetivo de las pruebas es el de obtener información de la calidad del software, y sirven para: encontrar defectos o bugs, aumentar la calidad del software, refinar el código previamente escrito sin miedo a romperlo o introducir nuevos bugs, etc.
Instalación y mantenimiento: Una vez se han desarrollado todas las funcionalidades del software y se ha comprobado que funcionan correctamente, se inicia la fase de instalación y mantenimiento. Se instala la aplicación en el sistema y se comprueba que funcione correctamente en el entorno en que se va a utilizar
Es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. Es una adaptación de "alta velocidad" del modelo de cascada. El proceso de DRA permite que un equipo de desarrollo cree un sistema completamente funcional dentro de un periodo muy corto de 60 a 90 días.
El software no se desarrolla y utiliza en su totalidad, sino en una serie de incrementos, donde en cada incremento se incluyen nuevas funcionalidades al sistema.
A menudo se desarrollan las interfaces de usuario del sistema utilizando un sistema de desarrollo interactivo que permite que el diseño de la interfaz se cree rápidamente dibujando y colando iconos en la interfaz.
Para su desarrollo se utilizan herramientas de desarrollo visual para agilizar el proceso.
Se necesitan equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo completo, así como aquellas personas involucradas en los requisitos.
Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.
Tiempo de desarrollo reducido.
Aumenta la reutilización de los componentes.
Se realizan revisiones iniciales rápidas
Fomenta los comentarios de los clientes
La integración desde el principio resuelve muchos problemas de integración.
Depende de un equipo sólido y de desempeños individuales para identificar los requisitos del negocio.
Solo el sistema que se puede modularizar se puede construir con RAD
Requiere desarrolladores / diseñadores altamente calificados.
Alta dependencia de las habilidades de modelado.
Inaplicable a proyectos más baratos, ya que el costo de modelado y generación automática de código es muy alto.
RAD debería usarse cuando sea necesario crear un sistema que pueda modularizarse en 2-3 meses.
Debe usarse si hay una alta disponibilidad de diseñadores para modelar y el presupuesto es lo suficientemente alto como para pagar su costo junto con el costo de las herramientas automatizadas de generación de código.
El modelo RAD SDLC debe elegirse solo si se dispone de recursos con alto conocimiento comercial y existe la necesidad de producir el sistema en un corto período de tiempo (2-3 meses).
Modelado comercial: el flujo de información se identifica entre varias funciones comerciales.
Modelado de datos: la información recopilada del modelado de negocios se utiliza para definir los objetos de datos que se necesitan para el negocio.
Modelado de procesos: los objetos de datos definidos en el modelado de datos se convierten para lograr el flujo de información comercial para lograr algún objetivo comercial específico. La descripción se identifica y se crea para CRUD de objetos de datos.
Generación de aplicaciones: las herramientas automatizadas se utilizan para convertir los modelos de proceso en código y en el sistema real.
Pruebas y rotación: pruebe nuevos componentes y todas las interfaces.
Es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial.
En el modelo espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, lo que se produce puede ser un modelo o prototipo. En las iteraciones posteriores se crean versiones cada vez más completas del sistema. El modelo en espiral se divide en un conjunto de actividades estructurales.
Gran cantidad de análisis de riesgos, por lo tanto, se mejora la evitación de riesgos.
Bueno para proyectos grandes y de misión crítica.
Fuerte aprobación y control de documentación.
Se puede agregar funcionalidad adicional en una fecha posterior.
El software se produce temprano en el ciclo de vida del software.
Puede ser un modelo costoso de usar.
El análisis de riesgos requiere experiencia altamente específica.
El éxito del proyecto depende en gran medida de la fase de análisis de riesgos.
No funciona bien para proyectos más pequeños
Cuando los costos y la evaluación de riesgos son importantes
Para proyectos de riesgo medio a alto
Compromiso del proyecto a largo plazo imprudente debido a posibles cambios en las prioridades económicas
Los usuarios no están seguros de sus necesidades.
Los requisitos son complejos.
Nueva línea de productos
Se esperan cambios significativos (investigación y exploración)
Planificación. Se determinan los objetivos y el alcance del ciclo que comienza, tras un necesario ejercicio de investigación. Con cada iteración, se irá incrementando el tamaño de software entregado y la funcionalidad cubierta.
Análisis de Riesgo. Se evalúa todo aquello que pueda afectar al proyecto según el estado en que se encuentre y su grado de avance. Para ello, se diseñarán los prototipos que deberán ser validados en el ciclo.
Implementación. Se desarrolla y valida el software según el alcance acordado, el cual está íntimamente relacionado y condicionado con el análisis de riesgos anterior.
Evaluación. Antes de proceder a realizar otra vuelta en la espiral, se debe prestar atención a lo que sucedió en la vuelta anterior. Se debe analizar en detalle si los riesgos detectados anteriormente ya tuvieron solución. Básicamente, esta fase servirá para determinar el avance del proyecto y dar pistas de hacia dónde debe enfocarse la próxima iteración.