Universidad Nacional Experimental de Caracas UNEXCA
Programa Nacional de Formación Ingeniería Informática PNFI
Unidad curricular Ingeniería del software II - Código ISC339
Trimestre II - Tema 2 : Métodos y actividades de IR
2. MÉTODO WATCH
02
Marco metodológico que describe, en
términos generales, un conjunto
estructurado de actividades necesarias
para producir una aplicación
empresarial. Este modelo organiza
estas actividades en dos tipos de
procesos diferentes pero
complementarios, a saber: procesos
gerenciales y procesos de desarrollo.
Método WATCH, versión 2004. Ph.D. Jonás A.
Montilva. ULA. Mérida. Derechos reservados.
3. 03
Los procesos gerenciales describen las
actividades que el área de proyecto debe
realizar para controlar el proyecto de
desarrollo de un sistema y asegurar la calidad
del prodcuto de sofware empresarial.
Los procesos de desarrollo son los procesos
técnicos que describen que debe hacer el
grupo de desarrollo para producir una
aplicación empresarial. Estos procesos se
organizan en una estructura jerárquica
formada por fases, pasos y actividades.
Método WATCH, versión 2004. Ph.D. Jonás A.
Montilva. ULA. Mérida. Derechos reservados.
MÉTODO WATCH
4. FASE 2: IR
04
Objetivo: Determinar las necesidades de información y
automatización de procesos de negocios, que tienen los usuarios
de la aplicación, mediante la definición y especificación de sus
requisitos.
Método WATCH, versión 2004. Ph.D. Jonás A. Montilva. ULA. Mérida. Derechos reservados.
6. ACTIVIDADES IR
03
Según el método Watch (Montilva 2004),
en IR existen 5 actividades básicas que
se tienen que llevar a cabo para
completar el proceso, a saber:
descubrimiento, análisis, especificación,
validación y gestión de requisitos.
Estas actividades ayudan a convertir las
necesidades y requerimientos de los
usuarios en un producto gestionado
llamado "requisitos“, siendo este
proceso, lo más idóneo para continuar el
desarrollo de un software.
7. ACTIVIDAD #1 DESCUBRIMIENTO
DE REQUISITOS
Representa el comienzo del proceso IR y se centra en la extracción de
los requisitos dado los requerimientos del usuario. En esta actividad, el
Ingeniero de requisitos trabaja junto al usuario para descubrir el
problema que el sistema debe resolver, los diferentes servicios que el
sistema debe prestar, las restricciones que se pueden presentar, entre
otros. Es importante que esta actividad sea efectiva, ya que la
aceptación del producto de software depende de lo bien que éste
satisfaga las necesidades del usuario.
07
Establecer objetivos;
Entender el dominio;
Organizar el conocimiento;
Recolectar requerimientos.
Dentro de esta actividad, se considera:
1.
2.
3.
4.
8. ACTIVIDAD #2
ANÁLISIS DE REQUISITOS
08
Descubrir problemas con los requisitos del sistema identificados
hasta el momento. Usualmente se hace un análisis luego de
haber producido un bosquejo inicial del ERS. En esta etapa se
leen los requisitos, se conceptúan, se investigan, se
intercambian ideas con el resto del equipo, se resaltan los
problemas, se buscan alternativas y soluciones y luego se van
fijando reuniones con el cliente para discutir los requisitos.
Clasificación de requisitos
Negociación de requsitos
Modelado del problema
Diseño inicial de la aplicación
Dentro de esta actividad, se considera:
1.
2.
3.
4.
9. ACTIVIDAD #3
ESPECIFICACIÓN DE REQUISITOS
09
Se documentan los requisitos acordados con el usuario, en un nivel
apropiado de detalle. En la práctica, esta actividad se va realizando
conjuntamente con el análisis de requisitos y 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 ello, los casos de uso y la obtención de
requisitos basada en casos de uso, se utiliza cada vez más y se genera la
especificación de los casos de uso ECU por separado como una práctica de
entrega iterativa.
Definición del tipo, estructura y contenido de la ERS
Elaboración de la ERS
Elaboración de la ECU
Dentro de esta actividad, se considera:
1.
2.
3.
10. 10
ACTIVIDAD #4
VALIDACIÓN DE REQUISITOS
Ratifica y verifica que todos los requisitos que aparecen en
el ERS y ECU, sean consistentes y completos, para
asegurarse que representan una descripción aceptable del
sistema que se va a implementar. Normalmente esta
actividad es realizada por el equipo de aseguramiento y
control de calidad, en conjunto con el usuario, el
modelador del negocio y el ingeniero de requisitos.
Validar la ERS y las ECU´s.
Validar estándares de calidad.
Validar conocimiento del negocio a través de los modelos.
Validar funcionalidades.
Dentro de esta actividad, se considera:
1.
2.
3.
4.
11. 11
ACTIVIDAD #5
GESTIÓN DE REQUISITOS
Administrar los requisitos a través del control de cambio. En
esta actividad se chequea ¿quién propuso el requisito?
¿porqué existe? ¿qué relación tiene un requisito con otros
requisitos? y ¿qué relación tiene un requisito con los
entregables de ingeniería de software?
Gestión de almacenamiento de requisitos.
Gestión de cambios.
Rastreo de requisitos.
Dentro de esta actividad, se considera:
1.
2.
3.
12. Entrevistas y cuestionarios
Casos de uso
Prototipos
Análisis de sistemas existentes
Lluvia de ideas (Brainstorm)
Plantilla Volerer (MetodoWatch)
Herramientas automatizadas (RequisitePro
IBM Rational)
TÉCNICAS DE
IDENTIFICACIÓN Y
ANÁLISIS DE REQUISITOS
12
13. CONSIDERACIONES FINALES
13
Desarrolle IR con estricta disciplina.
Tenga un concepto claro que represente de la
mejor manera los requerimientos del usuario.
Recuerde que el método para hacer ingeniería de
requisitos, más que una herramienta, es un
apoyo.
Ingeniería de requisitos ayuda al equipo de
Ingeniería del software a identificar, controlar y
rastrear los requisitos y cambios en cualquier
momento del desarrollo de software, mediante un
enfoque iterativo.
1.
2.
3.
4.