Desarrollo de Aplicaciones Informáticas: Ciclo de Vida y Metodologías

Introducción al Desarrollo de Aplicaciones Informáticas

• Ciclo de Vida del Software

Conceptos: Ciclo de Vida y Ciclo de Desarrollo

Se entiende por ciclo de vida del software al conjunto de fases por las que pasa el software a lo largo del tiempo, desde que se empieza a construir hasta que se deja de usar.

Se entiende por ciclo de desarrollo del software al conjunto de fases por las que pasa el software a lo largo del tiempo, desde la fase de análisis hasta la entrega del sistema al usuario.

Procesos del Ciclo de Vida del Software

La norma ISO 12207-1 indica las actividades a realizar durante el ciclo. Según esta norma, las actividades a realizar se agrupan en:

• Los procesos principales son aquellos que resultan útiles a las personas que inician o realizan el desarrollo, la explotación o el mantenimiento del software.
• Los procesos de soporte sirven de apoyo al resto de los procesos.
• Los procesos generales ayudan a establecer y mejorar la organización. Son los que emplea una organización para llevar a cabo funciones tales como la gestión.

Procesos Principales

• Procesos de adquisición: Contiene actividades que el cliente realiza para adquirir el producto software.
• Proceso de suministro: contiene actividades que el suministrador realiza; se inicia en el momento se prepara una propuesta para responder la petición del comprador y finaliza con la entrega del producto al comprador.
• Proceso de desarrollo: contiene todas las actividades de desarrollo del producto software: desde el análisis, diseño, pruebas, e instalación, hasta la aceptación del software.
• Proceso de explotación: incluye la explotación del software y el soporte operativo a los usuarios.
• Proceso de mantenimiento: aparece cuando el software necesita modificaciones.

Procesos de Soporte

• Proceso de documentación: incluye todas las actividades que permiten planificar, diseñar, desarrollar, editar, distribuir y mantener los documentos necesarios para todas las personas involucradas en el software.
• Proceso de gestión de la configuración: aplica procedimientos administrativos y técnicos.
• Proceso de aseguramiento de la calidad: garantiza que el software cumple con los requisitos especificados.
• Proceso de verificación: verifica si los requisitos del sistema están completos y son correctos, y si cumplen los requisitos impuestos sobre ellos.
• Proceso de validación: determina si el sistema o software final cumplen los requisitos previstos para su uso.
• Proceso de revisión conjunta: evalúa el funcionamiento general del sistema.
• Proceso de auditoría: permite establecer si se han cumplido los requisitos, los planes y el contrato.
• Proceso de resolución de problemas: permite analizar y eliminar los problemas.

Procesos Generales (de la Organización)

• Proceso de gestión: comprende las actividades de planificación, seguimiento, evaluación, revisión, etc.
• Proceso de infraestructura: establece la infraestructura necesaria: hardware, software, herramientas, normas, técnicas e instalaciones para el desarrollo, la explotación o el mantenimiento.
• Proceso de mejora: establece, controla y mejora los procesos del ciclo de vida del software.
• Proceso de formación: proporciona formación y mantiene al personal formado.

Procesos de Adaptación

Consisten en adaptar los procesos al proyecto software y a la empresa que va a trabajar con él.

Modelos del Ciclo de Vida del Software

Modelo en Cascada

Es el modelo más antiguo y también el más utilizado. Sugiere un enfoque sistemático y secuencial del desarrollo de software que comienza en un nivel de análisis de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.

• Análisis de los requisitos del sistema o Análisis del sistema: el trabajo comienza estableciendo requisitos de todos los elementos del sistema.
• Análisis de los requisitos del software o Análisis Conceptual: Se especifican y documentan todos los requisitos que debe cumplir el software.
• Diseño: El proceso de diseño traduce los requisitos en una representación del software que se pueda evaluar antes de que comience la generación del código. Podemos dividirlo en dos fases:
  • Diseño preliminar o arquitectónico: consiste en transformar los requisitos del software en una arquitectura de alto nivel que identifique los principales componentes. También se diseñan los requisitos que deben cumplir las pruebas y se planifica la integración del software.
  • Diseño detallado del software: se trata de realizar un diseño detallado para cada uno de los componentes software.
• Codificación: El diseño se debe traducir en una forma legible por la máquina. Además, se documentan y prueban cada uno de los componentes software y las bases de datos desarrollados. Consiste en traducir el diseño lógico de forma que el resultado obtenido sea ejecutable por la máquina.
• Pruebas y puesta a punto: Se estudian y comprueban los resultados obtenidos por los programas elaborados. Si se encuentran errores se modifican los programas.
• Explotación y Mantenimiento: Una vez probada la nueva aplicación, se instala definitivamente para entrar en la fase de explotación y mantenimiento. Inevitablemente, surgirán cambios debido a errores.

Características:

• Cada fase empieza cuando ha terminado la fase anterior.
• Ayuda a prevenir que se sobrepasen las fechas de entrega y los costes esperados.
• Al final de cada fase, tienen la oportunidad de revisar el progreso del proyecto.
• Es sencillo de implantar y gestionar.

Inconvenientes:

• Es lineal y el desarrollo del software no lo es.
• Es difícil que el cliente exponga explícitamente todos los requisitos al principio. Este modelo lo requiere.
• Se tarda mucho tiempo en recorrer todo el ciclo.
• El cliente debe tener paciencia porque no tendrá una versión del software hasta que el proyecto esté muy avanzado.

Modelo de Construcción de Prototipos

El cliente define los objetivos generales del software a construir, pero no es capaz de identificar los requisitos detallados de entrada, procesamiento y salida. En estas circunstancias, este modelo puede ofrecer un buen enfoque.

También es recomendable cuando el sistema es interactivo con mucha operación por pantalla y el usuario está muy preocupado por el formato.

Comienza con la definición, por parte del cliente y del desarrollador, de los objetivos globales y la identificación de los requisitos conocidos. Entonces el desarrollador realiza un diseño rápido o prototipo. El cliente evalúa el prototipo y lo utiliza para refinar los requisitos del software a desarrollar.

Ventajas:

• Mejora la comunicación desarrollador – cliente.
• Mejora la identificación de los requerimientos del cliente.
• Satisface la curiosidad del cliente (enseguida puede ver cosas).

Inconvenientes:

• El principal inconveniente es la identificación del prototipo con el producto final. No entiende que hay que construir el producto completo.
• Se corre el peligro de dar posibles soluciones técnicas.

En general, este modelo suele ser efectivo si se definen bien las reglas del juego al principio.

Modelo de Procesos Evolutivos de Software

A veces, las estrictas fechas tope hacen que sea imposible finalizar un producto completo, por lo que se debe introducir una versión limitada. También puede ocurrir que se comprenda perfectamente el conjunto de requisitos centrales del sistema, pero aún se deben definir los detalles de extensiones del mismo. Por tanto, ambos modelos no tienen en cuenta la naturaleza evolutiva del software. Los modelos evolutivos se caracterizan por la forma en que permiten a los ingenieros del software desarrollar versiones cada vez más completas del mismo.

Modelo Incremental

Combina elementos del modelo en cascada con la filosofía interactiva de construcción de prototipos.

El sistema software se va creando añadiendo componentes funcionales al sistema. En cada paso se actualiza el sistema con nuevas funcionalidades. El primer incremento suele ser el producto central, se afrontan los requisitos básicos, pero muchas funciones suplementarias quedan sin extraer. El cliente utiliza el producto central y como resultado se desarrolla un plan para el incremento siguiente. Este proceso se repite hasta que se elabore el producto completo. Hay que tener en cuenta que en cualquier incremento se puede utilizar el modelo de construcción de prototipos.

El modelo incremental es interactivo, y se centra en la entrega de un producto operacional con cada incremento. Este modelo se ajusta muy bien a entornos de alta incertidumbre. También es útil cuando no hay suficiente personal para una implementación completa en la fecha límite.

Ventajas:

• Satisface la curiosidad del cliente.
• Posibilidad de detener el proyecto sin perder todo lo realizado.
• Mayor flexibilidad ante cambios en los requerimientos durante el desarrollo.

Inconvenientes:

• Cada nuevo módulo se debe integrar en el sistema sin afectar a lo que ya está funcionando.
• El diseño y desarrollo de los diferentes módulos debe ser coherente entre sí.
• Gran tendencia a la degeneración del control del proyecto ante la imposibilidad de verlo como un todo.

Modelo en Espiral

Acompaña la naturaleza interactiva de construcción de prototipos con los aspectos controlados y sistemáticos del modelo en cascada.

El software se desarrolla en una serie de versiones incrementales. Las primeras podrían ser un modelo en papel o un prototipo; durante las últimas, se producen versiones cada vez más completas.

El modelo en espiral se divide en regiones de tareas:

• Comunicación con el cliente:
  • Los objetivos de la parte del producto que está siendo elaborada.
  • Las alternativas principales de la implementación de esa porción del producto.
  • Las restricciones impuestas para cada alternativa.
• Planificación: contiene las tareas requeridas para definir los recursos, el tiempo y otra información relacionada con el proyecto.
• Análisis de riesgos: evaluar los riesgos técnicos y de gestión. Se definen los riesgos existentes basándose en los requisitos anteriores y se decide el modo de resolverlos y las posibles alternativas a cada uno de ellos.
  • Si los riesgos han sido resueltos satisfactoriamente, evaluar los resultados de la fase y planificar la siguiente.
  • Si alguno de los riesgos no puede ser resuelto, abandonar el proyecto inmediatamente.
• Ingeniería: para construir una o más representaciones de la aplicación (prototipos).
• Construcción y adaptación: tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.
• Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software.

En el modelo en espiral, cada ciclo se completa con una revisión. Los planes para las sucesivas fases pueden incluir una partición del producto en incrementos o en componentes. El modelo en espiral utiliza la construcción de prototipos como mecanismo de reducción de riesgos. Mantiene el enfoque sistemático de los pasos sugeridos por el ciclo de vida clásico pero lo incorpora al marco de trabajo interactivo.

Ventajas:

• Inclusión del análisis de riesgos a lo largo del proceso.
• Desarrollo de software = proceso evolutivo.
• Uso de prototipos, uso de simulaciones.
• El cliente ve evolucionar el proyecto.
• Tratamiento del mantenimiento al mismo nivel que el desarrollo (se trata de otra espiral más).

Inconvenientes:

• Difícil de convencer al cliente de su utilidad (hay que realizar muchos test y esto cuesta dinero).
• Implantación muy compleja.
• Necesita gran habilidad en la valoración de riesgos.
• Método muy nuevo.

Conclusión de los Modelos del Ciclo de Vida del Software

Si se está familiarizado con la tecnología y con los métodos de desarrollo, se pueden hacer mejores predicciones de tiempos, costes, etc. y, por tanto, el ciclo en cascada es más adecuado. Cuando la tecnología es nueva y es necesario experimentar, se utilizaría un ciclo de vida en espiral o prototipado.

En el caso de proyectos grandes se suele utilizar una aproximación por fases.

Metodologías de Desarrollo de Software

Introducción

El ciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto, la metodología indica cómo.

Clasificación de las Metodologías de Desarrollo

Metodologías Estructuradas

Proponen la creación de modelos del sistema que representan los procesos, los flujos y la estructura de los datos de una manera descendente. Se pasa de una visión más general hasta llegar a un nivel de abstracción más bajo.

Orientadas a los Procesos o Tratamientos

Son las que se centran en la parte del proceso. Se basan en la utilización de un método descendente de descomposición funcional para definir los requisitos del sistema. Se apoyan en técnicas gráficas dando lugar a un nuevo concepto: la especificación estructurada, Análisis y Diseño Estructurado.

Una especificación estructurada es un modelo gráfico, particionado, descendente y jerárquico de los procesos del sistema y de los datos utilizados por los procesos. Se compone de:

• Diagramas de Flujo de Datos (DFD): representan los procesos que debe llevar a cabo un sistema a distintos niveles de abstracción y los datos que fluyen entre las funciones.
• Diccionario de Datos (DD): Es un listado organizado de todos los datos que interesan en el sistema.
• Especificaciones de proceso: definen cómo se obtienen las salidas del proceso a partir de sus entradas.

Principales metodologías estructuradas orientadas a los procesos:

• Metodología de DeMarco (1979)

  Sus pasos son:

  • Estudio del sistema físico actual. Antes de estudiar las necesidades del usuario, se comienza haciendo un modelo del sistema en el que se muestran los procedimientos.
  • Derivación al modelo lógico actual. Se obtiene un modelo derivado.
  • Derivación al nuevo modelo lógico. Genera un modelo que describe qué hay que hacer teniendo en cuenta necesidades del usuario.
  • Creación de modelos físicos alternativos. A partir del modelo anterior, se establecen diferentes alternativas para escoger la más conveniente.
  • Valorar cada opción estudiando los costes y beneficios.
  • Seleccionar una opción.
  • Desarrollar la opción elegida y empaquetar la especificación.

• Metodología de Gane y Sarson

  Es parecida a la de DeMarco. Las diferencias son: elimina el primer paso y crea uno nuevo; no sólo elabora una especificación estructurada, sino que también construye un modelo lógico de datos en tercera forma normal.

• Metodología de Yourdon/Constantine (1989)

  Sus pasos son:

  • Realizar los DFD del sistema.
  • Evaluación del diseño midiendo la cohesión y el acoplamiento.
  • Preparación del diseño para la implantación.

Orientada a los Datos

Estas metodologías representan los requisitos del software centrándose en la estructura de los datos. Primero se definen las estructuras de datos y a partir de éstas se obtienen los procedimientos. Se centran en la creencia de que los datos constituyen el corazón del sistema.

Podemos dividirlas en dos tipos:

• Orientadas a estructuras de datos jerárquicas.
• Orientadas a estructuras de datos no jerárquicas: este modelo está formado por un conjunto de entidades de datos básicas y las interrelaciones que existen entre ellas.
• Mixtas: Utiliza una mezcla de los anteriores.

Metodologías Orientadas a Objetos

Las metodologías orientadas a objetos examinan el sistema como un conjunto de objetos que interactúan entre sí.

Utilizan un enfoque integrador estudiando datos y tratamientos en una unidad denominada objeto.

Podemos distinguir dos enfoques diferentes:

• “Revolucionarios” o “puros”. Entienden la orientación al objeto como un cambio profundo en la forma de analizar y diseñar respecto a las metodologías estructuradas.
• “Evolutivos”. Piensan que el análisis y el diseño estructurado constituyen la base para el desarrollo orientado al objeto.

Sistemas en Tiempo Real

Son sistemas muy dependientes del tiempo que procesan información más orientada al control que a los datos.

Se controlan por medio de eventos externos.

Los STR se caracterizan porque:

• Se lleva a cabo el proceso de muchas actividades de forma simultánea (concurrencia).
• Se asignan prioridades a determinados procesos.
• Existe comunicación entre tareas.
• Existe acceso simultáneo a datos comunes.

Principales Metodologías de Desarrollo de Europa

Metodología Merise

• Estudio de los tratamientos por un lado y de los datos por otro.
• Uso del modelo E/R.
• Realiza un completo reparto de tareas y responsabilidades entre desarrolladores, directivos y usuarios.
• Incorpora un ciclo de vida más largo que los existentes hasta entonces.
• Introducción de dos ciclos complementarios: ciclo de abstracción y ciclo de decisión.

Metodología SSADM

Método Estructurado de Análisis y Diseño de Sistemas. Introduce la técnica del “diseño del diálogo” utilizada para diseñar la interfaz de usuario.

Metodología Métrica

Su objetivo principal es crear un entorno que permita al equipo de trabajo construir sistemas, que:

• Den soluciones a los objetivos considerados prioritarios en la Administración.
• Se desarrollen cuando el usuario los necesite y de acuerdo a los presupuestos y duración estimados.
• Se mantengan fácilmente para soportar los cambios futuros en la organización.