Investigacion

Análisis estructurado.
4.1. Introducción.
4.2. Notaciones.
4.2.1. Diagramas de flujo de datos.
4.2.2. Especificaciones de proceso.
4.2.3. Diagramas de flujo de control.
4.2.4. Especificaciones de control.
4.2.5. Diagramas de estados.
4.2.6. Diagramas Entidad/Relación.
4.3. Diccionario de datos.
4.4. Metodología del análisis estructurado.
4.4.1. Fases.
4.4.2. Consistencia entre losmodelos.
4.5. Modelos del sistema: esencial y de implementación.
4.6. Ejemplos. 
Bibliografía
Ingeniería del Software: un enfoque práctico
R.S. Pressmann. Mc Graw Hill. Madrid, 1993. 3ª Edición.
Modern Structured Analysis
E. Yourdon. Prentice-Hall. New Jersey, 1989.
Strategies for Real-Time System Specification
D.J. Hatley & I.A. Pirbhai. Dorset House. New York, 1988.
Object-OrientedModeling and Design
Rumbaugh, J. et al. Prentice Hall, 1991.

Tema 4. Análisis estructurado.
4.1. Introducción.
Todos los métodos de análisis de requisitos se basan en la construcción de modelos del sistema que se pretende desarrollar. Utilizando alguna notación, propia de cada método, creamos modelos que reflejen el sistema, y aplicamos técnicas de descomposición y razonamiento top-down, de talforma que al final establecemos la esencia del sistema que pretendemos construir.
El desarrollo de modelos presenta algunas ventajas claras:
• Permite centrarse en determinadas características del sistema, dejando de lado otras menos significativas. Esto nos permite centrar las discusiones con el usuario en los aspectos más importantes del sistema, sin distraernos en características delsistema que sean irrelevantes.
• Permite realizar cambios y correcciones en los requisitos a bajo coste y sin correr ningún riesgo. Si nos damos cuenta que no habíamos entendido las necesidades del usuario o si el usuario ha cambiado de idea acerca de los requisitos del sistema, podemos cambiar el modelo o incluso desecharlo y empezar de nuevo. Si no hiciésemos modelos, los cambios en losrequisitos sólo se efectuarían después de construir el producto software, y el coste sería muchísimo mayor.
• Permite verificar que el ingeniero del software ha entendido correctamente las necesidades del usuario y que las ha documentado de tal forma que los diseñadores y programadores pueden construir el software.
Sin embargo, no todas las técnicas de análisis logran estos tres objetivos: unadescripción del sistema de 500 páginas (que sería, en sentido estricto, un modelo) oculta las características del sistema, tanto las relevantes como las irrelevantes, su desarrollo puede costar más que el del propio sistema, es difícil de modificar y no permite verificar si se han establecido los requisitos.
El análisis de requisitos clásico, usado hasta finales de los 70, consistía en redactarespecificaciones funcionales, en forma de documentos textuales, de este tipo:
• Eran monolíticas. Para entender el sistema había que leerse la especificación de cabo a rabo. No había posibilidad de que ni el analista ni el usuario pudiesen centrarse en una determinada parte de la especificación, sin tener que leerse el resto.
• Eran redundantes. La misma información se repartía en diferentespartes del documento. Debido a esto cualquier cambio que se hiciese en la especificación debía reflejarse en varios puntos del documento. Esta situación produce con frecuencia inconsistencia: si no se cambiaba en todos estos lugares la misma información (p.ej. el mismo código) tenía definiciones distintas.
• Eran ambiguas. Al estar escritas en lenguaje natural, podían ser interpretadas de formadistinta por analistas, usuarios, diseñadores o programadores. Hay estudios que muestran que el 50% de los errores encontrados en el sistema final y el 70% del coste de la corrección de los errores surgía de este tipo de malentendidos.
• Eran imposibles de mantener o modificar. Por todas las razones anteriores, la especificación del sistema estaba totalmente obsoleta cuando finalizaba el...