05.04.- Diseño de soluciones

1.- OBJETIVOS

Una vez se dispone de los requisitos desarrollados (también llamado diseño funcional), se trata de determinar las tecnologías concretas sobre las que se desarrollará, implantará y explotará la aplicación o el sistema final.

En su caso se incluirá la selección y adquisición de componentes para la solución.

Por último se realizará el diseño físico de las bases de datos, ficheros e interfases y el diseño detallado de procesos.

2.- DEFINICIONES

Arquitectura de un sistema

Es el conjunto de las principales decisiones de diseño adoptadas durante su desarrollo y posterior evolución.

Módulo

DRAE: 2. m. Pieza o conjunto unitario de piezas que se repiten en una construcción de cualquier tipo, para hacerla más fácil, regular y económica.

3.- PRINCIPIOS

Modularización

Aunque el verbo modularizar o modularización no figura en el diccionario de la Real Academia, está ampliamente extendida en el desarrollo de sistemas. Se entiende la división de un programa o sistema en módulos o partes que, siendo cada uno mas sencillo, se ensamblan para hacer el producto completo.

Reutilización

En la medida en que un sistema sea modular, podremos utilizar módulos o componentes previamente desarrollados o adquiridos para otro producto y por tanto reducir los costes. Para que la reutilización sea viable es preciso que las interfases entre módulos estén normalizadas o estandarizadas.

Integración

El conjunto de sistemas y subsistemas que mantiene y opera la Organización de TI debe estar diseñado de forma que el coste de unir información o funcionalidades de varios resulte lo menor posible. Para ello es importante mantener un diseño de datos e intefases cuanto más homogéneo posible.

Flexibilidad

Cuando se diseña un sistema hay que considerar que, a lo largo de su vida, será ampliado, modificado o integrado con otros, puesto que pueden variar, y variarán, las necesidades del negocio y las circunstancias del entorno técnico y económico.

4.- SUBPROCESOS / PRACTICAS / ACTIVIDADES / TAREAS

4.1.- Definición de la arquitectura general del sistema

Una vez se dispone de los requisitos definidos por los usuarios y convenientemente desarrollados (ver 05.03.- Recogida y desarrollo de requisitos), el primer paso del diseño es definir la arquitectura general del sistema a crear.

Para ello partiremos de los criterios básicos de arquitectura establecidos en la Organización (ver 04.04.- Arquitectura tecnológica e innovación), puesto que entendemos que cualquier nuevo sistema ha de mantener la máxima coherencia estructural posible con los demás sistemas desarrollados, mantenidos y operados por la Organización de TI.

Si el diseño de cada nuevo sistema o producto se hace de forma autónoma, se dificulta la reutilización de equipamiento, componentes y conocimiento, con el correspondiente impacto negativo en la calidad y los costes futuros.

4.2.- Análisis de "hacer, comprar o reutilizar"

Prácticamente siempre que se aborda el diseño de un sistema es necesario decidir si los componentes se desarrollan, se compran o se reutiliza alguno ya existentes.

Estas decisiones en muchas ocasiones no son fáciles ni obvias, dado que se dan ventajas e inconvenientes contradictorios, de forma que se ha de acabar eligiendo la solución menos mala.

Por ejemplo, entre desarrollar un software o adquirirlo, casi siempre parece más rápido y económico la adquisición, pero raramente el producto disponible en el mercado se ajusta exactamente a las necesidades, por lo que hay que invertir en adaptaciones en ocasiones complejas. Frecuentemente se asume un riesgo con la capacidad futura del proveedor de dar soporte y evolución satisfactorios. También se suele perder flexibilidad y nivel de integración.

4.3.- Selección de los componentes a adquirir

En la medida en que se ha decidido que determinados componentes (software, hardware, servicios) hay que adquirirlos, será necesario realizar la selección de los posibles proveedores y seguir el proceso de contratación (ver 07.02.- Aprovisionamiento).

4.4.- Diseño físico de datos a partir del modelo de datos.

Diseño de base de datos, ficheros e interfases. Indices, relaciones de integridad, etc..

4.5.- Diseño detallado de procesos y configuraciones

Se definirán los programas, clases, scripts, y demás artefactos software o de configuración requeridos para cumplir los requisitos.

5.- HERRAMIENTAS / PRODUCTOS

Existen numerosas herramientas o productos orientados a ayudar el proceso de diseño. Por ejemplo:

• Herramientas de modelización, como las que implementan el leguaje unificado de modelización (UML).
• Diccionario de datos
• Herramientas de documentación

Una técnica muy útil para asegurar un diseño de calidad es el uso de las revisiones entre iguales o peer reviews (ver Revisiones entre iguales en proyectos de TI), muy recomendadas en el modelo CMMI.

6.- METRICAS

El avance del proceso de diseño de un producto software se mide con el número de puntos-función que representan los componentes o partes ya diseñadas.

La calidad se medirá por el número de oportunidades de mejora detectadas en las revisiones del diseño y, a posteriori, por el número de defectos o incidencias encontradas en las fases de implementación, prueba e incluso explotación que se puedan achacar a fallos de diseño.

7.-EN LOS MODELOS

7.1.- En CMMI

DEV: TS: Solución técnica

Incluye los objetivos específicos y prácticas específicas siguientes:

SG1 - Selección de soluciones para los componentes del producto

SP 1.1 - Desarrollar soluciones alternativas y criterios de selección

SP 1.2 - Seleccionar soluciones para los componentes del producto

SG2 - Desarrollar el diseño

SP 2.1 - Diseñar el producto o componente

SP 2.2 - Establecer un paquete de datos técnicos

SP 2.3 - Diseñar las interfases conforme a los criterios establecidos

SP 2.4 - Hacer el análisis de hacer, comprar o reutilizar

SG3 - Implementar el diseño del producto

SP 3.1 - Implementar el diseño

SP 3.2 - Desarrollar la documentación de soporte

El análisis de "hacer, comprar o reutilizar" (SP 2.4) se incluye en el objetivo específico de diseño (SG2), en vez de en el de selección de soluciones y componentes (SG1), donde estaría, en nuestra opinión, mejor ubicado.

El objetivo SG1 estaría mejor titulado como "definición de la arquitectura del producto".

También en nuestra opinión, la implementación forma parte de un proceso diferente al diseño, de forma análoga en que en otras ramas de la ingeniería, los planos se hacen en la oficina técnica y la implementación en el taller o la obra. De hecho, en la industria del software se está extendiendo el uso de "factorias de software", en muchos casos en paises en desarrollo (offshore), donde se realiza la codificación y prueba unitaria, mientras que el diseño y la prueba se realiza por otros equipos incluso en otro país.

7.2.- En ITIL

Dentro del libro III (Diseño de servicios), el capítulo 5 (Actividades de diseño de servicios relacionadas con la tecnología) incluye un apartado 5.3 sobre gestión de aplicaciones. En este apartado rincón hay un par de párrafos relativos al desarrollo y mantenimiento de aplicaciones.

Como siempre ITIL se enfoca a los servicios, pero no presta interés a los aspectos del desarrollo, mantenimiento e integración de las aplicaciones y sistemas, dado que los considera aspectos "tecnológicos" de reducido interés para la gestión.

7.3.- En COBIT

COBIT cita algunas ideas sobre el diseño de soluciones en los procesos:

AI2: Adquirir y mantener aplicaciones

AI3: Adquirir y mantener la infraestructura

Son objetivos de control muy generales.

7.4.- Otros modelos o normas

Sin referencias significativas

8.- REFERENCIAS

8.1.- Bibliografía

Software Arquitecture. Taylor, Richard N. et at.

8.2.- Legislación

Sin referencias significativas

8.3.- Sitios web

Sin referencias significativas