UNIDAD II: INGENIERÍA DE REQUISITOS
2.1.- TAREAS DE LA INGENIERÍA DE REQUISITOS
La
Ingeniería de requerimientos se entiende como el proceso de descubrimiento y
comunicación de las necesidades de clientes y usuarios y la gestión de los
cambios de dichas necesidades. La
ingeniería de requerimientos del software es un proceso de búsqueda,
refinamiento, modelado y especificación donde se toman como base requisitos de
datos, flujo de información y control, y de comportamiento operativo.
Como
menciona Goguen, uno de los aspectos más importantes de la ingeniería de
requerimientos es la comunicación, característica ésta que vuelve el proceso
complejo por la alta presencia del factor humano que contiene y es la
responsable de que la disciplina contenga aspectos sociales y culturales y no
sólo de índole técnica.
.
Tipos
de requerimientos
Estos
pueden dividirse en 2 categorías: requerimientos funcionales y requerimientos
no funcionales.
Los requerimientos
funcionales: son los que definen las funciones que el sistema
será capaz de realizar, describen las transformaciones que el sistema realiza
sobre las entradas para producir salidas. Es importante que se describa el
¿Qué? y no el ¿Cómo? se deben hacer esas transformaciones. Estos requerimientos
al tiempo que avanza el proyecto de software se convierten en los algoritmos,
la lógica y gran parte del código del sistema.
Los requerimientos
no funcionales: son
características que de una u otra forma puedan limitar el sistema, por ejemplo,
el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad
(robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, potabilidad, etc.
Aunque
los requerimientos pueden cambiar a lo largo del proyecto se pueden generar
errores. El desarrollador
debe comprender el contexto que envuelve el negocio tal como el cliente lo ve.
Un panorama correcto en fases tempranas del desarrollo minimiza la ocurrencia
de errores y mitiga el impacto que pueden introducir los cambios.
Importancia
de la definición de de requerimientos
El
hecho de omitir métodos, procesos o herramientas propuestas por la ingeniería
de requerimientos genera fallas en la comunicación entre clientes y analistas;
etapas, actividades y documentos sin clara de limitación conceptual, escasa
reutilización y problemas de gestión, afectando negativamente la calidad del
producto, los costos y el tiempo de desarrollo.
2.2.- TÉCNICAS DE LA INGENIERÍA DE
REQUISITOS
Como se menciono anteriormente, la
ingeniería de requerimientos sirve como una base sólida en el proceso de
desarrollo de software, por lo que antes de pasar a tratar los aspectos
referentes a la administración adecuada de los requerimientos, es importante
primero definir lo que es un requerimiento y cuales serían las características
deseables que deberían de tener.
Tipos de Requerimientos
Los requerimientos de software pueden
dividirse en 2 categorías: requerimientos funcionales y requerimientos no
funcionales.
Los requerimientos funcionales son los que
definen las funciones que el sistema será capaz de realizar, describen las
transformaciones que el sistema realiza sobre las entradas para producir
salidas.
Características de un Requerimiento
Es importante no perder de vista que un
requerimiento debe ser:
Especificado
por escrito: Como todo contrato o acuerdo entre dos partes.
Posible
de probar o verificar.Si un requerimiento no se puede comprobar, entonces ¿cómo
se
sabe si se cumplió con él o no?
Conciso: Un requerimiento es conciso si es
fácil de leer y entender. Su redacción debe ser simple
y clara para aquellos que vayan a
consultarlo en un futuro.
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.
No
ambiguo: Un requerimiento no es
ambiguo cuando tiene una sola interpretación. El lenguaje
usado en su definición, no debe causar
confusiones al lector.
Dificultades para definir los
requerimientos
Durante la etapa de especificación de
requerimientos se pueden presentar muchos inconvenientes los cuales son
importantes de identificar y prevenir, a continuación se presenta un listado
con los problemas más comunes en este proceso:
Los requerimientos no son obvios y
vienen de muchas fuentes.
Son difíciles de expresar en
palabras (el lenguaje es ambiguo).
La cantidad de requerimientos en un
proyecto puede ser difícil de manejar.
Un requerimiento puede cambiar a lo
largo del ciclo de desarrollo.
El usuario no puede explicar lo que
hace
Tiende a recordar lo excepcional y
olvidar lo rutinario
Hablan de lo que no funciona
Los usuarios tienen distinto
vocabulario que los desarrolladores.
Actividades de la ingeniería de
requerimientos
Dentro del mismo documento mencionado
anteriormente (Herrera, 2003: 6), se dice que dentro de la IR existen cuatro
actividades básicas que se tienen que llevar a cabo para completar el proceso.
Estas actividades ayudan a reconocer la importancia que tiene para el
desarrollo de un proyecto de software realizar una especificación y
administración adecuada de los requerimientos de los clientes o usuarios.
Las cuatro actividades son: extracción,
análisis, especificación y validación, y serán explicadas a continuación cada
una de ellas.
Extracción
Esta fase representa el comienzo de cada
ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en
el descubrimiento de los requerimientos del sistema. Aquí, los analistas de
requerimientos deben trabajar junto al cliente para descubrir el problema que
el sistema debe resolver, los diferentes servicios que el sistema debe prestar,
las restricciones que se pueden presentar, etc. Es importante, que la
extracción sea efectiva, ya que la aceptación del sistema dependerá de cuan
bien éste satisfaga las necesidades del cliente.
Análisis
Sobre la base de la extracción realizada
previamente, comienza esta fase en la cual se enfoca en descubrir problemas con
los requerimientos del sistema identificados hasta el momento.
Usualmente se hace un análisis luego de
haber producido un bosquejo inicial del documento de requerimientos; en esta
etapa se leen los requerimientos, 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 requerimientos.
Especificación
En esta fase se documentan los
requerimientos acordados con el cliente, en un nivel apropiado de detalle.
Técnicas utilizadas en las actividades de
IR
Existen varias técnicas para la IR
propuestas para ingeniería de requerimientos (Herrera, 2003: 12), y delas
cuales en este artículo solo se abarcarán cinco de ellas. Es importante
resaltar que estas técnicas pueden ser aplicables a las distintas fases del
proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las
características propias del proyecto en particular que se este desarrollándose
para aprovechar al máximo su utilidad.
Entrevistas y Cuestionarios
Las entrevistas y cuestionarios se emplean
para reunir información proveniente de personas o de grupos.Durante la
entrevista, el analista conversa con el encuestado; el cuestionario consiste en
una serie de preguntas relacionadas con varios aspectos de un sistema.
Sistemas existentes
Esta técnica consiste en analizar
distintos sistemas ya desarrollados que estén relacionados con el sistema a ser
construido. Por un lado, podemos analizar las interfaces de usuario, observando
el tipo de información que se maneja y cómo es manejada, por otro lado también
es útil analizar las distintas salidas que los sistemas producen (listados,
consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de
estas.
Lluvia de ideas (Brainstorm)
Este es un modelo que se usa para generar
ideas. La intención en su aplicación es la de generar la máxima cantidad posible
de requerimientos para el sistema. No hay que detenerse en pensar si la idea
eso no del todo utilizable. La intención de este ejercicio es generar, en una
primera instancia, muchas ideas.
Prototipos
Durante la actividad de extracción de
requerimientos, puede ocurrir que algunos requerimientos no estén demasiado
claros o que no se esté muy seguro de haber entendido correctamente los
requerimientos obtenidos hasta el momento, todo lo cual puede llevar a un
desarrollo no eficaz del sistema final.
Casos de Uso
Los casos de uso son una técnica para
especificar el comportamiento de un sistema. El sitio en Internet wikipedia.org,
define a un caso de uso.
2.3.- MODELADO DE REQUISITOS
El modelo de requisitos tiene como
objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer
desde la perspectiva del usuario. Este modelo puede funcionar como un contrato
entre el desarrollador y el cliente o usuario del sistema, y por lo tanto
proyecta lo que el cliente desea según la percepción del desarrollador. Por lo
tanto, es esencial que los clientes puedan comprender este modelo.
Requisitos: El modelo de casos de uso sirve para
expresar el modelo de requisitos, el cual se desarrolla encooperación con otros
modelos como se verá más adelante.
Análisis: La funcionalidad especificada por el modelo de casos de
uso se estructura en el modelo de análisis,que es estable con respecto a
cambios, siendo un modelo lógico independiente del ambiente de implementación.
Diseño: La funcionalidad de los casos de uso ya estructurada por
el análisis es realizada por el modelo de
diseño, adaptándose al ambiente de
implementación real y refinándose aún más.
Implementación: Los casos de uso son implementados
mediante el código fuente en el modelo de implementación.
Pruebas: Los casos de uso son probados a través de las pruebas de
componentes y pruebas de integración.
Documentación: El modelo de casos de uso debe ser
documentado a lo largo de las diversas actividades, dando lugar a distintos
documentos como los manuales de usuario, manuales de administración, etc.
Descripción del Problema
La descripción del problema es una
descripción muy preliminar de necesidades que sirve únicamente como punto de
inicio para comprender los requisitos del sistema. Se trata aquí de simular una
descripción preparada por un cliente la cual debe evolucionar por medio del
modelo de requisitos para lograr la especificación final del sistema a
desarrollarse. La descripción del problema debe ser una descripción de
necesidades y no una propuesta para una solución. La descripción inicial puede
ser incompleta e informal. No hay razón para esperar que la descripción inicial
del problema, preparada sin un análisis completo, sea correcta.
2.4.- HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS
Las herramientas CASE (Computer Aided
Software Engineering, Ingeniería de Software Asistida por Computadora) son
diversas aplicaciones informáticas destinadas a aumentar la productividad en el
desarrollo de software reduciendo el coste de las mismas en términos de tiempo
y de dinero.
También se puede definir como:
Conjunto de métodos, utilidades y técnicas
que facilitan la automatización del ciclo de vida del desarrollo de sistemas de
información, completamente o en alguna de sus fases.
Clasificación de las Herramientas CASE
No existe una única clasificación de
herramientas CASE y, en ocasiones, es difícil incluirlas en una clase
determinada. Podrían clasificarse atendiendo a:
• Las plataformas que soportan.
• Las fases del ciclo de vida del
desarrollo de sistemas que cubren.
• La arquitectura de las aplicaciones que
producen.
• Su funcionalidad.
Componentes y funcionalidades de una
Herramienta CASE
Módulos de diagramación y modelización
Algunos de los diagramas y modelos
utilizados con mayor frecuencia son:
• Diagrama de flujo de datos.
• Modelo entidad - interrelación.
• Historia de la vida de las entidades.
• Diagrama Estructura de datos.
• Diagrama Estructura de cuadros.
• Técnicas matriciales.
Algunas características referentes a los
diagramas son:
• Número máximo de niveles para poder
soportar diseños complejos.
• Número máximo de objetos que se pueden
incluir para no encontrarse limitado
• en el diseño de grandes aplicaciones.
• Número de diagramas distintos en
pantalla o al mismo tiempo en diferentes ventanas.
• Dibujos en formato libre con la
finalidad de añadir comentarios, dibujos, información adicional para aclarar
algún punto concreto del diseño.
• Actualización del repositorio por
cambios en los diagramas. Siempre resulta más fácil modificar de forma gráfica
un diseño y que los cambios queden reflejados en el repositorio.
Herramientas Case
• Control sobre el tamaño, fuente y
emplazamiento de los textos en el diagrama.
• Comparaciones entre gráficos de
distintas versiones.De esta forma será más fácil identificar qué diferencias
existen entre las versiones.
Herramienta de prototipado
El objetivo principal de esta herramienta
es poder mostrar al usuario, desde los momentos iniciales del diseño, el
aspecto que tendrá la aplicación una vez desarrollada.Ello facilitará la
aplicación de los cambios que se consideren necesarios, todavía en la fase de
diseño.
Actualmente, es imprescindible utilizar
productos que incorporen esta funcionalidad por la cambiante tecnología y
necesidades de los usuarios. Los prototipos han sido utilizados ampliamente en
el desarrollo de sistemas tradicionales, ya que proporcionan una realimentación
inmediata, que ayudan a determinar los requisitos del sistema.
Generador de código
Normalmente se suele utilizar sobre
ordenadores personales o estaciones de trabajo, por lo que el paso posterior
del código al host puede traer problemas, al tener que compilar en ambos
entornos.
Las características más importantes de los
generadores de código son:
• Lenguaje generado. Si se trata de un
lenguaje estándar o un lenguaje propietario.
• Portabilidad del código
generado.Capacidad para poder ejecutarlo en diferentes plataformas físicas y/o
lógicas.
• Generación del esqueleto del programa o
del programa completo.Si únicamente genera el esqueleto será necesario
completar el resto mediante programación.
• Posibilidad de modificación del código
generado.Suele ser necesario acceder directamente al código generado para
optimizarlo o completarlo.
Estructura general de una
herramienta case
La estructura CASE se basa en la siguiente
terminología:
• CASE de alto nivel son aquellas
herramientas que automatizan o apoyan las fases finales o superiores del ciclo
de vida del desarrollo de sistemas como la planificación de sistemas, el
análisis de sistemas y el diseño de sistemas.
• CASE de bajo nivel son aquellas
herramientas que automatizan o apoyan las fases finales o inferiores del ciclo
de vida como el diseño detallado de sistemas, la implantación de sistemas y el
soporte de sistemas.
• CASE cruzado de ciclo de vida se aplica
a aquellas herramientas que apoyan actividades que tienen lugar a lo largo de
todo el ciclo de vida, se incluyen actividades como la gestión de proyectos y
la estimación.
Biografia
Pressman, Roger S. 2006, “Ingeniería del Software: Un enfoque
práctico”, Sexta edición, México
DF, Editorial McGraw Hill.
Sommerville Ian, 2005, “Ingeniería del Software”, Sétima edición, México DF, Editorial Pearson
DF, Editorial McGraw Hill.
Sommerville Ian, 2005, “Ingeniería del Software”, Sétima edición, México DF, Editorial Pearson
Paginas Web
IEEE Std 610.12-1990, “IEEE Standard Glossary of Software
Engineering Terminology”,
recuperado el 24 de mayo de 2006 en:
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html
Herrera J., Lizka Johany (2003) “Ingeniería de Requerimientos, Ingeniería de Software”,
Recuperado el 25 de mayo de 2006 en: http://www.monografias.com/trabajos6/resof/resof.shtml
Montes Meyhuay Magno, “Ingeniería de Requerimientos”, recuperado el 25 de mayo de 2006 en:
www.proamazonia.gob.pe/bpa/ingenieria_requerimientos.htm
Organización Exactus, recuperado el 29 de mayo de 2006 en: www.exactus.com
recuperado el 24 de mayo de 2006 en:
http://standards.ieee.org/reading/ieee/std_public/description/se/610.12-1990_desc.html
Herrera J., Lizka Johany (2003) “Ingeniería de Requerimientos, Ingeniería de Software”,
Recuperado el 25 de mayo de 2006 en: http://www.monografias.com/trabajos6/resof/resof.shtml
Montes Meyhuay Magno, “Ingeniería de Requerimientos”, recuperado el 25 de mayo de 2006 en:
www.proamazonia.gob.pe/bpa/ingenieria_requerimientos.htm
Organización Exactus, recuperado el 29 de mayo de 2006 en: www.exactus.com
