La Ingeniería de Requerimientos
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.
El análisis de requerimientos
establece el proceso de definición de requerimientos como una serie de tareas o
actividades mediante las cuales se busca ganar conocimientos relevantes del
problema, que se utilizarán para producir una especificación formal del
software necesario para resolverlo. En este proceso se deben conciliar
diferentes puntos de vista y utilizar una combinación de métodos, personas y
herramientas. El resultado final constituye la documentación de los
requerimientos. Éstos deben expresarse de forma clara y estructurada de manera
que puedan ser entendidos tanto por expertos como por el usuario, quien deberá
participar en la validación.
El proceso del establecimiento de
requerimientos de un sistema de software es el primer paso esencial en entregar
lo que el cliente desea. Entre los métodos conocidos se puede citar a los
siguientes:
1. Reconocimiento
del problema: Se deben de estudiar inicialmente las especificaciones del
sistema y el plan del proyecto del software. Realmente se necesita llegar a
comprender el software dentro del contexto del sistema. El analista debe
establecer un canal adecuado de comunicación con el equipo de trabajo
involucrado en el proyecto. En esta etapa la función primordial del analista en
todo momento es reconocer los elementos del problema tal y como los percibe el
usuario.
2. Evaluación
y síntesis: En esta etapa el analista debe centrarse en el flujo y estructura
de la información, definir las funciones del software, determinar los factores
que afectan el desarrollo de nuestro sistema, establecer las características de
la interfaz del sistema y descubrir las restricciones del diseño. Todas las
tareas anteriores conducen fácilmente a la determinación del problema de forma
sintetizada.
3. Modelización:
Durante la evaluación y síntesis de la solución, se crean modelos del sistema
que servirán al analista para comprender mejor el proceso funcional, operativo
y de contenido de la información. El modelo servirá de pilar para el diseño del
software y como base para la creación de una especificación del software.
4. Especificación:
Las tareas asociadas con la especificación intentan proporcionar una
representación del software. Esto más adelante permitirá llegar a determinar si
se ha llegado a comprender el software, en los casos que se lleguen a modelar
se pueden dejar plasmados manuales.
5. Revisión:
Una vez que se han descrito la información básica, se especifican los criterios
de validación que han de servir para demostrar que se ha llegado a un buen
entendimiento de la forma de implementar con éxito el software. La
documentación del análisis de requerimientos y manuales, permitirán una
revisión por parte del cliente, la cual posiblemente traerá consigo
modificaciones en las funciones del sistema por lo que deberán revisare el plan
de desarrollo y las estimaciones previstas inicialmente.
5.
Técnicas
La ingeniería de requisitos puede
ser un proceso largo y arduo para el que se requiere de habilidades
psicológicas. Los nuevos sistemas cambian el entorno y las relaciones entre la
gente, así que es importante identificar a todos los actores involucrados,
considerar sus necesidades y asegurar que entienden las implicaciones de los
nuevos sistemas. Los analistas pueden emplear varias técnicas para obtener los
requisitos del cliente. Históricamente, esto ha incluido técnicas tales como
las entrevistas, o talleres con grupos para crear listas de requisitos.
Técnicas más modernas incluyen los prototipos, y utilizan casos de uso. Cuando
sea necesario, el analista empleará una combinación de estos métodos para
establecer los requisitos exactos de las personas implicadas, para producir un
sistema que resuelva las necesidades del negocio
·
Entrevistas: Las entrevistas son un método
común. Por lo general no se entrevista a toda la gente que se relacionará con
el sistema, sino a una selección de personas que represente a todos los sectores
críticos de la organización, con el énfasis puesto en los sectores más
afectados o que harán un uso más frecuente del nuevo sistema.
·
Talleres: Los requisitos tienen a menudo
implicaciones cruzadas desconocidas para las personas implicadas individuales y
que a menudo no se descubren en las entrevistas o quedan incompletamente
definidas durante la misma. Estas implicaciones cruzadas pueden descubrirse
realizando en un ambiente controlado, talleres facilitados por un analista del
negocio, en donde las personas implicadas participan en discusiones para
descubrir requisitos, analizan sus detalles y las implicaciones cruzadas. A
menudo es útil la selección de un secretario dedicado a la documentación de la
discusión, liberando al analista del negocio para centrarse en el proceso de la
definición de los requisitos y para dirigir la discusión.
Existen dos
técnicas de este tipo que son las más utilizadas: Brainstorming (Lluvia de
ideas) y JAD (Joint Application Development, Diseño de Aplicación Conjunta). La
diferencia que existe entre ambas técnicas es que durante la tormenta de ideas
se tiene como objetivo generar una gran cantidad de ideas, es desestructurada y
la información que se obtiene puede ser visual, textual o coloquial; mientras
que en el JAD el taller es ordenado, la información que se obtiene es visual y
su objetivo es generar requisitos y la interfaz del sistema.
Durante una
sesión de Lluvia de ideas, todos los participantes pueden aportar distintas
ideas en un ambiente libre de prejuicios. Ningún participante debe juzgar
negativamente la propuesta de otros, sino que se anotan todas las ideas en una
pizarra y serán evaluadas al final de la sesión. El principio básico es no
descartar de manera apresurada ningún planteo, de modo que existe la posibilidad
de que surjan otras ideas derivadas de la idea original y se generan varios
puntos de vista del problema.
En el Joint
application development se trabaja directamente sobre los documentos a generar,
las temáticas que se tratan durante las reuniones siguen un esquema y se busca
que la misma sea ordenada y racional. Se define una agenda con los puntos
principales a tratar durante la jornada. Este tipo de taller tiene el
inconveniente de que es muy difícil poder reunir a todos los participantes, es
costoso y generalmente es necesaria más de una reunión para establecer los
requisitos del sistema.
·
Forma de contrato: En lugar de una entrevista,
se pueden llenar formularios o contratos indicando los requisitos. En sistemas
muy complejos éstos pueden tener centenares de páginas.
Objetivos
medibles Los requisitos formulados por los usuarios se toman como objetivos
generales, a largo plazo, y en cambio se los debe analizar una y otra vez desde
el punto de vista del sistema hasta determinar los objetivos críticos del
funcionamiento interno que luego darán forma a los comportamientos apreciables
por el usuario. Luego, se establecen formas de medir el progreso en la
construcción, para evaluar en cualquier momento qué tan avanzado se encuentra
el proyecto.
·
Prototipos u casos de uso: Un prototipo es una
pequeña muestra, de funcionalidad limitada, de cómo sería el producto final una
vez terminado. Ayudan a conocer la opinión de los usuarios y rectificar algunos
aspectos antes de llegar al producto terminado.
Un caso de uso es
una técnica para documentar posibles requisitos, graficando la relación del
sistema con los usuarios u otros sistemas. Dado que el propio sistema aparece
como una caja negra, y sólo se representa su interacción con entidades
externas, permite omitir dichos aspectos y determinar los que realmente
corresponden a las entidades externas. El objetivo de esta práctica es mejorar
la comunicación entre los usuarios y los desarrolladores, mediante la prueba
temprana de prototipos para minimizar cambios hacia el final del proyecto y
reducir los costes finales. Esta técnica se enfrenta a los siguientes peligros
potenciales.
Ø
A los directivos, una vez que ven un prototipo,
les cuesta comprender que queda mucho trabajo por hacer para completar el
diseño final.
Ø
Los diseñadores tienden a reutilizar el código
de los prototipos por temor a “perder el tiempo” al comenzar otra vez.
Ø
Los prototipos ayudan principalmente a las
decisiones del diseño y de la interfaz de usuario. Sin embargo, no proporcionan
explícitamente cuáles son los requisitos.
Ø
Los diseñadores y los usuarios finales pueden
centrarse demasiado en el diseño de la interfaz de usuario y demasiado poco en
producir un sistema que sirva el proceso del negocio.
Los prototipos
pueden ser: diagramas, aplicaciones operativas con funcionalidades
sintetizadas. Los diagramas, en los casos donde se espera que el software final
tenga diseño gráfico, se realizan en una variedad de documentos de diseño
gráficos y a menudo elimina todo el color del diseño del software (es decir
utilizar una gama de grises). Esto ayuda a prevenir la confusión sobre la
apariencia final de la aplicación.
|
Actividades de la Ingeniería
de requerimientos para diferentes modelos de ingeniería de software
|
|||||
|
Modelo
|
Oliver and Steiner
1996
|
EIA / IS-632
|
IEEE estándar 1220-
1994
|
CMM nivel Repetitivo
|
RUP
|
|
Actividades
|
Evaluar la
información disponible
|
Análisis de
requerimientos
|
Análisis de
Requerimientos
|
Identificación de
requerimientos
|
Análisis del
Problema
|
|
Definir métricas
efectivas
|
Análisis funcional
|
Estudio de los
requerimientos
|
Identificación de
restricciones del sistema a desarrollar
|
Comprender las
necesidades de los involucrados
|
|
|
Crear un modelo del
comportamiento del sistema
|
Síntesis
|
Validación de
requerimientos
|
Análisis de los
requerimientos
|
Definir el sistema
|
|
|
Crear un modelo de
los objetos
|
Análisis funcional
|
Representación de
los requerimientos
|
Analizar el alcance
del proyecto
|
||
|
Ejecutar el análisis
|
Evaluación y estudio
de funciones
|
Comunicación de los
requerimientos
|
Modificar la
definición del sistema
|
||
|
Verificación de
funciones
|
Validación de
requerimientos
|
Administrar los
cambios de requerimientos
|
|||
|
Síntesis
|
|||||
|
Verificación física
|
|||||
|
Control
|
|||||
No hay comentarios:
Publicar un comentario