Desarrollo de Software Basado en Componentes: Requisitos, Fases y Mejores Prácticas

Diagnóstico de la Situación y Necesidad del Sistema

Se debe realizar una descripción concisa de la situación actual y las mejoras que traerá la implementación del sistema. En esta etapa, se puede decidir que no es necesario un nuevo desarrollo o que se reutilizará uno existente. Por lo tanto, es fundamental explicar por qué se justifica el desarrollo en cuestión.

Declaración de Propósitos

Consiste en una descripción textual, breve y concisa del propósito del sistema, de no más de un párrafo. Debe incluir la enumeración de los beneficios tangibles y cuantificables que se lograrán con el nuevo sistema.

Diagrama de Contexto

Muestra en forma detallada las distintas interfaces con el ambiente. Representa gráficamente las personas, organizaciones, máquinas o sistemas con los que el nuevo sistema se comunica, así como los datos que recibe y produce.

Listado de Eventos

Es especialmente importante en sistemas interactivos, no justificándose su aplicación en desarrollos batch. Consiste en un listado de estímulos que ocurren en el ambiente a los cuales el sistema debe responder. Debe incluir situaciones de fallo o error y los agentes que estimulan el sistema.

Catálogo de Requerimientos

Incluye los requerimientos, tanto funcionales como de cualquier otro tipo, que pudieran haberse detectado en las entrevistas con usuarios.

Glosario

Es una descripción de términos que hacen al negocio, cuya comprensión es necesaria por parte de diseñadores y programadores. Tiene la forma de un diccionario, con los términos y sus significados.

Diagrama de Gantt

Se debe elaborar el plan de trabajo del proyecto en forma de diagrama de Gantt o similar, que luego se irá actualizando al final de cada etapa.

Modelo de Comportamiento

Define el comportamiento del sistema para manejarse con éxito en el ambiente. Ese comportamiento se establece tomando como unidad cada uno de los estímulos de la lista de eventos ya comentada.

Diagrama de Flujo de Datos

Es un diagrama que muestra los procesos y los flujos de datos entre los mismos. Se lo llama también diagrama de burbujas. Es fundamental cuando las funciones o procesos son más importantes que los datos.

Especificación de Proceso

Es la especificación de los procesos que se diagraman en el diseño de flujo de datos. De todas maneras, solo tiene sentido realizarlo cuando los procesos tengan cierta complejidad.

Modelo de Implantación de Programas

Organización jerárquica de módulos en una tarea. Se realiza con un diagrama estructurado.

Interfaces de Usuario

Se especifican con prototipos de las interfaces de usuario y reportes. Estas pueden consistir en dibujos o bocetos que muestren cómo van a ser las interfaces, aun cuando estos sean modificados posteriormente.

Código Fuente con Documentación Incorporada

Se refiere a la documentación impregnada en el código. También debe documentarse las configuraciones que se deban hacer en la máquina de desarrollo para que esas fuentes corran, como directorios especiales, variables de entorno, DLLs, entre otros.

Documentación sobre las Pruebas Realizadas

Debe incluir una descripción de la metodología de pruebas centradas en verificación o validación de caja blanca o negra, lotes de prueba, revisiones de código, pruebas unitarias, de integración, de sistemas y de aceptación.

Manuales

• Manual de procedimientos del usuario: Puede reemplazarse por información sobre tutoriales y ayudas en línea.
• Pautas para la migración de datos: Si la hubiese.
• Manual de administración y soporte técnico: Es necesario que tenga una descripción de los errores posibles del sistema, así como los procedimientos de recuperación ante fallas y una guía de los problemas más comunes que se pueden plantear.
• Descripción general para el funcionario no informático: Puede ser un simple diagrama que indique la funcionalidad general del sistema y su despliegue en los distintos componentes de hardware, pero escrito en términos lo más corriente que sea posible.

Diagrama de Componentes y Despliegue

Se usa para modelar el despliegue de los distintos componentes de software sobre el hardware.

Forma de Entregar la Documentación

Cuando deba entregarse, la documentación se presentará en CD. Los formatos de los archivos a entregar deberán ser alguno de los siguientes:

• Texto puro
• Documentación textual
• Planillas de cálculo y tablas
• Presentaciones
• Diagramas

Se pueden enviar archivos compactados, como ZIP o TAR.GZ.

Características de un Componente de Software

Un componente de software debe poseer las siguientes características:

• Identificable: Debe tener una identificación que permita acceder fácilmente a sus servicios y que permita su clasificación.
• Autocontenido: Un componente no debe requerir de la utilización de otros para completar la función para la cual fue diseñado.
• Reemplazable: Se puede reemplazar por nuevas versiones u otro componente que lo reemplace y mejore.
• Acceso a través de su interfaz: Debe asegurar que estas no cambiarán a lo largo de su implementación.
• Servicios estables: Las funcionalidades ofrecidas en su interfaz no deben variar, pero su implementación sí puede hacerlo.
• Bien documentado: Un componente debe estar correctamente documentado para facilitar su búsqueda si se quiere actualizar, integrar con otros, adaptarlo, etc.
• Genérico: Sus servicios deben servir para varias aplicaciones.
• Reutilizable dinámicamente: Puede ser cargado en tiempo de ejecución en una aplicación.
• Independiente de la plataforma: Hardware, software, sistema operativo.

¿Qué es el Desarrollo de Software Basado en Componentes?

Las tecnologías de objetos proporcionan el marco de trabajo técnico para un modelo de proceso basado en componentes para la ingeniería del software. El paradigma orientado a objetos enfatiza la creación de clases que encapsulan tanto los datos como los algoritmos que se utilizan para manejar los datos.

Beneficios del Software Basado en Componentes

• Reutilización del software: Permite alcanzar un mayor nivel de reutilización de software.
• Simplifica las pruebas: Facilita la ejecución de pruebas al probar cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados.
• Simplifica el mantenimiento del sistema: Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y agregar componentes según sea necesario, sin afectar otras partes del sistema.
• Mayor calidad: Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo.

Beneficios del Software Basado en Componentes (Resumen)

• Reutilización del software
• Simplificación de las pruebas
• Simplificación del mantenimiento del sistema
• Mayor calidad

Prototipado

El prototipado se refiere al diseño rápido de aspectos visibles para el usuario.

Actividades Fundamentales en el Proceso de Software

• Especificación de software: Se debe definir la funcionalidad y restricciones operacionales que debe cumplir el software.
• Diseño e implementación: Se diseña y se construye el software de acuerdo a la especificación.
• Validación: El software debe validarse para asegurar que cumpla con lo que quiere el cliente.
• Evolución: El software debe evolucionar para adaptarse a las necesidades del cliente.

Modelos de Proceso de Software

• Modelo lineal secuencial
• Modelo de construcción de prototipos
• Modelo DRA (Desarrollo Rápido de Aplicaciones)
• Modelos de procesos evolutivos de software
• Modelo de métodos formales
• Técnicas de cuarta generación

Desarrollo Basado en Reutilización

Modelo fuertemente orientado a la reutilización. Este modelo consta de cuatro fases:

• Análisis de componentes: Se determina qué componentes pueden ser utilizados para el sistema en cuestión. Casi siempre hay que hacer ajustes para adecuarlos.
• Modificación de requisitos: Se adaptan los requisitos para concordar con los componentes de la etapa anterior. Si no se puede modificar, hay que seguir buscando componentes adecuados.
• Diseño del sistema con reutilización: Se diseña o se reutiliza el marco de trabajo para el sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para diseñar este marco.
• Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad separada.

Integración de Módulos

Son aquellas que se realizan en el ámbito del desarrollo de software una vez que se han aprobado las pruebas unitarias.

Implementación del Software

Es la realización de una especificación técnica o algoritmos con un programa, componente de software, u otro sistema de cómputo.

Entrega y Aceptación del Software

Se revisa la estrategia de implantación que ya se determinó en el proceso de estudio de viabilidad del sistema. Se estudia su alcance y, en función de sus características, se define un plan de implantación y se especifica el equipo que lo va a llevar a cabo. Conviene señalar la participación del usuario de operación en las pruebas de implantación, del usuario final en las pruebas de aceptación, y del responsable de mantenimiento.

Necesidad de Documentación

Dos son las razones principales por las que la empresa debe y tiene que conservar o guardar la documentación:

• Por el propio interés de la organización: Conservar o guardar la documentación, los documentos que recibe y emite la empresa debidamente organizados y clasificados, permite mantener viva o en activo la memoria o la información de la propia empresa. Cualquier sistema de archivo evita uno de los mayores problemas con que se encuentran las empresas en su actividad burocrática.
• Por exigencias legales: El Código de Comercio en su artículo 30, apartado primero, indica lo siguiente: "Los empresarios conservarán los libros, correspondencia, documentación y justificantes concernientes a su negocio, debidamente ordenados, durante seis años, a partir del último asiento realizado en los libros, salvo lo que se establezca por disposiciones generales o especiales".

Problemática de Desarrollo

• Presión excesiva en el tiempo de ejecución
• Cambios en las especificaciones del proyecto
• Ausencia de especificaciones técnicas
• Ausencia de un proyecto documentado o correctamente documentado
• Demasiadas innovaciones superficiales
• Añadir en el desarrollo funcionalidades que no estaban originalmente
• Ausencia del método científico
• Ignorar lo obvio
• Comportamiento poco ético

Verificación del Software

Es un conjunto de procesos de comprobación y análisis que aseguran que el software que se desarrolla está acorde a su especificación y cumple las necesidades de los clientes.