Modulo de Analisis y Diseno Tercero Bachillerato

UNIDAD EDUCATIVA PCEI
MIGUEL DE CERVANTES
MDULO # 1: DE ANLISIS Y DISEO DETALLADO DE

APLICACIONES INFORMTICAS DE GESTIN
TERCERO INFORMTICA
OBJETIVOS:
El Mdulo de Anlisis y Diseo Detallado de Aplicaciones Informticas de
Gestin 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 elaboracin de un
plan de pruebas de aplicacin para conseguir que la solucin informtica
presentada ante una demanda cumpla los requisitos inicialmente
establecidos. Todos estos pasos habr que documentarlos y
fundamentarlos siguiendo las directrices que marque la metodologa de
desarrollo que se emplee, as como siguiendo las directrices del (de los)
analista(s).
CONTENIDOS:
Introduccin a los sistemas de informacin
Introduccin
Sistemas de Informacin
Software
Empresa como sistema de informacin
Sistema de informacin bsicos en las empresa
Desarrollo de aplicaciones informticas
Ciclo de vida de un sistema.

1
Lic. Sandra E. Tene G.

MIGUEL DE CERVANTES
Metodologa de desarrollo.
Clasificacin de las metodologas de desarrollo.
Principales metodologas de desarrollo europeas.
Anlisis de necesidades y estudio de viabilidad
Cmo comienza un proyecto.
Definicin del problema.
Propuesta de soluciones alternativas.
Seleccin de una alternativa.
Anlisis de requisitos. Anlisis estructurado. Modelizacin conceptual

de funciones
Introduccin al anlisis de requisitos (A.R.).
Anlisis estructurado
Modelizacin conceptual de datos
Introduccin a las bases de datos. Concepto.
Arquitectura. Modelos de datos
Tcnicas de especificacin de control
Anlisis orientado a los datos

MIGUEL DE CERVANTES
INTRODUCCIN A LOS SISTEMAS DE INFORMACIN

Introduccin
Hoy en da, todas las organizaciones han asumido la necesidad de utilizar
herramientas informticas para mejorar la comprensin 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 da a da. Para subsistir en
este escenario, donde los mercados exigen respuestas cada vez ms
rpidas y nada es estable ni inmutable, es preciso que los gestores puedan
acceder de forma rpida y eficaz a las fuentes de informacin que les
indiquen la situacin 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 adquisicin y proceso
de datos de los seres humanos no asistidos por sistemas de cmputo. Por
todo ello, las organizaciones crean sistemas de informacin automatizados
que les ayudan a lograr sus objetivos.
A continuacin se definen los trminos sistema e informacin.
SISTEMA
Un sistema es un conjunto de elementos ordenadamente relacionados
entre s y que cooperan para la consecucin de un determinado fin u
objetivo comn.
Ejemplo:
Sistema monetario,
de seguridad,
Sistema Solar,
de ftbol,
de lavado.
Atendiendo a la definicin se pueden distinguir los principales elementos y
caractersticas presentes en cualquier sistema tpico:
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.

MIGUEL DE CERVANTES
El fin u objetivo del sistema: esta caracterstica que puede resultar

discutible, se encuentra presente en los sistemas finalistas, donde
los elementos se relacionan para la consecucin 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
agregacin/divisin puede formar parte de otro ms general, que
sera su entorno, y/o estar formado por otros sistemas, que en este
caso lo tendran a l como entorno comn denominndose
subsistemas (estudiados mediante el enfoque sistmico), o por
solapamiento que existan elementos o partes del sistema que
pertenezcan a varios sistemas.
Los lmites del sistema: la frontera entre lo que el sistema es y lo

que constituye el entorno.
Tambin 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 sistmico u holstico del sistema se pude definir como: la
manera de estudiar o analizar sistemas adoptando una visin global de los
mismos, que se va refinando progresivamente mediante una
descomposicin de arriba a abajo. Se empieza por concebir al sistema
como una caja negra con entradas y salidas. Una vez identificados los
lmites 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 contina
descomponindose 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.
INFORMACIN.
4

MIGUEL DE CERVANTES
La informacin es un conjunto de datos procesados y comunicados de

forma que resulten tiles o significativos para el receptor de los mismos.
Por tanto, la informacin slo surge cuando se produce un proceso de
comunicacin, debido a que la informacin depende tanto de los datos
transmitidos como del estado del receptor.
Los datos estn constituidos por registros de hechos, acontecimientos,
transacciones, etc.
Ejemplo:
Datos Informacin
260664 Fecha de nacimiento: 26 de junio de 1964.
Maana 1950 Cita con el dentista a las 19 horas y 50 minutos.
Efecto 2000 (260600) 26/06/1900 26/06/2000
La informacin estimula a la accin y su valor reside en que permite decidir
mejor, ya que la decisin es el paso previo para toda accin.
Cantidad frente a Calidad:
Lo que nos interesa no es tanto la cantidad de informacin sino su calidad.
Llamamos calidad de la informacin al conjunto de cualidades que, adems
de su capacidad para disminuir el nivel de incertidumbre del receptor,
ayudan a este a tomar decisiones ms ventajosas. Estas cualidades son:
La informacin es relevante para el propsito de la decisin 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 informacin relevante para la decisin, pero esto nunca
ocurre en el mundo real. Lo importante es que la informacin sobre
los elementos clave sea completa.
La informacin se comunica a la persona adecuada para la toma de

la decisin.
Se comunica a tiempo para que pueda ser til.
Llega al nivel de detalle ms adecuado.
La informacin debe ser comprensible para el receptor.
Sistemas de informacin
Cualquier organizacin o empresa es un sistema en s misma. Su entorno
es el sistema productivo en que se inserta, del que recibe un flujo fsico
5

MIGUEL DE CERVANTES
de entradas compuesto por materias primas, mano de obra, flujos

financieros y otros recursos, que transforma en un flujo fsico de salidas u
oferta, compuesto por productos o servicios, flujos financieros, etc.
A este conjunto de elementos y operaciones se les suele denominar
sistema fsico, operativo o de operaciones.
Para controlar el sistema fsico de la organizacin es preciso que exista
un sistema de gestin-decisin, encargado de la regulacin y direccin de
dicho sistema. Su fin ser pues ajustar el comportamiento del sistema
fsico a los objetivos que sean fijados. Tpicamente el sistema de gestindecisin se compone del personal de la empresa, directivos, ejecutivos y
simples operarios, que toman sus decisiones a partir de la informacin
que reciben del sistema fsico.
A su vez dentro del sistema de gestin-decisin 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 funcin (sistema) contable y de gestin
econmica.
Comercializar de manera ptima los productos o servicios en los

que la empresa basa sus negocios: funcin comercial y de ventas.
Fabricar productos o crear servicios que vender en el mercado.

Funcin o departamento de Produccin.
Para que tanto el sistema fsico como los dems subsistemas (sistema de
gestin-decisin) que forman la organizacin funcionen coordinadamente,
es necesario otro subsistema ms, el sistema de informacin (SI). Este
sistema dota, a la organizacin, de la infraestructura necesaria para
coordinar los flujos y los registros de informacin 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.
Definicin de sistema de informacin basada en su objetivo.
Objetivos en el tratamiento de la informacin:
Proporcionar la informacin correctamente.

MIGUEL DE CERVANTES
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 mnimo.
Definicin:
Un SI es un conjunto formal de procesos que, operando sobre una
coleccin de datos estructurada segn las necesidades de la empresa,
recopilan, elaboran y distribuyen la informacin (o parte de ella) necesaria
para las operaciones de dicha empresa y para las actividades de
direccin y control correspondientes (decisiones) para desempear 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 informacin. Es el elemento fundamental del sistema y su razn

de ser. Se debe adaptar a las personas que la manejan y al equipo
disponible, segn los procedimientos de trabajo que la empresa ha
creado para que las actividades se realicen de forma eficaz.
Los procedimientos y las prcticas habituales de trabajo que rigen

la transmisin de los flujos de informacin y su uso para el buen
funcionamiento de la empresa.
Recursos humanos: las personas o usuarios. Se trata de individuos

o unidades de la organizacin que introducen, manejan o usan la
informacin para realizar sus actividades en funcin de los
procedimientos de trabajo establecidos.
Recursos fsicos o materiales: el equipo de soporte para la

comunicacin, el procesamiento y el almacenamiento de
informacin. Este sistema fsico puede incluir elementos de los
ms variados niveles tecnolgicos, como documentos y
archivadores, equipos de telecomunicaciones y de informtica,...
Para lograr sus objetivos, la organizacin y sus individuos adoptan

maneras de trabajar que resulten ms tiles y eficaces. Estas prcticas de
trabajo marcan:
Qu informacin se necesita.

MIGUEL DE CERVANTES
Cmo 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 informacin de la que no se
puede disponer.
Las prcticas de trabajo obligan a la gente a adoptar una cierta manera

de actuar, pero deben, a su vez, adaptarse a las caractersticas de las
personas implicadas para ser eficaces.
Los procedimientos deben acomodarse al equipo o tecnologa existente.
Sistemas de informacin y tecnologas de la informacin.
Aunque un SI puede organizarse sin incluir prcticamente ningn
componente al que se pueda clasificar dentro de los elementos de las
modernas tecnologas de la informacin (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
tambin en tremendas mejoras de la estructura y funcionamiento de los SI
en las organizaciones.
Al principio de la revolucin de la informacin se comenz con mquinas
de escribir, calculadoras mecnicas, telfonos, cintas de papel perforado,
etc. y se ha llegado, en plena era postindustrial, y dentro de lo que se
conoce como era de la informacin, a utilizarse tecnologas sofisticadas
de tratamiento y comunicacin de informacin, como informtica,
comunicaciones, etc. a las que se ha denominado genricamente TIC
(Tecnologas de la informacin y la comunicacin). Actualmente se
comenta que la era de la informacin ha dado paso a la era de la
comunicacin, en la cual nos encontramos.
Dentro de un SI existirn mbitos en los que las TI manejen todas las
transformaciones significativas de informacin. A dichos mbitos se les ha
dado el nombre de sistemas automatizados de informacin (SAI). Las dos
razones principales que justifican la automatizacin de un SI son:
La simplificacin y mejora del nivel operacional, tanto en el trabajo

administrativo (soporte de la gestin comercial, contabilidad,
facturacin, nmina, etc.) como en el de produccin (operaciones
de ingeniera, diseo, fabricacin asistidas por ordenador) al
automatizarse procedimientos repetitivos y frecuentemente
tediosos y al potenciar enormemente las capacidades operativas
del ser humano.

MIGUEL DE CERVANTES
Ayuda a la gestin-decisin: la formidable potencia de proceso de

los equipos informticos permiten organizar, procesar, condensar,
filtrar y manipular la informacin de manera que su utilidad de cara
a los mbitos de gestin y decisin se haga mxima.
La implantacin 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
ms sencillo es el operacional o transaccional. A este nivel se producen
las operaciones o transacciones cotidianas de la empresa. Dependiendo
del tamao, calidad y complejidad de la empresa existen de forma
abstracta o escrita unos protocolos (manuales de actuacin) para la
realizacin de tareas por parte de los empleados.
Por ejemplo, en una empresa de servicios telefnicos se incluyen las
operaciones para realizar un contrato, consultar el estado de un telfono,
dar de alta una avera.
Una vez que se llevan a cabo las tareas operativas diarias de forma
informatizada se produce un segundo caso, que consiste en la
implantacin de las bases de datos. El desarrollo de las bases de datos
da origen a los Sistemas de informacin para la gestin (Management
Information System o MIS). Un MIS es un sistema de organizacin de la
informacin en la empresa donde se puede mostrar toda la informacin
disponible. Son sistemas soportados a nivel Tctico, permitiendo tomar
decisiones no rutinarias, pero esperadas, que se repiten con cierta
periodicidad, de una forma ms adecuada y rpida.
No son transacciones, pero s consultas estructuradas segn algn
lenguaje de manipulacin de datos que le permita crear informes, listados,
basados en la informacin almacenada en las bases de datos, llegndose
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 automticamente dichas
decisiones.
A un nivel superior, en la implantacin 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 mtodos claros para
tomarlas y tampoco es posible identificar con anticipacin cules deben
ser los factores que hay que considerar.
Por ejemplo, un directivo se pregunta sobre la respuesta de la
9

MIGUEL DE CERVANTES
competencia ante el nuevo modelo de contestador automtico 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 decisin en
manos del directivo. Los datos disponibles provienen de diversas fuentes,
por lo que estarn almacenados en varios ficheros, a no ser que se
emple un DSS especfico para un determinado tipo de problemas.
Con las nuevas tecnologas de la comunicacin, como la mensajera
electrnica, y con posibilidades de realizar toda la gestin de informacin
comercial a travs de Internet, se pueden conseguir MIS ms eficaces.
Aunque en una empresa coexistirn varios niveles de sistemas de
informacin, se tender a crear un sistema de informacin total sobre
todos los niveles.
Software
Durante los primeros tiempos de la informtica el principal desafo fue el
desarrollo del hardware de los ordenadores, el software se desarrollaba
intentando optimizar al mximo el hardware. Los responsables de los
Centros de Proceso de Datos ponan normas en el Anlisis y Diseo, para
conseguir mejoras; de esta forma el desarrollo del software se convirti en
un arte indisciplinado.
Durante la dcada de los 80 los avances en microelectrnica 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.
Definicin.
El software engloba:
1. Instrucciones que cuando se ejecutan suministran la funcionalidad
(funcin y comportamiento) deseada.
2. Estructuras de datos que facilitan a las instrucciones manipular
adecuadamente la informacin.
3. Documentos que describen el desarrollo, uso, instalacin y
mantenimiento de los programas.
El software es por tanto un elemento ms lgico que fsico con unas
caractersticas propias que lo distinguen de hardware.
Caractersticas del software.
10

MIGUEL DE CERVANTES
El software es un elemento del sistema que es lgico.
Es desarrollado, no fabricado en un sentido clsico.
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 situacin en la que se haya
definido previamente un conjunto especfico de pasos procedimentales.
La determinacin y contenido de la informacin son factores importantes
para determinar la naturaleza de una aplicacin software.
El contenido se refiere al significado y a la forma de informacin de
llegada.
La determinacin de la informacin se refiere a la necesidad de predecir
el orden y tiempo de llegada de los datos.
En funcin de estos dos factores obtenemos las siguientes categoras
bsicas:
Software de sistemas: es un conjunto de programas que estn hechos
para servir a otros programas. Tienen una fuerte interaccin con el
hardware de la computadora, operando de forma concurrente, por lo que
requiere planificacin, comparticin de recursos y una sofisticada gestin
de procesos. (p. ej.: compiladores, utilidades de gestin de archivos, de
perifricos, 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
ningn desastre.
Software de gestin: orientado al procesamiento de informacin
comercial, siendo esta una de las reas de mayor aplicacin del software.
Este software ha evolucionado de los sistemas discretos (nominas,
contabilidades, inventarios, etc.) hacia los sistemas de informacin de
gestin que hacen uso de grandes bases de datos (MIS, DSS).
Software cientfico y de ingeniera: se caracteriza por el uso de
algoritmos de manejo de nmeros, generando software para, por
11

MIGUEL DE CERVANTES
ejemplo, astronoma, anlisis de presin de automotores, biologa

molecular. Algunas aplicaciones interactivas, como simulacin de
sistemas o CAD, toman caractersticas 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 slo lectura. (p. ej.: microondas, videos, sistema
ABS de un automvil, etc.).
Software de inteligencia artificial (IA): hace uso de algoritmos no
numricos para la resolucin de problemas complejos, ya que no es
adecuado el clculo o el anlisis directo. Dentro de la IA podemos
encontrar distintas reas como los sistemas expertos o sistemas basados
en el conocimiento, sistemas de reconocimiento de patrones (imgenes y
voz), redes neuronales artificiales.
PERSPECTIVA HISTRICA.
Dcada 50 60
Desarrollo artesanal del software. Se utilizan C
lenguajes de bajo nivel.
Dcada 60 70:
Se utilizan los lenguajes de alto nivel y los
compiladores.
Crisis del software.
Dcada 70 80: Dcada de las metodologas. Programacin
estructurada. Se entiende la programacin
como
una disciplina cientfica y tecnolgica.
Ingeniera del Software.
Dcada 80 90: Tecnologa de SGBDs y SOs. Nuevos paradigmas de
programacin y de produccin de programas.
Dcada 90:
Tecnologa CASE. (Volcado de resultados tericos 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 estimacin de costes.
Notables retrasos en las fechas de entrega.
Prestaciones inadecuadas.
12

MIGUEL DE CERVANTES
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

ingeniera al desarrollo del software, es decir, pasar de programacin a
produccin industrial del software, mejorando continuamente las tcnicas
y las herramientas.
Problemtica de la industria del software.
>> Objetivos de la produccin industrial del software.
Producir soluciones automatizadas a gran variedad de problemas
complejos, dando productos de calidad y cuya produccin sea
econmicamente rentable, no genere costes posteriores y se realice a
tiempo.
>> Problemas:
Los productos software son de baja calidad (fiabilidad, eficiencia,...), cuya
produccin conlleva grandes costes de desarrollo, mayores costes de
mantenimiento y notables retrasos.
>> Causas:
Naturaleza no fsica de la programacin.
Conjunto limitado de teoras bajo investigacin.
Difusin an ms limitada de dichos conceptos.
Industria artesanal y poco fundamento cientfico.
Herramientas comerciales obsoletas.
Problemas de gestin. (Planificaciones optimistas, plantillas poco

cualificadas, herramientas inadecuadas).
Problemas derivados de la intervencin de grupos.
13

MIGUEL DE CERVANTES
Poco esfuerzo en el anlisis y la especificacin.
Problemas de comunicacin con los clientes.
Gestin de proyectos por personal no informtica.
>> Soluciones:
Difusin de avances tericos (formacin):
Mtodos de parcelacin de la complejidad: programacin con

esquemas, programacin modular, programacin con objetos.
Mtodos de razonamiento formal (lgica y lgebra): lenguajes

formales ejecutables, prototipado automtico, programacin por
transformacin.
Difusin de avances tecnolgicos:
Tcnicas de reutilizacin del software.
Herramientas de cuarta generacin.
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:
INGENIERA DEL SOFTWARE.
Frizt Bauer (1969) define Ingeniera del Software diciendo que constituye
el establecimiento y uso de principios de ingeniera robustos, orientados a
obtener con economa de costes, software fiable y que funcione de
manera eficiente sobre mquinas reales.
Segn Pressman [Press98] la produccin de programas debe abordarse
como una ingeniera ms, 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 Ingeniera del Software debe aportar tres elementos clave:
mtodos, herramientas y procedimientos, de forma que se produzca
software de gran calidad.
14

MIGUEL DE CERVANTES
MTODOS.
Describen como construir tcnicamente el software. Los mtodos
incluyen tareas de: planificacin y estimacin de proyectos, anlisis de los
requerimientos del sistema y del software, diseo estructurado de datos,
diseo de programas, codificacin, prueba y mantenimiento.
Los mtodos de la ingeniera del software introducen frecuentemente una
notacin especial orientada a un lenguaje o grfica y un conjunto de
criterios para la calidad del software.
Como ejemplos de mtodos se pueden ver:
Diagrama de Flujo de Datos (DFD): son una representacin

grfica de los flujos de informacin y fsicos internos y externos a la
organizacin.
Modelo entidad/relacin: se utiliza para representar la estructura

lgica de los datos. Para stos se ha de alcanzar siempre, y como
mnimo, la tercera forma normal.
HERRAMIENTAS.
Suministran un soporte automtico o semiautomtico para los mtodos.
Existen herramientas automatizadas para soportar cada uno de los
mtodos vistos anteriormente, y sistemas que integran las herramientas
de cada fase de forma que la informacin creada por una herramienta
sirve para otra en el proceso de desarrollo. Estas herramientas se
denominan CASE (Computer Assisted Software Enginering), Ingeniera
del Software Asistido por Computadora.
Construccin de prototipos.
Un prototipo es la primera versin de un nuevo tipo de producto, en el que
15

MIGUEL DE CERVANTES
se han incorporado solamente algunas caractersticas del sistema final, o

no se han realizado completamente.
La construccin de prototipos es un proceso que facilita al programador la
creacin 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 interaccin hombre-mquina, de forma que d al
usuario una idea de cmo se realizar dicha interaccin.
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 funcin deseada, pero
con caractersticas por mejorar durante el desarrollo.
Los prototipos pueden ser Totales o Parciales dependiendo de s se
hacen para el sistema completo o slo para un subconjunto. Tambin
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 ejecucin de un prototipo sera:

Primero se recogen los requisitos y se definen los objetivos globales para
el software. Despus se produce un diseo rpido, enfocado a una
representacin de los aspectos del software visibles al usuario (mtodos
de entradas, formato de salidas, etc.).
El diseo rpido conduce a la construccin 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 compresin del trabajo a realizar.
16

MIGUEL DE CERVANTES
Los problemas que representa el prototipado son:
El cliente cree que el producto est disponible antes de lo debido.
El tcnico de desarrollo suele realizar la implementacin sobre el

prototipo con el objetivo de que funcione rpidamente.
Qu hacer con el prototipo?
Lo correcto sera, una vez concluido el trabajo para el cual se diseo el

prototipo, si no se ha utilizado una tcnica que asegure la calidad del
software, es decir, el cdigo utilizado est formado por retazos de otros
cdigos y no se disponga de una herramienta que permita construir una
aplicacin reutilizndolo, se debe desechar.
Tcnicas de Cuarta Generacin (4GT).
Aunque para Pressman las Tcnicas de Cuarta Generacin constituyen
un Paradigma del Ciclo de Vida del Software de la Ingeniera del
Software, podemos considerar a estas tcnicas como herramientas a
utilizar en otros Paradigmas como el Ciclo de Vida Clsico o el Modelo en
Espiral.
Estas tcnicas aparecen asociadas a los llamados Lenguajes de Cuarta
Generacin (4GL). En principio, estos lenguajes buscan un nivel de
especificacin mayor del software frente a los 3GL (Cobol, Pascal, C,...),
de forma que permita una construccin ms rpida del software. Como
ejemplo tememos el SQL para acceso a bases de datos relacionales.
Pero la cuarta generacin de lenguajes de programacin corresponde,
tambin, 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, generacin de
informes, definicin de pantallas, generacin asistida/automatizada de
cdigo, facilidades de grficas de alto nivel, utilizacin y ensamblaje de
unidades funcionales de muy elevado grado de complejidad como hojas
de clculo, procesadores de texto, etc.
Herramientas CASE.
CASE es la automatizacin del software.
(Computer Aided Software Engineering Ingeniera del Software asistida
por ordenador).
CASE es el conjunto de herramientas y mtodos asociados que
proporcionan asistencia automatizada en el proceso de desarrollo del
software a lo largo de su ciclo de vida:
17

MIGUEL DE CERVANTES
Gestin del proyecto: planificacin, estimacin y control.
Desarrollo del software: anlisis, diseo, implementacin y

validacin.
Mantenimiento del software.
El uso de las herramientas CASE va en aumento debido a:
La creciente dificultad prctica de poner en funcionamiento ciertos

procedimientos de las metodologas actuales de desarrollo si no es
con la ayuda de herramientas informticas (diseos grficos
complejos, tareas repetitivas, modelizacin o prototipado de
sistemas, etc.)
La necesidad de que se realice con seriedad y rigor todo el

proceso de anlisis y, sobre todo, el anlisis previo que
normalmente vena obvindose ante la urgencia de generar cdigo
cuanto antes.
Las herramientas CASE facilitan la diagramacin para la

representacin de flujos de datos y procesos haciendo ms fcil el
dilogo del usuario con el desarrollador tan importante para la
realizacin de la aplicacin.
La necesidad de contar con herramientas para disear a nivel

lgico y fsico la aplicacin a partir del anlisis.
Objetivos de la tecnologa CASE:

1. Incrementar la productividad de las reas de desarrollo y
mantenimiento de los sistemas informticos.
2. Mejorar la calidad del software desarrollado.
3. Reducir tiempos y costes de desarrollo y mantenimiento del
software.
4. Mejorar la gestin y dominio sobre el proyecto en cuanto a su
planificacin, ejecucin y control.
5. Mejorar el archivo de datos (enciclopedia) de conocimientos (knowhow) y sus facilidades de uso, reduciendo la dependencia de
analistas y programadores
18

MIGUEL DE CERVANTES
6. Automatizar:
o El desarrollo del software.
o La documentacin.
o La generacin del cdigo.
o El chequeo de errores.
o La gestin del proyecto.
7. Permitir
o La reutilizacin (reusabilidad) del software.
o La portabilidad del software.
o La estandarizacin de la documentacin.
8. Integrar las fases de desarrollo (ingeniera del software) con las
herramientas CASE
9. Facilitar la utilizacin de las distintas metodologas que desarrollan
la propia ingeniera del software
Taxonoma de las herramientas CASE.
(Revisar este punto una vez estudiado los Paradigmas del Ciclo de Vida
del Software).
Existen diferentes formas de establecer la clasificacin del CASE.
A.- Considerando su amplitud o cobertura:
CASE TOOLKIT
Es una coleccin de herramientas software integradas que permiten
automatizar un conjunto de tareas de algunas de las fases del ciclo de
vida del sistema informtico: Planificacin estratgica, Anlisis, Diseo,
Generacin de programas.
Comparten la BD de soporte y la interfaz de usuario.
CASE WORKBENCH
Son conjuntos integrados de herramientas software que dan soporte a la
automatizacin del proceso completo de desarrollo del sistema
informtico. Permiten cubrir el ciclo de vida completo. El producto final
aportado por ellas es un sistema en cdigo ejecutable (operativo) y su
19

MIGUEL DE CERVANTES
documentacin.
Adems de compartir la BD de soporte y la interfaz de usuario, estn
basadas en una misma metodologa.
B.- Por posicin o fase del ciclo de vida que automatizan:
UPPER CASE
Son las herramientas de apoyo a las primeras fases.
Planificacin estratgica, requerimientos de desarrollo funcional de planes
corporativos, estimacin de costes, mtricas del software.
MIDDLE CASE
Herramientas de apoyo a las fases centrales. Anlisis y diseo.
Entre otros muchos productos comerciales se pueden citar Designer 2000
de Oracle, System Architect 2001 de Popkin Software, EasyCase de
Visible System Corporation
LOWER CASE
Apoyo a las ltimas fases del ciclo de vida. Generacin de cdigo,
pruebas, creacin de documentacin para la implantacin y el usuario
final.
Como herramientas de bajo nivel se pueden citar todas las herramientas
de RAD -Rapid Application Development- (tcnicas RAD son la
combinacin adecuada del prototipado con las herramientas de 4
generacin). PowerObject de Oracle, PowerBuilder de Powersoft, Delphi
de Imprise, Visual Basic de Microsoft.
PROCEDIMIENTOS.
Relacionan formalmente los mtodos y las herramientas.
Definen la secuencia en la que se aplican los mtodos, 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 mtodos, herramientas y procedimientos que constituyen la
Ingeniera del Software van orientados a un nico fin: producir software de
gran calidad.
El Software: factores de calidad.
La garanta de calidad del software se aplica durante todo el proceso de
ingeniera del software, es decir, en Anlisis, Diseo, Codificacin y
Pruebas.
La calidad es la concordancia de los requisitos funcionales y de
rendimiento explcitamente establecidos, con los estndares de desarrollo
explcitamente documentados, y con las caractersticas implcitas de todo
software desarrollando profesionalmente.
20

MIGUEL DE CERVANTES
La calidad del Software es una compleja mezcla de ciertos factores que

varan para las diferentes aplicaciones y los clientes que las solicitan.
Mc Call realiza la siguiente clasificacin con respecto a la calidad del
software:
Factores Externos.
Los factores externos son aquellos que son observables sin mirar el
cdigo del sistema. Se pueden distinguir los siguientes:
Correccin. El grado en que un programa satisface sus

especificaciones y consigue los objetivos de la misin
encomendada por el cliente.
Eficiencia. El buen uso de recursos Hw/Sw disponibles y de

cdigo 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 Interoperacin. 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 Diseo

del sistema determina la facilidad de ser verificado en cuanto a su
correccin. En general, cuanto ms modular sea un sistema ms
facilidad para aporta para poderse comprobar su correccin.
Integridad. Un sistema ntegro ser aqul que preserve las

garantas 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 interaccin para los
21

MIGUEL DE CERVANTES
usuarios, sobre todo para los no expertos en informtica.

Factores Internos.
Son aquellos que son observables sobre el cdigo del sistema:
Legibilidad. Facilidad de lectura e interpretacin del cdigo del

programa.
Modularidad. Independencia funcional de los componentes del

programa. El software que es monoltico (de una sola pieza) no
puede ser fcilmente abarcado por un lector debido al gran nmero
de variables y referencias que incluye.
Empresa como sistema de informacin

Introduccin.
La empresa es una unidad econmica de produccin y/o servicios cuyo
objetivo tradicional es la obtencin del mximo beneficio a medio y largo
plazo. Una empresa tpica ha de acometer una serie de funciones, siendo
las ms caractersticas las siguientes:
* Funciones organizativas:
Administrativas y contable: muy importante. Se trata de la versin

actual de la clsica tenedura de libros, cuyo objetivo es el control de
las magnitudes cuantitativas internas (bienes, derechos, obligaciones)
y externas (legales) de la organizacin.
Direccin: marca la pauta de todas las dems funciones controladas

para que cumplan con los objetivos que previamente se han
determinado.
Financiera: el aprovisionamiento y utilizacin de los recursos

financieros constituyen una importante faceta de cualquier
organizacin actual.
Recursos humanos: se ocupa tanto de la gestin de personal como

de las tareas administrativas relacionadas con la contraprestacin
salarial (nminas).
* Funciones productivas:
Comercializacin: incluye tanto las tareas directas de poner a

disposicin de los clientes los bienes y/o servicios, como aquellas
tareas accesorias de promocin, publicidad y marketing,
22

MIGUEL DE CERVANTES
indispensables en un entorno competitivo como el actual.
Gestin de almacn: es una funcin complementaria a las de

comercializacin y/o produccin de bienes. Su objetivo es gestionar
de la mejor forma posible las existencias de bienes, de manera que
no slo suponga una carga (por inmovilizacin del recurso) para la
empresa, sino que lleguen a producir autnticos beneficios.
Investigacin
y
desarrollo: esta
es
una
funcin
que
desgraciadamente no se da en muchas organizaciones. Busca la
mejora en las tcnicas, procesos y equipamientos utilizados o
suministrados por la empresa
Produccin de bienes y /o servicios: muchas empresas son

simplemente comerciales, dedicndose a ofrecer los productos y
servicios ofrecidos por otras organizaciones. Sin embargo, en otras
muchas, el mbito de produccin es muy importante.
Niveles de la toma de decisiones.

En cualquier organizacin, las necesidades de informacin pueden ser
graduadas segn una escala de impredecibilidad, presentada a
continuacin:
No repetitiva e impredecible
No repetitiva, pero parcialmente predecible.
Bastante repetitiva, definida slo en parte.
Muy repetitiva, definida con precisin
La posicin que esas necesidades ocupan en esta escala tiene un gran

efecto sobre el diseo de las estructuras informticas de soporte de los SI:
En el fondo de la escala, la informacin en cuestin 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 informacin que se solicita, cuya estructura,
contenidos y formatos se encuentran definidas con absoluta
precisin.
A medida que se asciende en la escala, los requerimientos de

informacin son cada vez menos repetitivos. Por ejemplo, podran
23

MIGUEL DE CERVANTES
limitarse a uno cada varios das por persona. Asimismo, existira una
variacin creciente en la estructura deseada de lo que se pide, de
modo que el sistema de informacin deber llevar a cabo una
composicin sobre la marcha, lo que ser indudablemente ms
costoso que un simple rellenado de campos predefinido. En este
sentido, cuando menos frecuentes sean las solicitudes de
informacin, tanto ms valiosas deben ser las respuestas para
justificar el costo del sistema.
En el tope superior de la escala, la informacin buscada ha de ser

tremendamente valiosa. Estamos hablando, por ejemplo, de los datos
que necesita la direccin de una empresa para tomar grandes
decisiones. En estos casos es perfectamente posible que esa
informacin nunca haya sido solicitada con anterioridad, pues hubiera
sido necesaria una visin de futuro extraordinaria para preverla. No
obstante, es muy posible que los datos necesarios para atender el
requerimiento en cuestin se hallen almacenados en algn lugar de la
base de datos de la organizacin. Pero para poder responder a la
solicitud ser preciso localizar esos datos y procesarlos. La
localizacin ser rpida slo si los datos estn debidamente
organizados y stos podrn ser procesados slo si se cuenta con los
programas convenientes.
Tradicionalmente, se ha venido describiendo la estructura decisional de

todas las organizaciones, incluyendo las empresas, en funcin de esta
escala de predecibilidad. Para ello, se utiliza la metfora de la pirmide, que
representa la jerarqua de los niveles de actuacin y decisin de la empresa:
24

MIGUEL DE CERVANTES
Nivel estratgico.
En este nivel se mueve exclusivamente la direccin de la organizacin,
trabajando con plazos medios y largos (superior a un ao) para acometer la
tarea de decidir las lneas maestras que debe seguir la empresa en el futuro.
La informacin tiene un formato muy resumido, con el objetivo de predecir
qu ser lo mejor para el xito futuro de la compaa. Las decisiones que se
deben tomar en este nivel estn poco formalizadas y tienen un fuerte
componente subjetivo.
En este mbito, el SI de informacin debe estar orientado pues a soportar la
toma de decisiones, facilitando la labor de la direccin. Se trata pues de un
trabajo en el nivel mnimo de predecibilidad, es decir, no existe una carga
peridica de trabajo, ni utilizacin predecible. Destacan entre estos
sistemas, los Sistemas de informacin para la gestin (Management
Information System o MIS), Sistemas de soporte o apoyo a las decisiones
(DSS), Sistemas de Informacin Ejecutivos (EIS, Executive Information
Systems), Sistemas de Simulacin de Negocios (en la prctica son Sistemas
Expertos o de Inteligencia Artificial).
Nivel Tctico.
En este nivel se mueven tanto los elementos directivos como ejecutivos de
la organizacin, preocupar de la asignacin efectiva de recursos a medio
plazo para mejorar el rendimiento de la empresa.
El manejo de informacin se centra en datos de produccin tanto peridica y
rutinaria como excepcional y de necesidad inmediata. Tiene el propsito de
descubrir algo nuevo sobre los datos, no slo lo evidente, actuando sobre
informacin resumida y de naturaleza comparativa ms 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 compaas).
El trabajo se concentra en el anlisis de informes de los tipos siguientes:
Resmenes con medidas estadsticas. Media de ventas por unidad

organizativa, total de horas extras, etc.
De excepciones. Aquellas unidades organizativas cuyos parmetros

se apartan de la media, como centros con prdidas, etc.
Especficos. Informaciones que no se haban pedido antes y que los

directivos necesitan normalmente con rapidez para resolver un
problema muy concreto (que se suele detectar gracias a algn
informe de excepciones). Por ejemplo cuando un producto nuevo no
funciona se puede pedir un informe de lneas actuales de
25

MIGUEL DE CERVANTES
comercializacin, caractersticas de los adquirientes, etc.

Este nivel tctico se suele apoyar en sistemas ofimticos, sistemas de
transmisin de mensajeras (e-mail y servicios de facsmil), coordinacin y
control de tareas y tratamiento de documentos (captacin, tramitacin y
bases de datos documentales), as como Sistemas MIS.
Nivel Tcnico-Operativo.
Situado en el punto ms bajo de la escala de impredecibilidad, este nivel
incluye el procesamiento de las actividades diarias o transacciones, los
acontecimientos rutinarios que afectan a la organizacin: facturacin, pagos,
entrega de productos, fabricacin de bienes, etc., y al nivel de decisin
inmediatamente superior, que se preocupa del anlisis de los resultados, en
especial con relacin a los recursos consumidos en las operaciones
habituales para tomar decisiones a corto plazo y de consecuencias
limitadas, como, por ejemplo, adquisicin de materias primas, ordenacin de
la produccin, asignacin de trabajadores, etc.
En el primer caso se trata de un mbito informacional dominado por las
operaciones de tipo transaccin, que son procesamientos de las actividades
diarias o transacciones, los acontecimientos rutinarios que afectan a la
organizacin. Suelen tener caractersticas similares en todas las empresas:
Los procesos de tratamiento estn perfectamente descritos hasta el

ms mnimo detalle.
Aunque estn 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 nmero de operaciones es muy elevado.
En nivel operativo de direccin se suele trabajar con informacin procedente

del registro de transacciones, informacin cuyas caractersticas principales
son:
Es repetitiva y predecible. As, son documentos tpicos de este nivel

los informes peridicos 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 informticos actuales van siendo capaces
de mostrar al momento el resultado de todas las operaciones habidas
hasta la fecha.
26

MIGUEL DE CERVANTES
Con datos originados internamente. Lo que permite que tengan

asignados formatos bien estructurados y que sean detallados y
precisos.
En cualquier caso, las herramientas informticas utilizadas cubren el ncleo

de operaciones tradicionales de captura masiva de datos y servicios bsicos
de tratamientos de datos, con tareas predefinidas (contabilidad, facturacin,
almacn, presupuesto, personal y otros sistemas administrativos, fabricacin
asistida, etc.). Estos sistemas evolucionan paralelamente a las capacidades
de los sistemas informticos. Por ejemplo, si tradicionalmente exista un
conjunto de operarios encargados de introducir en el sistema a posteriori la
informacin sobre las operaciones efectuadas por todos lo dems, hoy en
da va siendo habitual que la informacin 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 Organizacin.
Flujos de informacin en la empresa.
Existen dos grupos principales de flujos de informacin en la empresa:
horizontales (para la coordinacin) y verticales (basados en la jerarqua):
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. Carcter histrico.
2. Flujos verticales descendentes: de jefe a subordinado. Se trata de
rdenes, tambin solicitudes especficas de informacin para tomar
decisiones o controlar el funcionamiento.
3. Flujos horizontales: entre personas del mismo nivel de autoridad,
entre compaeros 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 comunicacin giles y eficaces en la empresa.
Sistema de informacin bsica en la empresa
Sistema de Recursos Humanos.
El recurso o activo ms importante en una empresa es el constituido por el
conjunto de personas que la componen. Las actividades de gestin
relacionadas con el personal de la empresa se basan en dos aspectos
principales:
1) La gestin de la informacin relacionada con la plantilla: incluye
informacin personal compuesta de:
27

MIGUEL DE CERVANTES
Filiacin completa.
Historial laboral.
Datos relacionados con el salario y los incentivos.
Datos sobre la carrera profesional e historial formativo de los

empleados.
2) La ejecucin de la nmina: para determinar todos los conceptos de la

paga de cada empleado, se debe disponer de sus datos contractuales y del
historial laboral en el perodo para determinar su retribucin bruta.
Despus se deben deducir los pagos de la seguridad social, retenciones del
impuesto de la esta, etc. Cada uno de ellos se calcula en funcin de datos
personales. Dado que tiene una gran relacin con el entorno legal, la
nmina, junto a la contabilidad, es el subsistema que ms cambios sufre
como reaccin a los cambios del entorno, por lo que deben contar con una
estructura flexible. El desarrollo de la aplicacin de nminas suele ser muy
cuidadoso por la repercusin social de cualquier fallo.
Generalmente se hace una adaptacin 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
gestin econmica.
La gestin 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 psicolgico, etc, para que se puedan
identificar candidatos para las promociones internas y adecuar cada
persona al puesto ms apropiado a sus caractersticas.
Inventario de puestos de trabajo existentes en la empresa y de las

condiciones ms adecuadas para desempearlos.
Evaluacin de los empleados en funcin de los informes de sus

superiores, de la consecucin de los objetivos marcados, etc.
Generacin de los informes que hay que remitir a la administracin

pblica.
28

MIGUEL DE CERVANTES
Gestin de las solicitudes de empleo.
Nivel tctico:
Anlisis y diseo del perfil de persona ideal para cada puesto de

trabajo, para saber qu tipo de persona hay que contratar o qu
formacin debe recibir alguien antes de ascender a un cargo.
Analizar las necesidades de contratacin de personal para cubrir los

objetivos de la empresa a medio plazo, generando planes de
previsin de reclutamiento de plantilla.
Generar planes para crear incentivos y aplicar beneficios sociales a

los empleados.
Anlisis de las necesidades de formacin y creacin de planes para la

mejora del nivel tcnico-profesional de la plantilla.
Nivel estratgico:
la gestin de RRHH debe preocuparse de crear planes que indiquen

la cantidad de personal, sus caractersticas, las fechas en las que
contratar, los cursos de formacin necesarios, etc. para poder contar
con la infraestructura de personal apropiada para los objetivos de la
empresa
Las caractersticas de los sistemas informticos que dan soporte a

estos subsistemas son:
La nmina se suele realizar mediante aplicaciones de trabajo en lotes

ya que slo deben trabajar a finales de mes con grandes ficheros que
resumen los datos relacionados con el salario una vez que toda la
informacin est disponible.
La gestin de personal requiere algunos tratamientos inmediatos e

interactivos y otros que actan de manera peridica sobre grandes
grupos de datos.
En ambos casos la informacin manejada es confidencial, por ello los

sistemas deben contar con un control estricto de accesos que asegure una
adecuada proteccin de los datos.
Sistema de Gestin Comercial.
El propsito principal de todo negocio es vender satisfaciendo las
29

MIGUEL DE CERVANTES
necesidades de los clientes. Las actividades de gestin relacionadas con el

trato con los clientes se basan en dos reas principales:
1) Las propias ventas, que incluyen:
La gestin y el tratamiento de los pedidos. Se debe controlar la forma

de pago, determinar con precisin 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 facturacin de la venta o pedido una vez comprobada su

viabilidad.
El control de los detalles de entrega y la actualizacin del inventario

cuando se confirma la operacin de venta.
En la tramitacin de pedidos puede haber una gran cantidad de

acontecimientos que hay que considerar: cancelacin, pedidos en espera de
contar con todos los productos, reserva de ejemplares o artculos, pedidos
pendientes de pago, etc.
2) La funcin de comercializacin:
Implica el anlisis de las ventas, de la competencia, de los gustos y
demanda de los clientes, para optimizar todos los aspectos que intervienen
en la implantacin de productos en el mercado. Los planes comienzan con
un pronstico de ventas, basado en factores como la ventaja competitiva, el
precio, la promocin, las preferencias de los clientes, etc. Todos los
presupuestos y planes para la publicidad, promocin e, incluso, creacin de
productos o servicios dependern de los ingresos estimados y de los
estudios sobre su xito comercial. El estudio de la comercializacin requiere
informacin de:
Ventas: estadsticas sobre las ventas.
Investigacin de mercados.
Tcnica de los departamentos de produccin, de diseo o de

fabricacin sobre la capacidad de innovacin, sobre la mejora de las
caractersticas de los productos, etc.
Datos sobre la capacidad financiera de la empresa para acometer

campaas de promocin, diseo de nuevos productos, etc.
En los distintos niveles se ocupa de:
30

MIGUEL DE CERVANTES
Nivel operativo:
Gestin de las carteras de clientes para la localizacin de los

compradores potenciales.
Control de los contactos con los clientes.
Consultas sobre caractersticas y disponibilidad de productos.
Informacin sobre el crdito p la consideracin econmica de cada

cliente.
Facilidades para la gestin de pedidos y facturas o cualquier otro

documento comercial.
La gestin de la distribucin de los productos.
Nivel tctico:
La recogida de informacin de ventas de cada cliente, de cada zona,

de cada tipo de producto, etc. para un posterior anlisis que permitir
controlar si las previsiones se cumplen, detectar posibles problemas,
etc. Gracias al estudio de estos datos se pueden planificar las
prximas campaas, se controlan las actuales y se pueden fijar los
objetivos de ventas para los responsables de rea y para los
departamentos.
La gestin y el control de las campaas de publicidad y de promocin

con el fin de optimizarlas, consiguiendo llegar al segmento de
mercado deseado, eligiendo los medios ms apropiados, buscando la
mejor mezcla de acciones de presentacin, etc.
El establecimiento de los precios en funcin de los datos del

mercado.
Las decisiones sobre la mejor forma de distribuir los productos en

funcin de la informacin sobre los costes y los plazos de los distintos
canales de distribucin, la fiabilidad de la entrega, etc.
Anlisis de los competidores.
Nivel estratgico:
Dividir el mercado n segmentos de personas con caractersticas o

31

MIGUEL DE CERVANTES
necesidades comunes.
Seleccionar los segmentos a los que la organizacin 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.
Caractersticas de los sistemas informticos que dan soporte:

La gestin de pedidos y facturacin 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 gestin comercial se
debe apoyar en grandes masas de datos para obtener la suficiente
informacin, lo que implica el trabajo con grandes bases de datos cuyos
accesos ms crticos deben ser optimizados. La mayora de las funciones de
anlisis de mercado necesitan realizar simulaciones complejas y anlisis
estadsticos sofisticados. Se pueden encuadrar como sistemas de apoyo a
las decisiones.
Sistema de Gestin Contable y Financiera.
La gestin econmica se ocupa en los distintos niveles de:
Nivel operativo:
Las actividades de contabilidad de toda la empresa siguiendo la legislacin
correspondiente, lo que provoca que muchos de los datos a tratar y los
procedimientos a seguir estn prcticamente estandarizados. La gestin
contable diaria implica hacer frente a ciertas funciones clsicas:
Control de activos fijos.
Gestin de cobros.
Gestin de pagos.
Control de inventario.
Ejecucin de la nmina.
Generacin de informes para la direccin y de toda clase de

documentos oficiales preceptivos.
32

MIGUEL DE CERVANTES
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 transaccin. sta constituye el objeto principal del control interno
representado por la contabilidad.
Nivel tctico:
Gestin y control de presupuestos.
Informacin sobre el flujo de caja.
Control de los planes de gasto de capital.
Nivel estratgico:
Obtencin de previsiones financieras a largo plazo.
Recogida de informacin tanto financiera como de parmetros

econmicos y sociales para el posterior anlisis y simulacin.
Caractersticas de los sistemas informticos que dan soporte:

Los sistemas informticos suelen ser interactivos, deben trabajar con
grandes bases de datos y requieren simulaciones. Los sistemas de
informacin deben estar orientados eminentemente al apoyo a las
decisiones.
Sistema de Control de Almacn.
El objetivo principal de un sistema de gestin de inventario es el control de
las existencias almacenadas. Los grandes costes que significar tener
mercancas paradas en un almacn 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.
Recepcin de las materias primas o componentes.
Envo de los productos fabricados a los clientes.
33

MIGUEL DE CERVANTES
Nivel tctico:
Gestin y control de las materias primas, los productos sin terminar y

los ya terminados. Determinacin del nivel ptimo de
reaprovisionamiento.
Planificacin de la capacidad de produccin ptima para no saturar el

almacn.
Nivel estratgico:
Decisiones estratgicas de la alta direccin general.
Otros Subsistemas.
Sistemas de automatizacin de oficinas (ofimtica): conjunto de

ayudas necesarias para realizar el trabajo esencial de oficina.
Constituyen sistemas bsicos de infraestructura comn a distintas
unidades organizativas, son sistemas transversales ya que afectan a
varios departamentos.
Sistemas de produccin: incluyen la automatizacin de fabricacin y

las ayudas para el diseo y puesta en produccin de productos.
Pueden abarcar el control de calidad, de herramientas y el
mantenimiento del equipo de fabricacin.
DESARROLLO DE APLICACIONES INFORMTICAS

Ciclo de Vida de un sistema
La Ingeniera del Software est formada por una serie de pasos que abarcan
los mtodos, herramientas y procedimientos. Estos pasos se denominan
Paradigmas de la Ingeniera del Software.
La norma IEEE 1074 entiende por ciclo de vida del software "una
aproximacin lgica a la adquisicin, el suministro, el desarrollo, la
explotacin 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 explotacin y el mantenimiento de un producto software,
abarcando la vida del sistema desde la definicin de los requisitos hasta la
finalizacin de su uso".
En resumen, el ciclo de vida es una sucesin de etapas por las que
atraviesa un producto software a lo largo de su desarrollo y existencia.
34

MIGUEL DE CERVANTES
La eleccin de un Paradigma concreto se realiza de acuerdo con la

naturaleza del proyecto y de la aplicacin, de los mtodos y herramientas
disponibles, y de tener los controles y entregas adecuadas.
Existen varios paradigmas, los ms conocidos son:
1. Ciclo de Vida Clsico.
2. Ciclo de Vida Clsico con Prototipado.
3. Modelo en Espiral.
4. RAD (Rapid Application Development). Desarrollo Rpido de Aplicaciones.
5. Paradigma Orientado a Objetos.
VISIN INTEGRADA DE LA INGENIERA DEL SOFTWARE
Independientemente del paradigma que se utilice, del rea de aplicacin, y
del tamao y la complejidad del proyecto, el proceso de desarrollo de
software contiene siempre una serie de fases genricas, existentes en todos
los paradigmas. Estas fases son la definicin, el desarrollo y el
mantenimiento.
Definicin.
La fase de definicin se centra en el qu (qu hacer?). Durante esta fase,
se intenta identificar:
Qu informacin es la que tiene que ser procesada
qu funcin y rendimiento son los que se esperan
qu restricciones de diseo existen
qu interfaces deben utilizarse.
qu lenguaje de programacin, sistema operativo y soporte hardware

van a ser utilizados.
qu criterios de validacin 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 realizarn tres tareas especficas:
Anlisis del sistema.
Define el papel de cada elemento de un sistema informtico, estableciendo
cul es el papel del software dentro de ese sistema.
Anlisis de requisitos del software.
El mbito establecido para el software proporciona la direccin a seguir, pero
antes de comenzar a trabajar desarrollar es necesario hacer una definicin
35

MIGUEL DE CERVANTES
ms detallada de la funcin del software. Con esta fase, se pretenden

obtener modelos conceptuales detallados de las estructuras de datos y de
los procedimientos que para su gestin les son aplicables.
El anlisis y definicin de los requisitos es una tarea que debe llevarse a
cabo conjuntamente por el desarrollador de software y por el cliente. La
especificacin de requisitos del software es el documento que se produce
como resultado de esta etapa.
Planificacin del proyecto software.
Durante esta etapa se lleva a cabo el anlisis de riesgos, se definen los
recursos necesarios para desarrollar el software y se establecen las
estimaciones de tiempo y costes. El propsito de esta etapa de planificacin
es proporcionar una indicacin preliminar de la viabilidad del proyecto de
acuerdo con el coste y con la agenda que se hayan establecido.
Posteriormente, la gestin del proyecto durante el desarrollo del mismo
realiza y revisa el plan de proyecto de software.
Desarrollo.
La fase de definicin se centra en el cmo (cmo hacerlo).
Cmo ha de ser la arquitectura de la aplicacin.
Cmo han de ser las estructuras de datos.
Cmo han de implementarse los detalles procedimentales de los

mdulos.
Cmo van a ser las interfaces.
Cmo ha de traducirse el diseo a un lenguaje de programacin.
Cmo van a realizarse las pruebas.
Aunque, al igual que antes, los pasos concretos dependen del modelo de
ciclo de vida utilizado, en general se realizarn cuatro tareas especficas:
Diseo.
El diseo del software traduce los requisitos a un conjunto de
representaciones (grficas, en forma de tabla o basadas en algn lenguaje
apropiado) que describen cmo van a estructurarse los datos, cul va a ser
la arquitectura de la aplicacin, cul va a ser la estructura de cada programa
y cmo van a ser las interfaces. Es necesario seguir criterios de diseo que
nos permitan asegurar la calidad del producto.
Una vez finalizado el diseo es necesario revisarlo para asegurar la
36

MIGUEL DE CERVANTES
completitud y el cumplimiento de los requisitos del software.

Codificacin.
En esta fase, el diseo se traduce a un lenguaje de programacin, dando
como resultado un programa ejecutable. La buena calidad de los programas
desarrollados depende en gran medida de la calidad del diseo.
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 diseo.
El listado fuente de cada mdulo (o el programa fuente en soporte
magntico) pasa a formar parte de la configuracin del sistema.
Pruebas.
Una vez que tenemos implementado el software es preciso probarlo, para
detectar errores de codificacin, de diseo o de especificacin. Las pruebas
son necesarias para encontrar el mayor nmero posible de errores antes de
entregar el programa al cliente.
Es necesario probar cada uno de los componentes por separado (cada uno
de los mdulos o programas) para comprobar el rendimiento funcional de
cada una de estas unidades.
A continuacin 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
especificacin.
Se puede desarrollar un plan y procedimiento de pruebas y guardar
informacin sobre los casos de pruebas y los resultados de las mismas.
Garanta 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 correccin 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
definicin y de desarrollo, pero en el contexto de un software ya existente y
en funcionamiento.
37

MIGUEL DE CERVANTES
INGENIERA INVERSA Y REINGENIERA DEL SOFTWARE.

Ingeniera Inversa:
Para aquellos proyectos software desarrollado sin tener en cuenta las
metodologas estructuradas de anlisis y diseo, es muy til aplicar tcnicas
de ingeniera inversa, las cuales permiten obtener los documentos de
anlisis y diseo pertinentes que permitan conocer la estructura interna de la
aplicacin.
Reingeniera:
Si tenemos herramientas que son capaces de desarrollar una aplicacin a
partir del anlisis de la misma, podemos aplicarlas a partir del producto
obtenido de efectuar la ingeniera inversa a proyectos de software
desarrollados sin tener en cuenta las metodologas estructuradas de anlisis
y diseo. En teora, el resultado que se obtendr ser un proyecto de
software realizado segn los postulados del anlisis estructurado y que
soluciona el problema que desarrollaba el producto original.
METODOLOGAS DE DESARROLLO
1.- INTRODUCCIN.
1.1.- Conceptos generales.
Para desarrollar un proyecto software es necesario establecer un enfoque
disciplinado y sistemtico. Las metodologas de desarrollo, que influyen
directamente en este proceso de construccin, se elaboran a partir del
marco definido por uno o varios ciclos de vida.
Pero, qu entendemos por metodologa?.
Hay que destacar, ante todo, que no hay un consenso entre los distintos
autores sobre el concepto de metodologa y, por lo tanto, no existe una
definicin universalmente aceptada. S hay un acuerdo en considerar a la
metodologa como un conjunto de pasos y procedimientos que deben
seguirse para el desarrollo de software.
Una definicin representativa del concepto podra ser la de [MADDISON,
1983], que define Metodologa como un conjunto de filosofas, fases,
procedimientos, reglas, tcnicas, herramientas, documentos y aspectos de
formacin para los desarrolladores de sistemas de informacin.
Segn esto, una metodologa es un conjunto de componentes que
especifican:
Cmo se debe dividir un proyecto en etapas.
Qu tareas se llevan a cabo en cada etapa.
Qu salidas producen y cuando se deben producir.
38

MIGUEL DE CERVANTES
Qu restricciones se aplican.
Qu herramientas se van a utilizar.
Como se gestiona y controla un proyecto.
Atendiendo a una definicin ms genrica, podemos considerar una
metodologa de desarrollo como un conjunto de procedimientos, tcnicas,
herramientas, y un soporte documental que ayuda a los desarrolladores a
realizar nuevo software. Normalmente consistir en un conjunto de fases
descompuestas en subfases (mdulos, etapas, pasos,...). Esta
descomposicin del proceso de desarrollo gua a los desarrolladores en la
eleccin de las tcnicas que debe elegir para cada estado del proyecto, y
facilita la planificacin, gestin, control y evaluacin de los proyectos. Una
metodologa, por tanto, representa el camino para desarrollar software de
una manera sistemtica.
Necesidades principales que se intentan cubrir con una metodologa:
Mejores aplicaciones: el seguimiento de una metodologa 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 ms rpidamente y con los recursos
apropiados.
Un proceso estndar en la organizacin: lo que aporta claros

beneficios.
Entre los objetivos tenemos que:
Registrar los requisitos de un sistema de informacin de forma

acertada.
Proporcionar un mtodo sistemtico de desarrollo de forma que se

pueda controlar su progreso.
Construir un sistema de informacin dentro de un tiempo apropiado y

unos costes aceptables.
Construir un sistema que est bien documentado y que sea fcil de

mantener.
Ayudar a identificar lo ms pronto posible cualquier cambio que sea

necesario realizar dentro del proceso de desarrollo.
39

MIGUEL DE CERVANTES
Proporcionar un sistema que satisfaga a todas las personas

afectadas por el mismo, ya sean clientes, directivos, auditores o
usuarios.
La descomposicin 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 ms productos. El sistema deseado est constituido por un
conjunto de productos finales.
Para aplicar un procedimiento se pueden utilizar una o ms tcnicas grficas
con apoyos textuales formales y determinan el formato de los productos
resultantes de cada tarea.
Para la realizacin de una tcnica podemos apoyarnos en las herramientas
software que automatizan su aplicacin. Algunas herramientas dan soporte
especfico a una metodologa, otras son de propsito ms general.
Una metodologa 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 metodologa indicara el cmo.
1.2.- Visin histrica del desarrollo de metodologas de desarrollo de
sistemas de informacin.
1.2.1.- Desarrollo convencional.
El desarrollo convencional se basaba en funciones bsicas de procesos de
datos. Los programadores estaban ms enfocados en las tareas de codificar
que en la de recoger y comprender las necesidades de los usuarios. Se
observ que haba ms de un papel en el proceso de desarrollo de
sistemas: operadores, programadores y analistas de sistemas (funcionales y
tcnicos u orgnicos).
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.

40

MIGUEL DE CERVANTES
Sigue unos mtodos de ingeniera, dirigidos a aspectos tanto tcnicos como

de gestin en la construccin de software. Tiene los siguientes conceptos
asociados:
Programacin estructurada.
Diseo estructurado.
Anlisis estructurado.
1.2.3.- Desarrollo orientado al objeto.

El paradigma orientado a objetos trata los procesos y los datos de forma
conjunta. La orientacin a objetos empieza con los lenguajes de
programacin orientados a objetos. En estos lenguajes se daba nfasis a la
abstraccin 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.- CARACTERSTICAS PRINCIPALES DE LAS METODOLOGAS.
2.1.- Impacto de la metodologa en el entorno de desarrollo de
software.
Todo entorno de desarrollo incluye un conjunto de componentes que
condicionan la construccin 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 metodologa de desarrollo
influye muy directamente en estos dos factores.
Dentro de este entorno, la organizacin mantiene a un equipo de desarrollo
de software. Los procedimientos de gestin determinan el tipo de soporte
automatizado, hardware y software. Los procedimientos de gestin
coordinan y guan a los desarrolladores en el empleo de las tcnicas. El
soporte automatizado mejora la productividad automatizando diversas tareas
y verificando su correcta realizacin. No todos los resultados pueden ser
verificados de forma automatizada. Es necesaria la realizacin de revisiones
manuales. Todos los entornos de desarrollo de software tienen formas de
trabajo muy diferentes. La organizacin de desarrollo tiene dos opciones:
Seleccionar entre un gran nmero de posibilidades y combinaciones de
mtodos de gestin, tcnicas de desarrollo y soporte automatizado, para
crear y desarrollar la metodologa de desarrollo software ms apropiado.
Analizar y evaluar metodologas existentes y adoptar en la organizacin la
41

MIGUEL DE CERVANTES
que ms se ajuste a sus necesidades. Esta es la ms comn.

2.2.- Caractersticas deseables en una metodologa.
Existencia de reglas predefinidas: que definan sus fases, tareas,

productos intermedios, tcnicas, herramientas, ayudas al desarrollo y
formatos de documentacin estndar.
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 correccin. 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 aceptacin
o durante la fase de mantenimiento.
Planificacin y control: una forma de desarrollar software de manera

planificada y controlada para que no se disparen los costes ni se
amplen los tiempos de entrega.
Comunicacin efectiva: entre los desarrolladores para facilitar el

trabajo en grupo y con los usuarios.
Utilizacin sobre un abanico amplio de proyectos: debe ser flexible.

No se deberan utilizar metodologas diferentes para cada proyecto.
Fcil formacin: los desarrolladores deben comprender las tcnicas y

los procedimientos de gestin.
Herramientas CASE: debe estar soportada por herramientas

automatizadas que mejoren la productividad del equipo de desarrollo
y la calidad de los productos resultantes.
La metodologa debe contener actividades que mejoren el proceso de

desarrollo: es necesario disponer de datos que muestren la
efectividad de la aplicacin 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 reingeniera del software

42

MIGUEL DE CERVANTES
debera ser tomado en cuenta por las metodologas para facilitar las
modificaciones sobre los sistemas existentes.
Soporte de la reutilizacin del software: las metodologas

estructuradas existentes no proporcionan mecanismos para la
reutilizacin de componentes software. Se deberan incluir
procedimientos para la creacin, mantenimiento y recuperacin de
componentes reutilizables que no se limiten slo al cdigo.
3.- CLASIFICACIN DE LAS METODOLOGAS.

3.1.- Metodologas estructuradas.
Proponen la creacin de modelos del sistema que representan los procesos,
los flujos y la estructura de los datos de una manera descendente (topdown), tanto en las funciones del sistema, en la estructura de los datos o a
ambos aspectos dando lugar a metodologas orientadas a procesos,
orientadas a datos y mixtas.
Mecanismos para el anlisis:
Flujo de datos.
Estructura de datos.
Mecanismos de subdivisin: cada metodologa aplica un criterio diferente de

descomposicin, y se apoya en elementos grficos distintos.
Proceso.
Estructura de datos.
Tendencias principales:
Metodologas orientadas a PROCESOS (FLUJO DE DATOS.)
Metodologas orientadas a ESTRUCTURAS DE DATOS.
3.1.1.- Metodologas orientadas a procesos (flujo de datos).

La ingeniera del software est fundamentada sobre el modelo bsico de
entrada/proceso/salida de un sistema. Los datos se introducen en el sistema
y el sistema responde ante ellos transformndolos para obtener las salidas.
Una especificacin estructurada es un modelo grfico, particionado,
43

MIGUEL DE CERVANTES
descendente y jerrquico de los procesos del sistema y de los datos

utilizados por los procesos.
Estas metodologas enfocan el criterio de descomposicin que emplean al
concepto de Proceso.
Las herramientas asociadas a estas metodologas son:
Diagramas de flujo de datos. (DFD).
Diagramas de Entidad-Relacin. (Definicin de almacenes de datos

para el DFD).
Diccionario de datos.
Descripciones funcionales.
o Lenguaje natural estructurado.
o Tablas de decisin.
Diagramas de flujos de datos (DFD).

Son diagramas que representan los procesos (funciones) que debe llevar a
cabo un sistema a distintos niveles de abstraccin y los datos que fluyen
entre los procesos. Los procesos ms complejos se descomponen en
nuevos diagramas hasta llegar a los procesos sencillos. Es la tcnica ms
importante del anlisis estructurado, y se emplea en todas las metodologas
de anlisis y diseo estructurados.
Diagrama de entidad-relacin.
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 informacin usando una notacin casi-formal
(notacin regular) tomada de la
Teora de Lenguajes Formales.
Los datos compuestos se definen en funcin de sus componentes.
Para composicin de datos se usan como mecanismos: la secuencia, la
44

MIGUEL DE CERVANTES
seleccin y la agrupacin repetida (multiconjunto).

Construccin de datos
Notacin
Significado
Secuencia
Seleccin
Repeticin
=
+
[ ]
{ }n
( )
Esta compuesto de
Y
Uno u otro
n repeticiones de
Datos opcionales
Especificaciones de proceso:
En este apartado se incluyen la definicin de las operaciones, describiendo
con ms detalle lo que ocurre dentro de un proceso, es decir, definen cmo
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-cdigo imperativo, un ingles o
castellano estructurado. Los mecanismos de estructuracin son: la
secuencia, la seleccin y la repeticin.
Ejemplos de metodologas orientadas al flujo de datos de:
Yourdon / de Marco.
(Anlisis Estructurado)
Gane / Sarson
(A. y Diseo Estructurado)
Yourdon / Myers /Constantine (Diseo Estructurado)
Page / Jones
(Diseo Estructurado)
Ejemplo: Metodologa de Yourdon/Constantine:
Realizar los DFD del sistema.
Realizar el diagrama de estructuras, obtenindolo a partir de los

DFD's mediante dos tcnicas, al anlisis de transformacin y el
anlisis de transaccin.
Evaluacin del diseo, midiendo la calidad de la estructura resultante

mediante el acoplamiento y la cohesin.
Preparacin del diseo para la implantacin (cuadernos de carga).
3.1.2.- Metodologas orientadas a ESTRUCTURAS DE DATOS.

Tambin llamadas metodologas dirigidas por los datos.
45

MIGUEL DE CERVANTES
Estas metodologas toman como base la idea de que los datos, adems de
fluir y tener un contenido, tienen una estructura. As, el criterio de
descomposicin es la estructura de datos.
Los datos constituyen el corazn del sistema de informacin, son ms
estables que los procesos que actan sobre ellos. El estudio de los procesos
viene derivado de una definicin inicial de los datos (modelo de datos)
constituido por el conjunto de entidades de datos bsicas y las
interrelaciones entre ellas.
Como ejemplos de metodologas orientadas a la estructura de datos
tenemos las metodologas de:
DSED Warnier / Orr.
(Anlisis de entradas y salidas)
JSD Jackson
(Anlisis de entradas)
SADT
Entidad-Relacin.
Caractersticas comunes a estas metodologas:
Se identifican entidades y procesos.
Se presupone una estructura jerrquica en los datos. (Si no lo es, se

fuerza el mtodo).
Se representa la estructura de los datos usando la secuencia, la

seleccin y la repeticin.
Se definen mtodos para transformar una estructura de datos

jerrquica en una estructura de programa.
3.3.3.- Defectos de las metodologas estructuradas.
No dan respuesta fcil 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 ocultacin de

informacin.
3.2.- Metodologas orientadas a objetos.

Cobra mucha ms importancia el aspecto de modelado del sistema,
examinando el dominio del problema como un conjunto de objetos que
interactan entre s. Tenemos dos enfoques en las metodologas orientadas
al objeto:
46

MIGUEL DE CERVANTES
Revolucionarios o puros: que entienden la orientacin al objeto como un

cambio profundo que convierten a las metodologas estructuradas en
obsoletas.
Sintetistas o evolutivos: que piensan que el anlisis y diseo estructurado
constituyen la base para el desarrollo orientado al objeto, pudindose
combinar elementos del anlisis y diseo estructurado con los de orientacin
a l objeto.
3.3.- Sistemas en tiempo real.
Son sistemas muy dependientes del tiempo que procesan informacin
orientada al control. Controlan y son controlados por eventos externos. Se
caracterizan porque:
Se lleva a cabo el proceso de muchas actividades de forma

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

de mayor prioridad.
Existe comunicacin entre tareas.
Existe acceso simultneo a datos comunes.
Para especificar los requisitos de estos sistemas hay que incluir nuevos
conceptos para:
El manejo de interrupciones.
La comunicacin y sincronizacin entre tareas.
Gestionar procesos concurrentes.
Dar respuesta oportuna y a tiempo ante eventos externos.
Datos continuos o discretos.
3.4.- Comparacin entre Metodologas Estructuradas y Orientadas a

Objetos.
47

MIGUEL DE CERVANTES
Estructuradas
Orientadas a Objetos
Para representar un modelo del mundo

real, se requiere una transformacin del
espacio del problema
Correspondencia directa con los

objetos del mundo real.
El Diseo se encuentra muy influenciado

por el criterio de descomposicin.
Se tratan datos y procesos con el

mismo nivel de abstraccin.
Cada mdulo modela una funcin o un

paquete de datos
Cada mdulo 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 metodologas de desarrollo europeas

4.- PRINCIPALES METODOLOGAS DE DESARROLLO.
4.1.- Metodologa MERISE.
Esta metodologa surge en Francia en 1977 a propuesta del Ministerio de
Industria, como un intento de unificar criterios en torno a la metodologa de
desarrollo para los sistemas informticos de la Administracin Pblica
Francesa.
Sus principios generales son:
Desglose en etapas: estudio preliminar, estudio detallado, realizacin

y puesta en marcha.
Divisin en el estudio de los tratamientos por un lado y el estudio de

los datos por otro.
Uso del modelo Entidad/Relacin y sus formalismos para representar

los datos.
48

MIGUEL DE CERVANTES
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 explotacin. (Esquema director)
NIVEL
TRATAMIENTOS DATOS
OPCIN
CONCEPTUAL
Modelo
Conceptual
De gestin
Modelo
Conceptual
ORGANIZACIONAL Modelo
Modelo Lgico De
Organizacional
organizacin
OPERACIONAL
Modelo
Operacional
Modelo Fsico
Tcnica
4.2.- Metodologa SSADM. (Mtodo Estructurado de Anlisis y Diseo

de Sistemas).
Aparece en Gran Bretaa por los mismos motivos que MERISE y se
establece como obligatoria para la Administracin Pblica a partir de 1983.
Los aspectos claves de esta metodologa son:
nfasis en los usuarios: sus requisitos y participacin.
Definicin del proceso de produccin.
Tres puntos de vista: datos, eventos y procesos.
Mxima flexibilidad en herramientas y tcnicas de implementacin.
SSADM proporciona un conjunto de procedimientos para llevar a cabo el

anlisis y diseo, pero no cubre aspectos como la planificacin estratgica ni
entra en la construccin del cdigo.
4.3.- Metodologa MTRICA. Versin 3.
Ministerio para la Administraciones Pblicas. Consejo Superior de
Informtica. Proyecto Mtrica Versin 3. Metodologa de planificacin y
desarrollo de Sistemas de Informacin, 2000.
49

MIGUEL DE CERVANTES
Disponible en:
http://www.map.es/csi/metrica3/index.html
Es la metodologa adoptada como estndar por la Administracin Pblica

Espaola. Consiste en un conjunto de fases donde se utilizan multitud de
tcnicas conducentes a la obtencin de aplicaciones de calidad, fciles de
mantener y muy bien documentadas.
4.3.1.- Objetivos de Mtrica versin 3.
La metodologa MTRICA Versin 3 ofrece a las Organizaciones un
instrumento til para la sistematizacin 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 Informacin que sirvan a la

consecucin de los fines de la Organizacin mediante la definicin de
un marco estratgico para el desarrollo de los mismos.
Dotar a la Organizacin de Productos software que satisfagan las

necesidades de los usuarios dando una mayor importancia al anlisis
de requisitos.
Mejorar la productividad permitiendo una mayor capacidad de

adaptacin a los cambios y teniendo en cuenta la reutilizacin en la
medida de lo posible.
Facilitar la comunicacin y entendimiento entre los distintos

participantes en la produccin de software a lo largo de todo el ciclo
de vida.
Facilitar la operacin, mantenimiento y uso de los Productos software

obtenido.
4.3.2.- Caractersticas.
MTRICA Versin 3 contempla el desarrollo de Sistemas de

Informacin para las distintas tecnologas que actualmente estn
conviviendo y los aspectos de gestin que asegurarn que un
50

MIGUEL DE CERVANTES
Proyecto cumple sus objetivos en trminos de calidad y coste.
Su punto de partida es la versin anterior de MTRICA 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 elaboracin de MTRICA Versin 3 se han tenido en cuenta los

mtodos de desarrollo ms extendidos, as como los ltimos
estndares de ingeniera del software y calidad, as como referencias
especficas en cuanto a seguridad y gestin de proyectos.
4.3.3.- Estructura de Mtrica V3.

En una nica estructura la metodologa MTRICA Versin 3 cubre distintos
tipos de desarrollo: estructurado y orientado a objetos, y facilita a travs de
interfaces la realizacin 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 tcnicas y prcticas a utilizar.
Los responsables de realizarla.
Sus productos de entrada y salida.
Estructura de procesos:
Planificacin PSI
Desarrollo
Estudio de viablidad EVS
Anlisis ASI
Diseo DSI
51

MIGUEL DE CERVANTES
Construccin CSI
Implantacin y aceptacin IAS
Mantenimiento MSI
Interfaces
Aseguramiento de la Calidad
Seguridad
Gestin de Configuracin
Gestin de Proyectos
Anlisis de necesidades y estudio de viabilidad

Cmo comienza un proyecto.
52

MIGUEL DE CERVANTES
La Ingeniera del Software, trmino 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 segn Alan Davis como "la aplicacin inteligente de principios
probados, tcnicas, lenguajes y herramientas para la creacin y mantenimiento,
dentro de un coste razonable, de software que satisfaga las necesidades de los
usuarios".
La necesidad de aplicar los principios de otras ingenieras 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
situacin 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 mayora 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, estn relacionadas directamente
con la correcta identificacin y gestin de los requisitos que deban cumplir las
aplicaciones desarrolladas para satisfacer las necesidades de los usuarios.
Por tanto, la primera etapa dentro de la concepcin de un sistema informtico
consiste en entender y representar de un modo apropiado los requisitos de
usuario. Este proceso recibe el nombre de ingeniera 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 deteccin
hasta la etapa de operacin, provocando fallos con serias consecuencias sobre
todo en sistemas crticos.
Estos errores producidos en la etapa de extraccin o licitacin de requisitos estn
provocados principalmente por el gap existente entre los usuarios y el proceso de
desarrollo
1. Actividades iniciales.
53

MIGUEL DE CERVANTES
Un proyecto es esencialmente un conjunto de actividades interrelacionadas, con

un inicio y una finalizacin 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
metodologa y en principio, cualquier metodologa 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 lgica de las actividades se debe
establecer el mtodo, el tiempo y el costo de cada operacin.
Los recursos son los elementos utilizados para poder realizar la ejecucin 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 mltiples actividades y una gran cantidad de recursos para
poder alcanzarlo.
Independientemente de su complejidad, caractersticamente todo proyecto rene
la mayora de los siguientes criterios:
Tener un principio y un fin
Tener un calendario definido de ejecucin
Plantearse de una sola vez
Constar de una sucesin de actividades o de fases
Agrupar personas en funcin de las necesidades especficas 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 adems
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
54

MIGUEL DE CERVANTES
organizaciones, incluidos los proyectos informticos.

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, comprensin
tcnica, competencia en la gestin, presteza y decisin, versatilidad y flexibilidad,
integridad, previsin.
Definicin del problema
1.1. Qu es un proyecto informtico?
Los recursos ms frecuentemente utilizados que caracterizan a un sistema de informac

son los componentes de la Tecnologa de la Informacin (TI) como el uso de hardw
software y comunicaciones.
Considerando la importancia que la informtica tiene en los planes estratgicos de cualq

empresa moderna; no solamente se debe tener en cuenta la evolucin de los recursos d
tecnologa de la informacin, sino tambin las distintas metodologas para el desarrollo
los sistemas de informacin.
As pues, el solo hecho de considerar a un asunto informtico como un proyecto al que

asocian tcnicas y procedimientos de diseo, supone un paso importante.
Un proyecto informtico es un sistema de cursos de acciones simultneas y/o secuenci

que incluye personas, equipamientos de hardware, software y comunicaciones, enfoca
en obtener uno o ms resultados deseables sobre un sistema de informacin.
Siendo que los diferentes Sistemas de Informacin abordan los diferentes tipos
problemas organizacionales; podemos clasificar a los Sistemas de Informacin segn s
las aplicaciones que necesite cada usuario en: Sistemas de Transacciones, Sistemas
Soporte para la toma de decisiones, y Sistemas Expertos.
55

MIGUEL DE CERVANTES
1.2. Inicio de un proyecto informtico

El inicio de un proyecto informtico generalmente viene dado en la solicitud de u
requisitos o necesidades de los usuarios.
En una empresa u organizacin se plantea la necesidad de un desarrollo software p
satisfacer las necesidades de dar soporte informtico al sistema de informacin o parte de
Si ya se dispone de un entorno informtico estable, la decisin de iniciar un proyecto vi
dada, generalmente, por las necesidades de mantenimiento del software existe
modificaciones requeridas, mejoras o sustitucin por obsolescencia fsica, tecnolgic
competitiva, o por capacidad para nuevos sistemas.
La Modificacin del programa; involucra algo ms que un simple cambio en

programa; involucra un cambio estructural de una entidad. Por ejemplo, un cambio
el nmero de dgitos del cdigo postal, o en el cdigo de zona telefnica. La difere
con el Mantenimiento es el grado de importancia
La Mejora del sistema; es el agregado de capacidades que no formaron parte

sistema de informacin original; por ejemplo cuando en una divisin se implement
sistema de inventarios, este sistema no inclua un mdulo para calcular la fu
demanda de bienes. La inclusin de este sofisticado mdulo de clculo
considerado una mejora del sistema.
El Reemplazo del sistema; ocurre cuando los sistemas de informacin se tor

fsicamente, tecnolgicamente o competitivamente obsoletos. Como es el caso d
utilizacin del lser, en el reconocimiento ptico de caracteres para la lectura
cdigo de barras, remplazando a la entrada por teclado.
La Nueva Capacidad del sistema; son sistemas de informacin para los cuales
es necesario el uso de la automatizacin. Estn dados por la capacidad de po
modelizar la aplicabilidad de nuevos sistemas. Un ejemplo de ello, es la aplicacin
los sistemas expertos.
Una vez tomada la decisin de emprender el proyecto deben seguirse unas tcnicas
recogida de informacin sobre el proyecto, implicando a los directivos nivel alto/medio.
El resultado de los estudios previos se suelen recoger en un documento llamado informe

necesidades.
56

MIGUEL DE CERVANTES
A continuacin se realiza el estudio de la viabilidad del proyecto (Anlisis de factibilidad)

Propuesta de soluciones alternativas
1.3. Estudio de viabilidad
En la prctica, 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 realizacin del anlisis de viabilidad exige bastante experiencia y
supone un proceso de estudio donde pueden encontrarse las siguientes
fases:
Estudiar la solicitud del proyecto y establecer el alcance y los lmites

del sistema.
Estudiar la situacin actual, describiendo y valorando los actuales

sistemas de informacin e identificando a usuarios y personas
involucradas o afectadas por el proyecto.
Realizar una definicin preliminar de los requisitos, catalogando y

especificando los mismos, as como las directrices tcnicas o de
gestin que puedan influir en el proyecto.
Estudiar y especificar las diferentes alternativas de solucin 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
peticin de propuestas, seleccionar uno de los ofertantes y
supervisar los resultados mediante un control de aceptacin
del producto [ISO, 1995].
o Automatizar slo parcialmente el sistema para reducir
gastos.
Evaluar cada una de las alternativas, incluyendo:
57

MIGUEL DE CERVANTES
o Viabilidad econmica. (Los beneficios compensan los

costes?).
o Tcnica. (Se encuentra disponible la tecnologa necesaria?)
o Legal. (Se atenta contra alguna ley o reglamento? p.e.
LOPD, Ley Orgnica de Proteccin de Datos)
o Operativa. (Puede coordinarse con los mtodos
existentes? Encaja en la filosofa de la empresa?)
ya
o Plazos y calendarios: determinar si el plazo es realista, las

fechas apropiadas.
Seleccionar y aprobar la alternativa ms apropiada.
Es posible que despus de analizar la viabilidad del proyecto, ste se

desestime. Hay que tener en cuenta que el dinero que ya se ha invertido
en el anlisis de viabilidad no debera condicionar esta decisin.
Si no se desestima, realizaremos una especificacin detallada de la
alternativa seleccionada, estableciendo fechas y compromisos de trabajo
por parte de las personas y departamentos implicados, es decir, la
definicin de un plan inicial del proyecto.
1.4. Anlisis de Coste-Beneficio.
El anlisis de coste-beneficio permite seleccionar la alternativa ms
beneficiosa de entre varios proyectos y prever las necesidades financieras.
La mayor fuerza de un anlisis 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 (estimndolo), sino que nos permite
hallar su tasa de rendimiento o, alternativamente, el volumen de ganancia
social que reportara. Comparando rendimientos, puede elegirse el
proyecto al que ms eficientemente podemos dedicar los siempre escasos
recursos de que disponemos.
Los pasos habituales a seguir en la elaboracin de un anlisis costebeneficio son:
1. Definir con claridad el cambio a valorar (nueva situacin respecto a
la evolucin esperada del status quo)
58

MIGUEL DE CERVANTES
2. Identificar los principales costes y beneficios esperados

3. Decidir el ao de referencia del anlisis (generalmente el periodo
inicial, cero), el ao del periodo inicial y el ao del periodo final (si
como es habitual se toma el ao como unidad temporal de medida)
4. Decidir si se van a utilizar valores constantes o nominales. Los ms
frecuente es utilizar valores constantes (tambin llamados reales),
referidos al ao de referencia o periodo inicial
5. Estimar los valores de cada variable para cada periodo (este es el
paso que ms trabajo conlleva)
6. Decidir que tasa de descuento se toma como referencia (en
trminos reales son habituales tasas del 4%, 5%, 6%)
7. Estimar algunos de los indicadores bsicos del anlisis costebeneficio:
Cociente entre Beneficios y Costes (tambin llamado Ratio de

Beneficios y Costes)
Valor Actual Neto (VAN, tambin llamado Valor Presente
Neto)
Tasa Interna de Retorno (TIR, tambin llamada Tasa de
Retorno Interno, TRI)
Primer Periodo de Retorno de la Inversin (tambin llamado
Break-Even Point, entre otros trminos)
8. Realizar un anlisis de sensibilidad con las principales decisiones y

variables utilizadas
9. Emitir un consejo sobre la toma de decisin respecto al cambio o
cambios considerados
A la hora de realizar este anlisis 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
(obtencin de ventajas econmicas por la toma de mejores decisiones,
beneficios competitivos de un mejor entorno de trabajo,)
En general, los datos recopilados para el anlisis de coste-beneficio se
suelen presentar en forma de tabla. Siguiendo a (Piattini, 2006), en las
columnas aparecern los aos de vida del proyecto y en las filas los
distintos conceptos de gasto y beneficio del proyecto.
59

MIGUEL DE CERVANTES
Entre los costes que hay que tener en cuenta destacan:
Personal
Informtico
Consultora
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
produccin.
Ahorro de material, recursos externos, etc.
Beneficios financieros.
Intangibles: incremento de calidad, reduccin de errores, mejora de

imagen, mayor fiabilidad, etc.
ventas,
resultados
disminucin
coste
de
Para un anlisis eficaz de coste-beneficio conviene resaltar que la mayora

de las estimaciones de costes y beneficios suelen consistir en rangos de
valores probables. Tomada la decisin de continuidad del proyecto no se
puede pretender mayor precisin en esta etapa de decisin. A medida que
avanza el proyecto podr refinarse el anlisis econmico, pero la decisin
de realizarlos est ya tomada.
Por tanto, es recomendable hacer estimaciones conservadoras, tratando
de valorar y prever todos los riesgos.
Seleccin de una alternativa
60

MIGUEL DE CERVANTES
2. Tcnicas de recogida de informacin

Normalmente los tcnico de desarrollo de software no conocen todos los
detalles del trabajo de la empresas para la cual van a desarrollar la
aplicacin. Por otra parte los usuarios no saben que informacin es
necesaria o relevante para el desarrollo de una aplicacin. Para facilitar la
comunicacin de ambos colectivos en el proceso de anlisis de
necesidades, se recurre a tcnicas de comunicacin y recopilacin de
informacin.
En general, el proceso de anlisis debera seguir los siguientes pasos:
Identificar las fuentes de informacin relevantes para el proyecto y

planificar las actividades de investigacin.
Realizar las
necesidades.
Analizar la informacin 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 especificacin

apropiado.
preguntas
apropiadas
para
comprender
sus
Por tanto, el resultado del proceso ser la obtencin del documento de

especificacin de requisitos.
Las tcnicas principales utilizadas para la recogida de informacin son las
siguientes:
Entrevistas.
Desarrollo conjunto de aplicaciones Joint Application Design

(JAD).
Prototipado. Construccin de una maqueta o modelo.
Observacin. Analizar in situ la empresa del cliente.
Estudio de documentacin. los documentos que describen el

negocio, desde planes estratgicos hasta manuales de operacin o
de procedimientos, as como muestras de impresos u otros
61

MIGUEL DE CERVANTES
documentos de trabajo para conocer los datos que se manejan.
Cuestionarios. tiles para recopilar informacin de un gran nmero

de personas en poco tiempo.
Tormenta de ideas (Brainstorming). Reuniones de 4 a 10 personas,

usuarios o tcnicos, donde se identifican un primer conjunto de
requisitos en aquellos casos en los que no estn muy claras todas
las necesidades.
2.1. Entrevistas
Una entrevista se puede definir como un intento sistemtico de recoger
informacin
de otra persona a travs de una comunicacin
interpersonal que se lleva a cabo por medio de una conversacin
estructurada.
El aspecto ms destacable radica en la preparacin de la entrevista como
esencia para cumplir sus objetivos.
A continuacin se resumen las diferentes fases que se pueden distinguir en
una entrevista.
Preparacin. el entrevistador deber documentarse e investigar la

situacin de la organizacin, analizando los documentos,
programas, ficheros de la empresa. Preparar el objetivo y el
contenido de la entrevista y planificar lugar y hora.
Realizacin. Se distinguen tres etapas en el acto de la entrevista:

apertura, desarrollo y terminacin.
o En
el
desarrollo
pueden
emplearse
distintas
tcnicas: Preguntas abiertas, directas y/o cerradas, Utilizar
las palabras y frases apropiadas, Asentimiento y Muestras de
Escucha, Repetir las respuestas dadas, Pausas.
Anlisis. Recapitular los resultados obtenidos, reorganizar la

informacin, contrastarla con otras entrevistas o fuentes de
informacin, etc.
2.2. Desarrollo conjunto de aplicaciones JAD

Esta tcnica est basada en la creacin de equipos de usuarios y analistas
que se renen para trabajar conjuntamente en el establecimiento de las
62

MIGUEL DE CERVANTES
necesidades del software a desarrollar.

El JAD se basa en el aprovechamiento de las dinmicas de grupo, ayudas
visuales de comunicacin y comprensin de soluciones, y un proceso de
trabajo sistemtico y organizado.
Las fases que componen un JAD son:
Adaptacin o preparacin. Consiste en la seleccin de los

participantes formada por usuarios y analistas, recabar una cierta
informacin sobre el sistema a desarrollar y organizar la reunin
(varias, de 2 a 4 das) indicando el lugar, fecha, ayudas
audiovisuales, agenda de trabajo y la redaccin de un documento de
trabajo (una especificacin rudimentaria de requisitos sobre los que
se discutir).
Sesin JAD. Las reuniones donde, partiendo de un documento de

trabajo, se analiza para completar el conjunto de requisitos del
sistema. Al final de la sesin se tendr concluido un documento de
especificacin de requisitos, que debe ser aprobado por los
presentes.
Documentacin. En esta fase se procede a reordenar en el formato

adecuado el documento obtenido en la sesin JAD obteniendo el
documento de especificacin de requisitos final
Entrevistas vs. JAD

ENTREVISTAS
JAD
Requieren mucho tiempo

(prepararlas, hacerlas, y
elaborar conjunto coherente de
requisitos a partir de diferentes
entrevistados).
Ms difcil detectar errores

(slo el analista las revisa).
Participacin ms profunda
usuarios (se identifican con el
sistema) Ms difcil llevar a la
prctica.
Requiere ms organizacin.
Empricamente:
o mayor ahorro tiempo,

o mayor satisfaccin de
los usuarios
63

MIGUEL DE CERVANTES
2.3. Prototipado
Consiste en la elaboracin de un modelo o maqueta del sistema con el
objeto de facilitar la evaluacin 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 especificacin de requisitos est bien diseada, que satisface
las necesidades del usuario. Indicar que en este sentido no
encontramos con lenguajes de 4 generacin que aportan capacidad
de prototipado.
Modelos de Rendimiento. Tiene carcter tcnico, por lo que no se

utiliza en requisitos.
Prototipado funcional. Relacionado con los ciclos de vida con

varias iteraciones, el prototipo ser la primera versin del sistema
con funcionalidad limitada, desarrollndolo hasta llegar a la
aplicacin final.
En algunos casos se utiliza el prototipo como un medio para formalizar la

aceptacin previa del cliente de la especificacin de requisitos.
ANLISIS DE REQUISITOS. ANLISIS ESTRUCTURADO. MODELIZACIN
CONCEPTUAL DE FUNCIONES
Introduccin al anlisis de requisitos (A.R.)
3.1 Introduccin al anlisis de requisitos
64

MIGUEL DE CERVANTES
Como ya conocemos, el trmino anlisis aplicado a sistemas significa

descomponer el sistema en sus componentes para estudiar cada uno de
ellos tanto como un ente aislado como en interaccin con el resto de los
componentes.
Para ser til, al anlisis debe seguir un proceso de sntesis que consistir
en unir los componentes del sistema para determinar cmo funcionan en
conjunto.
Cuando se habla de una fase del ciclo de vida, el anlisis consiste en
producir un documento de especificacin de requisitos que describa lo que
el sistema debe hacer, pero no cmo hacerlo. No se trata pues de una
actividad slo de anlisis, sino tambin de sntesis.
Se define el anlisis de requisitos como el proceso del estudio de las
necesidades de los usuarios para llegar a una definicin de los requisitos
del sistema, de hardware o de software, as como el proceso de estudio y
refinamiento de dichos requisitos (Estndar IEEE Std. 610 [IEEE 1990]).
El Requisito es pues una condicin o capacidad que necesita el usuario
para resolver un problema o conseguir un objetivo determinado (por
ejemplo, poder listar rpidamente todos los clientes que deben dinero). Por
extensin, el trmino Requisito se aplica tambin a las condiciones que
debe cumplir o poseer un sistema o uno de sus componentes para
satisfacer un contrato, una norma o una especificacin.
La definicin 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. Ningn colectivo antes citado
puede redactar la Especificacin de Requisitos Software (ERS) ya que:
El cliente no suele conocer el proceso de diseo y desarrollo del

software.
Los analistas no entienden completamente el problema del cliente

dado que no dominan su rea de trabajo.
La fase de anlisis de requisitos, segn el estndar IEEE 1074 [IEEE,

1991] se desglosa en tres grandes actividades:
Definir los requisitos de software. Tarea iterativa para crear una

definicin o especificacin preliminar de los requisitos que debe
cumplir el software a partir de la informacin obtenida mediante
tcnicas de recogida de informacin 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
65

MIGUEL DE CERVANTES
se deben satisfacer para obtener una interaccin eficaz con otros

elementos del sistema (el usuario, el hardware, otras aplicaciones
software,...). En particular la interfaz con el usuario es crtica para la
facilidad de uso (y por tanto el xito) del software.
Los requisitos de interfaz con otras aplicaciones deben describir las
caractersticas 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 caractersticas de las interrelaciones
con elementos hardware.
Integrar los requisitos en un documento de especificacin y

asignarles prioridades. La asignacin de prioridades debe hacerse
en funcin de su importancia o los beneficios que puede aportar su
cumplimiento.
Otra manera de describir las actividades que se realizan en la fase de

anlisis de requisitos sera la siguiente (Raghavan, et al., 1995):
Extraccin o determinacin de requisitos. Proceso mediante el

cual los clientes o futuros usuarios del software descubren, revelan,
articulan y comprenden los requisitos que desean.
Anlisis 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.
Especificacin de requisitos. Proceso de redaccin o registro de

los requisitos. Suele recurrirse a un lenguaje natural, lenguajes
formales, modelos, grficos, etc.
Validacin de los requisitos. Confirmacin, por parte del usuario o

el cliente de que los requisitos especificados son vlidos,
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 anlisis.
3.2. ESPECIFICACIN DE REQUISITOS DEL SOFTWARE
3.2.1. Introduccin
66

MIGUEL DE CERVANTES
Segn el estndar IEEE, 1990 se define:

Especificacin: documento que define, de forma completa, precisa y
verificable, los requisitos, el diseo, el comportamiento u otras
caractersticas de un sistema o de un componente de un sistema
Software: Conjunto de programas, procedimientos y documentacin
asociada a la operacin de un sistema informtico.
Con estas premisas puede definirse la Especificacin de Requisitos del
Software (ERS) como la documentacin de los requisitos esenciales
(funciones, rendimiento, diseo, restricciones y atributos) del software y de
sus interfaces externas [IEEE,1990].
Las dos caractersticas fundamentales de una ERS eficaz son:
Incluir informacin veraz, es decir, coherente con las necesidades

reales del usuario que se desean satisfacer.
Comunicar dicha informacin 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 estndares de ERS particulares

para cada organizacin.
Ventajas de ERS.
Contrato cliente desarrolladores.
Reduccin del esfuerzo de desarrollo.
Base para la estimacin de costes y planificacin.
Punto de referencia para procesos de verificacin y validacin.
Base para posibles mejoras.
Las exigencias para una ERS conducen a no excederse a la hora de

definirla y construirla, sino ms bien a abordar la descripcin de lo que hay
que desarrollar, no el cmo, el cundo, etc., cuando se desarrolla el
67

MIGUEL DE CERVANTES
software. Esto implica:
Describir correctamente todos los requisitos de software sin incluir

requisitos necesarios.
No describir ningn detalle de diseo de software, de su verificacin,

de la direccin del proyecto, excepto las restricciones impuestas al
diseo que influyen en los requisitos.
3.2.2. Caractersticas de una buena Especificacin de Requisitos del

Sistema (ERS)
Las caractersticas 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 utilizacin durante la fase de explotacin y de

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

real.
No ambigua. Cada requisito descrito debe tener una nica interpretacin.
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
vlidos como para los que no lo son.
68

MIGUEL DE CERVANTES
Est conforme con el estndar de especificacin que se deba

cumplir.
Estn etiquetadas y referenciadas en el texto todas las figuras,

tablas y diagramas.
Si algn trmino est por determinar, se debe acompaar de una

descripcin de las condiciones que lo han causado y una posible
descripcin 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 slo s ningn conjunto de requisitos entran en
conflicto entre ellos. Pueden darse tres tipos de conflictos:
Dos o ms requisitos pueden describir el mismo objeto real pero

utilizan trminos distintos para designarlo.
Las caractersticas especificadas de objetos reales pueden estar en

conflicto.
Puede haber conflicto lgico 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 fcil, completa y consistente. Esto implica que la ERS debe:
Tener una organizacin 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

ms 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 documentacin.
Cuando un requisito de la ERS representa un desglose o una derivacin de
otro requisito, se debe facilitar tanto las referencias hacia atrs como las
69

MIGUEL DE CERVANTES
referencias hacia delante en el ciclo de vida. Estas ltimas son

especialmente importantes para el mantenimiento del software. Cuando el
cdigo o la documentacin son modificados, es esencial poder comprobar
el conjunto total de requisitos que pueden verse afectados por estas
modificaciones.
Facilidad de utilizacin durante la fase de explotacin y de
mantenimiento.
La ERS debe considerar las necesidades de mantenimiento, incluyendo
una eventual sustitucin 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 informacin necesaria para

el mantenimiento se dan por supuestos en la organizacin del
desarrollo, pero suelen estar ausentes en la organizacin de
mantenimiento.
3.2.3. Evolucin 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
realizarn 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 ms 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 revisin precisa y completa del rastro de las

modificaciones
Permitir un examen de fragmentos actuales y reemplazados en la

ERS.
70

MIGUEL DE CERVANTES
3.2.4.- Estructura para las ERS

Un modelo propuesto por el estndar IEEE Std. 830 [IEEE, 1984b] es el
que se presenta a continuacin:
71

MIGUEL DE CERVANTES
Existen otras normas emitidas por otros organismos que tambin aportan
esquemas para documentar las ERS (DOD, 1988, DORFMAN y THYER,
1990).
3.2.5. Especificacin 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 anlisis
estructurado, pueden identificarse fcilmente 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 presentacin
de la informacin, listados o salida en papel, ficheros, etc. Las entradas
sern pantallas de introduccin de datos mediante teclado, introduccin de
datos mediante sensores, ficheros, etc.
La definicin de las interfaces de E-S tiene como objetivo la estabilizacin
del modo en que el sistema va a interactuar con el exterior del sistema.
3.3.- Visin general de las tcnicas de especificacin
Sobre la clasificacin de tcnicas de especificacin no existe una regla
general por lo que posiblemente, la forma ms lgica de hacerlo sea por
orden alfabtico. Sin embargo, pueden clasificarse las tcnicas bajo dos
enfoques diferentes:
Por la forma de representacin (grfica, textual, matricial, DFD, DD,

etc.)
Por el enfoque de Modelizacin bajo los que se crean modelos del

sistema relativos a su funcin, informacin y tiempo.
3.31.- Clasificacin segn la forma de representacin
Grficas. Utilizan iconos que representan un componente particular

del modelo. Se usan cuando se quiere resaltar la conexin entre los
distintos componentes del modelo.
Textuales. Se utilizan para especificar con ms detalle los

componentes definidos en los grficos mediante una gramtica
definida ms o menos formal.
Marcos o plantillas. (Templates) especifican informacin relativa a

72

MIGUEL DE CERVANTES
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 caractersticas.
Matriciales. Son tcnicas de comprobacin entre modelos que

permiten estudiar las referencias cruzadas entre sus componentes.
Modelizacin conceptual de datos

Introduccin a las bases de datos. Concepto.
73

MIGUEL DE CERVANTES
1.- INTRODUCCIN.
1.1.- Sistemas de informacin (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 organizacin a la cual sirven la
informacin necesaria para el cumplimiento de sus fines.
Los SI deben cumplir una serie de objetivos a la hora de tratar la
informacin:
Proporcionar la informacin 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 mnimo.
Para llevar a cabo esto, un SI debe realizar una serie de funciones sobre
una coleccin de datos estructurada:
Recoger, procesar y almacenar datos.
Facilitar la recuperacin, elaboracin y presentacin de los datos Componentes
del S.I.
Contenido: los datos, su descripcin y los programas que los

manipulan.
Equipo fsico: el ordenador soporte del sistema de informacin.
Equipo lgico (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 abstraccin.

A la hora de abordar el estudio de un sistema de informacin se utilizan
diversos mtodos de abstraccin, como el enfoque sistmico u holstico,
para simplificar la complejidad de comprensin e interaccin con el sistema
de informacin.
74

MIGUEL DE CERVANTES
En el desarrollo de la abstraccin 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 abstraccin propiamente dicho, del cual se
obtiene un modelo. Utilizaremos cuatro conceptos para la abstraccin:
Entidad, atributo, relacin y restriccin semntica.
Entidad: Cualquier persona, objeto o suceso sobre el cual queremos

guardar informacin.
Atributo: es una propiedad bsica que caracteriza a una entidad.
Relacin: es una asociacin entre una, dos o ms entidades.
Ejemplo: Dada una asignatura, podr ser impartida por varios profesores; y
dado un profesor podr impartir varias asignaturas.
Restriccin semntica: 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.
Restriccin de Entidad: no puede haber dos
profesores con el mismo D.N.I.
Restriccin de Atributo: no puede existir un valor del
salario superior a 200.000.
Restriccin de Relacin: un profesor no puede
impartir ms de 2 asignaturas.
Fase 3. Organizar el conjunto de informacin que hemos definido en la

etapa anterior para almacenarlo en un soporte magntico.
Tenemos dos tipos de tcnicas:
basada en ficheros: es la clsica,
basada en Bases de Datos.
Atendiendo a estas fases de abstraccin, tendremos tres niveles:
75

MIGUEL DE CERVANTES
1.3.- Sistemas de informacin tradicionales. Sistemas de Ficheros.

Los SI tradicionales se organizaban bajo la tcnica de sistemas de ficheros y
surgieron al tratar de informatizar el manejo de los archivadores manuales
con objeto de proporcionar un acceso ms 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 organizacin o empresa, sino que para ello se escogi un modelo
descentralizado en el que cada seccin o departamento almacena y
gestiona sus propios datos.
Podemos clasificar los ficheros en funcin de la forma de organizarse.
Organizacin
ficheros:
de
ficheros:
Operaciones
- Secuencial.
realizadas
sobre
- Insercin.
- Directo.
- Recuperacin.
- Indexados.
- Actualizacin.
- Inversos.
- Borrado
1.3.1.- Caractersticas de los SI usando ficheros.
Para cada tipo de usuarios se desarrollan aplicaciones

independientes. Aparece un conjunto de programas que actan sobre
ficheros de datos.
76

MIGUEL DE CERVANTES
Redundancia: datos comunes que son almacenados dos o ms

veces. Parte de la informacin 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
puede ser diferente en cada fichero, dependiendo de la estructura
fsica de esos ficheros.
La estructura de los datos, el modo de acceso a los datos en funcin

del tipo de fichero donde se almacenan y su localizacin fsica,
forman parte de nuestro programa.
Se pueden crear y modificar sin necesidad de realizar una

planificacin 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, lgicos y limpios, pero

tambin presentan una serie de problemas asociados.
1.3.2.- Inconvenientes de los sistemas de ficheros.
Separacin y aislamiento de los datos. Cuando los datos se

separan en distintos ficheros, es ms 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.
Duplicacin de datos. La redundancia de datos existente en los

sistemas de ficheros hace que se desperdicie espacio de
almacenamiento y lo que es ms 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 fsica de los datos (la

77

MIGUEL DE CERVANTES
definicin de los ficheros y de los registros) se encuentra codificada

en los programas de aplicacin, cualquier cambio en dicha estructura
es difcil 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 caracterstico de los sistemas de
ficheros, se le denomina tambin falta de independencia de datos
lgica-fsica.
Formatos de ficheros incompatibles. Ya que la estructura de los

ficheros se define en los programas de aplicacin, es completamente
dependiente del lenguaje de programacin. La incompatibilidad entre
ficheros generados por distintos lenguajes hace que los ficheros sean
difciles de procesar de modo conjunto.
Consultas
fijas
y
proliferacin
de
programas
de
aplicacin. 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 aplicacin.
En otras organizaciones hubo una proliferacin de programas de

aplicacin 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 recuperacin ante posibles fallos y el control de
autorizacin (no todos los usuarios pueden acceder a un sistema de
informacin o a partes de l (Privacidad)).
2.- Bases de Datos y Sistema de Gestin de Bases de Datos.

2.1.- Objetivo de las Bases de Datos.
El objetivo de las bases de datos es unificar toda la informacin del sistema
para evitar las redundancias, sin perder por ello las diferentes visiones que
poseen los usuarios de esta informacin, manteniendo una independencia
de los datos respecto a las aplicaciones que los utilizan, almacenando datos
de manera ntegra y proporcionando una privacidad de la informacin.
78

MIGUEL DE CERVANTES
2.2.- Definicin de Base de Datos.

Una base de datos es una coleccin de datos estructurados segn 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 definicin y descripcin
que de ellos se posee debe ser nica, estando almacenada junto con los
mismos.
Los tratamientos que se realicen sobre los datos debern garantizar
la integridad y seguridad sobre dichos datos.
2.3.- Sistema de Gestin 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 informticos) definir, crear y mantener la base de datos,
adems de proporcionar acceso controlado a la misma.
Un SGBD se caracteriza por mantener una descripcin actual de la base de
datos, integrando toda la informacin del sistema para evitar redundancias y
sin que se pierdan, por ello, las distintas perspectivas que de la BD tienen
los usuarios (definicin 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 aplicacin sean independientes de los cambios
realizados en datos que no usan o en detalles de representacin
fsica 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 destruccin causada por el
entorno (fuego, inundacin, 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
79

MIGUEL DE CERVANTES
Para cumplir estos objetivos, los SGBD tienen una arquitectura estndar, la
arquitectura de niveles del SGBD.
2.4.- Instancia y Esquema de la Base de Datos.
Las BD cambian a lo largo del tiempo segn se aade y se suprime
informacin. La coleccin de informacin almacenada en un determinado
momento en el tiempo se llama instancia de la BD.
El diseo 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
definicin de tipo en un lenguaje de programacin, 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 abstraccin de la Arquitectura ANSI/SPARC (esquema
conceptual, lgico, fsico y externo).
Arquitectura. Modelos de datos
3.- Arquitectura de un SGBD.

3.1.- Arquitectura ANSI / SPARC.
Hay tres caractersticas importantes inherentes a los sistemas de bases de
datos: la separacin entre los programas de aplicacin y los datos, el manejo
de mltiples vistas por parte de los usuarios y el uso de un catlogo 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 caractersticas.
El objetivo de esta arquitectura es buscar la independencia de los datos
definiendo el esquema de la base de datos a tres niveles de abstraccin
distintos.
En cada uno de los niveles se genera un esquema de descripcin del trabajo
realizado:
80

MIGUEL DE CERVANTES
Nivel interno o fsico.
Esquema interno o fsico.
Es una descripcin de la base datos en trminos de su almacenamiento fsico

mediante un esquema interno. En l deben especificarse tres clases de
aspectos distintos:
Estrategia de almacenamiento. Comprende la asignacin 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 especificacin de claves primarias y

secundarias, as como los ndices y claves de ordenacin.
Miscelneas. Tcnicas
optimizacin,...
Nivel conceptual.
de
comprensin
de
datos,
encriptacin,
Esquema conceptual.
Se describe la estructura de toda la base de datos para un sistema de

informacin o la parte de l a tratar mediante un esquema conceptual.
Este esquema oculta los detalles fsicos 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 lgicos paradescribir
entidades, atributos, relaciones, operaciones de los usuarios y restricciones
con independencia del SGBD y de la mquina. (Esquema global).
En este nivel se puede utilizar un modelo conceptual o un modelo lgico para
especificar el esquema.
Nivel externo.
Esquemas externos.
Es el nivel ms cercano al usuario y representa la percepcin 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 debern encontrarse reflejados slo aquellos datos e
interrelaciones que se necesiten.
Tambin habrn 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 definirn tantos esquemas externos como exijan las diferentes
aplicaciones, y varios usuarios podrn compartir un mismo esquema externo.
Para una BD habr un nico esquema interno, un nico esquema conceptual,
81

MIGUEL DE CERVANTES
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 lgico o cannico.
Nivel lgico.
Esquema lgico.
Es una descripcin de la representacin de la BD en el esquema conceptual

(entidades, relaciones y restricciones,) teniendo en cuenta las
caractersticas del SGBD concreto que se vaya a usar.
La inclusin de este cuarto nivel de representacin del dominio del problema,
un nivel dependiente del SGBD, va a garantizar la independencia de la
informacin 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 excepcin del conceptual.

Para describir ste ltimo utilizaremos el mtodo Entidad/Relacin
(Entidad/Interrelacin).
Establecer las correspondencias entre los diferentes esquemas.
Aislar los esquemas de forma que sean lo ms independientemente

posibles. Los cambios en un esquema no deben afectar a los
esquemas de nivel superior y por tanto, tampoco a los programas de
aplicacin.
Cumpliendo estas obligaciones, el SGBD prev la independencia de los

datos.
Existen dos niveles de independencia de los datos:
82

MIGUEL DE CERVANTES
Independencia Lgica entre el esquema lgico y los externos.

Los esquemas externos y los programas de aplicacin que se utilicen no
deben verse afectados por las modificaciones que se efecten en el esquema
lgico sobre datos que no usen.
Independencia Fsica entre el esquema fsico y el lgico.
El esquema lgico no debe verse afectado por cambios en el esquema fsico
referentes a la implementacin de las estructuras de datos, modos de acceso,
tamaos de pginas, 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
simultneamente con subconjuntos de esta coleccin de datos y cuyas
necesidades varan 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 sealado 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:
Definicin de los datos a los distintos niveles de abstraccin (fsco,
lgico y externo).
Manipulacin de los datos en la base de datos.
Mantenimiento de la integridad de la base de datos. Integridad en
83

MIGUEL DE CERVANTES
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

caractersticas 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 comunicacin con la
base de datos; unos estn orientados hacia la funcin (definicin,
manipulacin o control) y otros dirigidos a diferentes tipos de usuarios o
procesos.
Atendiendo a la funcin realizada, podemos clasificar los lenguajes de la
siguiente forma:
Lenguaje de Definicin de Datos (LDD) Data Definition Language

(DDL).
Lenguaje de Manipulacin de Datos (LMD) Data Manipulation

Language (DML).
Lenguaje de Control de Datos (LCD) Data Control Language (DCL)
5.1.- Lenguaje de definicin de datos (DDL).

Permiten la definicin de datos a tres niveles: esquema lgico, fsico y
externo.
El primer paso consiste en especificar el esquema lgico 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 funcin consiste en
procesar las sentencias del lenguaje para identificar las descripciones de los
distintos elementos de los esquemas y almacenar la descripcin del esquema
en el catlogo o diccionario de datos.
Un diccionario de datos es un archivo que contiene metadatos, es decir, datos
(informacin) sobre datos o la descripcin 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 manipulacin de datos (DML).
Estos lenguajes permiten la insercin, modificacin, recuperacin y supresin
84

MIGUEL DE CERVANTES
de los datos almacenados en la base de datos.

El SGBD deber tener los mdulos que traducen estos lenguajes, tanto al
nivel de definicin como de manipulacin.
Dentro de los DML podemos clasificarlos por diferentes criterios:
Por su definicin:
o
Autosuficientes: los que se pueden ejecutar por ellos mismos,

pudindose realizar programas completos.
Huspedes: 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 cmo conseguirlos.
No procedimentales: el usuario debe especificar qu datos se

necesitan, pero no cmo obtenerlos.
En muchos SGBD se pueden introducir interactivamente instrucciones del

LMD desde un terminal o bien embeberlas en un lenguaje de programacin
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 cmo 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
cul es la estructura fsica de los datos y qu algoritmos se deben utilizar para
acceder a ellos. A los DML no procedurales tambin 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 informacin almacenada en el
diccionario de datos definiendo privilegios y tipos de acceso, as como el
control de la seguridad de los datos.
Tambin puede incluir mdulos para la reconstruccin de la base de datos, de
simulacin o de estadsticas entre otros.
85

MIGUEL DE CERVANTES
6.- Estructura general del SGBD.

Como ya se ha comentado, un SGBD se divide en mdulos que tratan cada
una de las responsabilidades del sistema general. En la mayora de los casos,
el sistema operativo proporciona nicamente los servicios bsicos, y el
sistema debe partir de esa base. As, el diseo de un SGBD debe incluir la
consideracin 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 informacin almacenada en disco.
Adems 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 Manipulacin de Datos) a instrucciones
de bajo nivel para que las entienda el gestor de BD. Adems el
procesador de consultas trata de traducir una peticin del usuario a
otra equivalente pero ms eficiente.
Compilador DDL. Convierte las proposiciones DDL (Lenguaje de

Definicin de Datos) en un conjunto de tablas que contienen
metadatos.
86

MIGUEL DE CERVANTES
Ficheros de datos. Almacenan la informacin (los datos).
Diccionario de datos. Almacena informacin referida a la estructura

de la BD. Se usa continuamente. Se debe poner un gran nfasis en un
buen diseo y una implementacin 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 informacin, 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 satisfaccin o
insatisfaccin 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 mdulo de programas que proporciona el interfaz
entre los datos de bajo nivel almacenados y los programas de aplicacin y
consultas, y es responsable de las siguientes tareas:
1.
Interaccin 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.
Implantacin de la integridad. Los valores de los datos que se
almacenan deben satisfacer ciertos tipos de restricciones de
consistencia, que debe especificar explcitamente el administrador de
la BD. El gestor de la BD entonces puede determinar si se produce
una violacin de la restriccin, si es as, se debe tomar la accin
apropiada.
3.
Implantacin de la seguridad. Es trabajo del gestor de la BD
debe hacer que se cumplan los requisitos de seguridad.
4.
Copia de seguridad y recuperacin. Un sistema informtico,
como cualquier otro dispositivo, est sujeto a fallos. Es
responsabilidad del gestor de BD detectar fallos y recuperar la BD al
87

MIGUEL DE CERVANTES
estado que exista antes de ocurrir el fallo. Esto se lleva a cabo

normalmente con procedimientos de copias de seguridad y
recuperacin.
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 interaccin entre los usuarios
concurrentes es otra responsabilidad del gestor de BD.
Los SGBD diseados para ordenadores personales y/o pequeos negocios u
organizaciones pueden no tener todas las caractersticas apuntadas.
6.2.- Esquema general de acceso del SGBD a los datos.
Cuando una aplicacin (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 aplicacin, escrito en un
lenguaje de programacin, lo hace por medio del sistema de gestin de
ficheros del sistema operativo que contiene los mtodos de acceso; mientras
que cuando se trata de una base de datos, el programa de aplicacin se
dirige al SGBD, el cual accede a la base de datos a travs del sistema
operativo.
El funcionamiento que se desencadena al realizarse una comunicacin del
usuario con el SGBD se puede dividir en tres pasos:
1.
Requerir informacin: peticin, acceso o activacin por parte de
las aplicaciones.
2.
SGBD: traduccin de la peticin (descomponer el programa) en
rutinas del SO. Debe conocer la descripcin 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.- Interaccin del SGBD con el SO y las aplicaciones (programas de

usuarios).
88

MIGUEL DE CERVANTES
rea de trabajo: zona de memoria para el intercambio de informacin

entre la base de datos y la aplicacin.
Estado: variable local para saber cul es el ltimo estado despus de

que la aplicacin haya realizado una operacin.
Ejemplo: desde que el programa de aplicacin (A) pide informacin hasta

que llega a su poder.
89

MIGUEL DE CERVANTES
(1) El programa de aplicacin (A) realiza una cierta peticin de datos al

SGBD.
(2) Consulta (recuperar) sobre las estructuras de datos del esquema
externo (A), utilizado por la aplicacin (A).
(3) Consultar el esquema lgico para establecer la correspondencia entre
los datos del esquema externo (A) y el esquema lgico, y realizar las
conversiones necesarias entre los dos esquemas para realizar la peticin
de datos sobre el esquema lgico.
(4) Consultar el esquema fsico para saber dnde se encuentra los datos
y como se debe convertir la operacin de peticin en rutinas del sistema
operativo.
(5) Lanzar las ordenes (rutinas) correspondientes al SO.
(6) El SO accede a la informacin. Hasta aqu se da la interaccin del
SGBD con el SO.
(7) La informacin ya localizada se transmite de la memoria externa a los
buffers de comunicacin.
(8) y (9) El SGBD toma la informacin de los buffers y la arregla para ser
compatible con el esquema externo, transmitindola al rea de trabajo.
(10) El SGBD le comunica al programa el resultado de su consulta.
Actualiza el estado de la operacin que pidi el programa. Despus
devuelve el control al Programa A.
Adems un SGBD debe cumplir los siguientes objetivos:

- Privacidad.
- Integridad, (seguridad).
- Recoger informacin para una posible reconstruccin de la BD.
El funcionamiento del SGBD est muy interrelacionado con el sistema
operativo.
7.- Usuarios del SGBD.
90

MIGUEL DE CERVANTES
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.
Definicin 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.
Definicin de la estructura de almacenamiento y del mtodo de
acceso. Se crean escribiendo un conjunto de definiciones traducidas
por el compilador del lenguaje de almacenamiento y definicin de
datos.
3.
Modificacin del esquema y de la organizacin fsica. 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.
Concesin 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.
Especificacin de las restricciones de integridad. Estas se
mantienen en una estructura especial del sistema que consulta el
SGBD cada vez que tiene lugar una actualizacin.
7.2.- Otros usuarios de la BD.
Un objetivo principal de un SGBD es proporcionar un entorno para recuperar
y almacenar informacin en la BD. En funcin de este objetivo podemos
clasificar los usuarios en cuatro tipos, segn la forma que tienen de
interaccionar con el sistema.
1.
Programadores de aplicaciones. Los profesionales en
computacin interactan 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 comnmente programas de aplicacin.
2.
Usuarios sofisticados. Interaccionan con el sistema sin escribir
programas, en cambio escriben sus preguntas en un lenguaje de
91

MIGUEL DE CERVANTES
consultas. Cada consulta se somete a un procesador de consultas,

cuya funcin 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 interactan con
el sistema invocando a uno de los programas de aplicacin
permanentes que se haya escrito anteriormente.
8.- Integridad.
La integridad hace referencia a la calidad de la informacin:
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 informacin de los datos se almacene de forma correcta.
Los datos estn 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 tcnicas para mantener la integridad: preventivas y

curativas.
8.1.- Tcnicas Preventivas.
El SGBD proporciona herramientas para prevenir la llegada a un estado
incorrecto. Tenemos varios tipos:
Verificacin: Se comprueba que las actualizaciones sobre la BD no

92

MIGUEL DE CERVANTES
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 ejecucin de un programa sean incorrectos, incoherentes o se pierdan
debido a la ejecucin concurrente de otro programa que accede a los mismos
datos.
Tipos de errores que se producen por accesos concurrentes mal
resueltos:
Perdidas de actualizaciones.
Obtencin 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 ningn otro programa los pueda emplear.
La reserva de datos se realiza a nivel de Granulo. El Granulo es elemento
atmico (dato ms elemental). Cuanto mayor es el grnulo menor es la
concurrencia. (Ej. un fichero, una pgina de un fichero,).
La ejecucin de un programa se realiza divida en transacciones.
Una transaccin es un conjunto de operaciones elementales, ya sean de
lectura y/o actualizacin de la BD La transaccin 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 transaccin se reservan los datos que se van a
utilizar; las modificaciones se acaban cuando termina la transaccin.
En todo SGBD existe un mdulo que se preocupa de la concurrencia
exclusivamente. Evita los abrazos mortales en las transacciones, mirando si
hay ciclos en la reserva de grnulos.
Control de la redundancia: existe un mdulo que se encarga de que

todo lo que sea redundante sea consistente.
8.2.- Tcnicas Curativas.

93

MIGUEL DE CERVANTES
Se encargan de reconstruir los estados incorrectos debidos a:
Fallos fsicos.
Interrupciones de programas de modificacin.
Las actualizaciones realizadas por parte del usuario sean errneas.
Frente a los estados incorrectos hay distintos tipos de reconstruccin:
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 reconstruccin son:
Copias de seguridad (backup): en el momento de realizar la copia no

debe de estar realizndose ninguna transaccin.
Fichero dietario: es un fichero en el cual se guarda la informacin que

permite deshacer o rehacer transacciones efectuadas en un preciso
intervalo de tiempo. Cuando una transaccin se confirma se apunta en
el dietario.
9.- SEGURIDAD.
9.1.- Objetivo.
Asegurar que a la informacin almacenada en la BD slo pueden acceder las
personas autorizadas y en la forma en la cual estn autorizadas.
9.2.- Tcnicas.
1)
Permitir la identificacin al usuario.
2)
Determinacin 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 actualizacin.
b. A base de mantener una lista de operaciones junto con los
objetos sobre los cuales puede realizar esas operaciones el
usuario. (Mejor opcin).
3) Efectuar una gestin de autorizacin transferida. El gestor debe
94

MIGUEL DE CERVANTES
comprobar y permitir:
a. Que las autorizaciones que son transferidas de un usuario a
otro permitan a este ltimo transferirlas tambin.
b. Cualquier autorizacin transferida se debe poder revocar
posteriormente.
c.
Debe cumplir la anulacin de autorizaciones en cascada.
TCNICAS DE ESPECIFICACIN DE CONTROL

Anlisis orientado a los datos
1.- INTRODUCCIN AL MODELO DE DATOS.

1.1.- Concepto de Modelo de datos.
Cuando se estudiaron los Sistemas de Informacin, se vio que el objetivo era
representar por medio de la abstraccin un subconjunto del mundo real en el
cual estamos interesados, y almacenar toda la informacin necesaria para el
buen funcionamiento del SI.
Podemos realizar la abstraccin de forma artstica o utilizando un mtodo.
Un SI tiene ciertas propiedades esttica y dinmicas.
- Estticas: son propiedades invariantes en el tiempo. Un SI est formado
por diferentes tipos de objetos, propiedades de cada objeto, relacin de objetos
entre s y restricciones de integridad sobre los objetos.
- Dinmicas (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 informacin capturando toda la semntica posible
asociada a dicha informacin, es decir, nos permite representar las
propiedades estticas y dinmicas de un sistema de informacin.
95

MIGUEL DE CERVANTES
Un esquema del SI es la descripcin de las estructuras de datos y de los

procesos del SI en trminos de un cierto modelo de datos.
- Esquema de la base de datos: descripcin de las propiedades estticas en
trminos de ese modelo de datos.
- Especificaciones de transaccin: descripcin de las propiedades dinmicas
en ese modelo de datos.
Una Base de Datos (BD) es una coleccin de datos estructurada segn un
cierto esquema de la BD.
A nosotros nos interesa el estudio de las propiedades estticas de un SI.
Fases del sistema de informacin:
Bases de Datos:
1. Anlisis:
2. Recogida de
requerimientos.
Modelo Conceptual.
3. Modelizacin.
Formalizacin de las
estructuras de datos.
Diseo Lgico.
4. Diseo. Estructurar la
informacin teniendo en
cuenta el S.G.B.D. que
se posee.
(S.G.B.D.) Diseo Fsico.
5. Implementacin.
Organizar la informacin
fsicamente en la
mquina a usar.
Obtenemos un subconjunto del mundo real.

1.2.- Fases del Modelo de Datos.
Atendiendo a las propiedades estticas de un SI, podemos definir el modelo de
datos como un conjunto de herramientas conceptuales para describir los datos
96

MIGUEL DE CERVANTES
que interesan almacenar en una aplicacin, sus relaciones, su semntica y sus

limitaciones o reglas.
En el Modelo de Datos se distinguen tres fases:
Modelo Conceptual, cuyo objetivo es representar la informacin de

forma comprensible a los usuarios e independientemente del software y
hardware disponible, en particular del Sistema de Gestin de Bases de
Datos (SGBD) especfico que se vaya a utilizar. Para la obtencin de
este
modelo
usaremos
el
modeloentidad/relacin o entidad/asociacin propuesto por Peter
Chen.
Diseo Lgico, transforma el modelo anterior (entidades, relaciones y

restricciones) teniendo en cuenta las caractersticas del SGDB concreto
que vayamos a utilizar en nuestra aplicacin El modelo inicial sufrir una
serie de refinamientos hasta llegar a estructuras de datos lo ms
independientes posibles aplicando tcnicas de normalizacin. Los
modelos utilizados para el diseo lgico son:
Modelo Relacional.
Modelo Jerrquico.
Modelo en Red.
Diseo Fsico, 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 fsicos.
El modelo de datos, una vez diseado, deber conseguir:

-
Obtener toda la informacin que el sistema necesita obtener para

sus fines.
Representar la informacin mediante una serie de conceptos

bsicos que contengan su significado.
Independizar los datos de los recursos fsicos as como de los

requerimientos de los usuarios.
Proporcionar a los usuarios del sistema la informacin tal y como

la necesitan.
97

MIGUEL DE CERVANTES
2.- MODELO ENTIDAD INTERRELACIN.

(MODELO CONCEPTUAL).
2.1.- Concepto de Modelo Entidad-Interrelacin.
El modelo Entidad-Interrelacin (E-R) fue propuesto por Peter Chen en 1976
para la definicin del esquema Conceptual de una BD. Posteriormente se ha
ido enriqueciendo con nuevos mecanismos de abstraccin y representacin de
la realidad. Este modelo es el ms ampliamente utilizado de los llamados
semnticos.
Es una tcnica de representacin grfica que incorpora informacin relativa de
los datos y la relacin existente entre ellos con el fin de darnos una visin de la
informacin 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 slo permiten describir las propiedades estticas 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 BDs del
sistema.
El modelo de datos define

almacenamientos de los DFDs.
las
relaciones
entre
los
2.2.- Representacin 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 informacin.
98

MIGUEL DE CERVANTES
Ejemplo: cliente, empleado, pieza, libro, factura, planificacin,...

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 tendramos las siguientes ocurrencias:
18.456.321 - Jos Ramrez Blasco - Alcaiz - 978662132
18.452.125 - Estrella Snchez Lpez - Calanda - 978674121
Una entidad debe cumplir las siguientes caractersticas:
Cada una de sus ocurrencias puede ser identificada

unvocamente. Existe alguna manera de diferenciar dos ocurrencias
individuales de la entidad.
Cada entidad juega una funcin dentro del sistema, El

sistema no funciona sin acceder a sus miembros instancias.
Cada entidad puede ser descrita por uno o ms elementos

(atributos). Los atributos se aplican a cada ocurrencia de la entidad.
Las entidades se representan mediante un rectngulo nominado. Para ponerles
un nombre, normalmente se utiliza un sustantivo en singular.
CLIENTE
Hay que tener en cuenta la relacin entre los almacenes del DFD y las
entidades del diagrama de Entidad-Relacin (DER). Si existe una entidad
artculo en un DER, debe haber un almacn de datos artculos en el DFD
asociado.
2.3.- Representacin de ATRIBUTOS.
Los atributos son cada una de las propiedades o caractersticas que tiene una
entidad o una relacin.
Ejemplo: Los atributos de la entidad
Cliente podran ser DNI, nombre,
poblacin, telfono,...
99

MIGUEL DE CERVANTES
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 relacin dicho nombre debe ser nico.
En funcin de los distintos tipos de atributos que nos podamos encontrar,
variar el tipo de representacin:
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.
100

MIGUEL DE CERVANTES
Atributo multivaluado, se indica mediante la etiqueta n sobre el arco.
2.4.- Representacin de RELACIONES.

Las relaciones entre entidades se representan mediante un polgono 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 polgono ir etiquetado con el nombre de
la relacin. Asimismo, se pueden etiquetar los arcos para realzar el papel que
juega dicho objeto dentro de la relacin.
Una relacin es la asociacin o correspondencia entre entidades. No tienen
existencia propia.
Una ocurrencia de relacin no es distinguible por s misma, sino a travs de la
designacin de las ocurrencias de las entidades asociadas.
Cada instancia de la relacin representa una asociacin entre 0 ms
ocurrencias de una entidad y 0 ms ocurrencias de otra entidad. Por ejemplo:
Instancia 1: cliente 1 compra artculo 1.
Instancia 2: cliente 2 compra artculo 2 y 3.
Instancia 3: cliente 3 y 4 compran artculo 4.
Instancia 1: cliente 5 no compra ningn artculo.
Nos podemos encontrar mltiples relaciones entre dos o ms entidades, y

debemos interpretarlo como una unidad. La relacin 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 relacin.
101

MIGUEL DE CERVANTES
Las entidades que pueden ser calculada o derivadas a partir de otros datos, no
se representan.
Grado de una relacin.
Es el nmero de entidades que forman parte de la relacin.
Atendiendo al grado de la relacin 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.
102

MIGUEL DE CERVANTES
2.5.- Representacin 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.
Slo 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 caracterstica o propiedad. Los atributos toman valores de un dominio por
lo que podemos decir que el atributo le da una determinada interpretacin al
contexto de una entidad o una relacin.
Conceptualmente los dominios pueden ser:
Continuos. Formado por todos los valores comprendidos entre un

mximo y un mnimo. 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:
103

MIGUEL DE CERVANTES
2.5.2.- Restricciones sobre ENTIDADES.

Restriccin 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 mnimo y el mximo de ocurrencias de una entidad que pueden
intervenir en una ocurrencia de una u otras entidades que participan en la
relacin.
2.5.3.1.- Restricciones de cardinalidad mxima.
Conectividad o tipo de correspondencia: es la cardinalidad mxima de una
entidad que toma parte de una relacin, es decir, representa la participacin
mxima de ocurrencias en la relacin de cada una de las entidades afectadas.
Tiene dos valores, 1 o muchos.
Las restricciones de cardinalidad mxima (conectividad) se expresan mediante
el rallado de la parte del polgono que indica la asociacin de una de las
entidades (en relaciones binarias, la mitad del rombo). Dependiendo del
nmero de entidades asociadas la cardinalidad mxima implica una lectura u
otra.
Suponiendo dos entidades A y B asociadas por una relacin R, definiremos las

restricciones de cardinalidad mnima (m) y mxima (M) como:
104

MIGUEL DE CERVANTES
R ( A(mA, MA), B(mB, MB) )

Slo nos vamos a fijar en las relaciones binarias, dndose los siguientes casos:
Uno a uno, 1:1. A cada ocurrencia de una entidad le corresponde

como mximo una ocurrencia de la otra y viceversa.
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, 1) )
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
Conect(PEDIDO)
Conect(PROV) = M
Conect(FACTURA)
Conect(PROD) = M
1:M
=
105
M:M
Conect(CLIENTE)
Conect(CUENTA)

MIGUEL DE CERVANTES
2.5.3.2.- Restricciones de cardinalidad mnima.

-
Restriccin de existencia.
Es la cardinalidad mnima en la que una entidad toma parte en una relacin.

Dada una entidad A que forma parte de una relacin R, sufre restriccin de
existencia si toda ocurrencia de la entidad E debe estar asociada en la relacin
R.
Para representar esta restriccin utilizaremos un doble rectngulo para la
entidad que sufre esta restriccin, y etiquetaremos el arco de la relacin con
una E.
Pertenecer ( DEPART(1, 1), EMPLE (0, ) )
Restriccin de identificacin 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 restriccin de identificacin se dice que es dbil,
en contraposicin a la entidad que presta sus identificadores, que se
considera fuerte. La entidad dbil hereda la clave de la otra entidad para formar
la clave con la suya propia.
Cualquier entidad que sufre la restriccin de identificacin tambin sufre la
restriccin de existencia.
106

MIGUEL DE CERVANTES
2.6.- EJEMPLO DE ENTIDAD-RELACIN.

Mostraremos a continuacin el diagrama E-R para un Sistema de Informacin
sobre la gestin de pedidos a proveedores de una empresa genrica.
El ejemplo pretende reflejar la poltica de compras de una empresa de
distribucin. Se compran ciertas mercancas a los distintos proveedores y son
vendidas posteriormente al pblico o a otros distribuidores.
Bsicamente, 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 mercancas 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 confeccin de un inventario, donde cada entrada, que

corresponda a un nico artculo, es el recuento real de existencias.
107

MIGUEL DE CERVANTES
Lista de precios de compra a proveedores.
Tenemos almacenada la informacin de aquellos proveedores habituales de la

empresa y de las piezas que entran y salen del almacn: 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 relacin M:M entre las dos
entidades mencionadas y que hemos denominado SUMINISTRA, contiene,
adems, los atributos que nos indican el precio actual al que se puede comprar,
los das que tarda en ser servida la pieza, y el posible descuento ofrecido por el
proveedor.
El siguiente ejemplo muestra una posible ocurrencia de la relacin
SUMINISTRA que asocia una ocurrencia de VENDEDOR, otra de pieza, y
contiene los atributos particulares de la asociacin.
Ocurrencia de VENDEDOR.
1 FEDERICO
LOPEZ
BASILIO
MECEMSA 978.665.214 Avda.

Cceres,
13
CALANDA TERUEL
Ocurrencia de PIEZA
DD-0001-
DISCO DURO WESTERN DIG 25.000

108

MIGUEL DE CERVANTES
210
6,2 Gb
Ocurrencia de SUMINISTRA
1 FEDERICO
LOPEZ
BASILIO
MECEMS
A
978.665.21
4
Avda.
CALAND
Cceres, A
13
DD-0001210
DISCO DURO WESTERN DIG 25.000

6,2 Gb
15000 3
15
TERUE
L
Se supone que almacenamos la informacin de las piezas que maneja la

empresa y la de los vendedores que podran suministrarlas. En la relacin M:M
SUMINISTRA se asocian efectivamente las piezas con los proveedores que las
sirven, y el precio de la oferta de cada uno. Ntese que, por la conectividad de
la relacin, 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, formaran cada ocurrencia de suministra, ilustra
cmo se relacionaran 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 enva al
vendedor que, posteriormente servir tales mercancas. Toda esta operativa se
refleja en dos nuevas entidades, PEDIDO y LINPED, y en tres relaciones,
RECIBE, CONTIENE y SE_PIDE_EN.
Adems, para controlar la recepcin de, los pedidos, se almacena informacin
sobre la fecha en que entran efectivamente las mercancas en el almacn, 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
109

MIGUEL DE CERVANTES
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 lneas de pedido que
contienen, cada una, una referencia a una nica pieza. Precisa de una
restriccin de dependencia de identificador puesto que, para todos los pedidos,
las lneas 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 cmo seran dos fichas de control
de pedidos servidos por los proveedores
Numpedido
numvend
Fecha
19/01/2000
Numlinea
numpieza
preciocompra cantpedida
Fecharecep
M-0001-C
30000
10
24/01/2000
P-0001-33
21000
20
24/01/2000
FD-0001-144
13500
20
24/01/2000
DD-OOO1210
15000
20
24/01/2000
T-0002-AT
3100
20
01/02/2000
Numpedido
numvend
Fecha
25/01/2000
110

MIGUEL DE CERVANTES
numlinea
numpieza
Preciocompra Cantpedida
Fecharecep
DK144-002-P
545
100
29/01/2000
T-0002-AT
3000
29/01/2000
Al 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 almacn se ha optado (no
tiene por qu ser la mejor alternativa) por una entidad INVENTARIO con una
relacin 1:1 con PIEZA, con restriccin de existencia.
De cada pieza se mantiene el ltimo recuento fsico en el almacn, por si ha
habido roturas o prdidas que alteren la diferencia entre bienes que entran y
salen. Tambin se especifica cual es el nivel mnimo 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 nmero de inventario
(numbin) y obligatoriamente estar asociada a una (distinta para cada entrada
de inventario) de PIEZA.
2.7.- MODELO ENTIDAD INTERRELACIN EXTENDIDO (EE-R).
El modelo Entidad Interrelacin Extendido surge de la actualizacin del Modelo
E-R, permitiendo la representacin de cualquier tipo de relaciones existentes
entre las clases de objetos que considera los principios de la abstraccin.
2.7.1.- Relaciones Exclusivas.
Dos o ms relaciones son exclusivas si cada ocurrencia de una entidad slo
puede pertenecer a una de las relaciones.
111

MIGUEL DE CERVANTES
2.7.2.- Generalizacin/Especializacin y Relaciones IS-A.

Generalizacin. Es el proceso de definir una entidad generalizada a partir de
otras entidades. Especifica que varias entidades con ciertos atributos en comn
pueden generalizarse en una entidad a nivel superior, denominada supertipo o
superclase.
Especializacin. Es el proceso de definir un conjunto de subtipos o subclases
a partir de una entidad ms general.
La descomposicin de entidades en varias subclases es una necesidad muy
habitual en la modelizacin de bases de datos, ya que permiten identificar y
representar jerarquas entre los tipos de entidad identificadoos en el problema
del mundo real a estudiar.
La relacin que se establece entre una superclase de entidad y sus subclses
corresponde a la nocin de <<ES-UN>> (conocida por sus siglas inglesas
<<IS-A>>) o, ms exactamente, <<ES-UN-TIPO-DE>>.
Las relaciones IS-A son implcitamente de cardinalidad 1:1 por lo que no se
indica explcitamente.
Una caracterstica muy importante de esta clase de relaciones es la herencia,
ya que, en principio, todo atributo de la clase ms general pasa a ser un
atributo de las subclases.
En este tipo de abstraccin los atributos comunes a todas las subclases se
asignan a la superclase, mientras que los atributos especficos se asocian a la
subclase correspondiente; siendo la clase ms general la nica que disponga
de identificadores. En resumen, toda subclase dispondr de sus atributos
propios (representados en el diagrama) ms 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
112

MIGUEL DE CERVANTES
a la superclase, asociando a las subclases las relaciones especficas en las

que la correspondiente subclase y slo ella participa.
La relacin jerrquica entre la entidad ms 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 especializacin 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. Tambin 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 especializacin se representa uniendo todas las entidades especializadas
segn un criterio con la entidad general a travs de un crculo en el que
indicaremos las propiedades de la Generalizacin/Especializacin. En el caso
de que slo haya una subclase, no hace falta el crculo.
Ejemplo de Generalizacin.
Ejemplos de especializacin:
113

MIGUEL DE CERVANTES
2.7.3.- Agregacin (Entidades compuestas).

Cuando la relacin que vincula dos o ms entidades tiene a su vez
caractersticas de entidad, de manera que se relaciona como tal con otras
entidades, se aplica el concepto de agregacin. Este mecanismo sirve para
expresar que las ocurrencias de la relacin agregada se comportan tambin
como entidades. Para ello, se engloba el smbolo de la relacin con un
rectngulo, lo que denota que esa relacin es un objeto agregado.
Las entidades agregadas nunca son dbiles ni tienen atributos identificadores
ya que heredan la identificacin de la relacin que las define. Sin embargo s
que pueden tener atributos con restriccin de unicidad o valor no nulo. Tambin
pueden sufrir restricciones de existencia.
Ejemplo:
2.8.- Reglas para la construccin de Diagramas E-R.
Construccin del modelo inicial.
El Diagrama E-R inicial se construye basndose en el propio conocimiento del

sistema, y a partir de las entrevistas iniciales al usuario donde obtenemos los
requerimientos de la organizacin.
No se debe esperar que este modelo inicial sea el definitivo.
Las actividades a realizar sern las siguientes:
-
Identificar tipos de entidad y atributos,
Identificar generalizaciones/especializaciones,
Identificar tipos de relacin entre tipos de entidades,
Identificar tipos de entidad dbiles,
Identificar agregaciones, y
114

MIGUEL DE CERVANTES
Especificar restricciones de integridad.
Refinamiento del modelo inicial.
Las actividades anteriores se realizan de forma iterativa hasta conseguir definir

un Diagrama E-R lo ms fiel posible a la realidad y en el cual el conjunto de
restricciones de integridad textuales sea lo ms pequeo posible.
Si se ha hecho el DFD, seguramente estar definido el almacn de datos
asociado en el Diccionario de Datos. Al hacer este refinamiento nos podemos
encontrar ante la necesidad de aadir nuevas entidades o eliminarlas.
Aadir/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:
edad,..., nmero de embarazos ...
Atributos:
nombre,
Solucin: Crear un conjunto de entidades subclases EmpleadoMasculino, Empleado-Femenino.

2. Datos elementales aplicables a todas las instancias de dos entidades
diferentes.
Entidad
Cliente-Caja,
Cliente-Crdito.
comunes: nombre, direccin.
Atributos
Solucin: crear una entidad superclase Cliente.
3. Datos elementales que describen relaciones entre entidades-tipo.
Relacin Compra y los datos fecha_de_compra, y

descuento.
Solucin: Crear una entidad asociativa Compra.
4. Eliminar grupos de datos repetitivos dentro de una entidad.
Entidad Empleado, y cada uno puede tener varios hijos.
Solucin:
Crear
115
una
entidad
Hijo
la
relacin

MIGUEL DE CERVANTES
Es_Padre_de. Eliminar entidad del modelo inicial.

5. Entidades de las cuales solo hay una instancia, y solo tienen
identificador.
Entidad Cnyuge, de la cual slo nos interesa el nombre.
Solucin: Eliminar la entidad Cnyuge y la relacin

Esta_Casado_con y guardamos el nom_cnyuge con el
atributo empleado.
6. Relaciones calculadas o derivadas.
Relacin Renovacin, que se puede calcular a partir de diversos datos

de Conductor (fecha_nacimiento, apellidos,...).
Solucin: eliminar la relacin Renovacin.
Comentarios:
-
No puede haber entidades con el mismo nombre que otra

entidad o que otra relacin.
En un diagrama ER todas las entidades tienen atributos

identificadores o bien son dbiles o especializaciones.
Las entidades especializadas nunca tienen atributos

identificadores ni son dbiles ya que heredan la identificacin de
su entidad general.
En una ocurrencia de una relacin 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 intencin de que represente una
relacin con otra entidad.
116

Modulo de Analisis y Diseno Tercero Bachillerato

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modulo de Analisis y Diseno Tercero Bachillerato

Uploaded by

Copyright:

Available Formats

UNIDAD EDUCATIVA PCEI

MDULO # 1: DE ANLISIS Y DISEO DETALLADO DE

Empresa como sistema de informacin

Sistema de informacin bsicos en las empresa

Desarrollo de aplicaciones informticas

Ciclo de vida de un sistema.

Lic. Sandra E. Tene G.

UNIDAD EDUCATIVA PCEI

Clasificacin de las metodologas de desarrollo.

Principales metodologas de desarrollo europeas.

Anlisis de necesidades y estudio de viabilidad

Cmo comienza un proyecto.

Definicin del problema.

Propuesta de soluciones alternativas.

Seleccin de una alternativa.

Anlisis de requisitos. Anlisis estructurado. Modelizacin conceptual

Introduccin al anlisis de requisitos (A.R.).

Modelizacin conceptual de datos

Introduccin a las bases de datos. Concepto.

Arquitectura. Modelos de datos

Tcnicas de especificacin de control

Anlisis orientado a los datos

Lic. Sandra E. Tene G.

UNIDAD EDUCATIVA PCEI

INTRODUCCIN A LOS SISTEMAS DE INFORMACIN

Componentes o elementos que integran el sistema: todo lo que

Las relaciones de orden entre elementos, determinando la

Lic. Sandra E. Tene G.

UNIDAD EDUCATIVA PCEI

El fin u objetivo del sistema: esta caracterstica que puede resultar

Los lmites del sistema: la frontera entre lo que el sistema es y lo

Tambin suelen existir relaciones entre el sistema y sus componentes y el

Lic. Sandra E. Tene G.

UNIDAD EDUCATIVA PCEI

La informacin es un conjunto de datos procesados y comunicados de

La informacin es relevante para el propsito de la decisin o el

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

Suficientemente completa para el problema. Lo ideal es poder contar

La informacin se comunica a la persona adecuada para la toma de

Se comunica a tiempo para que pueda ser til.

Llega al nivel de detalle ms adecuado.

La informacin debe ser comprensible para el receptor.

Lic. Sandra E. Tene G.

UNIDAD EDUCATIVA PCEI

de entradas compuesto por materias primas, mano de obra, flujos

Controlar y gestionar el empleo de los recursos financieros, el

Comercializar de manera ptima los productos o servicios en los

Fabricar productos o crear servicios que vender en el mercado.

Proporcionar la informacin correctamente.

Lic. Sandra E. Tene G.

UNIDAD EDUCATIVA PCEI

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 mnimo.

La informacin. Es el elemento fundamental del sistema y su razn

Los procedimientos y las prcticas habituales de trabajo que rigen

Recursos humanos: las personas o usuarios. Se trata de individuos

Recursos fsicos o materiales: el equipo de soporte para la

Para lograr sus objetivos, la organizacin y sus individuos adoptan

Lic. Sandra E. Tene G.

UNIDAD EDUCATIVA PCEI

Cmo se ven implicadas las personas.

Qu equipo se precisa para un trabajo eficaz.

Los procedimientos se deben adaptar a los elementos disponibles: