Análisis del Sistema
Tabla de contenidos
- Área: Ingeniería de requisitos
- Carácter del recurso: Recomendado
Descripción
Objetivo del Análisis del Sistema
El objetivo principal del Análisis del Sistema es servir como medio de comunicación entre ingenieros de requisitos y desarrolladores. Los trabajos se plasman en el documento de análisis del sistema (DAS), que es fundamentalmente un documento de carácter técnico, por lo que no está destinado ni a usuarios finales ni a clientes, a menos que éstos tengan la formación necesaria en ingeniería del software. El DAS debe contener principalmente modelos del sistema software a desarrollar, especificado previamente en los requisitos de la Especificación de Requisitos del Sistema (ERS). La realización de estos modelos permite a los analistas identificar problemas en los requisitos y dar el primer paso hacia el diseño y la implementación del sistema. De hecho, empieza a ser habitual la generación de código a partir de modelos aplicando un enfoque de Desarrollo Dirigido por Modelos (MDD, Model-Driven Development en inglés).
A diferencia de la ERS, el DAS no necesita ser aprobado por el cliente al tratarse de un documento técnico, por lo que, aunque debe estar bajo la Gestión de la Configuración, no es estrictamente necesario aplicar el Procedimiento de Control de Cambios establecido en el proyecto para su modificación a menos que se indique lo contrario en las Normas de Gestión del Proyecto. De hecho, lo ideal es que el DAS, o gran parte de su contenido, se genere automáticamente mediante herramientas CASE de modelado y desarrollo de software.
Características
Estructura y dependencias del Análisis del Sistema
El DAS es el principal producto de la tarea Analizar los requisitos del sistema del proceso de Ingeniería de Requisitos, y puede considerarse como un complemento a la Especificación de Requisitos del Sistema (ERS), ya que contiene la arquitectura lógica, los modelos conceptuales y la especificación de las interfaces del sistema software especificado mediante los requisitos de la ERS, a los que debe estar convenientemente trazado, tal como se muestra en la siguiente figura.
Estructura interna
La estructura interna del DAS puede verse en la siguiente figura, en la que también se muestran las tareas que producen cada uno de sus contenidos.
Dependencias internas y externas
En las siguientes figuras se muestran las principales dependencias internas y externas de los componentes del DAS. Las dependencias mostradas en las figuras son las más habituales y que deberían por lo tanto registrarse mediante las trazas oportunas. Ello no impide que puedan registrarse otras trazas no contempladas en las figuras y que se identifiquen durante el desarrollo de un proyecto.
Índice propuesto
En la siguiente figura puede verse el índice propuesto para el DAS, que se detalla sección por sección a continuación.
Las secciones dedicadas a los modelos e interfaces del sistema (secciones 3 a 6, ambas inclusive) pueden organizarse internamente como se considere oportuno para facilitar la legibilidad del documento, siendo la organización más habitual la división en los subsistemas descritos en la arquitectura lógica del sistema (sección 2), en cuyo caso la estructura del índice del DAS para dichas secciones podría ser cualquier de las que pueden verse en las siguientes figuras.
Portada
La portada del DAS, independientemente de la maquetación concreta, debe incluir los siguientes elementos:
- Nombre del documento: Documento de Análisis del Sistema
- Nombre del proyecto: el nombre del proyecto en el que se desarrolla el DAS.
- Versión: versión del DAS según la numeración de versiones que indique la Gestión de la Configuración del proyecto. Lo habitual es que la versión se componga de dos números. El primero indica el número de la línea base, que debe ser cero mientras no se haya entregado la primera línea base y que se debe incrementar con cada nueva línea base que se vaya entregando formalmente. El segundo número, que debe ponerse a cero cada vez que se incremente el primero, indica cambios dentro una línea base aún no entregada. En otras palabras, la primera línea base será la versión 1.0 del documento, la segunda línea base la 2.0 y así sucesivamente. Una versión como la 2.5 será la quinta versión intermedia a partir de la segunda línea base.
- Fecha: fecha de la publicación de la versión.
- Desarrollado por: nombre de la empresa o equipo de desarrollo del DAS.
- Desarrollado para: nombre del cliente, normalmente alguna consejería o servicio de la Junta de Andalucía o algún otro organismo dependiente de ésta.
Lista de control de cambios
Aunque la mayoría de las herramientas de Gestión de la Configuración permiten auditar los cambios que se van realizando sobre los productos que están bajo control de configuración, puede ser necesario incluir una lista de los cambios introducidos en el documento entre entrega y entrega de línea base. En ese caso, el documento incorporará una Lista de Control de Cambios que debe especificar, para cada versión del documento posterior a la 1.0, los cambios producidos en el mismo ordenados por fecha. Para cada cambio se indicará: el número de orden, la fecha, una descripción y los autores del cambio.
Índice
El índice del DAS debe indicar la página en la que comienza cada sección, subsección o apartado del documento. En la medida de lo posible, se sangrarán las entradas del índice para ayudar a comprender la estructura del documento. En el caso de documentos electrónicos, cada entrada podrá ser un hiperenlace al apartado correspondiente.
Listas de tablas y figuras
El DAS deberá incluir listas de las figuras y tablas que aparezcan en el mismo. Dichas listas serán dos índices que indicarán el número, la descripción y la página en que aparece cada figura o tabla del DAS. Al igual que en el índice general, en el caso de documentos electrónicos, cada entrada podrá ser un hiperenlace a la tabla o figura correspondiente.
1. Introducción
Esta sección obligatoria debe contener una descripción breve del contenido del documento y cualquier otra consideración que sitúe al posible lector en el contexto oportuno para comprender el resto del documento.
1.1 Alcance
Esta sección debe describir a qué elementos organizativos de la Junta de Andalucía afecta el desarrollo del nuevo sistema, de la misma forma que se hizo en la Especificación de Requisitos del Sistema.
1.2 Objetivos
Esta sección debe describir los principales objetivos que se esperan alcanzar cuando el sistema a desarrollar esté en producción, de la misma forma que se hizo en la Especificación de Requisitos del Sistema.
Esta sección obligatoria debe contener información relativa a la arquitectura lógica del sistema a desarrollar, es decir, un modelo de la estructura interna del sistema software y de sus relaciones con otros sistemas en el que se identifiquen los principales componentes y sus interacciones. En el ámbito de los sistemas de información, la arquitectura lógica suele seguir variantes del patrón MVC ((Modelo-Vista-Controlador) con n-capas, de forma que la capa i-ésima ofrece sus servicios a la capa i-1 utilizando los servicios de la capa i+1. En caso de aplicar un enfoque orientado a servicios, especialmente en casos de sistemas complejos, también es frecuente recurrir a una arquitectura en bus, normalmente usando un bus de servicios empresarial (ESB, Enterprise Service Bus en inglés).
2.1 Diagramas de la arquitectura lógica del sistema
Esta sección debe contener una representación gráfica de la arquitectura lógica que se propone para el sistema a desarrollar. Se recomienda usar un diagrama de componentes UML, un diagrama de paquetes UML o alguna notación ad-hoc si se considera oportuno.
2.2 Descripción de la arquitectura lógica del sistema
Esta sección debe contener una descripción textual de la arquitectura lógica del sistema, de sus componentes principales y de sus relaciones, en el formato que se considere más adecuado y que, idealmente, podría generar automáticamente una herramienta CASE. Opcionalmente, si no entorpece la comprensión de los diagramas, la descripción podría incorporarse como comentarios en los diagramas mediante anotaciones UML o similares como complemento a los mismos.
3 Modelo de clases del sistema
Esta sección obligatoria debe contener el modelo estático del sistema software a desarrollar, denominado modelo de clases en Métrica versión 3. El modelo estático describe la estructura de la información que debe almacenar el sistema software, es decir su estado, que habitualmente se almacenará en una base de datos relacional.
3.1 Diagramas de clases del sistema
Esta sección debe contener los diagramas de clases UML correspondientes al modelo estático del sistema. En función de la complejidad del modelo, éste podrá organizarse en el número de diagramas que se considere necesario.
3.2 Descripción de las clases del sistema
Esta sección debe contener una descripción textual de la clases identificadas en el modelo estático del sistema, de sus restricciones y de sus atributos y asociaciones, en el formato que se considere más adecuado y que, idealmente, podría generar automáticamente una herramienta CASE. Opcionalmente, si no entorpece la comprensión de los diagramas, la descripción podría incorporarse como comentarios en los diagramas mediante anotaciones UML o similares como complemento a los mismos.
3.3 Diagramas de estados de las clases del sistema [opcional]
Esta sección opcional debe contener aquellos diagramas de estados UML correspondientes a aquellas clases del modelo estático para las que se haya identificado un ciclo de vida complejo. Opcionalmente, estos diagramas de estado pueden adjuntarse a la descripción de las clases en el apartado anterior y prescindir de esta sección.
4 Modelo de casos de uso del sistema
Esta sección obligatoria debe contener el modelo dinámico/funcional del sistema software a desarrollar, denominado modelo de casos de uso en Métrica versión 3, ya que en él se modelan los casos de uso descritos en la Especificación de Requisitos del Sistema.
4.1 Diagramas de secuencia y flujos de trabajo del sistema
Esta sección debe contener los diagramas de secuencia UML y los diagramas de flujos de trabajo correspondientes al modelo dinámico/funcional del sistema, normalmente un diagrama de secuencia y/o un diagrama de flujo de trabajo por cada caso de uso o requisito de conducta de la ERS. La elección de un tipo de diagrama u otro (o ambos) dependerá de la naturaleza del caso de uso o del requisito de conducta, recomendándose los diagramas de flujo para los más cercanos a procesos administrativos y los diagramas de secuencia para el resto, incluyendo la posibilidad de usar ambos si se considera oportuno.
Para los diagramas de flujo de trabajo se podrán utilizar la notación que se considere más oportuna, por ejemplo diagramas de actividad UML, diagramas de la herramienta Model@, etc.
4.2 Descripción de los diagramas de secuencia y flujos de trabajo del sistema
Esta sección debe contener una descripción textual de los diagramas de secuencia y/o diagramas de flujo de trabajo realizados, en el formato que se considere más adecuado y que, idealmente, podría generar automáticamente una herramienta CASE. Opcionalmente, estas descripciones pueden adjuntarse a los diagramas en el apartado anterior y prescindir de esta sección.
5 Interfaz de usuario del sistema
Esta sección obligatoria debe contener el modelo de interfaz de usuario del sistema software a desarrollar, compuesto por esquemas de las pantallas e informes y por el modelo de navegación entre los mismos.
5.1 Diagramas de navegación del sistema
Esta sección debe contener los diagramas de navegación de la interfaz de usuario del sistema software a desarrollar, utilizando la notación que se considere más oportuno para ello, ya que no existe ningún diagrama de UML específico para este propósito.
5.2 Esquemas de la interfaz de usuario del sistema
Esta sección debe contener los esquemas de pantallas e informes de la interfaz de usuario del sistema software a desarrollar, utilizando la notación que se considere más oportuno para ello, ya que no existe ningún diagrama de UML específico para este propósito.
5.3 Descripción de la interfaz de usuario del sistema [opcional]
Esta sección debe contener una descripción textual de los diagramas de navegación y de los esquemas de pantallas e informes de la interfaz de usuario realizados, en el formato que se considere más adecuado y que, idealmente, podría generar automáticamente una herramienta CASE. Opcionalmente, estas descripciones pueden adjuntarse a los diagramas y esquemas en los apartados anteriores y prescindir de esta sección.
6. Interfaz de servicios del sistema
Esta sección obligatoria debe contener una especificación de alto nivel de la interfaz de servicios del sistema software a desarrollar, que normalmente coincide con los servicios de la capa de lógica de negocio identificados durante la realización del modelo dinámico/funcional del sistema, así como una relación de los servicios a consumir. Se deberán incluir las operaciones de la interfaz de servicios del sistema, sus parámetros y valores devueltos, así como su descripción.
6.1 Diagramas de la interfaz de servicios del sistema
Esta sección debe contener los diagramas de componentes UML correspondientes a la interfaz de servicios del sistema.
6.2 Descripción de la interfaz de servicios del sistema
Esta sección debe contener una descripción textual de las interfaces de servicios del sistema, de sus operaciones, sus parámetros, sus tipos devueltos, etc., en el formato que se considere más adecuado y que, idealmente, podría generar automáticamente una herramienta CASE. Opcionalmente, si no entorpece la comprensión de los diagramas, la descripción podría incorporarse como comentarios en los diagramas mediante anotaciones UML o similares como complemento a los mismos.
6.3 Servicios consumidos por el sistema
Esta sección debe contener una relación de los servicios consumidos por el sistema. Para cada servicio consumido se deberá indicar el identificador del requisito de integración que justifica su consumo, el nombre del servicio, el proyecto y el organismo que lo ha desarrollado y un enlace a su documentación, mediante una tabla como la que se muestra en la figura.
7 Información sobre trazabilidad
Esta sección obligatoria debe contener el conjunto de matrices de trazabilidad que se considere oportuno para identificar las dependencias entre los diferentes elementos que aparecen en el DAS y con respecto al contenido de la ERS. Se recomienda al menos realizar las siguientes matrices:
Matrices para representar dependencias externas
- Matriz de trazabilidad de clases frente a requisitos de los tipos que se consideren oportunos, especialmente requisitos de información y reglas de negocio.
- Matriz de trazabilidad de diagramas de secuencia frente a requisitos de los tipos que se consideren oportunos, especialmente casos de uso y requisitos de conducta.
- Matriz de trazabilidad de pantallas e informes frente a requisitos de los tipos que se consideren oportunos, especialmente casos de uso y requisitos de conducta.
- Matriz de trazabilidad de interfaces de servicios frente a requisitos de los tipos que se consideren oportunos, especialmente requisitos de integración y restricciones técnicas.
Matrices para representar dependencias internas
- Matriz de trazabilidad de clases frente a diagramas de secuencia.
- Matriz de trazabilidad de pantallas e informes frente a diagramas de secuencia.
- Matriz de trazabilidad de pantallas e informes frente a clases.
Anexos [opcional]
Los anexos se usarán para proporcionar información adicional a la documentación obligatoria del documento. Sólo deben aparecer si se consideran oportunos y se identificarán con letras ordenadas alfabéticamente: A, B, C, etc.
A continuación se describen algunos anexos habituales.
Anexo A Glosario de acrónimos y abreviaturas
Este anexo debe contener una lista ordenada alfabéticamente de los acrónimos y abreviaturas que aparezcan en el documento.
Para facilitar la reutilización entre proyectos, los acrónimos y abreviaturas comunes a la mayoría de los proyectos aparecerán en este glosario separados de los términos específicos del dominio del problema.
