Realizar el Diseño del Sistema de Información no es tarea fácil, por ello en Métrica V3 recomiendan llevar a cabo una serie de actividades y tareas. En función de si nuestro desarrollo es estructurado u orientado a objeto se definen una serie de actividades que deben realizar (normalmente en paralelo, unas con otras).
En este post vamos a revisar las 4 primeras actividades a tener en cuenta. Posteriormente, prepararé otras entradas donde ahondaremos en el resto de las actividades hasta la 12. ¿Quieres saber cuáles son todas esas actividades? Sigue leyendo y lo descubrirás.
Índice de contenidos
Definición de la Arquitectura del sistema
Arquitectura del sistema y Requisitos de diseño/construcción
En primer lugar, es necesario definir los niveles de la arquitectura del software. En otras palabras, debemos definir las principales particiones físicas del SI: nodos con características propias de función o ejecución, diseño y construcción. Se deben describir con suficiente detalle para una solución concreta, pero no es necesario describir nodo a nodo. En cuanto a infraestructura, es recomendable especificar: Gestores de datos, servidores, comunicaciones, tipos de puesto de cliente, tipos de dispositivos de impresión y monitores de teleproceso.
Las comunicaciones son las conexiones entre distintos nodos (unidireccional o bidireccional), se deben indicar los protocolos y tipos de mensajes utilizados. Sobre todo, es importante tener en cuenta los criterios para el diseño qué parten de la documentación inicial del proyecto (directrices tecnológicas o de integración, catálogo de requisitos o directrices propias de la instalación) y se debe prestar especialmente atención a usuarios, datos y procesos.
A continuación, actualizaremos el catálogo de requintos después de especificar los requisitos que están íntimamente ligados al diseño o arquitectura. Por ejemplo: criterios de ubicación de módulos, lenguajes, rendimientos de los elementos de la arquitectura, datos de los nodos, etc.
Excepciones, estándares, normas y Subsistema de diseño
Llegados a este punto, tendremos que definir los comportamientos no habituales en el sistema. Para ello, se debe establecer los criterios de catalogación y clasificación de los mismos; y el detalle con el que se van a describir. La catalogación es vital para la especificación técnica de pruebas y para el propio diseño del sistema. En función del nivel de especificación, se recomienda añadir las excepciones particulares.
En segundo lugar, se deben tener en cuenta las excepciones obligatorias: sobre nodos y comunicaciones del posicionamiento físico del sistema de información o rangos o valores no válidos en la entrada de datos.
- Tipo y descripción
- Pre-condiciones del sistema
- Elemento afectado
- Respuesta del sistema
- Elemento asociado a la respuesta del SI
Aquí también elaboraremos el catálogo de normas, producto de entrada para todas las tareas de diseño y construcción. En conclusión, se deben definir cuáles son los estándares técnicos y de nomenclatura, recomendaciones y normas que condicionan nuestro proyecto.
Subsistema de diseño en el Diseño del Sistema de Información
Siempre se ha dicho «divide y vencerás«, pues en el diseño de sistema de información, también se utiliza esta técnica. En este caso, se divide de forma lógica el sistema para reducir la complejidad y tener un mantenimiento más llevadero. Partiremos del ASI o se aplicarán nuevos criterios de diseños:
- Facilidad de mantenimiento,
- Funcionalidad común,
- Reutilización de elementos,
- Características de ejecución,
- Optimización de recursos.
Seguramente surjan nuevos subsistemas (y módulos, clases o servicios) no especificados previamente en el análisis. Posteriormente, completaremos la información de estos tal como avancemos en las otras tareas. En ocasiones se recomendará una reorganización y reubicación debido a criterios de optimización y reutilización.
En diseños Estructurados, presentaremos un diagrama de estructura a alto nivel y una definición de interfaz de cada subsistema.
Diferenciaremos entre dos tipos de subsistemas:
Subsistemas Específicos
Son las funcionalidades propias del sistema.
Subsistemas de soporte
Cubren los servicios comunes, dando un acceso transparente a los distintos servicios. Por ejemplo: comunicaciones entre subsistemas, gestión de transacciones, gestión de datos, seguridad y control de acceso. Control y gestión de errores, gestión de interfaz o interacción con los recursos del propio sistema.
Entorno tecnológico y Requisitos de operación y seguridad
En cuarto lugar, continuaremos con la especificación al detalle de los distintos elementos del entorno tecnológico. Para ello, se agruparán según tres conceptos: hardware, software u comunicaciones. Es probable, que se generen restricciones técnicas que afecten a la construcción o diseño del SI.
Por otro lado, no se puede olvidar la estimación de planificación de capacidades donde especificaremos los parámetros de los equipos de Explotación y Sistemas. No se debe olvidar señalar, al menos, las necesidades de almacenamiento, procesamiento y comunicaciones. Nos enfocaremos en conocer:
- Diseño físico de datos optimizados,
- Diseños detallados de módulos, clases y escenarios
- Información de control de comunicaciones
- Estimaciones de volúmenes de datos propios de la migración y carga inicial de datos (si procede).
Y por último, vamos a repasar los procedimientos de seguridad y operaciones. Este punto es importante para que no se comprometa el correcto funcionamiento del sistema y garantizar los niveles de servicios. Se diseñarán los requisitos de seguridad, control de accesos y procedimientos relacionados para evitar la pérdida o alteración de información. En este caso son:
- Acceso al sistema y recursos,
- Mantenimiento de la confidencialidad e integridad de los datos,
- Control y registro de accesos al sistema,
- Recuperación ante desastres,
- Copias de seguridad, recuperación de datos y su periodicidad.
Además, definiremos los requisitos de operación y procedimientos asociados con el tratamiento en línea y por lotes, el control y planificación de trabajos y la recuperación y reanudación de trabajos. También, la distribución de información generada por el sistema y, el control y seguimiento de los procedimientos de backup y recuperación.
- Diseño de la Arquitectura del Sistema
- Posicionamiento Físico de los Caos de Uso
- Descripción del subsistema de diseño
- Catálogo de requisitos
- El Catálogo de excepciones
- Catálogo de normas
- Entorno Tecnológico del Sistema
- Especificación del Entorno Tecnológico
- Restricciones Técnicas
- Estimación de Planificación de Capacidades
- Procedimiento de Seguridad y Control de Acceso
- Procedimiento de Operación y Administración del Sistema
Diseño de la arquitectura de soporte
Esta actividad se compone de dos partes: el diseño de los subsistemas de soporte y la identificación de los mecanismos genéricos de soporte. En primer lugar, revisaremos el diseño de los subsistemas de soporte. El objeto de este es realizar la especificación y diseño de módulos y/o clases que conforman los subsistemas de soporte. Es necesario realizarlo, siempre que no se disponga de una instalación de servicios comunes. Por tanto, es una tarea importante, ya que permite la reutilización de los subsistemas de soporte. Podemos apoyarnos en el histórico de otros proyectos y para su realización se siguen las pautas genéricas salvo algunas peculiaridades. En algunas ocasiones, es posible detectar comportamientos excepcionales, en esos casos son incorporados al catálogo de excepciones.
En este párrafo, vamos a repasar los mecanismos genéricos de soporte. Lo que se desea obtener con esta tarea es identificar y diseñar los esqueletos, patrones de diseño o guías de diseño a partir de comportamientos comunes (en el caso de no existir en la instalación). Para realizar un correcto Diseño del Sistema de Información, se estudian: la persistencia de datos, la gestión de transacciones, la utilización de recursos comunes, el control y la recuperación de errores, etc.
- Diseño detallado de los Subsistemas de Soporte
- Mecanismos Genéricos de Diseño y Construcción
Diseño de los casos de uso reales en el Diseño del Sistema de Información
Esta actividad solo es necesaria llevarla a cabo para sistemas donde hay Diseño Orientado a Objetos y se realiza en paralelo al diseño de clases (DSI04).
En primer lugar, se lleva a cabo una identificación de las clases que intervienen en los casos de uso (partimos de la identificación de las clases adicionales del punto. DSI04). De igual forma, al ir realizando el estudio de los casos de uso, podrán surgir nuevas clases de diseño. Estas serán incorporadas al modelo de clases.
En segundo lugar, para esta actividad del Diseño del Sistema de Información, es necesario hacer la tarea de diseño de la realización de casos de uso. Por tanto, se debe definir cómo interactúan los objetos identificados en la tarea anterior. Partiremos de escenarios especificados, entornos tecnológicos concretos y mecanismos genéricos de diseño. Las excepciones que surjan, será añadidas al catálogo de excepciones (deberán quedarse resueltas en los escenarios concretos). Seguramente, surgirán la definición de nuevas interfaces de usuarios y subsistemas, que serán añadidos a los catálogos correspondientes. En último lugar, de cara a la tarea de Diseño de la Jerarquía (DSI04) se estudiarán los escenarios, para identificar puntos comunes.
Revisión de subsistemas e interfaces de usuario
En la segunda parte de esta actividad, podremos en foco en la revisión de la interfaz de usuario, en primer lugar. Para ello, realizaremos un diseño detallado del comportamiento de la interfaz. ¿Cómo? Pues revisando la propia interfaz, los elementos que forman cada interfaz, si cumplen sus características y disposición. Además, se debe revisar la navegación entre las ventanas y los eventos relacionados. Cuándo dispongamos de prototipo de interfaz, lo tomaremos cómo punto de referencia. Sobre todo, es importante tener en cuenta, que si son necesarias realizar modificaciones significativas sobre la interfaz, esta debe ser validada.
En último lugar, hay que tener en cuenta la revisión de los subsistemas de diseño. Para ello, describiremos los casos de usuario y las interfaces necesarias. Deberemos definir: subsistemas, actores y mensajes que intercambian los objetos. Por tanto, verificaremos y detallaremos estas interfaces, de esta forma completaremos la tarea de Identificación de sistemas de diseños (DSI01).
Orientación a objetos
- Diseño de la Realización de los Casos de Uso
- Especificación detallada
- Definición a Nivel de subsistemas e interfaz
- Diseño de interfaz de usuario
- Formatos individuales de Interfaz de Pantalla Gráfica
- Catálogo de Controles y Elementos de Diseño de Interfaz de Pantalla Gráfica
- Modelo de navegación de Interfaz de pantalla gráfica
- Formatos de impresión
El diseño de clases en el Diseño del Sistema de Información
En el caso de Diseño orientado a objetos, comenzaremos con la identificación de las clases adicionales. Por tanto, se identificarán el conjunto de clases qué completen nuestro modelo, partiendo el ASI09. En todo momento, se debe tener en cuenta que cada interfaz corresponde al diseño de una clase. El conjunto de clases inicial podrá modificarse en función de las tecnologías utilizadas en el desarrollo. Trabajaremos con 4 tipos de clases:
- Clases de control: coordinación u secuencia entre objetos. Tienen la lógica de negocio.
- Clases de entidad: varían en función del sistema de gestión de datos. Puedes ser propias o de bibliotecas.
- Clases de interfaz: dependen de la tecnología específica.
- Clases abstractas: reúnen características comunes de varias clases.
Realizaremos las asociaciones y agregaciones entre clases partiendo de la descripción de interacción del ASI4. Para ello, hemos estudiado la secuencia de mensajes entre objetos. También, partiremos de la identificación de asociaciones y agregaciones del ASI5. En todo momento, debemos tener en cuenta:
- Características de la asociación,
- Relaciones bidireccionales se transforma en unidireccionales para simplificar,
- Se debe modelizar las rutas de acceso óptimas,
- Hay asociaciones que se pueden diseñar como clases.
Atributos y operaciones de las clases
En tercer lugar, se debe revisar el modelo de clases obtenido del Análisis de Sistema de información (ASI09) para identificar y describir los atributos de las clases. En otras palabras, para cada atributo se debe definir: tipo, formatos específicos y restricciones (si existieran). Puede darse el caso de convertir atributos en clases cuando:
- El atributo este definido en varias clases del diseño.
- La complejidad del atributo, complique el entendimiento de la clase.
En cuarto lugar, es necesario realizar una descripción de las operaciones de las clases. En otras palabras, se describirá los valores de nombre, parámetros y visibilidad para cada una de las operaciones. De esta forma, daremos respuesta alas responsabilidades de las clases de análisis y podremos definir las interfaces asociadas. Partiremos del modelo de clases (ASI), del diseño de casos de uso reales y de los requisitos de diseño. Cuando las operaciones presentan distintos estados, nos es de ayuda utilizar un diagrama de transición de estados.
Jerarquía, Métodos de operaciones y Migraciones y carga incial de datos.
Es importante tomarse un tiempo para revisar el diseño de las jerarquías. A raíz de las últimas tareas han surgido nuevas clases, y se debe constatar que son viables. Además, identificaremos clases abstractas (superclases), que nos permitirá agrupar atributos y operaciones.
A continuación, se deben describir los métodos de operaciones. Para ello, utilizaremos algoritmos, pseudocódigo o lenguaje natural. Para su implementación (fase de construcción) tomaremos como referencia la secuencia de interacciones del diagrama de iteración o en la secuencia de transiciones del diagrama de transición de estados.
En último lugar, se debe especificar las necesidades de migración y carga inicial de datos. Por tanto, se deben estudiar los casos que sean necesarios y analizar los resultados obtenidos. Como resultado, completaremos el Diseño de Migración y Carga inicial de datos (DSI9).
Orientación a objetos
- Modelo de clases de Diseño
- Comportamiento de clases de Diseño
- Plan de Migración y Carga Inicial de Datos.
Referencias
Para cualquier duda, puedes consultar la fuente original en la documentación incluida en la PAE. Esta metodología fue desarrollada en 2001 por el Ministerio de Hacienda y Función Pública y promovido por Consejo Superior de la informática.
Conclusión: Sigue métrica V3 para el diseño del sistema de información
Quizás es un poco complejo, y elaborado. Es muy probable que pienses que en los entornos ágiles en los que nos movemos es difícil llevar a cabo este tipo de marco o metodología. Sin embargo, nadie puede negar que realizando un exhaustivo diseño del sistema de información podremos obtener los mejores resultados.
Quizás te puede interesar
