1. Ciclo de vida del software
1.1. El ciclo de vida permite iniciar una serie de fases mediante las cuales se procede a la validación y al desarrollo del software.
1.1.1. FASES
1.1.1.1. PLANIFICACIÓN
1.1.1.1.1. Planteamiento del problema
1.1.1.2. ANÁLISIS
1.1.1.2.1. Definición de requisitos
1.1.1.3. DISEÑO
1.1.1.3.1. Estructura general del Software
1.1.1.4. PRUEBAS
1.1.1.4.1. Ajustes a errrores
1.1.1.5. MANTENIMIENTO
1.1.1.5.1. Correctivo, adaptativo y perfectivo.
1.2. Paradigmas de los modelos de ciclo de vida del software
1.2.1. Paradigma tradicional
1.2.1.1. Lineales, completa cada proceso de principio a fin hasta que quede listo.
1.2.1.1.1. Modelo en cascada (W. Royce en 1970)
1.2.1.1.2. Modelo espiral (Boehm en el año 1988 )
1.2.1.1.3. Modelo iterativo o por prototipos (McCracken y Jackson, 1982)
1.2.2. Paradigma orientado a objetos
1.2.2.1. Se pretende que el código fuente sea reutilizable para otros proyectos.
1.2.3. Paradigma de desarrollo ágil
1.2.3.1. Se agilizan las fases del desarrollo y las interacciones se hacen en corto tiempo.
1.2.3.1.1. Modelo Scrum
1.2.3.1.2. Modelo Kanban (David J. Anderson)
1.2.3.1.3. Modelo XP o programación extrema (Kent Beck)
2. Fase de definición de requisitos
2.1. Se recopila, se examina y se formulan los requisitos del cliente
2.1.1. Características que el sistema debe poseer.
2.1.1.1. Definición del alcance del proyecto
2.1.1.2. Identificación del negocio.
2.1.1.2.1. Modelo del negocio.
2.1.1.3. Toma de requerimientos
2.1.1.3.1. Análisis y realización de casos de uso
2.1.1.4. Estudio de procesos de negocio.
2.1.1.4.1. Modelo de procesos y actividades de negocio.
2.1.1.5. Calendarización del proyecto.
2.1.1.5.1. Cronograma del proyecto.
3. Requisitos
3.1. Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado (IEEE, 1990).
3.1.1. Importancia
3.1.1.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).
3.1.1.2. Indican al equipo del proyecto qué requieren los usuarios (necesidades de negocio).
3.1.1.3. Influencia el éxito o fracaso de un proyecto.
3.1.2. Características de los requisitos.
3.1.2.1. Necesario
3.1.2.2. Completo
3.1.2.3. Consistente
3.1.2.4. Correcto
3.1.2.5. Factible
3.1.2.6. Modificable
3.1.2.7. Priorizado
3.1.2.8. Verificable
3.1.2.9. Rastreable
3.1.2.10. Claro
3.1.3. Clasificación
3.1.3.1. Requerimientos del usuario
3.1.3.1.1. Son declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el sistema proporcione y de las restricciones bajo las cuales debe funcionar.
3.1.3.2. Requerimientos de sistema
3.1.3.2.1. Establece las funciones, servicios y restricciones operativas del sistema. Deberá ser preciso, y definir exactamente lo que se va a desarrollar.
4. Ingeniería de requisitos
4.1. Ha surgido para englobar los procesos de desarrollo y gestión de requisitos en el ciclo de vida del software.
4.2. Proporciona el mecanimo para:
4.2.1. Entender lo que el cliente quiere.
4.2.2. Analizar las necesidades.
4.2.3. Evaluar la factibilidad.
4.2.4. Negociar una solución razonable.
4.2.5. Especificar la solución sin ambigüedades.
4.2.6. Validar la especificación
4.2.7. Administrar los requisitos conforme éstos se transforman en un sistema operacional.
4.3. Etapas
4.3.1. Elicitación
4.3.1.1. Descubrir el problema que el sistema debe resolver, los diferentes servicios que el sistema debe prestar y las restricciones que se pueden presentar.
4.3.2. Análisis
4.3.2.1. Tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento
4.3.3. Especificación
4.3.3.1. Es el “pasar en limpio” el análisis realizado previamente aplicando técnicas y/o estándares de documentación
4.3.4. Validación
4.3.4.1. Puede llevar al analista a reescribir algunas especificaciones de requisitos y, en otros casos, a obtener nuevos, producto de la aparición de necesidades que hasta entonces estaban ocultas, para volver a evaluar el análisis inicial, o para corregir y perfeccionar el conjunto de requisitos documentados.