Modelo Evolutivo
MODELO EVOLUTIVO
MODELO ESPIRAL
El Modelo en Espiral está orientado a riesgos, que divide un proyecto de software en mini proyectos. Cada mini proyecto se centra en uno o más riesgos importantes hasta que todos estos están controlados. En cada ciclo o espiral las especificaciones del producto se van resolviendo.
1.1. Etapas
Planificación
Es la determinación de objetivos, límites y condiciones de contorno (alcance del sistema), condiciones que limitan de alguna manera el desarrollo, economía, tiempo, etc. del sistema.
Análisis de Riesgos
El análisis de riesgo es el desarrollo de un plan para descubrir los riesgos más importantes y resolver los mismos (mitigar riesgos).
Ingeniería
La ingeniería es el desarrollo del producto o prototipo según las condiciones de la etapa anterior.
Evaluación
La evaluación es la etapa en la cual se evalúa los resultados del prototipo obtenido se verifica y se valida.
1.2. Roles
Los roles de la metodología en espiral son;
Investigador: como esta metodología requiere de un análisis de documentación e investigación..
Jefe de Proyecto: será el líder del proyecto.
Desarrollador: en el caso de un desarrollo de software, será quien escriba el código y documente la programación.
Encargado de evaluar: cómo este modelo es muy utilizado en la creación de Software, este rol lo llevaría adelante el Tester.
2 . Modelo de desarrollo basado en componentes
2.1.Historia
Surgió a finales de los 90's, la idea de que el software deba estar componentizado - construido de componentes prefabricados - por primera vez llegó a ser prominente con el discurso de Douglas McIlroy en la conferencia de la OTAN sobre la ingeniería de software en Garmisch, Alemania, 1968, titulado Mass Produced Software Components (componentes de software producidos en masa).
2.2. Actividades
Sin importar la tecnología usada para crear los componentes, el modelo de desarrollo basado en componentes incorpora las actividades siguientes:
Se investigan y evalúan, para el tipo de aplicación de que se trate, productos disponibles basados en componentes.
Se consideran los aspectos de integración de los componentes.
Se diseña una arquitectura del software para que reciba los componentes.
Se integran los componentes en la aquitectura.
Se efectúan pruebas exhaustivas para asegurar la funcionalidad apropiada.
2.3. Etapas
Fase de Análisis del Contexto permite que el grupo de desarrollo adquiera un conocimiento adecuado del dominio o contexto del sistema en desarrollo.
Fases de Descubrimiento, Análisis y Especificación de Requerimientos se encargan de identificar las necesidades y requerimientos de los usuarios, así como analizarlos, especificarlos gráficamente y documentarlos.
Fase de diseño del sistema establece y describe la arquitectura del software. Describe cada uno de los componentes que requiere tal estructura y cómo esos componentes se interconectan para interactuar.
Fase de implementación, el grupo de desarrollo debe, a partir de esta arquitectura, determinar cuáles componentes se pueden reutilizar Fase de Entrega se encarga de la instalación, adiestramiento de usuarios y puesta en operación del sistema.
2.4. Roles
Rol del Usuario El papel del usuario con el prototipo puede resumirse en compromiso y honestidad. Si carece de compromiso pocos son los motivos para desarrollar un prototipo.
Utilizar y evaluar el prototipo las veces que sea necesario
Identificar mejoras
Sugerir las característica no deseadas
Describir los requerimientos de datos
Describir la salida deseada
Rol del Profesional de Sistema El papel del profesional de sistema no solo debe construir el prototipo sino también que debe:
Crear el clima adecuado al usuario para que este se exprese sin temor alguno
Familiarizar al usuario con el prototipo
Crear el plan para el desarrollo del prototipo
Construir la versión inicial
Evaluar las reacciones del usuario y plasmar las modificaciones en una nueva versión.
3.Modelo Incremental
3.1. Historia
Propuesto por Mills en 1980. Sugirió el enfoque incremental de desarrollo como una forma de reducir la repetición del trabajo en el proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta adquirir experiencia con el sistema .
3.3. Actividades
El modelo incremental combina los elementos de los flujos de proceso lineal y paralelo.
El modelo de proceso incremental se centra en que en cada incremento se entrega un producto que ya opera. Los primeros incrementos son versiones desnudas del producto final, pero proporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación.
3.3. Etapas
Requerimientos
Esta fase se refiere a todos los objetivos del proyecto, tanto el general o central como los específicos.
Se precisan las tareas e iteraciones
Ya teniendo claros los objetivos que el proyecto nos ayudará a alcanzar, la siguiente fase es definir las tareas y las iteraciones con que las que los concretamos. Si observamos, esta fase incrementa el alcance del objetivo central en comparación con la anterior.
Diseño de los incrementos
Se define cuál será la evolución del proyecto en las iteraciones. Cada una de ellas debe superar a la que le precede para que se pueda dar el incremento.
Desarrollo del incremento
Las tareas definidas son llevadas a cabo y así los incrementos previstos son desarrollados.
Validación de los incrementos
Los responsables de la gestión de proyecto han de verificar que cada iteración culminada de los resultados esperados. Si no es así, hay que hacer una revisión de las tareas y buscar las causas de los errores.
Integración de los incrementos
Como lo indica el nombre de esta fase, se trata de integrar todos los incrementos aprobados o validados por la gestión de proyectos. Así se da la evolución global del proyecto, lo que también se conoce como línea incremental.
Entrega del producto
Una vez hecha la integración y se constante que el producto cumple con los objetivos planteados, se realiza la entrega. Este es el último paso del modelo incremental fases.
3.4. Roles
Dueño del producto: Su misión es pedir lo que necesita (no el cómo, sino el qué) y aceptar o pedir correcciones sobre lo que se le entrega.
Cliente: Es el dueño del producto y el usuario final.
Analista de negocio: También es el dueño del producto porque trabaja codo a codo con el cliente y traduce los requisitos en tests de aceptación para que los desarrolladores los entiendan, es decir, les explica qué hay que hacer y resuelve sus dudas.
Desarrolladores: Toman la información del analista de negocio y deciden cómo lo van a resolver además de implementar la solución. Aparte de escribir código, los desarrolladores deben tener conocimientos avanzados sobre usabilidad y diseño de interfaces de usuario, aunque es conveniente contar con una persona experimentada para asistir en casos particulares. Lo mismo para la accesibilidad.