1. Fase de definición de requisitos o fase de análisis
1.1. Actividades
1.1.1. Se recopilan, se formulan y se examinan los requisitos del cliente y del sistema. También se verifican las posibles restricciones.
1.1.1.1. 1. Definición del alcance del proyecto.
1.1.1.2. 2. Identificación del negocio
1.1.1.3. 3. Toma requerimientos
1.1.1.4. 4. Estudio de procesos de negocio.
1.1.1.5. 5. Calendarización del proyecto.
1.1.2. El problema que puede surgir es que el cliente no tenga claro cuales son sus necesidades
1.2. Artefactos
1.2.1. Modelo del negocio
1.2.2. Análisis y realización de casos de uso
1.2.3. Modelo de procesos y actividades de negocio
1.2.4. Cronograma del proyecto
2. Ingeniería de Requisitos (IR)
2.1. Estructura
2.1.1. Ingeniería
2.1.1.1. Se enfoca en las actividades de:
2.1.1.1.1. Obtención
2.1.1.1.2. Análisis
2.1.1.1.3. Especificación
2.1.1.1.4. Validación de los requisitos que permitirá alcanzar los objetivos del negocio.
2.1.2. Requisitos
2.1.2.1. Se enfoca en la administración de los mismos
2.1.2.1.1. Su propósito central es la gestión de los cambios y la trazabilidad.
2.2. Algunas definiciones:
2.2.1. Disciplina para desarrollar una especificación completa, consistente y no ambigua (Boehm, 1979).
2.2.1.1. Esta servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema
2.2.2. Se considera como un proceso de descubrimiento y comunicación de las necesidades de clientes y usuarios y la gestión de los cambios de dichas necesidades (Amador, 2000)
2.2.3. Es el proceso para estudiar las necesidades del usuario para llegar a una definición de requisitos de sistema, hardware o software (IEEE, 1990).
2.2.3.1. A medida que avanza el proyecto el cliente se ve involucrado en su desarrollo sugiriendo mejoras, proponiendo ideas y estando pendiente del mismo.
2.3. Forma el mecanismo apropiado para:
2.3.1. Entender lo que el cliente quiere
2.3.2. Analizar las necesidades
2.3.3. Evaluar la factibilidad
2.3.4. Negociar una solución razonable
2.3.5. Especificar la solución sin ambigüedades
2.3.6. Validar la especificación
2.3.7. Administrar los requisitos conforme éstos se transforman en un sistema operacional
2.4. Etapas
2.4.1. Elicitación
2.4.1.1. Se realiza el descubrimiento de los requisitos del sistema, los analistas deben trabajar junto con el cliente para descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar y las restricciones que se pueden presentar.
2.4.2. Análisis
2.4.2.1. Tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento, para ello se basa en los siguientes objetivos:
2.4.2.1.1. Detectar conflicto en los requisitos que suelen provenir de distintas fuentes y presentar contradicciones o ambigüedades debido a su naturaleza informal.
2.4.2.1.2. Profundizar en el conocimiento del dominio del problema puede facilitar el proceso de construir un producto útil para clientes y usuarios (Durán, 2000).
2.4.3. Especificación
2.4.3.1. Se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.
2.4.4. Validación
2.4.4.1. Garantiza que los requisitos, una vez analizados y resueltos los posibles conflictos, correspondan realmente a las necesidades de clientes y usuarios, para evitar que, a pesar de que el producto final sea técnicamente correcto, no sea satisfactorio.
3. Ciclo de vida del Software
3.1. Proceso que se desarrolla para construir y hacer evolucionar un determinado software
3.1.1. ISO/IEC/IEEE 12207:2017
3.1.1.1. Desarrolla un marco común para procesos de ciclo de vida en programas informáticos
3.1.1.1.1. Usa una terminología bien definida
3.1.1.2. Contiene
3.1.1.2.1. Procesos
3.1.1.2.2. Actividades
3.1.1.2.3. Tareas
3.1.1.2.4. Objetivo
3.1.2. Elementos que lo integran
3.1.2.1. Entregables
3.1.2.1.1. Productos intermedios que permiten evaluar la marcha mediante comprobaciones de su adecuación
3.1.2.2. Fases
3.1.2.2.1. Garantiza cumplimiento de los requisitos de la aplicación
3.1.3. Paradigmas de desarrollo de Software
3.1.3.1. Se establece con el fin de proporcionar una metodología común entre el cliente y la empresa de software.
3.1.3.1.1. Para plasmar las etapas y la documentación necesaria, de manera que cada fase se valide antes de continuar con la siguiente.
3.1.3.2. Paradigmas de modelos de ciclo de vida para desarrollar software.
3.1.3.2.1. 1. Paradigma tradicional
3.1.3.2.2. 2. Paradigma orientado a objetos
3.1.3.2.3. 3. Paradigma de desarrollo ágil
4. Requisitos
4.1. Se refiere a una condición requerida por un cliente para llevar a cabo la solución de un problema. Estos pueden ser:
4.1.1. Esperados o inesperados
4.1.2. Obvios u ocultos
4.1.3. Conocidos o desconocidos
4.2. Importancia
4.2.1. Establecen el alcance del trabajo subsecuente, pueden definir estrategias de desarrollo, riesgos, tomar decisiones de negocio (viabilidad de negocio), de proyecto (tiempo, recursos), de sistema (arquitectura).
4.2.2. Indican al equipo del proyecto qué requieren los usuarios (necesidades de negocio).
4.2.3. El éxito o fracaso de un proyecto está altamente influenciado por la calidad de los requisitos y el proceso para gestionarlos durante el desarrollo de un producto.
4.3. Características que deben cumplir
4.3.1. 1. Necesario
4.3.1.1. Si se tiene alguna duda acerca de la necesidad del requerimiento, se puede preguntar
4.3.1.1.1. ¿Qué sería lo peor de no incluirlo?
4.3.2. 2. Completo
4.3.2.1. Un requerimiento está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión.
4.3.3. 3. Consistente
4.3.3.1. Un requerimiento es consistente si no es contradictorio con otro requerimiento.
4.3.4. 4. Correcto
4.3.4.1. Acuerdo entre dos partes.
4.3.4.2. Contiene una sola idea
4.3.5. 5. Factible
4.3.5.1. El requerimiento deberá de ser totalmente factible y dentro de presupuesto, calendario y otras restricciones, si se tiene alguna duda de su factibilidad, hay que investigar, generar pruebas de concepto para saber su complejidad y factibilidad, si aun así el requerimiento es no factible, hay que revisar la visión del sistema y replantear el requerimiento.
4.3.6. 6. Modificable
4.3.6.1. Los cambios en los requisitos deben hacerse de manera sistemática, y debe tenerse en cuenta su impacto en otros requisitos.
4.3.7. 7. Priorizado
4.3.7.1. Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo:
4.3.7.1.1. Esencial/crítico
4.3.7.1.2. Deseado
4.3.7.1.3. Opcional verificable
4.3.8. 8. Verificable
4.3.8.1. Si un requerimiento no se puede comprobar, entonces, ¿Cómo se sabe si se cumplió con él o no? Debe ser posible verificarlo:
4.3.8.1.1. Inspección
4.3.8.1.2. Análisis de prueba
4.3.8.1.3. Demostración
4.3.9. 9. Rastreable
4.3.9.1. La especificación se debe organizar de tal forma que cada función del sistema se pueda rastrear hasta su conjunto de requerimientos correspondiente.
4.3.9.1.1. Facilita las pruebas y la validación del diseño.
4.3.10. 10. Claro
4.3.10.1. Un requerimiento es conciso si es fácil de leer y entender, su redacción debe ser simple y clara para quienes lo consulten en un futuro.
4.4. Clasificación
4.4.1. Se encuentra relacionada con el nivel de descripción con la que cuentan los requerimientos, dentro de estos se encuentran:
4.4.1.1. 1. Requerimientos de usuario
4.4.1.1.1. Son declaraciones en lenguaje natural y en representada en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
4.4.1.2. 2. Requerimientos de sistema
4.4.1.2.1. Establecen con detalle las funciones, servicios y restricciones operativas del sistema.