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:procesos [2023/10/02 09:37] – thejuanvisu | ingenieria_de_requisitos:procesos [2023/10/02 10:12] (actual) – thejuanvisu | ||
---|---|---|---|
Línea 25: | Línea 25: | ||
==== Modelos del proceso ==== | ==== Modelos del proceso ==== | ||
=== Modelo de Loucopoulos y Karakostas === | === Modelo de Loucopoulos y Karakostas === | ||
- | {{ : | + | {{: |
== Aspectos fundamentales == | == Aspectos fundamentales == | ||
* Entendimiento del problema: Captura, definición, | * Entendimiento del problema: Captura, definición, | ||
Línea 33: | Línea 33: | ||
=== Modelo de Pohl === | === Modelo de Pohl === | ||
La ventaja de este modelo es que no tiene orden. | La ventaja de este modelo es que no tiene orden. | ||
- | {{ : | + | {{: |
== Características == | == Características == | ||
* No tiene orden | * No tiene orden | ||
Línea 43: | Línea 43: | ||
* Se verifican y validan | * Se verifican y validan | ||
- | ==== Modelo de Kotonya y Sommerville | + | === Modelo de Kotonya y Sommerville === |
- | {{ : | + | {{: |
+ | === Modelo de espiral de Kotonya y Sommerville === | ||
+ | {{: | ||
+ | == Características == | ||
+ | |||
+ | * Es un Modelo Iterativo: | ||
+ | * Educción | ||
+ | * Análisis | ||
+ | * Especificación | ||
+ | * Validación | ||
+ | * El problema es que no sabemos cuando termina | ||
+ | * Actividad de gestión | ||
+ | * Durante todo el proceso | ||
+ | * Gestiona la obtención incremental de requisitos y cambios | ||
+ | |||
+ | ===== Características generales de los requisitos ===== | ||
+ | * Son procesos iterativos | ||
+ | * El modelo en espirar obliga a un orden, los otros menos | ||
+ | * Los productos de profeso y fase no están claramente definidos | ||
+ | |||
+ | ===== Modelo SWEBOK ===== | ||
+ | Modelo perteneciente a la IEEE. Nos centramos en la parte de Requerimientos. Tiene 4 Fases: | ||
+ | * Educción | ||
+ | * Análisis | ||
+ | * Especificación | ||
+ | * Validación | ||
+ | |||
+ | ===== Actividades ===== | ||
+ | Estudio de viabilidad: No es obligatorio en requisitos, pero si aconsejable. | ||
+ | |||
+ | ===== Problemas en el proceso ===== | ||
+ | Tendremos problemas si se dan estos casos: | ||
+ | * Falta tiempo y otros requisitos | ||
+ | * Si los documentos no se entienden | ||
+ | * El proceso es excesivamente largo y costoso | ||
+ | * Trabajo perdido por culpa de errores | ||
+ | * No utiliza muchas de las capacidades del sistema | ||
+ | * Inmensa cantidad de solicitudes de cambio tras la entrega | ||
+ | * Demasiado tiempo para alcanzar un acuerdo cuando se proponen cambios | ||
+ | |||
+ | ===== Proceso de desarrollo ===== | ||
+ | * Estudio de viabilidad (Opcional) | ||
+ | * Captura y análisis | ||
+ | * Especificación de requisitos | ||
+ | * Validación | ||
+ | |||
+ | ===== Factor Humano (StakeHolders) ===== | ||
+ | Los Stakeholder son los usuarios e interesados en la plataforma, gente importante, dueños del proceso que queremos hacer, personas que entrevistaremos para hacer el software: | ||
+ | * Usuarios: Los que utilizaran el sistema | ||
+ | * Clientes: Propietarios del software o representantes del mercado objetivo | ||
+ | * Analistas de mercado: Identifican lo que el mercado demanda | ||
+ | * Reguladores: | ||
+ | * Ingenieros del Software | ||
+ | |||
+ | Cada StakeHolder tiene su punto de vista. Se debe negociar el equilibrio requisitos-presupuesto planificación. El cliente confía en que el ingeniero de requisitos pueda aclarar sus necesidades | ||
+ | |||
+ | Productos del proceso de la Ingeniería de Requisitos | ||
+ | Informe de viabilidad | ||
+ | Requisitos acordados | ||
+ | Especificación del sistema | ||
+ | |||
+ | ===== Fases del proceso ===== | ||
+ | |||
+ | * **A0: Estudio de viabilidad** | ||
+ | * Al comienzo del proceso de desarrollo | ||
+ | * Es opcional | ||
+ | * Es un proceso para conocer los objetivos de la organización | ||
+ | * Evaluar si se dispone de la tecnología necesaria | ||
+ | * Analizar si se puede integrar con otros sistemas | ||
+ | * __Entrada__ | ||
+ | * Conjunto de requisitos de negocio preliminares | ||
+ | * Descrpción resupida del sistema | ||
+ | * Contribución del sistema al proceso de negocio | ||
+ | * __Salida:__ Informe de viabilidad, que ayuda a decidir si continuar o no | ||
+ | * El proceso debe durar máximo 2 o 3 semanas | ||
+ | * **A1: Captura de requisitos (Educción)** | ||
+ | * Es la primera actividad a realizar | ||
+ | * Para llevar a cabo se debe saber de donde vienen los requisitos y como recopilarlos | ||
+ | * Buscamos detectar y resolver ciertos conflictos | ||
+ | * También buscamos descubrir los límites del software y como este debe interactuar con su entorno. | ||
+ | * Diversas tareas: | ||
+ | * Clasificación | ||
+ | * Modelado Conceptual | ||
+ | * Localización | ||
+ | * Negociación | ||
+ | * **A2: Especificación de requisitos** | ||
+ | * Se refiere a la producción de un ducomuento basado en la IEEE-830 | ||
+ | * **A3: Validación de requisitos** | ||
+ | * Se validan para comprobar que el ingeniero de requisitos los ha entendido | ||
+ | * Se trata de asegurar que el documento ERS define el software adecuado | ||
+ | * Tecnicas de validación | ||
+ | * Revisiones | ||
+ | * Prototipado | ||
+ | * Validación de Modelos | ||
+ | * Pruebas de aceptación | ||
+ | |||
+ | ===== Gestión de requisitos ===== | ||
+ | Los requisitos cambian: | ||
+ | * Cambio en la estrategia o prioridades de negocio | ||
+ | * Cambios tecnológicos | ||
+ | * Cambios en leyes o regulaciones | ||
+ | |||
+ | La Gestión de requisitos consiste en gestionar | ||
+ | * Los cambios en los requisitos acordados | ||
+ | * Las relaciones entre requisitos | ||
+ | * Las dependencias entre el documento ERS y otros documentos. | ||
+ | |||
+ | ===== Puntos Clave ===== | ||
+ | * Es un proceso Iterativo | ||
+ | * Suele tener un estudio de viabilidad | ||
+ | * Hay diferentes stakeholder con diferentes requisitos | ||
+ | * Los cambios en los negocios, que van a pasar, producen cambios en nuestros requisitos. |