Modelos Esenciales en el Desarrollo de Sistemas de Información

Paradigmas de los Sistemas de Información

Modelo Primitivo

Proceso: Codificación → Prueba

Inconvenientes

• Código pobremente estructurado tras varias iteraciones: código espagueti.
• Caro de desarrollar por las numerosas recodificaciones.
• Posible rechazo del usuario al no existir un análisis de requisitos.
• Caro de depurar por la falta de planificación.
• Caro de mantener por la falta de estructura y documentación.

Modelo Barroco

Proceso: Análisis → Diseño → Codificación

Inconvenientes

• Riesgo de agujeros negros.
• El desarrollo no es determinista; necesita iteraciones entre las fases.

Modelo Clásico

Proceso: Investigación preliminar → Análisis → Diseño → Codificación → Prueba → Mantenimiento

Generalidades

• Fases secuenciales.
• Permite la iteración de fases consecutivas.
• Obtención de documentos como criterio de finalización de fase.
• Distintas configuraciones.

Características

• Comienzo de una fase con el término de la anterior.
• Paso de fase al conseguir los objetivos.
• Apoyo a los gestores.
• El final de una fase puede suponer un punto de revisión.

Investigación Preliminar o Fase de Exploración

• Definición del problema.
• Determinación de los recursos necesarios.
• Análisis coste/beneficio.
• Estudio de viabilidad:
  • Técnica
  • Económica
  • Operacional

Inconvenientes

• Progresión secuencial.
• Rigidez: no es versátil, no permite flexibilidad.
• Monolítico: no entrega nada hasta el final del proceso y produce desesperación del cliente.

Consideraciones Finales

• Tiene un lugar destacado en los Sistemas de Información.
• Plantilla para adecuar los métodos.
• Similar al ciclo de vida genérico.
• Muy utilizado.
• Tiene problemas, pero es mejor que desarrollar sin una estructura.

Modelo Estructurado

Fases:

• Encuesta
• Análisis del sistema
• Diseño
• Implantación descendente
• Generación de las pruebas de aceptación
• Garantía de calidad
• Descripción del procedimiento
• Conversión de las Bases de Datos (BD)
• Instalación

Encuesta

• Determinación de los límites del sistema.
• Determinación de los requisitos del sistema.
• Estudio de viabilidad.
• Creación de un esquema que sirva de guía al resto de actividades.

Análisis del Sistema

• Especificación estructurada.

Diseño

• Desarrollar las especificaciones del análisis.
• Jerarquía de módulos.
• Modelo de implantación.
• Generación de modelos de bases de datos.

Implantación Descendente

• Codificación, prueba e integración de los módulos.

Generación de Pruebas de Aceptación

• Generación de casos de prueba de los requisitos.

Garantía de Calidad

• Realizar las pruebas de aceptación.

Descripción del Procedimiento

• Documentación.

Conversión de las Bases de Datos (BD)

• Conversión de la BD del sistema antiguo a la BD del nuevo sistema.

Instalación

• Forma radical.
• Forma gradual.

Forma de Llevar a Cabo las Actividades

• Enfoque radical.
• Enfoque conservador.

Factores

• Volubilidad del usuario.
• Experiencia del usuario.
• Presión en los ingenieros del software.
• Precisión en las estimaciones de recursos.

Modelo de Prototipos

Definición

Solución parcial que describe la interacción entre el usuario y la máquina, mostrando parte de su funcionalidad no optimizada.

Características Clave

• Proceso iterativo.
• Idea del software en líneas generales desde el punto de vista del usuario.
• Especificación de requisitos de forma concreta.
• Construcción rápida y a bajo coste.
• Desecho del prototipo (idealmente).
• Introduce cierta flexibilidad en la introducción de requisitos.

Ventajas

• Permite solventar objeciones del usuario.
• Sirve para formalizar la aceptación previa.
• Introduce flexibilidad en la captura de requisitos.
• Es útil cuando el área de aplicación no está definida, cuando el riesgo de rechazo es alto o como forma de evaluar el impacto de una aplicación.

Inconvenientes

• El sistema se puede llegar a deteriorar, tendiendo hacia el modelo primitivo.
• Se suele refinar el prototipo hacia el sistema final en lugar de desecharlo y empezar desde el principio.
• El cliente puede encontrar atractivo el prototipo y quedarse con él como sistema final.
• Relajación de los desarrolladores.
• No disminuye el tiempo entre la definición de los requisitos y la entrega del producto.
• Al usuario le desagrada que se deseche código.