VERIFICACIÓN Y VALIDACIÓN DE SISTEMAS 3.10 Fase de manejo de requerimientos 4.1 Modelado de pruebas en UML Ponente: ing. Alejandro tapia vazquez

3.10 FASE DE MANEJO DE REQUERIMIENTOS  Los requisitos son la parte más incomprendida de la Ingeniería de Software y sin embargo, es la más crucial.  Estudios apuntan a que más del 60% de la fallas en los proyectos de software en los Estados Unidos, se deben a una pobre definición de requisitos.  La gestión de requisitos es una parte importante de una organización que desarrolla sus propios proyectos de software, puesto que es vital para reducir los riesgos inherentes a ellos.  La Ingeniería de Requisitos es el proceso de descubrir, analizar, documentar y verificar los servicios proporcionados por el sistema y sus restricciones operativas.

 La Ingeniería de Requisitos también puede ser vista como una actividad de “Ingeniería” y “Gestión”; porque es concerniente con la identificación de metodologías apropiadas para desarrollar soluciones de software bajo unos costos que sean apropiados para su implementación.

REQUISITOS Y CLASIFICACIÓN  Los requisitos pueden ser considerados como las funcionalidades y/o servicios proporcionados por el sistema y sus restricciones operativas.  En otra aproximación, los requisitos son una colección de necesidades provenientes del usuario y otros stakeholders.

TIPOS DE REQUISITOS

MODELOS DE INGENIERÍA DE SOFTWARE  Modelo de Pohl

 Elicitación: buscar formas explícitas el conocimiento oculto sobre las necesidades de clientes y usuarios y el sistema a desarrollar, de manera que todos los stakeholders sean capaces de entenderlo.  Negociación: busca alcanzar acuerdos y/o entendimientos entre todos los participantes sobre los requisitos propuestos en la fase anterior.  Especificación/Documentación de requisitos: busca documentar los requisitos documentados y elicitados, utilizando varias notaciones, con el fin de ser lo más explícito posible.  Validación/Verificación de requisitos: busca que los requisitos documentados corresponden con las necesidades de los clientes y usuarios (validación) y comprobará que la especificación cumple los criterios de calidad oportunos (verificación).

MODELO ESPIRAL

 Haciendo la comparativa con el modelo de Pohl, la obtención de requerimientos equivale a las actividades de elicitación y negociación, la especificación de requerimientos a la especificación y documentación de requisitos, y la validación de requerimientos con la validación y la verificación

MODELO SWEBOK

MODELO BORLAND

GESTIÓN DE REQUISITOS  La gestión de los requisitos implica establecer un entendimiento compartido entre los stakeholders (personas relacionadas con el proyecto) y los requisitos que ellos han especificado para ser incluidos en el producto de software

 En la fase de Elicitación, especificación y modelamiento: implica comprender las necesidades de los stakeholders, los requisitos elicitados, modelados y agruparlos en un repositorio o base de datos.  Priorización: esta actividad asiste a los Gerentes de Proyectos en la resolución de conflictos, relacionados con determinar la importancia de los requisitos determinados.  Análisis del Impacto y Dependencias de los requisitos: se enfoca en la importancia de los cambios que pueden tener los requisitos y el impacto en el proyecto de software.  Negociación de los requisitos: la Ingeniería de Requisitos es esencialmente un proceso complejo de comunicación y negociación que involucra a clientes, diseñadores, Gerentes de Proyectos y Administradores. En muchas situaciones el conflicto es inherente en los requisitos, por lo que hay necesidad de negociar entre los stakeholders.  Aseguramiento de la calidad: el propósito es asegurar que los requisitos con alto nivel de calidad, sean incluidos en el documento de especificación de requisitos.

BUENAS PRÁCTICAS EN LA ESPECIFICACIÓN DE REQUISITOS  Una buena gestión de requisitos va a facilitarse, si desde las primeras actividades de la Ingeniería de Requisitos, se tienen en cuenta recomendaciones aceptadas por la comunidad de Ingeniería de Software, como lo son las promulgadas por la IEEE para la especificación de requisitos (IEEE Std ).

 Correcta.  No ambigua.  Completa.  Fácil de verificar.  Consistente (coherente).  Clasificada por importancia y estabilidad.  Fácil de modificar.  Fácil identificación del origen de las consecuencias de cada requisito (Trazabilidad).  De fácil utilización durante la fase de explotación y de mantenimiento.

CONCLUSIONES  La Ingeniería de Requisitos ha surgido para gestionar eficientemente esta importante etapa de la Ingeniería de Software, debido a que es muy frecuente la presencia de no conformidades en los requerimientos obtenidos mediante esta fase.

4.1 MODELADO DE PRUEBAS UML  ¿Qué es UML? Lenguaje Unificado de Modelado pre escribe un conjunto de notaciones y diagramas estándar para modelar sistemas orientados a objetos, y describe la semántica esencial de lo que estos diagramas y símbolos significan.  UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales se pueden modelar sistemas.

 Diagramas de Casos de Uso para modelar los procesos ’business’.  Diagramas de Secuencia para modelar el paso de mensajes entre objetos.  Diagramas de Colaboración para modelar interacciones entre objetos.  Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.  Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.  Diagramas de Clases para modelar la estructura estática de las clases en el sistema.  Diagramas de Objetos para modelar la estructura estática de los objetos en el sistema.  Diagramas de Componentes para modelar componentes.  Diagramas de Implementación para modelar la distribución del sistema.

MODELOS DE PRUEBA

MODELOS PARA LA GENERACIÓN DE PRUEBAS.