2. requerimientos del software
DESCRIPTION
TRANSCRIPT
REQUERIMIENTOS DEL SOFTWARE
INDICE
INTRODUCCION
REQUERIMIENTOS DEL SOFTWARE
CARACTERÍSTICAS DE LOS REQUERIMIENTOS
DIFICULTADES PARA DEFINIR LOS REQUERIMIENTOS
CARACTERÍSTICAS DE UN REQUERIMIENTO
FUNDAMENTOS DEL ANÁLISIS DE REQUERIMIENTOS
TAREAS DEL ANÁLISIS
ESPECIFICACIÓN DE REQUISITOS DE SOFTWARE (SRS)
CLASIFICACIÓN DE LOS REQUERIMIENTOS
ACTIVIDADES DE LA INGENIERÍA DE REQUERIMIENTOS
PRINCIPIOS DE ESPECIFICACIÓN
MANEJO DE REQUERIMIENTOS
ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO
REQUERIMIENTOS DEL SISTEMA
ESTRATEGIA DEL FLUJO DE DATOS
ESTRATEGIA DEL ANÁLISIS DE DECISIONES
ETAPAS EN LA ESTRATEGIA DEL ANÁLISIS DEL FLUJO DE DATOS
UTILIZACIÓN DE LOS DATOS DE REQUERIMIENTOS
DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE
MÉTODOS DE ANÁLISIS ORIENTADOS AL FLUJO DE DATOS
DIAGRAMAS DE FLUJOS DE DATOS
DICCIONARIO DE DATOS
DESCRIPCIONES FUNCIONALES
MÉTODOS ORIENTADOS A LA ESTRUCTURA DE DATOS
BIBLIOGRAFÍA
ESPECIFICACIÓN DE LOS REQUERIMIENTOS DEL SOFTWARE
INTRODUCCION
¿Qué son Requerimientos?
Normalmente, un tema de la Ingeniería de Software tiene diferentes
significados. De las muchas definiciones que existen para requerimiento, ha
continuación se presenta la definición que aparece en el glosario de la IEEE:
(1) Una condición o necesidad de un usuario para resolver un problema o
alcanzar un objetivo.
(2) Una condición o capacidad que debe estar presente en un sistema o
componentes de sistema para satisfacer un contrato, estándar,
especificación u otro documento formal.
(3) Una representación documentada de una condición o capacidad como
en (1) o (2).
Los requerimientos puedes dividirse en requerimientos funcionales y
requerimientos no funcionales.
Los requerimientos funcionales definen las funciones que el sistema será
capaz de realizar. Describen las transformaciones que el sistema realiza sobre
las entradas para producir salidas.
Los requerimientos no funcionales tienen que ver con características que de
una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento
(en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,
etc.
Características de los requerimientos
Las características de un requerimiento son sus propiedades principales. Un
conjunto de requerimientos en estado de madurez, deben presentar una serie
de características tanto individualmente como en grupo. A continuación se
presentan las más importantes.
Necesario: Un requerimiento es necesario si su omisión provoca una
deficiencia en el sistema a construir, y además su capacidad, características
físicas o factor de calidad no pueden ser reemplazados por otras capacidades
del producto o del proceso.
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.
Verificable: Un requerimiento es verificable cuando puede ser cuantificado de
manera que permita hacer uso de los siguientes métodos de verificación:
inspección, análisis, demostración o pruebas.
* Dificultades para definir los requerimientos *
• Los requerimientos no son obvios y vienen de muchas fuentes.
• Son difíciles de expresar en palabras (el lenguaje es ambiguo).
• Existen muchos tipos de requerimientos y diferentes niveles de detalle.
• La cantidad de requerimientos en un proyecto puede ser difícil de manejar.
• Nunca son iguales. Algunos son más difíciles, más riesgosos, más
importantes o más estables que otros.
• Los requerimientos están relacionados unos con otros, y a su vez se
relacionan con otras partes del proceso.
• Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales
específicas.
• Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.
• Son difíciles de cuantificar, ya que cada conjunto de requerimientos es
particular para cada proyecto.
* Ingeniería de Requerimientos vs. Administración de Requerimientos *
El proceso de recopilar, analizar y verificar las necesidades del cliente para
un sistema es llamado Ingeniería de Requerimientos. La meta de la
ingeniería de requerimientos (IR) es entregar una especificación de requisitos
de software correcta y completa.
Los requerimientos son la Pieza fundamental en un proyecto de desarrollo de
software, es ellos se basan muchos participantes del proyecto para:
Planear el proyecto y los recursos que se usarán en él. Los líderes de proyecto
usan los requerimientos como una base para la estimación del esfuerzo
necesario en un proyecto.
Especificar el tipo de verificaciones que se habrán de realizar al sistema. Por
ejemplo: cuando se está tratando de alinearse a cierta norma oficial o estándar.
Planear la estrategia de prueba a la que habrá de ser sometido el sistema. Los
requerimientos son la base sobre la cual se decide si un caso de prueba fue
ejecutado exitosamente por el sistema o no.
Son el fundamento del ciclo de vida del proyecto. Los requerimientos
documentados son la base para crear la documentación del sistema
De ahí su importancia y la importancia de que deban de ser definidos y
manejados de la forma mas adecuada posible.
Características de un requerimiento
Ya que visualizamos la importancia de los requerimientos en un sistema de
software entonces debemos de definir que características deben de poseer los
requerimientos adecuadamente formulados.
Los requerimientos deben ser:
Especificados por escrito. Como todo contrato o acuerdo entre dos partes
Posibles de probar o verificar. Si un requerimiento no se puede comprobar,
entonces ¿cómo sabemos si cumplimos con él o no?
Descritos como una característica del sistema a entregar. Esto es: que es lo
que el sistema debe de hacer (y no como debe de hacerlo)
Lo más abstracto y conciso posible. Para evitar malas interpretaciones.
* Fundamentos del Análisis de Requerimientos *
Definición: Es el conjunto de técnicas y procedimientos que nos permiten
conocer los elementos necesarios para definir un proyecto de software.
Es la etapa más crucial del desarrollo de un proyecto de software.
La IEEE los divide en funcionales y no funcionales:
Funcionales: Condición o capacidad de un sistema requerida por el usuario
para resolver un problema o alcanzar un objetivo.
No Funcionales: Condición o capacidad que debe poseer un sistema para
satisfacer un contrato, un estándar, una especificación u otro documento
formalmente impuesto.
Para realizar bien el desarrollo de software es esencial realizar una
especificación completa de los requerimientos de los mismos.
Independientemente de lo bien diseñado o codificado que esté, un programa
pobremente especificado decepcionará al usuario y hará fracasar el desarrollo.
La tarea de análisis de los requerimientos es un proceso de
descubrimiento y refinamiento, El ámbito del programa, establecido
inicialmente durante la ingeniería del sistema, es refinado en detalle. Se
analizan y asignan a los distintos elementos de los programas las soluciones
alternativas.
Tanto el que desarrolla el software como el cliente tienen un papel activo
en la especificación de requerimientos. El cliente intenta reformular su
concepto, algo nebuloso, de la función y comportamiento de los programas en
detalles concretos, El que desarrolla el software actúa como interrogador,
consultor y el que resuelve los problemas.
El análisis y especificación de requerimientos puede parecer una tarea
relativamente sencilla, pero las apariencias engañan. Puesto que el contenido
de comunicación es muy alto, abundan los cambios por mala interpretación
o falta de información. El dilema con el que se enfrenta un ingeniero de
software puede ser comprendido repitiendo la sentencia de un cliente anónimo:
"Sé que crees que comprendes lo que piensas que he dicho, pero no
estoy seguro de que lo que creíste oír sea lo que yo quise decir".
Los requerimientos de un sistema de software, cuando se ven en su conjunto
son extensos y detallados, y además contienen múltiples relaciones entre sí. Lo
que nos da a concluir, que el conjunto de requerimientos de un sistema
computacional es complejo.
Obtenemos la posibilidad de especificar sistemas complejos al documentar
especificaciones simples y concisas para el sistema. Esto se logra mediante al
clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras
palabras al analizar sus requerimientos.
El análisis de requerimientos es la tarea que plantea la asignación de software
a nivel de sistema y el diseño de programas. El análisis de requerimientos
facilita al ingeniero de sistemas especificar:
la función y comportamiento de los programas,
indicar la interfaz con otros elementos del sistema y
establecer las ligaduras de diseño que debe cumplir el programa.
El análisis de requerimientos permite al ingeniero:
refinar la asignación de software y
representar el dominio de la información que será tratada por el
programa.
El análisis de requerimientos da al diseñador:
la representación de la información y
las funciones que pueden ser traducidas en datos, arquitectura y diseño
procedimental.
Finalmente, la especificación de requerimientos suministra al técnico y al
cliente:
los medios para valorar la calidad de los programas, una vez que se
haya construido.
* Tareas del Análisis *
El análisis de requerimientos puede dividirse en cuatro áreas:
1.- Reconocimiento del problema
2.- Evaluación y síntesis
3.- Especificación
4.- Revisión.
Inicialmente, el analista estudia la especificación del sistema (si existe) y el
plan de proyecto. Es importante comprender el contexto del sistema y
revisar el ámbito de los programas que se usó para generar las
estimaciones de la planificación. A continuación, debe establecerse la
comunicación necesaria para el análisis, de forma que se asegure el
reconocimiento del problema.
El analista debe establecer contacto con el equipo técnico y de gestión del
usuario / cliente y con la empresa que vaya a desarrollar el software. El
gestor del programa puede servir como coordinador para facilitar el
establecimiento de los caminos de comunicación. El objetivo del analista es
reconocer los elementos básicos del programa tal como lo percibe el
usuario / cliente.
La evaluación del problema y la síntesis de la solución es la siguiente
área principal de trabajo del análisis. El analista debe evaluar el flujo y
estructura de la información, refinar en detalle todas las funciones del
programa, establecer las características de la interfase del sistema y
descubrir las ligaduras del diseño, Cada una de las tareas sirven para
descubrir el problema de forma que pueda sintetizarse un enfoque o
solución global.
Las tareas asociadas con el análisis y especificación existen para dar una
representación del programa que pueda ser revisada y aprobada por el
cliente. En un mundo ideal el cliente desarrolla una especificación de
requerimientos del software completamente por sí mismo. Esto se presenta
raramente en el mundo real. En el mejor de los casos, la especificación se
desarrolla conjuntamente entre el cliente y el técnico.
Una vez que se hayan descrito las funcionalidades básicas,
comportamiento, interfase e información, se especifican los criterios de
validación para demostrar una comprensión de una correcta
implementación de los programas. Estos criterios sirven como base para
hacer una prueba durante el desarrollo de los programas. Para definir las
características y atributos del software se escribe una especificación de
requerimientos formal. Además, para los casos en los que se desarrolle
un prototipo se realiza un manual de usuario preliminar.
Puede parecer innecesario realizar un manual de usuario en una etapa tan
temprana del proceso de desarrollo, Pero de hecho, este borrador del
manual de usuario fuerza al analista a tomar el punto de vista del usuario
del software. El manual permite al usuario / cliente revisar el software
desde una perspectiva de ingeniería humana y frecuentemente produce el
comentario: "La idea es correcta pero esta no es la forma en que pensé
que se podría hacer esto". Es mejor descubrir tales comentarios lo más
tempranamente posible en el proceso.
Los documentos del análisis de requerimiento (especificación y manual de
usuario) sirven como base para una revisión conducida por el cliente y el
técnico. La revisión de los requerimientos casi siempre produce
modificaciones en la función, comportamiento, representación de la
información, ligaduras o criterios de validación. Además, se realiza una
nueva apreciación del plan del proyecto de software para determinar si las
primeras estimaciones siguen siendo validas después del conocimiento
adicional obtenido durante el análisis.
* Obteniendo de la información *
Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de
desarrollo de software, este entendimiento es necesario para poder
construir software que satisfaga las necesidades de nuestro cliente.
Si los requerimientos se enfocan a describir las necesidades del cliente,
entonces es lógico que para recabarlos haya que obtener la información de
primera mano. Esto es, mediante entrevistas con el cliente o recabando
documentación que describa la manera que el cliente desea que funcione
el sistema de software.
Las necesidades y / o requerimientos del cliente evolucionan con el tiempo
y cada cambio involucra un costo. Por eso es necesario tener archivada
una copia de la documentación original del cliente, así como cada revisión
o cambio que se haga a esta documentación. Como cada necesidad del
cliente es tratada de diferente forma, es necesario clasificar estas
necesidades para saber cuáles de ellas serán satisfechas por el software y
cuales por algún otro producto del sistema.
* Especificación de Requisitos de Software *(SRS)
La especificación de requisitos de software es la actividad en la cual se
genera el documento, con el mismo nombre, que contiene una descripción
completa de las necesidades y funcionalidades del sistema que será
desarrollado; describe el alcance del sistema y la forma en cómo hará sus
funciones, definiendo los requerimientos funcionales y los no funcionales.
En la SRS se definen todos los requerimientos de hardware y software,
diagramas, modelos de sistemas y cualquier otra información que sirva de
soporte y guía para fases posteriores.
Es importante destacar que la especificación de requisitos es el resultado
final de las actividades de análisis y evaluación de requerimientos; este
documento resultante será utilizado como fuente básica de comunicación
entre los clientes, usuarios finales, analistas de sistema, personal de
pruebas, y todo aquel involucrado en la implementación del sistema.
Los clientes y usuarios utilizan la SRS para comparar si lo que se está
proponiendo, coincide con las necesidades de la empresa. Los analistas y
programadores la utilizan para determinar el producto que debe
desarrollarse. El personal de pruebas elaborará las pruebas funcionales y
de sistemas en base a este documento. Para el administrador del proyecto
sirve como referencia y control de la evolución del sistema.
La SRS posee las mismas características de los requerimientos: completa,
consistente, verificable, no ambigua, factible, modificable, rastreable,
precisa, entre otras. Para que cada característica de la SRS sea
considerada, cada uno de los requerimientos debe cumplirlas; por ejemplo,
para que una SRS se considere verificable, cada requerimiento definido en
ella debe ser verificable; para que una SRS se considere modificable, cada
requerimiento debe ser modificable y así sucesivamente. Las
características de la SRS son verificadas en la actividad de Validación,
descrita en el punto.
La estandarización de la SRS es fundamental pues ayudará, entre otras
cosas, a facilitar la lectura y escritura de la misma. Será un documento
familiar para todos los involucrados, además de asegurar que se cubren
todos los tópicos importantes.
Existen plantillas creadas para la SRS, sin embargo, cada uno tiene la
potestad de crear su propia plantilla.
Clasificación de los requerimientos
El clasificar requerimientos es una forma de organizarlos, hay
requerimientos que por sus características no pueden ser tratados iguales.
La siguiente es una recomendación de como pueden ser clasificados los
requerimientos aunque cada proyecto de software pueda usar sus propias
clasificaciones.
• Requerimientos del "entorno"
El entorno es todo lo que rodea al sistema. Aunque no podemos cambiar el
entorno, existen cierto tipo de requerimientos que se clasifican en esta
categoría porque:
El sistema usa el entorno y lo necesita como una fuente de los servicios
necesarios para que funcione. Ejemplos del entorno podemos mencionar:
sistemas operativos, sistema de archivos, bases de datos.
El sistema debe de ser robusto y tolerar los errores que puedan ocurrir en
el entorno, tales como congestión en los dispositivos y errores de entrada
de datos, por lo tanto el entorno se debe de considerar dentro de los
requerimientos.
• Requerimientos ergonómicos"
Él más conocido de los requerimientos ergonómicos es la interfase con el
usuario o GUI (Graphic User Interface). En otras palabras, los
requerimientos ergonómicos son la forma en que el ser humano interactúa
con el ser sistema.
• Requerimientos de Interfase
La interfase es como interactúa el sistema con el ser humano o con otros
sistemas (el enfoque es prácticamente el opuesto a los requerimientos
ergonómicos), La interfase es la especificación formal de los datos que el
sistema recibe o manda al exterior. Usualmente se especifica el protocolo,
el tipo de información, el medio para comunicarse y el formato de los datos
que se van a comunicar.
* Actividades de la Ingeniería de Requerimientos *
En el proceso de IR son esenciales diversas actividades. En este
documento serán presentadas, sin embargo, en un proceso de ingeniería
de requerimientos efectivo, estas actividades son aplicadas de manera
continua y en orden variado.
Dependiendo del tamaño del proyecto y del modelo de proceso de software
utilizado para el ciclo de desarrollo, las actividades de la IR varían tanto en
número como en nombres. La tabla #1 muestra algunos ejemplos de las
actividades identificadas para cada proceso.
A pesar de las diferentes interpretaciones que cada desarrollador tenga
sobre el conjunto de actividades mostradas en la tabla anterior, podemos
identificar y extraer cinco actividades principales que son:
• Análisis del Problema
• Evaluación y Negociación
• Especificación
• Validación
• Evolución
* Principios de Especificación *
La especificación, independientemente del modo en que se realice, puede
ser vista como un proceso de representación. Los requerimientos se
representan de forma que conduzcan finalmente a una correcta
implementación del software.
Baltzer y Goldman proponen ocho principios para una buena
especificación:
PRINCIPIO #1. Separar funcionalidad de implementación.
Una especificación es una descripción de lo que se desea, en vez de cómo
se realiza (implementa). Las especificaciones pueden adoptar dos formas
muy diferentes. La primera forma es la de funciones matemáticas: dado
algún conjunto de entrada, producir un conjunto particular de salida. La
forma general de tales especificaciones es encontrar [un/el/todos] resultado
tal que P (entrada), donde P representa un predicado arbitrario. En tales
especificaciones, el resultado a ser obtenido ha sido expresado
enteramente en una forma sobre el que (en vez de cómo). En parte, esto
es debido a que el resultado es una función matemática de la entrada (la
operación tiene puntos de comienzo y parada bien definidos) y no está
afectado por el entorno que le rodea.
PRINCIPIO #2. Se necesita un lenguaje de especificación de sistemas
orientado al proceso.
Considerar una situación en la que el entorno sea dinámico y sus cambios
afecten al comportamiento de alguna entidad que interactúe con dicho
entorno. Su comportamiento no puede ser expresado como una función
matemática de su entrada. En vez de ello, debe emplearse una descripción
orientada al proceso, en la cual la especificación del que se consigue
mediante la especificación de un modelo del comportamiento deseado en
términos de respuestas funcionales, a distintos estímulos del entorno.
PRINCIPIO #3. Una especificación debe abarcar el sistema del cual el
software es una componente.
Un sistema está compuesto de componentes que interactúan. Solo dentro
del contexto del sistema completo y de la interacción entre sus partes
puede ser definido el comportamiento de una componente específica. En
general, un sistema puede ser modelado como una colección de objetos
pasivos y activos. Estos objetos están interrelacionados y dichas relaciones
entre los objetos cambian con el tiempo. Estas relaciones dinámicas
suministran los estímulos a los cuales los objetos activos, llamados
agentes, responden. Las respuestas pueden causar posteriormente
cambios y, por tanto, estímulos adicionales a los cuales los agentes deben
responder.
PRINCIPIO #4. Una especificación debe abarcar el entorno en el que el
sistema opera.
Similarmente, el entorno en el que opera el sistema y con el que interactúa
debe ser especificado.
Afortunadamente, esto tan solo necesita reconocer que el propio entorno
es un sistema compuesto de objetos que interactúan, pasivos y activos, de
los cuales el sistema especificado es una agente, Los otros agentes, los
cuales son por definición inalterables debido a que son parte del entorno,
limitan el ámbito del diseño subsecuente y de la implementación. De hecho,
la única diferencia entre el sistema y su entorno es que el esfuerzo de
diseño e implementación subsecuente opera exclusivamente sobre la
especificación del sistema. La especificación del entorno facilita que se
especifique la interfaz del sistema de la misma forma que el propio sistema,
en vez de introducir otro formalismo.
PRINCIPIO #5. Una especificación de sistema debe ser un modelo
cognitivo.
La especificación de un sistema debe ser un modelo cognitivo, en vez de
un modelo de diseño o implementación. Debe describir un sistema tal como
es percibido por su comunidad de usuario. Los objetivos que manipula
deben corresponderse con objetos reales de dicho dominio; los agentes
deben modelar los individuos, organizaciones y equipo de ese dominio; y
las acciones que ejecutan deben modelar lo que realmente ocurre en el
dominio. Además, debe ser posible incorporar en la especificación las
reglas o leyes que gobiernan los objetos del dominio. Algunas de estas
leyes proscriben ciertos estados del sistema (tal como "dos objetos no
pueden estar en el mismo lugar al mismo tiempo"), y por tanto limitan el
comportamiento de los agentes o indican la necesidad de una posterior
elaboración para prevenir que surjan estos estados.
PRINCIPIO #6. Una especificación debe ser operacional.
La especificación debe ser completa y lo bastante formal para que pueda
usarse para determinar si una implementación propuesta satisface la
especificación de pruebas elegidas arbitrariamente. Esto es, dado el
resultado de una implementación sobre algún conjunto arbitrario de datos
elegibles, debe ser posible usar la especificación para validar estos
resultados. Esto implica que la especificación, aunque no sea una
especificación completa del como, pueda actuar como un generador de
posibles comportamientos, entre los que debe estar la implementación
propuesta. Por tanto, en un sentido extenso, la especificación debe ser
operacional.
PRINCIPIO #7. La especificación del sistema debe ser tolerante con la
incompletitud y aumentable.
Ninguna especificación puede ser siempre totalmente completa. El entorno
en el que existe es demasiado complejo para ello. Una especificación es
siempre un modelo, una abstracción, de alguna situación real (o
imaginada). Por tanto, será incompleta. Además, al ser formulad existirán
muchos niveles de detalle. La operacionalidad requerida anteriormente no
necesita ser completa. Las herramientas de análisis empleadas para
ayudar a los especificadores y para probar las especificaciones, deben ser
capaces de tratar con la incompletitud. Naturalmente esto debilita el
análisis, el cual puede ser ejecutado ampliando el rango de
comportamiento aceptables, los cuales satisfacen la especificación, pero tal
degradación debe reflejar los restantes niveles de incertidumbre.
PRINCIPIO #8. Una especificación debe ser localizada y débilmente
acoplada.
Los principios anteriores tratan con la especificación como una entidad
estática. Esta surge de la dinámica de la especificación. Debe ser
reconocido que aunque el principal propósito de una especificación sea
servir como base para el diseño e implementación de algún sistema, no es
un objeto estático precompuesto, sino un objeto dinámico que sufre
considerables modificaciones. Tales modificaciones se presentan en tres
actividades principales: formulación, cuando se está creando una
especificación inicial; desarrollo, cuando la especificación se esta
elaborando durante el proceso iterativo de diseño e implementación; y
mantenimiento, cuando la especificación se cambia para reflejar un entorno
modificado y / o requerimientos funcionales adicionales.
• Requerimientos funcionales
Estos son los que describen lo que el sistema debe de hacer. Es
importante que se describa él ¿Qué? Y no él ¿Cómo?. 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.
• Requerimientos de desempeño
Estos requerimientos nos informan las características de desempeño que
deben de tener el sistema. ¿Qué tan rápido?, ¿Que tan seguido?,
¿Cuántos recursos?, ¿Cuantas transacciones?
Este tipo de requerimientos es de especial importancia en los sistemas de
tiempo real en donde el desempeño de un sistema es tan crítico como su
funcionamiento.
• Disponibilidad (en un determinado periodo de tiempo)
Este tipo de requerimientos se refiere a la durabilidad, degradación,
potabilidad, flexibilidad, contabilidad y capacidad de actualización. Este tipo
de requerimientos es también muy importante en sistemas de tiempo real
puesto que estos sistemas manejan aplicaciones críticas que no deben de
estar fuera de servicio por periodos prolongados de tiempo.
• Entrenamiento
Este tipo de requerimientos se enfoca a las personas que van usar el
sistema. ¿Qué tipo de usuarios son?, ¿Que tipo de operadores?, ¿Que
manuales se entregarán y en que idioma?
Este tipo de requerimientos, aunque muchas veces no termina en un
pedazo de código dentro del sistema, son muy importantes en el proceso
de diseño ya que facilitan la introducción y aceptación del sistema en
donde será implementado.
• Restricciones de diseño
Muchas veces las soluciones de un sistema de software son normadas por
leyes o estándares, este tipo de normas caen como "restricciones de
diseño".
• Materiales
Aquí se especifica en que medio se entregara el sistema y como esta
empaquetado. Es importante para definir los costos de industrialización del
sistema.
* Manejo de requerimientos *
De acuerdo con el "Capability Maturity Model" (CMM), el manejo de
requerimientos involucra:
"Establecer y mantener un acuerdo con el cliente sobre los requerimientos
del proyecto de software. Este acuerdo son los requerimientos del sistema
alojados al software." … ". Este acuerdo cubre requerimientos técnicos y no
técnicos (como fechas de entrega). El acuerdo forma las bases para
estimar, planear, ejecutar y monitorear el proyecto de desarrollo de
software a través de todo su ciclo de vida." … "Bajo las restricciones del
proyecto, el grupo de manejo de requerimientos toma las medidas
necesarias para que los requerimientos que están bajo su responsabilidad
estén documentados y controlados"
¿De que manera podemos controlar los requerimientos de software si estos
siempre evolucionan con el tiempo?. El CMM nos proporciona las guías
para lograrlo.
"Para lograr el control de los requerimientos, el grupo de requerimientos
revisa los requerimientos antes de que estos sean incorporados al proyecto
de software y cada vez que los requerimientos cambian los planes,
productos, y actividades son ajustadas para quedar en línea con los nuevos
requerimientos de software".
En otras palabras, para obtener el nivel que requiere el CMM en manejo de
requerimientos débenos de tomar en cuenta dos cosas.
• Que los requerimientos deben de ser revisados (y aprobados) por el
grupo de requerimientos, y no son impuestos por en su totalidad por
presiones externas ajenas al proyecto.
El requerimiento técnico podrá ser impuesto por el mercado o presiones de
la competencia, pero entonces los requerimientos no técnicos (Calidad,
Costo y Tiempo de entrega) deberán estar especificados de común
acuerdo con el grupo de requerimientos del proyecto de software.
• Los requerimientos técnicos y no técnicos forman un conjunto entre sí, si
cambia uno forzosamente deberán cambiar los demás. Esto es: más
contenido técnico implica o más costo, o menos calidad o más tiempo
estimado de entrega. De modo que los cambios técnicos deberán ser
aprobados por el grupo de requerimientos y este grupo estimará los
impactos en tiempo, costo, calidad. El resultado de la estimación es la
entrada a los líderes del proyecto para decidir si el cambio se acepta o no.
* ORGANIZACIÓN Y CAPTURA DE REQUERIMIENTOS DE USUARIO *
Para prosperar en el mercado, cualquier producto debe satisfacer las
necesidades de los usuarios, lo cual no resulta posible si no integra y pone
al alcance del consumidor de forma comprensible los fundamentos de
todos los aspectos del desarrollo. Para captar las necesidades específicas
de los usuarios es indispensable que los documentos que recogen los
requerimientos se redacten utilizando métodos pragmáticos.
Se debe utilizar una metodología detallada de definición de los
requerimientos de usuario. Organizar entrevistas destinadas a obtener la
máxima información posible acerca de los requerimientos de los usuarios.
Traducir las oportunidades / necesidades en requerimientos del proyecto.
Comprender el perfil y entorno del usuario. Evaluar el flujo de trabajo. Crear
un documento de requerimientos generales. Conseguir la participación y
confirmación del usuario.
Los gerentes y usuarios del sistema también poseen un papel importante
en le diseño del sistema; no es solamente el proyecto del analista. Durante
el diseño, a algunos se les pide que revisen los borradores de los informes,
que examinen los formatos de entrada y que ayuden en la escritura de los
procedimientos para decirles a otras personas como utilizar el sistema en
forma apropiada.
La participación del usuario proporciona al analista una retroalimentación
importante conforme avanza en el diseño; además asegura a los usuarios
tengan un conocimiento no técnico de lo realizara o no el nuevo sistema.
Esta visión general del diseño de sistemas subraya los aspectos de diseño
que se verán mas adelante en el diseño de la salida de sistema.
* REQUERIMIENTOS DEL SISTEMA *
Los Sistemas de Información por computadora normalmente están
integrados por muchos componentes. En la mayor parte de los casos, es
difícil para los analistas entender todos estos componentes aún mismo
tiempo; por lo tanto los investigadores tienen que comenzar con preguntas
de tipo general con relación al propósito del sistema sus entradas y salidas
de los procesos incluidos.
En los grandes proyectos de sistema varios analistas llevan a cabo una
investigación en forma seccionada que la distribuye entre ellos mismos, de
manera que cada uno pueda trabajar en forma independiente.
Existen dos estrategias ampliamente utilizadas para determinar los
requerimientos de información. Se clasifican en dos tipos:
1.- Flujo de Datos.
2.- Estrategias de Análisis de Decisión para el Conocimiento para los
Sistema de Información.
* Estrategia del Flujo de Datos *
Cuando se siguen un flujo a través de los procesos de negocio, que es el
propósito del análisis del flujo de datos, le indica a los analistas una gran
cantidad de datos sobre como sé esta llevando a cabo los objetivos de la
compañía. Al manejar las transacciones y completar las tareas, los datos
de entrada se procesan, almacenan, consultan, utiliza, modifica y se
emiten.
El análisis de flujo de datos que muestra el estudio y el uso de cada
actividad, documenta los hallazgos en los diagramas de flujo de datos.
* Estrategia del Análisis de Decisiones *
La estrategia del análisis de decisiones es un complemento del análisis del
flujo de datos. Esta estrategia realza el estudio de los objetivos de una
operación y de las decisiones que deben realizarse para cumplir con los
objetivos.
Las decisiones se presentan tanto en los niveles operativos como en los de
alto nivel gerencial, la estrategia de análisis de decisión con frecuencia
utiliza por parte de alta gerencia para desarrollar la toma de decisiones.
La alternativa que selecciona los gerentes responsables en la toma de
decisiones, en cuanto a una estrategia de precios entre un conjunto de
alternativas, se maneja de forma diferente a la opción que toma un
supervisor de departamento para aceptar o rechazar pedidos.
La decisión de rechazar pedidos generalmente ocurre con más frecuencia,
de manera que las condiciones y acciones normalmente se conocen como
un aspecto importante.
* Etapas en la Estrategia del Análisis del Flujo de Datos *
1. - Estudiar las operaciones y procesos en marcha.
2. - Identificar cómo se procesan los datos al manejar transacciones y
terminar las tareas.
3. - Seguir el flujo de datos:
* Proceso
* Almacenamiento
* Recuperación
* Salida
4. - Añadir gradualmente detalles a los niveles inferiores.
Etapas en la Estrategia del Análisis de Decisión
1. -Estudiar los objetivos y decisiones necesarias.
2. - Desarrollar un modelo del proceso de decisión.
3. - Probar el modelo con datos de prueba.
4. - Identificar los requerimientos del proceso para los datos.
* Requerimientos De Entrada *
Es el enlace que une al sistema de información con el mundo y sus
usuarios, en esta existen aspectos generales que todos los analistas deben
tener en cuenta estos son:
• Objetivos del Diseño de Entrada.
• Captura de Datos para la Entrada.
Objetivo del Diseño de Entrada
Consiste en el desarrollo de especificaciones y procedimientos para la
preparación de datos, la realización de los procesos necesarios para poner
los datos de transacción en una forma utilizable para su procesamiento así
como la entrada de los datos se logra al instruir a la computadora para que
lea ya sea documentos escritos, impresos ó por personas que los escriben
directamente al sistema.
Existen cinco objetivos que controlan la cantidad de entrada requerida, a
enviar los retrasos, controlar los errores y mantener la sencillez de los
pasos necesarios, estos son:
• Control de la Calidad de Entrada
• Evitar los Retrasos
• Evitar los errores en los datos
• Evitar los pasos adicionales
• Mantener la Sencillez del Proceso
Control de la Calidad de Entrada:
Existen varias razones por las cuales un buen diseñador debe controlar la
cantidad de datos en la entrada:
- Las Operaciones de preparación y entrada dependen de las personas
dado que los costos de mano de obra son altos y la preparación de ingreso
de los datos también lo son.
-
La fase de entrada puede ser un proceso lento que toma mucho más
tiempo que el que necesitan las computadoras para realizar sus tareas.
Evitar los Retrasos:
También conocido con el nombre de cuello de botella son siempre uno de
los objetivos que el analista evita al diseñar la entrada, una forma de
evitarle es utilizar los documentos de retorno.
Evitar los errores en los datos:
La tasa de errores depende de la cantidad de datos, ya que entre más
pequeña sea esta menores serán las oportunidades para cometer errores.
Es común encontrar en las operaciones de ventas por lo menos un 3% de
errores en las operaciones de entrada de datos.
Evitar los Pasos Adicionales:
Algunas veces el volumen de transacciones y la cantidad de datos en
preparación es algo que no se puede controlar por ello el analista
experimentado, evitara diseños para la entrada que traigan una mayor
cantidad de pasos a seguir. Ya sea añadir o quitar pasos cuando se
alimenta un proceso muchas veces al transcurso de un día.
Mantener la sencillez del Proceso:
El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al
mismo tiempo proporcionarán métodos para el control de los errores, la
simplicidad funciona y es aceptada por cualquier usuario. Cuesta trabajo
que los usuarios acepten sistemas complejos o confusos y que no exista
ninguna garantía para el éxito al instalar un sistema complejo y que
domine.
Captura de Datos para la Entrada:
En una transacción existen datos importantes y otros que no, el analista
debe saber cuáles utilizará y cuales en realidad deben formar la entrada.
Existen dos tipos de datos:
• Datos variables
• Datos de identificación
Datos Variables:
Son aquellos que cambian para cada transacción o toman de decisión.
Datos de Identificación:
Estos son los que identifican en forma única el artículo que esta siendo
procesado.
* Requerimientos De Salida *
Niveles de diseño
El diseño de sistema se representa a través de dos fases: el diseño lógico y
el diseño físico.
Cuando los analistas formulan un diseño lógico; escriben las
especificaciones detalladas del nuevo sistema; esto es, describen sus
características: las salidas, entradas, archivos y bases de datos y
procedimientos; todos de manera que cubran los requerimientos del
proyecto.
El diseño lógico de un sistema de información es como el plano de un
ingeniero para armar un automóvil: muestra las características
principales(motor, transmisión y área para los pasajeros)y como se
relacionan unas con otras(donde se conectan entre sí los componentes del
sistema, o por ejemplo, cuan separadas están las puertas.
Los informes y la producción del analista son los componentes de todo el
mecanismo que emplea el ingeniero. Los datos y procedimientos se ligan y
entonces se produce un sistema que trabaje.
El diseño lógico también especifica las formas de entrada y las
descripciones de las pantallas de todas las transacciones y archivos a fin
de mantener los datos de inventario, los detalles de las transacciones y los
datos del proveedor. Las especificaciones de los procedimientos describen
métodos para introducir los datos, corridas de informes copiados de
archivos y detección de problemas.
El diseño físico, actividad que sigue el diseño lógico, produce programas de
software, archivos y un sistema en marcha, las especificaciones del diseño
indican a los programadores que debe hacer el sistema. Los
programadores a su vez escriben los programas que aceptan entradas por
parte de los usuarios, procesan los datos, producen los informes y
almacenan estos datos en los archivos.
Utilización de los Datos de Requerimientos:
El alcance del diseño de sistemas se guía por el marco de referencia para
el nuevo sistema desarrollado durante el análisis. Los datos de los
requerimientos, recopilados durante la investigación, conforman las
actividades y componentes del sistema. Los analistas formulan un diseño
lógico que apoya los procesos y decisiones, los contenidos del sistema
pueden cambiar como resultado de un nuevo diseño.
El diseño lógico va de arriba hacia abajo, como lo hizo la determinación de
requerimientos.
En primer lugar se identifican las características generales, como informes
y entradas; en el diseño de la salida por ejemplo, los analistas deben
conocer la longitud de campo de un dato específico para establecer cuanto
espacio dejar en la información, en la pantalla de despliegue visual o
archivo.
A lo largo de los años hemos visto una evolución de ideas y técnicas en el
campo del análisis de sistemas. La cual cabe en tres períodos amplios
según Yourdon:
1. El análisis de sistema convencional, anterior a los años 70´s,
caracterizado por especificaciones tipo novela victoriana que eran difíciles
de leer y entender, y casi imposibles de mantener.
2. El análisis estructurado clásico, de mediados de los años 70´s, a
mediados de los años 80´s. Esto se caracterizó por primeras versiones de
modelos gráficos, y énfasis en el modelado de las implementaciones
actuales de un sistema antes de modelar el nuevo.
3. El análisis estructurado moderno, en el cual se introducen mejoras sobre
todo para modelar sistemas de tiempo real y relaciones de situaciones
complejas. Aumentando por ende la comunicación entre el analista y el
sistema.
En la actualidad las técnicas modernas están siendo fusionadas, para así
lograr un mejor método que pueda hacerle frente a las necesidades de las
diferentes fases del ciclo de vida del sistema, incluyendo a la fase de
análisis. Obteniendo de está manera mejores resultados que pueda
interpretar el analista en forma rápida y precisa.
En primera instancia debemos decir que el análisis estructurado según
Senn "permite al analista conocer un sistema o proceso (actividad) en una
forma lógica y manejable al mismo tiempo que proporciona la base para
asegurar que no se omite ningún detalle pertinente". El objetivo que
persigue el análisis estructurado es organizar las tareas asociadas con la
determinación de requerimientos para obtener la comprensión completa y
exacta de una situación dada. Se puede decir adicionalmente que los
componentes del análisis estructurado son los siguientes: símbolos
gráficos, diccionarios de datos, descripciones de procesos y
procedimientos, reglas.
Después de relacionarnos brevemente con la terminología básica,
podemos entrar en aspectos relacionados con los cambios del análisis
estructurado.
Podemos decir que para finales de los años 60´s e inicios de los 70´s el
análisis estructurado surge de la necesidad de buscar una forma
interpretativa más rápida y eficiente, de tal manera que se pudiesen definir
los requerimientos del usuario y las especificaciones funcionales del
sistema. Pero esto no se daba porque lo que existía eran grandes
volúmenes de información que había que leer por completo y que
acarreaban una serie de problemas de: monolitismo, redundancia,
ambigüedad e imposibilidad de mantener. Es por ello que surge una amplia
variedad de diagramas que permiten representar las especificaciones
funcionales en forma sencilla y rápida, aumentando por ende el grado de
comunicación entre las especificaciones funcionales y el usuario final
(analista, programador, diseñador).
Posteriormente, a mediados de los años 70´s estando el análisis
estructurado clásico en su apogeo aparecen una serie de dificultades que
limitan al analista hacer un buen desempeño de sus actividades. Entre
estos problemas según Yourdon podemos mencionar:
• Distinción difusa y poca, definida entre los modelos lógicos y los modelos
físicos.
• Limitación para modelar sistemas en tiempo real.
• El modelo de datos se hacía de una manera primitiva.
Estas y otras razones dieron nacimiento a ciertas mejoras en el análisis
estructurado clásico tales como: diagramas de entidad-relación, diagramas
de transición de estados, división de eventos, modelos esenciales y
modelos de implantación. Pero a pesar de esto según Yourdon se siguieron
dando más problemas como los siguientes:
• Tras la segunda y tercera correcciones de un diagrama, el analista se
volvía cada vez más apuesto y renuente a hacer más cambios.
• Debido a la cantidad de trabajo requerido, el analista dejaba a veces de
dividir el modelo del sistema en modelos de menor nivel, quedando por
ende, funciones primitivas.
• A menudo no se incorporaban en el modelo del sistema los cambios en
los requerimientos del usuario sino hasta después de la fase de análisis del
proyecto.
Inclusive las correcciones de los diagramas había que hacerlas en forma
manual, para asegurar que fuesen consistentes y estuviesen completas; lo
cual era bastante tedioso y dejaba por fuera muchos errores que debían de
encontrarse. Pero para mediados de los 80´s aparecieron las herramientas
CASE que trataron de subsanar estos problemas. Las herramientas CASE
(Ingeniería de software auxiliada por computadora) se utilizan para dibujar
diagramas de flujo de datos y otros además de llevar a cabo una variedad
de labores de revisión de errores.
Finalmente, algunos usuarios tenían dificultades al tratar con los modelos
gráficos del análisis estructurado y preferían alguna otra forma de modelar
los requerimientos y comportamiento del sistema; es por ello que aparecen
las herramientas de generación de prototipos (mediados de los 80´s) que
son considerados como una alternativa al análisis estructurado para tales
usuarios. También se utiliza para recordar en forma breve y precisa lo que
se ha hecho a lo largo de todo el desarrollo del sistema, para no perder la
secuencia de lo que se está realizando.
En la actualidad muchas de estas herramientas se están utilizando para
facilitar la fase de análisis, e inclusive se están elaborando o fusionando lo
mejor de cada una de las técnicas que atienden las necesidades de todas
las fases del ciclo de vida del sistema; para así obtener un mejor
aprovechamiento, entendimiento, y rendimiento al momento que se ponga
a correr el sistema. Disminuyendo de esta manera la serie de errores que
se cometían anteriormente, con la introducción de herramientas más
especializadas y fáciles de utilizar.
Diversos aspectos del análisis estructurado han cambiado gradualmente a
lo largo de los últimos años. Las principales áreas de cambio incluyen lo
siguiente según Yourdon:
• Cambios de terminología.
• Partición de acontecimientos.
• La desenfatización del modelado físico actual.
• Herramientas de modelado en tiempo real.
• Integración más cercana del modelado de procesos y datos.
En un futuro no muy lejano se piensa que se darán, si es que ya no se
están dando, los siguientes cambios o pautas en el ámbito total en lo que
se refiere a análisis según Yourdon:
• Mayor difusión del análisis de sistemas, sobre todo en los siguientes
grupos: los niveles superiores de administración en organizaciones
gubernamentales y de negocios, los niños, y profesionales de la
computación en los países del tercer mundo.
• Impacto sobre la industria de software del tercer mundo.
• Proliferación de las herramientas automatizadas, aunque no todos los
analistas tienen acceso a las últimas herramientas de análisis.
• Impacto de los desastres de mantenimiento.
• Integración del análisis estructurado con la inteligencia artificial.
Podemos adicionar que el futuro del análisis estructurado va a depender
mucho también de que tan rápido pueda ajustarse el mismo a los cambios
tecnológicos que se viven hoy en día. Debido a que han estado surgiendo
otras técnicas en otras áreas como lo es la orientada a objetos, la cual
prevé un buen futuro y muchas mejoras para los sistemas actuales.
* DOCUMENTOS DE REQUERIMIENTOS DEL SOFTWARE*
Fue la aparición del diseño y la programación estructurada alrededor de los
años 60´s la que dieron cabida al surgimiento del análisis estructurado, ya
que existía la necesidad de utilizar una notación gráfica para representar
los datos y los procesos que los transforman". Es por ello que surgen una
serie de temas afines tales como: herramientas automatizadas (CASE),
prototipos, diagramas de entidad-relación etc.
Índice de Términos relacionados: CASE (Ingeniería de Software auxiliada
por computadora), elaboración de prototipos, símbolos gráficos,
diccionarios de datos, descripciones de procesos y procedimientos, reglas,
diagramas de estados, diagramas de entidad-relación, diagramas de
transición de eventos, división de eventos, modelos esenciales y modelos
de implantación.
* Métodos de Análisis Orientados al Flujo de Datos *
La información se transforma como un flujo a través de un sistema basado
en computadora. El sistema acepta entrada de distintas formas; aplica un
hardware, software y elementos humanos para transformar la entrada en
salida; y produce una salida en distintas formas. La entrada puede ser una
señal de control transmitida por un transductor, una serie de números
escritos por un operador humano, un paquete de información transmitido
por un enlace a red, o un voluminoso archivo de datos almacenado en
memoria secundaria. La transformación puede comprender una sencilla
comparación lógica, un complejo algoritmo numérico, o un método de
inferencia basado en regla de un sistema experto. La salida puede
encender un sencillo led o producir un informe de 200 páginas. En efecto,
un modelo de flujo de datos puede aplicarse a cualquier sistema basado en
computadora independientemente del tamaño o complejidad.
La función global del sistema se representa como una transformación
sencilla de la información, representada en la figura como una burbuja. Una
o más entradas. Representadas como flechas con etiqueta, conducen la
transformación para producir la información de salida. Puede observarse
que el modelo puede aplicarse a todo el sistema o solo a un elemento de
software. La clave es representar la información dada y producida por la
transformación.
* Diagramas de Flujos de Datos *
Conforme con la información se mueve a través del software, se modifica
mediante una serie de transformaciones. Un diagrama de flujos de datos
(DFD), es una técnica grafica que describe el flujo de información y las
transformaciones que se aplican a los datos, conforme se mueven de la
entrada a la salida. El diagrama es similar en la forma a otros diagramas de
flujo de actividades, y ha sido incorporado en técnicas de análisis y diseños
propuesto por Yourdon y Constantine, DeMarco y Gane y Sarson. También
se le conoce como un grafo de flujo de datos o un diagrama de burbujas.
* Diccionario de Datos *
Un análisis del dominio de la información puede ser incompleto si solo se
considera el flujo de datos. Cada flecha de un diagrama de flujo de datos
representa uno o más elementos de información. Por tanto, el analista debe
disponer de algún otro método para representar el contenido de cada
flecha de un DFD.
Se ha propuesto el diccionario de datos como una gramática casi formal
para describir el contenido de los elementos de información y ha sido
definido da la siguiente forma:
El diccionario de datos contiene las definiciones de todos los datos
mencionados en el DFD, en una especificación del proceso y en el propio
diccionario de datos. Los datos compuestos (datos que pueden ser además
divididos) se definen en términos de sus componentes; los datos
elementales (datos que no pueden ser divididos) se definen en términos del
significado de cada uno de los valores que puede asumir. Por tanto, el
diccionario de datos esta compuesto de definiciones de flujo de datos,
archivos [datos almacenados] y datos usados en los procesos
[transformaciones]...
* Descripciones Funcionales *
Una vez que ha sido representado el dominio de la información (usando un
DFD y un diccionario de datos), el analista describe cada función
(transformación) representada, usando el lenguaje natural o alguna otra
notación estilizada. Una de tales notaciones se llama ingles estructurado
(también llamado lenguaje de diseño del programa o proceso (LDP)). El
inglés estructurado incorpora construcciones procedimentales básicas –
secuencia, selección y repetición- junto con frases del lenguaje natural, de
forma que pueden desarrollarse descripciones procedimentales precisas de
las funciones representadas dentro de un DFD.
* Métodos Orientados a la Estructura de Datos *
Hemos ya observado que el dominio de la información para un problema de
software comprende el flujo de datos, el contenido de datos y la estructura
de datos. Los métodos de análisis orientados a la estructura de datos
representan los requerimientos del software enfocándose hacia la
estructura de datos en vez de al flujo de datos. Aunque cada método
orientado a la estructura de datos tiene un enfoque y notación distinta,
todos tienen algunas características en común: 1) todos asisten al analista
en la identificación de los objetos de información clave (también llamados
entidades o ítems) y operaciones (también llamadas acciones o procesos);
2)todos suponen que la estructura de la información es jerárquica; 3)todos
requiere que la estructura de datos se represente usando la secuencia,
selección y repetición; y 4) todos dan una conjunto de pasos para
transformar una estructura de datos jerárquica en una estructura de
programa.
Como los métodos orientados al flujo de datos, los métodos de análisis
orientados a la estructura de datos proporcionan la base para el diseño de
software. Siempre puede extenderse un método de análisis para que
abarque el diseño arquitectural y procedimental del software.
BIBLIOGRAFÍA
Senn, James A. "Análisis y Diseño de Sistemas de Información". Segunda
Edición. McGraw Hill. 1992.
JAMES A SENN, Análisis y Diseño de Sistema de Información, Mc Graw Hill,
Enero 1990
JAMES A. SENN, Análisis y Diseño de Sistemas de Información, Segunda
Edición, Mc Graw Hill, Abril 2000.
IEEE Task Force on Requirements Engineering. Software Engineering
Resources by Roger S. Pressman & Associates
Edward - Yourdon (1993) - Análisis Estructurado Moderno, Prentice Hall
Hispanoamericana, S. A., pp. 136-147, 500-511.
Roger - S. P. (1993) - Ingeniería del Software, Mc. Graw-Hill, pp. 217-218, 247.
Pressman, R.S., "Ingeniería del Software. Un enfoque práctico.", McGraw-Hill.
Larman, C. "UML y patrones: Introducción al análisis y diseño orientado a
objetos". Prentice halll