Metodologías para sistemas de tiempo real

 Cuando viajamos en un avión sabemos que el piloto debe solicitar permiso para despegar o para conocer la ruta que debe seguir, o la altura de vuelo. Todo esto se lo indica un controlador de vuelo que se ayuda de un sistema informático. ¿Qué pasaría si hay muchos aviones en vuelo que saturan el sistema informático y el controlador aéreo tiene que esperar para dar una orden a dos aviones que intentan aterrizar al mismo tiempo en el mismo aeropuerto? Desde luego lo mejor es no estar en esos aviones. Un sistema informático que debe captar señales (en este caso del radar y de los sistemas de comunicación de los aviones) sin perder ninguna y que debe contestar a las mismas antes de un determinado momento, es un sistema de tiempo real. En estos sistemas la velocidad de respuesta es fundamental porque el usuario, en este caso el controlador aéreo y el piloto, no pueden esperar.
No debemos confundir los sistemas de tiempo real con los sistemas interactivos, en los que hay que responder lo más rápido posible al usuario pero no hay riesgo de perder señales o datos a la entrada, ni un límite de tiempo en la respuesta.
 • Por ejemplo, un sistema interactivo que controla las operaciones de venta en un supermercado interesa que responda rápido, pero si tarda, el único problema es que hay que esperar. No perderemos datos porque no habrá otra venta hasta que termine la anterior, y no hay un límite de tiempo porque el cliente puede esperar. Esto es un inconveniente pero no un problema crítico como un accidente aéreo. • Otro ejemplo sería un sistema que controle las máquinas de una fábrica donde las tareas deben sincronizarse perfectamente. Para desarrollar estos sistemas será necesario disponer de metodologías de desarrollo del software que permitan especificar este tipo de situaciones de tiempo real y las posibles soluciones. ¿Qué incluirán estas metodologías? Deberán establecer mecanismos para modelar sistemas que
• Controlen la comunicación y sincronización entre tareas.
• Gestionen los procesos concurrentes que se ejecutan en paralelo.
• Respondan ante eventos externos como puede ser una nueva señal.
 • Reciban datos y señales continuas que no pueden perderse.
• Interrumpan los procesos para pasar a otra acción: por ejemplo al producirse una señal de alarma. 

Eurométodo

A lo largo de esta unidad hemos visto diferentes metodologías de desarrollo de software, que las empresas y administraciones públicas pueden utilizar en función de sus intereses y necesidades. Cada método aporta su estructura con unas particularidades determinadas. Cuando una empresa privada o un organismo público pretenden adquirir un sistema de información informático debe establecerse una buena colaboración y relación de entendimiento entre el proveedor y el cliente.
Podemos definir Eurométodo como una metodología para la adquisición de sistemas de información y servicios relacionados, desarrollada en el marco de un proyecto de instituciones europeas bajo supervisión de la Comisión Europea. Se trata de una metodología de carácter público que puede utilizarse libremente. Sus características de diseño permiten su utilización tanto en el ámbito público como en el privado. 
Para alcanzar estas pretensiones, Eurométodo se ha desarrollado con dos orientaciones diferentes: • Como marco metodológico proporciona un conjunto de conceptos y una terminología, que aporta las siguientes ventajas:
 Mejorar la relación cliente-proveedor:

•  Los conceptos y la terminología de Eurométodo se han diseñado para facilitar el entendimiento mutuo entre el cliente, el proveedor, y los desarrolladores. También permite entender mejor las propuestas de los proveedores y crear una situación de cooperación eficaz entre clientes y proveedores, que favorezca al máximo que los proyectos se rematen felizmente para ambas partes.
•   Armonizar los métodos: para lo que existen diccionarios puente entre los distintos métodos y Eurométodo. También, evita quedar ligado a un determinado proveedor o a un determinado método de desarrollo. 
• Como método sirve para definir, planificar y ejecutar la adquisición de un sistema de información y los servicios relacionados. Esto aporta las siguientes ventajas: 9 Permite gestionar y valorar la situación del problema y los riesgos asociados: Anima a los clientes y proveedores a controlar los costes y los plazos previstos, gestionar los riesgos y mejorar el entendimiento mutuo. 
• Poder expresar los requisitos del sistema con mayor claridad. 
• Valorar mejor el objetivo de la adquisición. 
•  Determinar mejor la estrategia de adquisición, en función de la situación específica del problema a resolver
•   Mejorar el "plan de entregas" del sistema software, el aspecto más relevante de las relaciones cliente-proveedor a nivel contractual. Eurométodo es compatible con las técnicas estructuradas, los modelos orientados a objetos y está abierto a cualquier evolución que estos enfoques u otros puedan experimentar en el futuro. Así por ejemplo, se han establecido las conexiones conceptuales y metodológicas oportunas entre Métrica y Eurométodo.

Métrica

La propuesta del Ministerio de Administraciones Públicas fue el desarrollo de la metodología Métrica para que todas las organizaciones siguiesen el mismo modelo y unificasen los criterios para aportar homogeneidad y eficiencia a las aplicaciones informáticas. El ámbito original de aplicación fue la administración general del estado español, pero puede ser utilizada por otras administraciones o empresas privadas. La primera versión es de 1989, la segunda versión apareció en 1993 y en el año 2001 apareció la tercera versión (Métrica V3).  

¿Qué objetivos persigue la última versión de Métrica? Podemos indicar que los objetivos generales de Métrica son: 

• Satisfacer las necesidades de los usuarios dando una mayor importancia al análisis de requisitos. 

• Mejorar la productividad permitiendo una mayor capacidad de adaptación a los cambios y teniendo en cuenta la reutilización en la medida de lo posible. 

• Facilitar la comunicación entre todos los participantes en el desarrollo teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de ellos. 

• Facilitar la operación, mantenimiento y uso de los productos software obtenidos.

 • Utilizar las distintas tecnologías que actualmente están conviviendo y los aspectos de gestión que aseguran que un proyecto cumple sus objetivos en términos de calidad, coste y plazos. Hemos visto los objetivos que persigue, ¿cómo intenta alcanzar esos objetivos? Veamos las características de Métrica con las que cumple con los objetivos marcados:

 • Tiene en cuenta los métodos de desarrollo más extendidos, así como los últimos estándares de ingeniería del software y calidad, además de referencias específicas en cuanto a seguridad y gestión de proyectos. Cumple con el estándar propuesto por Eurométodo.

 • En una única estructura, Métrica cubre el desarrollo estructurado (con un enfoque mixto orientado a procesos, datos y eventos) y el desarrollo orientado a objetos (utiliza UML). 

• La automatización de las actividades propuestas en la estructura de Métrica es posible ya que sus técnicas están soportadas por una amplia variedad de herramientas CASE. 

• Ha sido concebida para abarcar el desarrollo completo de sistemas sea cual sea su complejidad y magnitud, por lo cual su estructura responde a desarrollos máximos y deberá adaptarse y dimensionarse en cada momento de acuerdo a las características particulares de cada proyecto.

 • Es una guía formal que descompone cada uno de los procesos en actividades, y éstas a su vez en tareas. Para cada tarea se describe su contenido haciendo referencia a sus principales acciones, productos, técnicas, prácticas y participantes. 

• Aunque propone una secuencia de pasos, que podría identificarse con una estructura de cascada, hace una propuesta flexible en la que deja libertad para escoger el orden de realización de las actividades, pudiéndose realizar en paralelo. 

• Puede ser utilizada libremente con la única restricción de citar la fuente de su propiedad intelectual, es decir, el Ministerio de Administraciones Públicas de España.  

 SSADM

En 1980 el gobierno británico plantea la necesidad de crear una metodología para unificar y estandarizar los proyectos de software de las distintas administraciones. Así se desarrolló, entre el Central Computing and Telecommunications Agency (CCTA) y Learmonth and Burchett Management Systems (LBMS), la metodología SSADM (Structures Systems Analysis and Design Method).
Veamos algunas de las características fundamentales de SSADM que nos permitan acercarnos a esta metodología: • Centrada en los usuarios, atendiendo a sus requisitos y su participación. • Define de forma clara el proceso de producción, dando especificaciones acerca de qué hacer, cuándo y cómo. • Utiliza tres puntos de vista, para orientarse a datos, eventos y procesos. • Flexibilidad en herramientas y técnicas de implementación, proporcionando un conjunto de procedimientos para llevar a cabo las distintas tareas del análisis y diseño. 

Merise

El proyecto Merise nace en 1977 dentro del centro CTI (Centre Technique d’Information) perteneciente al Ministerio de Industria Francés. Su objetivo era desarrollar una metodología de desarrollo del software para cubrir las necesidades tanto de la empresa pública como de las empresas en general. En 1978 se presentó su primera versión para el sector público, y fue en 1982 cuando el modelo se revisó y se extendió a las empresas del sector privado. Merise puede ser utilizado para el desarrollo de todo tipo de sistemas de información, desde aquellos que utilizan bases de datos hasta los que procesan eventos en tiempo real, y pretende que los proyectos se completen con éxito dentro del costo y tiempos planeados.
La metodología Merise aportó un ciclo de vida más largo que los existentes anteriormente con un conjunto definido de etapas. Abarca los aspectos relacionados con:
• La recopilación y validación de la información.
• Capacitación de personal.
 • Evaluación de equipos informáticos.
 • Análisis, diseño y validación de los procesos.
 • Implementación, gestión de costos y tiempos y el desarrollo del código. Además del ciclo de vida mas largo, esta metodología introduce dos ciclos complementarios:
• El ciclo de abstracción, se basa en la percepción de tres niveles de abstracción (de lo más abstracto a los más concreto): conceptual (finalidades generales de la empresa), organizativo (descripción de la organización necesaria para alcanzar los objetivos) y físico (concreción de los medios software y hardware necesarios). Los tres niveles se desarrollan simultáneamente.
• El ciclo de decisión. En cada etapa del ciclo de vida, cada vez se va bajando más en el nivel de abstracción (según el ciclo de abstracción), y se toman decisiones, al principio de forma global, y después de forma más detallada, conforme se va progresando en el trabajo. 

 METODOLOGIAS MIXTAS

Por ejemplo, a partir del desarrollo estructurado, realizan una metodología con diferentes enfoques para centrarse tanto en los procesos como en las estructuras de datos, los eventos, etc. Estas metodologías han ido evolucionando para adaptarse a nuevas necesidades y paradigmas incluyendo la modelización de sistemas de tiempo real o la programación orientada a objetos, por lo que su principal característica es que son metodologías mixtas.

Metodologías orientadas a objetos

RUP Vimos cómo evolucionaron las metodologías para responder al paradigma de la programación orientada a objetos. Ha habido varias metodologías, pero la que se ha consolidado actualmente y tiene más presencia en la ingeniería del software es el Proceso Unificado (RUP) que utiliza las técnicas proporcionadas por el Lenguaje de Modelado Unificado (UML). RUP ha unificado distintas metodologías y técnicas en una sola metodología. Así, RUP constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
 Sus principales características son: 
• Forma disciplinada de asignar y organizar tareas y responsabilidades (quién, cómo, qué, cuándo).
• Desarrollo iterativo e incremental.
 • Proporciona mecanismos de gestión del proyecto administrando horarios y recursos.
 • Facilita la gestión de requisitos a través de un proceso completo para su recogida y documentación guiado por casos de uso.
• Centrada en la arquitectura para buscar su robustez con un producto que tenga el comportamiento deseado.
• Basada en componentes reutilizables.
• Modelado visual del software utilizando el estándar UML (asegura el uso de herramientas CASE).
 • Resulta fácil dividir el sistema en varios subsistemas independientes.