Uno de los procesos que debemos llevar a cabo, según la metodología Métrica V3 es el Análisis del Sistema de Información. En este proceso se recogen las especificaciones de nuestro sistema de información: requerimientos, interfaces, casos de uso, plan de pruebas a desarrollar, etc. Vamos a analizar que puntos o actividades que se deben tener en cuenta, cuales es el material con el que trabajamos y que productos obtenemos.
En métrica V3 se contempla tanto los desarrollos estructurados, como los orientados a objetos, por ello, se enumerarán los puntos a tener en cuenta en ambos casos. Solo debes utilizar las actividades que proceden para tu tipo de desarrollo.
Si deseas consultar el resto de procesos a realizar puedes acceder al post: «Procesos de la Metodología Métrica V3«, donde explico de forma resumida cada uno de los puntos.
Índice de contenidos
A continuación, enumero las actividades que se deben llevar a cabo para realizar un buen análisis del sistema de información utilizando métrica V3:
Definición del sistema
Para llevar cabo esta actividad, es frecuente que nos basemos en los productos obtenidos del Estudio de Viabilidad del Sistema (EVS). Se realizaran sesiones de trabajo en las que participe el jefe de proyecto, los analistas, directores de los usuarios y el equipo de soporte técnico.
Se debe primeramente, determinar el alcance del Sistema y para ello es necesario indicar los procesos y las entidades externas que aportan o reciben información. Si nos encontramos en un proyecto orientado a objetos, será necesario realizar un modelo de negocio, y así estableceremos el contento del sistema. En ambos casos, empezaremos por generar el catálogo de requisitos, y se irá creando el glosario de términos del negocio que nos permitirá tener una mayor precisión en la especificación del sistema.
Entorno, estándares y usuarios
Será necesario identificar el entorno tecnológico, definiendo con pinceladas el entono que dará respuesta a nuestro proyecto. Se deben especificar sus condicionantes y restricciones posibles.
No podemos olvidarnos de las especificaciones de estándares y normas. Debemos tener en cuenta las normativas, leyes, estándares y recomendaciones que debemos llevar a cabo a lo largo del desarrollo del proyecto. Actualizaremos el catálogo de normas del EVS, con la información necesaria desde el punto de vista de la instalación.
Y por último, uno de los elementos claves del desarrollo: la identificación de los usuarios participantes y finales. Actualizaremos el catálogo de usuarios, estos serán los encargados de la obtención de requisitos, validación de productos y aceptación final del sistema. Es de vital importancia señalar sus funciones y asignar responsabilidades. Además, se genera el plan de trabajo, concretamente los puntos del proceso de análisis.
- Catálogo de requisitos
- Glosario
- Descripción general del entorno tecnológico
- Catálogo de normas
- Catálogo de usuarios
- Planificación
- Contexto del Sistema
- Modelo conceptual de datos
- Modelo de negocio
- Modelo de dominio
Establecimiento de Requisitos, en el análisis del Sistema de información
Esta actividad, he de confesar que es una de mis preferidas. Creo que tener una enumeración clara e intuitiva de los requerimientos de un producto nos permite comprobar que la modelización del sistema se ajustan a las necesidades del mismo. Al igual que en la actividad anterior, para llevar a cabo la generación de los productos será necesaria la realización de sesiones de trabajo con usuarios expertos y analistas; y nos basaremos en los productos generados en la actividad ASI 01.
Comenzaremos por la obtención de requisitos. Se deben definir el catálogo de requisitos del sistema, que serán la base para establecer los niveles de servicios del sistema. Se deberá tener en cuenta las posibles restricciones del entorno y definiremos para cada requisito, la prioridad definida por los usuarios. Los requisitos catalogados serán de diferentes tipologías: funcionales, de rendimiento, de seguridad, de implantación y de disponibilidad del sistema. Para proyectos de orientación a objetos, se definirán también los casos de uso asociados a los requisitos funcionales, identificando actores, caso de uso y breve descripción de cada caso (según las normas u estándares de la organización).
Especificación de casos de uso y análisis de los requisitos
Posteriormente se llevará a cabo la especificación de casos de uso, siendo una tarea opcional en el caso de análisis estructurado y obligatoria en el caso de orientación a objetos. Se completará la información iniciada en la actividad anterior, con información de descripción del escenario, precondiciones y poscondiciones. Se identificarán las interfaces de usuario, condiciones de fallo que afecten al usuario y respuesta del sistema. En casos complejos, se opta por la división en casos más simples o en la especificación de diagramas de transición de estados.
En tercer lugar se realizará un análisis de requisitos, revisaremos todo lo generado para poder encontrar posibles inconsistencias, ambigüedades, duplicidades o falta de información. Se establecerá la relación de los requisitos y las prioridades asignadas. De esta forma, podremos encontrar comportamiento comunes, reestructurando la información de los casos de uso y cómo están relacionados.
En último lugar, es necesario realizar la validación de requisitos, por parte de los usuarios. Se confirmará que tanto requisitos, como casos de uso son validados, consistentes y complejos.,
- Catálogo de requisitos
- Modelo de Casos de Uso
- Especificación de Casos de Uso
Identificación de subsistemas de análisis
Esta actividad se realizará en paralelo con el resto de tareas de generación de modelos de análisis, ya que necesita una retroalimentación y ajustes continuos. Esto nos permite tener una visión global y unificada de los modelos. Para llevarla a cabo serán necesarias sesiones de trabajo del jefe de proyecto y los analistas.
En primer lugar se realizará la determinación de subsistemas de Análisis. Es común realizarla orientada a los procesos del negocio, pero también se realiza por criterios lógicos. Estos criterios son: homogeneidad de procesos, servicios comunes, prioridad, afinidad de requisitos o localización geográfica. En análisis estructurados, coincide con el primer nivel del Diagrama de Flujo de datos. En orientado a objetos, analizan los elementos compartidos entre subsistemas o las interfaces. Se puede crear una interfaz para dicho subsistema para delimitar su comportamiento y utilizar el modelado del sistema. En ambos casos, se procederá a la actualización del catálogo de requisitos y casos de uso, añadiendo los de los subsistemas identificados.
En segundo lugar, se realiza la integración de subsistemas de análisis. De esta forma se coordina la elaboración de los distintos modelos de análisis de los subsistemas, evitamos las duplicidades y enriquecemos nuestro catálogo de glosarios.
Estructurado
- Modelo de procesos
- Descripción de Subsistemas de Análisis
- Descripción de Interfaces entre Subsistemas
Análisis de los casos de uso, en el análisis del sistema de información
Esta actividad solo se realiza en el análisis orientado a objetos. Es realizada por los analistas, en sesiones de trabajo que realizan en paralelo.
Comenzaremos por la identificación de clases asociadas a un caso de uso. Se realizará una identificación de los objetos necesarios para cada caso de uso. Se creará una lista de objetos candidatos a clases, que se irá refinando en esta actividad o en otros procesos. Esas clases, serán catalogadas como clases de entidad, clases de interfaz de usuario o clases de control. También identificaremos atributos, que serán los objetos que definen mejor la información del sistema. Para diferenciar entre clases y atributos optaremos por los diagramas de interacción.
Segundo, se realizará la descripción de interacción de objetos. En ella se desea conocer la cooperación entre los objetos utilizados para la realización de un caso de uso. Utilizaremos diagramas de interacción (de secuencia y colaboración), que contienen instancias de los actores participantes, objetos y secuencia de mensajes intercambiados. Debes tener en cuenta que para casos de uso con múltiples escenarios se recomienda representar cada escenario en un diagrama.
Orientación a objetos
- Modelo de Clases de Análisis
Análisis de clases
Esta actividad solo se realiza en análisis orientado a objetos. Será ejecutada por los analistas en sesiones de trabajo. Describiremos las clases que han surgido cumpliendo la normativa y elaborando un modelo de clases para cada subsistema.
Para comenzar, realizaremos la identificación de responsabilidades y atributos. Obtendremos las responsabilidades de cada clase estudiando los objetos de los distintos casos de uso. De esta forma encontraremos las operaciones a realizar `por cada clase. Los atributos serán las especificaciones de las clases. Se puede elaborar una especificación por cada clase, que incluya la lista de operaciones, las clases y una descripción de responsabilidades y atributos. EN los casos en los que las clases dependan de estado, se optará por un diagrama de transición.
Continuaremos con la identificación de las asociaciones y agregaciones. Estudiaremos los mensajes establecidos entre los objetos del diagrama de interacción. Suelen coincidir con las expresiones verbales incluidas en las especificaciones. Para ello, necesitamos definir relaciones como respuesta a los distintos casos de uso y serán añadidas mediante agregaciones o herencia. Para cada relación se especificará el papel desempeñado, su direccionalidad y su cardinalidad. Revisaremos las especificaciones de los subsistemas para su optimización.
En último lugar, se realizará la identificación de generalizaciones, donde se representará una organización de clases sencilla, con herencia y una agrupación semántica de clases que cumpla las normas u estándares.
Orientación a objetos
- Modelo de Clases de Análisis
- Comportamiento de Clases de Análisis
Conclusión
Como hemos podido observar en estas cinco actividades, hay hacer un análisis del sistema de información muy detallado que satisfaga las necesidades de información del proyecto. El cumplir con los pasos de forma exhaustiva va a ocasionar que tengamos el punto de partida para poder definir el diseño del sistema de información.
Pero para ello, todavía es necesario que se realicen las actividades ASI06, ASI07, ASI08, ASI09, ASI10 y ASI11 que analizaremos en el próximo post. Estate atento o suscríbete al boletín de novedades.
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.