METODOLOGÍA DE DESARROLLO DE SISTEMAS DE INFO

METODOLOGIAS DE DESARROLLO DE SISTEMAS

http://www.ricardochamberlain.com/

1. Modelo SDM (System Development Methodology)

CAP Gemini SMD, o SDM2 (Metodología de Desarrollo de Sistemas) es un método de desarrollo creado por la empresa holandesa de software PANDATA en 1970. El método es un modelo de catarata dividió en 7 fases que tienen un inicio y fin claro. Cada fase entrega (sub)productos, llamados “milestones” o hitos. SDM es un modelo de arriba-abajo. Iniciando desde el sistema como un todo, su descripción se hace más detallada con forme avanza el diseño.

El Modelo SDM

SDM es un modelo basado en fases. Antes de cada fase, debe de existir un acuerdo detallando las actividades de esa fase. Esos documentos son llamados documentos de hitos (milestone documents). Existen diferentes usos para estos documentos:

• Trazabilidad – tras la aplicación de fechas de entrega de los documentos de hitos, los clientes pueden llevar el control de si el proyecto se encuentra dentro del calendario.

• Consolidación – al aprobar el documento de hitos, obtiene un cierto estado. El cliente no puede cambiar ninguna de las especificaciones durante el desarrollo.

• En caso de ser necesario, el proyecto puede ser abortado. Esto normalmente ocurre al inicio del desarrollo.

Fases

El modelo posee 7 fases las cuales son ejecutadas sucesivamente, como el modelo de cascada. Las fases son:

1. Planeación de la Información (IP – Information Planning): definición del problema y plan inicial

2. Definición del Estudio (DS – Definition Study): análisis de requerimientos y revisión del plan

3. Diseño Básico (BD – Basic Design): diseno técnico de alto nivel y revisión del plan

4. Diseño Detallado (DD – Detailed Design): construcción del sistema (y revisión del plan)

5. Realización (R – Realization): pruebas y aceptación (y revisión del plan)

6. Implementación (I – Implementation): instalación, conversión de datos, y puesta en marcha

7. Operación y Soporte (O & S – Operation and Support): entrega al departamento correspondiente

Tras la finalización de una fase, se decide si se debe continuar con la siguiente fase o no; los términos de “GO” y “NO-GO” son usados para esto. La siguiente fase no iniciará hasta que no se dé el “Go”, el proyecto se conserva en su fase actual para ser mejorado o es cancelado completamente.

Planeación de la Información (IP – Information Planning)

En esta fase, se definen los problemas que tienen que ser resueltos por el proyecto. Se analiza la situación actual y la deseada, y seguidamente se definen las metas del proyecto. En esta fase, es importante considerar las necesidades de todos los involucrados, como futuros usuarios y su manejo. Con frecuencia, sus expectativas chocan, causando problemas más adelante durante la producción o durante el uso del sistema.

Definición del Estudio (DS – Definition Study)

En esta fase se realiza un estudio del proyecto en mayor detalle. La organización es analizada para determinar sus necesidades y determinar el impacto del sistema en la organización. Seguidamente se discuten y deciden los requerimientos del sistema. Se determina la viabilidad del proyecto. Algunos aspectos que se pueden considerar para la viabilidad del proyecto son:

• Prudente – están los recursos disponibles para completar el proyecto (tanto en tiempo y conocimientos.

• Significativo – necesita ser cambiado el sistema actual?

• Técnicos – puede el equipo actual soportar los requerimientos del sistema?

• Económicos – son los costos de desarrollo del sistema menores a las ganancias del sistema puesto en marcha?

• Organización – será capaz la organización de usar el nuevo sistema?

• Legal – tiene problemas de conflictos con las leyes el nuevo sistema?

Diseño Básico (BD – Basic Design)

En esta fase se crea el diseño del proyecto. Una vez que la definición del estudio ha determinado lo que el sistema debe de hacer, el diseño determina cómo se va hacer. Normalmente esto resulta en dos documentos: el diseño funcional o diseño de interfaz de usuario en donde explican lo que hace cada parte del sistema, y el diseño técnico de alto nivel, explicando cómo cada parte del sistema va a funcionar. Esta fase combina el diseño técnico y funcional y únicamente da un diseño general de todo el sistema. Normalmente la arquitectura del sistema se define en esta fase.

Diseño Detallado (DD – Detailed Design)

En esta fase se describe el diseño del producto en términos técnicos para que pueda ser entendido por desarrolladores. Una vez aprobado el diseño básico, el diseño técnico detallado describe cómo se va a desarrollar en términos de software. Normalmente esto resulta en una librería de documentación de fuentes: el diseño funcional por función, y el diseño técnico por función, explicando cómo cada parte del sistema va a trabajar, y cómo se relacionan entre ellos.

Realización (R – Realization)

En esta fase, el diseño pasa a ser un sistema funcional. En sistemas más viejos los programadores tenían que escribir todo el código, sistemas más nuevos permiten al programador convertir directamente el diseño en código, haciendo menor el trabajo y menor el margen de errores. Al mismo tiempo, el sistema se convierte más cercano al diseño; pero el diseño debe de estar bien hecho de lo contrario habrán errores que el programador podría no ver.

Implementación (I – Implementation)

La implementación, o fase de pruebas consiste de dos etapas: pruebas del sistema y pruebas de aceptación.

Durante la fase de pruebas el equipo –u otro equipo- se encarga de probar que el sistema haga las funciones que debe de hacer. Ellos no van a probar todos los posibles escenarios, pero sí van a probar que el sistema haga lo que ellos quieren que haga y que funcione de una forma sencilla. Cualquier defecto que se encuentre en esta fase serán reportados a los desarrolladores para su corrección.

Durante esta fase la organización implementa la versión final del sistema: el hardware es configurado, el software es instalado, se crea la documentación del usuario y, se capacitan los usuarios finales a cómo usar el sistema, la data existente se ingresa en el sistema.

Operación y Soporte (O & S – Operation and Support)

Una vez que el sistema ha sido implementado, es usado dentro de la organización. Durante su vida, necesita estar funcionando y preferiblemente mejorado.

2. Modelo en V

El Modelo en V representa un proceso de desarrollo de software y puede ser considerada una extensión del modelo en cascada. En lugar de moverse de forma linear hacia abajo, los procesos se curvean hacia arriba después de la fase de codificación, para forma la típica forma de V. El modelo en V demuestra la relación entre cada fase del ciclo de vida de desarrollo y su fase asociada de pruebas. Los ejes horizontales y verticales representan tiempo o compleción del proyecto (de izquierda a derecha) y nivel de abstracción.

Fases de Verificación

Análisis de requerimientos

En la fase de análisis de requerimientos, los requerimientos del sistema propuesta son obtenidos por medio del análisis de las necesidades del usuario. Esta fase se concentra en establecer lo que el sistema ideal debe de hacer. Sin embargo, no determina cómo el sistema será diseñado o construido. Normalmente los usuarios son entrevistados, y sus requerimientos, necesidades, problemas, entre otros, son documentados en un documento de requerimientos.

El documento de requerimientos del usuario normalmente describe las funciones, interfaces, desempeño, data, seguridad, entre otros, del sistema esperados por el usuario. También en esta fase se diseñan las pruebas de aceptación del usuario.

Existen diferentes métodos de obtener requerimientos, entre ellos: entrevistas, cuestionarios, análisis de documentos, observación, casos de usos, entre otros.

Diseño de Sistemas

La fase de diseño de sistemas es la fase donde los ingenieros en sistemas analizan y entienden el negocio del sistema propuesto estudiando el documento de requerimientos del usuario. Ellos descubren posibilidades y técnicas de cómo implementar dichos requerimientos. Si alguno de los requerimientos no es posible, se le notifica al usuario. Se encuentra la solución y se actualiza el documento de requerimientos.

Se procede a crear el documento de especificaciones de software el cual funciona como plano constructivo para la fase de desarrollo. El documento contiene la organización general del sistema, estructura de menú, estructuras de datos, entre otros. De igual forma puede poseer escenarios del negocio, ventanas de ejemplo, reportes que faciliten el entendimiento. También se pueden producir otros documentos técnicos tales como diagrama de entidad, diccionario de datos, etc. Los documentos para pruebas del sistema son creados en esta fase.

Diseño de la Arquitectura

Es considerado un diseño de alto nivel. La línea base para seleccionar la arquitectura es que debe de contemplar todo, en donde típicamente consiste en: lista de módulos, breve descripción de cada módulo, su relación de interfaces, dependencias, tablas de base de datos, diagrama

...