DISEÑO LÓGICO DE DATOS

Proceso que forma parte diseño de base de datos, y que resulta en un esquema logico.

El diseño  lógico de una base de datos parte del esquema conceptual de una base de datos, resultando en un esquema logico de una base de datos.

Un esquema lógico de una base de datos es una descripción de la estructura de una base de datos que puede procesar un SGBD.

El esquema  lógico de base de datos depende de un tipo de SGBD (relacional, de redes, jerárquico...), pero no de un SGBD específico.

Metodologías de desarrollo ágil

Hemos estado describiendo las metodologías de desarrollo de software que han ido evolucionando a lo largo del tiempo. Cabría preguntarse:
• ¿Qué nuevas metodologías se están desarrollando?,
• ¿Siguen todas las metodologías los modelos tradicionales o están
apareciendo otras posibilidades?
Algunos desarrolladores creen que las metodologías tradicionales generan demasiada burocracia y
exigen demasiado esfuerzo, sobre todo para empresas de desarrollo pequeñas y en desarrollos de
proyectos pequeños. Por otro lado, el mercado competitivo actual de los productos tecnológicos, no sólo exige calidad, coste e innovación, sino también rapidez y flexibilidad. En este contexto, el mercado necesita ciclos de desarrollo más cortos.
Para solucionar estos problemas se han propuesto una serie de principios y valores que aligeren la
carga de las metodologías tradicionales. Con el desarrollo de estas ideas y conceptos han aparecido un nuevo tipo de metodologías que se denominan de desarrollo ágil. Sin embargo, algunos expertos
consideran que el desarrollo ágil no constituye realmente una nueva metodología, sino un conjunto
de recomendaciones y principios aplicables a las metodologías tradicionales para hacerlas más flexibles,rápidas y adaptables.
Las metodologías ágiles se basan en el trabajo en equipo y pretenden:
• Centrarse en el desarrollo y en satisfacer al cliente, es decir, producir un sistema con las
funcionalidades correctas. Esto significa que el sistema final tiene que incluir sólo el mínimo
número de características necesarias para satisfacer por completo al cliente real.
• Mejorar las predicciones y previsiones para cumplir plazos y ajustarse a los recursos.
• Eliminar riesgos tomando en consideración la incertidumbre.
• Disminuir costes, por ejemplo, deben eliminarse actividades relacionadas con algunos
productos intermedios, como documentos formales de especificaciones que no tienen una
relación directa con el resultado final del producto.

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.
Uno de los principales obstáculos en la consecución de este mutuo entendimiento es la variedad de
metodologías de desarrollo existentes, cada una de ellas con sus conceptos y terminología propios y en
general, con un vocabulario procedente de la ingeniería del software, que no siempre es fácilmente
comprendido por usuarios, compradores, responsables de la contratación, etc. Ante una determinada
oferta de contratación pueden acudir distintos proveedores, y cada uno de ellos, puede ofrecer un análisis
realizado con una metodología distinta, lo cual dificulta la toma de decisión sobre la opción más
adecuada. ¿Habría alguna solución?
Ésa fue la pregunta que se hizo la Comisión Europea, es decir, ¿es posible establecer un marco común
para toda la Unión Europea de manera que clientes y desarrolladores puedan utilizar especificaciones
comunes?
Con esta idea se pensó en la elaboración de un
Eurométodo que en realidad no es una metodología de
desarrollo de software, sino un marco con el que pueden
guiarse desarrolladores y clientes tanto de empresas
privadas como administraciones públicas, para adquirir sistemas de información software con garantías.

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.