Modelado de sistemas 101

Para poder llevar a cabo un correcto modelado del sistema en cuestión se ha seguido  la metodología RUP (Rational Unified Process) en su fase de extracción de requisitos,  análisis de los mismos y diseño del sistema [152]. 

La siguiente figura (Figura 23) muestra las etapas de la ingeniería de requisitos, que  serán descritas a continuación junto con las diferentes aproximaciones metodológicas  que se ha seguido para poder realizar el modelado de la “Residencia Virtual Asistida”. 

Figura 23: Modelo de ingeniería de requisitos 

4.1.1 Extracciónderequisitos

Para  obtener  una  correcta  extracción  de  requisitos  se  deben  llevar  a  cabo  las  siguientes acciones en las que participaran usuarios del sistema final: 

 Análisis de documentación: sobre sistemas afines al que se pretende diseñar con  la finalidad de establecer relaciones entre las funcionalidades y los usuarios de  dichos sistemas. 

 Entrevistas: se identifican tres fases en esta técnica: preparación, realización y  análisis [153]. 

o Preparación estudiando el dominio del problema previamente para poder  entender las necesidades del cliente y determinando el objetivo y contenido  de las entrevistas.  

o Realización:  se  debe  informar  al  entrevistado  sobre  el  objetivo  de  la  entrevista y  la mayor parte de ella (alrededor  de  un 80%) debe estar  destinada al entrevistado. 

o Análisis: para reorganizar la información así como contrastarla con otras  entrevistas o fuentes de información. 

Existen  otras  técnicas  para  poder  extraer  requisitos  como  por  ejemplo  Joint  Application Development y Brainstorming. 

4.1.2 Análisisyespecificaciónderequisitos

Tras la extracción de los requisitos, en esta fase aparte de especificar los requisitos, se  identificarán los actores que interactúan con el sistema, y también las funcionalidades 

a las que tienen acceso los actores. Se conoce como actor a un usuario del sistema(  personas, otros sistemas externos o dispositivos de comunicación). Las funcionalidades  anteriores conllevan la identificación de escenarios (interacciones entre usuario y  sistema) y la descripción de casos de usos (descripción concreta de una característica  del sistema desde el punto de vista de los actores que interaccionan con ella). 

La metodología seguida en este apartado ha sido obtenida de la combinación de varias  metodologías, destacando entre ellas el estándar IEEE 1233 “IEEE Guide for Developing  System Requirements Specifications” [154][155][156]. Esta metodología ofrece una  guía para la especificación de unos requisitos que cubren un grupo de necesidades del  usuario. Las distintas fases del proceso de análisis y especificación de requisitos se  muestran en la Figura 24 y se describen a continuación. 

Figura 24 Fases del proceso de análisis y especificación de requisitos [157] 

4.1.2.1 Identificaciónderequisitos

El objetivo de este proceso iterativo es capturar todos los requisitos del sistema y debe  ir dirigido al desarrollo de una base de datos de requisitos y ofrecer a los clientes un  sistema que cubra sus necesidades. Sus principales componentes son: 

 Cliente: son los primeros agentes del sistema que proporcionan al proceso de 

identificación de requisitos sus objetivos, necesidades o problemas. El cliente  debe ofrecer un feedback que incluye información para actualizar los objetivos,  necesidades o problemas del cliente. 

 Comunidad técnica: está compuesta por aquellos involucrados en el diseño de 

las  actividades  del  sistema,  la  implementación,  integración,  fabricación,  despliegue, operaciones y mantenimiento. 

 Entorno: además del analista técnico y el cliente, el entorno puede de manera 

4.1.2.2 Construcciónderequisitosbienformados

Los analistas técnicos deberán cumplir en esta fase las siguientes actividades: asegurar  que cada requisito es una necesidad definitiva, definir las condiciones apropiadas,  asegurar la legibilidad de los requisitos y garantizar que sean verificables. 

Un requisito bien formado es una declaración de la funcionalidad de un sistema que  puede ser validada y que soluciona el problema de un cliente o alcanza el objetivo del  cliente. Cada requisito debe ser independiente, no ambiguo y verificable. 

4.1.2.3 Organizaciónderequisitos

Los analistas deben estructurar el conjunto  de requisitos relacionando con otros  requisitos de acuerdo a elementos comunes. Dicha organización se realiza agrupando  los requisitos, definiendo sus propiedades y atributos. El método más utilizado es  distribuir los requisitos en una jerarquía de capacidades donde los más generales se  descompongan en otros  subordinados. 

4.1.2.4 Presentaciónderequisitos

Se centra en obtener un modelo de requisitos que capture aspectos de utilización y  funcionales expresados de una manera comprensiva. Este proceso se organiza a través  de la utilización de tres técnicas  complementarias: declaración  de la  misión del 

sistema, árbol de refinamiento, y requisitos funcionales. Una vez obtenido este  modelo, es necesario realizar un análisis de los requisitos para traducir los requisitos  funcionales estructurados en un esquema conceptual formado por casos de uso. Estas  fases quedan representadas en la siguiente figura (Figura 25): 

Figura 25 Presentación de modelo de requisitos 

El propósito del modelo de requisitos es capturar de manera precisa lo que el cliente  quiere construir. Así, las técnicas que componen el modelo de requisitos son: 

 Misión del sistema: describe el propósito del sistema en una o dos frases 

 Árbol de refinamiento: es de gran utilidad ya que organiza los requisitos y las  funcionalidades del sistema de manera jerárquica. Un ejemplo de árbol de  refinamiento es el de un terminal de venta que se muestra a continuación  (Figura 26): 

Figura 26 Ejemplo de árbol de refinamiento 

 Requisitos Funcionales: corresponden con el nivel más atómico del árbol de  refinamiento y describen una función determinada del sistema. 

 Modelos  de  casos  de  uso:  incluye  una  especificación  de  los  requisitos  funcionales para mostrar las interacciones externas del sistema con los actores.  Un caso de uso es una interacción entre el sistema y un usuario.  

4.1.2.4.1 Información sobre casos de uso

Un caso de uso debe incluir los siguientes elementos de información: 

 Identificador y nombre descriptivo (Identifier and descriptive name): identifica  al caso de uso dentro del conjunto que especifica el sistema. 

 Descripción (Description): este campo debe rellenarse con el evento que activa  el caso de uso. 

 Precondición (Precondition): la condición necesaria que debe cumplirse para  que el caso de uso funcione. 

 Secuencia ordinaria (Ordinary sequence): este campo contiene la secuencia de  interacciones del caso de uso. En cada paso, un actor o el sistema puede  desarrollar una acción, o activar otro caso de uso. Un paso puede tener sub‐ pasos condicionales, asumiendo que solo un sub‐paso puede ocurrir. 

 Postcondición (Postcondition): condición que se debe cumplir después de una  finalización normal del caso de uso expresado. 

 Excepciones (Performance): después de desarrollarse un determinado paso de  un caso de uso, alguna condición excepcional puede ocurrir. Este campo hace  referencia al comportamiento del sistema en tales circunstancias. Después de  que la acción o caso de uso asociado con la excepción ocurra, el sistema puede  volver a la secuencia ordinaria de acciones o abortar el caso de uso.