Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Unidad 5
Unidad 5
_____________________________________________________________________________________________________
UNIDAD V
Contenido:
5.1
Introduccin
5.2
5.3
5.4
5.5
5.6
Revisin de la Especificacin
Ingenieria de Software I
_____________________________________________________________________________________________________
5.1
INTRODUCCION
Un desarrollo de software tiene xito si se han comprendido perfectamente los requisitos del software. Si un programa
se analiza y especifica pobremente, decepcionar al usuario y desprestigiar a quien lo ha desarrollado. No importa lo bien
diseado o codificado que est un programa, si no se ha analizado correctamente, defraudar al cliente y frustrar al
desarrollador.
Cuando desarrollamos software siempre pensamos en encauzar nuestro esfuerzo a construir el producto correcto, sin
embargo frecuentemente nos damos cuenta que el producto que construimos no es el correcto cuando ya est terminado,
cuando ya se han invertido muchas horas y jornadas de trabajo y se ha invertido bastante dinero.
El correcto entendimiento que tengamos de los requisitos y funciones que debe proporcionar el software es la clave
para que podamos tomar el camino que nos lleve a construir el producto correcto.
Ese entendimiento correcto
Requisitos del Software.
El Anlisis de Requisitos del Software es una fase de la Ingeniera de Software que enlaza la Definicin del Software
a nivel Sistema y el Diseo de Software en un proceso de descubrimiento, refinacin, modelado y especificacin.
El anlisis de
requisitos
proporciona:
Ingenieria de Software I
_____________________________________________________________________________________________________
Inicialmente se debe estudiar la Definicin del Sistema y el Plan del Proyecto para comprender el sistema y revisar
las razones que se usaron para hacer las estimaciones en la planeacin.
Se debe adems establecer contacto con el equipo del cliente para reconocer el problema tal como lo percibe el
cliente.
2) Evaluacin y Sntesis
El analista debe evaluar el flujo y la estructura de la informacin, definir todas las funciones del software, establecer
las caractersticas de la interfaz y las restricciones de diseo. Esto servir finalmente para sintetizar una solucin global.
El analista debe centrarse en el qu ( qu se hace, qu se tiene, qu se puede hacer ) y no en el cmo.
3) Modelizacin.
Durante la evaluacin y sntesis de la solucin, se pueden crear modelos del sistema en un esfuerzo por entender
mejor el flujo de datos y de control, la operacin, funciones y contenido de la informacin.
Esta modelizacin puede hacerse a travs de:
Diagramas de Flujo de Datos
Prototipo
Manual de Usuario Preliminar.
4) Especificacin
El anlisis debe, al final, proporcionar una representacin que pueda ser revisada y aprobada por el cliente. Por ello
para describir las caractersticas, funciones y atributos del software se escribe una Especificacin Formal de Requisitos.
5) Revisin
Los documentos que especifican los requisitos del software sirven como base para una revisin, lo cual producir
quizs, modificaciones en la definicin del proyecto y en la reevaluacin del plan para determinar si las primeras estimaciones
siguen siendo vlidas.
Siempre es mejor descubrir los comentarios del tipo: La idea es correcta, pero esta no es la forma en que pens que
se hara, lo ms pronto posible.
5.2
Ingenieria de Software I
_____________________________________________________________________________________________________
Los siguientes principios resumen la escencia del Anlisis de Requisitos:
1.
2.
3.
4.
5.
Dominio de la Informacin
El software se construye para procesar datos, para transformarlos es decir, para aceptar datos de entrada, manipularlos
y producir informacin de salida. Pero el software tambin procesa acontecimientos, que controlan al sistema y no es mas que
un dato binario, tal como un sensor que enva al software una seal de alarma.
Por tanto, los datos ( nmeros, caracteres, imgenes, sonidos, etc. ) y el control ( acontecimientos ) son parte del
dominio de la informacin.
Para conocer y determinar el dominio de la informacin se debe examinar desde tres enfoques:
1.
2.
3.
Contenido de la Informacin
Flujo de la Informacin
Estructura de la Informacin
Contenido de la Informacin
Representa los elementos de datos individuales que componen otros elementos mayores de informacin. Por ejemplo,
el contenido de un elemento de informacin llamado Nmina podra ser:
Nmina
Nombre del empleado
Sueldo Neto
Sueldo Bruto
Deducciones
Flujo de la Informacin
Es la manera en que se representa la forma en que los datos cambian conforme se mueven a travs del sistema.
Datos de
Entrada
Transfor
-macin
1
Datos
Intermedios
Transfor
-macin
2
Datos de
Salida
Las transformaciones que se aplican a los datos son funciones que debe realizar un programa.
Estructura de la Informacin
Representa la organizacin interna de los distintos elementos de datos, ejemplo:
Sueldo Neto
Ingenieria de Software I
_____________________________________________________________________________________________________
Numrico
6 dgitos enteros
2 dgitos decimales
Modelado
Los modelos se crean para entender mejor la entidad que se va a construir. Los modelos pueden emplear una notacin
grfica que muestra informacin, procesamiento y comportamiento del sistema. El segundo y tercer principio de anlisis
requieren la construccin de los modelos funcional y de comportamiento.
Modelo Funcional
El modelo funcional representa las transformaciones ( entrada-procesamiento-salida ) que los datos sufren dentro del
sistema. El modelo funcional empieza con un modelo sencillo a nivel contexto ( ej. El nombre del software a construir ).
Despus de varias iteraciones se consiguen ms y ms detalles funcionales, hasta representar toda la funcionalidad del sistema.
Modelo de Comportamiento
El software puede responder a acontecimientos del mundo exterior que hacen que el sistema cambie de un estado a
otro, el estimulo-respuesta es la base del modelo de comportamiento. Un estado es un modo de comportamiento tal como
calculando, imprimiendo, esperando, haciendo cola, etc. que cambia solo cuando ocurre un acontecimiento: 1) un reloj que
indica que se cumple un intervalo de tiempo, 2) un movimiento de ratn, 3) un sistema externo, etc.
El modelo de comportamiento es una representacin de los estados del software y los acontecimientos que causan que
cambie de estado.
Particin
El cuarto y quinto principios del anlisis sugieren que se puedan particionar el dominio de la informacin, funcional
y de comportamiento. Muchas veces los problemas son demasiado grandes y complejos para entenderlos globalmente. Es ms
conveniente dividirlo en partes mas sencillas de manejar, analizar y entender.
La particin de la informacin o la funcin puede representarse jerrquicamente:
1. Descomponiendo el problema si nos movemos horizontalmente en la jerarqua
2. Exponiendo ms detalles conforme nos movemos verticalmente
Ejemplo:
Software de Control Escolar
Procesar admisiones
Inscribir alumnos
Procesar calificaciones
Configurar reglamento
Capturar fichas
Capturar resultados de examen
Imprimir relacin de aceptados
5.3
CONSTRUCCION DE PROTOTIPOS
Un prototipo es un sistema de trabajo que se desarrolla con rapidez para probar ideas y el entendimiento sobre el
nuevo sistema, en otras palabras no solo es un diseo en papel, sino un software que corre y produce informacin impresa o en
pantalla.
Ingenieria de Software I
_____________________________________________________________________________________________________
Las siguientes son razones para desarrollar prototipos de sistemas:
1. El cliente sabe que tiene un problema, pero no sabe que informacin necesita.
2. Requerimientos demasiado vagos como para formular un diseo.
3. Requerimientos bien definidos perso se tiene poco conocimiento para construir un sistema que cubra esos
requisitos.
Caractersticas
1.
2.
3.
4.
5.
5.4
Existen otros mtodos alternativos a la construccin de prototipos que se utilizan tambin para la modelizacin del
sistema, estos mtodos usan notaciones propias para representar el flujo, contenido y estructura de la informacin, entre estos
mtodos se encuentran los siguientes:
Ingenieria de Software I
_____________________________________________________________________________________________________
1. Anlisis Estructurado
2. Anlisis Orientado a Objetos
3. Anlisis Orientado a la Estructura de Datos
Anlisis Estructurado
El mtodo de Anlisis Estructurado es un mtodo que ha prosperado y cada vez es ms ampliamente utilizado en la
comunidad de Ingeniera de Software. El mtodo se basa en la construccin de modelos utilizando una notacin grfica para
modelar el flujo y contenido de la informacin.
Los modelos construidos deben lograr tres objetivos:
1. Describir lo que el cliente requiere
2. Establecer una base para crear el diseo del software
3. Definir los requisitos a validar cuando el software este terminado
Para lograr estos objetivos el anlisis estructurado emplea los siguientes componentes:
1.
2.
3.
4.
Diagrama
Entidad - Relacin
Diagrama de
Flujo de
Datos
Diccionario
de Datos
Diagrama de
Transicin
de Estados
Ingenieria de Software I
_____________________________________________________________________________________________________
El modelado de los datos emplea el Diagrama Entidad Relacin ( DER ) como base. Como el DER se centra solo en
los datos esto hace que proporcione el entendimiento del dominio de la informacin del problema. El DER servir a los
diseadores del software como base para producir el diseo de la base de datos.
Se han propuesto diferentes notaciones grficas para el DER Los objetos o entidades son representados por
rectngulos y las relaciones por lneas o rombos que conectan directamente a los objetos. Por ejemplo:
Alumno
Cursa
Materia
Cursa
Alumno
Materia
Sin embargo indicar que el objeto X se relaciona con el objeto Y no es suficiente. Se debe comprender la cantidad de
ocurrencias en que los objetos X Y se relacionan, esto se hace aplicando un concepto llamado CARDINALIDAD.
Dos objetos se pueden relacionar con las siguientes cardinalidades:
Uno a uno
Uno a muchos
Muchos a muchos
Los DER emplean smbolos que permiten representar la cardinalidad de las relaciones entre los objetos.
Alumno
Cursa
n
Materia
Alumno
Cursa
n
Materia
n
Imparte
Impart
Profesor
1
Profesor
Unidad Externa
Ingenieria de Software I
_____________________________________________________________________________________________________
Un rectangulo representa a un elemento del sistema ( por ejemplo un hardware, una
persona, un programa ) o un sistema que produce o recibe informacin que es
transformada por el software.
Proceso
Los DFDs pueden representar un sistema a cualquier nivel de detalle funcional. Un DFD de nivel cero es tambin
denominado diagrama de contexto, representa al elemento de software o al sistema como una sola burbuja o proceso de
transformacin con datos de entrada y salida representados con flechas.
Entidad Externa
Entidad Externa
Informacin de
entrada
Sistema basado en
computadora
Entidad Externa
Informacin de
salida
Entidad Externa
A partir del DFD de nivel 0 si se quieren representar mas detalles se crearn entonces diagramas de nivel 1, 2 etc.
segn la profundidad de los detalles.
Diagrama de Nivel 1
Ingenieria de Software I
_____________________________________________________________________________________________________
El DFD es una herramienta grfica muy valiosa para el anlisis de requisitos del software. Sin embargo muchas veces
el analista confunde los propsitos del diagrama, al elaborarlo e interpretar su funcin como un diagrama de flujo ( los
diagramas utilizados para representar un algoritmo )
Un DFD representa el flujo de la informacin sin representar explcitamente la lgica de procesamiento, es decir, el
DFD no representa condiciones, bucles, tiempo de ocurrencia de los procesos, etc. Los DFD no representan algoritmos, ms
bien cada burbuja de un DFD representa una funcin del sistema y esa funcin puede posteriormente detallarse en una
especificacin que derive en un algoritmo y a su vez en un programa.
Llena y comienzo
Leyendo
Ordenes
Copias hechas
Ingenieria de Software I
_____________________________________________________________________________________________________
Cada rectngulo representa un estado del sistema. Las flechas representan los sucesos y sealan de que estado a qu
estado cambia el sistema cuando ocurre dicho suceso. Las flechas se etiquetan con el nombre del suceso.
Ingenieria de Software I
_____________________________________________________________________________________________________
2. Descripcin de los procesos
3. Descripcin de las estructuras de datos
4. Descripcin de los elementos de datos
5. Descripcin de los flujos de datos
Para describir con claridad un elemento dato y sus relaciones con otros datos se utiliza la siguiente notacin:
Notacin
Significado
Est compuesto de
[ | ]
{ }n
n repeticiones de
()
datos opcionales
**
comentario
Ejemplo:
Los siguientes ejemplo de formatos pueden ser utilizados para integrar el diccionario de datos:
Almacenamiento de Datos
Nombre:
Descripcin:
Alumnos Inscritos
Alumnos que oficialmente forman parte de
la matrcula escolar.
Descripcin de Datos:
- Matrcula
- Promedio a la fecha
- Nombre completo - Carrera
- Domicilio
- Semestre que cursa
Volumen:
Procesos
Nombre:
Descripcin:
Entradas:
Kardex de calificaciones
Salidas:
Promedio general
Acta de Calificaciones
Nombre:
que el profesor
ResumenDescripcin:
Lgico:
Por cada Documento
calificacin oficial
final enpara
el Kardex
desde notifique
la Direccin
el primerasemestre
hastalas
la calificaciones
fecha hacer: finales de los alumnos
en la
materia impartida.
Acumular
suma de calificaciones
Acumular nmero de calificaciones
Contenido: Promedio General =Acta
= {de Matricula
+ Nombre +
SumaCalific
/ Nmero
calific.
Calificacin }n
Donde 30 <= n <= 45 aprox.
Volumen:
Ingenieria de Software I
_____________________________________________________________________________________________________
Estructura de Datos
Elemento Dato
Nombre:
Descripcin:
Tipo de Examen
Oportunidad de examen en la que se evala al alumno
para determinar si aprueba la materia.
Tipo:
Alfabtico
Longitud:
Rango de Valores:
Tipo Examen = [ O | E | T ]
5.5
La Especificacin de Requisitos del Software se produce como culminacin de la tarea de anlisis. En este documento
quedan plasmados los resultados de la tarea de anlisis, tales como:
1. Una descripcin funcional detallada.
2. Una indicacin de los requisitos de rendimiento.
3. Restricciones para el diseo.
4. Criterios de validacin.
Ingenieria de Software I
_____________________________________________________________________________________________________
En muchos casos la Especificacin de Requisitos del Software puede ir acompaada de un prototipo ejecutable ( que
en algunos casos puede remplazar la Especificacin ), un prototipo en papel o un Manual de Usuario Preliminar.
El formato de la Especificacin de Requisitos del Software puede tener la estructura siguiente:
Panorama del producto y resumen
Ambientes de desarrollo/operacin/mantenimiento
Interfaces externas y flujo de datos
Despliegues al usuario / formato de informes
Resumen de comandos del usuario
Diagrama de flujo de datos de alto nivel
Fuentes y destinos lgicos de datos
Almacenamiento lgico de datos
Diccionario lgico de datos
Especificaciones funcionales
Requisitos de operacin
Condiciones de excepcin / manejo de excepciones
Subconjuntos iniciales y prioridades de codificacin
Modificaciones y mejoras previstas
Criterios de aceptacin
Pruebas funcionales y de operacin
Estndares de documentacin
Guas de diseo
Fuentes de informacin
Glosario de trminos
5.6
REVISION DE LA ESPECIFICACION
El desarrollador de software y el cliente realizan una revisin de la Especificacin de Requisitos del Software ( y/o
del prototipo ). Debido a que la Especificacin constituye el fundamento de la fase de desarrollo, se debe tener un cuidado
extremo en la realizacin de la revisin.
Terminada la revisin tanto el cliente como el tcnico deben firmar la especificacin, este ser un contrato para
el desarrollo del software.
El cliente debe tener en cuenta que cada cambio posterior ser una ampliacin del software y podr en consecuencia
incrementar el costo y/o retrasar la agenda.
Modelizacin
Dominio de la informacin
Funcin
Comportamiento
Anlisis de Requisitos
Ingenieria de Software I
_____________________________________________________________________________________________________
5.7
Llevar a cabo el anlisis estructurado en forma manual usando papel, plantillas de smbolos y lpiz puede resultar
difcil sobre todo en la modelizacin de grandes sistemas.
Por esta razn las herramientas CASE son un apoyo imprescindible. Existen un sin numero de programas CASE con
mltiples propsitos: hay herramientas CASE para la construccin de prototipos, para el anlisis y diseo usando una
metodologa especfica, etc.
Ejemplos de herramientas CASE comerciales:
Herramienta:
Fabricante:
Ingenieria de Software I
_____________________________________________________________________________________________________
Metodologia:
Analisis Estructurado
Plataforma:
Windows 3.1, Windows 95 y Unix
Herramienta:
Fabricante:
Metodologa:
Plataforma:
Asistente de Desarrollo
Ristanoviz Case
Oritentado a Objetos
Win 3.1 y Win 95
La herramienta CASE AxiomSys de Anlisis Estructurado permiten que con pulsaciones de ratn y barra de
herramientas de dibujos crear rpidamente un DFD. Adems permiten ir especificando las descripciones de cada elemento que
se incorpora al diagrama, con lo que al final se genera automticamente el Diccionario de Datos. La herramienta lleva a cabo
validaciones automticas de consistencia entre los DFD de mayor nivel y sus DFD hijos o de detalle.
-oOo-