Muestra las diferencias entre dos versiones de la página.
| Ambos lados, revisión anteriorRevisión previa | |||
| ingenieria_de_requisitos:procesos [2023/10/02 09:52] – thejuanvisu | ingenieria_de_requisitos:procesos [2023/10/02 10:12] (actual) – thejuanvisu | ||
|---|---|---|---|
| Línea 86: | Línea 86: | ||
| * Demasiado tiempo para alcanzar un acuerdo cuando se proponen cambios | * 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. | ||