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. |