Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
| ingenieria_de_requisitos:resumenparcial2 [2024/01/10 22:03] – thejuanvisu | ingenieria_de_requisitos:resumenparcial2 [2024/01/10 22:34] (actual) – thejuanvisu | ||
|---|---|---|---|
| Línea 104: | Línea 104: | ||
| ===== Diferencia metodologías Ágiles y Tradicionales ===== | ===== Diferencia metodologías Ágiles y Tradicionales ===== | ||
| + | * Captura de requisitos | ||
| + | * Implicación de los usuarios | ||
| + | * Las metodologías Ágiles suponen que tendrán al cliente ideal | ||
| + | * Las metodologías tradicionales evitan esta suposición con técnicas para confrontar y validar | ||
| + | * Entrevistas | ||
| + | * Es la principal técnica de las metodologías Ágiles | ||
| + | * Priorización: | ||
| + | * Es una práctica donde se implementan primero los requisitos más valiosos para el cliente | ||
| + | * Especificación de requisitos | ||
| + | * Las reuniones de análisis son frecuentes durante todo el proceso pero la documentación es menos rígida | ||
| + | * Las técnicas de modelado solo se usan para facilitar comprensión en Ágil | ||
| + | * No se pretende generar una documentación completa | ||
| + | * Se deja mucha libertad al equipo de desarrollo | ||
| + | * Las historias de usuario son las técnicas más utilizadas en Ágil | ||
| + | * Validación de requisitos | ||
| + | * Se usan las reuniones de revisión | ||
| + | * Gestión de Requisitos | ||
| + | * No es posible la trazabilidad total de los requisitos como en las metodologías tradicionales | ||
| + | * Proporcionan buena base con el backlog y un listado de características | ||
| + | * Aproximación poco detallada a la captura de requisitos, se omiten detalles para completarlos más tarde. | ||
| + | * Las fases de las metodologías tradicionales no son fácilmente separables en las metodologías ágiles | ||
| + | * Las técnicas utilizadas en las metodologías tradicionales se encuentran vagamente descritas ya que se confía mucho en el equipo de desarrollo | ||
| + | * La documentación es poco extensa y compacta, lo que la hace sencilla de mantener. | ||
| ===== Notaciones en Z ===== | ===== Notaciones en Z ===== | ||
| + | * Las especificaciones se presenta como un texto informal complementado con descripciones formales, estas últimas contienen pequeños trozos fáciles de leer. | ||
| + | * Los esquemas introducen variables de estado y define restricciones y operaciones en el estado | ||
| + | * Ejemplo: | ||
| + | * La signatura define las entidades que constituyen el estado del sistema | ||
| + | * El predicado establece las condiciones que siempre deben cumplirse para esas entidades | ||
| + | <WRAP group left> | ||
| + | {{drawio> | ||
| + | </ | ||
| - | + | <WRAP group left> | |
| + | * Los esquemas pueden ser manipulados utilizando operaciones como la composición de esquemas, renombrado de esquemas o la ocultación de esquemas | ||
| + | * La signatura del esquema define las entidades que forma el estado del sistema y el predicado del esquema establece las condiciones en que deberían cumplirse estas condiciones | ||
| + | * Cuando un esquema define una operación, el predicado puede establecer precondiciones y postcondiciones | ||
| + | * Estas definen el estado antes y después de la operación, la diferencia entre ambas define la acción especificada en el esquema de la operación. | ||
| + | </ | ||
| + | <WRAP group left> | ||
| + | {{drawio> | ||
| + | </ | ||
| ===== Notaciones algebraicas ===== | ===== Notaciones algebraicas ===== | ||
| + | * Introducción: | ||
| + | * Descripción: | ||
| + | * Signatura: Define la sintaxis de las operaciones, | ||
| + | * Axiomas: Define la semántica de las operaciones mediante la definición de axiomas que caracterizan su comportamiento | ||
| + | <WRAP group left> | ||
| + | {{: | ||
| + | </ | ||