Reyes Sánchez García/ octubre 9, 2020/ Metodología y ágil/ 0 comentarios

Tiempo de lectura: 9 minutos

En este post voy a continuar repasando qué debemos hacer para realizar correctamente el Análisis del SI en métrica V3. Como conté en el post «Cómo hacer el Análisis del Sistema de Información en métrica V3 (I)«, uno de los procesos que debemos llevar a cabo según el marco de trabajo Métrica V3 es el Análisis del Sistema de Información. Gracias a este análisis sabremos «donde estamos» y tendremos mucha información para la creación de nuestro producto. En la primera entrada revisamos los procesos del 1 al 5, en esta ocasión nos adentraremos en los procesos del 6 al 11, con los que terminaremos de repasar este proceso.

Análisis del SI en métrica V·

Índice de contenidos

ASI 0 0

La Elaboración del modelo de datos

Esta actividad es llevada a cabo solo cuando nos encontremos en Análisis estructurados de datos.  Se realizan en paralelo a las actividades: ASI2, ASI3, ASI7 y ASI8. Su objetivo es obtener un Modelo de datos en el cual se contemplen todos los elementos para dar respuesta a las necesidades del SI: entidades, relaciones, atributos y reglas de negocio.

Inicialmente, elaboramos el modelo conceptual de datos, partiendo de los documentos obtenidos del ASI1: contexto del sistema y modelo conceptual de datos. Debemos identificar qué entidades se quedan dentro del sistema, los atributos de cada entidad, los dominios de esos atributos y qué relaciones existen entre ellos. También se deben identificar las entidades externas al modelo, señalando el tipo de relación. En este, se describen las reglas de negocio.

Posteriormente se establecerá el modelo lógico de datos procesando el modelo conceptual. Realizaremos acciones como: resolver relaciones complejas, eliminar las relaciones redundantes o eliminar las ambigüedades sobre los atributos. Igualmente se debe identificar las relaciones de dependencias entre entidades, completando posteriormente la información de las entidades y atributos resultantes. Finalmente se revisan y completan los identificadores de cada entidad.

Asimismo es importante definir algunos datos como son el máximo y la media de ocurrencias, qué estimación de crecimiento se tiene en cuenta en cada periodo, la frecuencia de acceso, temas de seguridad, disponibilidad o confidencialidad.

Normalización y Contexto de migración y carga inicial

Es necesario que nuestro modelo de datos cumpla la 3ª forma normal, por ello es necesario ejecutar esta técnica de revisión del modelo. De esta forma eliminamos redundancias e inconsistencias, evitando anomalía en su manipulación y facilitando su mantenimiento. No pueden existir grupos repetitivos, y se debe conocer los datos de forma semántica y las relaciones basándonos en el establecimiento de requisitos. Normalmente exige la modificación de entidades, reorganización de atributos o creación de nuevas entidades.

En último lugar, debemos tener en cuenta cómo se migrarán los datos y la carga inicial que se realizará. Es necesario realizar una especificación de necesidades de migración de datos y carga inicial teniendo en cuenta los puntos esenciales. Estos puntos son: la planificación, prioridad de carga y requisitos de conversión de información. Se debe tener en cuenta el plan de pruebas especifico, las necesidades especiales de equipamiento hardware y las estimaciones de capacidad, y de software. Sin olvidar la posible modificación del sistema original para que verifique de forma correcta la carga inicial o migración.

Productos obtenidos

Estructurado
  • Modelo Conceptual de Datos
  • El Modelo Lógico de Datos
  • Mod. Lógico de Datos Normalizado
  • Plan de Migración y Carga Inicial de Datos
ASI 0 0

Elaboración del modelo de procesos

De igual forma, esta actividad es llevada a cabo solo cuando nos encontremos en Análisis estructurados de datos.  Es necesario establecer el conjunto de procesos del sistema y para ello, aplicamos un proceso de descomposición. Nos basamos en la actividad de Identificación de Subsistemas de ASI3, y descomponemos en sucesivos niveles. Es recomendable utilizar la técnica del diagrama de flujo de datos.

Para cada proceso se debe definir una especificación de detalles: frecuencia de ejecución, procesos asociados, limitaciones, restricciones, tiempos máximos y mínimos, etc. Se deben definir cuáles van a estar controlados por el usuario y cuáles por el sistema. Esto nos permite definir la distribución de los componentes del software en la arquitectura técnica del sistema.

La Especificación de Interfaces con otros Sistemas

Se considera necesario describir las interfaces que interactúan con otros sistemas de información para poder acotar y definir cómo va a ser esa relación. Indicaremos: procesos asociados, especificaciones funcionales del sistema externo, formato de los datos intercambiados y la frecuencia o periodicidad que van a tener. También es necesario conocer los aspectos operativos de la interfaz, qué evento desencadena dicha interfaz y las validaciones y especificaciones que debe cumplir. Por último, no se debe olvidar si es necesaria realizar alguna modificación o adaptación.

Productos obtenidos

Estructurado
  • Modelo de procesos
  • Matriz de procesos / Localización Geográfica (ampliada)
  • Descripción de interfaz con otros sistemas
ASI 0 0

Definición de interfaces de usuario para el Análisis del SI en métrica V3

En la actividad de interfaces tendremos que elaborar un buen conjunto de productos. Primeramente se debe especificar los principios generales de la interfaz de usuario. Se seleccionará el entorno de la interfaz interactiva y se determinará cuáles son los principios del diseño de la interfaz de usuario. Para ello debemos contemplar las directrices generales, cómo se compondrán las pantallas y que criterio de ubicación de elementos se seguirá. Se debe normalizar el formato de los distintos puntos que componen la interfaz, incluyendo las ayudas. De igual forma se establecerá para la interfaz impresa, incluyendo composición de informes y formularios, y las normas de gestión de la información.

Identificaremos los perfiles de usuario y los diálogos de los que se componen. Debemos conocer las características de cada perfil: conocimientos, responsabilidades, etc. A partir del Modelo de procesos, se obtendrán los procesos en los que participa cada usuario y se clasificaran para una posterior descomposición. En los análisis de datos estructurados será necesario una descomposición de los procesos de diálogos para poder conocer la secuencia de los mismos.

Especificaciones

Se especificará los formatos individuales de la Interfaz de Pantalla. Para ello nos basaremos en: el catálogo de requisitos, en los modelos de Datos y de procesos generado en ASI6 y ASI7 (que se realizan en paralelo). Tendremos en cuenta las posibilidades de cambio, de ubicación o modalidad y los dispositivos de entrada. Se deberán considerar los datos asociados (de entrada y de salida) y, los elementos y controles asociados al diseño.

Igualmente, tenemos que especificar el comportamiento dinámico de la Interfaz para conocer el flujo entre los distintos formatos de la interfaz de pantalla y los del propio formato. Definiremos los valores, las reglas de validación y la lógica de los datos. Tras analizar y determinar la secuencia de acciones se completa las condiciones y restricciones de cada diálogo. A continuación, identificaremos los diálogos críticos y utilizando la técnica de diagrama de transición de estados para especificar el comportamiento de los diálogos complejos. Es recomendable la técnica de realización de prototipos.

No podemos olvidar especificar los formatos de impresión para conocer las características de salidas o entradas impresas del sistema. Se deben definir los formatos individuales de informes y formularios, y sus características principales. Se suele utilizar prototipos para su definición. 

Productos obtenidos

  • Especificación de Interfaz de usuario:
    • Principios generales de la interfaz
    • Descomposición Funcional en Diálogos
    • Catálogos de Perfiles de usuario
    • Formatos individuales de interfaz de pantalla
    • Catálogos de Controles y Elementos de Diseño de Interfaz de Pantalla
    • Mod. de Navegación de Interfaz de Pantalla
    • Prototipo de Interfaz Iterativa
    • Formatos de Impresión
    • El Prototipo de Interfaz de Impresión
ASI 0 0

Análisis de consistencia y especificación de requisitos

En primer lugar, es necesario asegurar la calidad formal de los modelos. Revisaremos que los modelos son correctos en función de la técnica utilizada para su elaboración y las normas definidas en el catálogo. Así habremos Verificado los modelos.

El segundo punto a tener en cuenta será analizar la Consistencia entre Modelos. En esta ocasión, comprobaremos que los modelos son coherentes, sin ambigüedades o duplicidades. En función del tipo de desarrollo: Estructurado u Orientado a Objetos se realizarán un conjunto de comprobaciones. En ambas circunstancias se tiene en común la utilización de matrices.

En los casos de Análisis Estructurado se obtiene los siguientes elementos: matriz almacenes datos frente a entidades modelo lógico con datos normalizado. También, la matriz atributos interfaz frente atributos de entidades del modelo lógico normalizado. Obtendremos los caminos de acceso lógico en consultas y el cálculo de accesos lógicos. Por último: matriz entidades frente a procesos y matriz de diálogos frente a procesos.

El resultado que se obtiene al analizar la consistencia en el Análisis Orientado a Objetos es: la matriz de mensajes del diagrama de interacción de los objetos frente a operaciones del modelo de clases. Asimismo se adquiere la matriz de mensajes del diagrama de interacción de objetos frente a las operaciones y atributos del modelo de clases. Obtenemos la matriz de eventos, acciones y actividades de clase frente a operaciones y la correspondencia de elementos de negocio de interfaz usuario frente al modelo de clases. Y en último lugar, la correspondencia de elementos de navegación de interfaz de usuario frente a mensajes del diagrama de interacción de objetos.

Validación de modelos y Elaboración de ERS

Es de vital importancia la validación de los distintos modelos. Por un lado, se validará el catálogo de requisitos mediante la trazabilidad, y por el otro lado será necesaria la validación directa del cliente. Para elementos como la interfaz es imprescindible utilizar un prototipo. A continuación, se procederá a la elaboración de requisitos de  software. En el siguiente bloque se enumera cómo está formado.

Documento de Especificación de Requisitos de Software contiene:
  • Introducción
  • Ámbito y alcance
  • Participantes
  • Requisitos del sistema de información
  • Visión general del SI
  • Referencia a los productos a entregar
  • Plan de acción
Productos obtenidos

  • La Especificación de Interfaz de Usuario
  • Resultado de Análisis de Consistencia
  • Especificación de Requisitos Software (ERS)
Estructurado
  • Modelo Lógico de Datos Normalizado
  • Mod. de Procesos
Orientación a objetos
  • El Modelo de Casos de Uso
  • Especificación de Casos de Uso
  • Modelo de Clases de Análisis
  • Comportamiento de Clases de Análisis
  • Análisis de la Realización de los Casos de Uso
  • Descripción de Subsistemas de Análisis
  • La Descripción Interfaces entre Subsistemas
ASI 0 0

Especificación del plan de pruebas en el Análisis del SI en métrica V3

En la actividad ASI10 comenzamos a desarrollar el plan de pruebas. Este será de guía para verificar la calidad del producto. Se deben definir el alcance de las pruebas, planificando para cada nivel de prueba los puntos necesarios y justificando su realización. Se tendrán en cuenta los niveles de: pruebas unitarias, de integración, del sistema, pruebas de implantación y de aceptación. No siempre se aplicarán todos los niveles, en función de la criticidad de cada uno de ellos, decidiremos si se llevará a cabo o no. 

La planificación se hará con base en: perfiles implicados en las pruebas, planificación en el tiempo o qué criterios de aceptación y verificación dispondrá cada nivel. Además, se debe definir un plan para la definición, creación y mantenimiento de los casos de pruebas y verificaciones. Sin olvidar, el análisis y la evaluación de los resultados y los productos que se entregaran como resultado de las pruebas.

Entorno de pruebas y pruebas de aceptación del sistema

Se recomienda tener un entorno independiente, donde se pueda asegurar la estabilidad de los datos. De esta forma tenemos una garantía de qué los resultados obtenidos sean representativos. A veces, no es posible asegurar este entorno. Sea como sea, es necesario especificar las características del entorno teniendo en cuenta: requisitos básicos de hardware y software base, y requisitos de configuración de entorno. También será necesario especificar herramientas auxiliares y procedimientos para la realización de pruebas y migración de elementos entre entornos.

Se deben especificar las pruebas de aceptación del sistema, haciendo especial hincapié en los criterios de aceptación. Estos criterios nos asegurarán que el sistema satisface los requisitos exigidos: procesos críticos del sistema,  rendimiento del sistema, seguridad y disponibilidad.

Productos obtenidos

  • Plan de pruebas:
    • Especificación de los niveles de pruebas
    • Definición de Requisitos del Entorno de Pruebas
    • Definición de las pruebas de aceptación del sistema
ASI 0 0

Aprobación del análisis del sistema de información

Para la aprobación del Análisis del SI en métrica V3, será necesario presentarlo (Especificación de requisitos de software y plan de pruebas) a la dirección para que procedan a la aprobación del mismo.

Productos obtenidos

  • Aprobación del Análisis del sistema de información.

Conclusiones: Es vital realizar el Análisis del SI en métrica V3

Con Métrica V3 tenemos un marco que nos permite hacer un análisis completo del producto a desarrollar para que pueda ser validado para su desarrollo. En él se muestran las técnicas recomendadas y cuáles son las actividades y procesos a llevar a cabo la documentación. ¿Crees que se puede compaginar con desarrollos basados en metodologías ágiles?

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.

Quizás te puede interesar

 
Compartir esta entrada

Dejar un Comentar

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*