1. CICLO DE VIDA DEL SOFTWARE
1.1. Es el proceso que se sigue para construir y hacer evolucionar un determinado software
1.2. Elementos que integran un ciclo de vida
1.2.1. Fases
1.2.1.1. conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto.
1.2.1.2. Fase de planificación
1.2.1.2.1. se realiza el planteamiento del problema, se definen alcances y objetivos del software
1.2.2. Entregables
1.2.2.1. productos intermedios que generan las fases. Pueden ser materiales o inmateriales (documentos, software).
1.3. Paradigmas de modelos
1.3.1. Tradicional: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
1.3.2. Paradigma orientado a objetos: Las etapas de desarrollo de software en el paradigma orientado a objetos, se conforma principalmente por la creación de clases, análisis de requisitos y el diseño.
1.3.3. Paradigma de desarrollo ágil: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
1.3.4. Modelo en cascada:cada una de las actividades genera, como salidas, productos y modelos que son utilizados como entradas para el proceso subsiguiente;
1.3.5. Modelo espiral: 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.
1.3.6. Modelo Iterativo:procedimiento que permite al equipo de desarrollo diseñar y analizar una aplicación que represente el sistema que será implementado
1.3.7. Modelo Scrum: 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.
2. FASE DE DEFINICIÓN DE REQUISITOS
2.1. A través de la fase de definición de requisitos, identificamos:
2.1.1. Actividades
2.1.1.1. Definición del alcance del proyecto. Identificación del negocio. Toma de requerimientos. Estudio de procesos de negocio. Calendarización del proyecto
2.1.2. Artefactos
2.1.2.1. Modelo del negocio. Analisis y realización de casos de uso. Modelo de procesos y actividades de negocio. Cronograma del proyecto
3. Es un proceso que permite identificar lo que realmente se necesita; requerimientos del sistema, a través de la etapa de análisi
4. REQUISITOS
4.1. condición o capacidad que necesita el usuario para resolver un problema
4.1.1. importancia
4.1.1.1. Establecen el alcance del trabajo subsecuente, pueden definir estrategias de desarrollo, riesgos, tomar decisiones de negocio
4.1.1.2. Indican al equipo del proyecto qué requieren los usuarios
4.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.
4.2. Caracteristicas
4.2.1. Completo, consistente, correcto, factible,modificable,priorizado,verificable, rastreable,claro.
4.3. Clasificación
4.3.1. requerimientos de usuario: declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema proporcione
4.3.2. requerimientos de sistema: establecen con detalle las funciones, servicios y restricciones operativas del sistema.
4.3.3. requerimientos funcionales: Son declaraciones de los servicios que debe proporcionar el sistema, de la manera en que este debe reaccionar a entradas particulares
4.3.4. requerimientos no funcionales:Son restricciones de los servicios o funciones ofrecidos por el sistema
5. INGENIERIA DE REQUISITOS
5.1. 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.
5.2. Etapas de la ingeniería de requisitos
5.2.1. Elicitación: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.
5.2.2. Análisis:tiene como propósito descubrir problemas con los requisitos del sistema identificados hasta el momento
5.2.3. Especificación: es el “pasar en limpio” el análisis realizado previamente aplicando técnicas y/o estándares de documentación,
5.2.4. Validación; 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,