Verificación y validación de sistemasjddiosvivar.files.wordpress.com/2014/06/3...3.10 FASE DE...
Transcript of Verificación y validación de sistemasjddiosvivar.files.wordpress.com/2014/06/3...3.10 FASE DE...
VERIFICACIÓN Y VALIDACIÓN DE
SISTEMAS
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. 830-1998).
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.