29 Mar
Modelo de ciclo de vida en cascada
Requisitos>Diseño>Construcción>Pruebas>Mantenimiento.
Cascada se caracteriza por su secuencialidad en las fases. El sistema se entrega completo al final del proyecto.
El estado del proyecto es visible en todo momento.
Asume requisitos estables en todo momento.
Los límites entre fases son muy rígidos y se propagan errores.
Es el modelo más antiguo. En este modelo el concepto de fase se mantiene. En los modelos antiguos las actividades no se limitaban a una fase, sino que tenían lugar en varias de ellas avanzando mediante iteraciones.
Ciclo de vida iterativo
Es un proceso de desarrollo de software creado en respuesta a las debilidades del modelo tradicional de cascada.
Este modelo de desarrollo es un conjunto de tareas agrupadas en pequeñas etapas repetitivas(iteraciones). Es uno de los más utilizados ya que se relaciona con estrategias de desarrollo del software y una programación extrema, es empleado en metodologías diversas.
El análisis de cada iteración permite identificar puntos de mejora en cada ciclo. Esas mejoras se pueden incorporar en las iteraciones posteriores.
La gestión de riesgos es más precisa. Al iniciar la planificación se dispone de una visión de los riesgos a los que te enfrentas en cada iteración.
Los procesos cíclicos aportan un margen de flexibilidad extra.
- Ventajas del desarrollo iterativo
- En cada iteración se puede comprobar los avances y el beneficio que reporta.
- El riesgo que se asume es pequeño. Si hay algún impedimento se puede solventar en la siguiente iteración.
- El gap entre lo planeado y lo ejecutado se minimiza con las sucesiones de las pequeñas iteraciones.
- La complejidad del proyecto se diluye en pequeñas partes menos complejas.
- El conocimiento sobre el producto es creciente y progresivo sin tener una visión detallada de cada parte al principio del desarrollo
Debilidades del desarrollo iterativo
- Implica tener un cliente involucrado durante el desarrollo
- La relación con el cliente debe basarse en principios éticos y una colaboración mutua.
- Infunde responsabilidad en el equipo de desarrollo.
- En el desarrollo del producto puede que los requerimientos previamente definidos y cerrados cambien notablemente.
Ciclo de vida en espiral
Es una combinación del ciclo de vida en cascada y el modelo iterativo.
Las fases por las que pasa cada ciclo de la espiral son:
- Planificación: Se determinan los objetivos y el alcance del ciclo. Con cada iteración se ira incrementado el tamaño del software y su funcionalidad.
- Análisis de riesgo: Se evalúa todo aquello que pueda afectar al proyecto. Para ello, se diseñan los prototipos que deberán ser validados en el ciclo.
- Implementación: Se desarrolla y valida el software, el cual está relacionado y condicionado con el análisis de riesgos anterior.
- Evaluación: Antes de pasar a la siguiente iteración se debe analizar si los riesgos detectados anteriormente ya se solucionaron. Esta fase sirve para determinar el avance del proyecto.
Ventajas:
- Los factores de riesgos son reducidos
- El desarrollo es iterativo y se pueden incorporar funcionalidades progresivamente
Inconvenientes:
- La duración de la ejecución no es concreta
- Fallos en el análisis de riesgos podría influir negativamente a todo el proyecto.
Factores que influyen en los requisitos
-complejidad del problema a resolver
-Factores relacionados con el cliente
-Dificultades de comunicación
-Existencia de requisitos ocultos
Tipos de requisitos
Funcionales: funciones, servicios o tareas a llevar a cabo. Son más fácilmente verificables, en general.
No funcionales: aspectos técnicos que debe incluir el sistema desarrollado.
- Restricciones: limitaciones a que se enfrentan los desarrolladores del sistema. Ej: el sistema operativo del entorno del usuario.
- Calidades: carácterísticas que importan a los clientes y usuarios, relevantes para su satisfacción con el sistema final (rendimiento, fiabilidad o disponibilidad del sistema).
- En general, son más difíciles de validar.
Clasificación de requisitos no funcionales
- Requisitos del producto: detallan limitaciones o comportamientos exigidos al producto resultante del desarrollo. Ej: Cantidad de memoria requerida, velocidad de respuesta en operaciones interactivas.
- Requisitos de la organización: relacionados con las normativas de funcionamiento de la organización que lleva a cabo el desarrollo, sus procedimientos y políticas. Ej: Estándares de desarrollo, documentación a entregar junto con el producto, plazos de entrega.
- Requisitos externos: cubren aspectos externos al sistema y a su proceso de desarrollo. Ej: Interoperabilidad con otros sistemas, requisitos legales.
Obtención
Objetivo: establecer las fronteras del futuro Sistema
Acciones a llevar a cabo:
- Determinar las fuentes de información de las que se obtendrán los requisitos
- Establecer las técnicas de obtención de requisitos a utilizar. Ej: Entrevista y cuestionarios, prototipos, escenarios, sistemas existentes, tormentas de ideas, etc.
Análisis
Objetivo: descubrir las tareas que deben llevarse a cabo para examinar los requisitos para delimitarlos y definir exactamente cada uno.
Acciones a llevar a cabo:
- Detectar y resolver conflictos entre requisitos
- Delimitar el software y establecer con que elementos externos interacciona
- Elaborar los requisitos del sistema para obtener, a partir de ellos, los requisitos del software a desarrollar.
Enlaza la definición de alto nivel del sistema desde la perspectiva del usuario – externa -, con el diseño del software que permitirá implementar dicho sistema – interna -.
Visión simplista: el proceso consiste exclusivamente en realizar un modelo conceptual de los requisitos.
Sin embargo, el modelado es importante, pero no es la única tarea:
- Clasificación de los requisitos
- Diseño de la arquitectura del sistema y situación de requisitos en la misma
- Toma de decisiones de compromiso en los casos de conflictos entre varios requisitos (negociación).
Especificación
Objetivo: describir completamente los requisitos del sistema a desarrollar.
Implica con frecuencia la construcción de un modelo (o varios) del sistema a construir desde el punto de vista de los usuarios del sistema, que incluya los requisitos obtenidos.
De manera generalizada, los requisitos se plasman en un documento denominado especificación de requisitos del software (SRS)
- Importancia: documento contractual
En proyectos complejos, 3 documentos:
- Documento de definición del sistema
- Documento de requisitos del sistema
- Especificación de requisitos del software (SRS)
Modelado de los requisitos
Parte de la especificación
En un modelado conceptual cada entidad se corresponde de manera univoca con un objeto en el mundo real. A menudo se plasman en modelos visuales.
Para crear estos modelos es necesario un lenguaje y un conjunto de reglas que establezcan como se han de usar los elementos del lenguaje. Ej casos de uso, diagramas de clases de análisis UML, diagramas Entidad-Relación, notaciones formales.
Validación
Objetivo: examinar si los documentos de requisitos definen el software que los usuarios esperan y no otro.
Un grupo de revisores con representación de los actores más significativos cumplimenta una tabla con sus análisis.
- Objetivo: buscar errores y contradicciones en los requisitos, descripciones poco claras y desviaciones de las practicas estándar.
Gestión del proceso de requisitos
Seguimiento + Métricas + Herramientas de gestión
Seguimiento: más improbable que el sistema final tenga inconsistencia por culpa de cambios realizados sin un control exhaustivo.
Los requisitos evolucionan iterativamente hasta alcanzar un nivel de calidad y detalle suficiente que permita iniciar los trabajos de diseño de las funcionalidades que les dan soporte.
Para facilitar la compresión completa de todos los aspectos asociados con los requisitos han de definirse líneas base. Una línea base es un conjunto de requisitos que deberá contener una entrega del producto.
Seguimiento de los requisitos
Matriz de seguimiento: tabla donde se relacionan dos documentos, los cuales pertenecen probablemente a etapas distintas del desarrollo.
- Su utilización más frecuente es seguir la pista de los requisitos a lo largo de todo el desarrollo.
- Fundamentalmente en diseño, plan de pruebas y casos de pruebas.
- Hace corresponder los requisitos con los componentes software que los implementaran, y especialmente con los casos de prueba.
Métricas de requisitos
Es posible tomar medidas de los requisitos software que indiquen el alcance del proyecto, su crecimiento potencial, su estabilidad y progreso.
Las medidas de requisitos son únicas: caracterizan el espacio del problema. Otras medidas del desarrollo caracterizan el espacio de la solución.
Herramientas de requisitos
El tamaño y complejidad de los desarrollos ha convertido el uso de herramientas en algo esencial.
Las herramientas de gestión de requisitos:
- Facilitan un modo de seguimiento de los cambios que se producen durante el ciclo de vida del proyecto
- Permiten automatizar algunas de las tareas relacionadas con los cambios y el seguimiento de requisitos. Ej: identificación, medición.
- Mejoran la productividad y la calidad en el desarrollo.
Deja un comentario