Un proceso de software detallado y
completo suele denominarse “Metodología”. Las metodologías se basan en una
combinación de los modelos de proceso genéricos (cascada, evolutivo,
incremental, etc.). Adicionalmente una metodología debería definir con
precisión los artefactos, roles y actividades involucrados, junto con prácticas y técnicas recomendadas, guías de adaptación de
la metodología al proyecto, guías para uso de herramientas de apoyo, etc.
Habitualmente se utiliza el término “método” para referirse a técnicas,
notaciones y guías asociadas, que son aplicables a una (o algunas) actividades
del proceso de desarrollo, por ejemplo, suele hablarse de métodos de análisis
y/o diseño.
La comparación y/o clasificación de
metodologías no es una tarea sencilla debido a la diversidad de propuestas y
diferencias en el grado de detalle, información disponible y alcance de cada
una de ellas. A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar
artefactos producidos en actividades de análisis y diseño (es decir,
concentrándose no en el desarrollo sino más bien en el análisis y diseño como
tal), podemos clasificar las metodologías en dos grupos: Metodologías
Estructuradas y Metodologías Orientadas a Objetos. Por otra parte, considerando su filosofía de
desarrollo, aquellas metodologías con mayor énfasis en la planificación
y control del proyecto, en especificación precisa de requisitos y modelado,
reciben el apelativo de Metodologías Tradicionales (o peyorativamente
denominada Metodologías Pesadas, o Peso Pesado). Otras metodologías,
denominadas Metodologías
Ágiles, están más orientadas a la generación de código con ciclos muy cortos de desarrollo,
se dirigen a equipos de desarrollo pequeños, hacen especial hincapié en
aspectos humanos asociados al trabajo en equipo e involucran activamente al
cliente en el proceso. A continuación se revisan brevemente cada una de estas
categorías de metodologías.
ü Metodologías Estructuradas
Los métodos estructurados comenzaron a desarrollarse a
fines de los 70’s con la Programación Estructurada, luego a mediados de los
70’s aparecieron técnicas para el Diseño (por ejemplo: el diagrama de
Estructura) primero y posteriormente para el Análisis (por ejemplo: Diagramas
de Flujo de Datos). Estas metodologías son particularmente apropiadas en
proyectos que utilizan para la implementación lenguajes de 3ra y 4ta generación.
La metodología de análisis y diseño estructurado, conocido
por sus siglas en inglés como SA/SD (Structured Analysis and Structured Design)
ha tenido mucho seguimientos durante las últimas décadas (Yourdon y Constantine
1978, DeMarco 1979, Page-Jones 1980, Ward y Mellor 1985, Yourdon 1989, Martin y
Jackson). Existen múltiples variaciones al concepto básico estructurado como
son SADT (Structured Analysis and Design Technique) (Ross, 1985) y RDD
(Requirement Driven Design) basado en SREM (Alford, 1985). La metodología
estructurada se basa primordialmente en la división entre funciones y datos. La
metodología estructurada identifica durante el análisis las funciones del
sistema, mientras que durante el diseño identifica los datos. Otros enfoques
como la programación funcional rompen con este esquema (Backus 1977, Bird and
Wadler 1988).
Mirar
libro de Análisis Estructurado Whitten
Durante
las fases de requisitos y análisis se utilizan las siguientes herramientas para
describir el sistema lógico:
ü Diagramas de flujo de
datos
ü Especificación de
procesos
ü Diccionario de datos
ü Diagramas de
transición de estados
ü Diagramas de
entidad-relación”.
Durante
las fases de diseño e implementación, los detalles son incorporados a los
modelos anteriores y los diagramas de flujo de datos son convertidos a cartas
estructuradas (“charts”) las cuales especifican el código fuente.
Diagramas
de flujo de datos (DFD) sirven para modelar la transformación de los datos
en el sistema, y es uno de los modelos más importantes de SA/SD. Un diagrama de
flujo de datos se compone:
ü Procesos
ü flujo de datos
ü actores (entidades
externas)
ü almacenamiento de
datos
Durante
el diseño, los procesos del DFD son agrupados en tareas y asignados para su
ejecución en el sistema operativo. Procesos del DFD se convierten en funciones
del lenguaje de programación, y una carta estructurada es creada mostrando el
árbol de llamadas de procedimientos.
Especificación
o Diagrama de procesos sirve para describir los procesos a nivel más detallado.
Esta especificación comienza desde el nivel más alto del diagrama de flujo de
datos, donde los procesos se dividen de manera recursiva, con ayuda de
subdiagramas, hasta que existen procesos suficientemente pequeños que sean
fáciles de implementar.
Esta
especificación puede ser expresada con tablas de decisión, pseudo-código, u
otras técnicas.
Diccionario
de datos contiene detalles omitidos en los diagramas de flujo de
datos, definiendo el significado de los nombres de los flujos y almacenamiento
de datos.
Diagramas
de transición de estados modelan el comportamiento que depende del tiempo. La
mayoría de los diagramas de transición describen procesos de control o tiempo
de ejecución de funciones y acceso a datos causado por eventos.
Diagramas
de Entidad-Relación (ER) (Chen, 76) muestran la relación entre el
almacenamiento de datos que de otra forma sólo serían vistos en la
especificación o diagrama de proceso.
Cada
elemento del ER corresponde a un dato almacenado. (La notación del diagrama de
clases es una extensión del diagrama ER.) Este es el enfoque más común para el
modelo de información. ER es una técnica gráfica que es popular ya que su
notación es fácil de comprender, y suficientemente poderosa para modelar
problemas del mundo real. Los diagramas ER son usualmente traducidos
directamente a implementaciones de bases de datos.
