METODOLOGÍAS PARA DESARROLLO DE SOFTWARE

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.