Herramientas de usuario
ingenieria_de_requisitos:procesos
Diferencias
Muestra las diferencias entre dos versiones de la página.
| Próxima revisión | Revisión previa | ||
| ingenieria_de_requisitos:procesos [2023/10/02 09:33] – creado 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 == | ||
| + | * No tiene orden | ||
| + | * Proceso iterativo | ||
| + | * Secuencia habitual: | ||
| + | * Se obtienen los requisitos | ||
| + | * Se negocia con los participantes | ||
| + | * Se integran con el resto de la documentación | ||
| + | * Se verifican y validan | ||
| + | === 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. | ||
ingenieria_de_requisitos/procesos.1696239199.txt.gz · Última modificación: 2023/10/02 09:33 por thejuanvisu
Herramientas de la página
