1. Ciclo de vida del software:También conocido como (SDLC o Systems Development Life Cycle), es el proceso que se sigue para construir y hacer evolucionar un determinado software. El ciclo de vida permite iniciar una serie de fases mediante las cuales se procede a la validación y al desarrollo del software garantizando que se cumplan los requisitos para la aplicación y verificación de los procedimientos de desarrollo; para ello, se utilizan métodos del ciclo del software, que indican distintos pasos a seguir para el desarrollo de un producto.
1.1. faces
1.1.1. planificación:En esta primera fase se realiza el planteamiento del problema, se definen alcances y objetivos del software..
1.1.2. análisis:Esta fase busca definir los requisitos que son los que dirigirán el desarrollo del proyecto de software.
1.1.3. diseño:En esta fase se estudian posibles opciones de implementación para el software que hay que construir, estructura general del mismo
1.1.4. implementación:Esta fase busca detectar fallos cometidos en las etapas anteriores para corregirlos
1.1.5. pruebas:En esta fase se realizan tres puntos referenciados: mantenimiento correctivo, mantenimiento adaptativo y mantenimiento perfectivo.
1.1.6. mantenimiento,
2. Paradigmas de los modelos de ciclo de vida del software:
2.1. Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software e intenta determinar el orden de las etapas involucradas y los criterios de transición asociados entre estas.
2.1.1. Paradigma tradicional
2.1.1.1. Los paradigmas tradicionales se identifican, fundamentalmente, por ser lineales, es decir se trata de completar cada proceso de principio a fin hasta que quede listo para avanzar a la segunda fase del ciclo del software.
2.1.2. Paradigma de desarrollo ágil
2.1.2.1. El objetivo de este paradigma es el desarrollo de proyectos en poco tiempo, se simplifican procesos tediosos, se agilizan las fases del desarrollo y las interacciones se hacen en corto tiempo.
3. Modelo en cascada
3.1. En su concepción básica, cada una de las actividades genera, como salidas, productos y modelos que son utilizados como entradas para el proceso subsiguiente; esto supone que una actividad debe terminarse (por lo menos, en algún grado) para empezar la siguiente
4. Modelo espiral
4.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. El espiral se repite las veces que sea necesario hasta que el cliente o el usuario obtenga la satisfacción de sus necesidades. En este modelo hay 4 actividades que envuelven a las etapas: planificación, análisis de riesgo, implementación y evaluación. Una de sus principales ventajas es que los riesgos van disminuyendo conforme avanzan los ciclos o interacciones.
5. Modelo iterativo o por prototipos
5.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. Modelo Kanban
6.1. David J. Anderson (reconocido como el líder de pensamiento de la adopción del Lean/Kanban para el trabajo de conocimiento), formuló el método Kanban como una aproximación al proceso evolutivo e incremental y al cambio de sistemas para las organizaciones de trabajo. El método está enfocado en llevar a cabo las tareas pendientes y los principios más importantes pueden ser divididos en cuatro principios básicos y seis prácticas.
6.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.
7. Modelo XP o programación extrema
7.1. La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre este tema: Extreme Programming Explained: Embrace Change (1999). 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.
7.1.1. Características principales de la programación extrema:
7.1.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.
8. Modelo Scrum
8.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.
8.1.1. Los procesos que utiliza son
8.1.1.1. 1 Product Backlog. 2 Sprint Backlog. 3 Sprint Planning Meeting. 4 Daily Scrum. 5 Sprint Review. 6 Sprint Retrospective
9. Conclusiones
9.1. Importancia de la ingeniería de requisitos en el éxito del proyecto de software Resumen de los principales conceptos y técnicas de la ingeniería de requisitos
10. Proceso de ingeniería de requisitos
10.1. Etapas
10.1.1. Elicitación
10.1.1.1. Actividad involucrada en el descubrimiento de los requisitos del sistema. Aquí 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.
10.1.1.1.1. Conocer el dominio del problema, de forma tal que los analistas puedan entenderse con los clientes y usuarios y sean capaces de transmitir dicho conocimiento al resto del equipo.
10.1.1.1.2. Descubrir necesidades reales entre clientes y usuarios, haciendo énfasis en aquellas que la mayor parte de las veces se asumen y toman por implícitas.
10.1.1.1.3. Consensuar los requisitos entre los propios clientes y usuarios hasta obtener una visión común de los mismos.
10.1.2. Análisis
10.1.2.1. Sobre la base de la obtención realizada previamente, comienza esta fase la cual tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento, para ello se basa en los siguientes objetivos
10.1.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.
10.1.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).
10.1.3. Especificación
10.1.3.1. Aquí se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle. En la práctica, esta etapa se realiza conjuntamente con el análisis, por lo que se puede decir que la especificación es el “pasar en limpio” el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje de Modelado Unificado), que es un estándar para el modelado orientado a objetos, por lo que los casos de uso y la obtención de requisitos basada en los casos de uso se utilizan cada vez más para la obtención de requisitos.
10.1.4. Validación
10.1.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. La validación 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.
11. 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 y dentro de este tipo de clasificación se encuentran:
11.1. Requerimientos de usuario
11.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.
11.2. Requerimientos de sistema
11.2.1. Estos requerimientos establecen con detalle las funciones, servicios y restricciones operativas del sistema. El documento de requerimientos del sistema deberá ser preciso, y definir exactamente lo que se va a desarrollar.
11.2.1.1. Requerimientos funcionales
11.2.1.1.1. Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a entradas particulares; o también pueden declarar explícitamente lo que el sistema no debe hacer.
11.2.1.2. Requerimientos no funcionales
11.2.1.2.1. Son restricciones de los servicios o funciones ofrecidos por el sistema. Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares. Dentro de estos requerimientos se encuentra todo lo referente a la fiabilidad, el tiempo de respuesta y la capacidad de almacenamiento.
12. Requisitos
12.1. Los requisitos comunican las expectativas de los consumidores de productos software; de otra parte, los requisitos pueden ser obvios o estar ocultos, conocidos o desconocidos, esperados o inesperados, desde el punto de vista del cliente.
12.1.1. Importancia de los requisitos
12.1.1.1. Los requisitos cobran importancia dentro del ciclo de vida del software, puesto que:
12.1.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).
12.1.1.1.2. Indican al equipo del proyecto qué requieren los usuarios (necesidades de negocio).
12.1.1.1.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.
12.1.2. se pueden revisar las características que los requisitos deben cumplir de acuerdo con Pfleeger
12.1.2.1. Necesario
12.1.2.1.1. Si se tiene alguna duda acerca de la necesidad del requerimiento, se puede preguntar “¿Qué sería lo peor de no incluirlo?”. Si no se encuentra una respuesta o cualquier consecuencia, entonces es probable que no sea un requerimiento necesario.
12.1.2.2. Completo
12.1.2.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.
12.1.2.3. Consistente
12.1.2.3.1. Un requerimiento es consistente si no es contradictorio con otro requerimiento.
12.1.2.4. Correcto
12.1.2.4.1. Acuerdo entre dos partes. Contiene una sola idea
12.1.2.5. Factible
12.1.2.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.
12.1.2.6. Modificable
12.1.2.6.1. Los cambios en los requisitos deben hacerse de manera sistemática, y debe tenerse en cuenta su impacto en otros requisitos.
12.1.2.7. Priorizado
12.1.2.7.1. Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo: esencial/crítico, deseado, opcional verificable.
12.1.2.8. Verificable
12.1.2.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 ya sea por inspección, análisis de prueba o demostración. Cuando se escriba un requerimiento, se deberán determinar los criterios de aceptación.
12.1.2.9. Rastreable
12.1.2.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. Facilita las pruebas y la validación del diseño.
12.1.2.10. Claro
12.1.2.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.