Diseño estructurado de sistemas de información: análisis y desarrollo

Análisis y Diseño Estructurado de Sistemas de Información

Objetivo

Obtener una especificación detallada del sistema de información (SI), y de sus interfaces con otros sistemas, que satisfaga las necesidades de información de los usuarios y sirva de base para el diseño.

Integración de Metodologías

Integra las actividades de análisis estructurado y orientado a objetos (OO). Se refinan los productos obtenidos en el proceso EVS. Productos generados:

• Catálogo de requisitos
• Glosario
• En AE (Análisis Estructurado), o Contexto del sistema o Modelo conceptual de datos
• En AOO (Análisis Orientado a Objetos), o Modelo del negocio / Modelo del dominio
• Catálogo de estándares y normas
• Catálogo de usuarios (participantes y finales)
• Entorno tecnológico del sistema
• Plan de trabajo

Definición y Validación de Requisitos

Objetivo: Definición, análisis y validación de los requisitos.

• Se completa el catálogo de requisitos.
• Modelos gráficos de requisitos: casos de uso (obligatorios en AOO, opcionales en AE)
• Las tareas se realizan de forma iterativa con continuas realimentaciones y solapamientos.

Sesiones de trabajo con usuarios

Sesiones de trabajo con los usuarios para extraer los requisitos (con prioridades): Técnica de recogida de información.

• Catálogo de requisitos
• Modelo de casos de uso

Requisitos Funcionales

Con casos de uso (obligatoriamente) en AOO:

• Actores
• Casos de uso
• Breve descripción de cada caso de uso

Requisitos No Funcionales

• Restricciones del entorno
• Niveles de servicio del sistema:
  • Rendimiento, seguridad, implantación, disponibilidad...

Análisis del Sistema de Información (ASI)

Objetivo: Validación de los requisitos. Mediante esta tarea, los usuarios confirman que los requisitos especificados en el catálogo de requisitos, así como los casos de uso, son válidos, consistentes y completos.

Pasos del Proceso de Análisis

En general, el proceso de análisis debería seguir los siguientes cinco pasos:

1. Identificar las fuentes de información.
2. Realizar las preguntas apropiadas.
3. Analizar la información.
4. Confirmar con los usuarios lo que parece haberse comprendido de los requisitos.
5. Sintetizar los requisitos en un documento.

Tipos de Requisitos

Requisitos Funcionales: describen la funcionalidad o los servicios que se espera que el sistema provea: sus entradas y salidas, excepciones, etc., en resumen, su lógica. Requisitos No Funcionales: se refieren a las propiedades emergentes del sistema como la fiabilidad, el tiempo de respuesta, la capacidad de almacenamiento, la capacidad de los dispositivos de entrada/salida, y la representación de datos que se utiliza en las interfaces del sistema.

Características de un Buen Análisis de Requisitos

Las características deseables para un buen análisis de los requisitos son las siguientes [IEEE 1984b]:

• No ambigua
• Completa
• Fácil de verificar
• Consistente
• Fácil de modificar
• Fácil para identificar el origen o las consecuencias de cada requisito
• Fácil de utilizar durante la fase de explotación y mantenimiento

Visión Panorámica del Análisis y Diseño Estructurado

Análisis

Diagramas de Flujo de Datos

Diseño

Diagrama de Estructuras

• Visión general de las funciones y transformaciones de datos en una organización
• Modelo lógico y gráfico del sistema, también como modelo físico
• Identifica entradas, salidas, procesos y relaciones con el exterior

Diccionario de Datos

Es un conjunto de metadatos, es decir, de información (datos) sobre datos. Contiene las definiciones de todos los elementos de los diagramas.

Implementación

• Manual
• Procesador de textos
• Base de datos
• Automático e integrado

Diseño Estructurado (DE)

El diseño lógico de los requisitos del nuevo sistema de información se convierte en un modelo de la aplicación, plasmado en un DIAGRAMA DE ESTRUCTURA. En el paso AE → DE:

• Análisis de transacciones
• Análisis de transformaciones

Diagramas de Flujo de Datos (DFD)

Procesos

Nombres únicos, significativos y concisos. Preferiblemente expresados en función de las entradas y salidas.

Diagrama de Contexto

Es el DFD más general. Está formado por un solo macroproceso (el sistema), las entidades externas (fuentes y destinos) y sus relaciones con el macroproceso. Delimita el sistema y su entorno.

Entidades Externas

Señalan los límites del sistema y establecen sus relaciones con el entorno.

Flujos de Datos

Los nombres de los flujos de datos (FD) deben ser únicos, significativos y concisos. Son datos, así que nómbralos como datos. Pueden estar indistintamente en singular o en plural, ya que en los DFDs no se representan cantidades.

Flujos de Control

En los DFDs no se muestra el control ni el orden de ejecución. No se puede mostrar:

• Procesos que se realizan antes que otros
• Sincronización
• Periodificación

Extensiones al AE para sistemas en tiempo real

• (Ward & Mellor 85)
• (Hatley & Pirbhai 87)

Almacenes de Datos

Nombre único, significativo y conciso. Convenciones de nombres en los FD a/desde un almacén:

• No lleva etiqueta
• La etiqueta es la misma que la del almacén
• La etiqueta es distinta de la del almacén

Consistencia en el DFD

Cada proceso en un diagrama “padre” es una consolidación del DFD “hijo”. Balanceo de DFDs. Las E/S de un proceso “padre” deben corresponderse con las E/S del DFD “hijo” que lo explica.

Jerarquía de DFDs

En un DFD completo cada proceso tiene un número único que lo identifica en función de su situación en la jerarquía. Cada DFD tiene también un número único que coincide con el proceso que describe. Las hojas o nodos terminales corresponden a “procesos primitivos” o indescomponibles. Para cada proceso primitivo existirá una miniespecificación.

DFD 0

El primer diagrama general que sigue al de contexto es el número 0 por convenio. En el DFD 0 se hace una descomposición en subsistemas, es decir, se indican los procesos más importantes en el sistema.

Concepto y Principios del Diseño

El diseño es un proceso a través del cual los requerimientos establecidos en la fase de análisis deben traducirse en una representación modular del producto de software que se precisa construir, acompañado de los procedimientos para que cada módulo lleve a cabo su tarea y de las estructuras de datos que debe procesar.

El diseño estructurado es un método de configuración de la organización modular del software que se desarrolla a partir de los flujos de datos que contiene la especificación de requerimientos obtenida en la fase de análisis bajo enfoque estructurado. Consiste en el diseño de programas como estructuras de funciones únicas y de relativa independencia.

Efectividad del Diseño

Para evaluar la efectividad de una representación de diseño, es preciso establecer"criterios para un buen diseñ", entre los cuales se destacan:

• El diseño debe exhibir una organización jerárquica con mecanismos de control que no atenten contra la independencia relativa de cada componente de la jerarquía.

Modularidad

“Módulo es una unidad claramente definida y manejable que forma parte de los elementos constituyentes del software”. “La modularidad consiste en el particionamiento del software en elementos con nombres y direcciones separadas que se denominan módulos, los cuales en su composición generan la totalidad que debe ser capaz de resolver el problema global”. Tiene que ver con la separabilidad de las funciones que en conjunto cumplen un objetivo mayor.

Beneficios de la Modularidad

• Programas más simples, fáciles de comprender, verificar, programar, depurar, mejorar y alterar por partes.
• Módulos desarrollados con relativa independencia.
• Disminución de la posibilidad de errores al reducir la complejidad.
• Programas que pueden evaluarse por partes, facilitando las pruebas.
• Programas más fáciles de alterar.
• Módulos de función única reutilizables.

La posibilidad de cometer errores disminuye al reducir las líneas de código que se manejan simultáneamente. La rotación de personal se hace menos crítica.

Fan out y Fan in

El Fan out es el número de módulos controlados directamente por otro módulo (número de subordinados inmediatos). El Fan in indica cuántos módulos controlan directamente un determinado módulo (número de superiores inmediatos). Un módulo que controla a otro es"superordinad", y uno controlado por otro es"subordinad".

Abstracción

Cuando se considera una solución modular, se puede plantear en distintos niveles de abstracción. Un nivel superior supone una solución en términos amplios, usando un lenguaje del entorno del problema. A niveles más bajos, se toma una orientación más procedimental, combinando terminología orientada al problema con una orientada a la implementación. El nivel más bajo permite la implementación directa.

Factores de Calidad: Acoplamiento y Cohesión

El acoplamiento corresponde al grado de independencia entre dos módulos. Minimizarlo es prioritario. Se logra eliminando relaciones innecesarias, reduciendo el número de relaciones necesarias y debilitando la dependencia de las relaciones necesarias.

La cohesión corresponde a la medida de relación funcional de los elementos de un módulo (instrucciones, definiciones de datos, llamadas a otros módulos). La idea es organizar estos elementos para que tengan una mayor relación entre ellos al realizar la tarea específica del módulo.

Diseño Detallado

Especificación

Mediante las miniespecificaciones del análisis. Este método considera que las miniespecificaciones generadas durante la fase de análisis sirven también como especificación de módulos. La limitación es que no siempre existe una correspondencia uno a uno entre las burbujas (procesos) y los módulos del diagrama de estructura.

Especificación por Pseudocódigo

El pseudocódigo es un lenguaje informal similar al lenguaje estructurado, más preciso y detallado que la especificación por interfaz-función. Tiene sintaxis fija para constructores, declaración de datos y módulos, y sintaxis libre para describir características de procesamiento.