Modulo de Analisis y Diseno Tercero Bachillerato

UNIDAD EDUCATIVA PCEI “MIGUEL DE CERVANTES”

OBJETIVOS:

El Módulo de Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión persigue los siguientes objetivos generales:

Llevar a cabo todas las acciones y tareas necesarias desde el estudio de los requisitos (proporcionados por el analista) hasta la elaboración de un plan de pruebas de aplicación para conseguir que la solución informática presentada ante una demanda cumpla los requisitos inicialmente establecidos. Todos estos pasos habrá que documentarlos y fundamentarlos siguiendo las directrices que marque la metodología de desarrollo que se emplee, así como siguiendo las directrices del (de los) analista(s).

CONTENIDOS:

Introducción a los sistemas de información

Introducción Sistemas de Información Software Empresa como sistema de información Sistema de información básicos en las empresa

Desarrollo de aplicaciones informáticas

Ciclo de vida de un sistema. Metodología de desarrollo. Clasificación de las metodologías de desarrollo. Principales metodologías de desarrollo europeas .

1 Lic. Sandra E. Tene G.

MÓDULO # 1: DE ANÁLISIS Y DISEÑO DETALLADO DE APLICACIONES INFORMÁTICAS DE GESTIÓN

TERCERO INFORMÁTICA


Análisis de necesidades y estudio de viabilidad

Cómo comienza un proyecto. Definición del problema . Propuesta de soluciones alternativas . Selección de una alternativa .

Análisis de requisitos. Análisis estructurado. Modelización conceptual de funciones

Introducción al análisis de requisitos (A.R.) . Análisis estructurado

Modelización conceptual de datos

Introducción a las bases de datos. Concepto. Arquitectura. Modelos de datos

Técnicas de especificación de control

Análisis orientado a los datos



INTRODUCCIÓN A LOS SISTEMAS DE INFORMACIÓN

Introducción

Hoy en día, todas las organizaciones han asumido la necesidad de utilizar herramientas informáticas para mejorar la comprensión de sus propios procesos y del mundo en el que se desenvuelven.

En el ámbito empresarial, los colectivos se enfrentan a entornos cambiantes que incrementan su complejidad día a día. Para subsistir en este escenario, donde los mercados exigen respuestas cada vez más rápidas y nada es estable ni inmutable, es preciso que los gestores puedan acceder de forma rápida y eficaz a las fuentes de información que les indiquen la situación propia, la de la competencia, y la del entorno donde todos luchan por la supervivencia, para de este modo poder tomar las mejores decisiones. Ello requiere el conocimiento y manejo de una cantidad elevada de factores que se interrelacionan entre sí de forma nada simple, lo que supera ampliamente la capacidad de adquisición y proceso de datos de los seres humanos no asistidos por sistemas de cómputo. Por todo ello, las organizaciones crean sistemas de información automatizados que les ayudan a lograr sus objetivos.

A continuación se definen los términos sistema e información.

SISTEMA

“Un sistema es un conjunto de elementos ordenadamente relacionados entre sí y que cooperan para la consecución de un determinado fin u objetivo común”.

Ejemplo: Sistema monetario, de seguridad, Sistema Solar, de fútbol, de lavado.

Atendiendo a la definición se pueden distinguir los principales elementos y características presentes en cualquier sistema típico:

Componentes o elementos que integran el sistema: todo lo que tiene entidad, ya sea corporal o espiritual, natural o artificial, real o abstracta.

Las relaciones de orden entre elementos, determinando la estructura del sistema.

El fin u objetivo del sistema: esta característica que puede resultar discutible, se encuentra presente en los sistemas finalistas, donde los elementos se relacionan para la consecución de ciertos fines. Sin



embargo existen sistemas de los que ignoramos su fin u objetivo. En nuestro caso el sistema empresarial es claramente finalista.

El entorno del sistema: aquello que lo rodea, dentro del cual está ubicado. Debe tenerse en cuenta que un sistema por agregación/división puede formar parte de otro más general, que sería su entorno, y/o estar formado por otros sistemas, que en este caso lo tendrían a él como entorno común denominándose subsistemas (estudiados mediante el enfoque sistémico), o por solapamiento que existan elementos o partes del sistema que pertenezcan a varios sistemas.

Los límites del sistema: la frontera entre lo que el sistema es y lo que constituye el entorno.

También suelen existir relaciones entre el sistema y sus componentes y el exterior representado por el contorno. Estas relaciones con el exterior suelen conocerse como entradas y salidas del sistema (sistemas abiertos).

El enfoque sistémico u holístico del sistema se pude definir como: la manera de estudiar o analizar sistemas adoptando una visión global de los mismos, que se va refinando progresivamente mediante una descomposición de arriba a abajo. Se empieza por concebir al sistema como una caja negra con entradas y salidas. Una vez identificados los límites del sistema y sus relaciones con el exterior, se pasa a describir su interior. Se identifican subsistemas y las relaciones que los ligan entre sí. Consideramos a cada subsistema como una caja negra, no nos interesa su interior sino sus entradas y salidas. El proceso continúa descomponiéndose cada subsistema en otros menores hasta que los componentes son tan simples que se pueden estudiar al completo y sin problemas. Este enfoque es muy útil para el desarrollo de aplicaciones software grandes o complicadas.

INFORMACIÓN.La información es un conjunto de datos procesados y comunicados de forma que resulten útiles o significativos para el receptor de los mismos.Por tanto, la información sólo surge cuando se produce un proceso de comunicación, debido a que la información depende tanto de los datos transmitidos como del estado del receptor.Los datos están constituidos por registros de hechos, acontecimientos,


https://sites.google.com/site/adai6jfm/home/introduccin/adai01.png?attredirects=0


transacciones, etc.

Ejemplo: Datos Información 260664 Fecha de nacimiento: 26 de junio de 1964. Mañana 1950 Cita con el dentista a las 19 horas y 50 minutos. Efecto 2000 (260600) 26/06/1900 ó 26/06/2000

La información estimula a la acción y su valor reside en que permite decidir mejor, ya que la decisión es el paso previo para toda acción.

Cantidad frente a Calidad:Lo que nos interesa no es tanto la cantidad de información sino su calidad.Llamamos calidad de la información al conjunto de cualidades que, además de su capacidad para disminuir el nivel de incertidumbre del receptor, ayudan a este a tomar decisiones más ventajosas. Estas cualidades son:

La información es relevante para el propósito de la decisión o el problema considerado.

Debe de ser lo suficientemente precisa para que se pueda confiar en ella.

Suficientemente completa para el problema. Lo ideal es poder contar con toda la información relevante para la decisión, pero esto nunca ocurre en el mundo real. Lo importante es que la información sobre los elementos clave sea completa.

La información se comunica a la persona adecuada para la toma de la decisión.

Se comunica a tiempo para que pueda ser útil. Llega al nivel de detalle más adecuado. La información debe ser comprensible para el receptor.

Sistemas de información

Cualquier organización o empresa es un sistema en sí misma. Su entorno es el sistema productivo en que se inserta, del que recibe un flujo físico de entradas compuesto por materias primas, mano de obra, flujos financieros y otros recursos, que transforma en un flujo físico de salidas u oferta, compuesto por productos o servicios, flujos financieros, etc.

A este conjunto de elementos y operaciones se les suele denominar sistema físico, operativo o de operaciones.Para controlar el sistema físico de la organización es preciso que exista un sistema de gestión-decisión, encargado de la regulación y dirección de dicho sistema. Su fin será pues ajustar el comportamiento del sistema físico a los objetivos que sean fijados. Típicamente el sistema de gestión-decisión se compone del personal de la empresa, directivos, ejecutivos y simples operarios, que toman sus decisiones a partir de la información que reciben del sistema físico.



A su vez dentro del sistema de gestión-decisión existen varios subsistemas, los distintos departamentos o áreas en que se divide la empresa. Esta estructura organizativa suele descansar en una red de funciones que hay que desarrollar para que la empresa lleve a cabo sus actividades.Como ejemplo de funciones podemos citar:

Controlar y gestionar el empleo de los recursos financieros, el dinero, mediante la función (sistema) contable y de gestión económica.

Comercializar de manera óptima los productos o servicios en los que la empresa basa sus negocios: función comercial y de ventas.

Fabricar productos o crear servicios que vender en el mercado. Función o departamento de Producción.

Para que tanto el sistema físico como los demás subsistemas (sistema de gestión-decisión) que forman la organización funcionen coordinadamente, es necesario otro subsistema más, el sistema de información (SI). Este sistema dota, a la organización, de la infraestructura necesaria para coordinar los flujos y los registros de información necesarios para desarrollar sus actividades de acuerdo a su planteamiento o estrategia de negocio. Del buen funcionamiento de este subsistema depende en gran parte el éxito global del sistema.

Definición de sistema de información basada en su objetivo.Objetivos en el tratamiento de la información:

Proporcionar la información correctamente. Proporcionarla en el momento y en el lugar requerido. Proporcionarla a las personas autorizadas para ello. Todos estos objetivos deben de realizarse con un coste mínimo.

Definición:Un SI es un conjunto formal de procesos que, operando sobre una colección de datos estructurada según las necesidades de la empresa, recopilan, elaboran y distribuyen la información (o parte de ella) necesaria para las operaciones de dicha empresa y para las actividades de dirección y control correspondientes (decisiones) para desempeñar su actividad de acuerdo a su estrategia de negocio.

Un S.I. es mecanizado cuando este está soportado por un ordenador.

Elementos de un SI.Los elementos que forman un SI son:



La información. Es el elemento fundamental del sistema y su razón de ser. Se debe adaptar a las personas que la manejan y al equipo disponible, según los procedimientos de trabajo que la empresa ha creado para que las actividades se realicen de forma eficaz.

Los procedimientos y las prácticas habituales de trabajo que rigen la transmisión de los flujos de información y su uso para el buen funcionamiento de la empresa.

Recursos humanos: las personas o usuarios. Se trata de individuos o unidades de la organización que introducen, manejan o usan la información para realizar sus actividades en función de los procedimientos de trabajo establecidos.

Recursos físicos o materiales: el equipo de soporte para la comunicación, el procesamiento y el almacenamiento de información. Este sistema físico puede incluir elementos de los más variados niveles tecnológicos, como documentos y archivadores, equipos de telecomunicaciones y de informática,...

Para lograr sus objetivos, la organización y sus individuos adoptan maneras de trabajar que resulten más útiles y eficaces. Estas prácticas de trabajo marcan:

Qué información se necesita. Cómo se ven implicadas las personas. Qué equipo se precisa para un trabajo eficaz. Los procedimientos se deben adaptar a los elementos disponibles:

Así, no pueden implicar el uso de información de la que no se puede disponer.

Las prácticas de trabajo obligan a la gente a adoptar una cierta manera de actuar, pero deben, a su vez, adaptarse a las características de las personas implicadas para ser eficaces.Los procedimientos deben acomodarse al equipo o tecnología existente.

Sistemas de información y tecnologías de la información.Aunque un SI puede organizarse sin incluir prácticamente ningún componente al que se pueda clasificar dentro de los elementos de las modernas tecnologías de la información (TI), a nadie se le escapa que son ámbitos absolutamente complementarios. Así pues, los enormes avances de los que viene disfrutando el campo de las TI se traducen también en tremendas mejoras de la estructura y funcionamiento de los SI en las organizaciones.

Al principio de la revolución de la información se comenzó con máquinas de escribir, calculadoras mecánicas, teléfonos, cintas de papel perforado, etc. y se ha llegado, en plena era postindustrial, y dentro de lo que se conoce como era de la información, a utilizarse tecnologías sofisticadas



de tratamiento y comunicación de información, como informática, comunicaciones, etc. a las que se ha denominado genéricamente TIC (Tecnologías de la información y la comunicación). Actualmente se comenta que la era de la información ha dado paso a la era de la comunicación, en la cual nos encontramos.

Dentro de un SI existirán ámbitos en los que las TI manejen todas las transformaciones significativas de información. A dichos ámbitos se les ha dado el nombre de sistemas automatizados de información (SAI). Las dos razones principales que justifican la automatización de un SI son:

La simplificación y mejora del nivel operacional, tanto en el trabajo administrativo (soporte de la gestión comercial, contabilidad, facturación, nómina, etc.) como en el de producción (operaciones de ingeniería, diseño, fabricación asistidas por ordenador) al automatizarse procedimientos repetitivos y frecuentemente tediosos y al potenciar enormemente las capacidades operativas del ser humano.

Ayuda a la gestión-decisión: la formidable potencia de proceso de los equipos informáticos permiten organizar, procesar, condensar, filtrar y manipular la información de manera que su utilidad de cara a los ámbitos de gestión y decisión se haga máxima.

La implantación de los SI dentro de la empresa pasa por varias fases o niveles que se corresponden con el desarrollo evolutivo de los SI. El nivel más sencillo es el operacional o transaccional. A este nivel se producen las operaciones o transacciones cotidianas de la empresa. Dependiendo del tamaño, calidad y complejidad de la empresa existen de forma abstracta o escrita unos protocolos (manuales de actuación) para la realización de tareas por parte de los empleados.

Por ejemplo, en una empresa de servicios telefónicos se incluyen las operaciones para realizar un contrato, consultar el estado de un teléfono, dar de alta una avería.

Una vez que se llevan a cabo las tareas operativas diarias de forma informatizada se produce un segundo caso, que consiste en la implantación de las bases de datos. El desarrollo de las bases de datos da origen a los Sistemas de información para la gestión (Management Information System o MIS). Un MIS es un sistema de organización de la información en la empresa donde se puede mostrar toda la información disponible. Son sistemas soportados a nivel Táctico, permitiendo tomar decisiones no rutinarias, pero esperadas, que se repiten con cierta periodicidad, de una forma más adecuada y rápida.

No son transacciones, pero sí consultas estructuradas según algún lenguaje de manipulación de datos que le permita crear informes, listados,



basados en la información almacenada en las bases de datos, llegándose a conseguir informes relativamente complejos. Por ejemplo, un director de ventas puede obtener en un impreso los totales de ventas mensuales: por provincias, por vendedores, por productos, de modo separado o agrupados estos datos del modo que se prefiera.

En algunos casos, los MIS pueden tomar automáticamente dichas decisiones.

A un nivel superior, en la implantación de los SI, se encuentran los Sistemas de soporte o apoyo a las decisiones (DSS). Su objetivo es ayudar en la toma de decisiones para situaciones poco frecuentes y sobretodo poco estructuradas, en las que no existen métodos claros para tomarlas y tampoco es posible identificar con anticipación cuáles deben ser los factores que hay que considerar.

Por ejemplo, un directivo se pregunta sobre la respuesta de la competencia ante el nuevo modelo de contestador automático que piensa sacar al mercado.

Un DSS emplea sobre todo, modelos que permiten analizar, desde diversas alternativas, los datos de que se dispone, dejando la decisión en manos del directivo. Los datos disponibles provienen de diversas fuentes, por lo que estarán almacenados en varios ficheros, a no ser que se empleé un DSS específico para un determinado tipo de problemas.

Con las nuevas tecnologías de la comunicación, como la mensajería electrónica, y con posibilidades de realizar toda la gestión de información comercial a través de Internet, se pueden conseguir MIS más eficaces. Aunque en una empresa coexistirán varios niveles de sistemas de información, se tenderá a crear un sistema de información total sobre todos los niveles.

Software

Durante los primeros tiempos de la informática el principal desafío fue el desarrollo del hardware de los ordenadores, el software se desarrollaba intentando optimizar al máximo el hardware. Los responsables de los Centros de Proceso de Datos ponían normas en el Análisis y Diseño, para conseguir mejoras; de esta forma el desarrollo del software se convirtió en un “arte indisciplinado”.

Durante la década de los 80 los avances en microelectrónica han dado como resultado ordenadores con mayor potencia y menor coste. Ahora, el problema ha pasado a ser como reducir el coste y mejorar la calidad de las soluciones.

Definición.El software engloba:



1. Instrucciones que cuando se ejecutan suministran la funcionalidad (función y comportamiento) deseada.

2. Estructuras de datos que facilitan a las instrucciones manipular adecuadamente la información.

3. Documentos que describen el desarrollo, uso, instalación y mantenimiento de los programas.

El software es por tanto un elemento más lógico que físico con unas características propias que lo distinguen de hardware.

Características del software.

El software es un elemento del sistema que es lógico. Es desarrollado, no fabricado en un sentido clásico. No se estropea, se deteriora por cambios Se construye a medida, en vez de ensamblando componentes

existentes. (Cerrado).

Tipos de software.

El software puede aplicarse en cualquier situación en la que se haya definido previamente un conjunto específico de pasos procedimentales. La determinación y contenido de la información son factores importantes para determinar la naturaleza de una aplicación software.

El contenido se refiere al significado y a la forma de información de llegada.La determinación de la información se refiere a la necesidad de predecir el orden y tiempo de llegada de los datos.

En función de estos dos factores obtenemos las siguientes categorías básicas:

Software de sistemas: es un conjunto de programas que están hechos para servir a otros programas. Tienen una fuerte interacción con el hardware de la computadora, operando de forma concurrente, por lo que requiere planificación, compartición de recursos y una sofisticada gestión de procesos. (p. ej.: compiladores, utilidades de gestión de archivos, de periféricos, procesadores de telecomunicaciones).

Software de tiempo real: es un software que mide, analiza y controla sucesos del mundo real conforme ocurren. Un sistema en tiempo real debe responder dentro de unos rangos estrictos de tiempo; frente a un sistema interactivo, donde superar el tiempo de respuesta no produce ningún desastre.



Software de gestión: orientado al procesamiento de información comercial, siendo esta una de las áreas de mayor aplicación del software. Este software ha evolucionado de los sistemas discretos (nominas, contabilidades, inventarios, etc.) hacia los sistemas de información de gestión que hacen uso de grandes bases de datos (MIS, DSS).

Software científico y de ingeniería: se caracteriza por el uso de algoritmos de “manejo de números”, generando software para, por ejemplo, astronomía, análisis de presión de automotores, biología molecular. Algunas aplicaciones interactivas, como simulación de sistemas o CAD, toman características del software de tiempo real o de sistemas.

Software imbricado o empotrado: se utiliza para controlar productos y sistemas de los mercados industriales y de consumo. Dicho software reside en memorias de sólo lectura. (p. ej.: microondas, videos, sistema ABS de un automóvil, etc.).

Software de inteligencia artificial (IA): hace uso de algoritmos no numéricos para la resolución de problemas complejos, ya que no es adecuado el cálculo o el análisis directo. Dentro de la IA podemos encontrar distintas áreas como los sistemas expertos o sistemas basados en el conocimiento, sistemas de reconocimiento de patrones (imágenes y voz), redes neuronales artificiales.

PERSPECTIVA HISTÓRICA.

Década 50 – 60 Desarrollo artesanal del software. Se utilizan C lenguajes de bajo nivel.Década 60 – 70: Se utilizan los lenguajes de alto nivel y los compiladores.

Crisis del software.Década 70 – 80: Década de las metodologías. Programación estructurada. Se entiende la programación como una disciplina científica y tecnológica.

Ingeniería del Software.Década 80 – 90: Tecnología de SGBD’s y SO’s. Nuevos paradigmas de programación y de producción de programas.Década 90: Tecnología CASE. (Volcado de resultados teóricos al campo productivo).

LA CRISIS DEL SOFTWARE.La crisis del software se refiere a un conjunto de problemas encontrados en el desarrollo del software:



Los productos exceden la estimación de costes. Notables retrasos en las fechas de entrega. Prestaciones inadecuadas. Mantenimiento casi imposible. Modificaciones a precios prohibitivos. Falta de fiabilidad del producto software. Todos estos casos dan lugar a un software de baja calidad.

Los problemas anteriores pueden corregirse dando un enfoque de ingeniería al desarrollo del software, es decir, pasar de programación a producción industrial del software, mejorando continuamente las técnicas y las herramientas. Problemática de la industria del software.

>> Objetivos de la producción industrial del software.Producir soluciones automatizadas a gran variedad de problemas complejos, dando productos de calidad y cuya producción sea económicamente rentable, no genere costes posteriores y se realice a tiempo.

>> Problemas:Los productos software son de baja calidad (fiabilidad, eficiencia,...), cuya producción conlleva grandes costes de desarrollo, mayores costes de mantenimiento y notables retrasos.

>> Causas:

Naturaleza “no física” de la programación. Conjunto limitado de teorías bajo investigación. Difusión aún más limitada de dichos conceptos. Industria artesanal y poco fundamento científico. Herramientas comerciales obsoletas. Problemas de gestión. (Planificaciones optimistas, plantillas poco

cualificadas, herramientas inadecuadas). Problemas derivados de la intervención de grupos. Poco esfuerzo en el análisis y la especificación. Problemas de comunicación con los clientes. Gestión de proyectos por personal no informática.

>> Soluciones:Difusión de avances teóricos (formación):

Métodos de parcelación de la complejidad: programación con esquemas, programación modular, programación con objetos.



Métodos de razonamiento formal (lógica y álgebra): lenguajes formales ejecutables, prototipado automático, programación por transformación.

Difusión de avances tecnológicos:

Técnicas de reutilización del software. Herramientas de cuarta generación. Herramientas de desarrollo asistido (CASE).

Como se puede apreciar, es necesaria una disciplina que englobe los distintos avances tanto actuales como futuros para el desarrollo del software:

INGENIERÍA DEL SOFTWARE.

Frizt Bauer (1969) define Ingeniería del Software diciendo que “constituye el establecimiento y uso de principios de ingeniería robustos, orientados a obtener con economía de costes, software fiable y que funcione de manera eficiente sobre máquinas reales”.

Según Pressman [Press98] la producción de programas debe abordarse como una ingeniería más, permitiendo controlar el proceso de desarrollo del software y suministrando a los que la practican las bases para construir software de alta calidad y de una forma productiva.Para ello, la Ingeniería del Software debe aportar tres elementos clave: métodos, herramientas y procedimientos, de forma que se produzca software de gran calidad.

MÉTODOS.Describen “como” construir técnicamente el software. Los métodos incluyen tareas de: planificación y estimación de proyectos, análisis de los requerimientos del sistema y del software, diseño estructurado de datos, diseño de programas, codificación, prueba y mantenimiento.

Los métodos de la ingeniería del software introducen frecuentemente una notación especial orientada a un lenguaje o gráfica y un conjunto de criterios para la calidad del software.Como ejemplos de métodos se pueden ver:

Diagrama de Flujo de Datos (DFD): son una representación gráfica de los flujos de información y físicos internos y externos a la organización.


https://sites.google.com/site/adai6jfm/home/software/adai03.png?attredirects=0


Modelo entidad/relación: se utiliza para representar la estructura lógica de los datos. Para éstos se ha de alcanzar siempre, y como mínimo, la tercera forma normal.

HERRAMIENTAS.

Suministran un soporte automático o semiautomático para los métodos.Existen herramientas automatizadas para soportar cada uno de los métodos vistos anteriormente, y sistemas que integran las herramientas de cada fase de forma que la información creada por una herramienta sirve para otra en el proceso de desarrollo. Estas herramientas se denominan CASE (Computer Assisted Software Enginering), Ingeniería del Software Asistido por Computadora.

Construcción de prototipos.Un prototipo es la primera versión de un nuevo tipo de producto, en el que se han incorporado solamente algunas características del sistema final, o no se han realizado completamente.La construcción de prototipos es un proceso que facilita al programador la creación de un modelo del software que se tiene que construir. Puede tener una de las tres formas siguientes:

1. Un prototipo en papel o un modelo basado en un ordenador que describa la interacción hombre-máquina, de forma que dé al usuario una idea de cómo se realizará dicha interacción.

2. Un prototipo que implemente algunas de las funciones requeridas al producto software o un subconjunto de las mismas.

3. Un programa que ejecute parte o toda la función deseada, pero con características por mejorar durante el desarrollo.

Los prototipos pueden ser Totales o Parciales dependiendo de sí se hacen para el sistema completo o sólo para un subconjunto. También pueden ser Evolutivos o Desechables dependiendo si se piensa usar




como programa final, o si simplemente sirve para captar requerimientos y funcionalidad por parte del usuario.

Un posible modelo de ejecución de un prototipo sería:Primero se recogen los requisitos y se definen los objetivos globales para el software. Después se produce un “diseño rápido”, enfocado a una representación de los aspectos del software visibles al usuario (métodos de entradas, formato de salidas, etc.).

El diseño rápido conduce a la construcción de un prototipo. El prototipo es evaluado por el cliente/usuario y se utiliza para refinar los requerimientos del software a desarrollar. Con este proceso interactivo el producto se va afinando, de manera que satisfaga las necesidades del cliente y proporcione al desarrollador una mayor compresión del trabajo a realizar.

Los problemas que representa el prototipado son:

El cliente cree que el producto está disponible antes de lo debido. El técnico de desarrollo suele realizar la implementación sobre el

prototipo con el objetivo de que funcione rápidamente. ¿Qué hacer con el prototipo?

Lo correcto sería, una vez concluido el trabajo para el cual se diseño el prototipo, si no se ha utilizado una técnica que asegure la calidad del software, es decir, el código utilizado está formado por retazos de otros códigos y no se disponga de una herramienta que permita construir una aplicación reutilizándolo, se debe desechar.

Técnicas de Cuarta Generación (4GT).Aunque para Pressman las Técnicas de Cuarta Generación constituyen un Paradigma del Ciclo de Vida del Software de la Ingeniería del Software, podemos considerar a estas técnicas como herramientas a utilizar en otros Paradigmas como el Ciclo de Vida Clásico o el Modelo en




Espiral.

Estas técnicas aparecen asociadas a los llamados Lenguajes de Cuarta Generación (4GL). En principio, estos lenguajes buscan un nivel de especificación mayor del software frente a los 3GL (Cobol, Pascal, C,...), de forma que permita una construcción más rápida del software. Como ejemplo tememos el SQL para acceso a bases de datos relacionales. Pero la cuarta generación de lenguajes de programación corresponde, también, a una serie de herramientas, que permiten construir aplicaciones sencillas combinando segmentos de programas prefabricados.

Un entorno de 4GT puede incluir: lenguajes no procedimentales para acceso a bases de datos, lenguajes orientados a objetos, generación de informes, definición de pantallas, generación asistida/automatizada de código, facilidades de gráficas de alto nivel, utilización y ensamblaje de unidades funcionales de muy elevado grado de complejidad como hojas de cálculo, procesadores de texto, etc.

Herramientas CASE.“CASE es la automatización del software”.(Computer Aided Software Engineering – Ingeniería del Software asistida por ordenador).CASE es el conjunto de herramientas y métodos asociados que proporcionan asistencia automatizada en el proceso de desarrollo del software a lo largo de su ciclo de vida:

Gestión del proyecto: planificación, estimación y control. Desarrollo del software: análisis, diseño, implementación y

validación. Mantenimiento del software.

El uso de las herramientas CASE va en aumento debido a:

La creciente dificultad práctica de poner en funcionamiento ciertos procedimientos de las metodologías actuales de desarrollo si no es con la ayuda de herramientas informáticas (diseños gráficos complejos, tareas repetitivas, modelización o prototipado de sistemas, etc.)

La necesidad de que se realice con seriedad y rigor todo el proceso de análisis y, sobre todo, el análisis previo que normalmente venía obviándose ante la urgencia de generar código cuanto antes.

Las herramientas CASE facilitan la diagramación para la representación de flujos de datos y procesos haciendo más fácil el diálogo del usuario con el desarrollador tan importante para la realización de la aplicación.

La necesidad de contar con herramientas para diseñar a nivel



lógico y físico la aplicación a partir del análisis.

Objetivos de la tecnología CASE:

1. Incrementar la productividad de las áreas de desarrollo y mantenimiento de los sistemas informáticos.

2. Mejorar la calidad del software desarrollado.3. Reducir tiempos y costes de desarrollo y mantenimiento del

software.4. Mejorar la gestión y dominio sobre el proyecto en cuanto a su

planificación, ejecución y control.5. Mejorar el archivo de datos (enciclopedia) de conocimientos (know-

how) y sus facilidades de uso, reduciendo la dependencia de analistas y programadores

6. Automatizar:o El desarrollo del software.o La documentación.o La generación del código.o El chequeo de errores.o La gestión del proyecto.

7. Permitiro La reutilización (reusabilidad) del software.o La portabilidad del software.o La estandarización de la documentación.

8. Integrar las fases de desarrollo (ingeniería del software) con las herramientas CASE

9. Facilitar la utilización de las distintas metodologías que desarrollan la propia ingeniería del software

Taxonomía de las herramientas CASE.(Revisar este punto una vez estudiado los Paradigmas del Ciclo de Vida del Software).Existen diferentes formas de establecer la clasificación del CASE.

A.- Considerando su amplitud o cobertura:

CASE TOOLKITEs una colección de herramientas software integradas que permiten automatizar un conjunto de tareas de algunas de las fases del ciclo de vida del sistema informático: Planificación estratégica, Análisis, Diseño, Generación de programas.Comparten la BD de soporte y la interfaz de usuario.

CASE WORKBENCHSon conjuntos integrados de herramientas software que dan soporte a la



automatización del proceso completo de desarrollo del sistema informático. Permiten cubrir el ciclo de vida completo. El producto final aportado por ellas es un sistema en código ejecutable (operativo) y su documentación.Además de compartir la BD de soporte y la interfaz de usuario, están basadas en una misma metodología.

B.- Por posición o fase del ciclo de vida que automatizan:

UPPER CASESon las herramientas de apoyo a las primeras fases.Planificación estratégica, requerimientos de desarrollo funcional de planes corporativos, estimación de costes, métricas del software.

MIDDLE CASEHerramientas de apoyo a las fases centrales. Análisis y diseño.Entre otros muchos productos comerciales se pueden citar Designer 2000 de Oracle, System Architect 2001 de Popkin Software, EasyCase de Visible System Corporation

LOWER CASEApoyo a las últimas fases del ciclo de vida. Generación de código, pruebas, creación de documentación para la implantación y el usuario final.Como herramientas de bajo nivel se pueden citar todas las herramientas de RAD -Rapid Application Development- (técnicas RAD son la combinación adecuada del prototipado con las herramientas de 4ª generación). PowerObject de Oracle, PowerBuilder de Powersoft, Delphi de Imprise, Visual Basic de Microsoft.

PROCEDIMIENTOS.Relacionan formalmente los métodos y las herramientas.Definen la secuencia en la que se aplican los métodos, las entregas (documentos, informes, etc.) que se requieren, los controles que ayudan a garantizar la calidad y coordinar los cambios, y las directrices que permiten a los gestores del software a evaluar los progresos.

Todos los métodos, herramientas y procedimientos que constituyen la Ingeniería del Software van orientados a un único fin: producir software de gran calidad.

El Software: factores de calidad.

La garantía de calidad del software se aplica durante todo el proceso de ingeniería del software, es decir, en Análisis, Diseño, Codificación y Pruebas.

La calidad es la concordancia de los requisitos funcionales y de



rendimiento explícitamente establecidos, con los estándares de desarrollo explícitamente documentados, y con las características implícitas de todo software desarrollando profesionalmente.

La calidad del Software es una compleja mezcla de ciertos factores que varían para las diferentes aplicaciones y los clientes que las solicitan.Mc Call realiza la siguiente clasificación con respecto a la calidad del software:

Factores Externos.

Los factores externos son aquellos que son observables sin mirar el código del sistema. Se pueden distinguir los siguientes:

Corrección. El grado en que un programa satisface sus especificaciones y consigue los objetivos de la misión encomendada por el cliente.

Eficiencia. El buen uso de recursos Hw/Sw disponibles y de código requeridos por un programa para llevar a cabo sus funciones.

Robustez. Capacidad de un sistema software para funcionar en situaciones anormales.

Adaptabilidad. Capacidad de poder alterar las especificaciones funcionales del programa.

Reusabilidad. Posibilidad de reutilizar el software (o una parte de él) con el consiguiente ahorro de esfuerzo.

Compatibilidad o facilidad de Interoperación. El esfuerzo que se requiere para acoplar un producto software con otro distinto.

Portabilidad. Facilidad de ser transportado a otras plataformas Hw/Sw.

Verificabilidad o Facilidad de Prueba. La Calidad en el Diseño del sistema determina la facilidad de ser verificado en cuanto a su corrección. En general, cuanto más modular sea un sistema más facilidad para aporta para poderse comprobar su corrección.

Integridad. Un sistema íntegro será aquél que preserve las garantías frente a violaciones de su seguridad tanto interna como externa.

Facilidad de Uso. Actualmente todos los sistemas que se desarrollan van mejorando la capacidad de interacción para los usuarios, sobre todo para los no expertos en informática.

Factores Internos.

Son aquellos que son observables sobre el código del sistema:

Legibilidad. Facilidad de lectura e interpretación del código del programa.



Modularidad. Independencia funcional de los componentes del programa. El software que es monolítico (de una sola pieza) no puede ser fácilmente abarcado por un lector debido al gran número de variables y referencias que incluye.

Empresa como sistema de información

Introducción.La empresa es una unidad económica de producción y/o servicios cuyo objetivo tradicional es la obtención del máximo beneficio a medio y largo plazo. Una empresa típica ha de acometer una serie de funciones, siendo las más características las siguientes:

* Funciones organizativas:

Administrativas y contable: muy importante. Se trata de la versión actual de la clásica teneduría de libros, cuyo objetivo es el control de las magnitudes cuantitativas internas (bienes, derechos, obligaciones) y externas (legales) de la organización.

Dirección: marca la pauta de todas las demás funciones controladas para que cumplan con los objetivos que previamente se han determinado.

Financiera: el aprovisionamiento y utilización de los recursos financieros constituyen una importante faceta de cualquier organización actual.

Recursos humanos: se ocupa tanto de la gestión de personal como de las tareas administrativas relacionadas con la contraprestación salarial (nóminas).

* Funciones productivas:

Comercialización: incluye tanto las tareas directas de poner a disposición de los clientes los bienes y/o servicios, como aquellas tareas accesorias de promoción, publicidad y marketing, indispensables en un entorno competitivo como el actual.

Gestión de almacén: es una función complementaria a las de comercialización y/o producción de bienes. Su objetivo es gestionar de la mejor forma posible las existencias de bienes, de manera que no sólo suponga una carga (por inmovilización del recurso) para la empresa, sino que lleguen a producir auténticos beneficios.

Investigación y desarrollo: esta es una función que desgraciadamente no se da en muchas organizaciones. Busca la mejora en las técnicas, procesos y equipamientos utilizados o suministrados por la empresa

Producción de bienes y /o servicios: muchas empresas son simplemente comerciales, dedicándose a ofrecer los productos y servicios ofrecidos por otras organizaciones. Sin embargo, en otras muchas, el ámbito de producción es muy importante.



Niveles de la toma de decisiones.En cualquier organización, las necesidades de información pueden ser graduadas según una escala de impredecibilidad, presentada a continuación:

No repetitiva e impredecible

No repetitiva, pero parcialmente predecible.

Bastante repetitiva, definida sólo en parte.

Muy repetitiva, definida con precisión

La posición que esas necesidades ocupan en esta escala tiene un gran efecto sobre el diseño de las estructuras informáticas de soporte de los SI:

En el fondo de la escala, la información en cuestión se requiere continuamente, como ocurre cuando, por ejemplo, en la labor diaria de las sucursales de un banco se solicita repetidamente el estado de cuentas de los clientes. En este caso, se conoce perfectamente la naturaleza de la información que se solicita, cuya estructura, contenidos y formatos se encuentran definidas con absoluta precisión.

A medida que se asciende en la escala, los requerimientos de información son cada vez menos repetitivos. Por ejemplo, podrían limitarse a uno cada varios días por persona. Asimismo, existiría una variación creciente en la estructura deseada de lo que se pide, de modo que el sistema de información deberá llevar a cabo una composición sobre la marcha, lo que será indudablemente más costoso que un simple rellenado de campos predefinido. En este sentido, cuando menos frecuentes sean las solicitudes de información, tanto más valiosas deben ser las respuestas para justificar el costo del sistema.

En el tope superior de la escala, la información buscada ha de ser tremendamente valiosa. Estamos hablando, por ejemplo, de los datos que necesita la dirección de una empresa para tomar grandes decisiones. En estos casos es perfectamente posible que esa información nunca haya sido solicitada con anterioridad, pues hubiera sido necesaria una visión de futuro extraordinaria para preverla. No obstante, es muy posible que los datos necesarios para atender el requerimiento en cuestión se hallen almacenados en algún lugar de la base de datos de la organización. Pero para poder responder a la solicitud será preciso localizar esos datos y procesarlos. La localización será rápida sólo si los datos están debidamente organizados y éstos podrán ser procesados sólo si se cuenta con los



programas convenientes.

Tradicionalmente, se ha venido describiendo la estructura decisional de todas las organizaciones, incluyendo las empresas, en función de esta escala de predecibilidad. Para ello, se utiliza la metáfora de la pirámide, que representa la jerarquía de los niveles de actuación y decisión de la empresa:

Nivel estratégico.

En este nivel se mueve exclusivamente la dirección de la organización, trabajando con plazos medios y largos (superior a un año) para acometer la tarea de decidir las líneas maestras que debe seguir la empresa en el futuro. La información tiene un formato muy resumido, con el objetivo de predecir qué será lo mejor para el éxito futuro de la compañía. Las decisiones que se deben tomar en este nivel están poco formalizadas y tienen un fuerte componente subjetivo.

En este ámbito, el SI de información debe estar orientado pues a soportar la toma de decisiones, facilitando la labor de la dirección. Se trata pues de un trabajo en el nivel mínimo de predecibilidad, es decir, no existe una carga periódica de trabajo, ni utilización predecible. Destacan entre estos sistemas, los Sistemas de información para la gestión (Management Information System o MIS), Sistemas de soporte o apoyo a las decisiones (DSS), Sistemas de Información Ejecutivos (EIS, Executive Information Systems), Sistemas de Simulación de Negocios (en la práctica son Sistemas Expertos o de Inteligencia Artificial).

Nivel Táctico.


https://sites.google.com/site/adai6jfm/home/empresa-como-sistema-de-informacin/adai02.png?attredirects=0


En este nivel se mueven tanto los elementos directivos como ejecutivos de la organización, preocupar de la asignación efectiva de recursos a medio plazo para mejorar el rendimiento de la empresa.El manejo de información se centra en datos de producción tanto periódica y rutinaria como excepcional y de necesidad inmediata. Tiene el propósito de descubrir algo nuevo sobre los datos, no sólo lo evidente, actuando sobre información resumida y de naturaleza comparativa más que descriptiva. Las fuentes de datos son tanto internas (de las transacciones) como externas (por ejemplo, para comparar los resultados propios con los que ocurren en otras compañías).

El trabajo se concentra en el análisis de informes de los tipos siguientes:

Resúmenes con medidas estadísticas. Media de ventas por unidad organizativa, total de horas extras, etc.

De excepciones. Aquellas unidades organizativas cuyos parámetros se apartan de la media, como centros con pérdidas, etc.

Específicos. Informaciones que no se habían pedido antes y que los directivos necesitan normalmente con rapidez para resolver un problema muy concreto (que se suele detectar gracias a algún informe de excepciones). Por ejemplo cuando un producto nuevo no funciona se puede pedir un informe de líneas actuales de comercialización, características de los adquirientes, etc.

Este nivel táctico se suele apoyar en sistemas ofimáticos, sistemas de transmisión de mensajerías (e-mail y servicios de facsímil), coordinación y control de tareas y tratamiento de documentos (captación, tramitación y bases de datos documentales), así como Sistemas MIS.

Nivel Técnico-Operativo.

Situado en el punto más bajo de la escala de impredecibilidad, este nivel incluye el procesamiento de las actividades diarias o transacciones, los acontecimientos rutinarios que afectan a la organización: facturación, pagos, entrega de productos, fabricación de bienes, etc., y al nivel de decisión inmediatamente superior, que se preocupa del análisis de los resultados, en especial con relación a los recursos consumidos en las operaciones habituales para tomar decisiones a corto plazo y de consecuencias limitadas, como, por ejemplo, adquisición de materias primas, ordenación de la producción, asignación de trabajadores, etc.En el primer caso se trata de un ámbito informacional dominado por las operaciones de tipo transacción, que son procesamientos de las actividades diarias o transacciones, los acontecimientos rutinarios que afectan a la organización. Suelen tener características similares en todas las empresas:

Los procesos de tratamiento están perfectamente descritos hasta el más mínimo detalle.



Aunque estén previstas las excepciones a la operatoria habitual, ésta no será la norma, sino que lo usual es que dentro de un ámbito organizativo las operaciones tenga una gran similitud entre ellas.

El número de operaciones es muy elevado.

En nivel operativo de dirección se suele trabajar con información procedente del registro de transacciones, información cuyas características principales son:

Es repetitiva y predecible. Así, son documentos típicos de este nivel los informes periódicos de ventas, pagos, etc., los balances mensuales, los estados de cuentas de clientes,...

Centrada en el pasado inmediato. Esto es cada vez menos así, debido a que los sistemas informáticos actuales van siendo capaces de mostrar al momento el resultado de todas las operaciones habidas hasta la fecha.

Con datos originados internamente. Lo que permite que tengan asignados formatos bien estructurados y que sean detallados y precisos.

En cualquier caso, las herramientas informáticas utilizadas cubren el núcleo de operaciones tradicionales de captura masiva de datos y servicios básicos de tratamientos de datos, con tareas predefinidas (contabilidad, facturación, almacén, presupuesto, personal y otros sistemas administrativos, fabricación asistida, etc.). Estos sistemas evolucionan paralelamente a las capacidades de los sistemas informáticos. Por ejemplo, si tradicionalmente existía un conjunto de operarios encargados de introducir en el sistema a posteriori la información sobre las operaciones efectuadas por todos lo demás, hoy en día va siendo habitual que la información se recoja en origen, mediante el uso de aplicaciones que ayudan a los operarios en sus tareas y que se conectan directamente con la base de datos de la Organización.

Flujos de información en la empresa.

Existen dos grupos principales de flujos de información en la empresa: horizontales (para la coordinación) y verticales (basados en la jerarquía):

1. Flujos verticales ascendentes: de subordinado a superior. Suelen consistir en informes sobre resultados de las actividades o de las gestiones y avisos sobre incidencias. Carácter histórico.

2. Flujos verticales descendentes: de jefe a subordinado. Se trata de órdenes, también solicitudes específicas de información para tomar decisiones o controlar el funcionamiento.

3. Flujos horizontales: entre personas del mismo nivel de autoridad, entre compañeros de una misma unidad o entre personas de departamentos distintos. Constituyen un medio esencial para



adaptarse mejor al mercado, se trata de fomentar que existan canales horizontales de comunicación ágiles y eficaces en la empresa.

Sistema de información básica en la empresa

Sistema de Recursos Humanos.El recurso o activo más importante en una empresa es el constituido por el conjunto de personas que la componen. Las actividades de gestión relacionadas con el personal de la empresa se basan en dos aspectos principales:

1) La gestión de la información relacionada con la plantilla: incluye información personal compuesta de:

Filiación completa. Historial laboral. Datos relacionados con el salario y los incentivos. Datos sobre la carrera profesional e historial formativo de los

empleados.

2) La ejecución de la nómina: para determinar todos los conceptos de la paga de cada empleado, se debe disponer de sus datos contractuales y del historial laboral en el período para determinar su retribución bruta. Después se deben deducir los pagos de la seguridad social, retenciones del impuesto de la esta, etc. Cada uno de ellos se calcula en función de datos personales. Dado que tiene una gran relación con el entorno legal, la nómina, junto a la contabilidad, es el subsistema que más cambios sufre como reacción a los cambios del entorno, por lo que deben contar con una estructura flexible. El desarrollo de la aplicación de nóminas suele ser muy cuidadoso por la repercusión social de cualquier fallo.

Generalmente se hace una adaptación de paquetes comerciales. El paso final del pago de los salarios a los trabajadores y su registro en los distintos documentos de la contabilidad es responsabilidad del departamento de gestión económica.

La gestión de los recursos humanos en los distintos niveles es:

Nivel operativo:

Mantenimiento de los datos de los empleados. Inventario de cualificaciones de los empleados: experiencia,

preferencia de trabajo, perfil psicológico, etc, para que se puedan identificar candidatos para las promociones internas y adecuar cada persona al puesto más apropiado a sus características.

Inventario de puestos de trabajo existentes en la empresa y de las condiciones más adecuadas para desempeñarlos.

Evaluación de los empleados en función de los informes de sus



superiores, de la consecución de los objetivos marcados, etc. Generación de los informes que hay que remitir a la administración

pública. Gestión de las solicitudes de empleo.

Nivel táctico:

Análisis y diseño del perfil de persona ideal para cada puesto de trabajo, para saber qué tipo de persona hay que contratar o qué formación debe recibir alguien antes de ascender a un cargo.

Analizar las necesidades de contratación de personal para cubrir los objetivos de la empresa a medio plazo, generando planes de previsión de reclutamiento de plantilla.

Generar planes para crear incentivos y aplicar beneficios sociales a los empleados.

Análisis de las necesidades de formación y creación de planes para la mejora del nivel técnico-profesional de la plantilla.

Nivel estratégico:

la gestión de RRHH debe preocuparse de crear planes que indiquen la cantidad de personal, sus características, las fechas en las que contratar, los cursos de formación necesarios, etc. para poder contar con la infraestructura de personal apropiada para los objetivos de la empresa

Las características de los sistemas informáticos que dan soporte a estos subsistemas son:

La nómina se suele realizar mediante aplicaciones de trabajo en lotes ya que sólo deben trabajar a finales de mes con grandes ficheros que resumen los datos relacionados con el salario una vez que toda la información está disponible.

La gestión de personal requiere algunos tratamientos inmediatos e interactivos y otros que actúan de manera periódica sobre grandes grupos de datos.

En ambos casos la información manejada es confidencial, por ello los sistemas deben contar con un control estricto de accesos que asegure una adecuada protección de los datos.

Sistema de Gestión Comercial.

El propósito principal de todo negocio es vender satisfaciendo las necesidades de los clientes. Las actividades de gestión relacionadas con el trato con los clientes se basan en dos áreas principales:



1) Las propias ventas, que incluyen:

La gestión y el tratamiento de los pedidos. Se debe controlar la forma de pago, determinar con precisión los productos o componentes incluidos y las cantidades que hay que pedir, verificar si la empresa puede aceptar el pedido, comprobar si hay existencias disponibles, etc

La facturación de la venta o pedido una vez comprobada su viabilidad.

El control de los detalles de entrega y la actualización del inventario cuando se confirma la operación de venta.

En la tramitación de pedidos puede haber una gran cantidad de acontecimientos que hay que considerar: cancelación, pedidos en espera de contar con todos los productos, reserva de ejemplares o artículos, pedidos pendientes de pago, etc.

2) La función de comercialización: Implica el análisis de las ventas, de la competencia, de los gustos y demanda de los clientes, para optimizar todos los aspectos que intervienen en la implantación de productos en el mercado. Los planes comienzan con un pronóstico de ventas, basado en factores como la ventaja competitiva, el precio, la promoción, las preferencias de los clientes, etc. Todos los presupuestos y planes para la publicidad, promoción e, incluso, creación de productos o servicios dependerán de los ingresos estimados y de los estudios sobre su éxito comercial. El estudio de la comercialización requiere información de:

Ventas: estadísticas sobre las ventas. Investigación de mercados. Técnica de los departamentos de producción, de diseño o de

fabricación sobre la capacidad de innovación, sobre la mejora de las características de los productos, etc.

Datos sobre la capacidad financiera de la empresa para acometer campañas de promoción, diseño de nuevos productos, etc.

En los distintos niveles se ocupa de:

Nivel operativo:

Gestión de las carteras de clientes para la localización de los compradores potenciales.

Control de los contactos con los clientes. Consultas sobre características y disponibilidad de productos. Información sobre el crédito p la consideración económica de cada

cliente. Facilidades para la gestión de pedidos y facturas o cualquier otro



documento comercial. La gestión de la distribución de los productos.

Nivel táctico:

La recogida de información de ventas de cada cliente, de cada zona, de cada tipo de producto, etc. para un posterior análisis que permitirá controlar si las previsiones se cumplen, detectar posibles problemas, etc. Gracias al estudio de estos datos se pueden planificar las próximas campañas, se controlan las actuales y se pueden fijar los objetivos de ventas para los responsables de área y para los departamentos.

La gestión y el control de las campañas de publicidad y de promoción con el fin de optimizarlas, consiguiendo llegar al segmento de mercado deseado, eligiendo los medios más apropiados, buscando la mejor mezcla de acciones de presentación, etc.

El establecimiento de los precios en función de los datos del mercado.

Las decisiones sobre la mejor forma de distribuir los productos en función de la información sobre los costes y los plazos de los distintos canales de distribución, la fiabilidad de la entrega, etc.

Análisis de los competidores.

Nivel estratégico:

Dividir el mercado n segmentos de personas con características o necesidades comunes.

Seleccionar los segmentos a los que la organización desea acceder. Planificar los productos y los servicios que se deben ofertar para

satisfacer las necesidades de dichos clientes. Predecir las ventas para los distintos productos y segmentos con los

que se va a trabajar.

Características de los sistemas informáticos que dan soporte:

La gestión de pedidos y facturación suele trabajar sobre esquemas conocidos de transacciones que se mantienen en trabajo por lotes ya que no hay una gran urgencia de proceso. La potencia de la gestión comercial se debe apoyar en grandes masas de datos para obtener la suficiente información, lo que implica el trabajo con grandes bases de datos cuyos accesos más críticos deben ser optimizados. La mayoría de las funciones de análisis de mercado necesitan realizar simulaciones complejas y análisis estadísticos sofisticados. Se pueden encuadrar como sistemas de apoyo a las decisiones.



Sistema de Gestión Contable y Financiera.La gestión económica se ocupa en los distintos niveles de:

Nivel operativo: Las actividades de contabilidad de toda la empresa siguiendo la legislación correspondiente, lo que provoca que muchos de los datos a tratar y los procedimientos a seguir estén prácticamente estandarizados. La gestión contable diaria implica hacer frente a ciertas funciones clásicas:

Control de activos fijos. Gestión de cobros. Gestión de pagos. Control de inventario. Ejecución de la nómina. Generación de informes para la dirección y de toda clase de

documentos oficiales preceptivos.

La contabilidad se registra manualmente en los libros diario y mayor, realizando los llamados asientos en las cuentas correspondientes en el debe y el haber. Cada una de las operaciones elementales de negocio se denomina transacción. Ésta constituye el objeto principal del control interno representado por la contabilidad.

Nivel táctico:

Gestión y control de presupuestos. Información sobre el flujo de caja. Control de los planes de gasto de capital.

Nivel estratégico:

Obtención de previsiones financieras a largo plazo. Recogida de información tanto financiera como de parámetros

económicos y sociales para el posterior análisis y simulación.

Características de los sistemas informáticos que dan soporte:Los sistemas informáticos suelen ser interactivos, deben trabajar con grandes bases de datos y requieren simulaciones. Los sistemas de información deben estar orientados eminentemente al apoyo a las decisiones.

Sistema de Control de Almacén.

El objetivo principal de un sistema de gestión de inventario es el control de las existencias almacenadas. Los grandes costes que significar tener mercancías paradas en un almacén ha llevado a que el control de



existencias haya adquirido mucha importancia en las empresas. Se trata de ofrecer el mismo servicio a los clientes minimizando la cantidad de dinero que debe dejarse inmovilizado en forma de existencias. Se debe controlar tanto las materias primas como los productos elaborados a la espera de venderse.

Nivel operativo:

Compras de materias primas o componentes. Recepción de las materias primas o componentes. Envío de los productos fabricados a los clientes.

Nivel táctico:

Gestión y control de las materias primas, los productos sin terminar y los ya terminados. Determinación del nivel óptimo de reaprovisionamiento.

Planificación de la capacidad de producción óptima para no saturar el almacén.

Nivel estratégico:

Decisiones estratégicas de la alta dirección general.

Otros Subsistemas.

Sistemas de automatización de oficinas (ofimática): conjunto de ayudas necesarias para realizar el trabajo esencial de oficina. Constituyen sistemas básicos de infraestructura común a distintas unidades organizativas, son sistemas transversales ya que afectan a varios departamentos.

Sistemas de producción: incluyen la automatización de fabricación y las ayudas para el diseño y puesta en producción de productos. Pueden abarcar el control de calidad, de herramientas y el mantenimiento del equipo de fabricación.

DESARROLLO DE APLICACIONES INFORMÁTICAS

Ciclo de Vida de un sistema

La Ingeniería del Software está formada por una serie de pasos que abarcan los métodos, herramientas y procedimientos. Estos pasos se denominan Paradigmas de la Ingeniería del Software.La norma IEEE 1074 entiende por ciclo de vida del software "una



aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software".La norma ISO 12207-1 entiende por ciclo de vida "un marco de referencia que contiene los procesos, las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto software, abarcando la vida del sistema desde la definición de los requisitos hasta la finalización de su uso".En resumen, el ciclo de vida es una sucesión de etapas por las que atraviesa un producto software a lo largo de su desarrollo y existencia.La elección de un Paradigma concreto se realiza de acuerdo con la naturaleza del proyecto y de la aplicación, de los métodos y herramientas disponibles, y de tener los controles y entregas adecuadas.Existen varios paradigmas, los más conocidos son:1. Ciclo de Vida Clásico.2. Ciclo de Vida Clásico con Prototipado.3. Modelo en Espiral.4. RAD (Rapid Application Development). Desarrollo Rápido de Aplicaciones.5. Paradigma Orientado a Objetos.

VISIÓN INTEGRADA DE LA INGENIERÍA DEL SOFTWARE

Independientemente del paradigma que se utilice, del área de aplicación, y del tamaño y la complejidad del proyecto, el proceso de desarrollo de software contiene siempre una serie de fases genéricas, existentes en todos los paradigmas. Estas fases son la definición, el desarrollo y el mantenimiento.

Definición.La fase de definición se centra en el qué (¿qué hacer?). Durante esta fase, se intenta identificar:

Qué información es la que tiene que ser procesada qué función y rendimiento son los que se esperan qué restricciones de diseño existen qué interfaces deben utilizarse. qué lenguaje de programación, sistema operativo y soporte hardware

van a ser utilizados. qué criterios de validación se necesitan para conseguir que el sistema

final sea correcto.

Aunque los pasos concretos dependen del modelo de ciclo de vida utilizado, en general se realizarán tres tareas específicas:

• Análisis del sistema.Define el papel de cada elemento de un sistema informático, estableciendo cuál es el papel del software dentro de ese sistema.



• Análisis de requisitos del software.El ámbito establecido para el software proporciona la dirección a seguir, pero antes de comenzar a trabajar desarrollar es necesario hacer una definición más detallada de la función del software. Con esta fase, se pretenden obtener modelos conceptuales detallados de las estructuras de datos y de los procedimientos que para su gestión les son aplicables.

El análisis y definición de los requisitos es una tarea que debe llevarse a cabo conjuntamente por el desarrollador de software y por el cliente. La especificación de requisitos del software es el documento que se produce como resultado de esta etapa.

• Planificación del proyecto software.Durante esta etapa se lleva a cabo el análisis de riesgos, se definen los recursos necesarios para desarrollar el software y se establecen las estimaciones de tiempo y costes. El propósito de esta etapa de planificación es proporcionar una indicación preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que se hayan establecido. Posteriormente, la gestión del proyecto durante el desarrollo del mismo realiza y revisa el plan de proyecto de software.

Desarrollo.La fase de definición se centra en el cómo (¿cómo hacerlo).

Cómo ha de ser la arquitectura de la aplicación. Cómo han de ser las estructuras de datos. Cómo han de implementarse los detalles procedimentales de los

módulos. Cómo van a ser las interfaces. Cómo ha de traducirse el diseño a un lenguaje de programación. Cómo van a realizarse las pruebas.

Aunque, al igual que antes, los pasos concretos dependen del modelo de ciclo de vida utilizado, en general se realizarán cuatro tareas específicas:

• Diseño.

El diseño del software traduce los requisitos a un conjunto de representaciones (gráficas, en forma de tabla o basadas en algún lenguaje apropiado) que describen cómo van a estructurarse los datos, cuál va a ser la arquitectura de la aplicación, cuál va a ser la estructura de cada programa y cómo van a ser las interfaces. Es necesario seguir criterios de diseño que nos permitan asegurar la calidad del producto.Una vez finalizado el diseño es necesario revisarlo para asegurar la completitud y el cumplimiento de los requisitos del software.



• Codificación.

En esta fase, el diseño se traduce a un lenguaje de programación, dando como resultado un programa ejecutable. La buena calidad de los programas desarrollados depende en gran medida de la calidad del diseño.

Una vez codificados los programas deben revisarse su estilo y claridad, y se comprueba que haya una correspondencia con la estructura de los mismos definida en la fase de diseño.El listado fuente de cada módulo (o el programa fuente en soporte magnético) pasa a formar parte de la configuración del sistema.

• Pruebas.

Una vez que tenemos implementado el software es preciso probarlo, para detectar errores de codificación, de diseño o de especificación. Las pruebas son necesarias para encontrar el mayor número posible de errores antes de entregar el programa al cliente.

Es necesario probar cada uno de los componentes por separado (cada uno de los módulos o programas) para comprobar el rendimiento funcional de cada una de estas unidades.A continuación se procede a integrar los componentes para probar toda la arquitectura del software, y probar su funcionamiento y las interfaces. En este punto hay que comprobar si se cumplen todos los requisitos de la especificación.

Se puede desarrollar un plan y procedimiento de pruebas y guardar información sobre los casos de pruebas y los resultados de las mismas.

• Garantía de calidad.Una vez terminada la fase de pruebas, el software está casi preparado para ser entregado al cliente.

Mantenimiento.

La fase de mantenimiento se centra en los cambios que va a sufrir el software a lo largo de su vida útil. Como ya hemos dicho, estos cambio pueden deberse a la corrección de errores, a cambios en el entorno inmediato del software o a cambios en los requisitos del cliente, dirigidos normalmente a ampliar el sistema.La fase de mantenimiento vuelve a aplicar los pasos de las fases de definición y de desarrollo, pero en el contexto de un software ya existente y en funcionamiento.

INGENIERÍA INVERSA Y REINGENIERÍA DEL SOFTWARE.



• Ingeniería Inversa:

Para aquellos proyectos software desarrollado sin tener en cuenta las metodologías estructuradas de análisis y diseño, es muy útil aplicar técnicas de ingeniería inversa, las cuales permiten obtener los documentos de análisis y diseño pertinentes que permitan conocer la estructura interna de la aplicación.

• Reingeniería:

Si tenemos herramientas que son capaces de desarrollar una aplicación a partir del análisis de la misma, podemos aplicarlas a partir del producto obtenido de efectuar la ingeniería inversa a proyectos de software desarrollados sin tener en cuenta las metodologías estructuradas de análisis y diseño. En teoría, el resultado que se obtendrá será un proyecto de software realizado según los postulados del análisis estructurado y que soluciona el problema que desarrollaba el producto original.

METODOLOGÍAS DE DESARROLLO

1.- INTRODUCCIÓN.

1.1.- Conceptos generales.

Para desarrollar un proyecto software es necesario establecer un enfoque disciplinado y sistemático. Las metodologías de desarrollo, que influyen directamente en este proceso de construcción, se elaboran a partir del marco definido por uno o varios ciclos de vida.Pero, ¿qué entendemos por metodología?.

Hay que destacar, ante todo, que no hay un consenso entre los distintos autores sobre el concepto de metodología y, por lo tanto, no existe una definición universalmente aceptada. Sí hay un acuerdo en considerar a la “metodología” como un conjunto de pasos y procedimientos que deben seguirse para el desarrollo de software.

Una definición representativa del concepto podría ser la de [MADDISON, 1983], que define Metodología como “un conjunto de filosofías, fases, procedimientos, reglas, técnicas, herramientas, documentos y aspectos de formación para los desarrolladores de sistemas de información”.Según esto, una metodología es un conjunto de componentes que especifican:

• Cómo se debe dividir un proyecto en etapas.• Qué tareas se llevan a cabo en cada etapa.• Qué salidas producen y cuando se deben producir.• Qué restricciones se aplican.• Qué herramientas se van a utilizar.



• Como se gestiona y controla un proyecto.

Atendiendo a una definición más genérica, podemos considerar una metodología de desarrollo como un conjunto de procedimientos, técnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a realizar nuevo software. Normalmente consistirá en un conjunto de fases descompuestas en subfases (módulos, etapas, pasos,...). Esta descomposición del proceso de desarrollo guía a los desarrolladores en la elección de las técnicas que debe elegir para cada estado del proyecto, y facilita la planificación, gestión, control y evaluación de los proyectos. Una metodología, por tanto, representa el camino para desarrollar software de una manera sistemática.

Necesidades principales que se intentan cubrir con una metodología:

Mejores aplicaciones: el seguimiento de una metodología no basta para asegurar la calidad del producto final.

Un mejor proceso de desarrollo: que identifica las salidas de cada fase de forma que se pueda planificar y controlar el proyecto. Los sistemas se desarrollan más rápidamente y con los recursos apropiados.

Un proceso estándar en la organización: lo que aporta claros beneficios.

Entre los objetivos tenemos que:

Registrar los requisitos de un sistema de información de forma acertada.

Proporcionar un método sistemático de desarrollo de forma que se pueda controlar su progreso.

Construir un sistema de información dentro de un tiempo apropiado y unos costes aceptables.

Construir un sistema que esté bien documentado y que sea fácil de mantener.

Ayudar a identificar lo más pronto posible cualquier cambio que sea necesario realizar dentro del proceso de desarrollo.

Proporcionar un sistema que satisfaga a todas las personas afectadas por el mismo, ya sean clientes, directivos, auditores o usuarios.

La descomposición del proyecto llega hasta las tareas o actividades elementales. Para cada tarea se identifica un procedimiento que define la forma de ejecutarla. Como resultado de seguir un procedimiento, se obtienen uno o más productos. El sistema deseado está constituido por un conjunto de productos finales.



Para aplicar un procedimiento se pueden utilizar una o más técnicas gráficas con apoyos textuales formales y determinan el formato de los productos resultantes de cada tarea.Para la realización de una técnica podemos apoyarnos en las herramientas software que automatizan su aplicación. Algunas herramientas dan soporte específico a una metodología, otras son de propósito más general.

Una metodología puede seguir uno o varios modelos de ciclo de vida. El ciclo de vida indica qué es lo que hay que obtener a lo largo del desarrollo del proyecto. La metodología indicaría el cómo.

1.2.- Visión histórica del desarrollo de metodologías de desarrollo de sistemas de información.

1.2.1.- Desarrollo convencional.

El desarrollo convencional se basaba en funciones básicas de procesos de datos. Los programadores estaban más enfocados en las tareas de codificar que en la de recoger y comprender las necesidades de los usuarios. Se observó que había más de un papel en el proceso de desarrollo de sistemas: operadores, programadores y analistas de sistemas (funcionales y técnicos u orgánicos).

Este enfoque presenta los siguientes problemas:

Los resultados finales son impredecibles. No hay forma de controlar lo que está sucediendo en el proyecto,

dado que no hay fases establecidas ni productos intermedios sobre los que hacer verificaciones.

Los cambios organizativos afectan negativamente al proceso de desarrollo.

1.2.2.- Desarrollo estructurado.

Sigue unos métodos de ingeniería, dirigidos a aspectos tanto técnicos como de gestión en la construcción de software. Tiene los siguientes conceptos asociados:

Programación estructurada. Diseño estructurado. Análisis estructurado.

1.2.3.- Desarrollo orientado al objeto.

El paradigma orientado a objetos trata los procesos y los datos de forma conjunta. La orientación a objetos empieza con los lenguajes de programación orientados a objetos. En estos lenguajes se daba énfasis a la abstracción de datos y los problemas del mundo real se representaban



como un conjunto de objetos de datos para los que se adjuntaban un conjunto de operaciones.

2.- CARACTERÍSTICAS PRINCIPALES DE LAS METODOLOGÍAS.

2.1.- Impacto de la metodología en el entorno de desarrollo de software.

Todo entorno de desarrollo incluye un conjunto de componentes que condicionan la construcción del software. Cualquier cambio que se realice dentro del entorno puede tener un efecto inmediato sobre la productividad del personal de desarrollo. La productividad en sí no basta y debe estar asociada a la calidad de los productos finales. La metodología de desarrollo influye muy directamente en estos dos factores.

Dentro de este entorno, la organización mantiene a un equipo de desarrollo de software. Los procedimientos de gestión determinan el tipo de soporte automatizado, hardware y software. Los procedimientos de gestión coordinan y guían a los desarrolladores en el empleo de las técnicas. El soporte automatizado mejora la productividad automatizando diversas tareas y verificando su correcta realización. No todos los resultados pueden ser verificados de forma automatizada. Es necesaria la realización de revisiones manuales. Todos los entornos de desarrollo de software tienen formas de trabajo muy diferentes. La organización de desarrollo tiene dos opciones:

Seleccionar entre un gran número de posibilidades y combinaciones de métodos de gestión, técnicas de desarrollo y soporte automatizado, para crear y desarrollar la metodología de desarrollo software más apropiado.

Analizar y evaluar metodologías existentes y adoptar en la organización la que más se ajuste a sus necesidades. Esta es la más común.

2.2.- Características deseables en una metodología.

Existencia de reglas predefinidas: que definan sus fases, tareas, productos intermedios, técnicas, herramientas, ayudas al desarrollo y formatos de documentación estándar.

Cobertura total del ciclo de desarrollo: pasos que hay que realizar desde el planteamiento de un sistema hasta su mantenimiento, proporcionando mecanismos para integrar los resultados de una fase a la siguiente, de forma que se pueda referenciar a fases previas y comprobar el trabajo realizado.

Verificaciones intermedias: sobre productos generados en cada fase para comprobar su corrección. Por medio de revisiones software que detectan inconsistencias, inexactitudes o cualquier otro tipo de defecto que se genera durante el proceso de desarrollo evitando que salgan a relucir en la fase de pruebas o en las pruebas de aceptación



o durante la fase de mantenimiento. Planificación y control: una forma de desarrollar software de manera

planificada y controlada para que no se disparen los costes ni se amplíen los tiempos de entrega.

Comunicación efectiva: entre los desarrolladores para facilitar el trabajo en grupo y con los usuarios.

Utilización sobre un abanico amplio de proyectos: debe ser flexible. No se deberían utilizar metodologías diferentes para cada proyecto.

Fácil formación: los desarrolladores deben comprender las técnicas y los procedimientos de gestión.

Herramientas CASE: debe estar soportada por herramientas automatizadas que mejoren la productividad del equipo de desarrollo y la calidad de los productos resultantes.

La metodología debe contener actividades que mejoren el proceso de desarrollo: es necesario disponer de datos que muestren la efectividad de la aplicación del proceso sobre un determinado producto. Definir mediciones que indiquen la calidad y el coste asociado a cada etapa del proceso.

Soporte al mantenimiento: el campo de reingeniería del software debería ser tomado en cuenta por las metodologías para facilitar las modificaciones sobre los sistemas existentes.

Soporte de la reutilización del software: las metodologías estructuradas existentes no proporcionan mecanismos para la reutilización de componentes software. Se deberían incluir procedimientos para la creación, mantenimiento y recuperación de componentes reutilizables que no se limiten sólo al código.

3.- CLASIFICACIÓN DE LAS METODOLOGÍAS.

3.1.- Metodologías estructuradas.

Proponen la creación de modelos del sistema que representan los procesos, los flujos y la estructura de los datos de una manera descendente (top-down), tanto en las funciones del sistema, en la estructura de los datos o a ambos aspectos dando lugar a metodologías orientadas a procesos, orientadas a datos y mixtas.Mecanismos para el análisis:

Flujo de datos. Estructura de datos.

Mecanismos de subdivisión: cada metodología aplica un criterio diferente de descomposición, y se apoya en elementos gráficos distintos.

Proceso.



Estructura de datos.

Tendencias principales:

Metodologías orientadas a PROCESOS (FLUJO DE DATOS.) Metodologías orientadas a ESTRUCTURAS DE DATOS.

3.1.1.- Metodologías orientadas a procesos (flujo de datos).

La ingeniería del software está fundamentada sobre el modelo básico de entrada/proceso/salida de un sistema. Los datos se introducen en el sistema y el sistema responde ante ellos transformándolos para obtener las salidas.

Una especificación estructurada es un modelo gráfico, particionado, descendente y jerárquico de los procesos del sistema y de los datos utilizados por los procesos.

Estas metodologías enfocan el criterio de descomposición que emplean al concepto de Proceso.

Las herramientas asociadas a estas metodologías son:

Diagramas de flujo de datos. (DFD). Diagramas de Entidad-Relación. (Definición de almacenes de datos

para el DFD). Diccionario de datos. Descripciones funcionales.

o Lenguaje natural estructurado.o Tablas de decisión.

Diagramas de flujos de datos (DFD).

Son diagramas que representan los procesos (funciones) que debe llevar a cabo un sistema a distintos niveles de abstracción y los datos que fluyen entre los procesos. Los procesos más complejos se descomponen en nuevos diagramas hasta llegar a los procesos sencillos. Es la técnica más importante del análisis estructurado, y se emplea en todas las metodologías de análisis y diseño estructurados.

Diagrama de entidad-relación.

Se construye a partir del texto de los requerimientos. Está formado por: entidades, relaciones, atributos y claves.

Diccionario de datos.

Es el conjunto de las definiciones de todos los datos que aparecen en el



DFD, tanto almacenados como en los flujos de datos, incluido el propio diccionario.Especifica el contenido de la información usando una notación casi-formal (notación regular) tomada de la

Teoría de Lenguajes Formales.

Los datos compuestos se definen en función de sus componentes.Para composición de datos se usan como mecanismos: la secuencia, la selección y la agrupación repetida (multiconjunto).

Construcción de datos Notación Significado

SecuenciaSelecciónRepetición

=+[ ] { }n( )

Esta compuesto deYUno u otron repeticiones deDatos opcionales

Especificaciones de proceso:

En este apartado se incluyen la definición de las operaciones, describiendo con más detalle lo que ocurre dentro de un proceso, es decir, definen cómo se obtienen las salidas del proceso a partir de sus entradas.

Se usa un subconjunto del lenguaje natural con un cierto formato o estructura: por ejemplo un “pseudo-código imperativo”, un “ingles” o “castellano” “estructurado”. Los mecanismos de estructuración son: la secuencia, la selección y la repetición.

Ejemplos de metodologías orientadas al flujo de datos de:

Yourdon / de Marco. (Análisis Estructurado) Gane / Sarson (A. y Diseño Estructurado) Yourdon / Myers /Constantine (Diseño Estructurado) Page / Jones (Diseño Estructurado)

Ejemplo: Metodología de Yourdon/Constantine:

Realizar los DFD del sistema. Realizar el diagrama de estructuras, obteniéndolo a partir de los

DFD's mediante dos técnicas, al análisis de transformación y el análisis de transacción.

Evaluación del diseño, midiendo la calidad de la estructura resultante mediante el acoplamiento y la cohesión.



Preparación del diseño para la implantación (cuadernos de carga).

3.1.2.- Metodologías orientadas a ESTRUCTURAS DE DATOS.

También llamadas metodologías “dirigidas por los datos”.

Estas metodologías toman como base la idea de que los datos, además de fluir y tener un contenido, tienen una estructura. Así, el criterio de descomposición es la estructura de datos.

Los datos constituyen el corazón del sistema de información, son más estables que los procesos que actúan sobre ellos. El estudio de los procesos viene derivado de una definición inicial de los datos (modelo de datos) constituido por el conjunto de entidades de datos básicas y las interrelaciones entre ellas.

Como ejemplos de metodologías orientadas a la estructura de datos tenemos las metodologías de: DSED Warnier / Orr. (Análisis de entradas y salidas) JSD Jackson (Análisis de entradas) SADT Entidad-Relación.

Características comunes a estas metodologías:

Se identifican entidades y procesos. Se presupone una estructura jerárquica en los datos. (Si no lo es, se

fuerza el método). Se representa la estructura de los datos usando la secuencia, la

selección y la repetición. Se definen métodos para transformar una estructura de datos

jerárquica en una estructura de programa.

3.3.3.- Defectos de las metodologías estructuradas.

No dan respuesta fácil a cambios en el dominio del problema. Son inadecuadas para dominios de problemas de naturaleza

concurrente y de tiempo real. No ofrecen medidas para garantizar el principio de ocultación de

información.

3.2.- Metodologías orientadas a objetos.

Cobra mucha más importancia el aspecto de modelado del sistema, examinando el dominio del problema como un conjunto de objetos que interactúan entre sí. Tenemos dos enfoques en las metodologías orientadas al objeto:



Revolucionarios o puros: que entienden la orientación al objeto como un cambio profundo que convierten a las metodologías estructuradas en obsoletas.

Sintetistas o evolutivos: que piensan que el análisis y diseño estructurado constituyen la base para el desarrollo orientado al objeto, pudiéndose combinar elementos del análisis y diseño estructurado con los de orientación a l objeto. 3.3.- Sistemas en tiempo real.

Son sistemas muy dependientes del tiempo que procesan información orientada al control. Controlan y son controlados por eventos externos. Se caracterizan porque:

Se lleva a cabo el proceso de muchas actividades de forma simultánea.

Se asignan prioridades a determinados procesos. Se interrumpe una tarea antes de que concluya, para comenzar otra

de mayor prioridad. Existe comunicación entre tareas. Existe acceso simultáneo a datos comunes.

Para especificar los requisitos de estos sistemas hay que incluir nuevos conceptos para:

El manejo de interrupciones. La comunicación y sincronización entre tareas. Gestionar procesos concurrentes. Dar respuesta oportuna y a tiempo ante eventos externos. Datos continuos o discretos.

3.4.- Comparación entre Metodologías Estructuradas y Orientadas a Objetos.

Estructuradas Orientadas a Objetos

Para representar un modelo del mundo real, se requiere una transformación del espacio del problema

Correspondencia directa con los objetos del mundo real.



El Diseño se encuentra muy influenciado por el criterio de descomposición.

Se tratan datos y procesos con el mismo nivel de abstracción.

Cada módulo modela una función o un paquete de datos

Cada módulo representa un objeto o clase de objetos.

No son útiles en problemas de naturaleza concurrente o de tiempo real.

Son aplicables a todo tipo de problemas

Principales metodologías de desarrollo europeas

4.- PRINCIPALES METODOLOGÍAS DE DESARROLLO.

4.1.- Metodología MERISE.

Esta metodología surge en Francia en 1977 a propuesta del Ministerio de Industria, como un intento de unificar criterios en torno a la metodología de desarrollo para los sistemas informáticos de la Administración Pública Francesa.

Sus principios generales son:

Desglose en etapas: estudio preliminar, estudio detallado, realización y puesta en marcha.

División en el estudio de los tratamientos por un lado y el estudio de los datos por otro.

Uso del modelo Entidad/Relación y sus formalismos para representar los datos.

Uso de los Diagramas de Encadenamiento de Procedimientos para representar los tratamientos.

Completo reparto de tareas y responsabilidades entre los desarrolladores durante la fase inicial, y entre los usuarios y ordenador en la explotación. (Esquema director)

NIVEL TRATAMIENTOS DATOS OPCIÓN

CONCEPTUAL Modelo Conceptual

Modelo Conceptual

De gestión

ORGANIZACIONAL Modelo Organizacional

Modelo Lógico De organización

OPERACIONAL Modelo Modelo Físico Técnica



Operacional

4.2.- Metodología SSADM. (Método Estructurado de Análisis y Diseño de Sistemas).

Aparece en Gran Bretaña por los mismos motivos que MERISE y se establece como obligatoria para la Administración Pública a partir de 1983.

Los aspectos claves de esta metodología son:

Énfasis en los usuarios: sus requisitos y participación. Definición del proceso de producción. Tres puntos de vista: datos, eventos y procesos. Máxima flexibilidad en herramientas y técnicas de implementación.

SSADM proporciona un conjunto de procedimientos para llevar a cabo el análisis y diseño, pero no cubre aspectos como la planificación estratégica ni entra en la construcción del código.

4.3.- Metodología MÉTRICA. Versión 3.Ministerio para la Administraciones Públicas. Consejo Superior de Informática. Proyecto Métrica Versión 3. Metodología de planificación y desarrollo de Sistemas de Información, 2000. Disponible en:

http://www.map.es/csi/metrica3/index.html

Es la metodología adoptada como estándar por la Administración Pública Española. Consiste en un conjunto de fases donde se utilizan multitud de técnicas conducentes a la obtención de aplicaciones de calidad, fáciles de mantener y muy bien documentadas.

4.3.1.- Objetivos de Métrica versión 3.

La metodología MÉTRICA Versión 3 ofrece a las Organizaciones un instrumento útil para la sistematización de las actividades que dan soporte al ciclo de vida del software dentro de un marco que permite alcanzar los siguientes objetivos:

Proporcionar o definir Sistemas de Información que sirvan a la consecución de los fines de la Organización mediante la definición de



un marco estratégico para el desarrollo de los mismos. Dotar a la Organización de Productos software que satisfagan 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 y entendimiento entre los distintos participantes en la producción de software a lo largo de todo el ciclo de vida.

Facilitar la operación, mantenimiento y uso de los Productos software obtenido.

4.3.2.- Características.

MÉTRICA Versión 3 contempla el desarrollo de Sistemas de Información para las distintas tecnologías que actualmente están conviviendo y los aspectos de gestión que asegurarán que un Proyecto cumple sus objetivos en términos de calidad y coste.

Su punto de partida es la versión anterior de MÉTRICA de la cual se ha conservado la adpatabilidad, flexibilidad y sencillez. Se ha tenido en cuenta la experiencia de los usuarios de las versiones anteriores para solventar los problemas o deficiencias detectados.

En la elaboración de MÉTRICA Versión 3 se han tenido en cuenta los métodos de desarrollo más extendidos, así como los últimos estándares de ingeniería del software y calidad, así como referencias específicas en cuanto a seguridad y gestión de proyectos.

4.3.3.- Estructura de Métrica V3.En una única estructura la metodología MÉTRICA Versión 3 cubre distintos tipos de desarrollo: estructurado y orientado a objetos, y facilita a través de interfaces la realización de los procesos de apoyo u organizativos.

Procesos principales. Interfaces.

• Procesos principales:Cada Proceso detalla las Actividades y Tareas a realizar.Para cada tarea se indican:

Las técnicas y prácticas a utilizar. Los responsables de realizarla. Sus productos de entrada y salida.



• Estructura de procesos:

Planificación PSI Desarrollo Estudio de viablidad EVS Análisis ASI Diseño DSI Construcción CSI Implantación y aceptación IAS Mantenimiento MSI

• Interfaces

Aseguramiento de la Calidad Seguridad Gestión de Configuración Gestión de Proyectos

Análisis de necesidades y estudio de viabilidadCómo comienza un proyecto.

La Ingeniería del Software, término utilizado por primera vez por Fritz Bauer en la primera conferencia sobre desarrollo de software patrocinada por el Comité de Ciencia de la OTAN celebrada en Garmisch, Alemania, en octubre de 1968, puede definirse según Alan Davis como "la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento,


https://sites.google.com/site/adai6jfm/principales-metodologas-de-desarrollo-europeas/dESARROLLO.png?attredirects=0


dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios".

La necesidad de aplicar los principios de otras ingenierías al desarrollo de software está plenamente justificada por el alto grado de fracasos en los procesos de desarrollo de software. Desde 1994 el Grupo Standish realiza estudios en los que se encuestan a directores de proyectos de desarrollo de software sobre la situación del desarrollo de software y sus principales problemas en Estados Unidos. Los resultados de estos informes muestran que casi un tercio de los proyectos de desarrollo de software se cancelan durante su desarrollo y que la gran mayoría presenta graves desviaciones respectos a plazos y presupuestos iniciales.

Las principales causas, tanto de éxito como de fracaso, indicadas por los directivos encuestados en los informes CHAOS, están relacionadas directamente con la correcta identificación y gestión de los requisitos que debían cumplir las aplicaciones desarrolladas para satisfacer las necesidades de los usuarios.Por tanto, la primera etapa dentro de la concepción de un sistema informático consiste en entender y representar de un modo apropiado los requisitos de usuario. Este proceso recibe el nombre de ingeniería de requisitos y ha sido reconocido como una tarea crucial dentro del proceso de desarrollo software (Bennett, 1997; Kotonya et al. 1998).

Los errores originados en la etapa de requisitos pueden permanecer sin detección hasta la etapa de operación, provocando fallos con serias consecuencias sobre todo en sistemas críticos.Estos errores producidos en la etapa de extracción o licitación de requisitos están provocados principalmente por el gap existente entre los usuarios y el proceso de desarrollo

1. Actividades iniciales.


https://sites.google.com/site/adai6jfm/home/cmo-comienza-un-proyecto/cuadroestadistico.png?attredirects=0


Un proyecto es esencialmente un conjunto de actividades interrelacionadas, con un inicio y una finalización definida, que utiliza recursos limitados para lograr un objetivo deseado.

Las actividades son las tareas que deben ejecutarse para llegar en conjunto a un fin preestablecido (objetivo deseado). Toda actividad debe estar basada en una metodología y en principio, cualquier metodología es mejor que ninguna.

Un aspecto fundamental en todo proyecto es el orden en el cual se realizan las actividades. Y para determinar la secuencia lógica de las actividades se debe establecer el método, el tiempo y el costo de cada operación.

Los recursos son los elementos utilizados para poder realizar la ejecución de cada una de las actividades. En cuanto al objetivo del proyecto, este puede ser sencillo y no demandar ni muchas actividades ni demasiados recursos; o por el contrario, puede ser complejo y exigir múltiples actividades y una gran cantidad de recursos para poder alcanzarlo.

Independientemente de su complejidad, característicamente todo proyecto reúne la mayoría de los siguientes criterios:

Tener un principio y un fin Tener un calendario definido de ejecución Plantearse de una sola vez Constar de una sucesión de actividades o de fases Agrupar personas en función de las necesidades específicas de cada

actividad Contar con los recursos necesarios para desenvolver las actividades

Cada uno de los proyectos que se desarrollan en las organizaciones tiene cometidos que deben cumplirse en un cierto plazo de tiempo y que además requieren de la concurrencia de otras personas. Es aquí donde empieza a tener relevancia la figura del administrador, en los proyectos a realizarse en las organizaciones, incluidos los proyectos informáticos.

Los administradores eficaces de proyectos, son los que logran que el trabajo se ejecute a tiempo, dentro del presupuesto, y conforme a las normas de calidad especificadas.A la hora de seleccionar un administrador del proyecto podemos fijarnos si dispone de una serie de cualidades como: capacidad de liderazgo, comprensión técnica, competencia en la gestión, presteza y decisión, versatilidad y flexibilidad, integridad, previsión.



Definición del problema

1.1. ¿Qué es un proyecto informático?

Los recursos más frecuentemente utilizados que caracterizan a un sistema de información, son los componentes de la Tecnología de la Información (TI) como el uso de hardware, software y comunicaciones.

Considerando la importancia que la informática tiene en los planes estratégicos de cualquier empresa moderna; no solamente se debe tener en cuenta la evolución de los recursos de la tecnología de la información, sino también las distintas metodologías para el desarrollo de los sistemas de información.

Así pues, el solo hecho de considerar a un asunto informático como un proyecto al que se asocian técnicas y procedimientos de diseño, supone un paso importante.

Un proyecto informático es un sistema de cursos de acciones simultáneas y/o secuenciales que incluye personas, equipamientos de hardware, software y comunicaciones, enfocadas en obtener uno o más resultados deseables sobre un sistema de información.

Siendo que los diferentes Sistemas de Información abordan los diferentes tipos de problemas organizacionales; podemos clasificar a los Sistemas de Información según sean las aplicaciones que necesite cada usuario en: Sistemas de Transacciones, Sistemas de Soporte para la toma de decisiones, y Sistemas Expertos.

1.2. Inicio de un proyecto informáticoEl inicio de un proyecto informático generalmente viene dado en la solicitud de unos requisitos o necesidades de los usuarios.En una empresa u organización se plantea la necesidad de un desarrollo software para satisfacer las necesidades de dar soporte informático al sistema de información o parte de él. Si ya se dispone de un entorno informático estable, la decisión de iniciar un proyecto viene dada, generalmente, por las necesidades de mantenimiento del software existente, modificaciones requeridas, mejoras o sustitución por obsolescencia física, tecnológica o competitiva, o por capacidad para nuevos sistemas.


https://sites.google.com/site/adai6jfm/home/definicin-del-problema/tit.png?attredirects=0


La Modificación del programa; involucra algo más que un simple cambio en el programa; involucra un cambio estructural de una entidad. Por ejemplo, un cambio en el número de dígitos del código postal, o en el código de zona telefónica. La diferencia con el Mantenimiento es el grado de importancia

La Mejora del sistema; es el agregado de capacidades que no formaron parte del sistema de información original; por ejemplo cuando en una división se implementó un sistema de inventarios, este sistema no incluía un módulo para calcular la futura demanda de bienes. La inclusión de este sofisticado módulo de cálculo es considerado una mejora del sistema.

El Reemplazo del sistema; ocurre cuando los sistemas de información se tornan físicamente, tecnológicamente o competitivamente obsoletos. Como es el caso de la utilización del láser, en el reconocimiento óptico de caracteres para la lectura del código de barras, remplazando a la entrada por teclado.

La Nueva Capacidad del sistema; son sistemas de información para los cuales no es necesario el uso de la automatización. Están dados por la capacidad de poder modelizar la aplicabilidad de nuevos sistemas. Un ejemplo de ello, es la aplicación de los sistemas expertos.

Una vez tomada la decisión de emprender el proyecto deben seguirse unas técnicas de recogida de información sobre el proyecto, implicando a los directivos nivel alto/medio.

El resultado de los estudios previos se suelen recoger en un documento llamado informe de necesidades.

A continuación se realiza el estudio de la viabilidad del proyecto (Análisis de factibilidad)

Propuesta de soluciones alternativas

1.3. Estudio de viabilidad

En la práctica, los proyectos de desarrollo software se caracterizan por la escasez de recursos y la dificultad para cumplir los plazos establecidos. Por lo tanto, antes de seguir con un desarrollo debe llevarse a cabo un estudio de viabilidad y analizar los riesgos que comporta.

La realización del análisis de viabilidad exige bastante experiencia y supone un proceso de estudio donde pueden encontrarse las siguientes


https://sites.google.com/site/adai6jfm/home/definicin-del-problema/tit2.png?attredirects=0


fases:

Estudiar la solicitud del proyecto y establecer el alcance y los límites del sistema.

Estudiar la situación actual, describiendo y valorando los actuales sistemas de información e identificando a usuarios y personas involucradas o afectadas por el proyecto.

Realizar una definición preliminar de los requisitos, catalogando y especificando los mismos, así como las directrices técnicas o de gestión que puedan influir en el proyecto.

Estudiar y especificar las diferentes alternativas de solución que se puedan concebir. Por ejemplo:

o Comprar un producto software comercial, ya construido, que cumpla los requisitos marcados.

o Desarrollar el producto internamente.o Desarrollarlo de forma externa mediante un contrato

(outsourcing). En este caso, es necesario realizar una petición de propuestas, seleccionar uno de los ofertantes y supervisar los resultados mediante un control de aceptación del producto [ISO, 1995].

o Automatizar sólo parcialmente el sistema para reducir gastos.

Evaluar cada una de las alternativas, incluyendo:o Viabilidad económica. (¿Los beneficios compensan los

costes?). o Técnica. (¿Se encuentra disponible la tecnología necesaria?) o Legal. (¿Se atenta contra alguna ley o reglamento? p.e.

LOPD, Ley Orgánica de Protección de Datos) o Operativa. (¿Puede coordinarse con los métodos ya

existentes? ¿Encaja en la filosofía de la empresa?)o Plazos y calendarios: determinar si el plazo es realista, las

fechas apropiadas. Seleccionar y aprobar la alternativa más apropiada.

Es posible que después de analizar la viabilidad del proyecto, éste se desestime. Hay que tener en cuenta que el dinero que ya se ha invertido en el análisis de viabilidad no debería condicionar esta decisión. Si no se desestima, realizaremos una especificación detallada de la alternativa seleccionada, estableciendo fechas y compromisos de trabajo por parte de las personas y departamentos implicados, es decir, la definición de un plan inicial del proyecto.

1.4. Análisis de Coste-Beneficio.

El análisis de coste-beneficio permite seleccionar la alternativa más



beneficiosa de entre varios proyectos y prever las necesidades financieras.

La mayor fuerza de un análisis coste-beneficio reside en su utilidad para tomar decisiones eficientes. No es solo que puedan medirse los beneficios, restar de ellos los costes, y ver si el saldo es negativo (por tanto desestimando el proyecto) o positivo (estimándolo), sino que nos permite hallar su tasa de rendimiento o, alternativamente, el volumen de ganancia social que reportaría. Comparando rendimientos, puede elegirse el proyecto al que más eficientemente podemos dedicar los siempre escasos recursos de que disponemos.

Los pasos habituales a seguir en la elaboración de un análisis coste-beneficio son:

1. Definir con claridad el cambio a valorar (nueva situación respecto a la evolución esperada del status quo)

2. Identificar los principales costes y beneficios esperados3. Decidir el año de referencia del análisis (generalmente el periodo

inicial, cero), el año del periodo inicial y el año del periodo final (si como es habitual se toma el año como unidad temporal de medida)

4. Decidir si se van a utilizar valores constantes o nominales. Los más frecuente es utilizar valores constantes (también llamados reales), referidos al año de referencia o periodo inicial

5. Estimar los valores de cada variable para cada periodo (este es el paso que más trabajo conlleva)

6. Decidir que tasa de descuento se toma como referencia (en términos reales son habituales tasas del 4%, 5%, 6%)

7. Estimar algunos de los indicadores básicos del análisis coste-beneficio:

Cociente entre Beneficios y Costes (también llamado Ratio de Beneficios y Costes)

Valor Actual Neto (VAN, también llamado Valor Presente Neto)

Tasa Interna de Retorno (TIR, también llamada Tasa de Retorno Interno, TRI)

Primer Periodo de Retorno de la Inversión (también llamado Break-Even Point, entre otros términos)

8. Realizar un análisis de sensibilidad con las principales decisiones y variables utilizadas

9. Emitir un consejo sobre la toma de decisión respecto al cambio o cambios considerados

A la hora de realizar este análisis debemos tener en cuenta tanto los elementos tangibles, que se pueden valorar directamente, como los



elementos intangibles, que pueden marcar la viabilidad de un proyecto (obtención de ventajas económicas por la toma de mejores decisiones, beneficios competitivos de un mejor entorno de trabajo,…)

En general, los datos recopilados para el análisis de coste-beneficio se suelen presentar en forma de tabla. Siguiendo a (Piattini, 2006), en las columnas aparecerán los años de vida del proyecto y en las filas los distintos conceptos de gasto y beneficio del proyecto.

Entre los costes que hay que tener en cuenta destacan:

Personal Informático

Consultoría Software adicional

Hardware Infraestructura Debidos al usuario

Por otra parte, los beneficios pueden aparecer de diferentes maneras:

Incremento de la productividad, ahorro o mejor uso de recursos. Ahorro de gastos de mantenimiento. Ahorro en inversiones y mantenimiento de hardware y/o software. Incremento de ventas, resultados o disminución coste de

producción. Ahorro de material, recursos externos, etc. Beneficios financieros. Intangibles: incremento de calidad, reducción de errores, mejora de

imagen, mayor fiabilidad, etc.

Para un análisis eficaz de coste-beneficio conviene resaltar que la mayoría de las estimaciones de costes y beneficios suelen consistir en rangos de valores probables. Tomada la decisión de continuidad del proyecto no se puede pretender mayor precisión en esta etapa de decisión. A medida que avanza el proyecto podrá refinarse el análisis económico, pero la decisión de realizarlos está ya tomada. Por tanto, es recomendable hacer estimaciones conservadoras, tratando de valorar y prever todos los riesgos.

Selección de una alternativa

2. Técnicas de recogida de información

Normalmente los técnico de desarrollo de software no conocen todos los



detalles del trabajo de la empresas para la cual van a desarrollar la aplicación. Por otra parte los usuarios no saben que información es necesaria o relevante para el desarrollo de una aplicación. Para facilitar la comunicación de ambos colectivos en el proceso de análisis de necesidades, se recurre a técnicas de comunicación y recopilación de información.

En general, el proceso de análisis debería seguir los siguientes pasos:

Identificar las fuentes de información relevantes para el proyecto y planificar las actividades de investigación.

Realizar las preguntas apropiadas para comprender sus necesidades.

Analizar la información para detectar los aspectos que quedan poco claros.

Confirmar con los usuarios los que parece haberse comprendido de los requisitos.

Sintetizar los requisitos en un documento de especificación apropiado.

Por tanto, el resultado del proceso será la obtención del documento de especificación de requisitos.Las técnicas principales utilizadas para la recogida de información son las siguientes:

Entrevistas. Desarrollo conjunto de aplicaciones – Joint Application Design

(JAD). Prototipado. Construcción de una maqueta o modelo. Observación. Analizar in situ la empresa del cliente. Estudio de documentación. los documentos que describen el

negocio, desde planes estratégicos hasta manuales de operación o de procedimientos, así como muestras de impresos u otros documentos de trabajo para conocer los datos que se manejan.

Cuestionarios. Útiles para recopilar información de un gran número de personas en poco tiempo.

Tormenta de ideas (Brainstorming). Reuniones de 4 a 10 personas, usuarios o técnicos, donde se identifican un primer conjunto de requisitos en aquellos casos en los que no están muy claras todas las necesidades.

2.1. Entrevistas

Una entrevista se puede definir como un intento sistemático de recoger información de otra persona a través de una comunicación interpersonal que se lleva a cabo por medio de una conversación estructurada.



El aspecto más destacable radica en la preparación de la entrevista como esencia para cumplir sus objetivos.

A continuación se resumen las diferentes fases que se pueden distinguir en una entrevista.

Preparación. el entrevistador deberá documentarse e investigar la situación de la organización, analizando los documentos, programas, ficheros… de la empresa. Preparar el objetivo y el contenido de la entrevista y planificar lugar y hora.

Realización. Se distinguen tres etapas en el acto de la entrevista: apertura, desarrollo y terminación.

o En el desarrollo pueden emplearse distintas técnicas: Preguntas abiertas, directas y/o cerradas, Utilizar las palabras y frases apropiadas, Asentimiento y Muestras de Escucha, Repetir las respuestas dadas, Pausas.

Análisis. Recapitular los resultados obtenidos, reorganizar la información, contrastarla con otras entrevistas o fuentes de información, etc.

2.2. Desarrollo conjunto de aplicaciones – JAD

Esta técnica está basada en la creación de equipos de usuarios y analistas que se reúnen para trabajar conjuntamente en el establecimiento de las necesidades del software a desarrollar.

El JAD se basa en el aprovechamiento de las dinámicas de grupo, ayudas visuales de comunicación y comprensión de soluciones, y un proceso de trabajo sistemático y organizado.

Las fases que componen un JAD son:

Adaptación o preparación. Consiste en la selección de los participantes formada por usuarios y analistas, recabar una cierta información sobre el sistema a desarrollar y organizar la reunión (varias, de 2 a 4 días) indicando el lugar, fecha, ayudas audiovisuales, agenda de trabajo y la redacción de un documento de trabajo (una especificación rudimentaria de requisitos sobre los que se discutirá).

Sesión JAD. Las reuniones donde, partiendo de un documento de trabajo, se analiza para completar el conjunto de requisitos del sistema. Al final de la sesión se tendrá concluido un documento de especificación de requisitos, que debe ser aprobado por los presentes.

Documentación. En esta fase se procede a reordenar en el formato



adecuado el documento obtenido en la sesión JAD obteniendo el documento de especificación de requisitos final

Entrevistas vs. JAD

ENTREVISTAS JAD

Requieren mucho tiempo (prepararlas, hacerlas, y

elaborar conjunto coherente de requisitos a partir de

diferentes entrevistados). Más difícil detectar errores

(sólo el analista las revisa).

Participación más profunda usuarios (se identifican con el sistema) Más difícil llevar a la

práctica. Requiere más organización.

Empíricamente:o mayor ahorro tiempo,o mayor satisfacción de

los usuarios

2.3. Prototipado

Consiste en la elaboración de un modelo o maqueta del sistema con el objeto de facilitar la evaluación de los requisitos con los usuarios, permitiendo descubrir con rapidez si el usuario se encuentra satisfecho, o no, con los requisitos.

Disponemos de tres tipos de prototipos principales:

Prototipado de la interfaz de usuario. Nos permite asegurar de que la especificación de requisitos está bien diseñada, que satisface las necesidades del usuario. Indicar que en este sentido no encontramos con lenguajes de 4ª generación que aportan capacidad de prototipado.

Modelos de Rendimiento. Tiene carácter técnico, por lo que no se utiliza en requisitos.

Prototipado funcional. Relacionado con los ciclos de vida con varias iteraciones, el prototipo será la primera versión del sistema con funcionalidad limitada, desarrollándolo hasta llegar a la aplicación final.

En algunos casos se utiliza el prototipo como un medio para formalizar la aceptación previa del cliente de la especificación de requisitos.



ANÁLISIS DE REQUISITOS. ANÁLISIS ESTRUCTURADO. MODELIZACIÓN CONCEPTUAL DE FUNCIONES

Introducción al análisis de requisitos (A.R.)

3.1 Introducción al análisis de requisitos

Como ya conocemos, el término análisis aplicado a sistemas significa descomponer el sistema en sus componentes para estudiar cada uno de ellos tanto como un ente aislado como en interacción con el resto de los componentes.

Para ser útil, al análisis debe seguir un proceso de síntesis que consistirá en unir los componentes del sistema para determinar cómo funcionan en conjunto.

Cuando se habla de una fase del ciclo de vida, el análisis consiste en producir un documento de especificación de requisitos que describa lo que el sistema debe hacer, pero no cómo hacerlo. No se trata pues de una actividad sólo de análisis, sino también de síntesis.

Se define el análisis de requisitos como “el proceso del estudio de las necesidades de los usuarios para llegar a una definición de los requisitos del sistema, de hardware o de software, así como el proceso de estudio y refinamiento de dichos requisitos” (Estándar IEEE Std. 610 [IEEE 1990]).

El Requisito es pues “una condición o capacidad que necesita el usuario para resolver un problema o conseguir un objetivo determinado” (por ejemplo, poder listar rápidamente todos los clientes que deben dinero). Por extensión, el término Requisito se aplica también a “las condiciones que debe cumplir o poseer un sistema o uno de sus componentes para satisfacer un contrato, una norma o una especificación”.

La definición de los requisitos en un proyecto debe ser fruto del trabajo conjunto de las partes involucradas en su desarrollo: Suministradores de software (analistas), clientes y usuarios. Ningún colectivo antes citado puede redactar la Especificación de Requisitos Software (ERS) ya que:

El cliente no suele conocer el proceso de diseño y desarrollo del software.

Los analistas no entienden completamente el problema del cliente dado que no dominan su área de trabajo.

La fase de análisis de requisitos, según el estándar IEEE 1074 [IEEE, 1991] se desglosa en tres grandes actividades:

Definir los requisitos de software. Tarea iterativa para crear una definición o especificación preliminar de los requisitos que debe



cumplir el software a partir de la información obtenida mediante técnicas de recogida de información analizadas en el punto anterior.

Definir los requisitos de las interfaces del software con el resto del sistema y con el exterior. Deben definirse las propiedades que se deben satisfacer para obtener una interacción eficaz con otros elementos del sistema (el usuario, el hardware, otras aplicaciones software,...). En particular la interfaz con el usuario es crítica para la facilidad de uso (y por tanto el éxito) del software. Los requisitos de interfaz con otras aplicaciones deben describir las características para que el software se relacione con ellas, las cuales pueden estar muy influenciadas por restricciones de trabajo del sistema (S.O. utilizado, SGBD empleado, Compiladores, controladores de red, etc.).

Así mismo deben definirse las características de las interrelaciones con elementos hardware.

Integrar los requisitos en un documento de especificación y asignarles prioridades. La asignación de prioridades debe hacerse en función de su importancia o los beneficios que puede aportar su cumplimiento.

Otra manera de describir las actividades que se realizan en la fase de análisis de requisitos sería la siguiente (Raghavan, et al., 1995):

Extracción o determinación de requisitos. Proceso mediante el cual los clientes o futuros usuarios del software descubren, revelan, articulan y comprenden los requisitos que desean.

Análisis de requisitos. Proceso de razonamiento sobre los requisitos obtenidos en la etapa anterior, detectando y resolviendo posibles inconsistencias o conflictos, coordinando los requisitos relacionados entre sí, etc.

Especificación de requisitos. Proceso de redacción o registro de los requisitos. Suele recurrirse a un lenguaje natural, lenguajes formales, modelos, gráficos, etc.

Validación de los requisitos. Confirmación, por parte del usuario o el cliente de que los requisitos especificados son válidos, consistentes, completos, etc.

Aunque estas actividades no tienen por qué realizarse en secuencia, ya que hay muchas iteraciones y solapamientos entre ellas, sí marcan un proceso general para la fase de análisis.

3.2. ESPECIFICACIÓN DE REQUISITOS DEL SOFTWARE

3.2.1. Introducción



Según el estándar IEEE, 1990 se define:

Especificación: documento que define, de forma completa, precisa y verificable, los requisitos, el diseño, el comportamiento u otras características de un sistema o de un componente de un sistema

Software: Conjunto de programas, procedimientos y documentación asociada a la operación de un sistema informático.

Con estas premisas puede definirse la Especificación de Requisitos del Software (ERS) como la documentación de los requisitos esenciales (funciones, rendimiento, diseño, restricciones y atributos) del software y de sus interfaces externas [IEEE,1990].Las dos características fundamentales de una ERS eficaz son:

Incluir información veraz, es decir, coherente con las necesidades reales del usuario que se desean satisfacer.

Comunicar dicha información de forma eficaz, es decir, de tal manera que se pueda comprender perfectamente.

Objetivos de ERS.

Ayudar a los clientes a describir claramente lo que se desea obtener mediante un cierto software.

Ayudar a los desarrolladores a entender qué quiere exactamente. Servir de base para desarrollos de estándares de ERS particulares

para cada organización.

Ventajas de ERS.

Contrato cliente –desarrolladores. Reducción del esfuerzo de desarrollo. Base para la estimación de costes y planificación. Punto de referencia para procesos de verificación y validación. Base para posibles mejoras.

Las exigencias para una ERS conducen a no excederse a la hora de definirla y construirla, sino más bien a abordar la descripción de lo que hay que desarrollar, no el cómo, el cuándo, etc., cuando se desarrolla el software. Esto implica:

Describir correctamente todos los requisitos de software sin incluir requisitos necesarios.

No describir ningún detalle de diseño de software, de su verificación, de la dirección del proyecto, excepto las restricciones impuestas al diseño que influyen en los requisitos.

3.2.2. Características de una buena Especificación de Requisitos del



Sistema (ERS)

Las características deseables para una buena ERS son las siguientes [IEEE 1984B]:

No ambigua. Completa. Correcta. Verificable. Consistente. Modificable. Facilidad para identificar el origen y las consecuencias de cada

requisito. Facilidad de utilización durante la fase de explotación y de

mantenimiento.

Correcta. Todo requisito de la ERS contribuye a satisfacer una necesidad real.

No ambigua. Cada requisito descrito debe tener una única interpretación.

Completa. Lo será si:

Incluye todos los requisitos significativos del software. Define la respuesta del software a todas las posibles clases de datos

de entrada y en todas las posibles situaciones, tanto para los datos válidos como para los que no lo son.

Está conforme con el estándar de especificación que se deba cumplir.

Están etiquetadas y referenciadas en el texto todas las figuras, tablas y diagramas.

Si algún término está por determinar, se debe acompañar de una descripción de las condiciones que lo han causado y una posible descripción para eliminarlo.

Verificable. Si para cada requisito expresado en la ERS existe un procedimiento de prueba finito y efectivo en coste para demostrar que el futuro sistema lo satisface.

Consistente. Lo será sí y sólo sí ningún conjunto de requisitos entran en conflicto entre ellos. Pueden darse tres tipos de conflictos:

Dos o más requisitos pueden describir el mismo objeto real pero utilizan términos distintos para designarlo.

Las características especificadas de objetos reales pueden estar en conflicto.

Puede haber conflicto lógico o temporal entre dos acciones determinadas.



Modificable. La estructura y el estilo de la ERS deben permitir que cualquier cambio necesario en los requisitos pueda realizarse de forma fácil, completa y consistente. Esto implica que la ERS debe:

Tener una organización coherente y manejable (con una tabla de contenidos, un índice y referencias cruzadas).

No ser redundante, es decir, el mismo requisito no debe aparecer en más de un lugar en la ERS.

Facilidad para identificar el origen y las consecuencias de cada requisito (facilidad de traza).

Se dice que una ERS facilita las referencias con otros productos del ciclo de vida si establece un origen claro para cada uno de los requisitos y si posibilita la referencia de estos requisitos en desarrollos futuros o en incrementos de la documentación.Cuando un requisito de la ERS representa un desglose o una derivación de otro requisito, se debe facilitar tanto las referencias hacia atrás como las referencias hacia delante en el ciclo de vida. Estas últimas son especialmente importantes para el mantenimiento del software. Cuando el código o la documentación son modificados, es esencial poder comprobar el conjunto total de requisitos que pueden verse afectados por estas modificaciones.

Facilidad de utilización durante la fase de explotación y de mantenimiento. La ERS debe considerar las necesidades de mantenimiento, incluyendo una eventual sustitución del software, especialmente debido a:

El personal que se encarga del mantenimiento no ha estado relacionado con el desarrollo del producto software.

Gran parte de los conocimientos y de la información necesaria para el mantenimiento se dan por supuestos en la organización del desarrollo, pero suelen estar ausentes en la organización de mantenimiento.

3.2.3. Evolución de las ERS

Normalmente, la ERS deberá ser cambiada a medida que progresa el producto software ya que es casi imposible especificar algunos detalles en el momento en el que se inicia el proyecto y es casi seguro que se realizarán cambios adicionales como consecuencia de haber encontrado deficiencias, defectos e inexactitudes que se descubren a medida que el producto evoluciona.En este proceso deben tenerse en cuenta las consideraciones siguientes:

El requisito debe ser especificado de la forma más completa posible, aun en el caso en que se prevean de forma inevitable revisiones en



el proceso de desarrollo. Debe iniciarse un proceso formal de cambio para identificar,

controlar, seguir e informar de cambios proyectados tan pronto como sean identificados.

Los cambios aprobados en los requisitos deben incluirse en la ERS de forma que permita:

Suministrar una revisión precisa y completa del rastro de las modificaciones

Permitir un examen de fragmentos actuales y reemplazados en la ERS.

3.2.4.- Estructura para las ERSUn modelo propuesto por el estándar IEEE Std. 830 [IEEE, 1984b] es el que se presenta a continuación:


https://sites.google.com/site/adai6jfm/home/introduccin-al-anlisis-de-requisitos-ar/a1.png?attredirects=0


Existen otras normas emitidas por otros organismos que también aportan esquemas para documentar las ERS (DOD, 1988, DORFMAN y THYER, 1990).

3.2.5. Especificación de requisitos de Interfaces

Las interfaces con el exterior coinciden con lo que tradicionalmente se ha llamado entradas y salidas (E-S) del sistema. En el caso del análisis estructurado, pueden identificarse fácilmente observando los flujos que entran y salen del sistema en el diagrama de contexto (del que se hablará posteriormente).

En el caso de las salidas puede hablarse de las pantallas de presentación de la información, listados o salida en papel, ficheros, etc. Las entradas serán pantallas de introducción de datos mediante teclado, introducción de datos mediante sensores, ficheros, etc.

La definición de las interfaces de E-S tiene como objetivo la estabilización del modo en que el sistema va a interactuar con el exterior del sistema.


https://sites.google.com/site/adai6jfm/home/introduccin-al-anlisis-de-requisitos-ar/a2.png?attredirects=0


3.3.- Visión general de las técnicas de especificación

Sobre la clasificación de técnicas de especificación no existe una regla general por lo que posiblemente, la forma más lógica de hacerlo sea por orden alfabético. Sin embargo, pueden clasificarse las técnicas bajo dos enfoques diferentes:

Por la forma de representación (gráfica, textual, matricial, DFD, DD, etc.)

Por el enfoque de Modelización bajo los que se crean modelos del sistema relativos a su función, información y tiempo.

3.3–1.- Clasificación según la forma de representación

Gráficas. Utilizan iconos que representan un componente particular del modelo. Se usan cuando se quiere resaltar la conexión entre los distintos componentes del modelo.

Textuales. Se utilizan para especificar con más detalle los componentes definidos en los gráficos mediante una gramática definida más o menos formal.

Marcos o plantillas. (“Templates”) especifican información relativa a un componente de un modelo que ha sido declarado en un diagrama o en otro marco. Se representan mediante un formulario que incluye todas sus características.

Matriciales. Son técnicas de comprobación entre modelos que permiten estudiar las referencias cruzadas entre sus componentes.

Modelización conceptual de datos

Introducción a las bases de datos. Concepto.



1.- INTRODUCCIÓN.1.1.- Sistemas de información (SI). (Recordatorio del tema 1).

Un SI es un conjunto de elementos ordenadamente relacionados entre sí de acuerdo con ciertas reglas, que aportan a la organización a la cual sirven la información necesaria para el cumplimiento de sus fines.

Los SI deben cumplir una serie de objetivos a la hora de tratar la información:

Proporcionar la información correctamente. Proporcionarla en el momento y en el lugar requerido. Proporcionarla a las personas autorizadas para ello. Todos estos objetivos deben de realizarse con un coste mínimo.

Para llevar a cabo esto, un SI debe realizar una serie de funciones sobre una colección de datos estructurada:

Recoger, procesar y almacenar datos.

Facilitar la recuperación, elaboración y presentación de los datos Componentes del S.I.

Contenido: los datos, su descripción y los programas que los manipulan.

Equipo físico: el ordenador soporte del sistema de información. Equipo lógico (software): SGBD, sistemas operativos, S.G. Ficheros. Administrador: la persona o equipos responsables de la calidad y

disponibilidad de los datos. Usuarios.

1.2.- Fases y conceptos para la abstracción.

A la hora de abordar el estudio de un sistema de información se utilizan diversos métodos de abstracción, como el enfoque sistémico u holístico, para simplificar la complejidad de comprensión e interacción con el sistema de información.

En el desarrollo de la abstracción se avanzará por tres fases:

Fase 1ª. Aislamos la parte del mundo real que es objeto de nuestro estudio e identificamos los diferentes objetos y las propiedades de éstos.

Fase 2ª. Es el proceso de abstracción propiamente dicho, del cual se obtiene un modelo. Utilizaremos cuatro conceptos para la abstracción:



Entidad, atributo, relación y restricción semántica.

Entidad: Cualquier persona, objeto o suceso sobre el cual queremos guardar información.

Atributo: es una propiedad básica que caracteriza a una entidad. Relación: es una asociación entre una, dos o más entidades.

Ejemplo: Dada una asignatura, podrá ser impartida por varios profesores; y dado un profesor podrá impartir varias asignaturas.

Restricción semántica: Tanto entidades, atributos, como relaciones pueden estar sometidas en el mundo real a restricciones que nos anulen algunas de las ocurrencias de entidades, atributos o relaciones.

Restricción de Entidad: no puede haber dos profesores con el mismo D.N.I.

Restricción de Atributo: no puede existir un valor del salario superior a 200.000.

Restricción de Relación: un profesor no puede impartir más de 2 asignaturas.

Fase 3ª. Organizar el conjunto de información que hemos definido en la etapa anterior para almacenarlo en un soporte magnético.

Tenemos dos tipos de técnicas:

basada en ficheros: es la clásica, basada en Bases de Datos.

Atendiendo a estas fases de abstracción, tendremos tres niveles:

1.3.- Sistemas de información tradicionales. Sistemas de Ficheros.


https://sites.google.com/site/adai6jfm/home/introduccin-a-las-bases-de-datos-concepto/fase3.png?attredirects=0


Los SI tradicionales se organizaban bajo la técnica de sistemas de ficheros y surgieron al tratar de informatizar el manejo de los archivadores manuales con objeto de proporcionar un acceso más eficiente a los datos.

Un sistema de ficheros es un conjunto de programas que prestan servicio a los usuarios finales. Cada programa define y maneja sus propios datos.

Generalmente, la manera de trabajar con un sistema de ficheros no fue establecer un sistema centralizado en donde almacenar todos los datos de la organización o empresa, sino que para ello se escogió un modelo descentralizado en el que cada sección o departamento almacena y gestiona sus propios datos.

Podemos clasificar los ficheros en función de la forma de organizarse.

Organización de ficheros: Operaciones realizadas sobre ficheros:

- Secuencial. - Inserción.

- Directo. - Recuperación.

- Indexados. - Actualización.

- Inversos. - Borrado

1.3.1.- Características de los SI usando ficheros.

Para cada tipo de usuarios se desarrollan aplicaciones independientes. Aparece un conjunto de programas que actúan sobre ficheros de datos.

Redundancia: datos comunes que son almacenados dos o más veces. Parte de la información suele estar replicada en diferentes ficheros.

Las aplicaciones que estamos desarrollando tienen una dependencia total de los datos, pues el formato de almacenamiento de los datos


https://sites.google.com/site/adai6jfm/home/introduccin-a-las-bases-de-datos-concepto/fig2.png?attredirects=0


puede ser diferente en cada fichero, dependiendo de la estructura física de esos ficheros.

La estructura de los datos, el modo de acceso a los datos en función del tipo de fichero donde se almacenan y su localización física, forman parte de nuestro programa.

Se pueden crear y modificar sin necesidad de realizar una planificación global.

Los datos se suelen almacenar en cintas, es decir, secuencialmente, lo que aconseja el Procesamiento por Lotes (Batch Processing).

A simple vista parecen simples de manejar, lógicos y limpios, pero también presentan una serie de problemas asociados.

1.3.2.- Inconvenientes de los sistemas de ficheros.

Separación y aislamiento de los datos. Cuando los datos se separan en distintos ficheros, es más complicado acceder a ellos, ya que el programador de aplicaciones debe sincronizar el procesamiento de los distintos ficheros implicados para asegurar que se extraen los datos correctos.

Duplicación de datos. La redundancia de datos existente en los sistemas de ficheros hace que se desperdicie espacio de almacenamiento y lo que es más importante: puede llevar a que se pierda la consistencia de los datos. Se produce una inconsistencia cuando copias de los mismos datos no coinciden.

Dependencia de datos. Ya que la estructura física de los datos (la definición de los ficheros y de los registros) se encuentra codificada en los programas de aplicación, cualquier cambio en dicha estructura es difícil de realizar. El programador debe identificar todos los programas afectados por este cambio, modificarlos y volverlos a probar, lo que cuesta mucho tiempo y está sujeto a que se produzcan errores. A este problema, tan característico de los sistemas de ficheros, se le denomina también falta de independencia de datos lógica-física.

Formatos de ficheros incompatibles. Ya que la estructura de los ficheros se define en los programas de aplicación, es completamente dependiente del lenguaje de programación. La incompatibilidad entre ficheros generados por distintos lenguajes hace que los ficheros sean difíciles de procesar de modo conjunto.

Consultas fijas y proliferación de programas de aplicación. Desde el punto de vista de los usuarios finales, los sistemas de ficheros fueron un gran avance comparados a los sistemas manuales. A consecuencia de esto, creció la necesidad de realizar distintos tipos de consultas de datos. Sin embargo, los sistemas de ficheros son muy dependientes del programador de aplicaciones: cualquier consulta o informe que se quiera realizar debe ser programado por él. En algunas organizaciones se conformaron con fijar el tipo de consultas e informes, siendo imposible realizar otro tipo de consultas que no se hubieran tenido en cuenta a la hora de



escribir los programas de aplicación.

En otras organizaciones hubo una proliferación de programas de aplicación para resolver todo tipo de consultas, hasta el punto de desbordar al departamento de proceso de datos, que no daba abasto para validar, mantener y documentar dichos programas.

Insuficientes medidas de seguridad, sobre el control de la concurrencia, la recuperación ante posibles fallos y el control de autorización (no todos los usuarios pueden acceder a un sistema de información o a partes de él (Privacidad)).

2.- Bases de Datos y Sistema de Gestión de Bases de Datos.2.1.- Objetivo de las Bases de Datos.

El objetivo de las bases de datos es unificar toda la información del sistema para evitar las redundancias, sin perder por ello las diferentes visiones que poseen los usuarios de esta información, manteniendo una independencia de los datos respecto a las aplicaciones que los utilizan, almacenando datos de manera íntegra y proporcionando una privacidad de la información.

2.2.- Definición de Base de Datos.

Una base de datos es una colección de datos estructurados según un modelo, que refleja las relaciones y las restricciones en el mundo real. Estos datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben permanecer independientes de estas, y la definición y descripción que de ellos se posee debe ser única, estando almacenada junto con los mismos.

Los tratamientos que se realicen sobre los datos deberán garantizar la integridad y seguridad sobre dichos datos.

2.3.- Sistema de Gestión de Bases de Datos. (SGBD).

Un SGBD es una herramienta de software (conjunto de programas) que permite a los usuarios (analistas, programadores, administrador de la base de datos o no informáticos) definir, crear y mantener la base de datos, además de proporcionar acceso controlado a la misma.

Un SGBD se caracteriza por mantener una descripción actual de la base de datos, integrando toda la información del sistema para evitar redundancias y sin que se pierdan, por ello, las distintas perspectivas que de la BD tienen los usuarios (definición de vistas parciales).

Por tanto, el SGBD debe cumplir los siguientes objetivos, asegurar la:



Independencia de los datos, propiedad que asegura que los programas de aplicación sean independientes de los cambios realizados en datos que no usan o en detalles de representación física de los datos a los que acceden.

Integridad de los datos almacenados, realizando las validaciones necesarias cuando se realicen modificaciones en la base de datos.

No redundancia de los datos, eliminando así la inconsistencia de los mismos

Seguridad de los datos y privacidad. Podemos distinguir cuatro tipos de contextos para usar mecanismos de seguridad: seguridad contra accesos indebidos a los datos, seguridad contra accesos no autorizados a la BD, seguridad contra destrucción causada por el entorno (fuego, inundación, robo,...), seguridad contra fallos del propio sistema (fallos del hardware, del software,...).

Eficacia de acceso a los datos, en especial en el caso de consultas imprevistas

Para cumplir estos objetivos, los SGBD tienen una arquitectura estándar, la arquitectura de niveles del SGBD.

2.4.- Instancia y Esquema de la Base de Datos.

Las BD cambian a lo largo del tiempo según se añade y se suprime información. La colección de información almacenada en un determinado momento en el tiempo se llama instancia de la BD.

El diseño global de la BD se llama esquema de la BD, y se modifica muy raras veces.

El concepto de esquema se puede ver como una correspondencia a la definición de tipo en un lenguaje de programación, y el concepto del valor de una variable corresponderá al concepto de una instancia de un esquema de la BD.

Los sistemas de BD tienen varios esquemas, divididos de acuerdo a los niveles de abstracción de la Arquitectura ANSI/SPARC (esquema conceptual, lógico, físico y externo).

Arquitectura. Modelos de datos

3.- Arquitectura de un SGBD.3.1.- Arquitectura ANSI / SPARC.



Hay tres características importantes inherentes a los sistemas de bases de datos: la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos.

En 1977, el comité ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) propuso una arquitectura de tres niveles para los sistemas de bases de datos, que resulta muy útil a la hora de conseguir estas tres características.

El objetivo de esta arquitectura es buscar la independencia de los datos definiendo el esquema de la base de datos a tres niveles de abstracción distintos.

En cada uno de los niveles se genera un esquema de descripción del trabajo realizado:

Nivel interno o físico. Esquema interno o físico.

Es una descripción de la base datos en términos de su almacenamiento físico mediante un esquema interno. En él deben especificarse tres clases de aspectos distintos:

Estrategia de almacenamiento. Comprende la asignación de espacios de almacenamiento para el conjunto de los datos, las relaciones entre los distintos espacios de almacenamiento y la estrategia utilizada para ello, permitiendo optimizar tiempo y espacio en memoria secundaria.

Caminos de acceso. La especificación de claves primarias y secundarias, así como los índices y claves de ordenación.

Misceláneas. Técnicas de comprensión de datos, encriptación, optimización,...

Nivel conceptual. Esquema conceptual.

Se describe la estructura de toda la base de datos para un sistema de información o la parte de él a tratar mediante un esquema conceptual.

Este esquema oculta los detalles físicos de almacenamiento y se centra en la estructura organizacional de los datos obtenida al reunir los requerimientos de todos los usuarios, es decir, se centra en elementos lógicos paradescribir entidades, atributos, relaciones, operaciones de los usuarios y restricciones con independencia del SGBD y de la máquina. (Esquema global).

En este nivel se puede utilizar un modelo conceptual o un modelo lógico para especificar el esquema.



Nivel externo. Esquemas externos.

Es el nivel más cercano al usuario y representa la percepción individual que cada usuario o grupo de usuarios tiene de la base de datos, es decir, de las diversas vistas parciales de la base de datos que tienen los distintos usuarios y, por tanto, en él deberán encontrarse reflejados sólo aquellos datos e interrelaciones que se necesiten.

También habrán de especificase las restricciones de uso, como puede ser el derecho a insertar o a borrar determinados datos o el acceso a los mismos, etc.

Por tanto, se definirán tantos esquemas externos como exijan las diferentes aplicaciones, y varios usuarios podrán compartir un mismo esquema externo.

Para una BD habrá un único esquema interno, un único esquema conceptual, pero puede haber varios esquemas externos.

Pero en el esquema conceptual surge un problema: se supone que existe un modelo conceptual que debe ser entendido por todos los SGBD, pero esto es incorrecto. Como variante a esta arquitectura aparece un cuarto nivel, resultado de dividir el nivel conceptual en dos niveles distintos, nivel conceptual y nivel lógico o canónico.

Nivel lógico. Esquema lógico.

Es una descripción de la representación de la BD en el esquema conceptual (entidades, relaciones y restricciones,…) teniendo en cuenta las características del SGBD concreto que se vaya a usar.

La inclusión de este cuarto nivel de representación del dominio del problema, un nivel dependiente del SGBD, va a garantizar la independencia de la información en una base de datos.

3.2.- Independencia de los datos en SGBD.

Un SGBD que soporte la arquitectura de niveles debe:

Permitir definir los distintos esquemas a excepción del conceptual.


https://sites.google.com/site/adai6jfm/home/arquitectura-modelos-de-datos/fig3.png?attredirects=0


Para describir éste último utilizaremos el método Entidad/Relación (Entidad/Interrelación).

Establecer las correspondencias entre los diferentes esquemas. Aislar los esquemas de forma que sean lo más independientemente

posibles. Los cambios en un esquema no deben afectar a los esquemas de nivel superior y por tanto, tampoco a los programas de aplicación.

Cumpliendo estas obligaciones, el SGBD prevé la independencia de los datos.

Existen dos niveles de independencia de los datos:

Independencia Lógica entre el esquema lógico y los externos.

Los esquemas externos y los programas de aplicación que se utilicen no deben verse afectados por las modificaciones que se efectúen en el esquema lógico sobre datos que no usen.

Independencia Física entre el esquema físico y el lógico.

El esquema lógico no debe verse afectado por cambios en el esquema físico referentes a la implementación de las estructuras de datos, modos de acceso, tamaños de páginas, caminos de acceso, etc.

4.- Funciones de un SGBD.

Hay que tener en cuenta que en una base de datos existe una gran variedad de usuarios con necesidades diversas, susceptibles de trabajar simultáneamente con subconjuntos de esta colección de datos y cuyas necesidades varían a lo largo del tiempo. Por tanto se pone de manifiesto que es imprescindible dotar al sistema de la adecuada flexibilidad que pueda




atender las exigencias de todos los usuarios y para que sea capaz de responder a los cambios a un coste no excesivo. Es decir, el SGBD se ha creado de forma que las ventajas que se han señalado como propias de las bases de datos sean una realidad.

Así, un SGBD proporciona a los usuarios de la base de datos los medios necesarios para realizar las siguientes tareas:

Definición de los datos a los distintos niveles de abstracción (físco, lógico y externo).

Manipulación de los datos en la base de datos. Mantenimiento de la integridad de la base de datos. Integridad en

cuanto a los datos en sí, sus valores y las relaciones entre ellos. Control de la privacidad y seguridad de los datos en la base de datos. Los medios necesarios para el establecimiento de todas aquellas

características exigibles en una base de datos.

5.- Lenguajes de los SGBD.

Las distintas funciones que ha de cumplir un SGBD hacen necesario disponer de diferentes lenguajes y procedimientos que permitan la comunicación con la base de datos; unos están orientados hacia la función (definición, manipulación o control) y otros dirigidos a diferentes tipos de usuarios o procesos.

Atendiendo a la función realizada, podemos clasificar los lenguajes de la siguiente forma:

Lenguaje de Definición de Datos (LDD) – Data Definition Language (DDL).

Lenguaje de Manipulación de Datos (LMD) – Data Manipulation Language (DML).

Lenguaje de Control de Datos (LCD) – Data Control Language (DCL)

5.1.- Lenguaje de definición de datos (DDL).

Permiten la definición de datos a tres niveles: esquema lógico, físico y externo.

El primer paso consiste en especificar el esquema lógico y el esquema interno de la base de datos, y lacorrespondencia entre ambos, de forma que se mantenga el enlace entre estas dos definiciones.

El SGBD posee un compilador de DDL (ver figura 5) cuya función consiste en procesar las sentencias del lenguaje para identificar las descripciones de los distintos elementos de los esquemas y almacenar la descripción del esquema



en el catálogo o diccionario de datos.

Un diccionario de datos es un archivo que contiene metadatos, es decir, datos (información) sobre datos o la descripción de los objetos de la base de datos. Este archivo se consulta antes de leer o modificar los datos reales de la BD.

5.2.- Lenguaje de manipulación de datos (DML).

Estos lenguajes permiten la inserción, modificación, recuperación y supresión de los datos almacenados en la base de datos.

El SGBD deberá tener los módulos que traducen estos lenguajes, tanto al nivel de definición como de manipulación.

Dentro de los DML podemos clasificarlos por diferentes criterios:

Por su definición:o Autosuficientes: los que se pueden ejecutar por ellos mismos,

pudiéndose realizar programas completos.o Huéspedes: deben incluir sus instrucciones en un lenguaje de

alto nivel. Por su funcionalidad frente al usuario:

o Procedimentales: requieren que el usuario especifique qué datos se necesitan y cómo conseguirlos.

o No procedimentales: el usuario debe especificar qué datos se necesitan, pero no cómo obtenerlos.

En muchos SGBD se pueden introducir interactivamente instrucciones del LMD desde un terminal o bien embeberlas en un lenguaje de programación de alto nivel. Los DML no procedimentales permiten especificar los datos a obtener en una consulta o los datos que se deben actualizar, mediante una sola y sencilla sentencia. El usuario o programador especifica qué datos quiere obtener sin decir cómo se debe acceder a ellos. El SGBD traduce las sentencias del DML en uno o varios procedimientos que manipulan los conjuntos de registros necesarios. Esto libera al usuario de tener que conocer cuál es la estructura física de los datos y qué algoritmos se deben utilizar para acceder a ellos. A los DML no procedurales también se les denomina declarativos. Las bases de datos relacionales utilizan DML no procedurales, como SQL (Structured Query Language) o QBE (Query-By-Example).

5.3.- Lenguaje de Control de Datos y/o Auxiliares (DCL).

El DCL permite el control de acceso a la información almacenada en el diccionario de datos definiendo privilegios y tipos de acceso, así como el control de la seguridad de los datos.



También puede incluir módulos para la reconstrucción de la base de datos, de simulación o de estadísticas entre otros.

6.- Estructura general del SGBD.

Como ya se ha comentado, un SGBD se divide en módulos que tratan cada una de las responsabilidades del sistema general. En la mayoría de los casos, el sistema operativo proporciona únicamente los servicios básicos, y el sistema debe partir de esa base. Así, el diseño de un SGBD debe incluir la consideración del interfaz entre la BD y el sistema operativo.

Los componentes funcionales de un SGBD incluyen:

Gestor de ficheros. Se encarga de las estructuras de datos que se emplean para representar la información almacenada en disco. Además es el encargado de asignar espacio en disco.

Gestor de BD. Es el interface entre los datos de bajo nivel almacenados en la BD y los programas de aplicaciones y consultas de datos.

Procesador de consultas. Traduce las proposiciones del lenguaje de consultas (DML – Lenguaje de Manipulación de Datos) a instrucciones de bajo nivel para que las entienda el gestor de BD. Además el procesador de consultas trata de traducir una petición del usuario a otra equivalente pero más eficiente.

Compilador DDL. Convierte las proposiciones DDL (Lenguaje de Definición de Datos) en un conjunto de tablas que contienen metadatos.

Ficheros de datos. Almacenan la información (los datos). Diccionario de datos. Almacena información referida a la estructura




de la BD. Se usa continuamente. Se debe poner un gran énfasis en un buen diseño y una implementación adecuada del diccionario de datos.

6.1.- Gestor de Bases de Datos.

Generalmente, las BD requieren una gran cantidad de espacio de almacenamiento, que se miden en gigabytes. Puesto que la memoria principal no puede almacenar toda esa información, se almacena en discos. Ya que el movimiento de los datos y el disco son lentos comparados con la CPU (Unidad Central de Proceso), es imperativo que el SGBD estructure los datos de forma que minimice la necesidad de mover los datos entre el disco y la memoria.

El objetivo de un SGBD es simplificar y facilitar el acceso a los datos. Las vistas de alto nivel ayudan a lograrlo. Un factor para la satisfacción o insatisfacción de un usuario con el SGBD es su funcionamiento. El funcionamiento de un sistema depende de la eficiencia de las estructuras de datos usadas para representar los datos y de la capacidad de eficiencia de operar sobre estas estructuras que el sistema tiene. Se debe llegar a un compromiso entre espacio, tiempo y eficiencia.

Un gestor de BD es un módulo de programas que proporciona el interfaz entre los datos de bajo nivel almacenados y los programas de aplicación y consultas, y es responsable de las siguientes tareas:

1. Interacción con el gestor de archivos. El gestor de la BD traduce las distintas sentencias DML a comandos del sistema de archivos a bajo nivel. Así, es responsable del verdadero almacenamiento de los datos.

2. Implantación de la integridad. Los valores de los datos que se almacenan deben satisfacer ciertos tipos de restricciones de consistencia, que debe especificar explícitamente el administrador de la BD. El gestor de la BD entonces puede determinar si se produce una violación de la restricción, si es así, se debe tomar la acción apropiada.

3. Implantación de la seguridad. Es trabajo del gestor de la BD debe hacer que se cumplan los requisitos de seguridad.

4. Copia de seguridad y recuperación. Un sistema informático, como cualquier otro dispositivo, está sujeto a fallos. Es responsabilidad del gestor de BD detectar fallos y recuperar la BD al estado que existía antes de ocurrir el fallo. Esto se lleva a cabo normalmente con procedimientos de copias de seguridad y recuperación.

5. Control de concurrencia. Cuando varios usuarios actualizan la



BD de forma concurrente, es posible que no se conserve la consistencia de los datos. Controlar la interacción entre los usuarios concurrentes es otra responsabilidad del gestor de BD.

Los SGBD diseñados para ordenadores personales y/o pequeños negocios u organizaciones pueden no tener todas las características apuntadas.

6.2.- Esquema general de acceso del SGBD a los datos.

Cuando una aplicación (programa de usuario) desea acceder a los datos, este acceso será diferente si lo realiza sobre un fichero o sobre una base de datos.

Cuando se accede a un fichero, el programa de aplicación, escrito en un lenguaje de programación, lo hace por medio del sistema de gestión de ficheros del sistema operativo que contiene los métodos de acceso; mientras que cuando se trata de una base de datos, el programa de aplicación se dirige al SGBD, el cual accede a la base de datos a través del sistema operativo.

El funcionamiento que se desencadena al realizarse una comunicación del usuario con el SGBD se puede dividir en tres pasos:

1. Requerir información: petición, acceso o activación por parte de las aplicaciones.

2. SGBD: traducción de la petición (descomponer el programa) en rutinas del SO. Debe conocer la descripción de los datos (nivel superior), y las rutinas del SO.

3. El SO recibe las operaciones (rutinas) y se encarga de acceder a disco.

6.3.- Interacción del SGBD con el SO y las aplicaciones (programas de usuarios).



Área de trabajo: zona de memoria para el intercambio de información entre la base de datos y la aplicación.

Estado: variable local para saber cuál es el último estado después de que la aplicación haya realizado una operación.

Ejemplo: desde que el programa de aplicación (A) pide información hasta que llega a su poder.

(1) El programa de aplicación (A) realiza una cierta petición de datos al





SGBD.

(2) Consulta (recuperar) sobre las estructuras de datos del esquema externo (A), utilizado por la aplicación (A).

(3) Consultar el esquema lógico para establecer la correspondencia entre los datos del esquema externo (A) y el esquema lógico, y realizar las conversiones necesarias entre los dos esquemas para realizar la petición de datos sobre el esquema lógico.

(4) Consultar el esquema físico para saber dónde se encuentra los datos y como se debe convertir la operación de petición en rutinas del sistema operativo.

(5) Lanzar las ordenes (rutinas) correspondientes al SO.

(6) El SO accede a la información. Hasta aquí se da la interacción del SGBD con el SO.

(7) La información ya localizada se transmite de la memoria externa a los buffers de comunicación.

(8) y (9) El SGBD toma la información de los buffers y la arregla para ser compatible con el esquema externo, transmitiéndola al área de trabajo.

(10) El SGBD le comunica al programa el resultado de su consulta. Actualiza el estado de la operación que pidió el programa. Después devuelve el control al Programa A.

Además un SGBD debe cumplir los siguientes objetivos:

- Privacidad.

- Integridad, (seguridad).

- Recoger información para una posible reconstrucción de la BD.

El funcionamiento del SGBD está muy interrelacionado con el sistema operativo.

7.- Usuarios del SGBD.7.1.- Administrador de la base de datos.

Una de las razones principales para tener un SGBD es tener el control central



de los datos y de los programas que acceden a los datos. La persona que tiene dicho control central sobre el sistema se llama Administrador de la Base de Datos (DBA, database administrator).

Las funciones del DBA son:

1. Definición de esquemas. El esquema original de la BD se crea escribiendo un conjunto de definiciones que son traducidas por el compilador de DDL a un conjunto de tablas, almacenadas permanentemente en el diccionario de datos.

2. Definición de la estructura de almacenamiento y del método de acceso. Se crean escribiendo un conjunto de definiciones traducidas por el compilador del lenguaje de almacenamiento y definición de datos.

3. Modificación del esquema y de la organización física. Estas modificaciones son poco comunes, pero se logran escribiendo un conjunto de definiciones usadas por el compilador de DDL para generar modificaciones a las tablas internas apropiadas.

4. Concesión de autorizaciones para el acceso a los datos. Esto permite al DBA regular que partes de la BD van a poder ser accedidas por varios usuarios.

5. Especificación de las restricciones de integridad. Estas se mantienen en una estructura especial del sistema que consulta el SGBD cada vez que tiene lugar una actualización.

7.2.- Otros usuarios de la BD.

Un objetivo principal de un SGBD es proporcionar un entorno para recuperar y almacenar información en la BD. En función de este objetivo podemos clasificar los usuarios en cuatro tipos, según la forma que tienen de interaccionar con el sistema.

1. Programadores de aplicaciones. Los profesionales en computación interactúan con el sistema por medio de llamadas en DML, incorporadas en un programa escrito en un lenguaje principal (como Pascal o C, Java, PHP o ASP, etc.). Estos programas se denominan comúnmente programas de aplicación.

2. Usuarios sofisticados. Interaccionan con el sistema sin escribir programas, en cambio escriben sus preguntas en un lenguaje de consultas. Cada consulta se somete a un procesador de consultas, cuya función es tomar una sentencia en DML y descomponerla en instrucciones que entienda el gestor de la BD.



3. Usuarios especializados. Algunos usuarios sofisticados escriben aplicaciones de BD especializadas que no encajan en el marco tradicional de procesamiento de datos, como sistemas basados en el conocimiento, etc.

4. Usuarios ingenuos. Los usuarios no sofisticados interactúan con el sistema invocando a uno de los programas de aplicación permanentes que se haya escrito anteriormente.

8.- Integridad.

La integridad hace referencia a la calidad de la información:

“los datos deben estar estructurados reflejando adecuadamente los objetos, relaciones y restricciones existentes en la parcela del mundo real que modela la base de datos”

Calidad en el aspecto de que el SGBD debe asegurar:

- La información de los datos se almacene de forma correcta.

- Los datos estén debidamente interrelacionados.

- Las ocurrencias de los datos deben ser accesibles de las formas correctas.

- El control de los accesos concurrentes. Las actualizaciones de los usuarios sobre la base de datos debe ejecutarse correctamente y de forma permanente.

Existen dos tipos de técnicas para mantener la integridad: preventivas y curativas.

8.1.- Técnicas Preventivas.

El SGBD proporciona herramientas para prevenir la llegada a un estado incorrecto. Tenemos varios tipos:

Verificación: Se comprueba que las actualizaciones sobre la BD no conducen a un estado no integro, es decir, que no viole las restricciones de integridad definidas en el esquema de la BD.



Control de accesos concurrentes: intentan evitar que los resultados de la ejecución de un programa sean incorrectos, incoherentes o se pierdan debido a la ejecución concurrente de otro programa que accede a los mismos datos.

Tipos de errores que se producen por accesos concurrentes mal resueltos:

Perdidas de actualizaciones. Obtención de datos incoherentes debido a datos validos de la B.D. Lectura de datos no confirmados.

Todos estos problemas de concurrencia deben ser resueltos por el SGBD utilizando la reserva de datos, es decir, cuando un programa va a hacer uso de los datos, los bloquea para que ningún otro programa los pueda emplear.

La reserva de datos se realiza a nivel de Granulo. El Granulo es elemento atómico (dato más elemental). Cuanto mayor es el gránulo menor es la concurrencia. (Ej. un fichero, una página de un fichero,).

La ejecución de un programa se realiza divida en transacciones.

Una transacción es un conjunto de operaciones elementales, ya sean de lectura y/o actualización de la BD La transacción o tiene éxito, es decir, realiza todo el conjunto de las operaciones, o sino no se hace ninguna. El conjunto de operaciones del programa se agrupan en un conjunto de transacciones.

Cuando se va a realizar una transacción se reservan los datos que se van a utilizar; las modificaciones se acaban cuando termina la transacción.

En todo SGBD existe un módulo que se preocupa de la concurrencia exclusivamente. Evita los abrazos mortales en las transacciones, mirando si hay ciclos en la reserva de gránulos.

Control de la redundancia: existe un módulo que se encarga de que todo lo que sea redundante sea consistente.

8.2.- Técnicas Curativas.

Se encargan de reconstruir los estados incorrectos debidos a:

Fallos físicos. Interrupciones de programas de modificación.



Las actualizaciones realizadas por parte del usuario sean erróneas.

Frente a los estados incorrectos hay distintos tipos de reconstrucción:

Total: se reconstruyen totalmente, teniendo una copia íntegra. Parcial: se realiza a base de repetir transacciones que han sido

incorrectas.

Las herramientas utilizadas para la reconstrucción son: Copias de seguridad (backup): en el momento de realizar la copia no

debe de estar realizándose ninguna transacción. Fichero dietario: es un fichero en el cual se guarda la información que

permite deshacer o rehacer transacciones efectuadas en un preciso intervalo de tiempo. Cuando una transacción se confirma se apunta en el dietario.

9.- SEGURIDAD.9.1.- Objetivo.

Asegurar que a la información almacenada en la BD sólo pueden acceder las personas autorizadas y en la forma en la cual están autorizadas.

9.2.- Técnicas.

1) Permitir la identificación al usuario.

2) Determinación de los tipos de accesos y operaciones permitidos, es decir, a donde puede acceder y que puede hacer cada usuario. Se pueden determinar de dos formas:

a. Con niveles de actualización.

b. A base de mantener una lista de operaciones junto con los objetos sobre los cuales puede realizar esas operaciones el usuario. (Mejor opción).

3) Efectuar una gestión de autorización transferida. El gestor debe comprobar y permitir:

a. Que las autorizaciones que son transferidas de un usuario a otro permitan a este último transferirlas también.

b. Cualquier autorización transferida se debe poder revocar posteriormente.

c. Debe cumplir la anulación de autorizaciones en cascada.



TÉCNICAS DE ESPECIFICACIÓN DE CONTROL

Análisis orientado a los datos

1.- INTRODUCCIÓN AL MODELO DE DATOS.

1.1.- Concepto de Modelo de datos.

Cuando se estudiaron los Sistemas de Información, se vio que el objetivo era representar por medio de la abstracción un subconjunto del mundo real en el cual estamos interesados, y almacenar toda la información necesaria para el buen funcionamiento del SI.

Podemos realizar la abstracción de forma artística o utilizando un método.

Un SI tiene ciertas propiedades estática y dinámicas.

- Estáticas: son propiedades invariantes en el tiempo. Un SI está formado por diferentes tipos de objetos, propiedades de cada objeto, relación de objetos entre sí y restricciones de integridad sobre los objetos.

- Dinámicas (como va a evolucionar el S.I.). Son operaciones que sufren los objetos, propiedades de dichas operaciones, agrupaciones de operaciones (como se agrupan) y restricciones de integridad sobre operaciones.

Un Modelo de datos es una herramienta conceptual que nos permite modelizar (estructurar) la información capturando toda la semántica posible asociada a dicha información, es decir, nos permite representar las propiedades estáticas y dinámicas de un sistema de información.

Un esquema del SI es la descripción de las estructuras de datos y de los procesos del SI en términos de un cierto modelo de datos.

- Esquema de la base de datos: descripción de las propiedades estáticas en términos de ese modelo de datos.

- Especificaciones de transacción: descripción de las propiedades dinámicas en ese modelo de datos.

Una Base de Datos (BD) es una colección de datos estructurada según un cierto esquema de la BD.

A nosotros nos interesa el estudio de las propiedades estáticas de un SI.



Fases del sistema de información : Bases de Datos:

1. Análisis:2. Recogida de

requerimientos.3. Modelización.

Formalización de las estructuras de datos.

4. Diseño. Estructurar la información teniendo en cuenta el S.G.B.D. que se posee.

5. Implementación. Organizar la información físicamente en la máquina a usar.

Modelo Conceptual.

Diseño Lógico.

(S.G.B.D.) Diseño Físico.

Obtenemos un subconjunto del mundo real.

1.2.- Fases del Modelo de Datos.

Atendiendo a las propiedades estáticas de un SI, podemos definir el modelo de datos como un conjunto de herramientas conceptuales para describir los datos que interesan almacenar en una aplicación, sus relaciones, su semántica y sus limitaciones o reglas.

En el Modelo de Datos se distinguen tres fases:

Modelo Conceptual, cuyo objetivo es representar la información de forma comprensible a los usuarios e independientemente del software y hardware disponible, en particular del Sistema de Gestión de Bases de Datos (SGBD) específico que se vaya a utilizar. Para la obtención de este modelo usaremos el modeloentidad/relación o entidad/asociación propuesto por Peter Chen.

Diseño Lógico, transforma el modelo anterior (entidades, relaciones y restricciones) teniendo en cuenta las características del SGDB concreto que vayamos a utilizar en nuestra aplicación El modelo inicial sufrirá una serie de refinamientos hasta llegar a estructuras de datos lo más independientes posibles aplicando técnicas de normalización. Los modelos utilizados para el diseño lógico son:

Modelo Relacional.

Modelo Jerárquico.


https://sites.google.com/site/adai6jfm/home/anlisis-orientado-a-los-datos/flechas.png?attredirects=0




Modelo en Red.

Diseño Físico, con el cual se pretende obtener un modelo de base de datos adaptado a nuestro gestor particular con el fin de obtener las estructuras de almacenamiento en soportes físicos.

El modelo de datos, una vez diseñado, deberá conseguir:

- Obtener toda la información que el sistema necesita obtener para sus fines.

- Representar la información mediante una serie de conceptos básicos que contengan su significado.

- Independizar los datos de los recursos físicos así como de los requerimientos de los usuarios.

- Proporcionar a los usuarios del sistema la información tal y como la necesitan.

2.- MODELO ENTIDAD – INTERRELACIÓN.

(MODELO CONCEPTUAL).

2.1.- Concepto de Modelo Entidad-Interrelación.

El modelo Entidad-Interrelación (E-R) fue propuesto por Peter Chen en 1976 para la definición del esquema Conceptual de una BD. Posteriormente se ha ido enriqueciendo con nuevos mecanismos de abstracción y representación de la realidad. Este modelo es el más ampliamente utilizado de los llamados semánticos.

Es una técnica de representación gráfica que incorpora información relativa de los datos y la relación existente entre ellos con el fin de darnos una visión de la información que se maneja en el mundo real.

Los principales elementos de este modelo son las entidades (objetos), las relaciones entre entidades, losatributos pertenecientes tanto a entidades como a relaciones y las restricciones.

El modelo E-R sólo permiten describir las propiedades estáticas del S.I.

¿Para qué definir un modelo orientado a datos?

Es necesario definir un modelo orientado a datos por:

- El sistema puede ser tan complicado que sea conveniente estudiar sus estructuras de datos independientemente del proceso que se llevará a cabo.

- El modelo de datos es esencial para comunicarse con el



administrador de datos, que es el responsable de gestionar, controlar los datos esenciales para administrar el negocio, asegurar el correcto y eficiente funcionamiento de las BD’s del sistema.

- El modelo de datos define las relaciones entre los almacenamientos de los DFD’s.

2.2.- Representación de ENTIDADES.

Una entidad es cualquier concepto o suceso, persona, lugar o cosa, es decir, cualquier objeto del mundo real tangible o intangible, y distinguible del resto de objetos, sobre la cual deseamos almacenar información.

Ejemplo: cliente, empleado, pieza, libro, factura, planificación,...

Ocurrencia de entidad: es cada uno de los miembros individuales de una entidad; cada uno de los conjuntos valores que puede tomar.

Ejemplo: de la entidad Cliente tendríamos las siguientes ocurrencias:

18.456.321 - José Ramírez Blasco - Alcañiz - 978662132

18.452.125 - Estrella Sánchez López - Calanda - 978674121

Una entidad debe cumplir las siguientes características:

Cada una de sus ocurrencias puede ser identificada unívocamente. Existe alguna manera de diferenciar dos ocurrencias individuales de la entidad.

Cada entidad juega una función dentro del sistema, El sistema no funciona sin acceder a sus miembros instancias.

Cada entidad puede ser descrita por uno o más elementos (atributos). Los atributos se aplican a cada ocurrencia de la entidad.

Las entidades se representan mediante un rectángulo nominado. Para ponerles un nombre, normalmente se utiliza un sustantivo en singular.

CLIENTE



Hay que tener en cuenta la relación entre los almacenes del DFD y las entidades del diagrama de Entidad-Relación (DER). Si existe una entidad “artículo” en un DER, debe haber un almacén de datos “artículos” en el DFD asociado.

2.3.- Representación de ATRIBUTOS.

Los atributos son cada una de las propiedades o características que tiene una entidad o una relación.

Ejemplo: Los atributos de la entidad Cliente podrían ser DNI, nombre, población, teléfono,...

Un atributo se representa en un DER como una elipse unida a una entidad mediante un arco. Cada atributo se define por su nombre. Dentro de una misma entidad o relación dicho nombre debe ser único.

En función de los distintos tipos de atributos que nos podamos encontrar, variará el tipo de representación:

Atributo identificador, son aquellos que identifican las ocurrencias de la entidad. Se representan mediante el subrayado del nombre del atributo.

Atributo descriptor, son los atributos no identificadores.

Si atendemos a la posible estructura de los atributos, tenemos:

Atributo simple o escalar. Atributo compuesto o estructurado: el nombre del atributo compuesto es

la etiqueta de un arco que se subdividirá en tantos atributos simples como forme la estructura.


https://sites.google.com/site/adai6jfm/home/anlisis-orientado-a-los-datos/fig01.png?attredirects=0



Atributo multivaluado, se indica mediante la etiqueta n sobre el arco.

2.4.- Representación de RELACIONES.

Las relaciones entre entidades se representan mediante un polígono de tantos lados como entidades se asocian, salvo en el caso de las binarias (relaciones que asocian dos entidades o una consigo misma) que utilizan un rombo, unido a las entidades mediante arcos. Este polígono irá etiquetado con el nombre de la relación. Asimismo, se pueden etiquetar los arcos para realzar el papel que juega dicho objeto dentro de la relación.

Una relación es la asociación o correspondencia entre entidades. No tienen existencia propia.

Una ocurrencia de relación no es distinguible por sí misma, sino a través de la designación de las ocurrencias de las entidades asociadas.

Cada instancia de la relación representa una asociación entre 0 ó más ocurrencias de una entidad y 0 ó más ocurrencias de otra entidad. Por ejemplo:

- Instancia 1: cliente 1 compra artículo 1.- Instancia 2: cliente 2 compra artículo 2 y 3.- Instancia 3: cliente 3 y 4 compran artículo 4.






- Instancia 1: cliente 5 no compra ningún artículo.

Nos podemos encontrar múltiples relaciones entre dos o más entidades, y debemos interpretarlo como una unidad. La relación se debe estudiar desde la perspectiva de cada una de las entidades participantes. Es el conjunto de todas aquellas perspectivas las que describen completamente a la relación.

Las entidades que pueden ser calculada o derivadas a partir de otros datos, no se representan.

Grado de una relación.

Es el número de entidades que forman parte de la relación.

Atendiendo al grado de la relación podemos distinguir los siguientes tipos de relaciones:

Grado 1: Relaciones reflexivas, asocia a un tipo entidad consigo misma.

Grado 2: Relaciones binarias, asocian a dos tipos de entidades.

Grado 3: Relaciones ternarias, asocian a tres entidades distintas.





2.5.- Representación de RESTRICCIONES.

Vamos a clasificar las restricciones sobre los objetos del diagrama de E-R (entidades, atributos y relaciones).

2.5.1.- Restricciones sobre ATRIBUTOS.

Sólo se pueden definir restricciones de valor asociando un dominio a los atributos. Se indicara colocando al lado del atributo el dominio sobre el que se define el mismo.

Dominio: Se denomina al conjunto de posibles valores que puede tomar una cierta característica o propiedad. Los atributos toman valores de un dominio por lo que podemos decir que el atributo le da una determinada interpretación al contexto de una entidad o una relación.

Conceptualmente los dominios pueden ser:

- Continuos. Formado por todos los valores comprendidos entre un máximo y un mínimo. Ejemplos: DNI, salario,...

- Discretos: Aquellos que contienen unos valores determinados dentro de un conjunto discreto de valores. Ejemplos: fecha, texto,....

Si un atributo no puede tomar valores nulos lo representaremos como:

2.5.2.- Restricciones sobre ENTIDADES.

Restricción de clave: toda entidad debe tener su conjunto de atributos identificador (uno o varios).






2.5.3.- Restricciones sobre RELACIONES.

Cardinalidad de una entidad:

Mide el mínimo y el máximo de ocurrencias de una entidad que pueden intervenir en una ocurrencia de una u otras entidades que participan en la relación.

2.5.3.1.- Restricciones de cardinalidad máxima.

Conectividad o tipo de correspondencia: es la cardinalidad máxima de una entidad que toma parte de una relación, es decir, representa la participación máxima de ocurrencias en la relación de cada una de las entidades afectadas. Tiene dos valores, “1” o “muchos”.

Las restricciones de cardinalidad máxima (conectividad) se expresan mediante el rallado de la parte del polígono que indica la asociación de una de las entidades (en relaciones binarias, la mitad del rombo). Dependiendo del número de entidades asociadas la cardinalidad máxima implica una lectura u otra.

Suponiendo dos entidades A y B asociadas por una relación R, definiremos las restricciones de cardinalidad mínima (m) y máxima (M) como:

R ( A(mA, MA), B(mB, MB) )

Sólo nos vamos a fijar en las relaciones binarias, dándose los siguientes casos:

Uno a uno, 1:1. A cada ocurrencia de una entidad le corresponde



como máximo una ocurrencia de la otra y viceversa.

R ( A(0, 1), B(0, 1) ) Uno a muchos, 1:M (1:N). A cada ocurrencia de la primera entidad le

corresponden varias ocurrencias de la segunda, y a cada ocurrencia de la segunda le corresponde una y solamente una de la primera.

R ( A(0, 1), B(0, ) ) Muchos a muchos, M:M (N:N). A cada ocurrencia de la primera entidad

le corresponden varias ocurrencias de la segunda y viceversa.

Las relaciones 1:M no pueden llevar atributos.

R ( A(0, ), B(0, ) )

Ejemplos de conectividad:

1:1 1:M M:M

Conect(PEDIDO) = 1 Conect(CLIENTE) = 1 Conect(PROV) = M

Conect(FACTURA) = 1 Conect(CUENTA) = M Conect(PROD) = M

2.5.3.2.- Restricciones de cardinalidad mínima.

- Restricción de existencia.

Es la cardinalidad mínima en la que una entidad toma parte en una relación.

Dada una entidad A que forma parte de una relación R, sufre restricción de existencia si toda ocurrencia de la entidad E debe estar asociada en la relación




R.

Para representar esta restricción utilizaremos un doble rectángulo para la entidad que sufre esta restricción, y etiquetaremos el arco de la relación con una “E”.

Pertenecer ( DEPART(1, 1), EMPLE (0, ) )

Restricción de identificación o de dependencia de identificador.

Aquellas entidades que no se puedan identificar por sí mismas, es decir, que necesitan de los atributos identificadores de otra entidad para reconocer cada ocurrencia de su entidad, se dice que sufren dependencia de identificador.

Cuando una entidad sufre una restricción de identificación se dice que es débil, en contraposición a la entidad que presta sus identificadores, que se considera fuerte. La entidad débil hereda la clave de la otra entidad para formar la clave con la suya propia.

Cualquier entidad que sufre la restricción de identificación también sufre la restricción de existencia.




2.6.- EJEMPLO DE ENTIDAD-RELACIÓN.

Mostraremos a continuación el diagrama E-R para un Sistema de Información sobre la gestión de pedidos a proveedores de una empresa genérica.

El ejemplo pretende reflejar la política de compras de una empresa de distribución. Se compran ciertas mercancías a los distintos proveedores y son vendidas posteriormente al público o a otros distribuidores.

Básicamente, las tareas que se pretenden mecanizar son las siguientes:

- Listas de precios de compra.

Conocer en todo momento los precios a los que venden en el momento actual los proveedores.

- Control de pedidos.

De aquellas mercancías que se solicitan a los proveedores, controlar si se han servido en el tiempo estimado y en la cantidad solicitada.

- Control de existencias.

Mediante la confección de un inventario, donde cada entrada, que corresponda a un único artículo, es el recuento real de existencias.




Lista de precios de compra a proveedores.

Tenemos almacenada la información de aquellos proveedores habituales de la empresa y de las piezas que entran y salen del almacén: son las entidades VENDEDOR y PIEZA, respectivamente.

Puesto que un mismo vendedor puede suministrar varias piezas, y una pieza puede ser ofertada por varios proveedores, nos interesa saber, para cada pieza, las condiciones que ofrecen unos y otros. La relación M:M entre las dos entidades mencionadas y que hemos denominado SUMINISTRA, contiene, además, los atributos que nos indican el precio actual al que se puede comprar, los días que tarda en ser servida la pieza, y el posible descuento ofrecido por el proveedor.

El siguiente ejemplo muestra una posible ocurrencia de la relación SUMINISTRA que asocia una ocurrencia de VENDEDOR, otra de pieza, y contiene los atributos particulares de la asociación.

Ocurrencia de VENDEDOR.

1 FEDERICO LOPEZ BASILIO

MECEMSA 978.665.214 Avda. Cáceres, 13

CALANDA TERUEL

Ocurrencia de PIEZA

DD-0001-210

DISCO DURO WESTERN DIG 6,2 Gb

25.000

Ocurrencia de SUMINISTRA




1 FEDERICO LOPEZ BASILIO

MECEMSA 978.665.214 Avda. Cáceres, 13

CALANDA TERUEL

DD-0001-210

DISCO DURO WESTERN DIG 6,2 Gb

25.000

15000 3 15

Se supone que almacenamos la información de las piezas que maneja la empresa y la de los vendedores que podrían suministrarlas. En la relación M:M SUMINISTRA se asocian efectivamente las piezas con los proveedores que las sirven, y el precio de la oferta de cada uno. Nótese que, por la conectividad de la relación, un mismo vendedor puede proveer de varias piezas a la empresa, y una misma pieza puede ser ofertada por varios vendedores a distintos precios.

La siguiente tabla, y prescindiendo de la mayor parte de los atributos que, como en el ejemplo anterior, formarían cada ocurrencia de suministra, ilustra cómo se relacionarían vendedores y piezas por suministro.

Control de pedidos.

La empresa decide en un momento dado solicitar a un proveedor que le suministre una serie de piezas. Se confecciona un pedido que se envía al vendedor que, posteriormente servirá tales mercancías. Toda esta operativa se refleja en dos nuevas entidades, PEDIDO y LINPED, y en tres relaciones, RECIBE, CONTIENE y SE_PIDE_EN.

Además, para controlar la recepción de, los pedidos, se almacena información sobre la fecha en que entran efectivamente las mercancías en el almacén, el precio al que se han comprado, y la diferencia entre la cantidad que se pidió y la que se recibió.

Debemos aclarar ciertos aspectos sobre las relaciones. En primer lugar, los precios de compra no tienen por qué coincidir con la lista de precios de SUMINISTRA. Se puede dar el caos de que este precio variara recientemente y que el pedido sea la fecha anterior, o simplemente que el proveedor ha hecho una oferta distinta de la que se conoce por SUMINISTRA.

Por último, los pedidos se estructuran mediante una cabecera, cuyos datos principales se almacenan en Pedido, y una serie de líneas de pedido que contienen, cada una, una referencia a una única pieza. Precisa de una restricción de dependencia de identificador puesto que, para todos los pedidos, las líneas se numeran desde 1 en adelante, con lo que el identificador numlinea no basta para diferenciar las tuplas de LINPED. Para ilustrar este punto, se muestra un ejemplo de cómo serían dos fichas de control de pedidos servidos por los proveedores



Numpedido numvend Fecha

1 1 19/01/2000

Numlinea numpieza preciocompra cantpedida Fecharecep

1 M-0001-C 30000 10 24/01/2000

2 P-0001-33 21000 20 24/01/2000

3 FD-0001-144 13500 20 24/01/2000

4 DD-OOO1-210

15000 20 24/01/2000

5 T-0002-AT 3100 20 01/02/2000

Numpedido numvend Fecha

2 1 25/01/2000

numlinea numpieza Preciocompra Cantpedida Fecharecep

1 DK144-002-P 545 100 29/01/2000

2 T-0002-AT 3000 1 29/01/2000Al igual que el ejemplo de SUMINISTRA, una ocurrencia de PEDIDO, no necesariamente, se asociará a una ocurrencia de VENDEDOR, y una de LINPED a una de PIEZA. Pero si obligatoriamente una ocurrencia de LINPED a una de PEDIDO (con todos los atributos de cada una).

CONTROL DE EXISTENCIAS.

Para controlar el nivel de existencias en nuestro almacén se ha optado (no tiene por qué ser la mejor alternativa) por una entidad INVENTARIO con una relación 1:1 con PIEZA, con restricción de existencia.

De cada pieza se mantiene el último recuento físico en el almacén, por si ha habido roturas o pérdidas que alteren la diferencia entre bienes que entran y salen. También se especifica cual es el nivel mínimo de existencias, que indica cual es el momento adecuado para realizar un nuevo pedido a proveedores.

Cada ocurrencia de la entidad se identifica por un número de inventario (numbin) y obligatoriamente estará asociada a una (distinta para cada entrada de inventario) de PIEZA.

2.7.- MODELO ENTIDAD INTERRELACIÓN EXTENDIDO (EE-R).

El modelo Entidad Interrelación Extendido surge de la actualización del Modelo E-R, permitiendo la representación de cualquier tipo de relaciones existentes



entre las clases de objetos que considera los principios de la abstracción.

2.7.1.- Relaciones Exclusivas.

Dos o más relaciones son exclusivas si cada ocurrencia de una entidad sólo puede pertenecer a una de las relaciones.

2.7.2.- Generalización/Especialización y Relaciones IS-A.

Generalización. Es el proceso de definir una entidad generalizada a partir de otras entidades. Especifica que varias entidades con ciertos atributos en común pueden generalizarse en una entidad a nivel superior, denominada supertipo o superclase.

Especialización. Es el proceso de definir un conjunto de subtipos o subclases a partir de una entidad más general.

La descomposición de entidades en varias subclases es una necesidad muy habitual en la modelización de bases de datos, ya que permiten identificar y representar jerarquías entre los tipos de entidad identificadoos en el problema del mundo real a estudiar.

La relación que se establece entre una superclase de entidad y sus subclses corresponde a la noción de <<ES-UN>> (conocida por sus siglas inglesas <<IS-A>>) o, más exactamente, <<ES-UN-TIPO-DE>>.

Las relaciones IS-A son implícitamente de cardinalidad 1:1 por lo que no se indica explícitamente.

Una característica muy importante de esta clase de relaciones es la herencia, ya que, en principio, todo atributo de la clase más general pasa a ser un atributo de las subclases.

En este tipo de abstracción los atributos comunes a todas las subclases se




asignan a la superclase, mientras que los atributos específicos se asocian a la subclase correspondiente; siendo la clase más general la única que disponga de identificadores. En resumen, toda subclase dispondrá de sus atributos propios (representados en el diagrama) más los atributos de la superclase incluyendo los atributos identificadores (no representados en el diagrama).

Del mismo modo, las relaciones que afectan a todas las subclases se asocian a la superclase, asociando a las subclases las relaciones específicas en las que la correspondiente subclase y sólo ella participa.

La relación jerárquica entre la entidad más general y sus subclases puede extenderse a varios niveles.

Una entidad puede participar en distintas Generalizaciones/especializaciones que se definen atendiendo a criterios distintos. El criterio se puede indicar al lado del arco.

La especialización de una entidad en varias subclases puede ser total (T) con lo que todas sus ocurrencias deben participar en alguna subclase, o parcial (P) en caso contrario. También tendrá la propiedad de ser solapada (S) si una ocurrencia de la entidad puede pertenecer a distintas subclases a la vez, o disjunta (D) en caso contrario.

La especialización se representa uniendo todas las entidades especializadas según un criterio con la entidad general a través de un círculo en el que indicaremos las propiedades de la Generalización/Especialización. En el caso de que sólo haya una subclase, no hace falta el círculo.

Ejemplo de Generalización.




Ejemplos de especialización:

2.7.3.- Agregación (Entidades compuestas).

Cuando la relación que vincula dos o más entidades tiene a su vez características de entidad, de manera que se relaciona como tal con otras entidades, se aplica el concepto de agregación. Este mecanismo sirve para expresar que las ocurrencias de la relación agregada se comportan también como entidades. Para ello, se engloba el símbolo de la relación con un rectángulo, lo que denota que esa relación es un objeto agregado.

Las entidades agregadas nunca son débiles ni tienen atributos identificadores ya que heredan la identificación de la relación que las define. Sin embargo sí que pueden tener atributos con restricción de unicidad o valor no nulo. También pueden sufrir restricciones de existencia.

Ejemplo:




2.8.- Reglas para la construcción de Diagramas E-R.

Construcción del modelo inicial.

El Diagrama E-R inicial se construye basándose en el propio conocimiento del sistema, y a partir de las entrevistas iniciales al usuario donde obtenemos los requerimientos de la organización.

No se debe esperar que este modelo inicial sea el definitivo.

Las actividades a realizar serán las siguientes:

- Identificar tipos de entidad y atributos,

- Identificar generalizaciones/especializaciones,

- Identificar tipos de relación entre tipos de entidades,

- Identificar tipos de entidad débiles,

- Identificar agregaciones, y

- Especificar restricciones de integridad.

Refinamiento del modelo inicial.

Las actividades anteriores se realizan de forma iterativa hasta conseguir definir un Diagrama E-R lo más fiel posible a la realidad y en el cual el conjunto de restricciones de integridad textuales sea lo más pequeño posible.

Si se ha hecho el DFD, seguramente estará definido el almacén de datos asociado en el Diccionario de Datos. Al hacer este refinamiento nos podemos encontrar ante la necesidad de añadir nuevas entidades o eliminarlas.

Añadir/eliminar entidades al modelo inicial.

Tendremos los siguientes casos:

1. Datos elementales que no pueden aplicarse a todas las instancias de una entidad.

Entidad Empleado: Atributos: nombre, edad,..., número de embarazos ...

Solución: Crear un conjunto de entidades subclases Empleado-Masculino, Empleado-Femenino.



2. Datos elementales aplicables a todas las instancias de dos entidades diferentes.

Entidad Cliente-Caja, Cliente-Crédito. Atributos comunes: nombre, dirección.

Solución: crear una entidad superclase Cliente.

3. Datos elementales que describen relaciones entre entidades-tipo.

Relación Compra y los datos fecha_de_compra, y descuento.

Solución: Crear una entidad asociativa Compra.

4. Eliminar grupos de datos repetitivos dentro de una entidad.

Entidad Empleado, y cada uno puede tener varios hijos. Solución: Crear una entidad Hijo y la relación

Es_Padre_de. Eliminar entidad del modelo inicial.

5. Entidades de las cuales solo hay una instancia, y solo tienen identificador.

Entidad Cónyuge, de la cual sólo nos interesa el nombre. Solución: Eliminar la entidad Cónyuge y la relación

Esta_Casado_con y guardamos el nom_cónyuge con el atributo empleado.

6. Relaciones calculadas o derivadas.

Relación Renovación, que se puede calcular a partir de diversos datos de Conductor (fecha_nacimiento, apellidos,...).

Solución: eliminar la relación Renovación. Comentarios:

- No puede haber entidades con el mismo nombre que otra entidad o que otra relación.

- En un diagrama ER todas las entidades tienen atributos identificadores o bien son débiles o especializaciones.

- Las entidades especializadas nunca tienen atributos identificadores ni son débiles ya que heredan la identificación de su entidad general.

- En una ocurrencia de una relación n-aria siempre participan n ocurrencias de entidad, una de cada una de la n entidades relacionadas.

- En el modelo ER no existen las claves ajenas (concepto propio del modelo relacional) de forma que nunca se debe incluir un atributo en una entidad con la intención de que represente una


Modulo de Analisis y Diseno Tercero Bachillerato

Documents

Transcript of Modulo de Analisis y Diseno Tercero Bachillerato