INGENIERIA DE REQUISITOS.pdf

PROGRAMACION DE SOFTWARE INGENIERÍA DE REQUISITOS La metodología Agile se usa en el desarrollo de software y otros proyectos de alto rendimiento; se centra en la implementación rápida de un equipo eficiente y flexible para planear el flujo de trabajo. Agile brinda la capacidad de elegir la mejor...

PROGRAMACION DE SOFTWARE INGENIERÍA DE REQUISITOS La metodología Agile se usa en el desarrollo de software y otros proyectos de alto rendimiento; se centra en la implementación rápida de un equipo eficiente y flexible para planear el flujo de trabajo. Agile brinda la capacidad de elegir la mejor opción en cada situación sin comprometer el proyecto Ciclo de vida del software También conocido como (SDLC o Systems Development Life Cycle o Ciclo de vida del desarrollo de sistemas ), 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. Un marco común para los procesos del ciclo de vida de los programas Si bien existen diferentes ciclos informáticos, con una terminología bien definida, a la que pueda remitirse la de desarrollo de software, la industria del software. Contiene procesos, actividades y tareas aplicables normativa ISO/IEC/IEEE durante la adquisición, el suministro, el desarrollo, el funcionamiento, el 12207:2017 establece: mantenimiento o la eliminación de sistemas, productos y servicios informáticos. Estos procesos del ciclo de vida se llevan a cabo mediante la participación de los interesados, con el objetivo final de lograr la satisfacción del cliente (s.p.). A continuación, se indican cuáles son los elementos que integran un ciclo de vida: Fases: Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales). Entregables: Son los productos intermedios que generan las fases. Pueden ser materiales o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecido. Fases Las fases del modelo de ciclo del software son: planificación, análisis, diseño, implementación, pruebas y mantenimiento. FASE PLANIFICACIÓN: En esta primera fase se realiza el planteamiento del problema, se definen alcances y objetivos del software. Objetivos: estudio de viabilidad, realizar planificación detallada. FASE ANÁLISIS (definición de requisitos): Esta fase busca definir los requisitos que son los que dirigirán el desarrollo del proyecto de software. Objetivos: conocer los requisitos, asegurar que los requisitos son alcanzables, formalizar acuerdo con el cliente. FASE DISEÑO: En esta fase se estudian posibles opciones de implementación para el software que hay que construir, estructura general del mismo. Objetivos: Identificar soluciones tecnológicas, asignar recursos materiales, proponer identificar y seleccionar, establecer métodos de validación, ajustar especificaciones. FASE PRUEBAS: Esta fase busca detectar fallos cometidos en las etapas anteriores para corregirlos. Objetivos: Realizar los ajustes necesarios para corregir posibles errores o inconsistencias. FASE MANTENIMIENTO: En esta fase se realizan tres puntos referenciados: mantenimiento correctivo, mantenimiento adaptativo y mantenimiento perfectivo. Objetivos: Operación asegurar que el uso del proyecto es el que se pretendía, mantenimiento. Mantenimiento correctivo: Es necesario cuando algo sale mal en una pieza de software, incluidos fallos y errores. Estos pueden tener un impacto generalizado en la funcionalidad del software en general y, por lo tanto, deben abordarse lo antes posible. Si una empresa puede reconocer y solucionar las fallas antes de que los usuarios las descubran, esta es una ventaja adicional que hará que su empresa parezca más respetable y confiable (después de todo, a nadie le gusta un mensaje de error). Mantenimiento adaptativo: Tiene que ver con las tecnologías cambiantes, así como con las políticas y reglas relacionadas con su software. Las cuales incluyen cambios en el sistema operativo, almacenamiento en la nube, hardware, etc. Cuando se realizan estos cambios, su software debe adaptarse para cumplir adecuadamente los nuevos requisitos y continuar funcionando bien. Mantenimiento perfectivo Tiene como objetivo ajustar el software agregando nuevas características según sea necesario y eliminando características que son irrelevantes o no efectivas en el software dado. Este proceso mantiene el software relevante a medida que el mercado y las necesidades del usuario cambian.  Paradigmas de los modelos de ciclo de vida del software Con la finalidad de proporcionar una metodología común entre el cliente y la empresa de software, se utilizan los modelos de ciclos de vida o paradigmas de desarrollo de software para plasmar las etapas y la documentación necesaria, de manera que cada fase se valide antes de continuar con la siguiente. 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. Según la norma 1074 IEEE se define al ciclo de vida del software como: “Una aproximación lógica a la La ISO/IEC 12207 Information Technology (Tecnologías de la información ) / Software Life Cycle Processes (Procesos del adquisición, el suministro, el ciclo de vida del software) señala que es: Un marco de referencia que contiene los procesos, las desarrollo, la explotación y el actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto de software, mantenimiento del software” abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso (2008). Existen modelos preestablecidos con los cuales se pude elaborar un proyecto; a continuación, se mencionan los diferentes paradigmas de modelos de ciclo de vida para desarrollar software. Paradigma tradicional 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. Si bien es verdad que las metodologías actuales están basadas en lo que fueron los paradigmas tradicionales, hoy en día se ha evolucionado, sin embargo, los paradigmas tradicionales se mantienen. Desventaja: Pérdida de tiempo si se encuentran errores en una fase avanzada porque al devolverse se debe pasar nuevamente por todas las fases y reestructurar de acuerdo con las modificaciones. 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. Con este paradigma se pretende que el código fuente sea reutilizable para otros proyectos. 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. Una de las principales diferencias con los paradigmas anteriores es que el cliente se ve involucrado en el proyecto durante el desarrollo de este, así, el cliente sugiere mejoras, propone ideas y se mantiene al tanto del desarrollo del producto, a diferencia del paradigma tradicional y el orientado objeto donde el cliente únicamente está al principio. Modelos del paradigma tradicional más utilizados. Modelo en cascada: 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” (waterfall model). 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. Requerimiento Diseño Codificación Pruebas Operación Modelo espiral del ciclo de vida del desarrollo. 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. El modelo incorpora un nuevo elemento en el desarrollo de software como es el “análisis de riesgos” y define cuatro actividades principales representadas por los cuatro cuadrantes de la figura: Planificación -> Determina objetivos, alternativas y restricciones Análisis de riesgo -> Evalúa alternativas, identifica y resuelve riesgos. Ingeniería -> Desarrollo y verificación del producto del siguiente nivel. Evaluación del cliente -> Valoración de los resultados y planificación de la siguiente fase. Una de sus principales ventajas es que los riesgos van disminuyendo conforme avanzan los ciclos o interacciones.  Con cada iteración alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se van construyendo sucesivas versiones del software, cada vez más completas. Durante la primera vuelta de la espiral, en el primer cuadrante (superior izquierdo) se determinan objetivos, alternativas y restricciones; y en el segundo cuadrante (superior derecho) se analizan e identifican los riesgos (¿se dispone de personal?, ¿está preparado?, ¿existe mercado para el producto?, etc.). Si el análisis de los riesgos indica que existe incertidumbre en los requisitos se puede desarrollar un prototipo para su valoración, y también se pueden usar simulaciones y otros modelos para definir más el problema y refinar los requisitos. En el cuadrante tercero (inferior derecho) se incorporan incrementalmente las etapas del ciclo de vida tradicional en cada ciclo de la espiral. Modelo espiral del ciclo de vida del desarrollo Modelo iterativo o por prototipos 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). Objetivos A Son un medio eficaz para aclarar los B Mediante el prototipo se puede requisitos de los usuarios e identificar las verificar la viabilidad del diseño de un características de un sistema que deben sistema. cambiarse o añadirse. Las etapas del modelo son: 1. Colecta y refinamiento de los requerimientos y proyecto rápido.  Análisis.  Especificación del prototipo. 2. Diseño rápido. 3. Construcción del prototipo. 4. Evaluación del prototipo por cliente 5. Refinamiento del prototipo. Diseño técnico. Programación y test. Operación y mantenimiento. 6. Producto de ingeniería Modelo iterativo o por prototipos. Con respecto a los modelos del ciclo de vida del paradigma ágil, estos se caracterizan por estar basados en etapas del ciclo de vida del software tradicional, pero combinándolas con algunas técnicas, al respecto se pueden revisar los siguientes: Modelo Scrum: 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. Los procesos que utiliza son: 1. Product Backlog (Lista de productos pendientes): Es un listado de todas las tareas que se pretenden hacer durante el desarrollo de un proyecto. Algunos product backlog pueden asociarse con proyectos de varios años, incluso. Todas las tareas deben listarse en el product backlog, para que estén visibles ante todo el equipo y se pueda tener una visión panorámica de todo lo que se espera realizar. 2. Sprint Backlog. (Lista de pendientes): Permite ver las tareas donde el equipo está teniendo problemas y no avanza, para tomar decisiones al respecto. Para cada uno de los objetivos/requisitos del proyecto se muestran las tareas a cubrir. 3. Sprint Planning Meeting. (Reunión de planificación de sprint) Actores externos pueden asistir por invitación del equipo, pero es inusual que suceda en la mayoría de las compañías. Durante esta reunión de planificación, el propietario del producto describe las características con mayor prioridad al equipo. 4. Daily Scrum: El equipo mantiene una reunion diaria. Usualmente estas reuniones se realizan en el mismo lugar y a la misma hora, en cada uno de los días. Estas reuniones son estrictamente desarrolladas con un tiempo límite de 15 minutos. Esto hace que la reunión sea breve y se traten puntos importantes. 5. Sprint Review: Es el nombre que recibe la reunión que se celebra con el propósito de evaluar los resultados que obtuvo el equipo. Esta permite, a su vez, analizar el progreso que está teniendo el desarrollo con miras a cumplir con el objetivo establecido. 6. Sprint Retrospective – (Retrospectiva): Con el objetivo de mejorar de manera continua la productividad y la calidad del producto que está desarrollando, la motivación del equipo, cómo están engranando entre ellos, como fue la última iteración o cómo está yendo el proyecto… el equipo analiza cómo ha sido su manera de trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que se comprometió al inicio de la iteración y por qué el incremento de producto que acaba de demostrar al cliente era lo que él esperaba o no: Qué cosas han funcionado bien. Cuales hay que mejorar. Qué cosas quiere probar hacer en la siguiente iteración. Qué ha aprendido. Cuales son los problemas que podrían impedirle progresar adecuadamente El Scrum consiste en realizar un análisis de los requerimientos del sistema (Product Backlog - Lista de productos pendientes), señalar cuáles serán los objetivos a corto o mediano plazo dentro de un sprint, o sea, la fase de desarrollo. Posteriormente, los desarrolladores harán lo suyo, se realizarán algunas pruebas y se retroalimentará de acuerdo con lo conseguido al terminar la última fase. Ventajas Gestión regular de las expectativas del usuario: los usuarios participan y proponen soluciones. Resultados anticipados: no es necesario esperar hasta el final para ver resultados. Flexibilidad y adaptación: se adapta a cualquier contexto, área o sector. Gestión sistemática de riesgos: los problemas son gestionados en el mismo momento de su aparición. Modelo ágil Scrum Modelo Kanban David J. Anderson (reconocido como el líder Mediante la metodología japonesa Kanban se: de pensamiento de la adopción del Lean/Kanban para el trabajo de 1. Define el flujo de trabajo. conocimiento), formuló el método Kanban 2. Establecen las fases del ciclo de producción. como una aproximación al proceso evolutivo 3. Stop Starting, start finishing.(Deja de empezar, empieza a terminar.) e incremental y al cambio de sistemas para 4. Tiene un control. 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. El modelo Kanban es uno de los modelos más visuales de las metodologías ágiles; este consiste en la creación de un tablero con etiquetas, donde se seccionan cada una de las fases de su desarrollo, además se clasifican de acuerdo con los equipos de trabajo y se les asignan objetivos a corto, mediano y largo plazo.  Características principales de la programación extrema: Modelo XP o programación extrema 1. Tipo de desarrollo iterativo e incremental. La programación extrema o 2. Pruebas unitarias. eXtreme Programming (XP) es un 3. Trabajo en Equipo. enfoque de la ingeniería de 4. Trabajo junto al cliente. software formulado por Kent 5. Corrección de errores. Beck, autor del primer libro sobre 6. Reestructuración del código. este tema: Extreme Programming 7. El código es de todos. Explained(Explicación de la 8. El código simple es la clave. programación extrema): Embrace Change (1999)(Aceptar el cambio). 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. Fase de definición de requisitos 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. Por eso, la etapa de análisis en el ciclo de vida del software corresponde al proceso a través del cual se intenta descubrir qué es lo que realmente se necesita y se llega a una comprensión adecuada de los requerimientos del sistema (las características que el sistema debe poseer). La etapa de análisis es esencial debido a que sin esta no se sabe con precisión qué es lo que se necesita y ningún proceso de desarrollo permitirá obtenerlo. El problema que se presenta es que al inicio del desarrollo el cliente no sepa exactamente lo que necesita; por tanto, se debe averiguar con ayuda de distintas técnicas. De otra parte, la inestabilidad de los requerimientos de un sistema es inevitable, pues se estima que 25% de los requerimientos iniciales de un sistema cambian antes de que el sistema comience a utilizarse. Por ello, muchas prácticas resultan efectivas para gestionar adecuadamente los requerimientos de un sistema y, en cierto modo, controlar su evolución. En esta tabla se describen las actividades y los artefactos que se realizan en la fase de definición de requisitos. Fase Actividades Artefactos Definición del alcance del proyecto. Identificación del negocio. Modelo del negocio. Toma de requerimientos. Análisis y realización de Análisis (definición de casos de uso. requisitos). Estudio de procesos de Modelo de procesos y negocio. actividades de negocio. Calendarización del Cronograma del proyecto. proyecto. Requisitos “Un requisito es una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado (IEEE, 1990). 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. Importancia de los requisitos Los requisitos cobran importancia dentro del ciclo de vida del software, puesto que: Establecen el alcance del trabajo subsecuente, pueden definir 1 estrategias de desarrollo, riesgos, tomar decisiones de negocio (viabilidad de negocio), de proyecto (tiempo, recursos), de sistema (arquitectura). 2 Indican al equipo del proyecto qué requieren los usuarios (necesidades de negocio). 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. En la siguiente figura se pueden revisar las características que los requisitos deben cumplir de acuerdo con Pfleeger (2002). Necesario 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. Completo 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. Consistente Un requerimiento es consistente si no es contradictorio con otro requerimiento. Correcto Acuerdo entre dos partes. Contiene una sola idea. Factible 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. Modificable Los cambios en los requisitos deben hacerse de manera sistemática, y debe tenerse en cuenta su impacto en otros requisitos. Priorizado Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo: esencial/crítico, deseado, opcional verificable. Verificable 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. Rastreable 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. Claro 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. Clasificación 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: Requerimientos de usuario : 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. Requerimientos de sistema: 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. Requerimientos no funcionales: 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. En la siguiente tabla se presentan algunos ejemplos sobre requisitos funcionales y no funcionales. Funcionales No funcionales Se debe ingresar cédula, nombre y teléfono de cada Las consultas deben resolverse en menos de 3 cliente. segundos. Se requiere un listado de clientes por zona. El lenguaje de programación debe ser php. Ingeniería de requisitos Las siguientes son definiciones de ingeniería de requisitos de algunos autores. 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). 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). La ingeniería de requisitos puede considerarse 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) El término IR “ingeniería de requisitos” ha surgido para englobar los procesos de desarrollo y gestión de requisitos en el ciclo de vida del software, el primer término (ingeniería) se enfoca en las actividades de obtención, análisis, especificación y validación de los requisitos que permitirá alcanzar los objetivos del negocio y el segundo (requisitos) está centrado en la administración de los mismos y tiene como propósito central la gestión de los cambios y la trazabilidad, de esta forma la IR proporciona el mecanismo apropiado para:  Entender lo que el cliente quiere.  Analizar las necesidades.  Evaluar la factibilidad.  Negociar una solución razonable.  Especificar la solución sin ambigüedades.  Validar la especificación.  Administrar los requisitos conforme éstos se transforman en un sistema operacional. Etapas de la ingeniería de requisitos Hay cuatro (4) etapas en un proceso usual de ingeniería de requisitos y que son utilizadas para el desarrollo de un producto único, a saber: elicitación, análisis, especificación y validación de los requisitos. Elicitación 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. Los principales objetivos que se deben alcanzar son los siguientes: 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. 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. Consensuar los requisitos entre los propios clientes y usuarios hasta obtener una visión común de los mismos. Análisis: 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: Detectar conflicto en los requisitos que suelen provenir de distintas fuentes y presentar contradicciones o ambigüedades debido a su naturaleza informal. Profundizar en el conocimiento del dominio del problema puede facilitar el proceso de construir un producto útil para clientes y usuarios (Durán, 2000). En esta fase, el analista proporciona un sistema de retroalimentación que refina el entendimiento conseguido en la etapa de obtención. Especificación: 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. Validación: 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. Glosario Ágil: comprende un conjunto de tareas o acciones que se utilizan para producir y mantener productos, así como para lograr los objetivos del proceso. La actividad incluye los procedimientos, estándares, políticas y objetivos para crear y modificar un conjunto de productos de trabajo. Ciclo de vida de software: aplicación de metodologías para el desarrollo del sistema software [AECC, 1986]. Método: indica cómo construir técnicamente el software. Se incluyen técnicas de modelado y otras técnicas descriptivas. Metodología: colección de métodos para resolver un tipo de problema. Requerimiento: se refiere a la petición que se hace de algo que se solicita. Requisito: condición que debe cumplir algo, en general el requisito cumple con lo que se requiere con el requerimiento. ISO: La Organización Internacional de Normalización es una organización para la creación de estándares internacionales compuesta por diversas organizaciones nacionales de normalización. IEC: La Comisión Electrotécnica Internacional, también conocida por su sigla en inglés IEC, es una organización de normalización en los campos: eléctrico, electrónico y tecnologías relacionadas. IEEE : El Instituto de Ingenieros Eléctricos y Electrónicos es la sociedad técnico-profesional más grande y prestigiosa del mundo, dedicada a promover y divulgar los avances científicos en las áreas de Ingeniería Eléctrica, Electrónica, Energética, Informática y afines. Pruebas unitarias: Consisten en verificar el comportamiento de las unidades más pequeñas de su aplicación. SPRINT: Período breve de tiempo fijo en el que un equipo de scrum trabaja para completar una cantidad de trabajo establecida. Material complementario CavernaTech. (01 de septiembre de 2019). Requisitos funcionales y no funcionales. YouTube. https://www.youtube.com/watch?v=Lv7XbZtnQ6A Itunes U – UAEH. (10 de enero de 2019). Tipos de requerimientos. YouTube. https://www.youtube.com/watch?v=PUyfzEzSUSg Universidad Católica de Murcia. (11 de febrero de 2015). Ingeniería del software - Ciclo de vida - Raquel Martínez YouTube. https://www.youtube.com/watch?v=4tWmULUzVdE&t=199s Pressman, R. (1993). Ingeniería del software: un enfoque práctico. McGraw-Hill Inc. https://doku.pub/documents/ingenieria-de-software-un-enfoque-practico6thedicion- rogerpressman1-p6lkgywex804