1. Importancia de los requisitos
1.1. Los requisitos cobran importancia dentro del ciclo de vida del software, puesto que:
1.2. Establecen el alcance del trabajo subsecuente, pueden definir estrategias de desarrollo, riesgos, tomar decisiones de negocio (
1.3. necesidades de negocio).
1.4. El éxito o fracaso de un proyecto está altamente influenciado por la calidad de los requisitos
2. las características
2.1. 1) necesario 2) completo 3) consistente $) correcto 5) factible 6) modificable 7) priorizado 8) verificable 9) rastreable 10) claro
3. Clasificación
3.1. Los requerimientos se pueden definir de distintas maneras, la primera clasificación se encuentra relacionada con el nivel de descripción con la que cuentan estos
3.2. Requerimientos de usuario
3.2.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.3. Requerimientos de sistema
3.3.1. Estos requerimientos establecen con detalle las funciones, servicios y restricciones operativas del sistema.
3.4. Requerimientos funcionales
3.4.1. pueden declarar explícitamente lo que el sistema no debe hacer.
3.5. Requerimientos no funcionales
3.5.1. Dentro de estos requerimientos se encuentra todo lo referente a la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento.
4. Ingeniería de requisitos
4.1. La ingeniería de requisitos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en dónde se describen las funciones que realizará el sistema. - (Boehm, 1979).
4.2. La ingeniería de requisitos es el proceso de estudiar las necesidades del usuario para llegar a una definición de requisitos de sistema, hardware o software. - (IEEE, 1990).
5. Etapas de la ingeniería de requisitos
5.1. Elicitación
5.1.1. Aquí los analistas deben trabajar junto con el cliente para descubrir el problema que el sistema debe resolver
5.1.1.1. Los principales objetivos que se deben alcanzar son los siguientes
5.1.1.1.1. Conocer el dominio del problema,
5.1.1.1.2. Descubrir necesidades reales entre clientes y usuarios
5.1.1.1.3. Consensuar los requisitos entre los propios clientes
5.2. Análisis
5.2.1. omienza esta fase la cual tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento
5.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.
5.2.1.2. Profundizar en el conocimiento del dominio del problema puede facilitar el proceso de construir un producto útil para clientes y usuarios
5.3. Especificación
5.3.1. Aquí se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.
5.4. Validación
5.4.1. Por último, la validación 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
6. modelos del paradigma tradicional más utilizados.
6.1. MODELO CASCADA
6.1.1. Uno de los primeros modelos de ciclo de vida del desarrollo fue establecido por W. Royce en 1970 y es conocido como el ?modelo de cascada
6.2. MODELO EN ESPIRAL
6.2.1. Fue diseñado por Boehm en el año 1988 y se basa en una serie de ciclos repetitivos para ir ganando madurez en el producto final
6.3. Modelo iterativo o por prototipos
6.3.1. Este modelo consiste en un procedimiento que permite al equipo de desarrollo diseñar y analizar una aplicación que represente el sistema que será implementado (McCracken y Jackson, 1982).
6.4. MODELO SCRUM
6.4.1. Este modelo se basa en el desarrollo incremental, es decir conforme pasen las fases y la iteración mayor será el tamaño del proyecto que se está desarrollando.
6.4.1.1. Los procesos que utiliza son: 1 Product Backlog. 2 Sprint Backlog. 3 Sprint Planning Meeting. 4 Daily Scrum. 5 Sprint Review. 6 Sprint Retrospective
6.5. Modelo Kanban
6.5.1. reconocido como el líder de pensamiento de la adopción del Lean/Kanban para el trabajo de conocimiento)
6.5.1.1. Mediante la metodología japonesa Kanban se: 1 Define el flujo de trabajo. 2 Establecen las fases del ciclo de producción. 3 Stop Starting, start finishing. 4 Tiene un control.
6.6. Modelo XP o programación extrema
6.6.1. Esta metodología es adaptable según las necesidades y requerimientos a implementar, además, el cliente se encuentra involucrado en el proceso de desarrollo lo que hace que el producto pueda ser terminado en un menor tiempo.
6.6.1.1. 1 Tipo de desarrollo iterativo e incremental. 2 Pruebas unitarias. 3 Trabajo en Equipo. 4 Trabajo junto al cliente. 5 Corrección de errores. 6 Reestructuración del código. 7 El código es de todos. 8 El código simple es la clave.
7. CICLO DE VIDA DEL SOFTWARE
7.1. es el proceso que se sigue para construir y hacer evolucionar un determinado software
7.1.1. PLANIFICACION
7.1.1.1. En esta primera fase se realiza el planteamiento del problema Objetivos: estudio de viabilidad, realizar planificación detallada.
7.2. MANTENIMIENTO
7.2.1. En esta fase se realizan tres puntos referenciados: mantenimiento correctivo, mantenimiento adaptativo y mantenimiento perfectivo.
7.3. PRUEBAS
7.3.1. Esta fase busca detectar fallos cometidos en las etapas anteriores para corregirlos.
7.4. DISEÑO
7.4.1. En esta fase se estudian posibles opciones de implementación para el software que hay que construir
7.5. ANALISIS
7.5.1. Esta fase busca definir los requisitos que son los que dirigirán el desarrollo del proyecto de software.
8. Paradigmas de los modelos de ciclo de vida del software
8.1. SO/IEC 12207
8.1.1. Un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software,
8.2. norma 1074 IEEE
8.2.1. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software
9. Fase de definición de requisitos
9.1. En esta primera fase del ciclo de vida del software, también llamada fase de análisis, se recopila, se examina y se formulan los requisitos del cliente, así como la verificación de las posibles restricciones que se puedan aplicar.
9.1.1. 1) Fase: Análisis (definición de requisitos). 2): Actividades: Definición del alcance del proyecto. Identificación del negocio. Toma de requerimientos. Estudio de procesos de negocio. Calendarización del proyecto. 3): Artefactos: Modelo del negocio. Análisis y realización de casos de uso. Modelo de procesos y actividades de negocio. Cronograma del proyecto.