1993 - 092 - Metodología de Planificación y Desarrollo de Sistemas de Informacion PDF

P.V.P. 6.000 Dtas.
MAP
Ministerio
para las
Adm,"' straciones
Pblicas
METODOLOGA
DE PLANIFICACIN Y
DESARROLLO DE SISTEMAS
DE INFORMACIN
MTRICA VERSIN 2
GUA DE REFERENCIA
METODOLOGA
DE PLANIFICACIN Y
DE INFORMACIN:
MTRICA VERSIN 2
GUA DE REFERENCIA
MINISTERIO PARA LAS ADMINISTRACIONES PUBLICAS
MADRID
1993
Coleccin: MANUALES
Primera edicin: Marzo 1993
La Metodologa de Planificacin y Desarrollo de Sistemas de Informacin.
METRICA ~ es una iniciativa promovida por el Consejo Superior de Infor-
mtica, rgano colegiado encargado de la elaboracin y desarrollo de la poltica
informtica del Gobierno.
Edita:
Direccin General de Servicios
Instituto Nacional de Administracin Pblica
ISBN: 84-7088-633-9 (Obra Completa)
ISBN: 84-7088-635-5 (Tomo Il)
NIPO: 329-93-002-6
Depsito Legal: M-10395-1993
Impresin: Jacaryan, S.A. Avda. Pedro Dez, 3 - 28019 Madrid
GUIA DE REFERENCIA
METODOLOGIA METRICA VERSION 2
GUIA DE REFERENCIA
INDICE
1
1. INTRODUCCION A LA METODOWGIA METRICA
VERSION 2 3
2. FASE O: PLAN DE SISTEMAS DE INFORMACION 29
3. FASE 1: ANALISIS DE SISTEMAS 81
3.1. MODULO ARS: ANALISIS DE
REQUISITOS DEL SISTEMA 87
3.2. MODULO EFS: ESPECIFICACION
FUNCIONAL DEL SISTEMA 113
4. FASE 2: DISEO DE SISTEMAS 153
4.1. MODULO DTS: DISEO TECNICO
DEL SISTEMA 159
5. FASE 3: CONSTRUCCION DE SISTEMAS 193
5.1. MODULO DCS: DESARROLLO DE
COMPONENTES DELSISTEMA 198
5.2. MODULO DPU: DESARROLLO DE
PROCEDIMIENTOS DE USUARIO 221
6. FASE 4: IMPLANTACION DE SISTEMAS 249
6.1. MODULO PIA: PRUEBAS, IMPLANTACION
y ACEPTACION DEL SISTEMA 255
7. GUIA DE GESTION DE PROYECTOS 287
8. APENDICES 321
MAP - Metodologa METRlCA Versin 2
2 GUIA DE REFERENCIA
8.1. GLOSARIO DE TERMINOS 323
8.2. ACRONIMOS UTILIZADOS 331
9. BIBUOGRAFIA RECOMENDADA 335
10. PROYECfOS PILOTO 339
11. EQUIPO RESPONSABLE DEL PROYECfO 343
MAP - Metodologa METRICA Versin 2
INTRODUCCION
INTRODUCCION A LA METODOLOGIA METRICA VERSION 2
INDICE
5
1.1. INTRODUCCION GENERAL 7
1.2. OBJETIVOS DE LA METODOLOGIA
METRICA VERSION 2 8
1.3. ESTRUCfURA DE LA METODOLOGIA
METRICA VERSION 2 10
1.4. ORGANIZACION DE LA METODOLOGIA
1.5. GESTION DE PROYECTOS 19
1.6. IMPLANTACION DE LA METODOWGIA
INTRODUCCION
1.1. INTRODUCCION GENERAL.
7
Dentro de cualquier tipo de Organizacin, el disponer con rapidez de una
informacin completa y fiable, constituye un elemento esencial para garantizar la
gestin eficaz de los recursos de la misma, mejorar laealidad de los servicios que
presta y adecuarse constantemente al entorno que la rodea. Esto hace que un
objetivo primordial de los responsables de toda Organizacin sea el de garantizar
la calidad de la informacin.
Para alcanzar este fin ltimo, es necesario definir de antemano una serie de
etapas intermedias, que permitan una adaptacin progresiva de todas las person'as
implicadas en la obtencin y utilizacin del recurso informacin, por un lado los
responsables de la direccin de proyectos informticos, y por otro, los
responsables de la gestin de la Organizacin. Estas etapas intermedias son:
Asegurar la calidad en la construccin de los equipos lgicos relacionados
con el tratamiento de la informacin.
Elaborar un marco homogneo de referencia dentro de la Organizacin,
que permita verificar que los productos que se generen tienen un nivel
adecuado de calidad.
Conseguir que la construccin de los equipos lgicos se desarrolle en unos
plazos y con unos costes razonables, de tal manera que se cumplan las
previsiones iniciales.
Consciente de estas necesidades, la Subdireccin General de Coordinacin
Informtica del Ministerio para las Administraciones Pblicas, ha desarrollado un
plan de accin, cuyo objetivo es establecer los trminos de referencia que
permitan satisfacer las etapas apuntadas anteriormente y cuyos resultados, hasta
la fecha, son:
La elaboracin de un Plan General de Garanta de Calidad, aplicable al
desarrollo de equipos lgicos.
La elaboracin de la Metodologa de Desarrollo de Sistemas de
informacin METRICA Versin 2, que ahora se presenta.
Ambos productos, constituyen a la vez un marco general de referencia para toda
la Administracin y requisitos bsicos para la consecucin de la calidad total de
la informacin. Su aplicacin contribuir, en gran medida, a mejorar la eficacia
de la Administracin, tanto en su vertiente interna, cmo en su vertiente de
prestacin de servicios pblicos a los ciudadanos.
8 INTRODUCCION
Por ltimo, es preciso establecer una premisa importante: solo se podr garantizar
el xito del esfuerzo realizado si existe el compromiso firme por parte de los
responsables, tanto de la gestin como del tratamiento de la informacin, de las
distintas Unidades de la Administracin, de adaptar este marco general de
referencia al mbito especfico de sus reas de responsabilidad.
1.2. OBJETIVOS DE LA METODOLOGIA METRICA VERSION 2.
A medida que crece el volumen de informacin a manejar en la Administracin,
aumenta la necesidad de disponer de una Tecnologa de la Informacin que
soporte dinmica y eficazmente el funcionamiento normal de los distintos
departamentos que la constituyen.
Dicho soporte ha de ser dinmico en el sentido de que debe adaptarse con
facilidad a las condiciones, externas e internas, cambiantes de la Organizacin.
Por otra parte, ha de ser eficaz y atenerse estrictamente a las necesidades del
usuario. Para ello la comunicacin entre las Unidades usuarias y la de Tecnologa
de la Informacin es un factor vital y determinante.
La problemtica de los Departamentos de Tecnologa de la Informacin que no
utilizan ninguna metodologa de desarrollo, se puede resumir as:
Escasa o nula documentacin de los sistemas, lo que dificulta las tareas de
desarrollo, implantacin y especialmente la de mantenimiento.
Falta de comunicacin con los usuarios, lo que genera productos no
entregados a tiempo y que, adems, no responden totalmente a las
necesidades de los usuarios.
Se justifica, por tanto, la implantacin de una Metodologa de Desarrollo de
Sistemas en ia Administracin, en la que se defina un conjunto de mtodos,
procedimientos, tcnicas y herramientas que faciliten la construccin de Sistemas
de Informacin, con el fin de:
Satisfacer todas las necesidades de los departamentos usuarios implicados.
Generar la documentacin asociada, la cual comprende instrucciones de
documentacin del mantenimiento y la explotacin, etc.
INTRODUCCION 9
El principal objetivo de la metodologa METRICA Versin 2 es crear un entorno
que permita al equipo de trabajo construir Sistemas, que:
Den solucin a los objetivos considerados prioritarios en la
Administracin.
Se desarrollen cuando el usuario los necesite y de acuerdo con los
presupuestos y duracin estimados.
Se mantengan fcilmente para soportar los cambios futuros de la
organizacin.
Todo ello utilizando un vocabulario comn y un conjunto completo de tareas y
productos finales que ayuden a construir con xito Sistemas de Informacin.
METRICA Versin 2 ha sido diseada por un grupo de trabajo constituido al
efecto por personal procedente de distintos Ministerios y Organismos de la
Administracin con la asistencia externa de la empresa Coopers & Lybrand.
Esta metodologa es una gua formal, aunque flexible en su utilizacin, para el
Diseo y Construccin de Sistemas de Informacin empleando conceptos y
tcnicas de Ingeniera de Sistemas de Informacin y Tecnologa de la
Informacin.
El mbito de aplicacin de METRICA Versin 2 ser la Administracin Central
del Estado en una primera etapa y eventualmente se podr ampliar a las
Administraciones Local y Autonmica.
En el desarrollo de METRICA Versin 2 se han considerado las Metodologas
y Proyectos de estandarizacin en curso siguientes:
SSADM, Metodologa pblica britnica.
MERISE, Metodologa pblica francesa.
SUMMITD, Metodologa de Coopers & Lybrand.
EUROMETODO, Marco metodolgico europeo.
PLAN GENERAL DE GARANTIA DE CALIQAD APLICABLE AL
DESARROLLO DE EQUIPOS LOGICOS
10 INTRODUCCION
1.3. ESTRUcruRA DE LA METODOLOGIA METRICA VERSION 2.
METRICA Versin 2 ofrece un marco de trabajo en el que se define:
Una estructura de proyecto que sirva de gua al equipo de trabajo e
involucre a los usuarios en su desarrollo y en sus puntos decisivos.
Un conjunto de productos finales a desarrollar.
Las diferentes responsabilidades y funciones de los miembros del equipo
de proyecto y de los usuarios.
Con este fin, se describe en detalle la sucesin de pasos, estructurados en Fases,
Mdulos, Actividades y Tareas, que se han de seguir en el desarrollo de sistemas
informticos, as como los productos que se obtienen en cada uno de dichos
pasos. Estos productos pueden ser, productos finales o bien productos intermedios
que servirn para la realizacin de algn paso posterior. Por ltimo se describe
la estructura final de la documentacin obtenida.
Las razones que han llevado a definir esta estructura de Fases y Mdulos son las
siguientes:
El trmino Fase conlleva la idea de secuencia, y presenta las
caractersticas que a continuacin se indican:
Establece un conjunto formal de Productos que deben ser
entregados por el equipo de trabajo antes de que se inicie la
siguiente fase. De esta forma, se pueden dividir los proyectos en
una serie de hitos preestablecidos, que facilitarn las labores de
Planificacin y Control de Proyectos.
El final de cada Fase requiere una aceptacin formal de las
conclusiones a las que se ha llegado al trmino de la misma.
El producto final obtenido en cada Fase es un documento que se
utiliza para el inicio de la siguiente fase.
La divisin en Mdulos obedece a razones de homogeneidad: Un mdulo
es un grupo de actividades y tareas que se realizan para producir un
conjunto especfico de productos finales.
MAP Metodologa METRICA Versin 2
INTRODUCCION 11
METRICA Versin 2 est dividida en cinco Fases que se descomponen en siete
Mdulos. Los Mdulos, a su vez, se descomponen en Actividades y stas en
Tareas.
Las fases en las que se divide METRICA Versin 2 son:
FASE o:
FASE 1:
FASE 2:
FASE 3:
FASE 4:
PLAN DE SISTEMAS DE INFORMACION.
ANALISIS DE SISTEMAS.
DISEO DE SISTEMAS.
CONSTRUCCION DE SISTEMAS.
IMPLANTACION DE SISTEMAS.
METRICA Versin 2 est apoyada en una serie de tcnicas que dan el soporte
prctico necesario para el desarrollo ptimo de las Actividades definidas en ella,
y permite el empleo de herramientas tecnolgicas avanzadas (CASE, Lenguajes
4
i
Generacin, etc.) que facilitan dicho desarrollo.
Es importante destacar que an contemplando aspectos de Gestin de Proyectos,
Gestin de Calidad y Gestin de Configuracin, METRICA Versin 2 no
pretende soportar todas las actividades relacionadas con estos conceptos de
Ingeniera de Sistemas. .
Sin embargo, aporta un nexo de unin con dichos conceptos, identificando el
lugar donde conectan la metodologa de desarrollo de sistemas y el resto de los
aspectos asociados al desarrollo de cualquier Sistema de Informacin.
En cualquier caso permite poner los cimientos de lo que sera una construccin
de sistemas con un enfoque de ingeniera.
A continuacin se describen con ms detalle cada una de las fases de la
Metodologa METRICA Versin 2. Cuadro INT-1
FASES Y MODULOS
PLAN SISTEMAS .
INFORMACION
PSI
PLAN DE SISTEMAS
DE INFORMAClON
olden1ifar necesidades
informacin Unidad
oldentifarDirllClrices
de GestiSn yT6alicas
oDiselWA1quil8clwade
la InlDrm8Ci6n
oRevisar lituaei6n actual
Sisternu InIormaci6n

oDefiril Iltlmalivas

o Baborar PI," de
Accin
ANALISIS DE
SISTEMAS
ARS
ANALISIS DE
REQUISITOS
DEL SISTEMA
oDesaibir el alcance.

del Sistema
oExaninar cistintas
Iltemativasde
soluci6n
oSelea:ionar una
Iltemativa
EFS
ESPECIFICACION
FUNCIONAL DEL
SISTEMA
oEspecificar los
Subsistemas
oEstablecer los
Requisitos
de Procesos
oEspecificar los

DISEO DE
SISTEMAS
DTS
DISEO TECNICO
DEL SISTEMA
oDiseftar A1quitec:twa
modular
oDesaibir Compo-
nentes del Sistema
DiseftarBasnde
Dalolo FICheros
oEspecificar Entorno
TllOlOkIgico
oDefirir Plan de
Pruebas
del Sistema
CONSTRUCCION DE
SISTEMAS
es
DESARROllODE COMPONENTES
DEL SISTEMA
o Preparar Entorno de Desarrolb
y Pruebas
oDesarrollo y Pruebas
oPruebas delntegraci6n
DPU
DESARROllO DE PROCEDIMIENfOS
DE USUARIO
oPreparar Procecimienlos de Usuario
oDetermina' Habilidades yRecusol
de Usuarios
Consolidar PrOCllcimienlos de Usuario
IMPLANTACION DE
SISTEMAS
PIA
PRUEBAS, IMPLANTAClON y
ACEPTAClON DEL SISTEMA
Realizar las Pruebas del
Sistema
Actualizar el Plan de
Implanlaci6n
oRelfizarlas Pruebas de
Aceplaci6n
ykIIptu el Sistema
o Realizar la l"1Jlantaci6n.
INTRODUCCION 13
FASE O: PLAN DE SISTEMAS DE INFORMACION.
La realizacin de un Plan de Sistemas de Informacin dentro de cualquier
Organizacin, tiene como finalidad asegurar la adecuacin entre los
objetivos estratgicos de la misma y la informacin necesaria para soportar
dichos grandes objetivos. Esto hace que una metodologa de planificacin
de sistemas abarque a toda la organizacin y exige tener en cuenta una
serie de conceptos, en cuanto a planificacin de estrategias que desbordan
el marco especfico de una Metodologa de Desarrollo de Sistemas.
Conscientes de esta diferencia en cuanto al mbito que se pretende cubrir
con una Metodologa de Planificacin de Sistemas, es necesario, sin
embargo, establecer una relacin directa entre ambas metodologas, con
el fin de que la informacin obtenida con una concepcin estratgica sirva
de entrada y punto de partida para la esptcificacin de los sistemas
concretos a desarrollar.
Para ello, se ha definido la Fase Ode la Metddologa METRICA Versin
2, con los siguientes objetivos:
Definir la informacin necesaria que se debe obtener con la
realizacin de una Metodologa de Planificacin, en cuanto a
objetivos estratgicos de la Organizacin y factores crticos de xito
para satisfacer estos objetivos.
Definir la Arquitectura de la Informacin (procesos y datos) que
satisfar los objetivos estratgicos de la Organizacin.
Definir los nuevos sistemas a desarrollar que permitan implantar
dicha Arquitectura. La informacin obtenida servir de punto de
partida para el desarrollo de cada uno de estos sistemas con
METRICA Versin 2.
Para el desarrollo de un sistema aislado, cuya necesidad no se derive de
un Plan de Sistemas, no se utilizar la Fase Ode la Metodologa.
14
FASE 1:
INTRODUCCION
ANALISIS DE SISTEMAS
El propsito de esta Fase ser, en primer lugar, describir el alcance, los
objetivos y los requisitos del Sistema. Basndose en todo esto, el equipo
del proyecto puede examinar distintas alternativas que podran solucionar
el problema y recomendar una de ellas. Con la finalizacin del primer
mdulo de esta Fase, Anlisis de requisitos del Sistema, se obtendr, como
producto final, un documento donde se establecer:
El alcance del Proyecto.
El Modelo Lgico Actual (de Datos y de Procesos)
Los requisitos de usuario.
El anlisis de alternativas, y la solucin propuesta.
El segundo objetivo de esta Fase es elaborar un conjunto de
especificaciones formales que describan la funcionalidad del Sistema para
su aprobacin por parte del usuario. Esta descripcin se documentar en
el mdulo siguiente de esta Fase, Especificacin Funcional del Sistema,
que deber incluir:
Definicin de los Subsistemas.
Definicin de los datos del Sistema.
Interfases de usuario y prototipos de pantallas.
Especificacin de la entrega.
INTRODUCCION 15
FASE 2:
FASE 3:
DISEO DE SISTEMAS.
El propsito de esta Fase ser obtener un conjunto de especificaciones
fsicas que constituirn el punto de partida para la construccin del
Sistema.
Durante el desarrollo de las actividades definidas en esta Fase, se deber
tener en cuenta el entorno tecnolgico donde se implantar el sistema.
Este aspecto especfico hace necesaria una adaptacin muy especial de
esta Fase de METRICA Versin 2 al entorno fsico que posea el
Departamento o Unidad de la Administracin que comience a utilizar en
sus proyectos los estndares aqu representados.
Este y otros aspectos a considerar al implantar METRICA Versin 2 en
cada entorno especfico, sern descritos en mayor detalle en el apartado
1.6 de esta Introduccin.
CONSTRUCCION DE SISTEMAS.
El propsito de esta Fase ser construir el sistema partiendo del conjunto
de especificaciones fsicas del mismo, obtenidas durante la Fase anterior.
Asimismo, se contemplar la realizacin de las pruebas unitarias
necesarias para asegurar el perfecto funcionamiento de los programas
desarrollados.
Durante esta Fase se establecer la estrategia para desarrollar los
procedimientos de usuario y el plan de formacin a usuario, identificando
los recursos para su realizacin.
16
FASE 4:
INTRODUCCION
IMPLANTACION DE SISTEMAS.
El propsito de la Fase de Pruebas e Implantacin es probar el equipo
lgico, los procedimientos de usuario y la efectividad de la formacin para
que, una vez aceptado el sistema, se implante y pase a funcionar en un
entorno real de produccin.
El objetivo fundamental es conseguir la aceptacin final del sistema por
parte de los usuarios del mismo, para ello:
Se combinarn por primera vez todo el equipo lgico y los
procedimientos para un trabajo del sistema real.
Se realizarn las pruebas de aceptacin, las cuales constituyen un
procedimiento formal ejecutado por los usuarios que permite
verificar que el sistema producido es totalmente funcional y
satisface los requisitos iniciales, como un paso previo a su
implantacin.
Se realizarn los procedimientos necesarios para la implantacin y
puesta en produccin del sistema.
IMPlANTACION
DE SISTEMAS
1---.....
t====---J SISTEMA A
t.DsltllryreJlizar
Pruobu dol S"""
2. AtllJliW "'an do

3.R..... I..
Pruobu doAcoptaei6n
4. Establ_ Proctdrnionlo.
do Plocllcc:iln
CONSTRUCCION DE SISTEMAS
VISION GENERAL DE LA METOOOLOGIA METRICA 2
DE SISTEMAS ANALlSIS DE SISTEMAS
FASES
MODULOS
t. Dolirir otljotivo ()garl.

atlCWlaI
3 ldonllicar llirOClricos do
GosllnyT_..
4. Disenar ArquitldUra
di la Informacin
5. RNsar stuacim actUal
Sistemas Inlormac:i6n
6. Espocilic. N......
Sistemas
7. Dolirir M m.
...
l. Babor. un Aan di Acd6n
ACTIVIDADES
PlANDE SISTEMAS
DE INFORMACION
5. CCIlsolidar Procedimientos de
Usuario
..-
...,
18 INTRODUCCION
1.4. ORGANIZACION DE LA METODOLOGIA METRICA VERSION 2.
La Metodologa METRICA Versin 2 est organizada en tres guas.
La GUIA DE REFERENCIA es el documento en que se describe el
cuerpo completo de la Metodologa. En l se presenta:
Una definicin de las Fases, Mdulos y Actividades a desarrollar,
incluyendo una serie de grficos que muestran las Actividades
incluidas en cada una de las Fases y la relacin de dichas
actividades con otras a desarrollar anterior o posteriormente.
Una descripcin detallada de cada uno de los Mdulos, incluyendo
las Actividades yTareas correspondientes. Definiendo tambin la(s)
Tcnica(s) a emplear para cada una de ellas.
Una descripcin de los productos finales que debern desarrollarse
al final de cada Mdulo.
Esta gua permitir consultar en detalle aspectos del desarrollo de
proyecto, por ello al ocurrir esto en un nmero limitado de ocasiones, no
ser necesario que cada persona posea una copia de la misma, siendo
suficiente que exista una copia por proyecto o grupo de desarrollo.
La GUIA DE TECNICAS es el documento en el que se describen en
detalle las tcnicas que soportan las distintas fases definidas en METRICA
Versin 2.
De la misma forma que en la gua anterior, ser suficiente una gua por
proyecto o grupo de desarrollo.
La GUIA DE USUARIO, es un resumen del Manual de Referencia que
puede ser empleado para consultas rpidas.
Esta gua ser la que ayudar a las personas involucradas en un proyecto
de desarrollo a seguir los estndares definidos en METRICA Versin 2,
por lo tanto, sera interesante que todos los participantes en proyectos de
este tipo tengan su propia gua de usuario.
INTRODUCCION
1.5. GESTION DE PROYECTOS.
19
METRICA Versin 2 es una metodologa flexible, pensada para permitir que el
Jefe del Proyecto pueda seleccionar aquellos Mdulos y Actividades que cubran
las necesidades especficas del mismo, sil1tener que desarrollarlos todos o hacerlo
con una estructura inadecuada y evitando, de esta manera, la realizacin de tareas
innecesarias.
Teniendo en cuenta esto, se han identificado diferentes tipos de proyectos, segn
su duracin, complejidad, tipo de ciclo de vida, alcance, etc...
Clasificando los proyectos segn sus caractersticas se aportan seis Mapas de
Actividades:
Proyectos Grandes (PG).
Proyectos Pequeos (PP).
Desarrollo Modular (DM).
Prototipado (PI).
Mantenimiento de Sistemas (MS).
Basada en Paquete (BP).
Estos Mapas de Actividades no tienen el propsito de ofrecer un catlogo al que
hay que adaptarse de forma obligatoria, sino que constituyen simplemente una
muestra de la adaptacin de METRICA Versin 2 a determinados ciclos de vida
considerados como estndares.
Una vez decidido el comienzo de un proyecto, se debern emplear los conceptos
aportados en los Mapas de Actividades para construir el Mapa de Actividades
especfico del proyecto.
Esta ser la herramienta que permitir al Jefe de Proyecto decidir, sin salirse del
esquema de METRICA Versin 2, qu actividades se ejecutarn y cuales no, qu
productos finales se obtendrn y cundo, y qu revisiones formales e informales
se realizarn y quin tendr la responsabilidad de ejecutarlas.
Este mecanismo permitir flexibilizar la utilizacin de METRICA Versin 2,
facilitando su implantacin en todo tipo de proyectos.
20 INTRODUCCION
1.6. IMPLANTACION DE LA METODOWGIA METRICA VERSION 2.
En primer lugar, hay que resaltar la importancia que tiene el proceso de
implantacin, en el proyecto de adopcin de nuevos estndares, tcnicas y
herramientas en una Organizacin.
Este proceso determinar el xito o el fracaso de la utilizacin adecuada del
marco metodolgico aportado por METRICA Versin 2.
Las Guas que componen esta metodologa no tienen el propsito de ofrecer en
s mismas un manual metodolgico completo a toda la Administracin. Esto es
porque en la Administracin conviven diferentes entornos, con mquinas, sistemas
operativos, lenguajes de programacin y hasta organizaciones diferentes.
Con esta perspectiva, METRICA Versin 2 define un marco de referencia comn
para el Desarrollo de Sistemas de Informacin en cada uno de los diferentes
entornos. Por ello, en su construccin, se han concretado muchos de los aspectos
asociados a la ejecucin de proyectos informticos, pero dejando una puerta
abierta a la adaptacin de otros aspectos asociados al entorno tecnolgico.
Por esta razn, teniendo en cuenta que la mejor Metodologa es la que se adapta
a las necesidades de cada organizacin, se debern considerar los siguientes
objetivos en el proceso de implantacin de METRICA Versin 2:
(a) Completar los aspectos no cubiertos por las guas que componen
METRICA Versin 2, considerando lenguajes de programacin. sistemas
operativos, bases de datos, tipos de ordenador, . estndares o
procedimientos anteriormente establecidos, estndares sobre
nomenclatura, etc...
(b) Integrar en METRICA Versin 21a utilizacin de las herramientas CASE
que se consideren necesarias.
(e) Considerar el cambio cultural y organizativo que la implantacin de
METRICA Versin 2 tiene asociado, tratando de minimizar el posible
impacto negativo que para los usuarios, personal de desarrollo,
responsables de Unidades, etc., pueda representar el comenzar a trabajar
con nuevos estndares de desarrollo.
MAP Metodologa METRlCA Versin 2
INTRODUCCION 21
Teniendo en cuenta la consecucin de estos objetivos, los pasos a seguir para la
correcta implantacin del entorno definido seran los siguientes:
PASO 1:
PASO 2:
PASO 3:
PASO 4:
Planificacin de la Implantacin yseleccin de herramientas CASE.
Adaptacin de METRICAVersin 2 e integracin de Herramientas
CASE.
Formacin
Desarrollo de Proyecto(s).
Para la realizacin de estos pasos ser de utilidad el soporte externo de un grupo
especializado en Metodologas de desarrollo y tcnicas de modelizacin,
constituido por personal de la Administracin conocedor de METRICA Versin
2, por personal externo o por un grupo mixto.
MAp Metodologa METRICA Versin 2
N
N
GESTION
DE
CAUDAD
r-------
I I
,..---..,1
I
I
I
I
I
'--__..JI
1""""--.. :
GESTION I
DE '
PROYEC :
TOS I
;==:::::
GESTION I
DE I
CONFIGU. I
RACION :
-------'
CASE
IIETRlCA
VERSl0N2
C Lq (VI

1 lIT
GUIA DE TECNICAS
..... PASO2
PASOl
ADAPTACION DE
IIETRlCA
PASO 4
-:
METRICAV.2
VERSl0N2 I
EINTEGRACION DE

I
PLANIACACION
HERRAMIENTAS lTTT
DESARROLLO
-
I
DE LA
CASE
GUIA DE TECNlCAS
DE I
IMPLANTACION
1 T T
PROYECTOS
I
Y
CASE
I
SELECCION

I
DE
I
HERRAMIENTAS
-
I
CASE
I
I
-
PASO3 -:
FORMACION
I
I
I
.
INTRODUCCION 23
PASO 1:
I
PLANIFICACION DE LA IMPLANTACION y SELECCION DE
HERRAMIENTAS CASE.
El propsito de este paso ser elaborar un plan detallado de implantacin
en el que se estimen los recursos involucrados y fechas estimadas de inicio
y finalizacin de cada paso del proyecto de implantacin.
El concepto de metodologa actualmente ha variado con respecto a lo que
esto significaba hace tan slo 3 4 aos. Este cambio ha consistido en
pasar de considerar la Metodologa como un conjunto rgido de actividades
y procedimientos, cuya realizacin daba lugar a un trabajo considerable de
cumplimentacin de formularios e informes preestablecidos, a considerarla
como algo eminentemente flexible y prctico que no tiene por qu
aumentar la carga de trabajo.
Para que una metodologa sea realmente prctica y no solo procedimental,
necesita que se automaticen al mximo las actividades a realizar y la
generacin de la documentacin final de cada Fase o Mdulo.
Estos aspectos los aportan las herramientas CASE, no siendo aconsejable,
actualmente, la utilizacin de Metodologas sin el apoyo automatizado que
aportan las herramientas CASE.
Todo esto es aplicable a METRICA Versin 2. An siendo posible su
utilizacin manualmente, es importante considerar la utilizacin de
herramientas CASE que soporten, de una manera completa, las tcnicas
propuestas en la metodologa.
La integracin de herramientas CASE en METRICA Versin 2 permitir
minimizar el esfuerzo de implantacin y ayudar a que el cambio cultural
no sea demasiado traumtico.
En este paso se evaluarn las posibles herramientas que existen en el
mercado y seleccionarn las ms adecuadas al tipo de entorno y
organizacin.
Se evaluarn herramientas de Planificacin, Anlisis, Diseo, Generacin
de Aplicaciones, Gestin de la Configuracin, Gestin de Calidad, etc.
Asimismo, se definirn los procedimientos de coordinacin necesarios y las
reuniones de seguimiento a realizar durante la implantacin.
24
PASO 2:
INTRODUCCION
ADAPTACION DE METRICA VERSION 2 E INTEGRACION DE
HERRAMIENTAS CASE.
El propsito de este paso ser el relizar la adaptacin de METRICA
Versin 2 a las caractersticas especficas de la Unidad en la que se
implantar.
En este proceso de adaptacin se completarn los aspectos que se
consideren necesarios, incluyendo:
(a) Responsabilidades asignadas a las personas relacionadas con el
desarrollo de Sistemas de Informacin.
Se revisarn las funciones y. responsabilidades inicialmente
presentados en la metodologa, ajustando los aspectos que se
consideren oportunos.
(b) Nomenclatura a utilizar.
Se tendrn en cuenta posibles estndares utilizados anteriormente
en la instalacin y, de manera muy especial, el entorno tecnolgico
que se posea.
Los aspectos ms importantes a considerar sern:
Lenguajes de Programacin.
Herramientas CASE.
Bases de Datos.
Monitor de Teleproceso.
(c) Dependencia del Entorno.
A partir de la Fase 1 ("Anlisis de Sistemas") de METRlCA
Versin 2, la dependencia del entorno aumenta. Por lo tanto se
debern revisar las fases 2, 3 y 4 (Diseo, Construccin e
Implantacin de Sistemas) ajustando los aspectos relacionados con
el entorno tecnolgico.
INTRODUCCION 25
Los aspectos ms importantes a considerar sern:
Lenguaje de programacin.
Tipo de Base de Datos.
Relacin con el departamento de sistemas y paso a
produccin.
Estructura de la aplicacin.
Manera de realizar las pruebas.
En todos estos casos, la diferente problemtica existente entre un entorno
de grandes sistemas, mini o microordenadores, la utilizacin de un
Lenguaje de 3i! generacin o de 4i! generacin, hara que sea necesaria la
matizacin de ciertos aspectos definidos previamente en METRlCA
Versin 2. .
Despus del proceso de adaptacin de METRICA Versin 2, se deber
obtener una versin de la metodologa totalmente adaptada a la
Organizacin, entorno tecnolgico y experiencias anteriores existentes en
la instalacin. Esto garantiza que:
(a) Se posee una metodologa totalmente ajustada y con un gran nivel
de detalle.
(b) Se asegura el seguimiento de la metodologa, ya que sta cubre en
su totalidad toda la problemtica especfica de la Organizacin.
Este proceso de adaptacin no implica el cambio de su estructura
fundamental, (fases, mdulos, tcnicas yproductos finales) de manera que,
an con particularidades diferentes, la estandarizacin en el mbito de la
Administracin se mantiene.
En cualquier caso este proceso de adaptacin no deber durar un periodo
demasiado grande de tiempo, del orden de uno a dos meses.
26
PASO 3:
INTRODUCCION
FORMACION
El propsito de este paso ser preparar al personal directamente
implicado en el desarrollo de proyectos informticos, incluyendo en
algunos casos a usuarios finales, para la realizacin de los mismos.
Para ello ser necesario:
(a) Identificar las necesidades de formacin, segn los perfils de las
diferentes personas implicadas (Jefes de proyecto, Analistas,
Programadores, Usuarios, etc.).
(b) Elaborar los planes de formacin adecuados. Habr que tener en
cuenta que no es aconsejable formar a persnas que no vayan a
utilizar, en la prctica yen un corto plazo, los aspectos tratados en
los cursos de formacin.
(c) Ejecutar el 'plan de formacin, contemplando todos los
componentes incluidos en el nuevo esquema metodolgico:
METRICA Versin 2.
Tcnicas de Desarrollo.
Herramientas CASE.
INTRODUCCION 27
PASO 4: DESARROLLO DE PROYEeros.
El propsito de este paso ser seleccionar el/los proyecto(s) a desarrollar
con METRICA Versin 2.
Las conclusiones que se obtengan de estos primeros proyectos permitirn
ajustar, en caso necesario, la metodologa y la integracin existente entre
herramientas o entre tcnicas y herramientas.
Se debern definir una serie de parmetros que permitan registrar datos
objetivos y cuantificables sobre el avance de la implantacin (nmero de
errores, nivel de modularidad, complejidad de programas, etc.),
permitiendo plantear las bases para una futura Gestin de la Calidad.
La experiencia obtenida de estos proyectos permitir cuantificar el grado
de avance y ayudar a plantear mejoras que hagan evolucionar a
METRICA Versin 2.
Durante estos primeros proyectos se valorar el impacto de la
implantacin y se definirn las acciones a tomar para generalizar la
utilizacin de METRICA Versin 2.
Es importante divulgar las experiencias parciales obtenidas, sobre todo,
para garantizar la continuidad de su utilizacin.
La designacin de una persona (o grupo) coordinadora, responsable o
soporte metodolgico, es un factor fundamental para la total divulgacin
del entorno metodolgico implantado.
La responsabilidad de dicha figura ser la de mantener actualizada, a
partir de las experiencias obtenidas, la propia metodologa.
Sera aconsejable que el tamao de los primeros proyectos desarrollados
no fuera demasiado grande, de manera que se asegure la obtencin de
conclusiones y xitos lo antes posible, o permitiendo la generalizacin de
la utilizacin de METRICA Versin 2 en un plazo limitado de tiempo.
FASE O: PLAN DE SISTEMAS DE INFORMACION
FASE O: PLAN DE SISTEMAS DE INfORMACION
INDICE
31
INTRODUCCION 33
PSI 1:
PSI 2:
PSI 3:
PSI 4:
DEFINIR OBJETIVOS, ORGANIZACION,
AMBITO y PLANIFICACION DEL PROYECTO. . . .. 38
1.1 Especificacin de objetivos
1.2 Identificacin de las Unidades afectadas
1.3 Organizacin de los participantes
1.4 Planificacin del proyecto
IDENTIFICAR LAS NECESIDADES DE
INFORMACION DE LAS UNIDADES
AFECTADAS......................................... 42
2.1 Identificacin de funciones y objetivos
2.2 Identificacin de requisitos
2.3 Identificacin de las necesidades de
informacin
IDENTIFICAR LAS DIRECTRICES DE
GESTION y TECNICAS. 47
3.1 Identificacin de las directrices de gestin
3.2. Identificacin de las directrices tcnicas
DISEAR LA ARQUITECTURA DE LA
INFORMACION. ..................................... 49
MAl - Metodologa METRICA Versin 2
32
4.1
4.2
4.3
Diseo del modelo conceptual de datos
Diseo de la jerarqua de funciones
Diseo de la Arquitectura de la Informacin
PSI 5:
PSI 6:
PSI 7:
PSI 8:
REVISAR LA SITUACION ACTUAL
DE LOS SISTEMAS DE INFORMACION. 56
5.1 Identificacin y descripcin de los
sistemas existentes
5.2 Anlisis del entorno tecnolgico actual
5.3 Diagnstico de la situacin ac.tual
ESPECIFICAR LOS NUEVOS SISTEMAS. . . . . . . . . . . . . . . . . . .. 62
6.1 Identificacin de mejoras en los
sistemas actuales
6.2 Identificacin de nuevos sistemas
6.3 Determinacin de prioridades de
desarrollo
6.4 Especificacin de los sistemas
DEFINIR LAS ALTERNATIVAS
TECNOLOGICAS. . 71
7.1 Identificacinde necesidades
tecnolgicas futuras
7.2 Definicin de opciones tecnolgicas
ELABORAR EL PLAN DE ACCION. 74
8.1 Elaboracin de un plan de implantacin
8.2 Mantenimiento del plan de sistemas
FASE O: PlAN DE SISTEMAS DE INFORMACION
INTRODUCCION
33
La Planificacin de Sistemas de Informacin responde a la necesidad, ampliamente
extendida, de lograr que el tratamiento de la informacin, considerado en trminos de
disponibilidad, ayude a la gestin y flexibilidad y se adapte a los objetivos generales
definidos para cualquier Unidad organizativa de la Administracin.
Con esta perspectiva, los planes de sistemas se encuadran dentro del marco ms general
de la Planificacin Estratgica, como una concrecin a corto y medio plazo de sta.
La Planificacin Estratgica tiene como finalidad principal, definir los objetivos a largo
plazo de una organizacin, en cuanto a servicios futuros a prestar, perspectivas de
crecimiento y previsiones de evolucin, as como estimar las necesidades de informacin
en funcin de dichos objetivos. Para ello se considera tanto la situacin de dicha
organizacin frente a su entorno, como la visin de los responsables de la misma.
La Planificacin de Sistemas se puede considerar como la realizacin "tctica" de los
objetivos estratgicos ya definidos para la Planificacin Estratgica. Para ello, entre sus
caractersticas, se pueden destacar:
Una definicin precisa de los Sistemas de Informacin identificados.
Una planificacin ajustada para la Implantacin de dichos sistemas, considerando
prioridades y recursos necesarios.
De estas dos caractersticas generales se puede deducir como consecuencia lgica que la
Planificacin de Sistemas requiere:
Un mbito organizativo ms restringido que el de la Planificacin Estratgica.
Un horizonte temporal ms limitado que cubra el corto y medio plazo.
Un trabajo sucesivo de refinamiento y revisin, de manera que se pueda valorar
el cumplimiento de los objetivos mximos establecidos por la Planificacin
Estratgica y adecuar dicha planificacin al da a da.
Los objetivos de esta Fase de Planificacin de i s t e ~ s de la Metodologa METRICA
Versin 2 sern:
Definir una serie de puntos bsicos que se han de considerar en la realizacin de
un Plan de Sistemas.
Obtener un conjunto de productos que sirvan de punto de partida de la
Metodologa de Desarrollo de Sistemas.
34 FASE O: PLAN DE SISTEMAS DE INFORMACION
Teniendo esto en cuenta, se ha definido en esta Fase de Planificacin de Sistemas de la
Metodologa METRICA Versin 2, un conjunto de actividades que contemplan:
La definicin de los objetivos y necesidades futuras de las Unidades objeto de
estudio. Esta definicin puede venir dada, como se ha dicho, como resultad de
una Planificacin Estratgica, o en un planteamiento ms pragmtico o inmediato,
por la realizacin de una serie de tareas que se indican en esta Fase.
La especificaCin de los Sistemas de Informacin a desarrollar como resultado de
un anlisis de la realidad actual, en sus vertientes funcional y tecnolgica, con el
fin de cumplir los objetivos y necesidades definidos.
La obtencin de un conjunto de pautas y parmetros para acometer el trabajo de
Desarrollo de los Sistemas especificados. Dichas pautas permitirn establecer la
relacin necesaria entre la Planificacin de Sistemas y la realizacin de las
distintas fases del ciclo de vida de Desarrollo de estos Sistemas.
Entre estas pautas podemos destacar, para cada sistema:
Definicin de los objetivos.
Viabilidad del sistema.
Marco norIt:lativo o trminos de referencia.
r ~ v descripcin del sistema.
Como resultado final se obtendr un conjunto de sistemas a desarrollar, con la
especificacin de sus prioridades, as como una planificacin inicial de los mismos. Esta
planificacin se ir refinando a medida que se acometa la construccin de dichos sistemas
y se establezcan puntos de control, coincidiendo con la finalizacin de los distintos
mdulos y fases de que consta la Metodologa METRICA Versin 2.
A continuacin se representa la interrelacin del Plan de Sistemas con el Plan
Estratgico y las fases de Desarrollo de S!stemas.
Por ltimo, es necesario destacar que en la realizacin de las actividades de esta fase, es
imprescindible la participacin de los responsables de las Unidades implicadas, dado que
a ellos corresponde el definir los objetivos y estrategias de evolucin de dichas Unidades,
as como el patrocinar todos los trabajos encaminados a obtener un plan de sistemas que
permita afrontar los retos de un entorno en constante evolucin.
::
en
tt1
>
R'
'I:l
g
,
:::
...
5'
en
CIQ
;
;-
ti!
----------
ANALlSIS
en
tl
n
tt1
>
PLAN
.-
...
e
z
;
...
o:
z
o
:>
ESTRATEGICO

DISEO
'"
",
o
o o
-.
m
<
DE
----------
.-
O
w
O O
Z
...
z
ONSTRUCCION
JI
SISTEMAS <
O ..J
.. lL
----------
-.
DE

INFORMACION ----------
IMPLANTACION
.... -
DOCUMENTO FIN DE FASE
PLAN DE MANTENIMIENTO
PLAN DE SISTEMAS DE INFORMACION (FASE O)
ACCIONES DE CONTROL
DE CALIDAD

Espeolieaci0n6s

Espec:llcacianes

Espealicaaones
ACCIONES DE DIRECCION
ACCIONES DE GESTION
DE PROYECTO
1.30ganillcitlndllosp.lrticipartes
1.4PlariIQndllpropdO
SEGuPUENTO y CCtlTROL
1l.18aborKi6ndllMpIan

8.2 Uaruni,rrienIo dII pWl
.....".
::::
>
."
[
g.
O
QQ
n
>
i
::l
N
3.1klenlil.Direcl'Icn
..-
.21dentif. Directioes
T-..
mErmARhGRAflCO
n REY1SION INFORMAl
V (no_lnrol
REVlSION FOAIIAL
'1' {_Innol
-

!UDi.gn6slico de l.
Siu06nactal
1l.2k11n1f.
U __priorido
dtsdednirr<Jla
1.4 Eapecificaci6nSislelT8l
FIN
FUNCIONES Y NIVEL DE RESPONSABILIDAD
PLAN
ACTIVIDADES
DE SISTEMAS
DE INFORMACION
1 2 3 4 5 6 7 8
COMITE DE DIRECCION
D,R R R F
DIRECTOR PROYECTO
R R R R R R R F
GRUPO DE CALIDAD
R F
GRUPO DE USUARIOS
I I I I I I
DEPARTAMENTO DE TI
A A
Especialistas en Sistemas
...... ...... ........ ...... ....... ........ ........ .......
Responsables Tcnicos
I I I I I I
EQUIPO DE PROYECTO
E
Jefe de Proyecto
E E
E E E E E
...... ...... ........ ....... ...... ....... ........ .......
Componentes Equipo
E E E E E E E
37
CLAVES:
A. Asistencia Tcnica
D Dotar Recursos
E Ejecucin
F Revisin Formal
R Revisin Informal
I Suministra Informacin
ACTIVIDADES:
1. Definir Objetivos. Organizacin. Ambito
y Planificacin del Proyecto
2. Identilicar las necesidades de informacin
de las Unidades afectadas
3. Identificar las Directrices de Gestin y Tcnicas
4. Disenar la Arquitectura de la Informacin
5. Revisar la situacin actual de los Sistemas
de Informacin
6. Especificar los nuevos sistemas
7.. Definir las alternativas tecnolgicas
8. Elaborar un Plan de Accin
38 FASE O: PlAN DE SISTEMAS DE INFORMACION
ACfIVIDAD PSI 1: DEFINIR OBJETIVOS, ORGANIZACION, AMBITO y
PLANIFICACION DEL PROYECfO
DESCRIPCION;
En esta actividad se establece y define el marco general de referencia para el Proyecto
de Realizacin de un Plan de Sistemas.
Los aspectos bsicos a considerar en dicho marco de referencia sern, entre otros:
La definicin de la Unidad organizativa objeto de estudio.
La posible existencia de un Plan Estratgico de Sistemas de Informacin a largo
plazo para dicha Unidad o la Organizacin que la engloba.
El plazo de tiempo considerado para la puesta en prctica de este plan de
sistemas.
Los participantes en dicho proyecto.
La planificacin del proyecto.
Como se ha indicado en la introduccin de esta fase, la posible existencia de un Plan
Estratgico de Sistemas de Informacin dentro de la Organizacin determinar en gran
medida el alcance y la extensin de las actividades que se realicen en esta fase.
TAREA PSI 1.1; ESPECIFICACION DE OBJETIVOS
DESCRIPCION y OBJETIVOS:
Los objetivos de esta tarea son los siguientes:
Determinar el alcance del plan de sistemas, detallando los objetivos a alcanzar
con el mismo y diferencindolos en el horizonte temporal: corto, medio y largo
plazo.
Un ejemplo de esta especificacin de objetivos sera:
Determinar las aplicaciones actualmente existentes cuya mejora funcional
se podra acometer a corto plazo.
fASE O: PLAN DE SISTEMAS DE INFORMACION
Especificar los antecedentes del plan de sistemas:
La existencia de un plan estratgico dentro de la Organizacin.
Plan de sistemas anterior, si lo hubiera.
Planes de Actuacin Ministerial o del Departamento o Unidad.
PRODUCfOS A OBTENER:
Especificacin detallada de objetivos del plan.
39
Recopilacin del conjunto de documentacin existente en la Unidad o en la
Organizacin.
TECNICA:
Entrevistas con el Director del Proyecto.
TAREA PSI 1.2: IDENTIFICACION DE LAS UNIDADES AFECfADAS
Identificar las Unidades objeto de estudio.
El trmino de Unidades se utiliza en un sentido general para recoger diferentes
mbitos de la organizacin dentro de la Administracin (Direcciones Generales,
Organismos Autnomos, Subdirecciones, etc.).
Es importante destacar que un Plan de Sistemas debera centrarse en un nmero
limitado de Unidades dentro de la Administracin, ya que un estudio demasiado
global o amplio puede hacerse muy generalista o extenderse demasiado en el
tiempo de su ejecucin.
Especificar las caractersticas generales de dichas Unidades.
Esta especificacin nos permitir obtener un Perfil general de la Unidad en
estudio y contendr informacin sobre los servicios proporcionados po.r dichas
Unidades (atencin al pblico, servicios generales dentro de la Administracin,
etc.), su localizacin geogrfica ysobre sus caractersticas organizativas, de gestin,
etc.
PRODUcrOS A OBTENER:
Perfil general de las Unidades objeto de estudio, incluyendo:
Informacin preliminar sobre los servicios y funciones realizadas.
Distribucin de las Unidades en cuanto a su localizacin geogrfica.
TECNICA:
Entrevistas con los responsables de la Unidad.
TAREA PSI 1.3: ORGANIZACION DE LOS PARTICIPANTES
DESCRIPCION y OB.IETIVOS:
Determinar los Organos involucrados en la gestin, realizacin, seguimiento y
actualizacin del Plan de Sistemas.
Definir las funciones y responsabilidades de los Organos participantes, los cuales
sern:
Comit de Direccin.
Constituido por los responsables de la Unidad o de las Unidades a las que
afecta el Plan, as como por los responsables de la gestin dentro de la
Unidad. Tambin ser importante la participacin de responsables de los
servicios comunes de la Administracin (Programacin y Presupuestacin,
Recursos Humanos, etc.).
En todo caso, la composicin del Comit de Direccin depender de las
caractersticas del Sistema.
Director del Proyecto.
41
Ser un Directivo de alto nivel, responsable de Sistemas de Informacin
o, en su defecto, con la responsabilidad de Planificacin o de
Coordinacin.
Equipo de,1 Proyecto.
Formado por personal de Tecnologa de la Informacin y personal tcnico
cualificado de la Unidad.
Si el Proyecto se hiciese con asistencia tcnica externa, el personal
consultor correspondiente se integrara en este Equipo de Proyecto.
Grupo de Usuarios.
Formado por distintos usuarios de alto nivel dentro de las Unidades a las
que afecta el Plan de Sistemas. Asmismo, adems habr expertos de los
servicios comunes de la Administracin (Programacin y Presupuestacin,
Recursos Humanos, etc.)
Especialistas en Sistemas.
Eventualmente se requerir la participacin de especialistas en tecnobgfas
de la informacin (comunicaciones, equipos fsicos, equipos lgicos) para
la realizacin de determinadas actividades dentro del plan.
Grupo de Calidad.
Constituido por personal con conocimientos en metodologas de
Planificacin y con experiencia en las competencias principales de la
Unidad. Su misin ser verificar que los trabajos del plan se realizan de
acuerdo a la metodologa aqu definida y validar el cumplimiento de las
funciories y objetivos de la Unidad.
La constitucin de estos Comits y Grupos depender de las caractersticas de
tamao y complejidad de la Unidad a la que afecta el Plan.
Elaborar una lista inicial de personal a entrevistar, con el fin de obtener
informacin del funcionamiento de la Unidad.
Comunicar al personal identificado en el punto anterior los objetivos del proyecto.
42
PRODUCTOS A OBTENER;
Organizacin de los diferentes equipos de participantes.
Lista inicial de personal participante.
TAREA PSI 1.4; PLANIFICACION DEL PROYECTO
DESCRIPCION y OBJETIVOS;
Elaborar el calendario de realizacin de las distintas actividades y tareas del Plan,
en funcin de los objetivos definidos y de las caractersticas identificadas en el
marco de referencia (la existencia o no de un Plan Estratgico, la dimensin de
las Unidades a tratar, etc.).
Asignar los recursos necesarios (humanos, tcnicos y materiales, etc.) para la
realizacin del plan.
Establecer un calendario de seguimiento, definiendo: fechas de las reuniones del
Comit de Direccin, plan de entrega de los productos del plan, posibles
modificaciones en los objetivos marcados por el plan, planes de revisin por el
.grupo de calidad, etc.
Cronograma del proyecto.
ACTIVIDAD PSI 2: IDENTIFICAR LAS NECESIDADES DE INFORMACION
DE LAS UNIDADES AFECTADAS
DESCRIPCION;
En .esta actividad se estudia el sistema actual de manera global, en relacin con las
funciones generales que realiza y sus relaciones con el entorno, as como sus objetivos
FASE O: PlAN DE SISTEMAS DE INFORMACION 43
y tendencias de evolucin. Con esto se profundiza en el estudio iniciado en la actividad
anterior y que haba producido el Perfil general de la Unidad.
Del estudio y recopilacin de los objetivos y nuevos servicios y funciones a desarrollar
por la Unidad, se extraen los requisitos que se deben cumplir para alcanzar dichos
objetivos y se definen prioridades para dichos requisitos.
. Estos requisitos, juntamente con la visin de los responsables de tratamiento de la
informacin y de la gestin de la Unidad, darn lugar a una aproximacin inicial a las
necesidades futuras de informacin.
En el caso de que el mbito del Plan de sistemas abarque varias Unidades, se podr, en
funcin de la complejidad y dimensiones de las mismas, acometer la realizacin del plan
en distintas fases:
Realizar un estudio global, a grandes rasgos, del conjunto de las Unidades,
haciendo especial nfasis en la interrelacin entre las mismas.
Realizar las distintas actividades de esta Fase 0, para cada una de las Unidades
identificadas.
Integrar los resultados del estudio.
Como consecuencia de la realizacin del Plan de Sistemas puede aparecer la necesidad
de reorganizar las Unidades a que afecta dicho Plan, con el fin de eliminar
disfuncionalidades y conseguir un mejor aprovechamiento de los recursos y servicios.
Si en la Unidad objeto de estudio se hubiese realizado un Plan Estratgico de
informacin, los resultados del mismo contendran todos los productos obtenidos en esta
actividad, eliminando as la necesidad de realizacin de la misma.
TAREA PSI 2.1: IDENTIFICACION DE FUNCIONES Y OBJETIVOS
Representar, mediante un modelo de alto nivel, el posicionamiento de la Unidad
frente a su entorno (Diagrama de Contexto).
Identificar las principales actividades y funciones (de operacin y de decisin)
relacionadas con los recursos y servicios proporcionados por la Unidad.
Para realizar esta labor se tomar como punto d partida el Perfil general de la
Unidad, obtenido en la Actividad PSI 1("Definir Objetivos, Organizacin, Ambito
y Planificacin del Proyecto"), y se profundizar en el estudio de la misma.
Se representar grficamente el flujo de informacin a travs de la Unidad, con
objeto de diferenciar las funciones de gestin y decisin, de las de o
tratamiento de la informacin.
Documentar los objetivos y las oportunidades de evolucin futura de la Unidad,
tanto por normativa legal (nuevos servicios proporcionados por la Administracin)
como por las mejoras consideradas necesarias en la gestin de los servicios y
recursos.
Diagrama de Contexto de la Unidad.
Representacin grfica de las funciones realizadas por la Unidad y del flujo de
informacin a travs de las mismas.
Lista de funciones y objetivos de la Unidad.
TECNICAS;
Entrevistas'y reuniones en grupo con los responsables de la Unidad.
Diagramas de flujo de datos (Diagrama de Contexto).
TAREA PSI 2.2; IDENTIFICACION DE REQUISITOS
Documentar la visin de los responsables de la Unidad con respecto a los
servicios proporcionados y los recursos manejados: puntos fuertes y dbiles,
prioridades de mejora, calidad de la informacin disponible y cobertura
FASE O: PlAN DE SISTEMAS DE INFQRMACION 45
proporcionada por los sistemas de tratamiento de la informacin para los servicios
y recursos manejados.
Identificar los requisitos que se deben satisfacer para que la Unidad cumpla los
objetivos identificados y definir prioridades para dichos requisitos.
Una buena aproximacin a la identificacin de requisitas puede ser el considerar
los factores estratgicos (fines de la Unidad), operativos (mejor gestin) y legales.
Esta identificacin y priorizacin de requisitos constituye un punto bsico de cara
a definir una mtrica que ayude a evaluar los nuevos sistemas y definir sus
prioridades de implantacin en el futuro Plan de Sistemas. Para realizar esta tarea
se utilizarn tcnicas como los Factores Crticos de Exito.
PRODUCTOS A OBTENER:
Lista inicial de problemas y necesidades.
Lista inicial de posibles mejoras en los sistemas de informacin.
Catlogo de requisitos, con sus prioridades.
TECNICAS;
Entrevistas con los responsables de la Unidad.
Reuniones en grupo con los responsables de la Unidad.
Factores crticos de xito.
TAREA PSI 2.3; IDENTIFICACION DE LAS NECESIDADES DE INFORMACION
Identificar los puntos crticos actualmente existentes en cuanto a volumen de
tratamiento, frecuencia de tratamiento, caractersticas de respuesta, ayuda a la
toma de decisiones, etc. Aqui se especifica en detalle la visin general obtenida
sobre la cobertura proporcionada por los sistemas de tratamietnto de la
informacin, apuntada en la tarea anterior.
Documentar la visin de los responsables de la Unidad y de tratamiento de la
informacin .en cuanto a posibles mejoras de los sistemas para satisfacer los
objetivos de la Unidad y evaluar, en lneas generales, el probable impacto de
dichos objetivos en la funcin de tratamiento de la informacin, identificando
posibles escenarios futuros, en funcin de las expectativas y planes de los
responsables (oportunidades de descentralizacin, gestin departamental de la
informacin, etc.).
Con este punto se pretende iniciar una aproximacin al fin ltimo de un Plan de
Sistemas: conseguir la adecuacin del Sistema de Informacin de la Unidad a sus
necesidades de gestin y servicio, de una manera flexible e integrada.
Para conseguir esto se realizarn entrevistas individuales con los responsables de
tratamiento de la informacin y responsables de la Unidad y se consolidarn los
resultados con el Comit de Direccin.
Lista inicial de problemas y necesidades.
Lista inicial de posibles mejoras en los sistemas de informacin.
Documentacin del posible impacto de los objetivos de la Unidad sobre los
sistemas de informacin (posibles escenarios identificados).
TECNICA;
Entrevistas y reuniones en grupo con los responsables de tratamiento de la
informacin y responsables de la Unidad.
ACTMDAD PSI 3: IDENTIFICAR LAS DIRECTRICES DE GESTION y
TECNICAS
DESCRIPCION:
47
La realizacin de esta actividad permite establecer los trminos de referencia de la
Unidad desde el punto de vista de estndares y procedimientos.
Es conveniente hacer nfasis en la realizacin de esta actividad, dado que esta
recopilacin de estndares facilita la tarea de elaboracin de un diagnstico de la
situacin actual, en la Actividad PSI 5 ("Revisar la situacin actual de los sistemas de
informacin").
En el caso de que se detecte la necesidad de definir determinadas directrices, debido a
su no existencia o a la obsolescencia de las existentes, sera funcin del Comit de
Direccin del Proyecto, asistido por el Equipo de Proyecto, la decisin de acometer otros
proyectos para la definicin de nuevas directrices.
.La .realizacin inicial en la Unidad de un Plan Estratgico de la Informacin
prop.orcionara el conjunto de directrices tcnicas y de gestin de la organizacin,
eliminando as la necesidad de realizacin de esta actividad.
Por ltimo, la identificacin de estas directrices puede dar lugar a nuevos requisitos para
los nuevos sistemas que se identifican. Estos requisitos se aadirn a la lista inicial
elaborada en la actividad anterior.
TAREA PSI 3.1: IDENTIFICACION DE LAS DIRECTRICES DE GESTION
Determinar el marco normativo en que se desarrollan las funciones y actividades
de la Unidad. Con este fin se recoger informacin sobre los siguientes estndares
y procedimientos, entre otros:
Poltica de Recursos Humanos..
Directrices de Gestin de Calidad.
Poltica Presupuestaria.
Poltica de Contratacin y Adquisicin de material.
Poltica de Auditoras.
Directrices de Planificacin.
Directrices de Gestin de Cambios.
Esta tarea permitir detectar las carencias del marco normativo existente actualmente
en la Unidad y formar parte del conjunto de ''Trminos de Referencia" en que se han de
desarrollar los nuevos sistemas que resulten de la realizacin del plan.
De la deteccin de las carencias y necesidades en cuanto a las directrices de gestin, se
obtendrn nuevos requisitos que vendrn a completar el catlogo de requisitos.
Recopilacin de polticas y directrices de gestin.
Catlogo de requisitos.
TECNICA:
Entrevistas con los responsables y usuarios de la Unidad y de tratamiento de la
informacin.
TAREA PSI 3.2: IDENTIFICACION DE LAS DIRECTRICES TECNICAS
Determinar el marco normativo en que se desarrollan las funciones y actividades
de la Unidad. Con este fin se recoger informacin sobre los siguientes estndares
y procedimientos, entre otros:
Polticas tcnicas:
FASE O: PLAN DE SISTEMAS DE INFORMACION 49
Gestin de Proyectos (seguimiento, revisin y aprobacin final).
Desarrollo de Sistemas (existencia de normativas, metodologas y
tcnicas de programacin).
Arquitectura de Sistemas (centralizada, distribuida).
Poltica de Seguridad (control de accesos, integridad de datos,
disponibilidad de aplicaciones).
Esta tarea permitir, por un lado, detectar las carencias del marco normativo existente
actualmente en la Unidad y, por otro lado, formar parte del conjunto de "Trminos de
Referencia" en que se han de desarrollar los nuevos sistemas que resulten de la
realizacin del plan.
De la deteccin de las carencias y necesidades en cuanto a las directrices tc:nicas, se
obtendrn nuevos requisitos que vendrn a completar el catlogo iniciado en la actividad
anterior.
Recopilacin de polticas y directrices tcnicas.
Catlogo de requisitos.
TECNICA:
Entrevistas con los responsables del tratamiento de la informacin.
ACTMDAD PSI 4: DISEAR LA ARQUITECTURA DE LA INFORMACION
DESCRIPCION
La realizacin de esta actividad requiere un alto grado de abstraccin, ya que su objetivo
es, eliminando toda consideracin fsica sobre los sistemas actuales, obtener un conjunto
de modelos funcionales y de informacin que proporcionen una representacin rigurosa
y estructurada de los requisitos y necesidades futuras de informacin dentro de la
Unidad, con el fin ltimo de construir, de la manera ms detallada posible, la
Arquitectura de la Informacin o bosquejo de los futuros sistemas que sea lo ms
independiente posible de eventuales cambios organizativos.
Por estas razones, se han de cumplir una serie de condiciones en la realizacin de esta
actividad:
La participacin activa de los usuarios y responsables expertos en el
funcionamiento de la Unidad, sus necesidades ysu posible evolucin, que asesoren
al Equipo de Proyecto en la realizacin de los modelos.
La participacin, dentro del Equipo del Proyecto, de especialistas en estrategia
que den una visin "top-down", de arriba a abajo, de los posibles escenarios de
evolucin de los Sistemas de Informacin.
El encaje de los modelos y de la arquitectura de informacin obtenida, dentro de
la cultura de la Organizacin, de manera que tenga en cuenta todo el entorno de
referencia que se ha venido construyendo en las actividades anteriores.
La existencia de un Plan Estratgico de Informacin de la Unidad, servira como punto
de partida para el desarrollo de las tareas de esta actividad, pero no eliminara la
necesidad de su realizacin, toda vez que no tendra el suficiente grado de detalle
requerido en esta actividad, dada la condicin ms generalista de los Planes Estratgicos.
PSI1 :DEFINIR OBJETIVOS,ORGANI
ZAcION,AMBITO v PlANln
CACION Del PROVECTO
12. IdentifICacin de las
Unidades aledadas
PSI2:IDENTIFlCAR LAS NECESIDADES
DE INFORMACION DE LAS
UNIDADESAFECTADAS
PSI4:DISEAR LA ARQUITECTURA DE
LA INFORMACION
4.1. Disea del modela canceplual
de dalas
42. Disea de la jerarqula
delunc:lanes
-
PSI5:REVISAR LA SITUACION
ACTUAl DE LOS SISTEMAS
DE INFORMACION
2.1. Identificacin de
!unciones yobjetivos
22. Identificacin de
requisk06
2.3. Identificacin de las
necesidades de
inlcnnaci6n
1:::1
r=:J
4.3. Disea de la Arqukec:tura
de la Irlannaci6n
PSI6:ESPECIRCAR LOS NUEVOS
_ SISTEMAS
UI
...
52
TAREA PSI 4.1: DISEO DEL MODELO CONCEPTUAL DE DATOS
Identificar las entidades de datos del Sistema. Se define entidad de datos como
todo objeto sobre el que se desea almacenar informacin .
Para identificar las entidades de datos del sistema ser de utilidad estudiar los
recursos utilizados por el mismo, los documentos actualmente existentes, as como
las necesidades futuras de informacin y los requisitos que se han de cumplir para
satisfacer los objetivos de la Unidad. Por ello en esta labor participar no slo
personal tcnico de tratamiento de la informacin, sino que adems es necesaria
la participacin de gestores con conocimiento profundo de la Unidad y de sus
necesidades.
En una primera aproximacin se pueden identificar "clases" de datos en funcin
de la relacin lgica entre los mismos (pertenecen a ficheros comunes, son
utilizados por los mismos procesos o funciones, etc.).
El grado de detalle que se alcance en la identificacin de entidades influir en el
diseo de la jerarqua de funciones que se llevar a cabo paralelamente en la
Tarea 4.2 ("Diseo de la Jerarqua de Funciones"), dado que el objetivo final es
construir la Arquitectura de la Informacin, es decir, determinar qu procesos o
funciones utilizan qu entidades.
Definir las asociaciones entre las entidades identificadas anteriormente.
Diseo del modelo conceptual de datos.
Con este modelo conceptual se representan de manera grfica, las entidades de
datos o clases de datos identificados y las asociaciones entre ellas. Esto constituye
el modelo de informacin de la Unidad, que ha de satisfacer las necesidades de
informacin futuras y que, debido a su grado de abstraccin, no est sujeto a
ninguna restriccin del entorno tecnolgico.
Lista de entidades o clases de datos dentro de la Unidad, con sus descripciones.
Modelo conceptual de datos de la Unidad.
fASE O: PlAN DE SISTEMAS DE INFORMACION
TECNICAS
53
Entrevistas con los responsables y usuarios de la Unidad y responsables de
tratamiento de la informacin. .
Modelo entidad-relacin.
TAREA PSI 4.2: DISEO DE LA JERARQUIA DE FUNCIONES
DESCRIPCION y OBJETIVOS
Identificar en detalle las funciones de la Unidad.
A partir de la visin general realizada en las Tareas 1.2 ("Identificacin de las
Unidades Afectadas") y 2.1 ("Identificacin de Funciones y Objetivos"), se procede
a especificar en detalle las funciones realizadas en la Unidad objeto d.e estudio.
Para ello ser de utilidad seguir las recomendaciones que se indican a
continuacin:
Se seguir el criterio de representar las funciones desde un punto de vista
lgico (qu es lo que se hace en la Unidad), independientemente de la
organizacin de la misma.
Una ayuda para realizar esta Tarea vendr dada por el grado de detalle
alcanzado en la Tarea PSI 4.1 ("Diseo del modelo conceptual de datos"),
la cual se realizar en paralelo con sta.
Se incluirn las funciones definidas para satisfacer los requisitos
especificados en las actividades anteriores.
Disear la jerarqua de funciones.
El procedimiento de disear una jerarqua de funciones es, como la identificacin
de dichas funciones, altamente subjetivo, dependiendo en gran medida de la
habilidad y experiencia de la persona que la realiza.
Por esta razn, es necesaria en esta tarea, la participacin de gestores con un
conocimiento profundo de la Unidad y de sus necesidades.
As, se pueden identificar funciones en relacin con el ciclo de vida de las
entidades o clases de datos dentro de la Unidad: funciones que crean o utilizan
estas entidades.
El grado de descomposicin de la jerarqua de funciones, vendr dado por el
grado de detalle alcanzado en el modelo conceptual de datos.
Elaborar un modelo de funciones.
Adems del .modelo jerrquico o descomposicin funcional, ser de utilidad
elaborar un modelo de las principales funciones de la Unidad (las que estn en
el nivel ms alto de la jerarqua), que muestre el flujo de informacin entre las
mismas. Para ello se emplear la tcnica del Diagrama de Flujo de Datos (DFD).
Para cumplir este objetivo se puede tomar como punto de partida la
representacin grfica del flujo de informacin entre sistemas, obtenido' en la
Tarea PSI 2.1 ("Identificacin de funciones y objetivos").
PRODUcrOS A OBTENER;
Catlogo de funciones de la Unidad.
Diagrama de descomposicin funcional (diseo de la jerarqua de funciones).
Diagrama de modelo de funciones de la Unidad.
TECNICAS;
Entrevistas con los responsables y usuarios de la Unidad.
Diagrama de Flujo de Datos (DFD).
TAREA PSI 4.3; DISEO DE LA ARQUITECfURA DE LA INFORMACION
Disear la Arquitectura lgica de la informacin.
FASE o: PLAN DE SISTEMAS DE INFORMACION ss
Se representan conjuntamente las funciones identificadas y las. entidades o clases
de datos. Para ello se puede utilizar una tcnica tipo Matriz EntidadFuncin, que
muestra el tratamiento lgico de la funcin sobre la entidad:
C: Crea
U: Usa
Es importante destacar que cuanto ms se haya detallado en la identificacin de
entidades y funciones, el diseo de la arquitectura lgica resultante ser tanto ms
estable e independiente de los posibles cambios en la organizacin.
La arquitectura lgica obtenida servir de base para:
Efectuar un diagnstico de la situacin actual de los Sistemas de
Informacin de la Unidad, lo que se realiza en la Actividad PSI 5 ("Revisar
la situacin actual de los Sistemas de Informacin")
Identificar los nuevos sistemas de informacin, lo que se realiza en la
Actividad PSI 6 ("Especificar los nuevos sistemas")
Diseo del modelo organizativo.
En funcin de las necesidades de informacin identificadas en la Tarea PSI 2.3
("Identificacin de las necesidades de informacin"), se puede realizar otro modelo
complementario de la Arquitectura de la Unidad que muestre la correlacin de
las funciones y entidades con la localizacin geogrfica de fas mismas.
Este modelo, conjuntamente con el anterior, servir de punto de partida para la
realizacin de las Actividades PSI 5 YPSI 6.
Identificar nuevos sistemas a partir de la Arquitectura de Informacin.
A partir de la Arquitectura Lgica de la informacin y los requisitos identificados,
se har una primera especificacin de los nuevos sistemas. Los criterios para
realizar esta labor son, entre otros:
Agrupar las funciones que crean y usan las mismas entidades y clases de
datos.
Homogeneidad de las funciones.
Localizacin geogrfica de los procesos.
Y, la experiencia y el juicio del equipo de proyecto junto con los usuarios.
56
PRODUcroS A OBTENER
Diseo de la Arquitectura Lgica de la Informacin.
Diseo de un Modelo Organizativo.
Identificacin inicial de los nuevos sistemas.
TECNICAS
Tcnicas matriciales, como:
Procesos-Entidades, Procesos-Organizacin.
ACfIVlDAD PSI S REVISAR LA SITUACION AcruAL DE LOS SISTEMAS DE
INFORMACION
DESCRIPCION
En esta actividad se realizar un estudio global o de conjunto sobre todos los Sistemas
de Informacin existentes en la Unidad, de manera que, sin entrar excesivamente en
detalle, se pueda contar con los elementos de juicio suficientes para realizar un
diagnstico.
El objetivo bsico en la realizacin de esta actividad es obtener conclusiones, fundadas
en la experiencia y juicio del Equipo de Proyecto, sobre la adecuacin de los sistemas
actuales a las necesidades de informacin de la Unidad. Estas conclusiones incluirn los
puntos fuertes y dbiles detectados y, si se mostrasen debilidades importantes, se
deberan identificar mejoras a corto plazo.
La responsabilidad principal en la ejecucin de esta actividad recaer sobre el Equipo
de Proyecto que trabajar conjuntamente con el personal de Sistemas de Informacin de
la Unidad. Es importante la asistencia de personal s p ~ i l i s t en tecnologa (equipo
lgico, fsico, etc.), dado que las recomendaciones futuras se basarn en los resultados
del estudio realizado en esta actividad.
La existencia de un Plan Estratgico de Sistemas de Informacin dentro de la Unidad,
proporcionara una primera aproximacin para el desarrollo de las tareas de esta
actividad.
MAP. Metodologa METRICA Versin 2
PSIS:REVlSAR LA SITUACION ACTUAL DE
LOS SISTEMAS DE INFORMACION
15.1. Identificacin y descripcin
1- delos sistemas exislenles
PSI2:IDENTIFICAR LAS NECESIDADES
UNIDADES AFECTADAS
PSI6:ESPECIFICAR LOS NUEVOS
15.2. Anlisis del enlomo tecnolgico

SISTEMAS
actual
PSI4: DISEflAR LA ARQUITECTURA
DE LA INFORMACION 15.3. Diagnstico delasituacin
1
actual

t.::J
TAREA PSI 5.1: IDENTIFICACION y DESCRIPCION DE WS SISTEMAS
EXISTENTES
Realizar un inventario de aplicaciones en el entorno actual.
Para cada una de las aplicaciones existentes en el entorno actual se estudian los
siguientes aspectos:
Funciones que realiza.
Ficheros de datos que maneja.
Relaciones con otros sistemas o aplicaciones.
Los resultados de este estudio permitirn establecer una correspondencia entre
las aplicaciones actuales y los ficheros de datos que manejan. Para ello se puede
construir una matriz "Aplicaciones-Ficheros de Datos". Esta mattiz servir en la
Actividad PSI 6 ("Especificar los Nuevos Sistemas") para establecer prioridades
de desarrollo.
Asmismo, el estudio de las aplicaciones actuales ayudar a determinar las
posibilidades de mantenimiento correctivo, perfectivo o adaptativo de las mismas,
de cara a la Actividad PSI 6 ("Especificar los Nuevos Sistemas").
Describir brevemente las caractersticas tcnicas de las aplicaciones existentes.
Se har un estudio preliminar de cada una de las aplicaciones existentes, en su
aspecto tecnolgico. Los resultados de esta visin preliminar se detallarn en
profundidad en la Tarea PSI 5.2 ("Anlisis del Entorno Tecnolgico Actual").
Identificar los proyectos en desarrollo.
Para cada uno de los proyectos en desarrollo se estudiarn las caractersticas
apuntadas en los apartados anteriores.
PRODUcroS A OBTENER
S9
Para cada aplicacin: Descripcin breve de sus funciones, relaciones con otras
aplicaciones, posibilidades de adaptacin y caractersticas tecnolgicas.
Correlacin entre las aplicaciones y los ficheros de datos que utilizan.
TECNICAS
Entrevistas con personal de tratamiento de la informacin.
Tcnicas matriciales (como: Aplicaciones-Ficheros de Datos).
TAREA PSI 5.2: ANALISIS DEL ENTORNO TECNOLOGICO ACfUAL
Realizar un inventario y evaluacin de los principales componentes tecnolgicos
que existen actualmente, as como los que se piensan incorporar a la Unidad. Se
consideran los siguientes aspectos:
Equipo fsico:
Comunicaciones:
Equipo Lgico:
Gestin de datos:
Procesadores, dispositivos de
almacenamiento, ordenadores
personales, estaciones de trabajo, etc.
Controladores de red, interfases
externas, protocolos, procedimientos de
respaldo, cargas actuales, etc.
Sistemas operativos, logical de red,
generadores de aplicaciones, lenguajes
de consulta, facilidades para el
desarrollo de aplicaciones,
herramientas CASE, etc.
Sistemas de gestin de bases de datos,
diccionarios de datos, etc.
60
Operciones en
explotacin:
Herramientas de control de trabajos,
planes de contingencia, gestin de red,
etc.
Se valorar para cada uno de estos componentes su efectividad y el grado de
integracin entre los mismos.
Analizar, para cada uno de los componentes identificados, la capacidad actual y
los perfiles de utilizacin en perodos normales y de carga de trabajo crtica.
Evaluar el grado de aprovechamiento de esta tecnologa. En funcin de las futuras
necesidades de informacin identificadas en la Tarea PSI 2.3 ("Identificacin de
las necesidades de informacin"), as como de las perspectivas de evolucin de la
Unidad, Tarea PSI 2.1 ("Identificacin de. Funciones y Objetivos"), se podr
elaborar una proyeccin de crecimiento del entorno tecnolgico actual y las
necesidades de recursos adicionales.
En estas actividades el equipo de proyecto deber ser asistido por especialistas en
tecnologa, que ayuden a valorar aspectos como la obsolescencia, idoneidad y
perspectivas de futuro para cada uno de los componentes tecnolgicos
identificados.
Perfil de los componentes del entorno tecnolgico actual, incluyendo, entre otros
aspectos:
Descripcin.
Capacidad actual.
Grado de integracin con otros componentes del entorno.
Utilizacin en perodos normales y crticos.
Perspectivas de futuro.
TECNICA:
TAREA PSI 5.3: DIAGNOSTICO DE LA SITUACION ACTUAL
61
Estudiar la adecuacin de los sistemas actualmente existentes a los requisitos
identificados y a las nuevas necesidades de informacin.
Para alcanzar este objetivo se tomarn como referencia los resultados obtenidos
en la Actividad PSI 4 ("Disear la Arquitectura de la Informacin") y en las
Tareas PSI 5.1 ("Identificacin y Descripcin de los Sistemas Existentes") y PSI
5.2 ("Anlisis del Entorno Tecnolgico Actual"). Estos resultados permitirn
elaborar una serie de matrices que muestren la relacin entre: Aplicaciones -
Funciones y Ficheros de Datos Actuales - Entidades de Datos. Estas matrices
ayudarn a evaluar el grado- de cobertura que proporcionan los sistemas actuales
a las necesidades futuras de informacin.
Evaluar el coste de los sistemas actuales en funcin de los beneficios y la
cobertura proporcionada.
Evaluar la adecuacin de los recursos humanos actuales a las nuevas necesidades
y requisitos.
Para ello se estudiarn aspectos tales como:
El nmero de personas en tratamiento de la informacin.
Su formacin y experiencia.
Con los resultados de este estudio, el Comit de Direccin del Plan de Sistemas
podr valorar la necesidad de acometer planes de formacin.
Valoracin de los sistemas actuales. Incluir entre otros:
Resumen Aplicaciones-Funciones.
Resumen Ficheros de Datos Actuales - Entidades de Datos.
Coste de los sistemas actuales yvaloracin de los mismos en funcin de los
beneficios que aportan.
Perfil de los recursos humanos en las Unidades de tratamiento de la informacin.
TECNICAS:
Tcnicas matriciales, como:
Aplicaciones-Funciones.
Ficheros de Datos Actuales - Entidades de Datos.
Anlisis Coste-Beneficio.
ACTIVIDAD PSI 6: ESPECIFICAR LOS NUEVOS SISTEMAS
DESCRIPCION:
En esta actividad se define el ncleo del Plan de Sistemas, basado en los requisitos
identificados y en la Arquitectura de la Informacin definida en actividades anteriores,
teniendo en cuenta las restricciones, financieras y de todo tipo, de la realidad actual.
Esta actividad se llevar a cabo paralelamente a la Actividad PSI 7 ("Definir las
Alternativas Tecnolgicas") y se obtendr como resultado, una especificacin detallada
de cada sistema que servir de punto de partida a la realizacin de las distintas fases del
desarrollo de aplicaciones.
La participacin activa de los usuarios y responsables de la Unidad, tanto de forma
individual como en el Comit de Direccin, ser imprescindible para determinar las
orientaciones futuras de desarrollo.
PSI6:ESPECIFlCAR LOS NUEVOS SISTEMAS
I
6.\. IdentKicaci6n de mejoras en
1-
106 sistemas adUales
PSI7: DEFINIRLAS ALTERNATIVAS
PSI4: DiSEARLA ARQUITECTURA
TECNOLOGICAS
DE LA INFORMACION
16.2. !dentificaci6n de ....-
1
7.1.IDENTlFlCACION DE
sistemas
NECESIDADES
TECNOLOGlCAS AlTURAS

I
6.3. Delermilaci6n de prioridades
I
dedesandlo
7.2. DEFINICION DE
PSI5: REVISAR LA SITUACION ACTUAL

OPCIONES
DELOS SISTEMAS DE
TECNOLOGICAS
INFORMACION
I 6.4. Especilicaci6n de los sistemas
l-
TAREA PSI 6.1: IDENTIFICACION DE MEJORAS EN LOS SISTEMAS AcruALES
Definir unos criterios de evaluacin de la arquitectura final.
Se definirn unos criterios de evaluacin que permitirn determinar la idoneidad
de las distintas soluciones potenciales para el Plan de Sistemas. Entre estos
criterios se consideran:
Flexibilidad.
Velocidad de implantacin.
Grado de cambio.
Determinar las aplicaciones actuales que formarn parte del Plan de Sistemas.
A partir de la Identificacin Inicial de Sistemas, realizada en la Actividad PSI 4
("Disear la Arquitectura de la Informacin") y del estudio de los sistemas
existentes, hecho en la Actividad PSI 5 ("Revisar la situacin actual de los
sistemas de informacin"), se pueden determinar las aplicaciones existentes
susceptibles de satisfacer, con algunas mejoras, los requisitos y objetivos de la
Unidad.
Un procedimiento para hacer esto es confrontar, por un lado, las aplicaciones
actuales con las funciones y ficheros de datos que manejan y, por otro, los
sistemas identificados inicialmente, a partir de la Arquitectura Lgica de la
Informacin. De esta confrontacin se derivarn las posibilidades de mejora de
las aplicaciones existentes, teniendo en cuenta los criterios de evaluacin definidos
anteriormente y el coste aproximado en recursos humanos y tecnolgicos.
Identificar aplicaciones que se drban transportar al nuevo entorno tecnolgico.
Se identificarn, a partir de la Arquitectura Lgica de la Informacin, realizada
en la Actividad PSI 4 ("Disear la Arquitectura de la Informacin"), del estudio
de los sistemas existentes efectuado en la Actividad PSI 5 ("Revisar la situacin
actual de los sistemas de informacin") y de las nuevas alternativas tecnolgicas
identificadas en la Actividad PSI 7 ("Definir las alternativas tecnolgicas"), las
aplicaciones actuales que se migrarn al nuevo entorno.
fASE O: PlAN DE SISTEMAS DE INfORMACION
Los criterios que se seguirn para identificar estas aplicaciones sern:
65
Criticidad para otras Unidades de la Administracin que no estn incluidas
en este Plan de Sistemas.
Alto nmero de interrelaciones con otros sistemas.
Criticidad de las aplicaciones dentro de la Unidad, que hace que no se
puedan sustituir en un corto plazo de tiempo.
Realizacin de una fuerte inversin en dichas aplicaciones.
Lista de las aplicaciones que formarn parte del nuevo Plan de Sistemas, con la
documentacin de las mejoras necesarias para su adecuacin a los objetivos y
requisitos definidos para la Unidad.
Lista de aplicaciones a migrar al nuevo entorno.
TECNICA:
Entrevistas con personal de tratamiento de la informacin y usuarios y
responsables de la Unidad.
TAREA PSI 6.2: IDENTIFICACION DE NUEVOS SISTEMAS
Identificar los nuevos sistemas a desarrollar.
Tomando como base los requisitos y objetivos de la Unidad, se refinarn los
sistemas inicialmente identificados en la Tarea PSI 4.3 ("Diseo de la Arquitectura
de la Informacin"), teniendo en cuenta, entre otros, los siguientes criterios:
Considerar los requisitos no satisfechos por las aplicaciones identificadas
en la tarea anterior.
Limitar, en la medida de lo posible, las interfases entre sistemas.
Considerar diferentes tipos de sistemas:
Sistemas que realizan operaciones tpicas de tratamiento de datos;
que cubren el ncleo tradicional de tratamiento de datos, con tareas
predefinidas (clculo de nminas, sistemas de facturacin, etc.) y,
frecuentemente, un alto volumen de datos.
Sistemas de gestin de la informacin, definidos para facilitar
consultas sobre la informacin almacenada en el sistema,
proporcionar. informes y, en resumen, facilitar la gestin
independiente de la informacin por parte de los departamentos
usuarios.
Sistemas de soporte a la toma de decisiones. Facilitan la labor de
la direccin, proporcionndoles un soporte bsico, en forma de
mejor informacin, para la toma de decisiones. Se caracterizan
porque son sistemas sin carga peridica de trabajo, es decir, su
utilizacin no es predecible, al contrario que en los dos casos
anteriores, cuya es peridica.
Sistemas especiales. Como sistemas expertos, sistemas de soporte a
la tQma de decisiones para ejecutivos, etc.
Considerar los criterios de evaluacin de la arquitectura final, identificados
en la tarea anterior, PSI 6.1 ("Identificacin de mejoras en los sistemas
actuales").
Considerar los factores de localizacin de los sistemas y de seguridad de
los mismos.
Considerar los reqUisitos identificados sobre volmenes, frecuencia de
ejecucin de determinadas funciones, tiempos de intercambio de
informacin. Estos requisitos ayudarn a establecer la fuerza y naturaleza
de las dependencias y relaciones entre los sistemas.
Considerar la respuesta a eventos externos (solicitudes de informacin,
demanda de servicios, etc.) sobre la Unidad. Esto permitir tambin
agrupar funciones en sistemas.
Todos estos criterios ayudarn a definir el entorno final de aplicaciones dentro de
la Unidad. Sin embargo, hay que tener en cuenta que la definicin de nuevos
sistemas no es un algoritmo preciso, sino que requiere grandes dosis de juicio y
FASE O: PlAN DE SISTEMAS DE INFORMACION 67
experiencia por parte del equipo del proyecto, as como la participacin activa de
los usuarios expertos en el funcionamiento de la Unidad.
PRODUcrOS A OBTENER;
Documentacin, para cada una de las nuevas aplicaciones, de:
Tipo de sistema.
Requisitos que satisface.
Soporte que proporciona a las funciones y entidades de la Unidad.
TECNICA:
Entrevistas con responsables y usuarios de la Unidad.
TAREA PSI 6.3: DETERMINACION DE PRIORIDADES DE DESARROLLO
Identificar una serie de criterios que permitan asignar prioridades a los nuevos
sistemas.
Estos criterios se pueden agrupar en cuatro grandes categoras:
Beneficios potenciales:
Tangibles.
Intangibles.
Retomo de la inversin.
Impacto en la organizacin:
Efecto cuantitativo (nmero de Unidades y personas afectadas).
Efecto cualitativo.
Efecto en el cumplimiento de objetivos.
Posibilidad de xito.
Probabilidad de implantacin completa.
Requisitos previos (implantacin de otras aplicaciones).
Riesgos.
Disponibilidad de recursos.
Demanda.
Valor de los sistemas existentes.
Relaciones con los sistemas existentes.
Se podr definir para estos criterios una medida para evaluar de manera precisa
la importancia de los mismos.
Establecer las prioridades de desarrollo.
Se aplicarn los criterios anteriores a las aplicaciones identificadas.
En esta Tarea, es necesario hacer nfasis en que la determinacin y valracin de
prioridades de las aplicaciones requieren juicios subjetivos, siendo necesaria la
participacin activa del Comit de Direccin del Plan de Sistemas. En cualquier caso es
deseable que las aplicaciones a implantar en primer lugar sean aquellas que solucionen
los problemas inmediatos y que proporcionen un rpido retorno de la inversin.
Documentacin de prioridades de implantacin para todas las aplicaciones.
TECNICAS:
Entrevistas y reuniones en grupo con los usuarios y Responsables de Unidad.
Anlisis Coste-Beneficio.
TAREA PSI 6.4: ESPECIFICACION DE LOS SISTEMAS
69
Especificar suficiente informacin sobre los nuevos sistemas, de modo que 'se
pueda acometer de modo ms preciso el plan de implantacin.
Entre los factores que se deben considerar por aplicacin se pueden destacar:
Localizacin.
Tipo de tratamiento (en lotes, interactivas, consultas interactivas...).
Tratamiento de los datos segn la localizacin.
Periodicidad de actualizacin de los datos.
Volmenes estimados y crecimiento previsto.
Frecuencia de tratamiento.
Requisitos de respuesta.
Toda esta informacin se recoger a partir de los requisitos especificados y de los
objetivos en cuanto a la calidad de los servicios proporcionados por la Unidad y.
la previsible demanda de los mismos. Es importante tener en cuenta la
informacin sobre las opciones tecnolgicas resultantes de la realizacin de la
Actividad PSI 7 ("Definir las Alternativas Tecnolgicas").
Debido a la naturaleza "previsional" de determinados factores, es necesaria la
participacin activa de los usuarios expertos en el funcionamiento de la Unidad
y los responsables de la misma.
Identificar opciones de implantacin para cada uno de los nuevos sistemas.
En este punto hay que tener en cuenta que el grado de detalle de cada uno de los
sistemas es an demasiado general como para realizar una seleccin. Sin embargo,
servir de orientacin hacer un estudio de viabilidad de las siguientes opciones:
Posibilidad de implantacin de paquetes existentes en el mercado.
70 FASE O: PlAN DE SISTEMAS DE INFORMAClON
Se har un estudio sobre la oferta de las caractersticas generales de los
paquetes, incluyendo:
Cumplimiento de los requisitos y funciones de la aplicacin.
Estimaciones sobre el esfuerzo de 'implantacin.
Evolucin del paquete.
Coste del paquete.
Adecuacin al entorno tecnolgico identificado en la Actividad PSI
7 ("Definir las Alternativas Tecnolgicas").
Estndares.
Posibilidad de desarrollo propio.
Para ello ser muy til considerar los resultados de la Actividad PSI 7
("Definir las Alternativas Tecnogicas"), en particular: lenguajes de
desarrollo (LAG, L3G, otros), sistemas de gestin de base de datos,
herramientas de productividad (generadores de aplicaciones, herramientas
CASE), etc. Esto permitir realizar una estimacin del coste, en tiempo y
recursos, del desarrollo.
Identificar restricciones con los responsables.
Se deber prestar especial atencin a las restricciones en cuanto a presupuesto,
directrices tcnicas y de gestin y tecnolgicas. Ser funcin del Comit de
Direccin revisar las opciones que se le presenten con el fin de plantear las
orientaciones futuras.
PRODUcroS A OBTENER;
Se obtendr, para cada sistema, un conjunto de especificaciones que contemplen,
entre otros, los siguientes puntos:
Objetivos del sistema.
Descripcin de sus funciones.
Restricciones.
Posibles alternativas de implantacin y breve descripcin de las mismas.
TECNICA
71
Entrevistas y reuniones con usuarios, responsables de la Unidad y Comit de
Direccin.
ACTIVIDAD PSI 7: DEFINIR LAS ALTERNATIVAS TECNOLOGICAS
DESCRIPCION
En esta actividad se analizan las oportunidades que se derivan de las tendencias
tecnolgicas existentes, bien mediante la investigacin en reas tcnicas o mediante la
colaboracin de especialistas en tecnologa con el equipo del proyecto.
El objetivo ltimo ser identifica, e integrar los componentes potenciales de una
infraestructura tecnolgica a largo plazo y examinar las repercusiones de dicha
infraestructura sobre la Unidad.
Para ello se tendrn en cuenta:
Las principales tendencias tecnolgicas.
Tecnologas especiales de inters para la Administracin.
Aspectos del entorno tecnolgico actual que ofrezcan oportunidades potenciales
para los nuevos servicios proporcionados por la Unidad.
Tecnologas actuales o nuevas que se pueden usar para mejorar la eficiencia y
productividad de la Unidad, con especial nfasis en la disponibilidad, calidad y
oportunidad de la informacin.
Tecnologas que presentan nuevas oportunidades para la Unidad, con objeto de
examinar su valor potencial en trminos de coste probable, beneficios y riesgos
potenciales.
Tecnologas que requieren un estudio ms detallado.
Ser funcin del Comit de Direccin, asistido por el Equipo de Proyecto y especialistas
72
en tecnologa, el estimar la necesidad de acometer estudios especiales en nuevas
tecnologas.
Esta actividad se llevara a cabo paralelamente a la Actividad PSI 6 ("Especificar los
nuevos sistemas") ysus resultados servirn para especificar los nuevos sistemas yplantear
alternativas de implantacin.
TAREA PSI 7.1: IDENTIFICACION DE NECESIDADES TECNOLOGICAS FUTURAS
Establecer los requisitos de la Unidad para el soporte tecnolgico futuro.
Se identificarn los componentes tecnolgicos necesarios para proporcionar
soporte a las necesidades de informacin de la Unidad y establecer cmo se
debern integrar para proporcionar una infraestructura completa.
Entre los componentes a considerar estarn:
Equipo fsico:
Comunicaciones:
Equipo lgico:
Operaciones en
explotacin:
procesadores, dispositivos de
almacenamiento, ordenadores
personales, estaciones de trabajo, etc.
controladores de red, interfaces
externas, protocolos, procedimientos de
respaldo, etc.
sistemas operativos, logical de red,
generadores de aplicaciones, lenguajes
de consulta...
seguridad, control de trabajos, etc.
Obtener una visin general de la tecnologa a emplear en la Unidad.
En esta visin de alto nivel se incluirn las caractersticas fundamentales
requeridas para los componentes antes considerados y se tendr en cuenta su
integracin y las directrices y estndares relacionados con la gestin y desarrollo
futuro de la tecnologa.
Visin general de la infraestructura tecnolgica requerida.
TECNICA
Entrevistas con responsables tcnicos de la Unidad.
TAREA PSI 7.2: DEFINICION DE OPCIONES TECNOLOGICAS
73
Establecer criterios para desarrollar y evaluar una infraestructura tecnolgica.
Se tendrn en cuenta, entre otros, los siguientes factores: flexibilidad, facilidad de
uso, riesgo tcnico, conocimientos requeridos.
Determinar los requisitos de soporte tecnolgico.
Se identificarn las necesidades para cada una de las localizaciones identificadas
en la Arquitectura Lgica de la Informacin: aplicaciones, comunicaciones,
desarrollo de sistemas y seguridad.
Identificar, para cada uno de los componentes considerados en la tarea anterior,
las opciones tecnolgicamente factibles, teniendo en cuenta los requisitos de
soporte tecnolgico.
Estimar la previsible demanda de recursos en infraestructura tecnolgica.
Determinar opciones tecnolgicas. Para esto se tenQr en cuenta:
Los componentes tecnolgicos factibles.
La demanda prevista de recursos.
Los criterios de evaluacin.
Los requisitos de soporte.
Las necesidades de formacin y conocimientos requeridos por parte del
personal tcnico de la Unidad.
Documentacin de las infraestructuras tecnolgicas potenciales, indicando, para
cada una, las ventajas e inconvenientes y las razones de su rechazo o aceptacin.
TECNICA;
Entrevistas con personal tcnico y responsables de tratamiento de la informacin.
ACfIVIDAD PSI 8; ELABORAR EL PLAN DE ACCION
DESCRIPCION'
Se definen en esta actividad las acciones a corto, medio y largo plazo para desarrollar
los sistemas identificados, en funcin de sus prioridades.
Dado el carcter dinmico de un plan de implantacin, es preciso hacer nfasis en las
actividades de mantenimiento del plan con vistas a asegurar que dicho plan se adapte a
las condiciones cambiantes del entorno y a las diferentes restricciones que vayan
apareciendo (de recursos humanos, presupuestarias y de polticas de gestin).
El desarrollo de los sistemas, segn la Metodologa de Desarrollo de Sistemas
METRICA Versin 2, proporcionar los puntos de control donde se efectuar la
evaluacin del cumplimiento del plan. Adems, los resultados de la realizacin de cada
fase de la Metodologa servirn de realimentacin al plan de implantacin.
TAREA PSI 8.1; ELABORACION DE UN PLAN DE IMPLANTACION
fASE O: PlAN DE SISTEMAS DE INFORMACION 7S
Desarrollar un Plan global de implantacin, que defina el orden de los proyectos
a implantar, en funcin de las prioridades establecidas.
Dentro de este Piar) global, se har ms nfasis en los proyectos considerados
como prioritarios, definiendo para los mismos "un calendario inicial de desarrollo
que contenga, entre otras cosas:
Fechas estimadas de inicio.
Fechas estimadas de finalizacin.
Estimacin de recursos necesarios, en funcin de las caractersticas del
proyecto (recursos humanos, tecnolgicos y organizativos).
Puntos de control que permitan evaluar el cumplimiento de los planes
iniciales y definir acciones correctivas.
Definir planes de formacin, como resultado de la implantacin nuevas
tcnicas.
Calcular el presupuesto estimado para los proyectos prioritarios, teniendo en
cuenta el tipo de proyecto, el coste estimado, la necesidad de nuevas tecnologas,
etc.
Plan global de implantacin, que defina el orden los proyectos a implantar.
Planes a corto plazo para los proyectos prioritarios.
TAREA PSI 8.2: MANTENIMIENTO DEL PLAN DE SISTEMAS
Evaluar en las reuniones de seguimiento el cumplimiento de los objetivos
previstos.
La interrelacin de la Metodologa de Desarrollo de Aplicaciones con el Plan de
Sistemas, permitir definir los puntos de controlo de realizacin de las reuniones
de seguimiento al finalizar cada una de las fases de la Metodologa, dado que en
ese momento se dispondr de suficientes elementos de juicio para valorar las
previsiones de implantacin y el cumplimiento de los plazos iniciales.
Definir el marco de mantenimiento del plan de sistemas.
Se identificarn los procedimientos de gestin que se deben desarrollar. Entre
stos:
Reuniones del Comit de Direccin.
Funciones de Control de Calidad.
Procedimientos de revisin del plan (actualizacin y definicin de nuevos
plazos).
Procedimientos de mantenimiento de proyectos en el plan:
Informes del estado de proyectos.
Adicin de nuevos proyectos.
Revisin de proyectos.
Revisar restricciones e hiptesis hechas en el plan de implantacin, para asegurar
que los plazos previstos son prcticos y realistas.
Se considerarn en esta revisin:
Sistemas actuales.
Plazos de cambio de la tecnologa actual al nuevo entorno.
Prcticas actuales de gestin.
Restricciones presupuestarias y de recursos humanos.
Procedimientos para el mantenimiento del plan de sistemas.
DOCUMENTOS DE LA FASE O
n
Como resultado de la realizacin de esta fase, se obtendrn los siguientes productos:
l. DOCUMENTO DE INICIO DEL PLAN DE SISTEMAS
Perfil general de las Unidades objeto de estudio:
Informacin preliminar sobre los servicios y funciones.
Distribucin geogrfica de los mismos.
Organizacin de los equipos de trabajo.
Planificacin del proyecto.
2. ESPECIFICACION DE OBJETIVOS Y REQUISITOS DE LAS UNIDADES
AFECfADAS
Diagrama de contexto de la Unidad.
Diagrama de Flujo de Informacin de la Unidad.
Catlogo de requisitos con sus prioridades.
3. MARCO NORMATIVO
Directrices tcnicas.
Directrices de gestin.
4. ARQUITECfURA DE LA INFORMACION
Modelo conceptual de datos.
Diagrama de descomposicin funcional.
Diagrama de flujo de datos.
Catlogo de funciones de la Unidad.
Matriz Entidad-Funcin.
Matriz Funciones-Localizacin.
5. DESCRlPCION DE LAS APLICACIONES EXISTENTES
Catlogo de aplicaciones existentes.
Matriz aplicaciones-ficheros de datos.
Descripcin de cada aplicacin:
Relaciones con otras aplicaciones.
Posibilidades de adaptacin.
Caractersticas tecnolgicas.
6. DESCRIPCION DEL ENTORNO TECNOLOGICO AcruAL
Descripcin de los componentes.
Capacidad actual de los componentes.
Grado de integracin entre los componentes.
Perspectivas de evolucin.
7. ESPECIFICACION DE LOS SISTEMAS
Para las aplicaciones existentes:
Mejoras identificadas.
Migracin a nuevos entornos.
Requisitos que satisfacen.
Para las nuevas aplicaciones:
Objetivos.
Funciones que realizan.
Requisitos que satisfacen.
Alternativas de implantacin.
8. DESCRIPCION DEL NUEVO ENTORNO TECNOLOGICO
Descripcin de los componentes.
Anlisis de las alternativas consideradas.
9. PLAN DE IMPLANTACION
Plan de implantacin de aplicaciones.
Prioridad.
Recursos asignados.
Calendario de implantacin.
Planes financieros.
Plan de formacin.
10. PLAN DE MANTENIMIENTO
Procedimientos de mantenimiento de proyectos.
Procedimientos de revisin.
Procedimientos de control de calidad.
79
fASE 1: ANALISIS DE SISTEMAS
FASE 1: ANALISIS DE SISTEMAS
ESTRUCfURA DE LA FASE
83
El Anlisis de Sistemas de Informacin es la primera Fase de la Metodologa METRlCA
Versin 2 y su objetivo final es obtener un conjunto de especificaciones formales del
sistema a desarrollar, que describan en detalle:
Las necesidades de informacin que debe satisfacer el nuevo sistema.
La Arquitectura lgica del nuevo sistema, de forma independiente del entorno
tcnico.
Con este fin, se ha estructurado esta Fase en los siguientes mdulos:
Anlisis de Requisitos del Sistema (ARS).
Especificacin Funcional del Sistema (EFS).
INTERRELACION CON EL PLAN DE SISTEMAS DE INFORMACION
Si la necesidad de desarrollo del Sistema viene de la realizacin en la Unidad de un Plan
de Sistemas de Informacin, descrito en la Fase Ode la Versin 2 de METRICA, se
dispondr al inicio de esta Fase de Anlisis de Sistemas de un conjunto de
documentacin sobre el proyecto a esta documentacin incluye:
Objetivos.
Necesidades de informacin de la Unidad que debe satisfacer el Proyecto.
Requisitos generales de la Unidad que se han de cumplir.
Planificacin inicial de la implantacin.
Directrices tcnicas y de gestin de la Unidad.
Esta documentacin inicial, que constituye los Trminos de Referencia del Proyecto,
eliminar la necesidad de realizacin de algunas de las actividades descritas en esta Fase
de Anlisis. Por otro lado, la realizacin de esta Fase de Anlisis permitir refinar las
previsiones de implantacin contenidas en el Plan de Sistemas de Informacin.
MAP - metodologa METRICA Versin 2
84
USUARIOS PARTICIPANTES
Los Organos participantes en la Fase de Anlisis de Sistemas sern:
Comit de Direccin.
Constituido por los responsables de la Unidad o de las Unidades a las que afecta
el sistema, as como por los responsables de la gestin dentro de la Unidad.
Tambin ser importante la participacin de responsables de los servicios
comunes de la Administracin (Programacin y Presupuestos, Recursos Humanos,
etc.).
Ser un Directivo de alto nivel, responsable de Sistemas de Informacin o, en su
defecto, con la responsabilidad de Planificacin o de Coordinacin.
Equipo del Proyecto.
Formado por personal de Tecnologa de la, Informacin y personal tcnico
Si el Proyecto se hiciese con asistencia tcnica externa, el personal consultor
correspondiente se integrara en este Equipo de proyecto.
Grupo de Usuarios.
Formado por distintos usuarios con conocimiento profundo de las funciones a
realizar por el Sistema a desarrollar. Adems participarn expertos de los
servicios comunes de la Administracin (Programacin y Presupuestos, Recursos
Humanos, etc.)
Eventualmente se requerir la participacin de especialistas en tecnologas de la
informacin (comunicaciones, equipos fsicos, equipos lgicos) para la realizacin
de determinadas actividades dentro de la Fase.
Grupo de Calidad.
ss
Constituido por personal con conocimientos en metodologas de desarrollo y con
experiencia en las competencias principales de la Unidad. Su misin ser verificar
que los trabajos de esta Fase se realizan de acuerdo a la metodologa aqu
definida y validar el cumplimiento de las funciones y requisitos del Sistema.
La constitucin de estos comits y grupos depender de las caractersticas del tamao
y complejidad del proyecto a desarrollar. As, en el caso de un sistema sencillo que
afecte a una Unidad concreta, puede ocurrir que, por ejemplo, el Comit de Direccin
sea unipersonal y est constituido nicamente por el responsable de la Unidad.
La participacin activa de los usuarios es imprescindible en esta Fase, ya que de ellos
depende la definicin clara de los requisitos que ha. de cumplir el nuevo sistema, as
como el asegurar que las especificaciones formales obtenidas en la realizacin de esta
Fase. satisfacen sus necesidades de informacin.
MAP metodologa METRICA Versin 2
1 11
PlAN
DE SISTEMAS
DE INFORMACION
l1NTENlM!ENTOPlAN DE SISTEMAS
LEYENDA DEL GAAFICO
O MODUlOOACTMOAO
PROOUCTORESULTANTE
FASE 1: ANAlISIS DEL SISTEMA
ANAllSlS
DE REOUISITOS
DEL SISTEMA
ESPI:CIFICACION
FUNCIONAL
DEL SISTEMA
FASE 1: ANALISIS DE SISTEMAS - MODULO ARS
FASE 1: ANALISIS DEL SISTEMA
INDICE
89
ARS: ANALISIS DE REQUISITOS DEL SISTEMA 91
ARS 1:
ARS 2:
ARS 3:
ARS 4:
ESTABLECER EL AMBITO y ALCANCE
DEL PROYECTO. . 94
1.1. Definicin del Proyecto
1.2 Identificacin de los usuarios
participantes
IDENTIFICAR Y DEFINIR
REQUISITOS 96
2.1. Planificacin y realizacin
de entrevistas
2.2. Identificacin de problemas y
necesidades
DISEAR EL MODELO LOGICO
ACTUAL 102
3.1. Construccin del modelo lgico
actual de procesos
actual de datos
ESTUDIARALTERNATIVAS DE
CONSTRUCCION 106
4.1. Definicin de Alternativas
4.2. Seleccin de una Alternativa
FASE 1: ANALISIS DE SISTEMAS MODULO ARS
MODULO ARS: ANALISIS DE REQUISITOS DEL SISTEMA
DESCRIPCION y OBJETIVOS GENERALES
91
Este Mdulo tiene como objetivo analizar y documentar las necesidades funcionales o
del servicio que debern ser soportadas por el sistema propuesto. Para ello se
identificarn los requisitos que ha de satisfacer el nuevo sistema, mediante entrevistas
y el estudio de los problemas y necesidades actuales.
La identificacin de los requisitos y su priorizacin, adems de establecer las necesidades
ms crticas e inmediatas, proporciona un punto de referencia bsico para validar el
sistema final, es decir, comprobar que el sistema se ajuste a las necesidades del usuario.
No se deber distinguir inicialmente entre los componentes manuales y automticos del
sistema. Una vez conocidos los requisitos del sistema, se realizar un estudio de las
diferentes alternativas o posibilidades de solucin que ya podr tener en cuenta los
componentes manuales y automticos.
Dichas alternativas podrn incluir soluciones "a medida", soluciones basadas en la
adquisicin de paquetes del mercado o soluciones mixtas.
Se deber estudiar el impacto econmico de cada una de las soluciones presentadas en
trminos de esfuerzo a realizar, costos y riesgos previsibles, antes de recomendar una
alternativa.
Si en la Unidad se ha realizado un Plan de Sistemas de Informacin, se dispondr de un
conjunto de documentacin inicial sobre el sistema a desarrollar, lo que eliminar la
necesidad de realizacin de algunas de las actividades de este mdulo.
MODULO CE ANALlSIS DE REQUISITOS DEL SISTEMA (ARS)
~ SEGUIMIENTOYCONTAOl
~ _
ACCIONES DE CONTROL
DECALIOAD
DE PROYECTO
VAprobar reqUIsitos '1
cq.tNo.
1.2Identifi"ci4n UsuarIos
PlriDponI..
I---....J-_E)
LEYENDA DEL GRAFICO
'iJ
REVISION INFORMAL
Ino necellria firma)
_ REVISION FORMAL
.... enoco........)
:::
>
."
ANALlSIS
ACTIVIDADES
DE REQUISITOS
DEL SISTEMA 1 2 3
4
COMITE DE DIRECCION
D.R R F
DIRECTOR PROYECTO
R R R F
GRUPO DE CALIDAD F
GRUPO DE USUARIOS
I R I
DEPARTAMENTO DE TI
--- -- - ---- - ---- --- --
Responsables Tcnicos I I
EQUIPO DE PROYECTO
Jefe de Proyecto
E E E E
- ---- ----- - ---- - ----
Componentes Equipo
E
E E
93
CLAVES:
A = Asistencia Tcnica
O= Dotar Recursos
E = Ejecucin
F =Revisin Formal
R = Revisin Informal
I = Suministra Informacin
ACTIVIDADES:
t. Establecer el Ambito y Alcance
del Proyecto
2. Identificar y definir Requisitos
3. Disear el Modelo Lgico Actual
4. Estudiar Alternativas de Construccin
94 FASE 1: ANALISIS DE SISTEMAS - MODULO ARS
ACfMDAD ARS 1: ESTABLECER EL AMBITO y ALCANCE DEL PROYECfO
DESCRIPCION
En esta actividad se describe el proyecto a desarrollar, en cuanto a sus objetivos, mbito
y restricciones, realizndose una primera planificacin del mismo. Asimismo, se identifica
a los participantes en el proyecto (equipos de trabajo y principales interlocutores),
definiendo de una manera clara el grado de implicacin de todos ellos en el proyecto.
La posible existencia de un Plan de Sistemas en la Unidad, proporcionar, como punto
de partida para el desarrollo del proyecto, una descripcin inicial del mismo que
comprende los siguientes aspectos:
Objetivos.
Requisitos generales a satisfacer.
Posibles alternativas de implantacin.
Asimismo, se habrn identificado las directrices tcnicas y de gestin que afectan a la
Unidad en estudio y se dispondr de un plan inicial de desarrollo del proyecto.
El grado de detalle de esta descripcin inicial, determinar la necesidad de realizacin
de esta actividad.
TAREA ARS 1.1.: DEFINICION DEL PROYECfO
DESCRIPCION y 08IETIVOS
Realizar una descripcin general del proyecto, sus objetivos y restricciones.
Identificar las Unidades, departamentos o grupos implicados en el proyecto.
Hacer la planificacin inicial del nuevo proyecto. Se estimar la duracin del
mismo, desglosada en cuatro fases:
MAP - Metodologa METRICA Versi6n 2
FASE 1: ANALISIS DE SISTEMAS MODULO ARS
Anlisis.
Diseo.
Construccin.
Pruebas e Implantacin.
95
En este momento no es necesario un gran detalle en la planificacin de las fases
de Diseo, Construccin y Pruebas, puesto que esta Planificacin se refinar al
final de este Mdulo una vez que se conozcan los Requisitos del nuevo Sistema.
Detallar la composicin del equipo de trabajo necesario y obtener la debida
confirmacin.
PRODUCTOS A OBTENER
Descripcin general del proyecto, incluyendo los siguientes aspectos:
Objetivos principales.
Unidades, departamentos o grupos implicados.
Planificacin inicial.
Restricciones.
Composicin del equipo de trabajo.
TECNICA
Entrevistas con los patrocinadores del proyecto (responsables de las Unidades
afectadas).
TAREA ARS 1.2: IDENTIFICACION DE WS USUARIOS PARTICIPANTES
Identificar a los responsables de cdda una de las Unidades implicadas. Elegir un
Responsable de Usuarios. Se deber decidir entre seleccionar uno por cada
Unidad involucrada o un nico Responsable de todas ellas.
Identificar a los principales usuarios afectados. Para ello se consideran aspectos
como:
Incorporacin de usuarios al equipo de proyecto.
Conocimiento de los usuarios de las funciones a automatizar.
Repercusin del nuevo sistema sobre las actividades actuales de los
usuarios.
Implicaciones legales del nuevo sistema.
Como resultado, se obtendr una lista de usuarios afectados directamente por el
nuevo sistema, con objeto de concretar su participacin en las tareas de
desarrollo.
Es de destacar la necesidad de una participacin activa de los usuarios del futuro
sistema en las actividades de desarrollo del mismo, con objeto de conseguir la
mxima adecuacin del sistema a sus necesidades y facilitar el conocimiento
paulatino de dicho sistema, permitiendo una rpida implantacin.
PRODUCTOS A OBTENER
Lista de usuarios participantes, tanto responsables como personal tcnico de las
reas afectadas.
TECNICA
Entrevistas y reuniones con responsables Unidad.
ACTIVIDAD ARS 2: IDENTIFICAR Y DEFINIR REQUISITOS
DESCRIPCION
En esta actividad se planifican y realizan todas las entrevistas necesarias con los usuarios
identificados en la Actividad ARS 1 ("Establecer el mbito y alcance del proyecto").
Las entrevistas se realizarn a dos niveles dentro de la Unidad:
(a) Con los responsables de la Unidad.
(b) Con los usuarios.
El alcance de dichas entrevistas tendr relacin con la visin que cada participante
'pueda aportar sobre la Unidad:
(a) Los responsables aportarn una visin global de la Unidad.
(b) Los usuarios aportarn una visin detallada de una parte especfica de la Unidad.
Como resultado se obtendr una descripcin general del funcionamiento actual del
sistema, con datos sobre volmenes de informacin tratados y tiempos de respuesta.
Esto permitir identificar los problemas existentes en la actualidad, en cuanto a la
satisfaccin de las necesidades presentes y futuras del servicio, costes excesivos,
disponibilidad de la informacin, soporte a la toma de decisiones, etc.
Con esta informacin se empezar a elaborar un Catlogo de Requisitos a satisfacer por
el nuevo sistema. Esta definicin de requisitos ser iterativa y se ir perfilando con
mayor detalle a medida que el proyecto progresa, con la realizacin de la actividad ARS
3 ("Disear el modelo lgico actual").
Los requisitos identificados en la realizacin de estas actividades han de ser definidos
de modo que:
Sean cuantificables y medibles.
Sean lo suficientemente detallados para reducir cualquier tipo de ambigedad y
permitir validar si el nuevo sistema satisface las necesidades de los usuarios.
Se minimice la duplicacin de los diferentes productos obtenidos en la Fase de
Anlisis.
A la hora de identificar y definir los requisitos del sistema, ser til la clasificacin de
los mismos en requisitos funcionales y no funcionales. Los requisitos funcionales son
aquellos que describen lo que debe hacer el sistema en cuanto a:
Func.iones de actualizacin de datos.
Funciones de consulta.
Informes proporcionados.
Dalos manejados.
Interaccin con otros sistemas.
Los requisitos no funcionales describen las facilidades que debe proporcionar el sistema
en cuanto a: .
Rendimiento.
Requisitos de seguridad:
Control de accesos
Procedimientos de copias de respaldo y recuperacin
Integridad de la informacin
Requisitos especiales de comunicaciones.
En esta actividad se contemplarn, de modo muy general, estos requisitos no funcionales,
hacindose nfasis en el estudio de los mismos en. la actividad EFS 5 ("Completar
Especificaciones del Sistema").
La posible existencia de un Plan de Sistemas en la Unidad donde se desarrolla el
Proyecto, proporciona un conjunto de documentacin sobre:
Los problemas detectados en los sistemas actuales.
Las directrices tcnicas y de gestin.
Requisitos generales a cumplir en cuanto a necesidades futuras de informacin.
Tendencias de evolucin de la Unidad.
Sin embargo, no se eliminar la necesidad de realizar esta actividad, dado el mayor
grado de detalle del estudio efectuado en la misma.
TAREA ARS 2.1: PLANIFlCACION y REALIZACION DE ENTREVISTAS.
Planificar las entrevistas a realizar con cada responsable de Unidad. La
plarnficacin incluir:
Fecha, hora y lugar de la entrevista.
Duracin estimada.
Guin de la entrevista, que deber incluir los aspectos siguientes:
Funciones que se realizan en su departamento o grupo.
Conjunto de productos involucrados.
Otros usuarios que deberan participar en futuras entrevistas.
99
La planificacin y el guin de la entrevista sern enviados a los participantes con
antelacin suficiente para permitir que preparen aspectos de inters y aporten la
documentacin relacionada.
Realizar las entrevistas con cada responsable de Unidad y documentarlas
debidamente.
Planificar las entrevistas a realizar con los usuarios identificados en la Tarea ARS
1.2 ("Identificacin de los usuarios participantes"). Se realizar un guin detallado
de las entrevistas previstas, que se distribuir con suficiente antelacin a los
entrevistados.
Realizar las entrevistas con los usuarios.
Ser/n el/los responsable/s de usuarios los encargados de coordinar y convocar
las entrevistas. Se har llegar a cada usuario el guin preparado para la
entrevista.
Documentar los requisitos identificados, con sus prioridades.
A partir de las entrevistas realizadas con los responsables y usuarios, se
identificarn los requisitos que debe cumplir el sistema y se establecer una
prioridad para los mismos, de acuerdo a las necesidades expresadas por los
usuarios y a los objetivos a cubrir por el nuevo sistema.
Un ejemplo-de definicin de prioridades ser el que se-muestra a- continuacin:
1: Mxima Prioridad
2: Prioridad Alta
3: Prioridad Media
4: Deseable
5: Poco Importante
100
PRODUCTOS A OBTENER
Plan de entrevistas.
Catlogo de requisitos del sistema.
TECNICA
Entrevistas con responsables y usuarios de la Unidad.
TAREA ARS 2.2: IDENTIFICACION DE PROBLEMAS Y NECESIDADES.
Representar grficamente el funcionamiento del sistema actual, desde un punto
de vista fsico, considerando las funciones que realiza, el flujo de informacin
entre las mismas, las entradas, salidas y almacenamiento de la informacin y las
comunicaciones con otras unidades de la organizacin. La realizacin de este
modelo fsico permitir profundizar en el conocimiento del sistema actual y
facilitar la identificacin de los problemas existentes.
Esta representacin grfica se har mediante un dibujo de formato libre, sin
ninguna tcnica especfica. Ser conveniente introducir iconos que representen
aspectos fsicos del Sistema actual (Pantallas, Ficheros, Operaciones manuales,
etc.)
Analizar, a partir de las entrevistas efectuadas, los flujos de informacin del
sistema y detectar los nuevos requisitos de informacin.
Identificar los objetivos de la unidad que pretende cubrir el sistema requerido.
Identificar los archivos principales y documentos que sern fuente de informacin.
Revisar los aspectos funcionales del sistema existente (manual o automtico)
Identificar:
Las principales entradas de datos.
Principales funciones que se ejecutan.
Las principales salidas.
Estimar los costos de la explotacin del sistema actual.
Incluir:
Tiempo de ordenador.
Operacin (explotacin) del ordenador.
Tiempo de usuario.
Mantenimiento y mejoras de programacin.
Evaluar la informacin producida por el sistema actual..
Determinar:
101
Satisfaccin de las expectativas del usuario.
Informacin requerida por el usuario pero no producida por el
sistema.
Departamentos donde se producen demoras en el flujo de la
informacin.
Otras deficiencias, como operativa complicada o engorrosa,
informes superfluos o de escasa utilizacin, tiempos de respuesta
excesivamente altos, funcionamiento deficiente de algunas
operaciones, etc.
Esta revisin de los aspectos del sistema existente facilitar la
identificacin de nuevos requisitos que deber satisfacer el sistema a
desarrollar.
PRODUCTOS A OBTENER
Modelo fsico del sistema actual.
Lista de problemas y necesidades del sistema actual.
Catlogo de requisitos del sistema, con sus prioridades.
TECNICA
Entrevistas con usuarios del sistema actual y personal tcnico de tratamiento de
la informacin.
ACTMDAD ARS 3: DISEAR EL MODELO LOGICO AcruAL
DESCRIPCION
En esta actividad se representa grficamente el modelo lgico, tanto para datos como
para procesos, del sistema actual, determinando los grandes procesos o subsistemas que
lo componen, los flujos de informacin entre ellos, las entidades de datos, u objetos
sobre los que el sistema guarda informacin y las interrelaciones entre ellas.
El objetivo es, por tanto, conocer el funcionamiento del sistema actual, de un modo
conceptual, es decir, eliminando todas las referencias al entorno fsico y mostrando
funcionalmente su organizacin. Para ello, se partir de la representacin grfica del
sistema actual desde un punto de vista fsico, obtenido en la tarea ARS 2.2
("Identificacin de problemas. y necesidades").
Los modelos obtenidos en la realizacin de esta actividad permitirn identificar nuevos
requisitos del sistema mediante la comparacin de las funciones realizadas y la
informacin proporcionada por el sistema actual con las necesidades de los usuarios y
las necesidades futuras de la Unidad objeto de estudio.
La posible existencia de un Plan de Sistemas en la Unidad donde se desarrolla el
proyecto, proporciona un conjunto de informacin sobre:
La Arquitectura de la Informacin.
El modelo conceptual de datos.
La jerarqua de funciones de la Unidad.
Estos modelos, referidos a toda la Unidad, nos servirn de base para la realizacin de
esta actividad, restringiendo el mbito de los mismos a las funciones y entidades
manejadas por el sistema ~ c t u l e incrementando el grado de detalle en la descripcin
de los mismos.
ARS4: ESTUDIAR ALTERNAnVAS
DE CONSTRUCCION
4.1. Detinlcin de ahematlvas
14.2. Seleccin de una
alternativa
ARS3: DISEAR EL MODELO LOGICO
ACTUAL
32. Diseflo del modelo lgico
actual de datos
actual de procesos
ARS 2: IDENTIFICAR YDEFINIR
REQUISITOS
LEYENDA DEL GRAFICO
c=J ACTIVIDAD OTAREA
f7777/I PRODUCTO
r.cLLL.d RESULTANTE
-
S
104 FASE 1: ANALISIS DE SISTEMAS MODULO ARS
TAREA ARS 3.1: CONSTRUCCION DEL MODELO WGICO ACTUAL DE
PROCESOS
Construir un Modelo Lgico actual de procesos, para lo cual se tendrn en cuenta
las siguientes consideraciones:
Eliminar todas las referencias al entorno fsico.
Tratar de mostrar Qu funciones se hacen, y no cmo se hacen.
Determinar las grandes funciones del sistema en estudio, que sern
contempladas posteriormente como subsistemas.
Identificar las entradas y las salidas como flujos de informacin de cada
uno de los subsistemas.
Definir las principales entidades de datos que estos subsistemas utilizan.
Esto se har en paralelo con la Tarea ARS 3.2 ("Construccin del Modelo
Lgico Actual de Datos").
Descomponer cada subsistema, si se considera necesario para su correcta
comprensin, en otro submodelo definiendo igualmente sus entradas y
salidas. En todo caso no se har ms de un nivel de descomposicin de
dichos subsistemas.
Para construir este modelo se utilizar la tcnica del Diagrama de Flujo de Datos
(DFD) que muestra:
Las actividades o procesos que realiza el sistema.
Los flujos de datos entre los mismos.
Los almacenes de datos (lugares donde se guardan los datos utilizados por
las funciones de consulta y actualizacin).
Las entidades externas con que el sistema se comunica.
FASE 1: ANALISIS DE SISTEMAS - MODULO ARS 105
Verificar que el modelo realizado es correcto. (Ver referencia de la tcnica de
Diagrama de Flujo de Datos en la Gua de Tcnicas).
Identificar nuevos requisitos para el sistema, a partir del modelo lgico actual de
procesos.
PRODUcroS A OBTENER
Modelo lgico actual de procesos, mediante un Diagrama de Flujo de Datos que
muestra el sistema descompuesto en los principales subsistemas de que consta
TECNICAS
Entrevistas con usuarios del sistema.
Diagrama de Flujo de Datos.
TAREA ARS 3.2: CONSTRUCCION DEL MODELO LOGICO ACTUAL DE DATOS.
Identificar las entidades u objetos sobre los que se desea almacenar informacin,
y sus principales atributos. .
Para identificar las entidades de informacin del sistema ser de utilidad estudiar
los recursos utilizados por el mismo Y los documentos, pantallas e informes
actualmente existentes.
En una primera aproximacin se pueden identificar "clases" de datos en funcin
de la relacin lgica entre los mismos (pertenecen a ficheros comunes, son
utilizados por los mismos procesos o funciones, etc.).
Definir las asociaciones entre las entidades identificadas anteriormente.
Disear el Modelo Lgico de Datos.
Con este modelo lgico se representan de manera grfica, las entidades de datos
o clases de datos identificadas y las asociaciones entre ellas.
Esta tarea deber llevarse a cabo en paralelo con la tarea ARS 3.1 ("Construccin
del Modelo Lgico Actual de Procesos").
Identificar nuevos requisitos para el sistema, a partir del modelo lgico actual de
datos.
PRODUCTOS A OBTENER
Lista de entidades o clases de datos manejados por el sistema dentro de la
Unidad, con sus descripciones y sus principales atributos.
Modelo lgico actual de datos del Sistema.
TECNICAS
Entrevistas con usuarios del sistema.
Diagrama de Estructura de Datos.
ACTIVIDAD ARS 4: ESTUDIAR ALTERNATIVAS DE CONSTRUCCION
DESCRIPCION
En esta actividad se establecen diferentes alternativas para la construccin del nuevo
sistema, teniendo en cuenta los requisitos identificados en las actividades anteriores ysus
prioridades. Una vez establecidas, se comparan entre s y se selecciona la ms adecuada.
El diseo de alternativas de construccin permite evaluar diferentes grados de
automatizacin en relacin con las necesidades identificadas previamente. Como aspecto
importante de esta actividad, est la posibilidad de proponer soluciones que puedan
acarrear cambios organizativos y estructurales.
D.e ello se deduce que un aspecto importante a considerar en la evaluacin de las
diferentes alternativas de construccin, es el impacto de las mismas en la organizacin.
FASE 1: ANAUSIS DE SISTEMAS - MODULO ARS 107
Otro aspecto fundamental a tener en cuenta es la viabilidd econmica de las diferentes
soluciones propuestas, para ello se ha de realizar un anlisis coste-beneficio de dichas
soluciones con el fin de evaluar esta viabilidad.
Como resultado extremo de esta actividad, se puede tomar la decisin de abandonar el
proyecto si se concluye la imposibilidad de cumplir los requisitos identificados en plazos
razonables y sin exceder las restricciones presupuestarias.
La posible realizacin de un Plan de Sistemas dentro de la Unidad donde se desarrolla
el proyecto proporciona una documentacin inicial de las diferentes alternativas de
construccin, as como un anlisis somero de las mismas, que necesitara ser estudiado
ms en detalle con la realizacin de las tareas comprendidas en esta actividad.
TAREA ARS 4.1: DEFINICION DE ALTERNATIVAS
En esta tarea se plantearn las diferentes alternativas de solucin conjuntamente
con los usuarios. Estas alternativas debern ser consistentes con los requisitos
identificados. Los pasos a seguir son:
Identificar los procesos manuales y los automticos.
Determinar la naturaleza de los procesos automticos (en lotes o
interactivos).
Representar, para cada alternativa, un modelo lgico de procesos que
describa sus rasgos ms distintivos.
Este modelo lgico de procesos se representar mediante un Diagrama de
Flujo de Datos (DFD) donde se muestran las caractersticas ms
importantes de cada alternativa, por ejemplo:
Distribucin geogrfica de las funciones del sistema y traspaso de
informacin entre ellas.
Funciones principales que se van a actualizar
t ~
108 FASE 1: ANALISIS DE SISTEMAS MODULO ARS
Ha de existir un compromiso entre el grado de detalle con que se describa
cada una de las alternativas especificadas y el tiempo y recursos
disponibles. En general, bastar elaborar un DFD de nivel funcin (ver
Gua de Tcnicas) para cada alternativa.
Diferenciar claramente las distintas alternativas.
Recoger y estudiar la informacin relativa a aquellos productos de aplicacin
existentes en el mercado que podran ser considerados como una alternativa a
valorar.
En esta informacin de cada producto, se incluir:
Cumplimiento de los requisitos del Sistema.
Estimaciones sobre el esfuerzo de implantacin.
Evolucin del producto.
Coste del producto.
Estndares.
Entorno tecnolgico.
Este ltimo punto ser llevado a cabo slo si existe una expectativa de aplicar
una solucin basada en productos externos.
PRODUcrOS A OBTENER
Descripcin de cada una de las alternativas identificadas, incluyendo:
Modelo lgico de procesos, mediante un DFD.
Descripcin de procesos manuales y automticos.
Diferencias con las dems alternativas.
Informacin sobre productos de aplicacin existente en el mercado.
TECNICA
TAREA ARS 4.2: SELECCION DE UNA ALTERNATIVA.
109
Identificar las ventajas y desventajas de cada alternativa. Para ello se deber
recoger para cada una, informacin sobre:
Facilidad operativa.
Complejidad tcnica.
Plazos requeridos para la implantacin.
Impacto sobre la carga de trabajo actual del ordenador, incluyendo las
necesidades de recursos de equipo fsico y/o lgico.
Para cada alternativa se deber hacer un estudio de costes, considerando:
Costes y tiempos estimados de Desarrollo.
Costes estimados de personal.
Costes de tiempo de ordenador.
Coste de equipo fsico y lgico adicionales del sistema.
Costes de Implantacin.
De la misma manera debern detallarse los beneficios proporcionados por cada
alternativa:
Beneficios de usuario.
Bene"ficios tcnicos.
Seleccionar la solucin ms adecuada, teniendo en cuenta:
Funcionalidad.
Impacto en la Organizacin.
Evaluacin costes-beneficios.
El Modelo Lgico de Procesos de la alternativa elegida, ya realizado en la Tarea
ARS 4.1 ("Definicin de Alternativas"), ser el punto de partida para el mdulo
EFS ("Especificacin Funcional del Sistema"). Este modelo deber incluir las
nuevas funciones y necesidades definidas por los usuarios.
Esta seleccin ser realizada por el Comit de Direccin del Proyecto, asistido
por el equipo de proyecto.
Revisar y refinar la planificacin efectuada en la Tarea ARS 1.1 ("Definicin del
Proyecto") de cara a la realizacin del siguiente Mdulo ("Especificacin
Funcional del Sistema"), teniendo en cuenta:
Los Requisitos identificados.
Las caractersticas de la alternativa seleccionada.
PRODUCTOS A OBTENER
Descripcin, para cada alternativa, de los costes estimados y beneficios esperados.
Descripcin en detalle de la alternativa seleccionada.
TECNICAS
Anlisis coste-beneficio.
Entrevistas con el Comit de Direccin.
MAP ." Metodologa METRICA Versin 2
FASE 1: ANAUSIS DE SISTEMAS - MODULO ARS
OOCUMENTACION ASOCIADA AL MODULO ARS
111
El documento asociado al Mdulo ARS Anlisis de Requisitos del Sistema ., se
llamar, de acuerdo al Plan General de Garanta de Calidad aplicable al desarrollo de
equipos lgicos, Documento de Especificaciones de Diseo, DEO, y sus contenidos sern
los siguientes:
1. Ambito y Alcance del Proyecto.
2. Usta de usuarios participantes.
3. Descripcin del sistema actual.
3.1. Modelo fsico.
3.2. Usta de problemas y necesidades.
3.3. Modelo lgico actual de procesos.
3.4. Modelo lgico actual de datos.
4. Catlogo de requisitos del s ~ s t e m con sus prioridades.
5. Anlisis de Alternativas.
5.1. Descripcin de cada alternativa.
5.2. Descripcin detallada de la alternativa seleccionada.
Modelo lgico de procesos.
Anlisis coste-beneficio.
Diferencias significativas con otras alternativas.
FASE 1: ANAUSIS DE SISTEMAS - MODULO EFS
INDICE
115
EFS: ESPECIFICACION FUNCIONAL DEL SISTEMA 117
EFS 1:
EFS 2:
EFS 3:
EFS 4:
CONSTRUIR EL MODEW DE
PROCESOS DEL NUEVO SISTEMA. 121
1.1. Diseo del diagrama de contexto
del sistema
1.2. Identificacin y definicin de
subsistemas
1.3. Especificacin de interfases con
otros sistemas
1.4. Descripcin de procesos manuales
CONSTRUIR EL MODEW DE DATOS DEL
NUEVO SISTEMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
2.1. Construccin del modelo de datos
2.2. Normalizacin del modelo de datos
REALIZAR EL ANALISIS DETALLADO
DEL NUEVO SISTEMA 133
3.1. Construccin del modelo
entidad-evento
3.2. Consolidacin de los modelos de
datos y procesos
DEFINIR INTERFASES DE USUARIO 137
4.1. Produccin de prototipos preliminares
y dilogos
4.2. Especificacin de informes y formularios
116
EFS S:
EFS 6:
FASE 1: ANALISIS DE SISTEMAS - MODULO EFS
COMPLETAR ESPECIFICACIONES
DEL SISTEMA. ............................... 141
5.1. Especificacin de requisitos
de seguridad y control
5.2. Especificacin de requisitos de
copias de respaldo, contingencias
y recuperacin de errores
5.3. Especificacin de requisitos de
rendimiento
COMPLETAR ESPECIFICACIONES
DE ENTREGA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 145
6.1. Preparacin del plan de pruebas
del sistema
6.2. Especificacin del plan de entrega
del sistema
6.3. Verificacin y validacin de la
especificacin funcional del
sistema
MAP- Metodologa METRICA Versi6n 2
MODULO EFS: ESPECIFICACION FUNCIONAL DEL
SISTEMA
DESCRlPCION y OBJETIVOS GENERALES
117
El objetivo bsico de este mdulo es construir una especificacin detallada del nuevo
sistema, de forma que:
Satisfaga las necesidades de informacin de los usuarios y los objetivos de la
Unidad.
Sirva de base para la construccin del sistema, adaptndose a las directrices
tcnicas y de gestin de la Unidad.
Para conseguir este objetivo, se tomar como punto de partida el Catlogo de Requisitos
del Sistema, elaborado en el mdulo anterior ("Anlisis de Requisitos del Sistema"),
mediante entrevistas con los usuarios y el estudio del sistema actual. Estos requisitos se
incorporarn a la alternativa de solucin seleccionada en ese mdulo y se especificar
en detalle el nuevo sistema as definido.
Se construirn modelos lgicos de procesos, datos y eventos y se describirn los
componentes de estos modelos (subsistemas, procesos, entidades de datos, eventos,
interfaces de usuario, etc.).
Adems, se considerarn, para la especificacin del nuevo sistema, los requisitos no
funcionales del mismo, es decir, las facilidades que ha de proporcionar el sistema, y las
restricciones a que estar sometido, en cuanto a rendimiento, frecuencia de tratamiento,
seguridad, etc.
Es importante sealar que el mdulo EFS establece para su estudio y desarroll
posterior, la divisin definitiva del sistema en subsistemas; los mdulos posteriores se
ceirn al estudio y desarrollo de cada uno de los subsistemas.
La participacin activa de los usuarios es una condicin imprescindible para la
construccin de la Especificacin Funcional del Sistema, ya que dicha participacin
constituye una garanta de que los requisitos identificados inicialmente son comprendidos
e incorporados al sistema y, por tanto, de que ste ser aceptado.
118 FASE 1: ANALISIS DE SISTEMAS - MODULO EFS
Para facilitar la participacin de los usuarios, se utilizarn tcnicas interactivas, como
diseo de dilogos y prototipos, que permiten al usuario familiarizarse con el nuevo
sistema y colaborar con la construccin y perfeccionamiento del mismo.
Si el sistema que se est estudiando est incluido dentro de un Plan de Sistemas de la
Unidad, se tendr, para la realizacin de este mdulo, un conjunto de documentacin
en la que se incluyen las directrices tcnicas y de gestin a las que se debe someter el
sistema. Los resultados de la realizacin de este mdulo y, por tanto, de la finalizacin
de la Fase de Anlisis del Sistema influirn en el Mantenimiento del Plan de Sistemas,
tal y como se ha explicado en la Fase O("Plan de Sistemas de Informacin
fl
) de la
Metodologa METRICA Versin 2.
MAr- Metodologa METRICA Versin 2
~
~
MODULO DE ESPECIFICACION FUNCIONAL DEL SISTEMA (EFS)
ti!
l":'
:::
.::-: .j,
~
I
ACCIONES DE OlRECClON
~ ACCIONES DE COIlTR'lL
.=-
S'
DECWOAO en
0Cl ....
10'
en
'V,-_tA1 'V,-_tA1 'V,_.....
.=.- lil
~
ACCIONES DE GESTION
E.....-, E.....-,
E ~
DE PROVECTO
~ SEGUlMENTO y CONTROL
~
ACTMDADES
,
S:
~
::s
N
1.1 __l1li.
~
CCrlIulodalSlallllla
1.2_,Datnld6n
~
._..
~
1.3Ealoc1_.lnt.,
__otnlollstama
1.4 DacIp:l6n do -O
..........
COIot'LETAR
PEQFlCACIO-
NESENTREGA
6.1 Pr....Id6nPl..
!'ruaba dolulllmI
8.2 EalocIBcaln dtI PI..
do Ennga dollilllma
6.3V.rlficlc:iln,VlIIcIocIcln
U E - ~
do EalociIca::I6n _ ..
dolSllllm1
.-
1.1 _In_poi
prolinin... , dWClgol I.EY9!DADEL GRAACO
UEIfIICi __
'1 REVlSION INFORMAl.
~
,-
(no_lona)
. ..
REVlSION FORMAl.
o--talnna)
...
....
\Q
120 FASE 1: ANAUSIS DE SISTEMAS MODULOEFS
ESPECIFICACION
ACTIVIDADES
FUNCIONAL
DEL SISTEMA
1 2 3 4 5 6
COMITE DE DIRECCION
F
DIRECTOR PROYECTO
R R
R
R R F
GRUPO DE CALIDAD
F
GRUPO DE USUARIOS
I I I
I I R
DEPARTAMENTO DE TI
Especialistas en Sistemas A A
---- --- ---- ----- -- --- .,. ---
I I
EQUIPO DE PROYECTO
Jefe de Proyecto E
E
E E
E E
---- --- ---- ----- -- --- -----
Componentes Equipo
E
E E
E
E
CLAVES:
A - Asistencia Tcnica
D - Dotar Recursos
E-Ejecucin
F - Revisin Formal
R - Revisin Informal
I - Suministra Informacin
ACTIVIDADES:
1. ConslNlr el Modelo de Procesos del Nuevo Sistema
2. ConslNlr el Modelo de detos del Nuevo Sistema
3. ReaDzar el Anllsls detallado del Nuevo Sistema
4. Definir Interfases de Usuario
5. Completar Especlflc:aclones del Sistema
6. Completar especificaciones de Entrega
FASE 1: ANALlSIS DE SISTEMAS MODULO EFS
ACTMDAD EFS 1: CONSTRUIR EL MODELO DE PROCESOS DEL NUEVO
SISTEMA
DESCRIPCION
121
En esta actividad se realizar una descomposicin funcional del sistema en sus
Subsistemas Principales. Adems se har una primera descripcin de QUE es lo que el
sistema debe hacer en vez de COMO lo va a hacer.
Siempre que el sistema sea lo suficientemente grande, la divisin en subsistemas puede
ayudar a describirlo de una manera ms completa.
Una vez identificados los subsistemas principales, se describirn en detalie, definiendo
sus componentes, con el fin de obtener una especificacin lo ms completa posible.
Esta actividad se deber realizar en paralelo con las Actividades EFS 2 ("Construir el
Modelo de Datos del nuevo Sistema") y EFS 4 ("Definir Interfases de Usuario"), puesto
que la definicin de un modelo de datos y la realizacin de prototipos de pantalla puede
determinar la divisin de un subsistema en distintos procesos. Asimismo, la realizacin
de la Tarea EFS 3.2 ("Consolidacin de los modelos de datos y procesos") puede
ocasionar cambios en los modelos de procesos debido a la identificacin de nuevos
eventos.
Por ltimo, si el sistema que se est estudiando est incluido dentro de un Plan de
Sistemas de la Unidad, ser de utilidad la especificacin de los nuevos sistemas, con las
funciones de que consta, realizada en la Actividad PSI 6 ("Especificar los Nuevos
Sistemas").
EFS 1: CONSTRUIR ELMODELODE PROCESOS
DEL NUEVO SISTEMA
ACTIVIDAD EFS 3:
14---_1 REALIZAR EL ANALISIS
DETALLADO DEL NUEVO SISTEMA
ACTIVIDAD EFS 2:
14- 1CONSTRUIR EL MODELO DE
DATOS DEL NUEVO SISTEMA
ACTIVIDAD EFS 4:
1.__.... DEFINIR NTERFASES
DE USUARIO
1.4. de proc:llSGS
manuales
MODlA.OARS:
ANALISIS DE REQUISITOS
DEL SISTEMA
.........oa_
0"""",,"0-
l!!I I::ZZJ =.
TAREA EFS 1.1: DISEO DEL DIAGRAMA DE CONTEXTO DEL SISTEMA
DESCRlPCION y OBJETIVOS
123
Definir las relaciones del sistema con sus usuarios, con otras aplicaciones, o
Unidades de la Organizacin, siempre indicando estas relaciones como flujos de
datos' de entrada o salida.
Para realizar el Diagrama de Contexto de todo el sistema se deber:
Identificar qu usuarios, Unidades de la Organizacin o aplicaciones
delimitan el sistema, en el sentido de que tienen entradas y salidas con l
mismo.
Identificar la informacin que aportan o reciben del Sistema.
Eliminar todas las referencias al entorno fsico.
PRODUcroS A OBTENER
Diagrama de contexto del sistema.
Descripcin de usuarios, unidades de la Organizacin o aplicaciones que
delimitan el sistema ("Entidades externas").
TECNICA
TAREA EFS 1.2: IDENTIFICACION y DEFINICION DE SUBSISTEMAS
DESCRIPCION y OBIETIVOS
Dividir el sistema en diferentes subsistemas para su desarrollo posterior.
Para ello se revisa el Modelo Lgico Actual de Procesos, resultado de la Tarea
ARS 3.1 ("Construccin del Modelo Lgico Actual de Procesos") y se incorporan
los subsistemas adicionales identificados en el .Modelo Lgico de Procesos de la
Alternativa seleccionada en la Tarea ARS 4.2 ("Seleccin de una alternativa"), en
caso de haberse realizado el mismo. Asimismo, se incorporan los requisitos
identificados en el Catlogo de Requisitos del Sistema, elaborado en el mdulo
ARS.
Estas modificaciones en los modelos de partida, pueden provocar la necesidad de
reorganizar los subsistemas existentes, o crear otros nuevos. Para esto se seguirn
los siguientes criterios:
Homogeneidad de las funciones que realizan los diferentes subsistemas.
Datos que manejan, con el fin de disminuir la comunicacin entre los
subsistemas.
Localizacin geogrfica de los subsistemas.
Factores de seguridad.
Respuesta a eventos externos (solicitud de informacin, demanda de
servicios, etc.).
Fechas de entrega de alguna parte del sistema.
Representar grficamente, mediante un Diagrama de Flujo de Datos, los
diferentes subsistemas identificados en el paso anterior y las comunicaciones entre
ellos.
Para ello se seguirn los pasos que se indican:
Se identifican, representan y describen las entradas y salidas y Flujos de
Datos entre los subsistemas.
Se determinan las principales entidades de datos que estos subsistemas
utilizan y se representan como almacenes de datos en el diagrama. Esto
se hace en paralelo con la Actividad EFS 2 ("Construir el Modelo de
Datos del Nuevo Sistema").
Descomponer cada subsistema en las funciones de que consta y representar
grficamente esta descomposicin, mediante un Diagrama de Flujo de Datos
(DFD)
MAP- Metodologa METRICA Versin 2
FASE 1: ANALISIS DE SISTEMAS - MODULO EFS 125
Para identificar las nuevas funciones de los subsistemas, es necesario considerar:
El detalle de los nuevos subsistemas identificados.
Funciones necesarias para soportar los requisitos del Catlogo.
Funciones de mantenimiento de los nuevos datos en el modelo de datos
del nuevo sistema.
La representacin grfica de los DFD en el nivel de funciones, se har siguiendo
los mismos criterios que para el DFD de nivel de subsistema (punto anterior). Es
de gran importancia asegurar la consistencia de los almacenes de datos con las
entidades representadas en el modelo de datos, que se construye en la Actividad
EFS 2 ("Construir el modelo de datos del nuevo sistema")
Describir las distintas funciones identificadas en los DFD.
En este punto, se proceder a la descomposicin de cada una de las funciones
identificadas en otro DFD que muestre el detalle las diferentes subfunciones de
que consta esta funcin.
Describir cada una de las subfunciones identificadas.
En esta descripcin se incluir:
Modo de acceso a las entidades de datos del sistema.
Caractersticas de la subfuncin:
Actualizacin de datos.
Consultas e informes.
Realizacin de algoritmos especficos y descripcin de los mismos.
Tipo de tratamiento (en lotes o interactivo). Para definir esto, sern de
utilidad los requisitos del sistema (funcionales y no funcionales) contenidos
en el catlogo de requisitos.
Informacin sobre la frecuencia de ejeeuci6n.
En el caso de que la descripcin de alguna de estas subfunciones sea demasiado
extensa, puede ser conveniente proceder a la descomposicin de la misma en otro
DFD que muestre el detalle de los diferentes procesos elementales que describen
dicha subfuncin.
Determinar los diferentes eventos del sistema (sucesos que activan
procesos o funciones que actualizan datos del sistema). Los eventos
determinados servirn de entrada para la realizacin de la Actividad EFS
3 ("Realizar el Anlisis detallado del nuevo sistema").
Por ltimo, es preciso tener en cuenta en la realizacin de esta actividad,
que las tcnicas estructuradas que se utilizan en esta Fase permiten el
sucesivo refinamiento de los modelos. Por lo tanto, en la prctica no es
necesario construir completamente los diagramas anteriores en una
primera aproximacin, ya que una vez determinados todos los procesos en
detalle, se proceder a refinar los DFD de nivel superior a partir de los
DFD de niveles inferiores, con una aproximacin de abajo a arriba,
"bottom-up"
PRODUcrOS A OBTENER
Diagrama de flujo de datos del sistema que muestra la descomposicin de ste
en subsistemas (DFD de nivel Subsistema).
Diagrama de flujo de datos de los subsistemas que muestran la descomposicin
de stos en funciones (DFD de nivel funcin).
Diagrama de flujo de datos que muestra la descomposicin de funciones en las
subfunciones de que constan (DFD de nivel subfuncin).
Opcionalmente, ypara subfunciones especialmente complejas, Diagramas de Flujo
de Datos que detallen los procesos elementales que describan dichas
subfunciones.
Descripcin de los Flujos de Datos en los DFD.
Descripcin de los almacenes de datos.
Descripcin de subfunciones.
Catlogo inicial de eventos.
TECNICAS
Entrevistas con usuarios.
FASE 1: ANALISIS DE SISTEMAS - MODULO EFS 127
TAREA EFS 1.3: ESPECIFICACION DE INTERFASES CON OTROS SISTEMAS.
Determinar para cada uno de los diferentes subsistemas identificados, las
interfases con otros sistemas o subsistemas, especificando:
Datos transferidos.
Modo, Medio y Frecuencia de la interfase.
Suceso que origina y desencadena la interfase.
Para poder definir las interfases con otros sistemas deber recogerse informacin
sobre el formato de los datos que van a comunicarse. Los pasos a seguir sern:
Identificar las interfases. Para ello se consultar el Diagrama de Contexto,
obtenido en la Tarea EFS 1.1. ("Diseo del Diagrama de Contexto del
Sistema").
Especificar los datos a ser transferidos/recibidos.
Indicar los aspectos operativos de la interfase (en lotes, interactiva, medio,
frecuencia).
Identificar los sucesos o eventos que desencadenan la realizacin de la
interfase.
Considerar la posibilidad de que puedan existir interfases con Productos
de equipo lgico estndar. En este caso se necesitar conocer las
especifiaciones funcionales del producto:
Revisar las especificaciones funcionales y averiguar los formatos de
datos.
Identificar las interfases con el producto e identificar posibles
modificaciones a hacer en el producto.
Una vez conocidas las interfases a desarrollar, seguir los mismos
pasos que en caso de otras interfases externas.
128
PRODUcroS A OBTENER
fASE 1: ANALISIS DE SISTEMAS MODULO EFS
Descripcin de interfases con otros sistemas o subsistemas.
TECNICAS
TAREA EFS 1.4: DESCRIPCION DE PROCESOS MANUALES.
Completar para cada uno de los subsistemas identificados, las definiciones de sus
procesos de realizacin manual.
Diferenciar entre aquellos procesos manuales relacionados con un proceso
interactivo (p. ej. introduccin de datos en pantalla) y aquellos procesos manuales
sin relacin directa con procesos automticos (p. ej. revisin de un listado).
Los pasos a seguir son:
Para procesos manuales relacionados con procesos automticos especificar:
Datos de entrada a introducir por pantalla.
Datos de salida mostrados en pantalla.
Descripcin sencilla del dilogo y manejo de la pantalla.
Completar las especificaciones de los procesos manuales sin relacin
directa con procesos automticos.
Asociar responsabilidades de ejecucin a reas concretas de usuarios y
comprobar la no existencia de limitaciones para la realizacin de todos los
procesos manuales:
Disponibilidad de las personas o equipos de trabajo.
Su formacin y experiencia.
PRODUCTOS A OBTENER
Descripcin de procesos manuales.
129
ACfIVIDAD EFS 2: CONSTRUIR EL MODEW DE DATOS DEL NUEVO SISTEMA.
DESCRIPCION
En esta actividad se construye un Modelo Lgico de Datos que recoja:
Todas las entidades de datos de relevancia para la Unidad cuya informacin va
a ser consultada o procesada de alguna manera en el sistema.
Todas las relaciones existentes entre las entidades de manera que se pueda
acceder a los datos relacionados con cualquiera de las entidades mediante
procesos sencillos.
Las claves de acceso a las entidades, as como los atributos caractersticos de las
distintas entidades definidas.
Esta actividad se realizar en paralelo con las Actividades EFS 1 ("Construir el Modelo
de Procesos del Nuevo Sistema") y EFS 4 ("Definir Interfases de Usuario").
Asimismo, la realizacin de la Tarea EFS 3.2 ("Consolidacin del modelo de datos y
procesos") puede ocasionar cambios en el modelo.
Una vez construido el modelo, se normaliza, hasta la tercera forma normal (3FN).
Por ltimo, si el sistema que se est estudiando est incluido dentro de un Plan de
Sistemas de la Unidad, ser de utilidad para la realizacin de esta actividad, el Modelo
conceptual de datos de la Unidad obtenido en la actividad PSI 4 ("Disear la
Arquitectura de la Informacin"), restringindolo al mbito especfico del presente
sistema.
EFS 2: CONSTRUIR a MODao DE DATOS
DEL NUEVO SISTEMA
w
o
MODULOARS:
ANALlSIS DE REQUISITOS
Da SISTEMA
LEYENDADB. ORARCO
[:::JAeTlll'KlADOTAREA
l?ZZI:=':'
..
2.1. Conslrucci6n del modelo
dedalos
12.2. NonnaJizacin del modelo de
datos
ACTIVIDAD EFS 1:
,_.. ..., CONSTRUIR EL MODELO DE
PROCESOS DEL NUEVOSISTEMA
ACTIVIDAD EFS 3:
14---'" REALIZAR a ANALlSIS
ACTIVIDAD EFS 4:
DEANIR INTERFASES
, ...---t DE USUARIO
TAREA EFS 2.1: CONSTRUCCION DEL MODELO DE DATOS
131
Producir un Modelo de Datos del Sistema a desarrollar, que estar basado en el
Modelo Lgico Actual obtenido en la tarea ARS 3.2 ("Construccin del modelo
lgico actual de datos"), en el caso de que exista, actualizndose con todos los
requisitos establecidos en el Catlogo de Requisitos del Sistema resultado del
Mdulo anterior ARS.
Para ello se utilizar la tcnica "Diagrama de Estructura de Datos" que permite
establecer yrepresentar las asociaciones entre las distintas entidades identificadas.
La incorporacin de los nuevos requisitos implica acciones como:
Definir nuevas entidades de datos (estructuras de datos) para contemplar
las necesidades de informacin futuras.
Incorporar nuevos atributos de datos a las entidades ya existentes.
Modificar el nombre de las entidades y/o de los atributos.
Identificar nuevas interrelaciones entre las entidades, teniendo en cuenta
las necesidades de acceso a la informacin.
Cambiar los atributos clave de las entidades.
Describir completamente las entidades de datos con todos sus atributos e
incorporar informacin sobre volmenes estimados, frecuencia de acceso
a las mismas, tiempo medio de almacenamiento dentro del sistema, etc.
PRODUCTOS A OBTENER
Descripcin de entidades de datos y sus atributos.
Modelo de datos del nuevo sistema.
TECNlCAS
MAP - Metodologia METRICA Versi6n 2
TAREA EFS 2.2: NORMALIZACION DEL MODELO DE DATOS.
DESCRIPCION y OB.IETIVQS
Normalizar las entidades de datos (estructuras de datos) identificadas en la Tarea
EFS 2.1 ("Construccin del Modelo de Datos").
Se aplicar la tcnica de normalizacin, hasta la tercera forma normal (3FN), con
el fin de eliminar redundancias e inconsistencias en las entidades de datos,
facilitar el mantenimiento de los datos y evitar anomalas en las operaciones de
manipulacin de stos.
Representar el modelo lgico de datos en tercera forma normal.
Como resultado del proceso de normalizacin, puede ocurrir que las entidades
de datos de las que se parte inicialmente, den lugar a varias entidades de datos
en tercera forma normal (o Relaciones), con atributos clave comunes, que
permiten establecer las asociaciones o interrelaciones entre estas entidades
normalizadas en 3FN.
De este modo, se construye el Modelo Lgico de Datos en 3FN, el cual se
compara con el modelo construido en la Tarea EFS 2.1 ("Construccin del
Modelo de Datos") con el fin de resolver las posibles inconsistencias entre ambos,
inconsistencias que pueden aparecer como consecuencia de la diferente tcnica
seguida en su construccin.
Una aproximacin sistemtica para resolver las inconsistencias entre ambos
modelos ser la siguiente:
1. Revisar los nombres de las entidades, dado que al normalizar puede
ocurrir, como se ha dicho, que se creen entidades diferentes de las
existentes inicialmente.
2. los smbolos especficos de Diagrama de Estructura de Datos
(Relaciones exclusivas, opcionales, etc.) que satisfacen los requisitos de
usuario y que no estn contemplados en el modelo lgico en 3FN.
FASE 1: ANALISIS DE SISTEMAS MODULO EFS
PRODUCfQS A OBTENER
Entidades de Datos normalizadas (3FN).
Modelo lgico de datos en 3FN.
TECNlCA
Modelizacin de datos (Normalizacin).
ACTIVIDAD EFS 3: REALIZAR UN ANALISIS DETALLADO DEL NUEVO
SISTEMA.
DESCRIPCION
133
En esta tarea se construye la modelizacin del nuevo sistema desde el punto de vista de
los eventos que actan sobre el mismo, considerando evento como todo suceso que
activa los procesos de actualizacin de datos dentro del sistema.
Para realizar esta actividad se utilizar una tcnica de gran nivel de detalle: Historia de
la Vida de las Entidades del Sistema (HVE), que permitir obtener una descripcin de
la evolucin de las Entidades de Datos del Sistema y que adems permitir asegurar la
consistencia de los Modelos de Procesos (DFD) y de Datos (Modelo Lgico en 3FN)
usados hasta ahora.
El grado de detalle de esta actividad exige un conocimiento profundo de los siguientes
factores:
El orden en que se suceden los distintos eventos dentro del sistema.
La posible existencia de situaciones no usuales, dentro del tratamiento realizado
por el sistema.
La interaccin con otros sistemas dentro de la Unidad.
Para ello ser imprescindible una participacin activa de usuarios expertos en el
funcionamiento de la Unidad junto con el Equipo de Proyecto.
l.EYENIlA DELGRAF!CO
t"'7 REVISlON_
Vlno_1IInaI
REVISIOII FOIIIIAI.

.COll'lETAA -
1----... PEaFlCAClO-
NESENTREGA
6.1 Pl...._1'I1I1
I'Noboldollilllma

do Enngadol_
6.3 VIlIIcl8ddn,VIlidId6n

dolSllllll11a
SEGUIMIENTO YCONTROL
1.1_lliIgr...
ConIuloclll_

<lo SLlIIiIIm..
1.3 EspocI_do 1n1".
--=._-

.........
ACCIONES DE GESTlON
ACCIONES DE CONlROl
DECAUDAD
ACCIONES DE D1RECClDN
ACTIVIDADES
TAREA EFS 3.1: CONSTRUCCION DEL MODELO ENTIDADEVENTO.
Identificar los eventos del sistema.
135
Para ello se parte del catlogo de eventos obtenido en la Tarea EFS 1.2
("Identificacin y definicin de subsistemas").
Construir el modelo EntidadEvento para todas las entidades del sistema.
Como punto de panida se tendr el modelo lgico de datos en 3FN, construido
en la Tarea EFS 2.2 ("Normalizacin del modelo de datos"). Este modelo
permitir considerar las repercusiones o efectos que los eventos que actan sobre
una entidad pueden tener sobre las entidades relacionadas con ella.
Adems ser de utilidad la especificacin de los sucesos que desencadenan las
interfases con otros sistemas, obtenida con la Tarea EFS 1.3 ("Especificacin de
interfases con otros sistemas").
Para la realizacin de este modelo se utilizar la de la Historia de la Vida
de la Entidad (HVE), descrita en la Gura de
La construccin de este modelo permitir identificar nuevos eventos en el
Sistema, y completar el catlogo de eventos.
PRODUCTOS A OBTENER
Catlogo de eventos.
Modelo Entidad-Evento.
Historia de la Vida de la Entidad.
MAr Metodologa METRICA Versin 2
136 FASE 1: ANAUSIS DE SISTEMAS - MODUW EFS
TAREA EFS 3.2: CONSOLIDACION DE LOS MODELOS DE DATOS Y PROCESOS.
Completar los Diagramas de Flujo de Datos con los nuevos eventos identificados
en la Tarea EFS 3.1. ("Construcci6n del modelo entidad-evento").
Para ello se introducen nuevos procesos en los DFD de nivel ms bajo (nivel
subfunci6n o nivel de los procesos contenidos en una subfunci6n) con el fin de
asegurar el proceso de los nuevos eventos.
Asegurar que el modelo de datos en 3FN est correctamente construido yque las
asociaciones identificadas (obligatorias, opcionales y exclusivas) permiten reflejar
las repercusiones o efectos que los eventos que actan sobre una entidad, tienen
sobre otras entidades del modelo (Ver tcnica de la Historia de la Vida de la
Entidad en la Gua de Tcnicas).
PRODUCTOS A OBTENER
Diagramas de flujo de Datos de bajo nivel, revisados.
Modelo 16gico de datos en 3FN revisado.
TECNICA
Interrelacin entre las tcnicas de Historia de Vida de la Entidad con Diagrama
de Flujo de Datos y Diagrama de Estructura de Datos.
ACTMDAD EFS 4: DEFINIR INTERFASES DE USUARIO.
DESCRIPCION
137
El objetivo de esta Actividad es especificar todas las interfases entre el sistema y el
usuario, como formatos de pantallas, dilogos, formatos de informes y formularios de
entrada (si fuera necesario).
Hay que dar ms importancia a los requisitos de usuario que a las definiciones tcnicas,
aunque podran tambin describirse limitaciones impuestas por el entorno de trabajo en
caso de que fueran conocidas.
La participacin activa de los usuarios del nuevo sistema es imprescindible, ya que
permitir que se vaya familiarizando con el aspecto externo del mismo y facilitar la
futura implantacin del sistema, al permitir, entre otras cosas, una formacin y
adaptacin paulatina de dichos usuarios.
Los modelos de representacin de sistemas utilizados hasta ahora no permiten visualizar
el aspecto interactivo de estos sistemas, en su relacin con el usuario. Un ejemplo claro
de esto pueden ser los procesos de entrada de datos por pantalla, de los que sera
interesante conocer las validaciones de campos, ediciones, ayudas, secuencias y
navegacin entre pantallas, etc.
Se puede observar que se ofrecera una versin ms amplia del sistema creando
simulaciones de su comportamiento (comnmente llamadas prototipos), mediante la
utilizacin de datos especficos. Con ello, se conseguira, entre otras, las siguientes
ventajas:
Reducir el riesgo en la implantacin del nuevo sistema.
Aumentar la calidad del producto.
Incrementar la productividad.
Permitir la introduccin de mejoras y modificaciones antes de presentar los
diseos definitivos.
Si no fuese factible realizar un prototipo completo, se disear un prototipo parcial que,
aunque no ofrezca todas las ventajas indicadas anteriormente, s permitir, con un coste
razonable, obtener una visin general de las tareas de ms frecuente realizacin.
TAREA EFS 4.1: PRODUCCION DE PROTOTIPOS PRELIMINARES Y DIAWGOS.
Definir los formatos individuales de las pantallas utilizadas. En el caso de utilizar
un paquete estndar, evaluar la posibilidad de adoptar el tipo de formato del
producto, o ~ iniciar labores para su adecuacin a los estndares de la Unidad.
Entre los aspectos a considerar en los formatos de pantallas cabe destacar:
Encabezamiento.
Cuerpo principal.
Pie.
Teclas de funcin.
Teclas de ayuda y lneas de visualizacin de los mensajes de ayuda.
Describir de modo detallado los dilogos entre pantallas y el encadenamiento
entre las mismas.
Para realizar esta descripcin ser de utilidad realizar una representacin
jerrquica de las pantallas del Sistema. En esta representacin jerrquica se
representarn en los niveles superiores los mens del sistema, y en los niveles
inferiores las pantallas de dilogos, representativos de funciones o procesos
concretos del sistema.
Ser de inters en esta representacin jerrquica, identificar los mens o dilogos
concretos en funcin de los grupos de usuarios que los utilicen. Para ello se parte
de la lista de usuarios elaborada en la Tarea ARS 1.2 ("Identificacin de los
usuarios participantes").
Determinar los dilogos que se consideran criticos para un funcionamiento
correcto del nuevo sistema.
La determinacin de dilogos r t i ~ s se har en funcin de factores tales como:
Tipo de proyecto.
Grado de cambio con respecto al sistema actual.
La complejidad de los trabajos del sistema.
En esta determinacin, sern de utilidad los siguientes criterios:
Frecuencia de uso de esos dilogos.
Acceso a gran nmero de entidades de datos del sistema.
Gran nmero de elementos de datos asociados con el dilogo.
Cambio en el modo habitual de trabajo en el sistema actual.
Dilogos comunes a diferentes grupos de usuarios.
Dilogos que contienen opciones complejas de navegacin.
Dilogos asociados a funciones importantes para la Unidad.
139
Realizar un prototipo dinmico que permita la simulacin (introduccin y
validacin de datos por pantalla) para los dilogos considerados como criticos en
el punto anterior. Este prototipo podr ayudar a establecer la descripcin de los
procesos de la Actividad EFS 1 ("Construccindel modelo de procesos del nuevo
sistema"), de ah que esta tarea, y toda la Actividad se realice en paralelo con la
Actividad EFS 1.
Como recomendaciones a seguir en la realizacin de este prototipo citaremos:
Determinar el punto de entrada a cada pantalla, y sus posibilidades de
navegacin a otras.
Especificar los datos asociados a cada pantalla (longitud, reglas de
validacin, mensajes de ayuda, etc.).
Evaluar la consistencia del diseo, asegurando que toda la informacin
necesaria para el usuario est contemplada en las pantallas y corregirlas
en caso contrario.
Confirmar con el usuario la validez de los diseos de pantalla realizados.
PRODUcroS A OBTENER
Formatos de pantallas.
Representacin jerrquica de las pantallas del sistema.
Asignacin de ls pantallas y dilogos a los grupos de usuarios.
Dilogos criticos del sistema.
Prototipos de los dilogos crticos.
140
TECNICAS
Prototipado de pantallas y dilogos.
Entrevistas con los usuarios.
TAREA EFS 4.2: ESPECIFICACION DE INFORMES Y FORMULARIOS.
Obtener una definicin de los formatos de los informes generados.
Definir los formularios utilizados (si fuera necesario).
Verificar que los diseos realizados estn de acuerdo con los estndares de la
Unidad y obtener la validacin y conformidad de los usuarios.
Esta tarea es similar a la anterior, y se podr realizar en paralelo con ella.
PRODUCTOS A OBTENER
Formatos de informes y formularios.
ACTMDAD EFS S: COMPLETAR ESPECIFICACIONES DEL SISTEMA
DESCRIPCION
141
En esta actividad se contemplan en detalle los requisitos no funcionales del sistema, es
decir, las facilidades que debe proporcionar el mismo en cuanto a:
Seguridad.
Rendimiento.
Comunicaciones.
La existencia de un Plan de Sistemas para la Unidad donde se desarrolla el proyecto,
proporciona un conjunto de documentacin sobre las directrices tcnicas existentes en
dicha Unidad, que debern ser tenidas en cuenta en la realizacin de esta actividad.
TAREA EFS 5.1: ESPECIFICACION DE REQUISITOS DE SEGURIDAD Y
CONTROL.
Especificar la poltica de Seguridad y Control para el nuevo sistema.
Definir exactamente los puntos de control que deben establecerse para garantizar .
los requisitos de seguridad establecidos.
En general, la planificacin de la seguridad lgica ha de realizarse en tres niveles.
Proteccin de acceso, establece las posibilidades del acceso a la
informacin en funcin de los procesos y sus futuros usuarios. En casos
extremos de necesidad de proteccin, pueden emplearse tcnicas de
encriptacin de datos.
Continuidad integral, que indicar los procedimientos adecuados para
asegurar una recuperacin de los datos involucrados en una operacin de
actualizacin en caso de terminacin anormal.
Integridad de datos.
Conocidos el nivel y los puntos de control a tener presentes, se realizarn los
siguientes pasos:
Determinar los requisitos de seguridad para almacenamientos de datos, y
de otros recursos a proteger, identificando las causas de peligro. Los
peligros ms comunes son:
Modificacin.
Destruccin.
Revelacin de datos a personas no autorizadas.
Definir requisitos de seguridad para los procesos y muy principalmente
para las transacciones interactivas.
Para ello, se tomar como punto de partida la identificacin de dilogos
crticos y la asignacin de dilogos a grupos de usuarios realizada en la
Tarea EFS 4.1 ("Produccin de prototipos preliminares y dilogos").
Todos estos requisitos de seguridad se incluirn en el Catlogo de
requisitos del sistema obtenido en el mdulo ARS.
PRODUcroS A OBTENER
Catlogo de Requisitos del Sistema actualizado.
FASE 1: ANALISIS DE SISTEMAS MODULO EFS 143
TAREA EFS 5.2: ESPECIFICACION DE REQUISITOS DE COPIAS DE RESPALDO,
CONTINGENCIAS Y RECUPERACION DE ERRORES.
Definir las n e e s ~ d d e s de copias de seguridad para los almacenamientos de
datos, procesos y transacciones del nuevo sistema.
Especificar los almacenamientos de datos que debern entrar en los
procedimientos de copias de respaldo, su periodicidad y condiciones
especiales.
Establecer un plan de contingencias para aquellas situaciones de fallo crtico del
sistema.
Especificar los procedimientos de tratamientos de los errores que se podrn
producir en el nuevo sistema, teniendo especial cuidado en:
Revisar las posibilidades de error y detallar los procedimientos de
recuperacin para cada subsistema.
Planificar el contenido de los mensajes de error, teniendo en cuenta si son
fciles de comprender para el destinatario.
Todos estos requisitos de copias de respaldo, contingencias y recuperacin de
errores se incluirn en el Catlogo de Requisitos del Sistema, obtenido en el
mdulo ARS.
PRODUCfOS A OBTENER
TAREA EFS 5.3: ESPECIFICACION DE REQUISITOS DE RENDIMIENTO.
.,
Especificar requisitos de rendimiento y eficiencia del nuevo sistema.
Para ello se tomar como punto de partida la identificacin de dilogos crticos,
realizada en la Tarea EFS 4.1 ("Pr.oduccin de prototipos preliminares y
dilogos"), y se realizarn, conjuntamente con los usuarios, estimaciones sobre:
Tiempos de respuesta requeridos.
Volmenes de ocupacin dentro del sistema.
Circunstancias especiales de explotacin (das o perodos de alto volumen
de transacciones).
Ser de utilidad considerar la informacin sobre el volumen estimado de las
entidades del sistema, realizado en la Tarea EFS 2.1 ("Construccin del modelo
de datos").
Los requisitos identificados en esta tarea se documentarn en el Catlogo de
Requisitos del Sistema, obtenido en el mdulo ARS.
Asegurar que la inclusin de las funciones de seguridad, control, copias de
seguridad, tratamiento de errores, etc., no estn limitando el rendimiento deseado
para el sistema.
PRODUCTOS A OBTENER
FASE 1: ANAUSIS DE SISTEMAS - MODUW EFS
ACTIVIDAD EFS 6: COMPLETAR ESPECIFICACIONES DE ENTREGA.
DESCRIPCION
145
En esta actividad se revisan y completan las especificaciones de entrega que se incluirn
en el "Documento de Diseo Funcional (DDF) o documento de Especificacin Funcional
del Sistema". Estas especificaciones de entrega consistirn en:
Planificacin del futuro desarrollo del sistema.
Plan de Pruebas y Plan de Aceptacin.
Estimacin ajustada de Recursos, Costes y Calendario de Realizacin.
Plan de Transicin.
Plan de Entrega.
Finalmente se har una revisin de las especificaciones elaboradas por parte del Grupo
de Calidad, para comprobar la validez formal del documento de especificacin. A
continuacin se llevar a cabo la revisin formal por parte de los usuarios y del Comit
de Direccin de dichas especificaciones.
Si el sistema a desarrollar est incluido dentro de un Plan de Sistemas de la Unidad, se
modificarn las previsiones de desarrollo efectuadas en dicho Plan y se pondrn en
marcha las acciones de mantenimiento del Plan de Sistemas diseadas en la Tarea PSI
8.2 ("Mantenimiento del Plan de Sistemas").
TAREA EFS 6.1: PREPARACION DEL PLAN DE PRUEBAS DEL SISTEMA.
Establecer los criterios de aceptacin del sistema. El cumplimiento, por parte del
sistema, de estos criterios, permitir asegurar que ste satisface los requisitos
exigidos y que usuario est conforme con el sistema final.
Para la definicin de estos criterios de aceptacin ser imprescindible la
146
participacin de los usuarios.
Los criterios de aceptacin han de ser definidos de manera clara yexplcita, yhan
de hacer nfasis principalmente en los siguientes puntos:
Funciones del sistema que son crticas para la Unidad.
Tiempos de respuesta exigidos para el sistema (Ver Catlogo de
Requisitos del Sistema)
Rendimiento del sistema en perodos crticos de alto volumen de
transacciones (Ver Catlogo de Requisitos del Sistema).
Preparar el plan de pruebas de aceptacin del sistema. Este plan deber incluir:
El tipo de pruebas a realizar.
La responsabilidad de la preparacin de los juegos de prueba y de su
realizacin.
Una descripcin de las caractersticas de la prueba (qu probar y qu no).
Condiciones para aceptar o rechazar el resultado de la prueba (ser
necesario involucrar al llsuario), para ello servirn como referencia los
criterios especificados en el punto anterior.
Revisar el Plan de Pruebas elaborado, verificando que todos los usuarios que han
de decidir la aceptacin final del sistema, estn de acuerdo con el Plan de
Pruebas establecido.
PRODUCTOS A OBTENER
Plan de pruebas de aceptacin del sistema.
TAREA EFS 6.2: ESPECIFICACION DEL PLAN DE ENTREGA DEL SISTEMA.
Preparar la planificacin del Desarrollo y Entrega del nuevo sistema.
Se realizarn los siguientes pasos:
147
Determinar las caractersticas que marcarn el desarrollo del nuevo
sistema (especificar sus caractersticas globales y aquellas excepciones a
tener en cuenta).
Estructurar o dividir el desarrollo en fases, determinando para cada una
de ellas sus productos finales y equipos de desarrollo. Determinar tambin
las dependencias entre productos finales para definir en consecuencia las
posibles acciones a realizar y su secuencia.
Identificar a grandes rasgos el entorno de desarrollo para cada fase. Se
tendrn en cuenta las consideraciones relativas a las instalacin de
productos externos.
Establecer el Plan de Aceptacin del sistema. Este plan deber incluir una
primera definicin de las pruebas de aceptacin a que el futuro sistema deber
someterse y de los recursos necesarios, as como la definicin de los responsables
de la aceptacin formal del sistema.
Revisar las fechas estimadas, teniendo en cuenta los recursos de los que se
dispondr durante el resto de las fases, y hacer las correspondientes correcciones.
PRODUCTOS A OBTENER
Plan de Desarrollo y Entrega del nuevo sistema.
Plan de Aceptacin del nuevo sistema.
Revisin de fechas y costes previstos.
148
TAREA EFS 6.3: VERlFICACION y VALIDACION DE LA ESPECIFICACION
FUNCIONAL DEL SISTEMA.
Asegurar la coherencia y exactitud de los modelos obtenidos.
Garantizar que los modelos obtenidos satisfacen los requisitos recogidos en el
Catlogo de Requisitos del Sistema. Esto se har mediante una revisin con el
Grupo de Calidad y con los usuarios.
Comprobar con el Grupo de Calidad, que la documentacin elaborada como
producto final de este mdulo sigue los estndares establecidos. Se harn las
correspondientes modificaciones con el objetivo de ajustarse al mximo a estos
estndares.
Una vez revisadas las especificaciones, y corregidos sus posibles defectos, deber
haber una aprobacin formal de las mismas por parte del Comit de Direccin.
No se continuar con la Fase siguiente hasta que el equipo del proyecto no
cuente con esta aprobacin.
PRODUCTOS A OBTENER
Conjunto completo de especificaciones funcionales del sistema revisado, validado
y aprobado.
DOCUMENTAC;ION ASOCIADA AL MODULO EFS
149
Como resultado de la realizacin de las actividades y tareas de este mdulo se obtienen
los siguientes documentos, definidos en el Plan General de Garanta de Calidad
aplicable al desarrollo de equipos lgicos:
Documento de Diseo Funcional, DDF o Especificacin Funcional del Sistema.
Plan de Pruebas del equipo lgico de proyecto, PPRB.
DOCUMENTO DE DISEO FUNCIONAL, DDF, con el siguiente contenido:
Las funciones a desarrollar.
Los procesos manuales y automticos.
Las estructuras de datos.
Los eventos del sistema.
Las interfases de usuarios.
Requisitos no funcionales del sistema.
Plan de Entrega.
Este documento es muy importante ya que:
Probablemente ser el ltimo documento de especificacin revisado por los
usuarios.
La aprobacin de este documento significa la aprobacin del resto de ciclo de
vida del Sistema.
La planificacin y estimacin detallada del resto del ciclo de vida del Sistema
estar basada en el contenido de este documento.
El ndice de dicho documento ser el siguiente:
1. Especificacin del Sistema Propuesto.
1.1. Diagrama de Contexto del Sistema.
1.2. Diseo de Subsistemas.
1.2.1. Diagramas de Flujo de Datos.
1.2.2. Descripcin de los Componentes.
2. Especificacin de Subsistemas.
2.1. Modelo de Procesos de cada Subsistema.
2.1.1. Diagrama de Flujos de Datos de cada Subsistema.
2.1.2. Descripcin de los Componentes de los DFD.
2.1.3. Descripcin de los Procesos Manuales.
2.2. Modelo de Procesos de las Funciones de cada Subsistema.
2.2.1. Diagrama de Flujos de Datos de las Funciones.
2.2.2. Descripcin de los Componentes de los DFD.
2.3. Modelo de Procesos de las Subfunciones de cada Funcin.
2.3.1. Diagrama de Flujo de Datos de las subfunciones.
2.3.2. Descripcin de los componentes de los DFD.
3. Modelo de Datos del Sistema.
3.1. Modelo Lgico de Datos en Tercera Forma Normal.
3.1.1. Modelo Grfico.
3.1.2. Entidades y Claves Primarias.
3.1.3. Entidades y Atributos.
4. Modelo de Eventos del Sistema.
4.1. Catlogo de Eventos.
4.2. Modelo grfico Entidad-Evento.
5. Interfases de usuario.
5.1. Pantallas.
5.1.1. Dilogo de Pantallas.
5.1.2. Mapa de Pantallas.
5.1.3. Elementos asociados.
5.1.4. Identificacin de Dilogos Crticos.
5.2. Informes.
5.2.1. Formato de Informe
5.2.2. Elementos asociados.
6. Otras Especificaciones no funcionales del Sistema.
1S1
6.1. Especificacin de Requisitos de Seguridad y Control.
6.2. Especificacin de Requisitos de Respaldo y Recuperacin de Errores.
6.3. Especificacin de Requisitos de Rendimiento.
7. Especificacin de la Entrega.
7.1. Plan de Desarrollo y Entrega del nuevo sistema.
7.2. Revisin del Plan del Proyecto.
8. Control de Calidad de la Especificacin Funcional.
8.1. Validacin del Modelo de Procesos.
8.2. Validacin del Modelo de Datos.
8.3. Validacin del Modelo de Eventos.
8.4. Seguimiento de los Requisitos de Usuario.
PlAN DE PRUEBAS DEL EQUIPO LOGICO DEL PROYEcrO, PPRB, que
contendr:
1. Plan de Pruebas.
1.1. Pruebas del Sistema.
1.2. Pruebas de Aceptacin.
FASE 2: DISEO DE SISTEMAS
ESTRUCI'URA DE LA FASE
15S
El Diseo de Sistemas es la segunda Fase de la Metodologa del Desarrollo de Sistemas
METRICA Versin 2 y en ella se obtendr el conjunto de especificaciones fsicas del
Sistema, que constituyen el punto de partida para construccin.
Esta Fase est constituida por el mdulo:
Diseo Tcnico del Sistema (DTS).
INIERRELACION CON EL PLAN DE SISTEMAS DE INFORMACION
Si el sistema est incluido dentro de un Plan de Sistemas de Informacin de la Unidad,
se partir, para la realizacin de esta fase, de un conjunto de documentacin en la que
se incluyen las directrices tcnicas del sistema, as como la definicin del entorno
tecnolgico en que funcionar.
Los resultados de la realizacin de la Fase de Diseo de Sistemas, influirn en el
mantenimiento del Plan de Sistemas, tal y como se ha especificado en la Fase O("Plan
de Sistemas de Informacin") de la Metodologa METRICA Versin 2.
Los Organos participantes en la Fase de Anlisis de Informacin, sern:
Comit de Direccin.
Constituido por los responsables de la Unidad o de las Unidades a que las afecta
comunes de la Administracin (ProgramacinyPresupuestos, Recursos Humanos,
etc.).
156 FASE 2: DISEO DE SISTEMAS
Las caractersticas especficas de esta Fase hacen imprescindible la participacin
de especialistas en tecnologas de la informacin (comunicaciones, equipos fsicos,
equipos lgicos) en la realizacin de las actividades dentro de la Fase.
Grupo de Calidad.
La constitucin 'de estos comits y grupos depender de las caractersticas de tamao y
complejidad del proyecto a desarrollar, as en el caso de un sistema sencillo que afecte
a una Unidad concreta, puede ocurrir que, por ejemplo, el Comit de Direccin sea
unipersonal y est constituido nicamente por el responsable de la Unidad.
PLAN
DE SISTEMAS
DE INFORMACION

'Q
CJACTMDADOTAREA
lZZIPRODUCTO _ENIolIOOOA.NII DE SlSIEIlA5
RESULTANTE
FASE 2: DISEO Del SISTEMA
DISEIlO
TECNICO
Del SISTEMA
FASE 2: DISEO DE SISTEMAS - MODULO DTS
INDICE
161
DTS: DISEO TECNICO DEL SISTEMA .... . . . . . . . . . . . . . . . . . . . . . . . . 163
DTS 1:
DTS2:
DTS3:
DTS4:
DTS S:
DISEAR LA ARQUITECTURA FISICA DEL
SISTEMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 166
1.1. Diseo de la Estructura modular del sistema
1.2. Descripcin de interfases entre mdulos
del sistema
1.3. Descripcin de interfases con otros sistemas
1.4. Descripcin de interfases de usuario
1.5. Definicin de componentes del sistema
DISEAR LA ESTRUCTURA FISICA DE DATOS
DEL SISTEMA. 175
2.1. Elaboracin del modelo fsico de datos
2.2. Optimizacin del modelo fsico de datos
ESPECIFICAR EL ENTORNO TECNOLOGICO DEL
SISTEMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 179
3.1. Definicin del entorno tecnolgico
del sistema
3.2. Especificacin de requisitos de comunicaciones
del sistema
3.3. Especificacin de requisitos de operacin,
seguridad y control
COMPLETAR EL PLAN DE PRUEBAS DEL
SISTEMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. 184
4.1. Diseo de planes de prueba del sistema
4.2. Definicin del entorno y limitaciones
de prueba.
COMPLETAR ESPECIFICACIONES DE DISEO. . 187
5.1. Preparacin de planes de construccin
5.2. Preparacin de planes para la implantacin
5.3. Revisin del Diseo Tcnico del Sistema
FASE 2: DISEO DE SISTEMAS MODULO DTS
MODULO DTS: DISEO TECNICO DEL SISTEMA
163
Este Mdulo tiene como objetivo realizar una descripcin de cmo va a ser el sistema
desde un punto de vista fsico, esta descripcin incluir:
El Diseo de la Arquitectura del Sistema.
El Diseo de la Estructura fsica de datos.
Para ello se tomar como punto de partida el conjunto de especificaciones funcionales,
que describen el sistema desde un punto de vista lgico, obtenido en l Fase 1 ("Anlisis
del Sistema") y se adaptar al entorno tecnolgico especfico en que va a funcionar el
sistema, el cual se especificar tambin en este mdulo.
El diseo tcnico del sistema depender en gran medida de las caractersticas de la
instalacin. Esto implicar que se han de tener en cuenta los siguientes condicionantes:
Exigencia de una participacin activa de los especialistas en Sistemas de la
Unidad u Organizacin donde se desarrolle el Sistema.
La adaptacin dinmica de las actividades y tareas de este mdulo a las distintas
facilidades de que se dispone en la instalacin. As, por ejemplo, no ser nunca
igual realizar un diseo de la estructura de datos para ficheros convencionales
que para una Base de Datos, donde existe un Sistema de Gestin de Base de
Datos, el cual permite automatizar en gran medida las distintas tareas a realizar.
Esto hace recomendable el elaborar un conjunto de procedimientos de diseo que
permitan la adaptacin de las actividades de diseo al entorno tecnolgico de que se
dispone.
Como resultado de la realizacin de este mdulo se obtendr el conjunto de programas
a construir, as como el diseo de las pruebas a realizar. Este diseo de las pruebas se
depurar en la fase siguiente ("Construccin del Sistema")
MODULO DE DISEO TECNICO DEL SISTEMA (DTS)
SEGUlllENTOy CONTIlOI.
ACCIONES DE OIRECCION
ACCIONES DECOIlIlIOl
DECALIIIAD
ACCIONES DE GESTlllN
DE PAO'/ECTO
ACTMDADES
. CXlIlPIETNI
g
PEQf1CACIO.
""
NEslllSEllO

...-

... ""'*
pnla""",-
g
U_dlI_
i
r_.... _
Eil
;'
Lmfl)6MLGMf!QQ
m

'Y REVlSIOHFOllIlAl.
>

;l
f o
o g:
(j
N
FASE 2: DISE&O DE SISlEMAS - MODULO DTS
DISEO
ACTIVIDADES
TECNICO
DEL SISTEMA
1 2 3 4 5
COMITE DE DIRECCION
F
DIRECTOR PROYECTO
R F
GRUPO DE CALIDAD
F
GRUPO DE USUARIOS
DEPARTAMENTO DE TI
A A
E
-- - ---- ----- ---- ----
A
A
E
EQUIPO DE PROYECTO
Jefe de Proyecto
E
E E
E
E
--- ---- ----- - ---- ----
Componentes Equipo
E E
E
E
165
:::LAVES:
O - Dotar Recursos
E - Ejecucl6n
F - Revls16n Formal
R - Revlsl6n Informal
I - Suministra Informacl6n
MAP - Metodologa ME1RICA Versin 2
ACTIVIDADES:
1. Dlsal\ar la Arquitectura Frslca del Sistema
2. Dlsel\ar la EstNctura Frslca de Datos del Sistema
3. Especificar entamo tecnol6glco del Sistema
4. Completar el Plan de Pruebas del Sistema
5. Completar Especificaciones de Olsel'lo
166 FASE 2: DISEO DE SISTEMAS - MODULO DTS
AcrIVIDAD DTS 1: DISEAR LA ARQUITECTURA FISICA DEL SISTEMA.
DESCRIPCION
En esta Actividad se establece el diseo global del sistema a desarrollar, a partir de los
Diagramas de Flujo de Datos obtenidos en el mdulo EFS ("Especificacin Funcional
del Sistema") y se obtiene:
El Diseo de la arquitectura modular del sistema.
La definicin de las interfases entre los mdulos creados.
La definicin de las interfases con otros sistemas y de usuarios.
La descripcin de los componentes del sistema.
Este conjunto de productos se integrarn en la documentacin general junto con la
especificacin de los programas 'a realizar en la fase siguiente de Construccin.
Para la realizacin de este diseo se han de tener en cuenta las caractersticas tcnicas
del entorno en que funcionar el nuevo sistema, por ello esta actividad se realizar en
paralelo con la Actividad DTS 3 ("Especificar el Entorno Tecnolgico del Sistema").
Adems ser de utilidad el Catlogo de Requisitos del Sistema, con la especificacin de
requisitos no funcionales, obtenido en la Fase anterior (Anlisis de Sistemas).
MAP - Metodologa METRI.CA Versin 2
DOCUMENTO MODULO EFS DTS1:DISEf.lAR ARQUITECTURA FISICA
DEL SISTEMA
~
11.1 Disefto EslrUctUra Modular
1-
DTS2: DISEf.lAR ESTRUCTURA
FISICA DE DATOS
'/
DELSISTEMA
112 Descrip. 1nl8t1ases entre mdulos J---
~
.I 1.3 Descrip.Inl8t1ases olros s1stamas l--
~
DTS3:ESPECIACAR EL ENTORNO
+
TECNOLOGICO DEL
1
SISTEMA
: 1.4 Descripcin interfases usuario
J-
t
,//
~
: 1.5 DefinicinCll/11lOf18tlIes s1slllma ~
~
TAREA DTS 1.1: DISEO DE LA ESTRUCTURA MODULAR DEL SISTEMA.
Identificar un conjunto inicial de actividades fsicas a realizar por el Sistema.
Para ello se tomarn como punto de partida los DFD construidos en la Actividad
EFS 1 ("Construir el Modelo de Procesos del Nuevo Sistema") y se definir un
conjunto inicial de actividades fsicas, teniendo en cuenta:
La divisin del sistema en subsistemas (DFD nivel subsistema)
La divisin de subsistemas en funciones (DFD nivel funcin)
La divisin de funciones en subfunciones (DFD nivel subfuncin)
La divisin de subfunciones en los procesos que las describen (DFD nivel
proceso)
El tipo de tratamiento por lotes o interactivo, de los procesos y
subfunciones.
Las caractersticas de las funciones y procesos.
Elaboracin de informes y consultas.
Actualizacin de entidades del sistema. (Respuesta a los eventos
identificados en el Catlogo de Eventos, contenido en la documentacin
asociada al mdulo EFS y que se ha obtenido en la Tarea EFS 3.1
("Construccin del Modelo Entidad-Evento").
Realizacin de algoritmos especficos.
Es preciso asegurar que todas las funciones realizadas por el Sistema estn
soponadas por el conjunto de actividades identificado.
Ser de utilidad, de cara a las fases posteriores de desarrollo del sistema,
determinar aquellas actividades fsicas con caractersticas comunes en cuanto al
proceso. Esto permitir disminuir el esfuerzo a realizar en la construccin,
facilitando la reutilizacin del cdigo. Asimismo, se podrn determinar actividades
ya existentes en libreras generales de desarrollo, en forma de rutinas de uso
FASE 2: DISEO DE SISTEMAS MODULO DTS 169
general dentro de la instalacin. El conjunto de actividades fsicas as obtenido,
se refinar en la Tarea D1'5 1.5 ("Definicin de Componentes del Sistema").
Disear la Estructura modular del Sistema.
Para ello se construir un conjunto de diagramas que muestren, en distintos
niveles de detalle, las diferentes unidades o mdulos de desarrollo de que consta
el sistema. Se seguir la tcnica del Diagrama de Estructura de Cuadros de
Constantine (ver Gua de Tcnicas). Como resultado de la aplicacin de esta
tcnica se obtendr:
Una Estructura de alto nivel que muestre el sistema descompuesto en los
subsistemas que lo componen. Para ello se tiene como punto de partida
el DFD de nivel de subsistema, contenido en el documento asociado al
mdulo EFS y que se ha construido en la actividad EFS 1 ("Construir el
modelo de procesos del nuevo sistema") y se aplican las estrategias de
paso del Diagrama de Flujo de datos al Diagrama de Estructura de
Cuadros, descritas en la Gua de Tcnicas.
Un conjunto de Diagramas de Estructura de Cuadros para cada una de las
actividades fsicas identificadas al comienzo de esta tarea. En estos
diagramas se muestran un conjunto de mdulos que describen y controlan
el tratamiento de la actividad fsica, la comunicacin entre estos mdulos
y la jerarqua de los mismos. Para ello se toman como punto de partida los
DFD de nivel funcin y los DFD que muestran la divisin de las funciones
en subfunciones (DFD nivel subfuncin) y las subfunciones en los procesos
que los describen (DFD nivel proceso) y se aplican las estrategias de paso
mencionadas en el prrafo anterior (ver Gua de Tcnicas).
Los diagramas de estructura as obtenidos mostrarn, en el caso de
tratamiento interactivo las sucesivas transacciones y dilogos y en el caso
de tratamiento por lotes la secuencia de programas dentro de cada ciclo
de proceso (fases, cadenas y pasos).
Refinar los diagramas obtenidos, aadiendo mdulos con el fin de detallar
el tratamiento de las actividades fsicas y que, por referirse a aspectos
fsicos no considerados en los DFD de partida, no han sido determinados
anteriormente.
Entre estos mdulos se incluirn:
Tratamientos de entradas y salidas.
Ediciones y validaciones de datos.
MAP - MetodolOga METRICA Versin 2
170 FASE 2: DiSEO DE SISTEMAS - MODULO DTS
Asimismo, se incorporarn a los diagramas construidos, smbolos que
detallen aspectos del tratamiento de las actividades, entre ellos:
Iteracin en el tratamiento de los mdulos.
Opcionalidad en el tratamiento de mdulos.
Por ltimo se considerarn refinamientos en el diseo como consecuencia
de la aplicacin de criterios de calidad especficos (acoplamiento y
cohesin) de la tcnica empleada, que se describen en la Gua de
Tcnicas. .
La aplicacin de estos criterios se har de modo interactivo, a medida que
se vaya profundizando en la descripcin de los diagramas de estructura de
cuadros con la realizacin de las Tareas D1'5 1.2 ("Descripcin de
interfases entre mdulos del sistema") y D1'5 1.3 ("Descripcin de
interfases con otros sistemas").
Como resultado, se podrn definir nuevos mdulos de desarrollo,
refinando los mdulos de partida, con el fin de reducir en lo posible la
complejidad de las interfases (disminuir el acoplamiento entre mdulos)
y aumentar la consistencia de las funciones realizadas por cada mdulo
(aumentar la cohesin de los mdulos).
PRODUCTOS A OBTENER
Conjunto de actividades fsicas del Sistema.
Actividades fsicas con caractersticas comunes de desarrollo.
Diagrama de estructura de cuadros de alto nivel, que muestre la comunicacin
entre los subsistemas.
Diagramas de estructura de cuadros que muestren el tratamiento de cada una de
las actividades fsicas del sistema y la estructura de las mismas (transacciones y
dilogos interactivos y fases y cadenas de tratamiento por lotes).
TECNICA
Diagrama de Estructura de Cuadros de Constantine.
FASE 2: DISEO DE SISTEMAS - MODUW DTS
TAREA DTS 1.2: DESCRIPCION DE INTERFASES ENTRE MODULOS DEL
SISTEMA.
171
Definir las interfases entre los Mdulos del Sistema, incluyendo la comunicacin
de informacin de control, as como la de los datos de la aplicacin. Cada
interfase entre mdulos debe incluir:
Los datos comunicados y su formato.
El origen y el destino de esos datos.
Para la descripcin de estas interfases entre mdulos, es preciso tener en cuenta
las siguientes consideraciones:
Facilidad de mntenimiento.
Esto se conseguir mediante el diseo de interfases sencillas que permitan
reducir la complejidad de comunicaciones entre los mdulos (reducir el
acoplamiento).
Umites del lenguaje o generador de cdigo.
Para ello ser necesaria la definicin del entorno tecnolgico, obtenido
con la realizacin de la actividad D1'5 3 ("Especificar el entorno
tecnolgico del sistema").
PRODUCTOS A OBTENER
Descripcin detallada de interfases de datos y control entre los mdulos.
TECNlCA
TAREA DTS 1.3: DESCRlPCION DE INTERFASES CON OTROS SISTEMAS.
Definir las interfases con otros sistemas que ya estn desarrollados y en
funcionamiento, o bien que estn planificados o desarrollndose en paralelo. En
la definicin de estas interfases se han de contemplar los siguientes aspectos:
Modo de operacin de la interfase: por lotes o interactivo.
Medio.
Frecuencia.
Evento que desencadenar ese traspaso de datos con otros Sistemas.
Formato de los datos que sern transferidos.
PRODUcrOS A OBTENER
Descripcin de interfases con otros sistemas.
TECNICA
TAREA DTS 1.4: DESCRIPCION DE INTERFASES DE USUARIO.
Establecer el,diseo detallado de las interfases de usuario para cada Componente
del Sistema, que deber estar referido al entorno tcnico en el que trabajarn
estas interfases. En este punto se ha de tener en cuenta el diseo de pantallas y
la identificacin de dilogos crticos, contenidos en el documento asociado al
mdulo EFS y que se ha obtenido en la Tarea EFS 4.1 ("Produccin de
FASE 2: DISEO DE SISTEMAS MODULO DTS 173
prototipos preliminares ydilogos"). Se revisarn los dilogos, criterios de edicin,
atributos de pantalla, etc., teniendo en cuenta la estructura modular creada.
La defmicin de componentes del sistema, con la agrupacin de mdulos en
funcin de sus caractersticas de tratamiento, realizada en la Tarea D1'8 1.5
("Definicin de componentes del sistema"), implicar en algunos casos una
redefinicin de los dilogos.
Por ltimo, en algunos casos podr ser de inters definir nuevos dilogos
especficos para los distintos tipos de usuarios definidos en el sistema,
dependiendo de los requisitos de seguridad identificados en la Tarea EFS 5.1
("Especificacin de requisitos de seguridad y control").
PRODUCTOS A OBTENER
Descripcin detallada de las interfases de usuario.
TECNICA
Prototipos de pantallas y dilogos.
TAREA DTS 1.5: DEFINICION DE COMPONENTES DEL SISTEMA.
Definir los componentes o unidades bsicas del desarrollo, describiendo, de forma
breve, su funcionamiento. Para ello se partir de la descripcin de las funciones
y procesos realizados en el mdulo EFS ("Especificacin Funcional del Sistema").
En principio, cada uno de los mdulos identificados en los Diagramas de
Estructura de Cuadros obtenidos en la Tarea D1'8 1.1 ("Diseo de la Estructura
Modular del Sistema") constituir un programa. Sin embargo, se podrn agrupar
mdulos con el fin de optimizar y disminuir el esfuerzo en la fase de
Construccin, para ello se tomar como punto de partida el conjunto de
actividades fsicas con caractersticas comunes en cuanto al tratamiento
identificado en la Tarea D1'8 1.1 ("Diseo de la Estructura Modular del Sistema")
y se refinar el diseo del sistema, teniendo en cuenta las siguientes
consideraciones:
174 FASE 2: DISEO DE SISTEMAS MODULO DTS
Agrupar mdulos que procesan el mismo grupo de registros.
Agrupar mdulos con la misma lgica de tratamiento.
Agrupar mdulos con un alto nmero de iteraciones, altos volmenes de
acceso a datos o gran frecuencia de proceso. Para ello sern de utilidad
los requisitos de rendimiento obtenidos en la Tarea EFS 5.3
("Especificacin de requisitos de rendimiento") ycontenidos en el Catlogo
de Requisitos.
Producir una especificacin detallada de cada Componente a desarrollar. Para
ello se describir en cada componente:
La lgica de tratamiento.
La llamada a otros componentes del sistema, o bien a un paquete
adquirido.
La secuencia en que los parmetros van a pasarse a otros componentes.
Por tanto se definir el pseudocdigo necesario para su construccin, inc;luyendo:
Las entradas y salidas del sistema que se disearon en la Tarea DTS 1.4
("Descripcin de interfases de usuario").
Los accesos a bases de datos o ficheros, de acuerdo con la definicin que
de estas bases de datos o ficheros se haga en la Actividad DTS 3
("Especificar el entorno tecnolgico del Sistema").
Las llamadas a otros componentes del sistema descritas en la Tarea DTS
1.2 ("Descripcin de interfases entre mdulos del Sistema").
La estructura de control interno de cada uno de los mdulos y
espedficamente las condiciones de fin de iteracin (bucles) o las
condiciones para la toma de decisiones.
Las interfases con otros sistemas definidos en la Tarea DTS 1.3
("Descripcin de interfases con otros sistemas").
FASE 2: DISEO DE SISTEMAS - MODULO D1'5
PROPUCTOS A OBTENER
Definicin de los componentes del Sistema.
Descripcin detallada de cada uno de ellos.
TECNlCAS
Diagrama de Estructura de cuadros de Constantine.
175
Descripcin de cada componente (pseudocdigo, lenguaje estructurado, etc.).
ACTMDAD DTS 2: DISEAR LA ESTRUCTURA FISlCA DE DATOS DEL
SISTEMA.
PESCRIPCION
En esta actividad se define la estructura fsica de datos que utilizar el sistema y se
revisar dicha estructura con el fin de satisfacer los requisitos de rendimiento
especificados en la Tarea EFS 5.3 ("Especificacin de requisitos de rendimiento") y
contenidos en el Catlogo de Requisitos.
El diseo fsico de la estructura de datos estar ntimamente relacionado con el entorno
tecnolgico descrito en la actividad DTS 3 ("Especificar el entorno tecnolgico del
sistema").
Adems, se ha de garantizar que el diseo fsico de datos satisface las necesidades de
tratamiento del nuevo sistema, y que las transacciones o dilogos criticos identificados
en la actividad EFS 4 ("Definir interfases de usuario") y descritas con detalle en la
Actividad DTS 1 ("Disear la arquitectura fsica del sistema"), se ejecutan dentro de los
mrgenes de rendimiento exigidos, lo cual puede requerir una labor de optimizacin del
diseo fsico de datos. La interrelacin entre estas actividades, DTS 1YDTS 2, implicar
la realizacin en paralelo de las mismas.
o
J
ji;'
DOCUMENTO MODULO EFS DTS2:DISEAR LA ESTRUCTURA FISICA
DE DATOS DEL SISTEMA
DTS1: DISEAR ARQUITECTURA
~
~
FISICA DEL SISTEMA
2.1 EIaboracl6n del
f--
1///////////.;1
Modelo Frslco
de Datos
f
22 Opdrnlzacl6n
'.;1 del Modelo FlsIco
~
1/ / / / / / / / / / / A
de Datos DT53: ESPECIFICAR EL ENTORNO
~
TECNOLOGICO
DEL SISTEMA
LEYENDA DEL GRAFICO
c=J ACTIVIDAD OTAREA
l'777l PRODUCTO
~ RESULTANTE
TAREA DTS 2.1: ELABORACION DEL MODELO FISICO DE DATOS.
Producir un modelo de datos fsico que tenga en cuenta la estructura de ficheros
del entorno tecnolgico donde va a funcionar el sistema (Ficheros convencionales
o Sistemas de Gestin de Base de Datos: r r q u i ~ Relacional, en Red).
Se seguirn los pasos que se indican a continuacin:
Definir cmo se implantarn las entidades y relaciones del Modelo de
datos en 3FN, obtenido en la Tarea EFS 2.2 ("Normalizacin del modelo
de datos").
Definir las claves, ndices u otras posibles maneras de acceder fsicamente
a los datos, para cumplir todos los requisitos de acceso.
Definir las vistas o subesquemas de la Base de Datos para cada
componente definido en la Tarea DTS 1.5 ("Definicin de componentes
del sistema").
Revisar el Modelo fsico de datos, para asegurar que es consistente con el
diseo de componentes del sistema, realizado en la Tarea D1'5 1.5
("Definicin de componentes del Sistema").
PRODUCTOS A OBTENER
Modelo de datos fsico.
TECNICA
Modelizacin fsica de datos (Depender de la estructura de ficheros en que se
desarrollar el sistema).
178 FASE 2: DISEO DE SISTEMAS MODULO DTS
TAREA DTS 2.2: OPTIMIZACION DEL MODEW FISICO DE DATOS.
Optimizar el modelo fsico de datos construido en la Tarea DTS 2.1
("Elaboracin del modelo fsico de datos") para las transacciones y dilogos
criticos identificados en la Tarea EFS 4.1. ("Produccin de prototipos preliminares
y dilogos"), de manera que se ajusten a los requisitos de rendimiento exigidos
para el sistema en cuanto a tiempos de respuesta, que han sido definidos en la
Tarea EFS 5.3 ("Especificacin de requisitos de rendimiento").
Se tendrn en cuenta en la realizacin de esta tarea los siguientes criterios:
Volmenes estimados de las entidades de datos.
Tipos de accesos a las entidades (por clave primaria o clave secundaria,
accesos a travs de otras entidades, etc.).
Frecuencia de cada tipo de acceso.
Entidades a que accede cada transaccin.
Toda esta informacin se extrae de las Tareas EFS 2.1 ("Construccin del modelo
de datos") y DTS 1.5 ("Definicin de los componentes del sistema").
Un estudio detallado de los criterios anteriores para las transacciones y dilogos
considerados como crticos, ayudar a detectar posibles inconsistencias con
respecto a los requisitos de rendimiento exigidos para el sistema. Esto puede
requerir una desnormalizacin del modelo de datos en Tercera Forma Normal,
contenido en el documento asociado al mdulo EFS, y que se ha obtenido en la
Tarea EFS 2.2 ("Normalizacin del modelo de datos"), con el fin de reducir el
nmero de accesos para las transacciones crticas. Para ello se seguirn, entre
otras, las siguientes recomendaciones.
Introducir redundancias en los elementos de datos.
Introducir elementos repetitivos.
Redefinir o aadir relaciones entre entidades para hacer ms directo el
acceso entre entidades.
FASE 2; DISEO DE SISTEMAS MODULO D1'5
Dividir entidades.
Modificar el tratamiento realizado por las transacciones criticas.
179
Combinar entidades, si los accesos para ellas son frecuentes dentro de la
misma transaccin.
En cualquier caso, se ha de tener presente que la desnormalizacin puede
implicar problemas y anomalas en las operaciones de manipulacin de datos. Por
esto, la decisin de proceder a la desnormalizacin ser funcin del
Administrador de la Base de Datos (si lo hubiera) o de la persona responsable
de la gestin de los datos dentro de la instalacin.
PRODUcroS A OBTENER
Estimacin del rendimiento de las transacciones crticas del sistema.
Modelo de datos desnormalizado.
TECNICA
Optimizacin del modelo de datos.
ACfMDAD DTS 3: ESPECIFICAR EL ENTORNO TECNOWGICO DEL SISTEMA.
DESCRIPCION
En esta Actividad se define el entorno tecnolgico en que se desarrollar el sistema,
incluyendo:
Descripcin de los componentes del equipo fsico y lgico en que funcionar el
sistema.
Descripcin de las restricciones fsicas impuestas por los componentes anteriores.
Diseo de la configuracin de la red de comunicaciones del sistema, atendiendo
a la distribucin geogrfica del mismo.
180 FASE 2: DISEO DE SISTEMAS MODULO D1'5
Dermicin de los estndares tcnicos que se aplicarn al diseo y desarrollo del
sistema, incluyendo:
Lenguajes.
Procedimientos de entrada y salida de datos, acceso al sistema, manejo de
errores y copias de seguridad.
Si el sistema en estudio est incluido dentro del Plan de Sistemas de la Unidadl, ser de
utilidad para la realizacin de esta actividad el conjunto de directrices tcnicas y de
gestin de la Unidad, as como la descripcin del entorno tecnolgico, realizados en
dicho Plan de Sistemas.
TAREA DTS 3.1: DEFINICION DEL ENTORNO TECNOLOGICO DEL SISTEMA.
Determinar las caractersticas del entorno tecnolgico en que va a funcionar el
nuevo sistema.
Se identificarn los componentes tecnolgicos necesarios para proporcionar
soporte a las funciones desarrolladas por el sistema, a la gestin de la
informacin manejada y a la distribucin geogrfica de dicho sistema.
Entre los componentes a definir, estarn:
Equipo fisico:
Gestin de datos:
Comunicaciones:
Procesadores, dispositivos de almacenamiento,
ordenadores personales, estaciones de trabajo,
etc.
Sistemas de gestin de bases de datos,
diccionarios de datos, etc.
Controladores de red, interfases externas,
protocolos, recuperacin y respaldo, etc.
FASE 2: DISEO DE SISTEMAS - MODUW D1'5 181
Equipo lgico:
Gestin de operaciones
en explotacin:
Sistemas operativos, logical de red,
generadores de aplicaciones, lenguajes de
consulta, facilidades para el desarrollo de
aplicaciones, herramientas CASE.
Herramientas de control de trabajos, planes
de contingencia, etc.
La definicin del entorno tecnolgico del nuevo sistema influye de manera
decisiva en las actividades D1'5 1 ("Disear la Arquitectura fsica del sistema") y
D1'5 2 ("Disear la estructura fsica de datos del sistema"), por ello esta tarea se
realizar antes o en paralelo a estas actividades.
En esta tarea ser necesaria la participacin activa de especialistas en tecnologa,
para ayudar a definir el entorno ptimo para el nuevo sistema.
PRODUCTOS A OBTENER
Especificacin del entorno tecnolgico del nuevo sistema.
TAREA DTS 3.2: ESPECIFICACION DE REQUISITOS DE COMUNICACIONES
DEL SISTEMA.
Disear las comunicaciones para el sistema.
En el caso de que el sistema est localizado en diferentes puntos geogrficos, se
disear la configuracin de la red de intercambio de datos entre estos puntos,
teniendo en cuenta los requisitos no funcionales especificados en la actividad EFS
5 ("Completar especificaciones del sistema") y recogidas en el Catlogo de
Requisitos.
Entre estos requisitos no funcionales, se destacan los siguientes:
Crecimiento y evolucin estimada del sistema, con respecto a cambios
esperados en su distribucin geogrfica, descentralizacin de funciones, etc.
182 FASE 2: DISEO DE SISTEMAS.; MODULO DTS
Puntos geogrficos o nodos de tratamiento de datos.
Volmenes de intercambio de datos entre las distintas redes, especificando
"picos" o perodos de sobrecarga.
Tiempos de respuesta exigidos.
Para realizar el diseo de la configuracin de la red de comunicaciones del
sistema, se seguirn los pasos que se indican a continuacin:
Seleccionar las caractersticas de la red de comunicaciones (topologa,
medios de transmisin, equipo lgico de la r ~ tipo de acceso, etc.) (Ver
DTS 3.1.: "Definicin del Entorno tecnolgico del Sistema").
Especificar los nodos de la red y asignar requisitos de rendimiento a cada
uno, teniendo en cuenta la distribucin geogrfica de las funciones del
sistema (Ver EFS 1.2 "Identificacin y Definicin de Subsistemas") y los
requisitos de rendimiento del sistema.
Asignar terminales a los nodos de la red.
Especificar accesos locales en cada uno de los nodos.
En esta tarea, es necesaria la participacin de especialistas en comunicaciones.
PRODUcroS A OBTENER
Diseo de la configuracin de la red de comunicaciones del Sistema.
TAREA DTS 3.3: ESPECIFICACION DE REQUISITOS DE OPERACION,
SEGURIDAD y CONTROL.
Definir, para cada uno de los componentes del sistema, identificados en Ha Tarea
DTS 1.5 ("Definicin de Componentes del Sistema"), los requisitos de operacin
del mismo.
Para ello, ser preciso establecer:
183
Los componentes del sistema que se ejecuten de forma regular.
Considerando, para estos componentes, los puntos que se indican a
continuacin:
Identificar los requisitos de tratamiento interactivo.
Identificar los requisitos de tratamiento diario ydefinir la secuencia
en que deben ser realizados, as como sus interdependencias.
Examinar el resto de los procesos que no sean diarios y establecer
otros periodos de tiempo requeridos.
Los componentes del sistema que slo se realicen si hay peticin.
Considerando, para estos componentes, los puntos que se indican a
continuacin:
Identificar el tipo de peticin de tratamiento de los componentes
que no se vayan a utilizar de forma regular.
Establecer los procedimientos de peticin y acordarlos con los
usuarios.
Ser de utilidad, para establecer los requisitos de operacin del sistema, la
identificacin de actividades fsicas del sistema, as como la descripcin de los
componentes realizada en la Actividad DTS 1 ("Disear la arquitectura fsica del
sistema").
Especificar en detalle los requisitos de seguridad y control, que debern
minimizar o eliminar la prdida o alteracin de los datos. Se debern revisar los
requisitos no funcionales del sistema, definidos en la Actividad EFS 5
("Completar Especificaciones del Sistema") y especificar los procedimientos
necesarios para cumplir estos requisitos, entre los que cabe destacar:
Especificacin de claves de acceso al sistema.
Especificacin de claves de acceso a los datos o a funciones especficas del
Sistema.
Desarrollo de ficheros que permitan controlar los accesos al sistema
("dietarios o logs")
184 FASE 2: DISEO DE SISTEMAS MODULO D1'5
Limitacin del nmero de intentos de acceso.
Especificacin de recuperacin y reanudacin de trabajos.
Especificacin de copias de seguridad o respaldo peridicas.
Especificacin en detalle de los procedimientos de control de trabajos.
PRODUCTOS A OBTENER
Procedimientos de operacin de los componentes del sistema, tanto peridicos
como mediante peticin.
Procedimientos de seguridad ycontrol (acceso, copias de respaldo y recuperacin,
etc...)
AcrMDAD DTS 4: COMPLETAR EL PLAN DE PRUEBAS DEL SISTEMA.
DESCRIPCION
En esta actividad se completa el plan de pruebas del sistema, a partir de la primera
descripcin realizada en la Tarea EFS 6.1 ("Preparacin del Plan de pruebas del
Sistema").
En este plan de pruebas se contemplarn los siguientes aspectos:
Arquitectura jerrquica de las pruebas a realizar .
Responsables de la realizacin de las pruebas.
Objetivos de las pruebas.
Planificacin de las necesidades de recursos (tcnicos y de personal) necesarios
para la realizacin de las pruebas.
Asimismo, se establece el entorno en que se realizarn las pruebas y se estiman los
volmenes de datos y transacciones para dichas pruebas. En todo caso, es importante
destacar que para la prueba de aspectos relativos al rendimiento del sistema en
FASE 2: DISEO DE SISTEMAS - MODULO DTS lSS
situaciones reales de alto volumen de transacciones y datos, ser necesaria una prueba
definitiva en el entorno real de explotacin.
TAREA DTS 4.1: DISEO DE PLANES DE PRUEBA DEL SISTEMA.
Disear los planes de prueba. Para ello se tomar como referencia la
documentacin obtenida como resultado de la realizacin de la Fase anterior
("Anlisis del Sistema"), y se disear un conjunto de pruebas para comprobar el
cumplimiento de las especificaciones recogidas en dicho documento.
Se seguir, para la especificacin de las pruebas, la estructura de niveles que se
especifica a continuacin:
Pruebas de componentes del sistema o unitarias.
Pruebas de integracin entre componentes.
Pruebas de cadenas.
Pruebas de transacciones.
Pruebas de subsistemas.
Pruebas del sistema.
Esta estructura jerrquica de pruebas permitir simplificar la visin del sistema,
as como comprobar el funcionamiento de partes muy detalladas del mismo. En
este sentido, hasta que uno de los niveles no se haya probado satisfactoriamente,
no se debe comenzar la ejecucin del siguiente, salvo que la prueba tenga como
objetivo aspectos funcionales totalmente distintos, pudiendo, en este caso,
realizarse avances independientes.
Adems, los planes de prueba debern incluir:
Alcance, recursos y planificacin del entorno adecuado para la realizacin
de las pruebas.
La especificacin de los objetivos de la prueba, haciendo especial nfasis
en:
Captura de informacin.
Validacin y edicin.
Tratamiento de errores.
Actualizacin de la informacin.
Interfases entre componentes.
Interfases externas.
Copias de respaldo y recuperacin.
Rendimiento del sistema para altos volmenes de informacin y
tiempos de respuesta cortos.
Responsables de la realizacin de la prueba.
En esta tarea sern de utilidad los resultados obtenidos en la Tarea EFS 6.1
("Preparacin del Plan de Pruebas del. Sistema"), donde se definen a grandes
rasgos las caractersticas que ha de recoger el plan de pruebas.
PRODUCTOS A OBTENER
Diseo de planes de prueba del sistema.
TECNICA
Diseo de p r u e ~
FASE 2: DISEO DE SISTEMAS - MODULO DTS 187
TAREA DTS 4.2: DEFINICION DEL ENTORNO Y LIMITACIONES DE PRUEBA.
Establecer el entorno tcnico necesario para realizar las actividades de prueba
planificadas.
Definir las herramientas de prueba necesarias, si se ha decidido su uso.
Estimar los volmenes de datos y de transacciones que se necesitarn para
ejecutar las pruebas. Estimar tambin los recursos necesarios de ordenador,
indicando la carga de trabajo prevista, las necesidades de almacenamiento de
datos y de comunicaciones.
Para la definicin del entorno y limitaciones de prueba, ser necesaria la participacin
activa de los responsables de sistemas de la instalacin, as como de los responsables de
base de datos, en el caso de que existan.
PRODUCTOS A OBTENER
Definicin del entorno de pruebas.
ACTMDAD DTS s: COMPLETAR ESPECIFICACIONES DE DISEO.
DESCRIPCION
En esta actividad se elaboran en detalle los planes de construccin, en cuanto a plazos,
recursos necesarios y costes estimados.
Adems se planifica de manera aproximada, la futura implantacin del sistema, con el
objeto de ir preparando la necesaria infraestructura de recursos y material.
Finalmente se har una revisin de las especificaciones de diseo, por parte del Grupo
de Calidad, con el fin de asegurar que estas especificaciones se ajustan a las
especificaciones funcionales.
Si el sistema a desarrollar est incluido dentro de un Plan de Sistemas de la n i d ~ se
modificarn las previsiones de desarrollo efectuadas en dicho Plan y se pondrn en
marcha las acciones de mantenimiento del Plan de Sistemas diseadas en la Tarea PSI
8.2 ("Mantenimiento del Plan de Sistemas") y contenidas en el documento de fm de la
fase Odel Plan de Sistemas de Informacin.
TAREA DTS 5.1: PREPARACION DE PLANES DE CONSTRUCCION
Preparar los planes para el desarrollo e integracin del nuevo equipo ngico y de
los procedimientos de operacin necesarios para el nuevo sistema.
Estos planes incluirn los aspectos siguientes:
Definicin de la secuencia de construccin de los componentes, para lo
cual se tendr en cuenta:
La estrategia de las Pruebas de Integracin.
La disponibilidad de personal.
Especificacin de recursos necesarios, incluyendo:
Necesidades de personal de desarrollo.
Tiempos y costes estimados para la realizacin de las distintas
tareas de construccin.
Equipo lgico requerido.
En la preparacin de planes y estimacin de tiempos y costes, influir de modo
decisivo el entorno tecnolgico de desarrollo (posible existencia de generadores
de cdigo, .etc.) descrito en la actividad DTS 3 ("Especificar en Entorno
Tecnolgico del Sistema").
PRODUCTOS A OBTENER
Especificacin del plan de construccin.
TECNICA
Tcnicas de estimacin.
TAREA DTS 5.2: PREPARACION DE PLANES PARA LA IMPLANTACION.
Estimar a grandes rasgos las tareas necesarias para la implantacin.
189
Esta primera aproximacin ser revisada en detalle al final de la fase siguiente
(Construccin de Sistemas), sin embargo, en este momento ayudar a preparar
con cierto adelanto los trabajos administrativos necesarios para la implantacin
del Sistema.
Entre los aspectos que se deben se incluyen los siguientes:
Personal necesario para introducir datos no existentes en el sistema actual.
Personal necesario para la conversin de datos al nuevo sistema.
Personal necesario para la realizacin de pruebas en paralelo del nuevo
sistema.
Preparacin de un calendario de implantacin, considerando:
Fechas previstas de instalacin de equipos necesarios.
Tiempo estimado para la formacin.
PRODUCTOS A OBTENER
Borrador de un plan de implantacin.
MAP - MetodologaMETRICA Versin 2
190
TECNICA
Tcnicas de estimacin.
TAREA DTS 5.3: REVISION DEL DISEO TECNICO DEL SISTEMA.
Revisar el Diseo Tcnico. Este diseo debe ser revisado por el Director del
proyecto y de los del Comit de Direccin, por el Grupo de Calidad y finalmente
por el equipo de Tecnologa de Informacin correspondiente.
Asegurar que las Especificaciones del Diseo Tcnico se ajustan a las
Especificaciones Funcionales obtenidas en la Fase de Anlisis.
Para ello ser necesario asegurar que todos los componentes del sistema,
obtenidos en la actividad DTS 1 ("Disear la Arquitectura Fsica del Sistema"),
permiten realizar todas las funciones identificadas en la fase de Anlisis del
Sistema.
Obtener la aprobacin formal de este Diseo.
PRODUCTOS A OBTENER
Conjunto completo de especificaciones de diseo revisado, validado y aprobado.
DOCUMENIACION ASOCIADA AL MODULO DTS
191
Como resultado de la realizacin de las actividades y tareas de este mdulo, se obtienen
Documento de Diseo Tcnico, DDT.
Documento de Operacin, DOP.
Plan de Pruebas del equipo lgico del proyecto, PPRB.
DOCUMENTO DE DISEO TECNICO, DDT, sus contenidos sern los siguientes:
Entorno Fsico del sistema.
Diseo Tcnico.
Diseo Detallado de Componentes del Sistema.
Diseo de Bases de Datos o Ficheros.
El ndice de dicho documento ser el siguiente:
1. Diseo de la Arquitectura del Sistema.
1.1. Diseo de la Arquitectura Modular.
1.1.1. Interfases entre Componentes.
1.2. Interfases con otros Sistemas.
1.3. Diseo Detallado.
1.3.1. Diseo Detallado de los Componentes.
1.3.2. Pantallas e Informes asociados.
1.3.3. Estructura de datos asociados.
2. Diseo Fsico de Datos.
2.1. Estructura Fsica de la Base de Datos o de los Ficheros.
2.2. Estructuras de Tablas y Vistas.
2.3. Ficheros Auxiliares.
2.4. Descripcin de Atributos.
3. Entorno Tecnolgico del Sistema.
3.1. Especificaciones del Entorno Tecnolgico.
3.1.1. Equipo Fsico.
3.1.2. Equipo Lgico.
3.1.3. Comunicaciones.
3.2. Restricciones Tcnicas.
4. Especificacin del Plan de Desarrollo e Implantacin.
5. Control de Calidad del Diseo Tcnico.
5.1. Revisin del Diseo Tcnico.
5.2. Validacin del Diseo Tcnico.
DOCUMENTO DE OPERACION, DOP, que contendr:
1. Procedimientos de operacin de los componentes del sistema.
2. Procedimientos de seguridad y control.
PLAN DE PRUEBAS DEL EQUIPO LOGICO DEL PROYECfO, PPRB, ~ se
ampliar con:
1. Diseo del Plan de pruebas del Sistema.
2. Definicin del entorno de pruebas.
FASE 3: CONSTRUCCION DE SISTEMAS
ESTRUcruRA DE LA FASE
195
La Construccin de Sistemas es la Tercera Fase de la Metodologa METRICA Versin
2 y su objetivo final es la construccin y prueba de los distintos componentes del sistema,
a partir del conjunto de especificaciones fsicas del mismo, obtenidas en la Fase de
Diseo de Sistemas.
La construccin y prueba de los componentes del Sistema, se llevar a cabo
simultneamente con la elaboracin de un conjunto de instrucciones que han de permitir
al usuario final la utilizacin ptima del sistema.
Con el fin de contemplar en detalle el conjunto de actividades que conlleva la
construccin de sistemas se ha estructurado esta fase en los siguientes mdulos:
Desarrollo de Componentes del Sistema (DCS)
Desarrollo de Procedimientos de Usuario (DPU)
INTERRELACION CON EL PLAN DE SISTEMAS DE INFORMACION
Si el sistema est incluido dentro de un Plan de Sistemas de la Unidad, se partir, para
la realizacin de esta fase, de un conjunto de documentacin en la que se incluyen:
Directrices tcnicas y de gestin de la Unidad.
Borrador de un plan de implantacin de las aplicaciones, con la especificacin de
los perfiles de personal y necesidades de informacin.
Los resultados de la realizacin de la Fase de Construccin de Sistemas, influirn en el
de Sistemas de Informacin").
Los Organos participantes en la Fase de Construccin de Sistemas sern:
Comit de Direccin.
196 FASE 3: CONSTRUCCION DE SISTEMAS
el sistema, as como por los responsables de la gestin dentro de Ila Unidad.
comunes de la Administracin (Programaciny Presupuestos, Recursos Humanos,
etc.).
Las caractersticas especficas de esta Fase hacen imprescindible la participacin
de especialistas en tecnologas de la informacin (comunicaciones, equipos fsicos,
equipos lgicos y formacin) en la realizacin de las actividades dentro de la
Fase.
Grupo de Calidad.
La constitucin de estos comits y grupos depender de las caractersticas de tamao y
complejidad del proyecto a desarrollar. As en el caso de un sistema sencillo que afecte
a una Unidad concreta, puede ocurrir que, por ejemplo, el Comit de Direccin sea
en
.....
en

>
en
n
O
Z
en

n
n
O
Z
g
DESARROllO
DE COMPONENTES
Del SISTEMA
DESARROllO
DE PROCEDIMIENTOS
DEUSUARJO
111 111 to:

11 11
MANTEfrOIENTOPlAN DE SISTEMAS
PLAN
DE SISTEMAS
DE INFORMACION
QerIYllADOTAREA
177/1 PIIOOUCTO
RESI1.T.oHIE

.
FASE 3: CONSTRUCCION DE SISTEMAS - MODULO DCS
INDICE
201
DCS: DESARROLW DE COMPONENTES DEL SISTEMA 203
Des 1:
DCS2:
DCS3:
PREPARAR ENTORNO DE DESARROLW,
PRUEBAS y PROCEDIMIENTOS DE OPERACION..... 206
1.1. Implantacin de la Base de Datos Fsica
o ficheros de datos
1.2. Preparacin del entorno de desarrollo
1.3. Preparacin del entorno de pruebas
1.4 Definicin de procedimientos de operaciones
de produccin e implantacin
DESARROLLAR Y PROBAR COMPONENTES
DEL SISTEMA 211
2.1. Generacin del C9igo de los componentes
del sistema
2.2. Preparacin, ejecucin y evaluacin de
las pruebas unitarias
2.3. Documentacin de los componentes del
Sistema
REALIZAR PRUEBAS DE INTEGRACION 217
3.1. Preparacin y ejecucin de pruebas
de integracin
3.2. Evaluacin y documentacin de los
resultados de las pruebas de integracin
MODULO DCS: DESARROLLO DE COMPONENTES DEL
SISTEMA
203
Este Mdulo tendr como objetivo realizar la Construccin, Pruebas unitarias y Pruebas
de integracin del equipo lgico y desarrollar todos los procedimientos de operacin, de
los componentes del sistema que se disearon en el Mdulo anterior D1'5 (Diseo
Tcnico del Sistema).
Los estndares que se debern utilizar en la construccin de componentes del sistema
no estn completamente detallados, ya que estos dependen del lenguaje especfico
utilizado y se realizar con tcnicas ms apropiadas para cada uno de ellos.
Es tambin objetivo de este Mdulo la preparacin del entorno de construccin y prueba
y la definicin de recursos de formacin del personal de explotacin.
La introduccin de lenguajes de cuarta generacin y de Tcnicas de Ingeniera para la
construccin del equipo lgico hacen que este proceso de construccin cada vez sea ms
automtico. Sin embargo la preparacin del entorno de construccin y de los
procedimientos de explotacin continan siendo vitales para el xito del sistema
desarrollado.
Este Mdulo debe ser realizado en paralelo con el Mdulo DPU - Desarrollo de
Procedimientos de Usuario -. Es necesaria una buena comunicacin entre los
responsables de la realizacin de ambos Mdulos, para garantizar que el Desarrollo de
Componentes del Sistema es consistente con el de los Procedimientos de Usuario.
MODULO DE DESARROLLO DE COMPONENTES Da SISTEMA (DeS)
ACCIONES PE CONTROL
DE CALIDAD
(')
O
Z
(1)
(')
(')
O
Z
ti
ttl
s::
O
ti
c:::
l""'
O
ti
(')
(1)
\/.-
-
\7_
SEGUIMIENTOYCONTROL V;
""""="'=--_.....1'ruoIlao
1. 2. DESARROLLAR Y
NPROBARENTESSODMI'O-ISTE'" 1-------'
TOS DE OPERACION
1.I1mp1_ndolo Base do DllDa 2.1 Gononci6ndel Qldigo
Flsicao Fichofosdo D_ do los ..doI SIshma
1.2 Pr....ocI6n dol Enton.. 2.2 Prop.ocI6n, Ej-r
do D..-roIIo EvalocI6n do la Pruo....
1.3 Pr....ocI6n dol UrI1lwlas
onlomo do Pruo.... 2.3 Doam1ontaci6n
1.4 Doinicilln do ProcodiniOnlDI do do los Campononlal
apor_1do - del Sillama

ACCIONES DE GESTION
DE PROVECTO
ACTIVIDADES
DESARROLLO
ACTIVIDADES
DE COMPONENTES
DEL SISTEMA
1 2 3
COMITE DE DIRECCION
DIRECTOR PROYECTO
F
GRUPO DE CALIDAD
F
GRUPO DE USUARIOS
DEPARTAMENTO DE TI
Especialistas en Sistemas E
-- ---
-----
E
EQUIPO DE PROYECTO
Jefe de Proyecto E
R
R
-- --- ----
Componentes Equipo
E
E
205
CLAVES:
A Asistencia Tcnica
D Dotar Recursos
E .. Ejecucin
F Revisin Formal
R .. Revisin Informal
I .. Suministra Informacin
ACTIVIDADES:
1. Preparar Entomo de Desarrollo, PNebaa
y Procedimientos de Operacin
2. Desarrollar y Probar Componentes
de' Sistema
3.RealiZar PNebas de 'ntegracln
locs
i
:1
206 FASE 3: CONSTRUCCION DE SISTEMAS - MODULO Des
ACTMDAD DCS 1: PREPARAR ENTORNO DE DESARROLLO, PRUEBAS Y
PROCEDIMIENTOS DE OPERACION.
DESCRIPCION
En esta actividad se asegura la disponibilidad de todos los medios y facilidades
necesarios para que la construccin y pruebas puedan llevarse a cabo de forma
adecuada. Entre estos medios cabe destacar la preparacin de los componentes fsiC9S
necesarios para la construccin, como por ejemplo, reas de trabajo y terminales, bases
de datos o ficheros de prueba, existencia de libreras de programas y de herramientas
de generacin y preparacin de equipo lgico.
Asfmismo, se definirn los procedimientos de control de versin. En este punto es
importante hacer nfasis en la necesidad de la existencia de una normativa general de
control de versiones dentro de la Unidad.
Por otra parte, en esta Actividad se preparan todos los procedimientos requeridos por
las operaciones de ordenador, tanto para ejecutar el sistema una vez implantado como
para que puedan realizarse las pruebas y los estados de transicin.
Los estados de transicin entre el sistema antiguo y el nuevo, incluirn procedimientos
de conversin de datos e instalacin del nuevo sistema adems de actividades especficas
como la ejecucin en paralelo.
Los procedimientos de operacin deben ser preparados de acuerdo a los estndares (si
existen). Si no hubiera estndares, habra que definirlos para este proyecto.
TAREA DCS 1.1: IMPLANTACION DE LA BASE DE DATOS FISICA O FICHEROS
DE DATOS
Crear las bases de datos fsicas o ficheros convencionales necesarios para realizar
la construccin y las pruebas. Esta creacin incluye los pasos siguientes:
Preparar y repasar las definiciones de la base de datos o ficheros, las
cuales se elaboraron en la Actividad DTS 2 ("Disear la estructura fsica
de datos del sistema"). Se comprobar que las tablas yvistas definidas son
correctas y se indicarn tambin los accesos, especificando las
restricciones.
Reservar el espacio fsico de almacenamiento. Se debern definir aspectos
tales como:
Dispositivo fsico que se va a emplear.
Colocacin del registro dentro de un bloque o pgina.
Tamao fsico del bloque o pgina.
Tipo de registro fsico (por ejemplo de longitud fija o variable).
Zona de desbordamiento.
Definicin de ndices.
Definicin de punteros/enlaces..
Opciones de almacenamiento de datos (p.e. tcnicas de
compresin).
Inicializar las bases de datos o ficheros.
Preparar todos los procedimientos de copias de respaldo para la base de
datos y los ficheros. Se debe reconstruir la base de datos desde la primera
copia de respaldo realizada, para comprobar el buen funcionamiento del
procedimiento de respaldo.
Documentar las bases de datos o ficheros creados. Se documentarn todas
las definiciones y procedimientos creados. Tambin se documentar
cualquier incidencia que ocurra durante el proceso de creacin.
Es importante generar varias copias de los datos para ensayo, pues sern
necesarias para diferentes momentos de la construccin y pruebas. Todas las
bases de datos debern tener una copia para pruebas y otra para construccin,
de forma que ambas actividades puedan realizarse en paralelo.
En funcin de las restricciones fsicas del gestor de base de datos, puede ser
necesario refinar el modelo de datos, con el fin de:
Ahorrar.espacio.
Facilitar el mantenimiento.
Aumentar la seguridad.
Aumentar la eficiencia.
208
PRODUcroS A OBTENER
FASE 3: CONSTRUCCION DE SISTEMAS - MODULO Des
Bases de datos fsica o ficheros convencionales para realizar la construccin y las
pruebas, con la documentacin correspondiente.
TAREA DCS 1.2: PREPARACION DEL ENTORNO DE DESARROLLO
Preparar el entorno en el que se desarrollar el sistema. El entorno de desarrollo
comprende:
Libreras para recopilar los componentes del logical del sistema (por
ejemplo, libreras de cdigo fuente, mdulos o rutinas estndar).
Procedimientos o herramientas para generar cdigo (por ejemplo,
generadores de cdigo, editores, etc.).
Procedimientos o herramientas para preparar el logical del sistema
(compiladores, verificadores sintcticos, montadores de enlace).
Puestos de trabajo y accesos a las bases de datos del equipo de
programacin.
Los pasos a seguir para realizar esta actividad son:
1. Garantizar y preparar el lugar de trabajo para todos los integrantes del
equipo de construccin:
Terminales, impresoras, etc.
2. Confirmar que cada componente del equipo de construccin tiene
asignado su acceso al ordenador (nombre de usuario, palabra clave y
restricciones).
3. Preparar todas las facilidades necesarias para la creacin fuente:
FASE 3: CONSTRUCCION DE SISTEMAS MODULO DCS
Generadores de cdigo
Editores de texto
209
4. Preparar todos los recursos necesarios para la preparacin dellogical del
sistema.
Pre-compiladores
Compiladores
Montadores de enlace
5. Preparar las libreras que sern utilizadas y todas las rutinas que puedan
ser empieadas.
PRODUCfOS A OBTENER
Descripcin completa del entorno de desarrollo que se ha preparado.
TAREA DCS 1.3: PREPARACION DEL ENTORNO DE PRUEBAS
DESCRIPCION y OBIETIVOS
Preparar los procedimientos y los recursos de ordenador necesarios para realizar
las pruebaS unitarias y las de integracin. Para preparar el entorno de pruebas se
realizarn los siguientes pasos:
Confirmar el acceso al ordenador de todos los miembros del equipo.
Asegurar que se dispone de las bases de datos o ficheros de datos para laS
pruebas (incluyendo parmetros y datos necesarios).
Preparar las libreras necesarias para la prueba de componentes.
Preparar todos los procedimientos (automticos o manuales) necesarios
para llevar a cabo las pruebas:
Inicio de las pruebas.
Formato en el que obtener los resultados.
Informes de errores y/o problemas que ocurran durante la prueba.
Probar el buen funcionamiento del entorno de pruebas creado, asegurando que
210 FASE 3: CONSTRUCCION DE SISTEMAS - MODULO DCS
todos los componentes del equipo de construccin tienen acceso al ordenador, a
las bases de datos o ficheros de datos para las pruebas y al resto de las
facilidades.
PRODuCTos A OBTENER
Descripcin completa del entorno de pruebas que se ha preparado.
TAREA DCS 1.4: DEFINICION DE PROCEDIMIENTOS DE OPERACIONES DE
PRODUCCION E IMPLANTACION
Preparar los procedimientos requeridos por los operadores y necesarios para
ejecutar el sistema una vez que se haya implantado y est en produccin. Los
procedimientos incluirn:
Operaciones de arranque diario del sistema y de cierre.
Tratamientos peridicos por lotes (se deber indicar el perodo - diario,
semanal - de estos tratamientos).
Tratamientos que slo se ejecutan bajo peticin (por ejemplo, informes
especiales).
Procedimientos de creacin de copias de seguridad de los datos de la
aplicacin, y de restauracin de las copias, indicando su frecuencia.
Procedimientos de operacin del equipo lgico adquirido.
Manipulacin de errores. Se debern documentar todos los mensajes que
podrn aparecer a los operadores, junto con su accin correctiva (si
existe).
Preparar todos los procedimientos necesarios para los operadores durante el
tiempo de transicin de la antigua aplicacin (cuando exista) a la nueva. Se
llevarn a cabo los siguientes pasos:
FASE 3: CONSTRUCCION DE SISTEMAS - MODULO DCS 211
Preparar procedimientos para la conversin de datos (se incluir tanto
conversin manual de datos, como conversin automtica).
Preparar los procediIIientos de instalacin del nuevo sistema. Estos
procedimientos pueden incluir la ejecucin en paralelo de ambos sistemas,
o el fin de actividad del sistema antiguo. Estos procedimientos se
realizarn en un tiempo limitado y no es precisa una definicin altainente
formal de los mismos.
PRODUCTOS A OBTENER
Procedimientos de operaciones de produccin e implantacin.
ACfMDAD DCS 2: DESARROLLAR Y PROBAR COMPONENTES DEL SISTEMA
DESCRIPCION
En esta Actividad se generar el cdigo correspondiente a cada uno de los componentes
identificados en el Mdulo D1'5 (Diseo Tcnico del Sistema) yse realizarn las pruebas
unitarias correspondientes a cada componente. Por ltimo se documentar el cdigo
obtenido.
Habr que tener en cuenta que esta actividad cubre tanto el equipo lgico necesario
para la migracin de los datos al nuevo sistema, como el del sistema en s mismo.
Debe tenerse en consideracin que esta Actividad se realizar de forma reiterativa, para
cada componente a desarrollar. Se har una codificacin inicial del componente, se
realizarn pruebas unitarias, y se harn las correcciones necesarias al cdigo para
resolver los problemas detectados en las pruebas unitarias. Puede ser que los errores no
se deban slo a una codificacin incorrecta, sino a errores en el diseo o incluso en la
especificacin funcional. Si esto ocurre, habra que hacer las oportunas correcciones en
los Mdulos D1'5 (Diseo Tcnico del Sistema) y/o EFS (Especificacin Funcional del
Sistema) y documentar adecuadamente las modificaciones hechas.
N
DCS2. DESARROLlAR YPROBAR COMPONENTES DEL SISTEMA

()
O
Z
tn

()
()
O
Z
tl
t
ICORRECCIONES
RESULTADOS
DCS3. REAUZAR PRUEBAS DE INTEGRAClON
2.3 DOCUMENTACION DE LOS
COMPONENTES DEL SISTEMA
RESULTADOS
CORRECCIONES
3.1 PREPARACION y EJECUClON .. 32 EVALUACION y OOCUMEN-
DE PRUEBAS DE INTEGRACION
TAClON DE RESULTADOS DE
lo
PRUEBAS DE INTEGRACION
CORRECCIONES
2.1 GENERACION DEL CODIGO
2.2 PREPARACION. EJECUClON
y EVALUAClONDE lAS
PRUEBAS UNITARIAS
RESULTADOS
TAREA DCS 2.1: GENERACION DEL CODIGO DE LOS COMPONENTES DEL
SISTEMA
213
Generar el cdigo necesario para cada Componente (incluir la reutilizacin de
cdigo existente as como la generacin de cdigo nuevo). Para ello, se llevarn
a cabo los siguientes pasos:
Disear la estructura del cdigo para cada Componente. (Si en el Mdulo
DTS - Diseo Tcnico del Sistema - se .hizo un diseo bien estructurado,
esta estructura estar implcita en las especificaciones hechas para cada
componente).
A la hora de disear la estructura del cdigo de los componentes, es
conveniente la existencia, dentro de la Unidad o de la Organizacin, de
estndares de programacin para todos los programadores de modo que
se facilite el trabajo de mantenimiento. Adems ser preciso conseguir una
estructuracin adecuada de dicho cdigo, dividindolo en segmentos
fcilmente comprensibles. Para ello se utilizarn tcnicas de programacin
estructurada, pudiendo ser de utilidad, en algunos casos, el diseo de
diagramas de estructura de cuadros, para los componentes del Sistema que
por su criticidad o por su complejidad, requieran una especial atencin.
Para la realizacin de este diseo se tomar como punto de partida la
descripcin detallada de los componentes del sistema contenida en el
documento de la Fase de Diseo de Sistema y que se ha obtenido con la
realizacin de la Tarea D1'5 1.5 ("Definicin de componentes del
sistema").
Escribir el cdigo fuente. Ser preciso documentar exhaustivamente el
cdigo generado, escribiendo comentarios y asignando nombres a los
parmetros y variables que sean significativos.
Preparar cdigo ejecutable a partir del cdigo fuente. Segn el entorno de
construccin utilizado, este paso puede incluir:
Verificar sintcticamente el cdigo.
Ensamblar o compilar.
Enlazar el cdigo.
Revisar el cdigo fuente para detectar posibles errores lgicos del mismo.
Suele ser til que la revisin sea hecha por un programador distinto al que
codific el programa.
PRODucrOS A OBTENER
Diseo de la estructura del cdigo de cada componente.
Cdigo fuente de los componentes del sistema
TECNICAS
Diagramas de estructura de cuadros de Constantine.
Tcnicas de estructuracin de programas.
TAREA DCS 2.2: PREPARACION, EJECUCION y EVALUACION DE LAS
PRUEBAS UNITARIAS
DESCRIPCION y OB.IETIVOS
Completar para cada componente las especificaciones de prueba. Estas
especificaciones fueron definidas en la Tarea D1'5 4.1 ("Diseo de planes de
prueba del sistema") y estn contenidas en la documentacin del mdulo D1'5
("Diseo Tcnico del Sistema").
Definir los conjuntos de datos de entrada, requeridos para las pruebas de los
componentes. Entre ellos, se considerarn los siguientes:
Registros de datos o pantallas a construir para probar cada componente.
Conjunto requerido de instrucciones para el control de trabajos.
Para cada uno de los elementos de datos de entrada, se han de definir:
Valores invlidos.
Valores vlidos.
Formatos invlidos.
Rangos de valores (permitidos y no permitidos)
Preparar la base de datos o ficheros de datos de prueba.
215
Asegurar que todos los recursos necesarios para la realizacin de la prueba
(incluyendo personal, horarios, herramientas de prueba) estn preparados.
Ejecutar las pruebas planificadas para cada uno de los componentes codificados.
Las pruebas debern realizarse conforme al plan especificado, que deber incluir:
Inicio.
Posibles acciones durante la ejecucin de la prueba.
Interrupcin normal o prematura de la prueba.
Contingencias no esperadas durante la ejecucin de la prueba.
Cada prueba realizada debe quedar registrada en un documento, denominado
"Informe de Prueba Unitaria", donde se reflejarn todas las incidencias acaecidas
durante la prueba, detallndose:
Datos de entrada.
Resultados esperados y resultados obtenidos.
Fecha y hora de ejecucin de la prueba.
Personal participante en la preparacin y ejecucin de la prueba.
Incidencias ocurridas durante la ejecucin y acciones que se llevarn a
cabo.
Causas conocidas, o indicios de los fallos detectados.
Para realizar las pruebas unitarias de los cOiDponentes o mdulos del Sistema, se
ha de tener en cuenta que puede ser necesario codificar uno o ms programas
auxiliares que permitan establecer la precondiciones necesarias, invocar el mdulo
objeto de la prueba y examinar los resultados de la misma.
Evaluar los resultados de las pruebas unitarias:
Comparar los resultados obtenidos con los esperados.
Determinar qu acciones deben llevarse a cabo para solucionar cada
problema (estas acciones pueden incluir desde revisar el cdigo hasta
revisar las especificaciones de diseo y/o la especificacin funcional).
Realizar las oportunas correcciones, y actualizar la correspondiente
documentacin.
Indicar qu pruebas deben volver a realizarse o si son necesarias nuevas
pruebas.
Completar el documento para cada prueba, aadiendo una evaluacin del
componente, su posible desviacin de los requisitos iniciales, y los
problemas sin resolver.
Terminar las pruebas unitarias, cuando todos los componentes hayan sido
probados satisfactoriamente. Se generar un informe de Pruebas Unitarias
Realizadas, que deber ser revisado.
PRODUCTOS A OBTENER
Pruebas unitarias de los componentes del sistema.
Informe de Prueba Unitaria para cada uno de los componentes.
TECNICA
Tcnicas de prueba.
TAREA DCS 2.3: DOCUMENTACION DE WS COMPONENTES DEL SISTEMA
Completar y agrupar la documentacin de cada componente del sistema en un
nico bloque, en el cual se incluir:
Revisiones de la especificacin del componente, como problemas resueltos,
mensajes aadidos, etc.
listados del cdigo fuente.
listados del equipo lgico de operacin necesarios para realizar las
pruebas de los componentes del Sistema (por ejemplo: macros).
Evidencias de la ejecucin satisfactoria de las pruebas unitarias (listados,
copia impresa de pantalla, etc.)
PRODUcroS A OBTENER
Documentacin completa de los componentes del sistema.
ACTMDAD DCS 3: REALIZAR PRUEBAS DE INTEGRACION
DESCRIPCION
217
En esta actividad se realizan las pruebas de integracin entre los componentes, con el
fin de asegurar que todos las interfases entre los Componentes funcionan correctamente
y que el sistema es capaz de funcionar en su totalidad sin ningn fallo. Tambin ser
objeto de esta Actividad comprobar que todos los procedimientos definidos (de equipo
lgico de aplicacin, de operacin) son tcnicamente compatibles.
No es objetivo de esta Actividad probar la funcionalidad del sistema, sino comprobar que
el sistema puede ser ejecutado sin interrupciones de una manera completa. Es decir, la
Actividad est enfocada a la integracin entre los Componentes desarrollados, ms que
a la funcionalidad. La separacin de las pruebas de integracin y las del sistema tiene
como ventaja que los usuarios suelen participar en las pruebas del sistema, mientras que
las pruebas de integracin son, efectuadas slo por el equipo de construccin.
Los errores tcnicos reducen confianza de los usuarios en el sistema y es preferible
eliminarlos antes de que el usuario vea el sistema en operacin. Sin embargo, si son
detectados errores funcionales obvios durante la prueba de integracin debidos
claramente a errores de programacin, se corregirn en el correspondiente Componente.
Si no hubiera defectos de integracin, los defectos funcionales identificados serian
registrados para las pruebas del sistema.
TAREA DCS 3.1: PREPARACION y EJECUCION DE PRUEBAS DE INTEGRACION
Preparar las Pruebas de Integracin de acuerdo con el plan de pruebas
especificado en la Tarea DTS 4.1 ("Diseo de de Prueba del y
que est incluido en la documentacin del mdulo D1'5 ("Diseo Tcnico del
Sistema").
Para ello se han de considerar los aspectos siguientes:
Obtener los Datos de Prueba.
Comprobar que los Componentes que van a integrarse son llamados en el
momento correcto.
Comprobar que se han desarrollado todas las interfases entre los
diferentes Componentes que se integran.
Garantizar que se dispone de todos los.recursos necesarios para efectuar
las pruebas (tablas de control, equipo lgico adquirido).
Ejecutar las pruebas de integracin, asegurando que todos los elementos
integrados se comportan de acuerdo con lo establecido. Los pasos a seguir son:
Realizar todos los procedimientos de prueba que se detallaron en la Tarea
D1'5 4.1 ("Diseo de Planes de Prueba del Sistema"), donde se indicaba
cmo iniciar las pruebas, qu datos deban obtenerse, cmo finalizar la
prueba (terminacin normal o interrupcin voluntaria), y cmo actuar en
caso de contingencias no esperadas.
Registrar y documentar todas las incidencias ocurridas durante na prueba.
Elaborar un Informe de las Pruebas de Integracin.
PRODUcroS A OBTENER
Pruebas de integracin entre componentes del sistema.
Informe de Pruebas de integracin.
Equipo lgico resultante, una vez realizadas las pruebas de integracin.
TECNICA
Tcnicas de prueba..
FASE 3: CONSTRUCCION DE SISTEMAS - MODULO Des 219
TAREA DCS 3.2: EVALUACION y DOCUMENTACION DE LOS RESULTADOS DE
Evaluar los resultados de las pruebas de integracin, incluyendo:
Acciones que deben realizarse para resolver cada problema de integracin
detectado.
Iniciar todas las acciones correctivas necesarias.
Actualizar todos los documentos del proyecto que hayan sido afectados por
correcciones.
Determinar las pruebas que deben volver a efectuarse, para comprobar
que han sido corregidos los errores de integracin.
Completar y consolidar todos los informes de las pruebas de integracin.
PRODUCTOS A OBTENER
Documentacin consolidada de los componentes afectados por correcciones.
Informes de pruebas de integracin.
DOCUMENTACION ASOCIADA AL MODULO DTS
Como resultado de la realizacin de las actividades y tareas de este mdulo, se obtienen
Documento de Operacin, DOP.
Documentacin Tcnica de Programacin, DTP.
Cdigo Fuente de los componentes del Sistema.
220 FASE 3: CONSTRUCCION DE SISTEMAS MODULO DCS
Plan de Pruebas del equipo lgico, PPRB.
Informe de las Pruebas de Validacin de mdulos, IPVM.
Informe de Pruebas de Integracin, IPI.
Aplicacin (Equipo lgico ejecutable), APL.
DOCUMENTO DE OPERACION, DOP, que se ampliar con:
1. Procedimientos de operaciones de produccin e implantacin.
DOCUMENTACION TECNICA DE PROGRAMACION, DTP, que contendr:
1. Diseo de la estructura del cdigo de cada componente.
2. Documentacin completa de lo's componentes del sistema.
3. Documentacin consolidada de los componentes afectados por
correcciones.
PLAN DE PRUEBAS DEL EQUIPO LOGICO DEL PROYECfO, PPRB, que se
ampliar con:
1. Pruebas unitarias de los componentes del sistema.
2. Pruebas de integracin entre componentes del sistema.
INFORME DE LAS PRUEBAS DE VALIDACION DE MODULOS, IPVM, que
contendr:
1. Informe de prueba unitaria para cada uno de los componentes del sistema.
INFORME DE PRUEBAS DE INTEGRACION, IPI, que contendr:
1. Resultados de las pruebas de integracin.
APUCACION, APL, que contendr:
1. Equipo lgico resultante una vez realizadas las pruebas de integracin.
FASE 3: CONSTRUcaON DE SISTEMAS MODULO DPU
FASE 3: CONSlRUCCION DE SISTEMAS
INDICE
223
DPU: DESARROLLO DE PROCEDIMIENTOS DE USUARIO ....... 22S
DPU 1:
DPU2:
DPU3:
DPU4:
COMPLETAR EL PLAN DE
DESARROLLO DE PROCEDIMIENTOS
'DE USUARIO .......................... 229
1.1. Preparacin de un borrador del plan
de desarrollo de procedimientos
de usuario
1.2. Especificacin de criterios de calidad y
estndares de procedimientos de usuario
ELABORAR PROCEDIMIENTOS DE
USUARIO ................................. 232
2.1. Diseflo de la estructura de los
procedimientos de usuario
2.2 Elaboracin de procedimientos
de usuario
DETERMINAR NECESIDADES
ESPECIALES PARA EL FUNCIONAMIENTO
DEL SISTEMA 236
3.1. Identificacin de perfiles de usuario
3.2. Especificacin de recursos necesarios
DESARROLLAR PLAN DE FORMACION
DE USUARIOS .............................. 239
4.1. Identificacin de requisitos y recursos
necesarios para la formacin de usuarios
4.2. Preparacin de los materiales de formacin
de usuarios
224
OPUS:
FASE 3: CONSTRUCCION DE SISTEMAS - MODULO DPU
CONSOLIDAR PROCEDIMIENTOS DE USUARIO 244
5.1. Organizacin de la documentacin de
5.2. Consolidacin de la documentacin de
MODULO DPU: DESARROLLO DE PROCEDIMIENTOS DE
USUARIO
DESCRIPCION y OBJETIVOS GENERALES.
22S
El propsito de este Mdulo es definir todos los procedimientos y formacin necesaria
para que los usuarios sean capaces de utilizar el nuevo sistema de forma satisfactoria,
y puedan explotar sus facilidades para lograr los mejores beneficios.
Los procedimientos de usuario describirn el conjunto.de operaciones manuales que han
de seguir dichos usuarios a la hora de trabajar con el sistema, haciendo especial nfasis
en los siguientes momentos del ciclo de vida de los sistemas:
Instalacin y conversin de datos.
Operacin y produccin.
La descripcin de estas operaciones manuales a seguir por los usuarios, incluir aspectos
tales como: por quin, cmo, dnde y cundo han de realizarse.
Tambin es objeto de este mdulo, determinar cul va a ser la formacin necesaria para
los usuarios, y estimar cules van a ser los recursos de usuarios (personal, equipos, etc),
necesarios para el entorno de trabajo.
La realizacin de este Mdulo se iniciar, en el caso de sistemas desarrollados
completamente, una vez que se haya completado la Especificacin Funcional del Sistema
(Mdulo EFS) y se realizar en paralelo a los Mdulos de Diseo Tcnico del Sistema
(DTS) y Desarrollo de Componentes del Sistema (DCS).
En el caso de sistemas en los que exista equipo lgico estndar adquirido a proveedores
externos, se realizar este Mdulo en paralelo con el de Desarrollo de Componentes del
Sistema (para poder especificar tambin aquellos procedimientos propios de las
interfases entre el equipo lgico adquirido y las partes de nueva construccin).
Es de suma 'importancia la comprensin de todas las funciones 1que realizar el nuevo
sistema, para poder identificar los perfiles de usuario requeridos. Puede ser a veces
necesario redefinir los puestos de trabajo actuales para un mejor empleo del sistema.
226 FASE 3: CONSTRUCCION DE SISTEMAS MODULO DPU
En el caso de que el sistema est incluido en un Plan de Sistemas de la Unidad, se
dispondr, como punto de partida para la realizacin de este mdulo, de un conjunto de
documentacin, contenida en el Documento del Plan de Sistemas de Informacin, entre
la que se incluye:
Plan de Implantacin del Sistema, que contiene el esbozo de un plan de
formacin de los usuarios.
Directrices tcnicas y de gestin de la organizacin. Entre las que puede figurar
un estndar de elaboracin y configuracin de los procedimientos de trabajo de
la unidad.
3.11d1n1ificod6n Pe_
do_
3.2Espod_iln
--
t t
+
\l_A....O-
_dlUoua1o
\1--
dlCIIIdIlI
\1._1'1_-
dlUouoo
SEGUlIIIENTOy CONlllOL
MODULO DE DESARROLLO DE PROCEDIMIENTOS DE USUARIODPU)
ACCIONES DE GESTION
DE PROYECTO
AlX:IONES DE DIRECClON
ACaONES DE CONlllDl
DECAUIlAD
AClIV1IIAOES
WNIlADaGMf!C9
{I AEVISICN IIfORloW.
V,.._....I
_REVISIONFIlRIIAL
... ~ m l
228 FASE 3: CONSTRUCCIONDE SISTEMAS- MODULO DPU
DESARROLLO
ACTIVIDADES
DE PROCEDIMIENTOS
DE USUARIO
1 2 3 4 5
COMITE DE DIRECCION R
D,F F
DIRECTOR PROYECTO
R
F
F
GRUPO DE CALIDAD R
F
GRUPO DE USUARIOS
DEPARTAMENTO DE TI
A
--- ---- ----- - - -- - ---
A
A
EQUIPO DE PROYECTO
Jefe de Proyecto
E
R E
E
E
--- f----- ----- -----
----
Componentes Equipo
E E
CLAVES:
A .. Asistencia Tcnica
D la Dotar Recursos
E .. Ejecuci6n
F Revisi6n Formal
R .. Revisi6n Informal
I .. Suministra Informaci6n
ACTIVIDADES:
1.Completar Plan de Desarrollo
de Procedimientos de Usuario
2.Elaborar Procedimientos de Usuario
3.Determinar Necesidades especiales
de funcionamiento del Sistema
4.Desarrollar Plan de Formaci6n
de Usuarios
S.Consolidar Procedimientos de Usuario
FASE 3: CONSTRUCCION DE SISTEMAS MODULO DPU
ACTIVIDAD DPU 1: COMPLETAR EL PLAN DE DESARROLLO DE
PROCEDIMIENTOS DE USUARIO.
DESCRIPCION.
229
En esta Actividad se establece la estrategia para desarrollar los procedimientos de
usuario y el plan de formacin, y se identifican los recursos materiales y personales
necesarios para el funcionamiento ptimo del sistema..
Se preparar, como producto final de esta Actividad un plan detallado de desarrollo de
los Procedimientos de Usuario, en el que se defmir:
El formato de los Procedimientos.
Los estndares y las vas de actualizacin de los Procedimientos.
Recursos y tiempos necesarios.
Tambin se preparar un Plan de Formacin de Usuarios.
La existencia dentro de la Unidad de estndares de elaboracin y configuracin de
procedimientos, as como de criterios de calidad, eliminar la necesidad de ejecucin de
alguno de los puntos comprendidos en las tareas de esta Actividad.
TAREA DPU 1.1: PREPARACION DE UN BORRADOR DEL PLAN DE
DESARROLLO DE PROCEDIMIENTOS DE USUARIO
DESCRIPCION y OBJETIVOS.
Definir un Plan para preparar:
Los procedimientos de usuario.
El programa de formacin de los usuarios.
Los recursos y el personal necesarios para la operacin ptima del nuevo
sistema.
230 FASE 3: CONSTRUCCION DE SISTEMAS - MODULO DPU
El Plan debe identificar:
Fechas crticas.
Actividades crticas.
Recursos necesarios.
Mecanismos para cada actividad que se incluya en este plan.
La realizacin de este borrador se llevar a cabo siguiendo los siguientes pasos:
1. Recopilar todas las Actividades que vayan a planificarse y agruparlas por
tipos:
Procedimientos de usuario.
Actividades del programa de formacin a usuarios.
Requisitos de recursos de usuariO.'
2. Identificar cules son los productos/objetivos que se esperan para cada
actividad.
3. Asignar fechas de inicio y fin a cada actividad (es importante, a la hora de
establecer fechas, tener en consideracin las posibles dependencias de
unas actividades con otras).
4. Asignar responsables para cada actividad, tanto del equipo de trabajo del
proyecto como de los usuarios y repasar las fechas asignadas con ellos.
5. Documentar este borrador, indicando:
Actividades.
Fechas.
Responsables.
PRODUcroS A OBTENER.
Borrador del Plan de desarrollo de procedimientos de usuario.
TAREA DPU 1.2: ESPECIFICACION DE CRITERIOS DE CALIDAD Y
ESTANDARES DE PROCEDIMIENTOS DE USUARIO
DESCRlPCION y OBJETIVOS
231
Identificar los criterios de Control de Calidad que deben seguirse durante la
elaboracin de los Procedimientos de Usuario. Estos criterios vel1drn dictados
por auditoras internas, o estndares existentes.
Revisar el plan hecho en la tarea anterior y comprobar que se ajusta a los
criterios de Calidad. Como consecuencia de esta revisin, hacer las oportunas
modificaciones.
Establecer qu estndares van a seguirse en la construccin de los procedimientos
de usuario:
1. Formato en el que se desarrollarn, considerando los aspectos siguientes:
Formato narrativo.
Lista paso a paso de las acciones que se realizan secuencialmente.
Inclusin de ejemplos de los informes obtenidos por el sistema.
Inclusin de ejemplos de las pantallas del sistema.
Inclusin de ejemplos de formatos de datos de entrada.
Descripcin de los apndices (glosario de trminos utilizados,
descripcin de las tcnicas empleadas, etc.)
2. Estilo que tendr el documento de los Procedimientos de Usuario,
incluyendo:
Ttulos.
Secciones del documento.
Firma de aprobacin.
Mrgenes, numeracin de pginas, etc.
3. Estndares de distribucin y mantenimiento:
Nmero de copias a editar.
Departamentos que deben recibir copia (identificando, si es posible,
232 FASE 3: CONSTRUCCION DE SISTEMAS MODULO DPU
a las personas).
Fechas de distribucin y de envo de actualizaciones.
Archivo.
Control de versin.
4. Documentar los estndares y formatos elegidos.
Incorporar el documento sobre estndares y formatos a la Planificacin (una vez
comprobado que sigue los criterios de Control de Calidad) y obtener la
aprobacin del Plan de Construccin de los Procedimientos de usuario.
PRODUcroS A OBTENER,
Plan de Construccin de los Procedimientos de usuario.
ACTMDAD DPU 2: ELABORAR PROCEDIMIENTOS DE USUARIO
DESCRIPCION.
En esta Actividad se elaboran los procedimientos de trabajo que deben seguir los
usuarios con el fin de conseguir la explotacin eficaz del nuevo sistema y asegurar el
correcto uso de los datos y procesos del sistema. Para ello, se har especial nfasis en
los siguientes aspectos:
La definicin y preparacin de todas las instrucciones necesarias para que los
usuarios realicen las actividades (manuales o automatizadas), incluyendo
manipulacin de errores, interfases manuales entre procesos automatizados y
procedimientos de inicializacin y fin del nuevo sistema. -- - o-
Definicin de las instrucciones necesarias para que los usuarios conviertan las
actividades y datos manuales a los nuevos sistemas automatizados.
El tamao de los sistemas, as como la relacin entre el equipo de trabajo y los usuarios,
determinar el nivel de detalle de la escritura formal de los procedimientos de usuario.
FASE 3: CONSTRUCCION DE SISTEMAS MODULO DPU 233
TAREA DPU 2.1: DISEO DE LA ESTRUcruRA DE LOS PROCEDIMIENTOS DE
USUARIO
DESCRIPCION y OBJETIVOS,
Establecer las actividades y tareas en su orden natural para los procedimientos
de usuario de:
Conversin de datos.
Instalacin.
Produccin/Operacin.
Los procedimientos de conversin de datos son limitados en comparacin con los
procedimientos de produccin. Es importante definir en estos procedimientos, los
criterios de aceptacin y verificacin de los datos convertidos del sistema antiguo
al nuevo.
Los procedimientos de instalacin, se utilizan generalmente slo en un perodo
inicial y muy limitado, por lo que no ser necesaria una definicin excesivamente
formal de los mismos, salvo en aquellos casos en los que la instalacin se realice
por personal ajeno al equipo del proyecto
Para la preparacin de los procedimientos de produccin/operacin, gran parte
de los detalles requeridos podrn encontrarse en 1;15 especificaciones contenidas
en la documentacin del mdulo EFS ("Especificacin Funcional del Sistema"),
en cuanto a:
Especificacin de procesos manuhles.
Definicin de Interfases de usuario.
As como las especificaciones contenidas en la documentacin del mdulo DTS
("Diseo Tcnico del Sistema"), en cuanto a:
Diseo de interfases de usuario.
Los pasos a seguir, para realizar esta tarea son los siguientes:
1. Identificar todas las actividades, definidas en la documentacin asociada
al mdulo EFS ("Especificacin Funcional del Sistema") y clasificarlas en
los tres grupos ya citados:
Instalacin.
Conversin de datos.
Produccin.
2. Definir las interfases entre procedimientos, es decir, determinar los pasos
intermedios necesarios entre dos actividades. A veces, puede existir un
producto final de una actividad, que sea la entrada para otras actividades.
3. Establecer horarios y tiempos. Las actividades deben organizarse en orden
secuencial:
Incluir las tareas de instalacin por orden cronolgico y por usuario
al que se va a instalar.
Tareas de conversin de datos.
Actividades de operacin /produccin:
Arranque diario.
Procesos peridicos.
Procesos que se realizan bajo peticin.
Procesos de mantenimiento, copias de respaldo.
Procesos de manipulacin de errores.
5. Preparar un borrador con la especificacin de cada actividad, para cada
uno de los tres grupos de procesos, e identificar procedimientos que sean
comunes para ms de un grupo (se escribirn de forma estndar).
6. Preparar el ndice de contenidos, siguiendo el formato que defina el grupo
de control de calidad.
PRODUCTOS A OBTENER.
Diseo de la Esttuctura de Procedimientos de usuario.
TAREA DPU 2.2: ELABORACION DE PROCEDIMIENTOS DE USUARIO
23S
Preparar y escribir las instrucciones necesarias para que los usuarios realicen los
procedimientos de instalacin, conversin de datos y operacin/produccin del
nuevo sistema.
Estas instrucciones deben:
Proporcionar ayuda continua durante las fases de inicio del funcionamien-
to del sistema (y durante el perodo de ejecucin en paralelo del sistema
antiguo y del nuevo).
Integrarse, en cuanto a su elaboracin, con los estndares de la Unidad
(que se revisaron durante la Tarea DPU 1.2 ("Especificacin de Criterios
de Calidad y Estndares de Procedimientos de Usuario").
Incluir instrucciones para hacer un seguimiento de cargas de trabajo,
porcentajes de error, etc.
Recoger todas las instrucciones necesarias para los procedimientos de
copias de respaldo, arranque, actividades a fin de mes y de ao, archivo
y destruccin de documentos.
Los pasos a seguir para'la ejecucin de esta Tarea son:
1. Escribir cada procedimiento, siguiendo el estilo y formato estndar que se
decidi en la Tarea DPU 1.2 ("Especificacin de Criterios de Calidad y
Estndares de Procedimientos de Usuario"). Cada procedimiento escrito
debe contener:
Descripcin general de qu se realiza y por qu.
Los pasos a seguir.
Las referencias necesarias a documentos utilizados, interfases con
otros sistemas, horarios, cdigos de error, equipos.
Perfiles de usuario que deban realizar cada uno de los pasos.
Referencias cruzadas respecto a las actividades previas y posterio-
res.
2. Validar cada Procedimiento. Revisar si est escrito de forma clara, lgica
y sin ambigedades. Corregir los errores detectados.
3. Solicitar la revisin de los procedimientos elaborados por parte del
Responsable de usuarios.
4. Recopilar todo el material elaborado para los procedimientos de usuario:
Indice de Contenido.
Textos.
Diagramas.
Tablas.
y componer el Manual de Usuario, para finalmente hacer las copias y
proceder a su distribucin entre los usuarios designados.
Manual de Usuario del nuevo sistema, que contiene los procedirruientos de
usuario del sistema.
ACfMDAD DPU 3: DETERMINAR NECESIDADES ESPECIALES PARA EL
FUNCIONAMIENTO DEL SISTEMA
DESCRIPCION.
En esta actividad se definen los recursos necesarios para el nuevo sistema, en lo
referente a los usuarios del mismo: su cualificacin, nmero, nivel y tipo ms adecuado.
Estos usuarios debern tener la experiencia, conocimientos y organizacin precisos para
realizar todos los procedimientos propios del sistema.
Por otra parte, se definen tambin las necesidades especiales o requisitos en cuanto a
equipos, consumibles, etc. necesarios para garantizar un funcionamiento adecuado del
nuevo sistema, con el fin de iniciar con suficiente antelacin los procedimientos
administrativos de adquisicin de los mismos.
TAREA DPU 3.1: IDENTIFICACION DE PERFILES DE USUARIO
237
Identificar qu tipos de usuarios se necesitan para realizar los procedimientos de
conversin de datos y produccin del nuevo sistema.
Determinar con exactitud cules son los conocimientos y la experiencia que
actualmente tiene el personal usuario, y compararlos con los que se consideran
necesarios para el funcionamiento ptimo del sistema. De los resultados de esta
comparacin se identificarn las deficiencias existentes, con el fin de disear en
actividades posteriores el plan de formacin.
Especificar en detalle el personal usuario requerido, teniendo en cuenta los
resultados obtenidos en los puntos anteriores, y haciendo nfasis en los siguientes
aspectos:
Su nmero.
Los conocimientos y habilidades que deben tener.
Sus responsabilidades y organizacin.
Redisear los puestos de trabajo, a partir de las deficiencias determinadas. Esto
puede suponer:
Redistribuir la carga de trabajo.
Establecer horarios para las actividades del nuevo sistema.
Optimizar el control de las actividades.
Especificar formalmente los Requisitos de Personal Usuario:
Describir la nueva organizacin, incluyendo las actividades y
responsabilidades que debern asumir los usuarios.
Describir los puestos de trabajo requeridos, indicando el nmero de
personas precisas en cada uno de ellos.
238
Definicin de perfiles de usuario requeridos.
TAREA DPU 3.2: ESPECIFICACION DE RECURSOS NECESARIOS
Determinar el equipo adicional o alternativo, los consumibles y el entorno de
trabajo que el nuevo sistema precisar.
Preparar las especificaciones que definan los recursos necesarios para que el
Departamento encargado de las compras, haga los pedidos pertinentes.
Seguir el proceso de adquisicin para garantizar que los recursos solicitados son
entregados a tiempo.
Los pasos a seguir para la ejecucin de esta tarea son los siguientes:
1. Revisar los Procedimientos de Usuario e identificar qu recursos sern
necesarios:
Equipos, tales como lectores pticos, lectores de cdigos de barras.
Consumibles, como cintas de copias de respaldo, formularios en papel
continuo, etc.
Recursos para el entorno de trabajo, como nuevas instalaciones elctricas,
espacio para nuevos usuarios.
y hacer una lista detallada de ellos.
2. Hacer una lista detallada de los recursos disponibles en la actualidad y
compararla con la lista del paso 1. Se determinar de esta forma qu recursos
deben adquirirse.
fASE 3: CONSTRUCCION DE SISTEMAS MODULO DPU
PRODUcroS A OBTENER,
Especificacin de los recursos necesarios.
AcrIVlDAD DPU 4: DESARROLLAR PLAN DE FORMACION DE USUARIOS
DESCRIPCION.
239
En esta Actividad se define cul es el nivel ptimo de conocimientos sobre el nuevo
sistema que permita realizar todas las tareas y responsabilidades definidas en los
Procedimientos de Usuario.
Es-preciso adems, establecer las diferencias entre los conocimientos y aptitudes actuales
con los que se requerirn para el buen funcionamiento del nuevo sistema.
Teniendo en cuenta las necesidades de formacin as establecidas, se elaborarn todos
los Materiales para la Formacin de los usuarios, y se realizar una planificacin de la
formacin a impartir. Los Materiales de Formacin deben desarrollarse con los medios,
nivel de detalle y tecnologa apropiados para formar a los usuarios eficientemente.
Para la realizacin de esta Actividad se utilizarn como entrada los Procedimientos de
Usuario, elaborados en DPU 2 ("Elaborar Procedimientos de Usuario"), el Plan de
desarrollo de los Procedimientos de Usuario, definido en la Actividad DPU 1
("Completar el Plan de Desarrollo de Procedimientos de Usuario"), y los perfiles de
usuario, determinados en la Tarea DPU 3.1 ("Identificacin de Perfiles de Usuario").
MAP Metodologa METRICA Versi6n 2
1
;.
DPU4:DESARROLLAR PLAN DE
DPU1:COMPLETAR EL PLAN
FORMACION USUARIOS
DE DESARROLLO DE LOS
PROCEDIMIENTOS DE USUARIO
4.1 Identificacin de Requisitos
y Recursos necesarios para
Formacin de Usuarios
DPU2: ELABORAR LOS
1
4.2 Preparacin de los Materiales
de Formacin de Usuarios
DPU3:DETERMINAR NECESIDADES
ESPECIALES FUNCIONAMIENTO
DEL SISTEMA
(PERFILES DE USUARIOl
FASE 3: CONSTRUCCION DE SISTEMAS - MODULO DPU 241
TAREA DPU 4.1: IDENTIFICACION DE REQUISITOS Y RECURSOS NECESARIOS
PARA LA FORMACION DE USUARIOS.
DESCRIPCION y 08IETIVOS.
Identificar los requisitos para formar a los usuarios en el uso del nuevo sistema.
Determinar los recursos, internos y externos necesarios para formar a los
usuarios. Los recursos incluirn instructores, equipos audiovisuales y cualquier
otro recurso relacionado.
Para la realizacin de esta Tarea, se han de seguir los pasos que se indican a
continuacin:
1. Revisar los requisitos de personal para el nuevo sistema identificados en la Tarea
DPU 3.1 ("Identificacin de Perfiles de Usuarios") y los procedimientos
elaborados en la Tarea DPU 2.2 ("Elaboracin de Procedimientos de Usuario"),
para determinar el grado y tipo de conocimientos necesarios para el funciona-
miento ptimo del nuevo sistema.
2. Establecer qu tipo de formacin se precisar para cada usuario, en funcin de
lo especificado en el paso 1.
3. Preparar un borrador de las sesiones de formacin. Este borrador debe incluir:
Introduccin. Se har una breve exposicin de los objetivos del curso o
sesin de formacin.
Indice de los temas a tratar.
Visin general de los procesos y funciones del nuevo sistema.
Descripcin de las ventajas y beneficios aportados por el nuevo sistema.
Descripcin detallada paso a paso de cada actividad del sistema, que
debern explicarse en el orden en que se realizarn por los usuarios.
Ayudas disponibles en el sistema.
Ejercicios y/o sesiones prcticas.
Conclusiones.
Preguntas y respuestas de los participantes al curso.
4. Determinar las personas que deben ser formadas en el uso del nuevo sistema. En
esa lista se incluir tambin el personal nuevo (si se ha previsto incorporar ms
personal).
5. Revisar las necesidades de formacin (detalladas en el paso 2) e identificar los
recursos necesarios para llevarla a cabo. Los recursos incluirn:
Recursos tcnicos: equipo lgico y fsico.
Recursos humanos: personal de la Unidad especializado en formacin,
personal externo.
Instalaciones apropiadas para impartir la formacin.
6. Determinar los costes que supondr la formacin (incluyendo costes de los
recursos).
7. Iniciar los procesos necesarios para que los Departamentos encargados adquieran
los recursos precisos.
PRODUcrOS A OBTENER.
Plan de formacin en el nuevo sistema, incluyendo:
Recursos necesarios.
Costes previstos.
lista de personal.
Necesidades de formacin especficas por perfiles identificados.
Esquema general de los cursos.
TAREA DPU 4.2: PREPARACION DE LOS MATERIALES DE FORMACION DE
USUARIOS
243
Preparar los materiales de formacin, con un formato y nivel de detalle que los
hagan tiles y eficaces, para adiestrar a los usuarios en el funcionamiento del
nuevo sistema.
La realizacin de esta Tarea se llevar a cabo en los siguientes pasos:
1. Elegir el formato apropiado de los materiales de formacin y las tcnicas
a emplear. Se repasar el primer borrador (elaborado en la Tarea DPU
4.1 "Identificacin de requisitos y recursos necesarios para la formacin de
usuarios"), haciendo las debidas correcciones. Se elegirn las tcnicas ms
indicadas y los medios. Entre estos ltimos se podrn incluir:
Presentaciones audiovisuales.
Manuales, tutoriales y libros de ejercicios.
Material de auto-estudio.
2. Preparar los Materiales de Formacin. Escribir la primera versin de todo
el material de formacin y presentacin del sistema. Comprobar, una vez
escritos, que:
Siguen una secuencia lgica.
Pueden impartirse en los tiempos determinados.
Son consistentes con los Procedimientos de Usuario.
3. Solicitar la revisin del plan y materiales de formacin, por el responsable.
4. Iniciar las tareas de reproduccin y montaje del material de formacin.
5. Aunque este paso no es obligado, puede ser de inters organizar una
sesin de formacin simulada entre los miembros del equipo de trabajo
para comprobar que la formacin planificada est ajustada en tiempos, el
material elaborado es til, etc. Al final de esta sesin simulada, se pedir
a los participantes que hagan crticas y recomendaciones que puedan
mejorar la calidad de la formacin prevista.
PRODUCfOS A OBTENER.
Material de formacin para los usuarios.
ACfIVIDAD DPU S: CONSOLIDAR PROCEDIMIENTOS DE USUARIO
DESCRIPCION.
En esta Actividad se rene toda la documentacin elaborada durante la ejecucin de
este Mdulo y se le da un formato apropiado para que puedan iniciarse las pruebas de
aceptacin y de sistema (Implantacin y Aceptacin del Sistema).
Para la realizacin de esta Actividad, deber disponerse de todos los documentos
elaborados durante el Mdulo:
El Plan de Construccin de los Procedimientos de Usuario.
Los Procedimientos de Usuario.
Definicin de los perfiles de usuario requeridos.
La Especificacin de Recursos necesarios.
El Plan de Formacin de Usuarios.
Adems, a la hora de consolidar los Procedimientos de Usuario, es preciso, tener en
consideracin una serie de aspectos para que la documentacin generada sea fcil de
usar:
Los usuarios, su nmero, el uso que hagan d.e los Procedimientos (consultas
puntuales, formacin), la frecuencia de uso, etc.
El formato del documento:
Formato de pgina.
Diagramas, pantallas.
Indice del contenido.
La preparacin del documento, su autorizacin, distribucin y archivo.
TAREA DPU 5.1: ORGANIZACION DE LA DOCUMENTACION DE PROCEDI-
MIENTOS DE USUARIO
245
Recopilar toda la documentacin relacionada con construccin de los
Procedimientos de Usuario y del Plan de Formacin de Usuarios.
La recopilacin de documentacin es un proceso continuo a lo largo de todo el
Mdulo DPU "Desarrollo de Procedimientos de Usuario". Una vez que el Mdulo
haya terminado, el material recogido se consolidar en un formato final, ms fcil
de mantener.
Para realizar esta tarea se llevarn a cabo los siguientes pasos:
1. Revisar toda la documentacin recogida, y comprobar que se dispone de
la ltima versin entregada y aceptada (puede haber versiones en borrador
que no se necesitarn).
2. Organizar la documentacin en un orden lgico para cada actividad.
Disear un ndice para la documentacin recopilada.
3. Poner en prctica los estndares de administracin de documentacin que
se definieron en la Tarea DPU 1.2 ("Especificacin de Criterios de
Calidad y Estndares de Procedimientos de Usuario"). Estos estndares,
que pueden ser ampliados si es necesario, deben incluir:
Procedimientos de control de versin.
Procedimientos de seguridad y confidencialidad.
Procedimientos de archivo, y de circulacin de documentos.
4. Asignar responsabilidades en el mantenimiento de la documentacin. Las
responsabilidades de mantenimiento incluirn, adems de la actualizacin
de los procedimientos, la distribucin de las actualizaciones.
PRODUcroS A OBTENER
Documentacin recopilada sobre procedimientos de usuario yPlan de Formacin.
TAREA DPU 5.2: CONSOLIDACION DE LA DOCUMENTACION DE
Consolidar y dar por terminados los Procedimientos de Usuario, antes de que se
inicien los procesos de mantenimiento de esta documentacin.
Para realizar esta tarea se seguirn los pasos que se indican a continuacin:
1. Revisar la documentacin referente a los Procedimientos de Usuario que
se recopil en la Tarea DPU 5.1 ("Organizacin. de la documentacin de
procedimientos de usuario").
2. Distribuir los Procedimientos de Usuario, a las personas y en las fechas
previstas.
3. Enviar la documentacin al responsable de las pruebas, para que pueda
servir de soporte a su ejecucin.
PRODUCTOS A OBTENER
247
Documentacin de Procedimientos de Usuario consolidada y revisada, que se
llamar, de acuerdo al Plan General de Garanta de Calidad aplicable al
desarrollo de equipos lgicos, Documento de Referencia de Usuarios, DRU.
MAP - METRICA Versin 2
FASE 4: IMPLANTACION DE SISTEMAS
ESTRUCTURA DE LA FASE
251
La Implantacin de Sistemas es la ltima Fase de la Metodologa METRICA versin 2
y su objetivo principal es el de conseguir la aceptacin final del sistema por parte de los
usuarios del mismo, as como llevar a cabo todas las actividades necesarias para su
puesta en
Esta Fase est formada por el mdulo:
Pruebas, Implantacin y Aceptacin del Sistema (PIA).
INTERRELACION CON EL PLAN DE SISTEMAS DE INfORMACION
Si el sistema est incluido dentro de un Plan de Sistemas de la Unidad, se partir, para
la realizacin de esta fase, de un conjunto de documentacin en la que se incluyen las
directrices tcnicas y de gestin de la Unidad, as como un conjunto de previsiones sobre
la Implantacin del Sistema.
Los resultados de la realizacin de la Fase de Implantacin de Sistemas, influirn en el
de Sistemas de Informacin") de la Metodologa METRICA Versin 2.
Los Organos participantes en la Fase de Anlisis de Informacin, sern:
Comit de Direccin.
comunes de la Administracin (ProgramacinyPresupuestos, Recursos Humanos,
etc.).
MAP metodologa METRICA Versin 2
252 FASE 4: IMPLANTACION DE SISTEMAS
Formado por personal de Sistemas de Informacin y personal tcnico cualificado
de la Unidad.
Grupo de Usuarios.
Formado por distintos usuarios con conocimiento profundo 'de las funciones a
realizar por el Sistema a desarrollar. Adems participarn expertos de los
Servicios comunes (Programacin y Presupuestos, Recursos Humanos, etc.) de la
Administracin.
Eventualmente se requerir la participacin de especialistas en tecnologas de la
informacin (comunicaciones, equipo fsico y lgico) para la realizacin de
determinadas actividades dentro de la Fase.
Grupo de Calidad.
definida y validar el cumplimiento de las funciones y requisitos del Sistema, as
como participar activamente en la realizacin de las pruebas de aceptacin.
La constitucin de estos comits y grupos depender de las caractersticas de tamao y
complejidad del proyecto a desarrollar, as en el caso de un sistema sencillo que afecte
a una Unidad concrta, puede ocurrir que, por ejemplo, el Comit de Direccin sea
PLAN
DE SISTEMAS
DE INFORMACION
PRUEBAS
IMPLANTACION
y ACEPTACION DEL SISTEMA
LEYENDA DaClIWICO
DACTMDADOTAREA
r?'7'I PRODUCTO

.
FASE 4: IMPlANTACION DE SISTEMAS MODULO PIA
FASE 4: IMPLANTACION DEL SISTEMA
INDICE
257
PIA: PRUEBAS, IMPLANTACION y ACEPTACION DEL SISTEMA 259
PIA 1:
PIA2:
PIA 3:
PIA4:
DISEAR Y REALIZAR LAS PRUEBAS
DEL SISTEMA 263
1.1. Preparacin de las pruebas del sistema
1.2. Creacin del entorno de pruebas del sistema
1.3. Realizacin de las pruebas del sistema
AcruALIZAR EL PLAN DE IMPLANTACION 270
2.1. Revisin del plan de implantacin
2.2. Preparacin del plan de trabajo de implantacin
REALIZAR LAS PRUEBAS DE ACEPTACION 274
3.1. Preparacin de las pruebas de aceptacin
3.2. Preparacin del entorno de produccin
3.3. Realizacin de las pruebas de aceptacin
ESTABLECER PROCEDIMIENTOS DE
PRODUCCIQN 281
4.1. Instalacin de procedimientos automticos
de produccin
4.2. Instalacin de procedimientos manuales
de produccin
4.3. Inicio de procedimientos de produccin
FASE 4: IMPLANTACION DE SISTEMAS - MODULO PIA
MODULO PIA: PRUEBAS, IMPLANTACION y ACEPTACION DEL SISTEMA
DESCRIPCION y OD.IETJYOS GENERALES.
259
Este mdulo tiene como objetivo principal el comprobar el sistema en su totalidad,
haciendo nfasis en los siguientes aspectos:
Verificar que funcionalmente cumple con todos los requisitos que se detallaron
en el mdulo ARS ("Anlisis de Requisitos del Sistema").
Comprobar que el sistema es capaz de manipular los volmenes de informacin
requeridos, de trabajar dentro de los tiempos de respuesta deseados y que funcio-
nan correctamente los procedimientos de copias de respaldo, seguridad e
interfases con otros sistemas. El comportamiento del sistema debe examinarse
bajo las condiciones ms extremas.
Para ello se tomarn como punto de partida los componentes del sistema, probados de
forma unitaria e integrada (Pruebas Unitarias y de Integracin) en la Fase anterior
(Construccin de Sistemas).
Las pruebas a realizar van a separarse en dos grandes bloques, Pruebas del sistema y
pruebas de aceptacin. Ambas van a ser similares en cuanto a lo que se va a probar, sin
embargo, el entorno tcnico donde tendrn lugar es distinto:
Las Pruebas de Sistema cubren un rango muy amplio, que va desde la comproba-
cin de cualquier detalle de diseo interno hasta aspectos tales como las
comunicaciones.
Las Pruebas de Aceptacin se realizan por y para los usuarios y tienen como
objetivo conseguir una demostracin formal de que el sistema cumple todos los
requisitos de usuario.
Realizadas las pruebas, y aceptado formalmente el sistema por los usuarios, ser objetivo
ltimo de este Mdulo realizar todas las tareas necesarias para la puesta en explotacin
del nuevo sistema, incluyendo:
Conversin o carga de nuevos datos.
Instalacin de procedimientos manuales y automticos.
Inicio de Procedimientos de Produccin.
260 FASE 4: IMPlANTACION DE SISTEMAS MODULO PIA
Existen una serie de principios que se debern tener en cuenta en el proceso de
explotacin:
Considerar la actividad de explotacin como si fuese un proceso de fabricacin.
Asegurar que un cambio de personal no afecta a la operativa diaria.
Evitar conflictos con los usuarios relacionados con la utilizacin de documentos
para emitir.o recibir informacin, peticiones o comunicados.
La estrategia de implantacin qued definida en el Mdulo DTS ("Diseo Tcnico del
Sistema"), pero generalmente sern necesarias una revisin y modificacin ulterior.
Existen diversas estrategias de implantacin que pueden segirse. La eleccin de las
mismas depende de mltiples factores, pero se destacan fundamentalmente stos:
El tipo de sistemas que puedan solaparse con el sistema a implantar.
El grado de descomposicin que permita una implantacin en fases, durante un
perodo de tiempo.
A veces es necesario realizar la transicin del sistema antiguo al nuevo de forma
instantnea, sin embargo, siempre que los horarios y los recursos lo permitan, el
funcionamiento en paralelo de ambos sistemas puede utilizarse para minimizar el riesgo.
En este ltimo caso, uno de los dos sistemas se considerar el "Maestro":
Si se elige el sistema existente como el sistema maestro, la operacin en paralelo
del nuevo sistema podra ser considerado como una sustitucin a las Pruebas de
Aceptacin.
Si se elige como sistema maestro al nuevo sistema, el sistema existente
proporciona una seguridad adicional ante un posible error del nuevo.
MODULO DE PRUEBAS,IMPLANTACION VACEPTACION DEL SISTEMA (PIA)
Ykoplal
Si.la...
ACCIONES DE CONTROL
\7::1VI1a' ,.llAladDs

DE CALIDAD
Plutbas dII Sistoma
"'"_do A<optoci6n
ACCIONES DE GESTION
\7::'viS. r.dtados
Pruebas dol Sistoma
DE PROYECTO
r
REPARAR
PlA- .1 SEGUIMIENTOYCONTROL r ACORDAR 1 _I COMPARAR CON I
DOCUMENTO
NES DETALlADOS RESULTADOS REQUISITOS FORMAL DE
DEL MODULO I 1 DE PRUEBAS I -1 INICIALES I -I ACEPTACION
ACTIVIDADES
I I
FIN
1BAS SISTEMA , -, ACEPTAClON I
t.1 Plaparad6n Plutbas 3_\ Plop.ad6n Pruebas
doISi._a do Acoplacln
WlW
uer.ad6nan_
3.2 Plaparad6n Entorno
do Plutbes doI Sisl....
d! Produccin
\.3 Roailad6ndo las 3.3 Roailad6n PruobaJ
Plutbes doI Sistema do Acoplacln
lEYENDA DEl GMFlCO
J 2. ACTUALIZAR 1 ABUECER . I
'V REVlSION INFORMAL
1
lPROCEDIMIENTOS I
(no ....orIalnna)
DE PRODUCCION
REVlSION FORMAL
L- 2.\ R_doIPlando '.lln.taIad6n PlocedmIo"".1UID-
(....... Inna)
lrnpIan_ malals do P0ucU:d6n
1- 2.2 Plop.ad6n dol Plan do '.2 Instalad6n Ploctdimio"".

m....a1.. do PIOduod6n
Ulnido PlocodimianlDs
doPlodll:d6n
262 FASE 4: IMPLANTACIONDESISTEMAS MODULO PIA
PRUEBAS,IMPLANTACION
ACTIVIDADES
Y ACEPTACION
DEL SISTEMA
1 2 3 4
COMITE DE DIRECCION
I F
DIRECTOR PROYECTO
I
F
GRUPO DE CALIDAD
R
E,F
GRUPO DE USUARIOS E,F
DEPARTAMENTO DE TI
E
R
E
E
-- - -- ----_. ----- -----
E R
E
E
EQUIPO DE PROYECTO
Jefe de Proyecto
E,R
E
E E
-- - -- ----- ----- - ----
Componentes Equipo
E
CLAVES:
A: Asistencia Tcnica
D: Dotar Recursos
E: Ejecuci6n
F: Revisi6n formal
R: Revisi6n informal
1: Suministra informaci6n
ACTIVIDADES:
1. Dise"ar y Realizar Pruebas
del Sistema
2. Actualizar el Plan de implantaci6n
3. Realizar Pruebas de Aceptacin
4. Establecer Procedimientos de Producci6n
MAP - Metodologa MBTRICA Versin 2
FASE 4: IMPlANTACION DE SISTEMAS - MODULO PIA
ACTMDAD PIA 1: DISEAR Y REALIZAR LAS PRUEBAS DEL SISTEMA
DESCRIPCION
263
En esta actividad se preparan las especificaciones de las pruebas y del sistema, las cuales
debern contemplar los _siguientes aspectos:
Comunicaciones, para determinar el correcto funcionamiento de las interfases
entre componentes (incluyendo enlaces entre dispositivos remotos).
Rendimiento en la ejecucin. Se medir el tiempo de respuesta del sistema bajo
diferentes condiciones.
Volumen. Se comprobar el sistema actuando sobre grandes volmenes de datos.
Tanto en este aspecto, como en el anterior se har especial nfasis en las
transacciones consideradas crticas y que han sido identificadas en las fases de
Anlisis y Diseo del Sistema.
Recuperacin de datos. Se probar que el sistema puede recuperar datos, cuando
haya fallos del equipo fsico o lgico.
Operaciones. Se comprobar el funcionamiento adecuado de los procedimientos
de arranque y finalizacin del sistema.
Seguridad. Se verificar que los mecanismos de seguridad definidos son
suficientes.
Integracin con productos de aplicacin existentes o que hayan sido adquiridos
en la Unidad.
Adems, se prepararn en esta actividad todos los procedimientos y facilidades necesa-
rios para la realizacin de las pruebas del sistema.
Por ltimo se realizarn las pruebas, segn-las especificaciones diseadas previamente,
y se documentarn los resultados de las mismas en un "Informe de Pruebas del Sistema".
Como resultado de la realizacin de estas pruebas se emprendern las acciones
correctivas necesarias para solucionar los problemas e incidencias ocurridos durante la
ejecucin de las pruebas.

.
J
ji;'

I
.,)
PIA1: DISEAR YREALIZAR LAS PRUEBAS DEL SISTEMA
CORRECCIONES
1.1 PREPARACION DE 1.3 REALlZACION DE
LAS PRUEBAS
LAS PRUEBAS
DEL SISTEMA
DEL SISTEMA
RESULTADOS
1.2 CREACION
DEL ENTORNO
DE PRUEBAS
/Ij

ltl

g
I
.
I

TAREA PIA 1.1: PREPARACION DE LAS PRUEBAS DEL SISTEMA
26S
Revisar y completar los planes de prueba del sistema, que se definieron en la
tarea DTS 4.1 ("Diseo de Planes de prueba del sistema") y que estn contenidos
en la documentacin final del mdulo DTS ("Diseo Tcnico del Sistema").
Adems se definirn pruebas adicionales, basadas en los Procedimientos de Usuario. Las
especificaciones de prueba debern incluir:
Un Plan de Pruebas del Sistema.
En este plan de pruebas se recogen los objetivos de las pruebas del sistema, entre
los que se encuentran:
Comprobar que el sistema se ajusta a las especificaciones funcionales del
mismo.
Comprobar el funcionamiento correcto del sistema, en lo que respecta a:
Captura de informacin.
Validacin y edicin.
Tratamiento de errores.
Actualizacin de la informacin.
Obtencin de informes.
Conversin de la informacin.
Interfases entre programas (condiciones que afectan a la lgica de
la interrelacin entre los programas del sistema).
Interfases externas.
Cuadres.
Procedimientos de copias de respaldo y de recuperacin.
Comprobar la adecuacin de los procedimientos de usuario al
funcionamiento del sistema.
Comprobar la respuesta del sistema.
266 FASE 4: IMPLANTACION DE SISTEMAS - MODULO PIA
Verificar que el sistema responde con precisin en situaciones de altos
volmenes de informacin y dentro de unos lmites ajustados de tiempo
de respuesta.
Adems, en el plan de pruebas se incluirn los miembros del equipo de pruebas
y las responsabilidades de las mismas.
Las especificaciones de los casos de prueba, los cuales han de contemplar datos
actuales y datos especialmente generados para satisfacer alguna de las pruebas.
Procedimientos detallados para la ejecucin de cada prueba.
Planes de prueba del sistema, estas pruebas estn contenidas en el documento
PPRB, Plan de Pruebas del equipo lgico del proyecto, definido en el Plan
General de Garanta de Calidad aplicable al desarrollo de equipos lgicos.
TAREA PIA 1.2: CREACION DEL ENTORNO DE PRUEBAS DEL SISTEMA
Disponer de todas las facilidades ylos procedimientos necesarios para realizar las
pruebas del sistema. El entorno de pruebas debe incluir:
Bases de datos o ficheros de prueba (incluyendo los parmetros
necesarios).
Procedimientos manuales y automticos para efectuar copias de respaldo
y recuperaciones de las bases de datos o ficheros de prueba.
FASE 4: IMPlANTACION DE SISTEMAS - MODULO PIA U,7
Procedimientos manuales y automticos necesarios para la ejecucin de las
pruebas.
Procedimientos de control de versin del equipo lgico y de los datos de
prueba.
Terminales, claves de acceso y cualquier facilidad fsica necesaria.
Probar que el entorno de pruebas est preparado para soportar las pruebas del
sistema. No son pruebas excesivamente formales, pero s es de inters realizarlas
para evitar los retrasos que podran ocurrir si hubiera fallos en el entorno de
pruebas.
Los pasos a seguir para la ejecucin de esta Tarea son:
1.- Refinar los procedimientos de control de versin del equipo lgico.
2.- Crear las bases de datos o ficheros de prueba definidos en la Actividad Des 1
("Preparar el Entorno de Desarrollo, Pruebas y Procedimientos de Operacin").
3.- Instalar, en su caso, las libreras que precisen las pruebas del sistema.
4.- Crear los procedimientos de gestin de pruebas.
5.- Probar todas las facilidades necesarias para la ejecucin de las pruebas
(terminales, comunicaciones etc).
6.- Verificar los procedimientos de prueba:
Iniciar sesiones de prueba.
Recibir o producir copias de los resultados.
Mantener las libreras de programas de prueba.
7.- Probar las bases de datos o ficheros que se utilizarn, y los procedimientos de
respaldo, recuperacin y acceso.
PRODUCTOS A OBTENER
Entorno de pruebas del sistema.
268
TAREA PIA 1.3: REALIZACION DE LAS PRUEBAS DEL SISTEMA
Realizar las pruebas del sistema, para asegurar que todos sus componentes se
comportan de la forma requerida.
Evaluar los resultados obtenidos en las pruebas del sistema, y determinar las
modificaciones necesarias.
Documentar los resultados de las pruebas y mantener un histrico.
Para realizar estas pruebas es preciso que se hayan realizado las pruebas de integracin.
La ejecucin de las pruebas del sistema se realizar siguiendo los pasos que se indican
a continuacin:
1.- Instalar los "componentes" necesarios para las pruebas.
2.- Preparar la base de datos o ficheros de prueba, inicializar los valores necesarios
para la ejecucin de las pruebas y crear las tablas y ficheros auxiliares que sean
precisos.
3.- Cargar los datos necesarios para las pruebas, y recopilar los datos manuales
(proporcionados por los usuarios) que deben ser probados.
4.- Ejecutar cada una de las p r u e ~ siguiendo los procedimientos que se definieron
en la Tarea PIA 1.1 ("Preparacin de las pruebas del sistema").
S.- Documentar todas las incidencias ocurridas durante la ejecucin de las pruebas.
Se deber incluir para cada prueba efectuada:
Datos de entrada.
Fecha, hora de ejecucin de la prueba y personal implicado.
Incidencias detectadas.
FASE 4: IMPLANTACION DE SISTEMAS MODULO PIA 269
Pasos llevados a cabo, cundo ocurrieron las incidencias e intentos de
reproducirlas.
Posibles causas de la incidencia (si se sospecha cules pueden ser).
6.- Evaluar los resultados de las pruebas y resolver los problemas derivados:
Revisar los informes de cada prueba y comparar los resultados obtenidos
con los resultados esperados, para determinar todas las discrepancias.
Determinar el origen de cada problema. La solucin de estos problemas
depende en gran medida del Mdulo de la Metodologa donde se
introdujo el error (ver la siguiente tabla).
Funcionalidad no se ajusta a los requisitos de los usuarios ARS
Producto adquirido que no funciona como se especific
Especificacin Incorrecta de la Solucin
Fallo en el diseo (especialmente en las interfases de
usuario)
Error de codificacin
Procedimientos de usuario errneos o incompletos
Pruebas mal especificadas o ejecutadas incorrectamente
EFS
D1'5
Des
DPU
EFS-D1'5-DCS-
PIA
7.- Determinar las acciones que deben llevarse a cabo para resolver los problemas
detectados. Las soluciones debern enfocarse hacia el Mdulo donde se
introdujo el error y se realizarn las Actividades correspondientes.
8.- Tras realizar las oportunas acciones correctivas, se actuiUizar toda la
documentacin (siguiendo los formatos definidos por la Metodologa).
9.- Determinar el conjunto de pruebas del sistema que deben volver a realizarse,
ejecutarlas y comprobar el impacto de los cambios efectuados.
10.- Verificar y validar el conjunto de pruebas del sistema por parte del Grupo de
Calidad.
MAP MetodolOga METRlCA Versin 2
11.- Completar el Informe de las Pruebas del Sistema:
Determinar si las pruebas pueden considerarse completas.
Notificar los problemas no resueltos.
Elaborar un informe final.
PRODUCTOS A OBTENER
Informe de pruebas del sistema.
Aplicacin resultante, una vez realizadas las pruebas del sistema. Este
producto se llama, de acuerdo al Plan General de Garanta de Calidad
aplicable al desarrollo de equipos lgicos, APL, Aplicacin (equipo lgico
ejecutable).
TECNICA
Tcnicas de prueba.
ACI'MDAD PIA 2: ACI'UALIZAR EL PLAN DE IMPLANTACION
DESCRIPCION.
En esta actividad se revisar el Plan de Implantacin del sistema, elaborado durante el
mdulo de Diseo Tcnico del Sistema, y se introducirn los cambios ocasionados como
consecuencia de la realizacin de las actividades de los mdulos posteriores, as como
el resultado de la realizacin de las Pruebas del Sistema.
En general, la implantacin de un sistema puede considerarse como el conjunto de
actividades necesarias para:
Aadir, modificar o crear los datos necesarios para el funcionamiento del nuevo
sistema.
Instalar todos los componentes del nuevo sistema.
FASE 4: IMPLANTACION DE SISTEMAS MODULO PIA 271
Instalar el conjunto de procedimientos manuales y automticos requeridos para
el nuevo sistema.
Por eso, dentro del Plan de Implantacin se han de considerar los aspectos siguientes:
Planificacin de la conversin de datos (si la hubiera).
Planificacin de los procedimientos de instalacin.
Planificacin de la instalacin de productos estndar adquiridos externamente.
Plan de contingencias.
Planes de trabajo y horarios.
Acciones de revisin, que se llevarn a cabo una vez realizada la implantacin.
Para una adecuada planificacin de los trabajos a realizar, ser necesario tener en cuenta
una serie de factores condicionantes que siempre suelen estar presentes en mayor o
menor medida.
El nmero de sistemas.
Tipo de sistemas/programas (por lotes, interactivos, gestin, tcnicas).
El nmero de usuarios.
Tiempos disponibles de ordenador.
Horas de mayor/menor nmero de usuarios conectados al sistema.
Horas de mayor/menor actividad del sistema.
La depuracin del Plan de Implantacin pasa por determinar aquellos procesos o
cadenas que se deben ejecutar en fechas fijas, anualmente, semestralmente,
trimestralmente, mensualmente y semanalmente.
Una vez establecidos los procesos de ejecucin fija, se proceder a planificar las
necesidades de procesos de ejecucin diaria, tanto interactivos como por lotes. Sin
perder de vista que se deben prever tiempos para la realizacin de actividades de
qtantenimiento del sistema, copias de seguridad, ejecucin de procesos de peticin
espordica, relanzamiento de cadenas que se ejecutaron errneamente, etc.
Por ltimo, se deber establecer un horario de ejecucin de los procesos, para lo que es
conveniente tener en cuenta:
Procesos que son incompatibles en el tiempo.
Procesos que es necesario ejecutar antes que otros (dependencias entre procesos).
Horas y das de mayor carga de actividad de los distintos departamen-
tos/aplicaciones.
La planificacin de fechas en el Plan de Implantacin es especialmente difcil , puesto
que a veces dependen de eventos externos, como la instalacin de productos adquiridos
a terceros. Sin embargo se pueden dar algunas recomendaciones que pueden facilitar esa
planificacin:
Procurar instalar y poner en marcha el sistema por partes.
No abandonar procedimientos antiguos ni perder los datos originales hasta que
se haya conseguido una implantacin con resultados satisfactorios.
No permitir, en la medida de lo posible, que presiones externas obliguen a
resolver problemas puntuales o a corto plazo, obstaculizando el proceso de
Implantacin.
Si el sistema est incluido dentro de un Plan de Sistemas, sern de utilidad en esta
actividad las previsiones de implantacin efectuadas en el mismo.
TAREA PIA 2.1: REVISION DEL PLAN DE IMPLANTACION
Asegurar que todos los cambios habidos desde el anlisis de requisitos hasta la
implantacin se han identificado y el nuevo Plan refleja los ltimos requisitos y
modificaciones, de manera que se pueda realizar adecuadamente la planificacin
de la carga de trabajo de un centro de explotacin, ya "que esta carga ser un
factor determinante en el nivel de rendimiento del sistema y en el grado de
aprovechamiento de sus recursos.
Los pasos a realizar en esta Tarea son los siguientes:
273
1.- Recopilar la documentacin referente al Plan de Implantacin que se elabor en
el Mdulo DTS ("Diseo Tcnico del Sistema").
2.- Investigar el estado actual del Sistema y de la ejecucin de las pruebas de Sistema
y de Aceptacin.
3.- Investigar todos aquellos aspectos que puedan afectar a las fechas iniciales
previstas:
Cambios por gestin, por ejemplo todos los relacionados con la legislacin
(fechas obligadas).
Cambios ocasionados por el estado de proyectos paralelos que tengan
interfase con el nuevo sistema.
Cambios de fechas de entrega de productos adquiridos a terceros.
4.- Preparar un borrador con la estrategia actualizada de implantacin, una vez
analizada toda la informacin recogida en los pasos anteriores.
Por ltimo es importante considerar la posibilidad de instalar el sistema por fases.
Aunque la estrategia general de implantacin determine cmo va a ser efectuada (en
paralelo con el sistema antiguo, en sustitucin del sistema antiguo, etc) se debe intentar
implantar pequeos paquetes del nuevo equipo lgico y de datos en fechas sucesivas.
Plan de Implantacin del Sistema.
TAREA PIA 2.2: PREPARACION DEL PLAN DE TRABAJO DE IMPLANTACION
274 FASE 4: IMPLANTACION DE SISTEMAS MODULO PIA
Preparar los planes detallados de trabajo para la ejecucin de la implantacin del
nuevo sistema, tal como se definieron y se presupuestaron por el equipo del
proyecto.
Asegurar que todas las personas involucradas:
Usuarios.
Direccin.
Suministradores de productos externos.
conocen su responsabilidad y las fechas de participacin, entrega o los recursos
que tienen que asignar.
Plan de trabajo de implantacin.
ACfMDAD PIA 3: REALIZAR LAS PRUEBAS DE ACEPTACION
DESCRIPCION.
En esta Actividad se llevarn a cabo las Pruebas de Aceptacin, con el fin de conseguir
que los usuarios aprueben el nuevo sistema.
Las pruebas de aceptacin tienen como finalidad demostrar a los usuarios que el nuevo
sistema desarrollado satisface todos sus requisitos, que fueron determinados y
especificados en los Mdulos ARS ("Anlisis de Requisitos del Sistema") y EFS
("Especificacin Funcional del Sistema"). Es pues decisivo que tanto la planificacin de
las pruebas, como los procedimientos necesarios y los casos de prueba se definan para
obtener la Aceptacin del Sistema.
En primer lugar, es preciso completar y revisar la Especificacin de las Pruebas de
Aceptacin, realizada en el Mdulo EFS. Esta especificacin, una vez revisada, deber
constar de:
FASE 4: IMPLANTACION DE SISTEMAS - MODULO PIA
Especificacin detallada de las pruebas de Aceptacin, incluyendo:
Z75
Planificacin de cada una de las pruebas.
Especificacin de los casos de prueba.
Procedimientos detallados para la ejecucin de cada una de las pruebas.
Datos que van a usarse en los casos de prueba.
Los casos de prueba que se especifican en esta actividad han de permitir valorar
los siguientes aspectos del sistema:
Verificacin de las salidas del sistema.
Calidad y exactitud de los datos convertidos para su uso por el nuevo
sistema.
Medida del cumplimiento de los requisitos y funciones especficas.
Adecuacin de los procediinientos de usuario e instrucciones de operacin
del sistema.
Comportamiento adecuado del sistema en situaciones de sobrecarga.
Eficiencia en el tratamiento realizado por el sistema.
El nuevo sistema puede haberse desarrollado en un entorno distinto de aqul en el cual
finalmente se implantar. Las pruebas de aceptacin deben llevarse a cabo en el entorno
real de produccin, por lo que ser tambin objetivo de esta Actividad comprobar que
este entorno est instalado y verificado. El entorno de produccin incluye los equipos
fsicos, equipo lgico del sistema y de aplicacin y los procedimientos de operacin.
Por ltimo, si el sistema est incluido en un Plan de Sistemas de la Unidad sern de
utilidad en algunas tareas de esta actividad los estndares tcnicos y de gestin definidos
en dicho plan.
ES
RESULTADOS
PIA3: REALIZAR LAS PRUEBAS DE ACEPTACION
3.2 PREPARACION
DEL ENTORNO
DE PRODUCCION
CORRECCION
3.1 PREPARACION DE 3.3 REAlIZACION DE
LAS PRUEBAS LAS PRUEBAS
DE ACEPTACION DE ACEPTACION

.
1

<
i
N
TAREA PIA 3.1: PREPARACION DE LAS PRUEBAS DE ACEPTACION
Revisar y corregir las especificaciones de las Pruebas de Aceptacin, definidas en
el Mdulo EFS ("Especificacin Funcional del Sistema").
Preparar los datos necesarios para desarrollar los casos de pruebas de aceptacin.
La preparacin de las pruebas de aceptacin seguir los pasos que se indican a
continuacin:
1.- Revisar el Plan de Aceptacin y hacer los cambios oportunos.
2.- Revisar los casos de prueba especificados y crear algn caso adicional que se
considere importante. A veces, podrn utilizarse muchos de los casos de prueba
que se utilizaron en la ejecucin de las Pruebas de Sistema.
3.- Recopilar datos reales que vayan a usarse y generar nuevos datos.
Es conveniente tener en cuenta las siguientes consideraciones:
La diferencia principal entre las Pruebas de Sistema y las de Aceptacin es que
estas ltimas son realizadas por los usuarios. Las pruebas de aceptacin determi-
nan si efectivamente el sistema cumple los requisitos definidos por dichos
usuarios.
Las pruebas de aceptacin deben realizarse tanto para los sistemas de conversin
de datos como para los sistemas de produccin.
La responsabilidad de esta tarea ser exclusiva de los usuarios y del Grupo de
Calidad.
Pruebas de aceptacin, estas pruebas estn contenidas, de acuerdo al Plan
General de Garanta de Calidad aplicable al desarrollo de equipos lgicos, en el
documento PPRB, ~ n de Pruebas del equipo lgico del proyecto.
MAP - Metodologa METRICA Vrsin 2
278 FASE 4: IMPlANTACION DE SISTEMAS - MODULO PIA
TAREA PIA 3.2: PREPARACION DEL ENTORNO DE PRODUCCION
Asegurar que todas las facilidades tcnicas y los recursos humanos precisos para
la realizacin de las pruebas de aceptacin y el paso subsiguiente a produccin,
estn disponibles.
El entorno tcnico incluye:
Ordenador: Equipo fsico y lgico adicional.
Los procedimientos de produccin.
El componente humano est formado:
Por los usuarios participantes en la ejecucin de las pruebas.
Por los operadores, personal de Tecnologa de la Informacin y personal del
equipo de proyecto.
Esta tarea puede desglosarse en los siguientes pasos:
1.- Comprobar la instalacin de los equipos fsicos y lgicos necesarios. Se
comprobar tambin la disponibilidad de los consumibles que vayan a necesitarse
en la ejecucin de las pruebas (papel de impresora, cintas para copias de
respaldo, etc).
2.- Revisar los procedimientos de produccin (y probarlos si es necesario). Estos
procedimientos han de contemplar" entre otros, los siguientes aspectos:
Convenciones estndar para nombrar ficheros.
Procedimientos de clculo y de reserva de espacios de almacenamiento
primario y secundario.
Copias de respaldo suficientes.
Recuperacin y reiniciacin de trabajos.
Planificacin de trabajos.
Instrucciones de encaminamiento para salidas impresas.
FASE 4: IMPlANTACION DE SISTEMAS MODULO PIA
3.- Crear las bases de datos o ficheros para produccin y configurar las libreras que
vayan a utilizarse (deben probarse).
4.- Comprobar que todos los usuarios participantes en las pruebas han recibido la
formacin precisa para una correcta ejecucin de las pruebas.
PRODUcroS A OBTENER
Entorno de produccin.
TAREA PIA 3.3: REALIZACION DE LAS PRUEBAS DE ACEPTACION
Realizar las pruebas de aceptacin por parte de Operacin y del Grupo de
Calidad con la participacin de los usuarios cuya aprobacin sea necesaria para
la aceptacin formal del sistema.
Evaluar los resultados obtenidos en las pruebas de aceptacin y llevar a cabo las
acciones correctivas necesarias.
Obtener la aceptacin formal del sistema, que certifique que el sistema satisface
todas las especificaciones de los usuarios.
Los pasos a seguir para el desarrollo de esta tarea son los siguientes:
1.- Instalar el equipo lgico del sistema a probar, as como los datos necesarios en
el entorno de produccin.
2.- Realizar todos los procedimientos definidos para la ejecucin de las pruebas de
aceptacin. Se documentarn todas las incidencias producidas, indicando:
Datos de entrada.
Fecha, hora de ejecucin de la prueba y personal implicado.
Incidencias detectadas.
280 FASE 4: IMPlANTACION DE SISTEMAS - MODULO PlA
Pasos llevados a cabo cuando ocurri la incidencia e intentos de repetirla.
Posibles causas de la incidencia (si se sospecha cules pueden ser).
3.- Completar un informe de la ejecucin de las pruebas.
4.- Evaluar los resultados de las pruebas y resolver los problemas derivados:
Revisar los informes de cada prueba y comparar los resultados obtenidos
con los resultados esperados y buscar todas las discrepancias.
Determinar el origen de cada problema, su solucin depender en gran
medida del Mdulo de la Metodologa dnde se cometi el error (ver
tabla de la Tarea PIA 1.3 "Realizacin de las Pruebas del Sistema").
Iniciar las acciones correctivas. Se deber actualizar toda la documentacin
que haya podido ser afectada por las correcciones.
Hacer nuevas pruebas si se determina la necesidad de las mismas.
5.- Completar un Informe para cada una de las pruebas realizadas teniendo en
cuenta:
La evaluacin de cada componente del sistema, segn las pruebas hechas.
Las desviaciones detectadas sobre los requisitos.
Problemas sin resolver.
Cuando todas las pruebas se consideren realizadas se elaborar un informe final
con un Sumario de las Pruebas realizadas y una Lista de los problemas sin
resolver.
6.- Conseguir la aceptacin del sistema. Se obtendr la firma de. aprobacin de todos
los componentes del nuevo sistema (incluido el nuevo equipo fsico instalado).
Informe de Pruebas de aceptacin, este informe se llamar, de acuerdo al Plan
General.de Garanta de Calidad aplicable al desarrollo de equipos lgicos, IPAA,
Informe de las Pruebas de Aceptacin de la Aplicacin. '
Lista de problemas sin resolver.
ACTMDAD PIA 4: ESTABLECER PROCEDIMIENTOS DE PRODUCCION
DESCRIPCION.
281
Esta actividad tiene como objetivo la instalacin de todos los procedimientos manuales
y automticos precisos para el funcionamiento en produccin del nuevo sistema y
comenzar la explotacin del sistema.
Para conseguir esto, es necesario que se disponga del entorno de producci6n,
perfectamente instalado y probado (esto se realiza en la Tarea PIA 3.2 "Preparacin del
Entorno de Produccin"), y que el sistema haya sido formalmente aceptado por los
usuarios (como resultado final de la Actividad PIA 3 "Realizar las Pruebas de
Aceptacin"), aunque a veces puedan realizarse paralelamente ambas Actividades.
En la ejecucin de esta Actividad, adems del equipo de proyecto, participar el
personal usuario del sistema, por tanto la responsabilidad de la realizacin correcta y en
los tiempos previstos, no estar en manos nicamente del Jefe de Proyecto, sino que el
Comit de Direccin compartir esa responsabilidad.
Es importante concienciar a las distintas Unidades o Servicios de que ellos son los
propietarios de la informacin, siendo por tanto su obligacin participar en el desarrollo
de esta Actividad.
TAREA PIA 4.1: INSTALACION DE PROCEDIMIENTOS AUTOMATICOS DE
PRODUCCION
Instalar todas las facilidades automticas de Produccin, que incluyen:
Los procedimientos automatizados y su correspondiente documentacin.
El entorno de produccin: equipo fsico, equipo lgico de aplicacin,
consumibles.
282 FASE 4: IMPlANTACION DE SISTEMAS - MODULO PIA
El personal formado y la organizacin y control necesarios.
Eliminar aquellos procedimientos actuales (bien sean manuales o automticos)
que sean redundantes con los nuevos procedimientos.
Los pasos a realizar para la ejecucin de esta Tarea son los siguientes:
1.- Recopilar los procedimientos automticos de produccin, junto con su
documentacin. Los procedimientos se habrn elaborado en el caso de sistemas
desarrollados a medida, o debern por los proveedores de
productos.
2.- Preparar el entorno fsico y organizativo para produccin, incluyendo personal
formado, procedimientos automticos ( que se habrn probado y aceptado en la
Actividad PIA 3 "Realizar las Pruebas de Aceptacin"), equipos, productos
tcnicos, instalaciones y consumibles.
3.- Instalar fsicamente los procedimientos automatizados, incluyendo los
procedimientos de acceso de usuarios y de seguridad.
4.- Asegurar que todos los procedimientos se han instalado, no nicamente el sistema
principal, sino tambin los procedimientos de:
Respaldo, y restauracin de datos.
Contingencias y recuperacin de errores.
Actividades que se realizan entre perodos de tiempo largos (por ejemplo,
procesos anuales).
Es preciso tener en cuenta las siguientes consideraciones:
Muchos de los procesos del nuevo sistema tendrn inevitablemente una ntima
asociacin entre procedimientos manuales y automatizados, por lo que las Tareas
PIA 4.1 ("Instalacin de procedimientos automticos de produccin") y PIA 4.2
("Instalacin de procedimientos manuales de produccin") se realizarn
coordinadamente.
Durante la realizacin de esta Tarea, se deber tener permanentemente
informado sobre tiempos planificados de realizacin a todo el personal
involucrado.
Los equipos lgicos y fsico requeridos, deben haberse probado en un entorno de
explotacin. La "instalacin" de equipos en esta tarea se refiere en este caso a
cambiar los equipos de un estado de pruebas a otro de explotacin.
PRODUCfOS A OBTENER.
Procedimientos automticos de produccin.
283
TAREA PIA 4.2: INSTALACION DE PROCEDIMIENTOS MANUALES DE
PRODUCCION
Establecer los procedimientos, documentacin, recursos, organizacin y controles
para todos aquellos procesos que vayan a realizarse de forma manual en el nuevo
sistema.
Eliminar aquellos procedimientos actuales que sean redundantes con los nuevos
procedimientos.
Los pasos a seguir para la ejecucin de esta Tarea son:
1.- Recopilar los procedimientos manuales de produccin, junto con su documenta-
cin. Los procedimientos se habrn elaborado en el caso de sistemas
desarrollados a medida, o debern suministrarse por los proveedores de productos
que se hubieran adquirido.
2.- Preparar el entorno fsico y organizativo para produccin, incluyendo personal
formado, procedimientos manuales que se habrn probado y aceptado en la
Actividad PIA3 ("Realizar Pruebas de Aceptacin"), equipos, productos tcnicos,
instalaciones y consumibles, necesarios para poder poner en explotacin los
nuevos procedimientos manuales.
3.- Instalar fsicamente los procedimientos manuales, incluyendo la documentacin
de dichos
4.- Asegurar que todos los procedimientos manuales se han instalado.
Por ltimo, se ha de tener en cuenta que muchos de los procesos del nuevo sistema
tendrn inevitablemente una ntima asociacin entre procedimientos manuales y
automatizados, por lo que las Tareas PIA 4.1 ("Instalacin de procedimientos
automticos de produccin") y PIA 4.2 ("Instalacin de procedimientos manuales de
produccin") se realizarn coordinadamente.
PRODucroS A OBTENER.
Procedimientos manuales de produccin.
TAREA PIA 4.3: INICIO DE PROCEDIMIENTOS DE PRODUCCION
Iniciar la fase de uso y produccin del nuevo sistema y eliminar todos los
componentes del antiguo sistema que ya no vayan a utilizarse (en el caso en que
existiese un sistema anterior). En muchos casos, el nuevo sistema implantado pasa
a ser el sistema ''vivo o maestro", y sus salidas son utilizadas por los usuarios.
Obtener la firma de los usuarios responsables dando por implantado el nuevo sistema.
Los pasos a realizar son los siguientes:
1.- Recopilar los nuevos procedimientos y datos de produccin y asignar fechas de
implantacin para cada funcin del nuevo sistema.
2.- Determinar las fechas de finalizacin de las funciones del sistema antiguo que no
deban continuar.
3.- Arrancar los nuevos procedimientos, una vez obtenida la autorizacin para ese
arranque.
4.- Obtener las autorizaciones de acceso al nuevo sistema para los usuarios. Esto ha
de hacerse mediante una comunicacin formal del responsable de usuarios al
responsable de sistemas.
5.- Revisar los resultados de los nuevos procedimientos e iniciar acciones de
contingencia cuando se considere necesario.
FASE 4: IMPlANTACION DE SISTEMAS - MODULO PIA 28S
6.- Obtener la firma final, que asegure que el personal usuario y la direccin
consideran correctamente implantado el nuevo sistema.
7.- Eliminar el sistema anterior (si lo hubiese).
8.- Revisar el sistema ya en produccin para asegurar que los usuarios utilizan el
nuevo sistema, y que el equipo de trabajo puede transferir la responsabilidad del
sistema a los usuarios.
GESTION DE PROVEeros
GESTION DE PROYECTOS
INDICE
289
7.1. ADAPTACION DE LA METODOLOGIA METRICA VERSION 2:
EL CONCEPTO DE MAPA DE ACflVIDAD. . 291
7.2. DESCRIPCION DETALLADA DE CADA UNO DE LOS MAPAS...... 295
7.2.1. Mapa de Actividades "PG" Proyecto Grande
7.2.2. Mapa de Actividades "PP" Proyecto Pequeo
7.2.3. Mapa de Actividades "MS" Mantenimiento de Sistemas
7.2.4. Mapa de Actividades "BP" Basada en Paquete
7.2.5. Mapa de Actividades "PT" Prototipado
7.2.6. Mapa de Actividades "0M" Desarrollo Modular
GESTION DE PROYECTOS 291
7.1. ADAPTACION DE LA METODOLOGIA METRICA VERSION 2: EL
CONCEPTO DE MAPA DE ACTIVIDAD
El Plan General de Garanta de Calidad aplicable al desarrollo de equipos lgicos
del MAP establece una serie de caractersticas que definen un proyecto
informtico, estas caractersticas, junto con las mtricas asignadas a cada una de
ellas, permiten establecer diferentes tipologas de proyectos, para las cuales habr
que definir diferentes modelos de ciclo de viCIa. Estos modelos son:
Modelo secuencial (o "en cascada") bsico.
Modelo secuencial intermedio.
Modelo secuencial detallado.
Modelo de desarrollo por evolucin de prototipos.
Modelo de desarrollo modular.
Teniendo pres.entes estos criterios, se han establecido, en esta Gua de Gestin
de Proyectos, diferentes adaptaciones para la Metodologa METRICA Versin
2, con el objetivo, por un lado, de contemplar los modelos de ciclo de vida
especificados en el Plan General de Calidad, y por otro lado, contemplar el
problema del mantenimiento de los sistemas existentes.
Las adaptaciones que se han establecido, y que en adelante se llamarn Mapas
de Actividades, son las siguientes:
PG Proyecto Grande
Cubre el desarrollo de un sistema a medida, cuyo tamao es grande o bien tiene
un alto grado de complejidad.
PP Proyecto Pequeo
Cubre el desarrollo de un sistema a medida, donde el tamao y/o complejidad
es limitado.
DM Desarrollo Modular
Cubre el desarrollo de un sistema a medida, que se puede estructurar en distintos
mdulos relativamente independientes.
PT Prototipado
Cubre el desarrollo de un sistema a medida, donde no existe una especificacin
funcional muy detallada y se puede utilizar un entorno tecnolgico avanzado que
permita construir un sistema preliminar que se pueda probar.
292 GESTION DE PROYECTOS
MS Mantenimiento de Sistemas
Cubre la entrega de un proyecto basado en la modificacin de un sistema
existente.
BP Basada en Paquete
Cubre la entrega de sistemas mixtos en los que una parte estar basada en un
paquete estndar y puede ser necesario algn tipo de desarrollo para
parametrizar o mejorar su integracin con otros sistemas.
Se puede establecer la siguiente correspondencia entre los modelos definidos en
el Plan General de Calidad aplicable al desarrollo de equipos lgicos y los Mapas
de actividades identificados en esta Gua:
PP - Modelo secuencial bsico o Modelo secuencial intermedio.
PG - Modelo secuencial detallado.
DM - Modelo de desarrollo modular
PT - Modelo de desarrollo por evolucin de prototipos. En este ltimo caso nos
referimos a los prototipos evolutivos (clase 3) (Mapa de Activndades P1)
La obtencin del Mapa de Actividades influye principalmente en la seleccin de
actividades y tareas requeridas para un proyecto en particular.
En algunos casos las caractersticas del proyecto estn relacionadas con ms de
un Mapa de Actividades Modelo. En estos casos se podrn combinar y formar el
Mapa de Actividades especfico del proyecto.
La adopcin de un Mapa de Actividades no es irreversible en un proyecto. Esta
puede ser revisada peridicamente (por ejemplo, al final de una fase) y ser
cambiada si fuese necesario. Se muestran unas tablas en las que se definen el
grado de obligatoriedad (O, C o blanco) y de impacto (+, -) para todas las
actividades definidas en la metodologa.
Las claves empleadas en dichas tablas son las siguientes:
O:
C:
Blanco:
Actividad obligatoria.
Actividad condicional:
+ Importancia alta
Importancia baja
Actividad no requerida.
GESTIONDEPROYECTOS
Para cada Mapa de Actividad se muestra lo siguiente:
Descripcin del Mapa y de las circunstancias bajo las que se utiliza.
Sus principales caractersticas.
293
Las principales consideraciones a tener en cuenta en relacin a su
utilizacin.
Un grfico que muestra el encaminamiento y utilizacin de las diferentes
actividades y los productos finales a obtener.
Comentarios sobre las excepciones existentes en relacin a las actividades
incluidas en la Metodologa.
Con respecto a los Mapas de actividades PT (Prototipado), DM (Desarrollo
Modular), y MS (Mantenimiento de Sistemas) es importante destacar que,
adems de determinadas actividades especficas de estos tipos de proyectos y que
se describen en detalle ms adelante, se utilizar para el desarrollo de los mismos
cualquiera de los Mapas de actividades PP (Proyecto Pequeo) o PG (Proyecto
Grande), por lo cual no se recogen en el cuadro siguiente una descripcin
pormenorizada de dichos Mapas.
Por ltimo, es preciso hacer nfasis en la idea de flexibilidad de la Metodologa
METRICA Versin 2. Se pueden definir diferentes Mapas de Actividades
dependiendo del tipo y caractersticas particulares de cada proyecto y de la
importancia que se le quiera dar a cada una de las actividades. La definicin de
los Mapas de Actividades es responsabilidad del Jefe de Proyecto, auxiliado por
el Grupo de Calidad.
Con el fin de facilitar el trabajo de elaboracin de Mapas de Actividades
especficos por proyecto, se incluye al final de esta Gua una plantilla que permita
elaborar el Mapa de Actividades especfico para cada proyecto a desarrollar.
ARS 1 Establecer el mbito y alcance del proyecto O O O
ARS2 Identificar y definir requisitos O O O
ARS3 Disear el modelo lgico actual O O- O
ARS4 Estudiar Alternativas de construccin O C 0+
294 GESTION DE PROYECfOS
EFS2 Construir el modelo de datos del nuevo sistema O O C
EFS3 Realizar el anlisis detallado del nuevo sistema O O O
EFS4 Definir interfases de usuario O O O
EFSS Completar especificaciones del sistema O O 0+
EFS6 Completar especificaciones de entrega O O C
D1'5 1 Disear la arquitectura fsica del sistema O O O
01'52 Disear la estructura fsica de datos del sistema O O C
01'53 Especificar el entorno tecnolgico del sistema O O
D1'54 Completar el plan de pruebas del sistema O O O
01'55 Completar especificaciones de diseo O O O
Des 1 Preparar Entorno de Desarrollo, Pruebas y O O- C
Procedimientos de Operacin
Des 2 Desarrollar y Probar Componentes del Sistema 0+ O C
DCS3 Realizar Pruebas de Integracin 0+ O C
DPU 1 Completar Plan de Desarrollo de Procedimientos de O O O
Usuario
DPU2 Elaborar Procedimientos de Usuario O O O
DPU3 Determinar Necesidad"es especiales para el O O O
funcionamiento del sistema
DPU4 Desarrollar Plan de Formacin de Usuarios O O O
OPUS Consolidar Procedimientos de Usuario O O O
PIA 1 Disear y realizar las Pruebas del Sistema O O O
PlA2 Actualizar el Plan de Implantacin O O O
PlA3 Realizar las Pruebas de Aceptacin O O O
PIA4 Establecer Procedimientos de Produccin O O O
7.2. DESCRIPCION DETALLADA DE CADA UNO DE LOS MAPAS
7.2.1. MAPA DE ACTMDADES "PG" (PROYECTO GRANDE)
DESCRIPCION
29S
El Mapa de Actividades "PG" cubre el desarrollo de un sistema a
medida cuyo tamao es grande o bien tiene un alto grado de
complejidad.
PRINCIPALES CARACTERISTlCAS DEL MAPA
Este Mapa trata todas las actividades como obligatorias.
Puede combinarse con algn otro Mapa. como el "MS"
(Mantenimiento de Sistemas), "PT' (Prototipado) en sus clases 1 y
2 Y"DM" (Desarrollo Modular").
CONSIDERACIONES
Este Mapa es particularmente adecuado cuando se presenta alguna
de las siguientes situaciones:
La duracin estimada del proyecto es mayor de 6

Existen funciones complejas.
Sistemas de conversiones de datos complejos o crticos.
Sistemas de alto rendimiento y/o alto volumen de
transacciones.
Existen interfases complejas con otros sistemas.
PG PROYECTOS GRANDES

I FASE DE IMPLANTACION
FASES DE
y DESARROLLO
DEL SISTEMA
(INICIO)

I I
,
1
I
ARS
I
EFS
1 I
1-6
1-4
FASE DE ANALlSIS DEL SISTEMA

1- - -
. PRUEBASY
,-- ACOPT_
I I
@
,
I
rl DTS
Des

,
1-5 1-3
,
PIA
L-
1-4
----
DPU
I
1-5
1-- -1
I
MAPA DE AcrMDADES "PG" (PROYEcrO GRANDE)
ARS: ANALISIS DE REQUISITOS DEL SISTEMA
297
Todas las actividades son obligatorias. El grado de detalle en la realizacin
de la actividad ARS 4 "Estudiar Alternativas de Construccin"
determinar, a su vez, la profundidad con que se realice la actividad EFS
1 ("Construir el modelo de procesos del nuevo sistema").
EFS: ESPECIFICACION FUNCIONAL DEL SISTEMA
Todas las actividades son obligatorias para este Mapa de Actividades.
DTS: DISEO TECNICO DEL SISTEMA
Todas las actividades son obligatorias para este Mapa, con una excepcin:
La Tarea DTS 1.3 "Descripcin de interfases con otros sistemas" se
realizar solamente cuando el sistema tenga relacin con otros productos
o aplicaciones desarrolladas.
DCS: DESARROLW DE COMPONENTES DEL SISTEMA
Todas las actividades son obligatorias para este Mapa. Se consideran dos
actividades de importancia alta.
DCS2
DCS3
"Desarrollar y Probar componentes del sistema"
"Realizar Pruebas de integracin"
DPU: DESARROLW DE PROCEDIMIENTOS DE USUARIO
Todas las actividades son obligatorias para este Mapa.
PIA: PRUEBAS, IMPLANTACION y ACEPTACION DEL SISTEMA
Todas las actividades son obligatorias para este Mapa.
7j.j.. MAPA DE ACTMDADES "PP" (PROYEcrO PEQUEO)
DESCRIPCION
El Mapa de Actividades "PP" cubre el desarrollo de un sistema a
medida cuyo tamao es limitado.
PRINCIPALES CARACTERISTICAS DEL MAPA
Los mdulos de "Anlisis de Requisitos del Sistema" (ARS) y de
"Especificacin Funcional del Sistema" (EFS) se unifican y
producen un nico documento.
Puede combinarse con algn otro Mapa, como el "MS"
(Mantenimiento de Sistemas), "FT' (Prototipado en sus clases 1 y
2) Y"DM" (Desarrollo Modular).
CONSIDERACIONES
Este Mapa es adecuado para el desarrollo de proyectos de bajo
riesgo. El propsito es permitir que se aborden proyectos de
tamao limitado sin emplear demasiado tiempo y recursos en
labores de documentacin y gestin del proyecto.
Este Mapa es particularmente recomendable cuando se desarrollan
sistemas conocidos por todos los componentes del proyecto y no se
utiliza ningn tipo de paquete.
Aunque el tamao del proyecto sea pequeo (menos de 6
meses/hombre), es desaconsejable utilizar este tipo de Mapa
cuando existan reas y aspectos del proyecto no decididos y
conocidos, ya sea desde un punto de vista tecnolgico o funcional.
En esos casos puede ser un riesgo truncar una serie de actividades
que simplifiquen el estudio de aspectos no decididos
completamente.

fUNCIO....
r - - DELSISIBIA
PROYECTOS PEQUEOS
I
FASES DE DISEFlo
y DESARROLLO
DE SISTEMAS
PP
(INICIO J
I
I

EFS ARS
1-6
I
I 4 lJ
1-3
1
BJ
........
TECIIOD _ TECIICA Itf1'EOIUQON
,--- 'CIl'"'''''' I-
DEL
...... I
I I
I I
I
DCS ll-
--- DTS
}-----
I
1-5
1-3
PIA
---
L
--
1-4
)
\
DPU
I
1-5
-.E" -1
-,
I
FASE DE IMPLANTACION
."
o
MAPA DE ACTIVIDADES "PP" (PROYECTO PEQUEO)
ARS: ANALISIS DE.REQUISITOS DEL SISTEMA
Al tratarse de un proyecto pequeo y de baja complejidad no ser
necesario profundizar excesivamente en el estudio del modelo actual.
Asimismo, la realizacin de la actividad ARS 4 ("Estudiar Alternativas de
Construccin") ser condicional, dependiendo de la posible existencia de
las mismas y de si merece la pena el esfuerzo habida cuenta de la escasa
entidad del proyecto, en este caso ser responsabilidad del Jefe de
Proyecto el tomar la decisin de acometer este estudio.Hay, en todo caso,
que destacar que la realizacin de estas actividades disminuir la carga de
trabajo a realizar con las actividades del mdulo EFS ("Especificacin
Funcional del Sistema").
Todas las actividades son obligatorias.
Todas las actividades son obligatorias. Hay que tener en cuenta que dadas
las caractersticas de un proyecto pequeo ser habitual que el entorno
tecnolgico en que se ste se desarrollar, ya est especificado, eliminando
la necesidad de realizar la actividad DTS 3 ("Especificar el entorno
tecnolgico"). La tarea DTS 1.3 ("Descripcin de interfases con otros
sistemas"), se realizar si existen dichas interfases.
DCS: DESARROLLO DE COMPONENTES DEL SISTEMA
Todas las actividades son obligatorias, aunque la dificultad de ejecucin
ser menor debido al alcance y complejidad limitada del proyecto. Todas
las tareas de la Actividad DCS 1 se consideran de importancia baja,
excepto la Tarea DCS 1.1 "Implantacin de la Base de Datos Fsica o
Ficheros de Datos".
DPU: DESARROLLO DE PROCEDIMIENTOS DE USUARIO
GESTlON DE PROYECTOS 301
7:1..3. MAPA DE ACI1VIDADES "MS" (MANTENIMIENTO DE SISTEMAS)
DESCRIPCION
El Mapa de actividades "MS" cubre el mantenimiento de
aplicaciones desarrolladas y en produccin.
Los tipos de mantenimiento soportados por este Mapa sern:
Mantenimiento correctivo: relacionado con los cambios
necesarios debidos a errores en el sistema.
Mantenimiento adaptativo: relacionado con los cambios
tecnolgicos y organizativos o funcionales de los Sistemas de
Informacin.
Mantenimiento perfectivo: relacionado con las
recomendaciones y nuevas posibilidades recibidas de los
usuarios.y que mejoran la funcionalidad ya existente.
Este Mapa, a diferencia de los dems, ofrece una gama que, de
manera individual o en combinacin con otros, permite organizar
y describir las actividades que pueden ocurrir despus de entregar
un proyecto informtico a produccin. Como el cambio es
inevitable, se deben desarrollar mecanismos para evaluar, controlar
y hacer modificaciones de una manera organizada.
PRINCIPALES CARAcrERISTICAS DEL MAPA
Este Mapa debe ser utilizado en combinacin con alguno de los
otros mapas presentados en esta Gua de Gestin de Proyectos,
dependiendo del alcance de la modificacin pedida.
Los objetivos de este Mapa son los siguientes:
Suministrar un mtodo de comunicacin entre Usuarios y las
Unidades de Tecnologa de la Informacin.
Identificar el estado de cada peticin de cambio.
Mantener una base de informacin de los cambios.
302 GESnON DE PROYEcrOS
CONSIDERACIONES
El proceso de implantacin de un cambio comienza cuando se
observa la necesidad del mismo. Las solicitudes de modificacin
suelen iniciarlas los usuarios. Una solicitud de cambio puede
entenderse como un requisito de cambio. Por tanto, se comenzar
este Mapa con el desarrollo del mdulo ARS, Anlisis de
Requisitos del Sistema.
La actividad A..'{S 4 ("Estudiar alternativas de construccin"), en el
caso de una peticin de cambio, deber establecer el tipo de accin
a tomar para la correccin o mejora del Sistema.
El impacto de la modificacin puede suponer una modificacin
sobre el Anlisis y/o Diseo, y tener un impacto de alcance sobre
otros sistemas, subsistemas, mdulos, datos, etc...
Por ello es necesario que los cambios (modificaciones) que se
propongan sean analizados antes de su ejecucin y autorizados por
representantes de todos los grupos de inters afectados. Una vez
autorizados es necesario coordinar las tareas de ejecucin.
Los mdulos y actividades a desarrollar dependern del tipo de
modificacin requerida y por ello en el presente Mapa se deja
abierta la posibilidad de seleccionar un mapa determinado o los
mdulos ms adecuados.
Los Mdulos, Actividades y Tareas relacionadas con el
mantenimiento son similares a las que se realizan durante el
desarrollo, aunque el mantenimiento de aplicaciones tiene una serie
de aspectos que le son propios. A continuacin se establece una
comparacin entre los mdulos y su forma de tratarlos en el
desarrollo y en el mantenimiento, resumida en tres puntos:
1. Las actividades de mantenimiento se realizan dentro del
contexto de un sistema existente. El personal de
mantenimiento debe realizar cambios considerando las
restricciones existentes tanto del diseo, como de la
estructura del cdigo.
2. Los esfuerzos de mantenimiento de aplicaciones se realizan
normalmente en un intervalo de tiempo ms corto que los
esfuerzos de desarrollo.
GESTION DE PROVEeros 303
3. En el trabajo de desarrollo se deben crear todos los datos
de prueba desde el comienzo.
El mantenimiento, en esto, puede beneficiarse de la
existencia de datos de prueba.
El principal reto para el personal de mantemnuento es crear
nuevos datos para probar adecuadamente los cambios que se han
realizado en el sistema, as como comprobar su impacto sobre el
resto del sistema.
Por ltimo ser necesaria en este Mapa la definicin de estndares
de gestin de cambios dentro de la Unidad.
MAP - Metodologa METRlCA Versi6n 2
MS MANTENIMIENTO DE SISTEMAS
~ J :--<..=...)
I
PG
I
PP I
I
ARS
BP
ARS
2 4
EFS
DTS
ANAUSIS DE REQUISITOS
Des
D D O ~
ACTMOAO ACTMOAO FINAl FINAl
OlIUQATORlA CXlHDlClONAl NO DOCUMENTADO DOCI.IlIENTADO
MAPA DE ACfIVIDADES "MS" (MANTENIMIENTO DE SISTEMAS)
ARS: ANALISIS DE"REQUISITOS DEL SISTEMA
Este mdulo ser bsico dentro de la Gestin de Cambios y del proceso
de Mantenimiento.
En este mdulo se recibirn las solicitudes de modificacin y se producir
su revisin.
Una vez estudiado su impacto se producir una de estas acciones:
Aceptacin.
Rechazo/Cancelacin.
Aplazamiento/Modificacin.
Despus de estimada la accin a tomar y planificados los recursos se
seleccionarn los mdulos o Mapas ms adecuados para llevar a cabo las
acciones planteadas.
A continuacin se detallarn las actividades a realizar. Este Mapa tiene
una serie de factores especficos, por ello tambin se detallarn las
responsabilidades y estndares a utilizar para su realizacin.
Las actividades ARS 1 "Establecer el Ambito y el Alcance del Proyecto"
y ARS 3 "Disear el Modelo Lgico Actual" no se realizarn, al suponerse
documentado en el Sistema en funcionamiento. La primera actividad a
realizar sera ARS 2 "Identificar y Definir Requisitos". En ella se
realizarn las siguientes tareas:
ARS 2.1. ("Planificacin y realizacin de entrevistas") se obtendrn
las peticiones de cambio, aunque el medio no ser mediante
Entrevistas, sino que sern originadas por los usuarios.
ARS 2.2. ("Identificacin de problemas y necesidades") slo se
obtendrn las peticiones de cambio, asignadas mediante solicitud
formal de los usuarios. Asimismo, se obtendr el Catlogo de
Requisitos a partir de dichas peticiones.
La realizacin de las tareas comprendidas dentro de la actividad ARS 4
("Estudiar Alternativas de Construccin"), se detalla a continuacin:
306 GESTION DE PROVEeros
ARS 4.1 ("Definicin de Alternativas") no se realizar, incluyndose
el estudio de Productos existentes y el Planteamiento de
Alternativas, en caso de ser necesario, en la tarea ARS 4.2
("Seleccin de una alternativa").
ARS 4.2 ("Seleccin de una Alternativa"), donde se analizar el
impacto del cambio, los beneficios esperados por el cambio y la
manera en que se puede desarrollar el cambio, estimando el
esfuerzo necesario para realizarlo.
Esta tarea ser llevada a cabo por el responsable de Tecnologa de
la Informacin. Adems se decidir la accin a tomar y se
asignarn prioridades y recursos concretos.
Por ltimo, se deber decidir el tipo de accin a tomar, seleccionando el
Mapa ms adecuado, Proyecto Grande (PG), en caso de que la
complejidad del cambio solicitado implique una modificacin sustancial en
el sistema, o bien Proyecto Pequeo (PP), en caso de modificaciones no
muy sustanciales.
7.2.4. MAPA DE ACfMDADES "BP" (BASADA EN PAQUETE)
DESCRIPCION
El Mapa "BP" cubre la entrega de sistemas en los que una parte
estar basada en un paquete estndar y puede ser necesario algn
tipo de desarrollo que permita parametrizarlo o mejore su
integracin con otros sistemas.
PRINCIPALES CARACTERISTICAS DEL MAPA
Se llevar a cabo una evaluacin completa de los paquetes de
aplicacin, existentes en el mercado. Esta evaluacin ser realizada
comparando las caractersticas y prestaciones del paquete con los
requisitos de usuario.
Este Mapa se podr realizar en combinacin con alguno de los
mapas ya definidos:
PG, Proyectos Grandes.
PP, Proyectos Pequeos.
MS, Mantenimiento de Sistemas.
CONSIDERACIONES
307
No es sencillo identificar un proyecto como adecuado para ser
desarrollado utilizando el mapa "BP" hasta que no sea completado
el mdulo de Anlisis de Requisitos del Sistema. En ese momento
los requisitos quedan claramente definidos y se habr obtenido la
aprobacin por parte de los responsables de los usuarios.
Cuando no es posible definir los requisitos inicialmente puede ser
una ayuda el emplear algn tipo de tcnicas de prototipos antes de
comenzar la utilizacin del Mapa "BP". En general, ser suficiente
realizar un prototipado rpido, del tipo "Clase 1" indicado en el
mapa PT.
Si para cumplir con las necesidades de los usuarios, el sistema
requiere una adaptacin significativa o es necesario desarrollar una
parte "a medida", puede ser interesante instalar el producto en su
estado bsico (no modificado) de manera que se puedan realizar
las pruebas adecuadas antes de aceptar el producto. El Mapa BP,
utilizado de manera aislada puede ayudar a seguir los pasos
necesarios para realizar este estudio.
Este Mapa es particularmente adecuado cuando los paquetes
encontrados cumplen solamente una parte de los requisitos y sea
desarrollar algunas de sus funciones, por una serie de
circunstancias:
Existen funciones complejas, o conversiones de datos
crticos.
Existen interfases con otros sistemas o con sistemas
desarrollndose en paralelo.
Existe una "parametrizacin" o "adaptacin" sustancial del
paquete.
Existe un nuevo entorno tecnolgico.
BP BASADA PAQUETE
\.lo)
o
00
"=TO
NO DOCUIENTADO DOCUIENTADO
DD
DE SISTEMAS
FASE DE DESARROLLO DE SISTEMAS
-
:-------i05J

[5J
INICIO)
_ _ FUNC1CNAI. TECNICll __
I DaSISTEMA DaSISTEMA 1
1 1
AR5
I
EF5 EF5
I DT5
[!]
DT5
-,
1 3-6
,
1 4-5 14
L
U
ESTUDIOS DE PAQUETES ESTANDAR
y DETERMINACION DEL ENTORNOTECNOLOGICO

: I I 1 1
FASE DE ANALISIS DEL SISTEMA FASE DE DISEO DEL SISTEMA 1

1
rcJ
p

[7J
Dt_1OS DI_IO-
INTEOIIAClON TECNICA 000 _ero

_ero
1lST_1DIl
1 1
SI8TElIAY
1 1

1 1
1
1
1
---- -
- ---- DPU
1
1 1
+1
"

1-5 1 _EllASY
1
ACVTACIDIl
1 1
I
-f---------I
1 I PIA
1
1 I
I
14
- - - - - - - - - - - __ 1
I 1
___1 I
IO,e: 1-----
D O D
GESTION DE PROYEcrOS
MAPA DE AcrMDADES "BP" (BASADO EN PAQUETE)
ARS: ANALISIS DE REQUISITOS DEL SISTEMA
Todas las Actividades son obligatorias.
309
La realizacin de la Actividad ARS 4 "Estudiar Alternativas de
Construccin", ser considerada de importancia alta, ya que a partir de
esta actividad se decidir acometer la evaluacin de paquetes estndar
existentes en el mercado.
Cuando los paquetes considerados requieran un determinado entorno
tecnolgico (equipo fsico, logical de sistema, etc.) se podr utilizar este
mdulo para evaluar dicho entorno.
La Especificacin Funcional del Sistema va a ser la primera definicin
formal de la solucin que va a ser estudiada y aprobada por los usuarios.
Todas las actividades son obligatorias. La realizacin de la actividad EFS
1"Construir el modelo de procesos del nuevo sistema" ser de importancia
alta, ya que permitir definir el uso adecuado de los parmetros del
producto y la seleccin de los mdulos, opciones y funciones apropiadas.
El proceso de anlisis supone el estudio del paquete y la definicin de
cmo utilizar las funciones disponibles para cumplir con los requisitos de
usuario.
Esto puede conseguirse, normalmente, accediendo a la documentacin
disponible. Sin embargo, se podr estudiar el producto en s mismo
(demostracin) en caso de ser necesario.
La mayora de las actividades son obligatorias en este Mapa. Conviene
hacer una aclaracin respecto a los trminos utilizados en la metodologa
para este Mapa concreto, as como el "encaje" de este mapa con otros
Mapas, dentro de un desarrollo completo:
"Anlisis" en muchos casos, se refiere a la seleccin de algunas de
las opciones del paquete.
Cuando alguna de las opciones no cumple, de una manera
adecuada, con las necesidades de los usuarios se debern
310 GESTION pE PROYEcrOS
especificar los procesos a desarrollar "a medida".
Para este tipo de desarrollo se seleccionarn los Mapas "PO".
Proyecto Grande, o "PPn, Proyecto Pequeo, dependiendo del
alcance de dichos procesos.
La Actividad EFS 2 "Construir el modelo de datos del nuevo
sistema" solamente ser adecuada si el diseador tiene control
sobre las estructuras de datos utilizadas en el paquete.
La Actividad EFS 5 "Completar Especificaciones de Entrega" es
considerada de importancia alta.
Dentro de la Actividad DTS 1"Disear la Arquitectura Fsica den Sistema"
se consideran de importancia alta las tareas:
DTS 1.1.: "Diseo de la Estructura modular del sistema"
DTS 1.2.: "Descripcin de interfases entre mdulos del sistema".
DTS 1.3.: "Descripcin de interfases con otros sistemas"
ya que durante su realizacin se definir cmo y dnde se necesitan los
parmetros para establecer las opciones requeridas.
La relacin de las tareas restantes:
DTS 1.4.: "Descripcin de interfases de usuario".
DTS 1.5.: "Definicin de componentes del sistema".
Ser opcional, ya que en la mayora de los casos solamente representa la
verificacin de las funciones disponibles en el paquete.
La Actividad DTS 2 "Disear la estructura fsica de datos del sistema" se
considera opcional, dependiendo de la extensin y del control sobre la
Base de Datos Fsica que el diseador tenga en el paquete.
El entorno tecnolgico del sistema, habr sido especificado
a la seleccin del paquete, por ello no ser necesaria la realizacin de la
actividad DTS 3 ("Especificar entorno tecnolgico del sistema").
Las dems actividades sern obligatorias.
DCS: DESARROLLO DE COMPONENTES DEL SISTEMA
311
Las actividades Des 1 "Preparar Entorno. de Desarrollo, Pruebas y
Procedimientos de operacin" yDes 2 "Desarrollar y Probar Componentes
del Sistema" sern opcionales. Slo sern necesarias cuando se deban
desarrollar y probar pequeas adaptaciones para la integracin con otros
sistemas o componentes.
La Actividad Des 3 "Realizar Pruebas de Integracin" es condicional.
Solamente los productos nuevos y muy complejos, o que necesiten una
adaptacin muy grande necesitarn las pruebas .de integracin.
DPU: DESARROLW DE PROCEDIMIENTOS DE USUARIO
Todas las actividades son obligatorias. Se debe intentar reducir costos y
tiempo utilizando la documentacin de usuario y material de formacin
del vendedor.
7.2.5. MAPA DE ACfIVIDADES "IT (PROTOTIPADO)
El prototipado es una aproximacin al desarrollo de sistemas de los que
no existe una especificacin funcional muy detallada, con el objetivo de
proporcionar al usuario un sistema preliminar, de forma que pueda
probarlo y familiarizarse con l en el tiempo ms breve posible, dicho
sistema preliminar puede evolucionar hasta convertirse en el sistema en
produccin.
Hay dos caractersticas que hacen que un sistema sea susceptible de ser
desarrollado utilizando esta aproximacin:
La dificultad que encuentran los usuarios en especificar claramente
sus requisitos.
La existencia de un entorno tecnolgico avanzado que proporcione
una serie de utilidades que faciliten la construccin rpida de
sistemas. Entre estas utilidades se pueden destacar:
312
GESTION DE PROYECfOS
Sistemas de gestin de bases de datos relacionales.
Diccionarios de datos.
Lenguajes de 4
11
Generacin (lAG)
Lenguajes de consulta para el usuario final.
Redactores de informes
Generadores de pantallas.
Herramientas CASE para Anlisis y Diseo.
Generadores de cdigo.
Aunque los prototipos se constituyen en las etapas iniciales del desarrollo
de sistemas, ser necesario un trabajo previo de modelizacin de datos y
funciones b ~ i c s por ello el prototipado ha de ser controlado como parte
de la Metodologa de Desarrollo de Sistemas.
Teniendo en cuenta esta premisa se considerarn en la Metodologa
METRICA Versin 2 tres clases de prototipos:
Clase 1: simulacin de dilogos de pantalla.
Clase 2: prototipado rpido.
Clase 3: prototipos evolutivos.
A continuacin se describirn brevemente cada uno de ellos.
CLASE 1: SIMULACION DE DIALOGOS DE PANTALLA
Se seguir el orden de actividades y tareas establecido en METRICA
Versin 2, haciendo nfasis en las siguientes singularidades:
Se utilizarn herramientas que permitirn:
Disear pantallas con facilidad.
Encadenar dichas pantallas, con el fin de simular la
navegacin entre las mismas.
Introducir datos de prueba en dichas pantallas, para dar al
usuario una idea aproximada de cmo puede ser el futuro
sistema.
GESTION DE PROYEcrOS 313
Se har especial nfasis en la realizacin conjunta con el usuario de
la actividad EFS 4 "Definir interfases de usuario", construyendo con
la ayuda de las herramientas reseadas en el punto anterior,
prototipos para funciones interactivas y los principales eventos y
consultas identificados mediante las tcnicas de modelizacin
utilizadas en la fase de Anlisis. DFD (Diagrama de Flujo de
Datos) y HVE (Historia de la Vida de la Entidad).
Las ventajas de esta aproximacin son las siguientes:
Permitir implicar al usuario ms activamente en el desarrollo del
sistema, proporcionndole una idea ms clara de las facilidades que
incorporar el sistema, as como de la futura apariencia del mismo.
Permitir refinar la especificacin de requisitos del sistema,
obtenida en el mdulo ARS ("Anlisis de Requisitos del Sistema").
Por otro lado es conveniente tambin apuntar como posible desventaja el
hecho de que se haga demasiado nfasis en el diseo de formatos de
pantalla que en el futuro no se vayan a utilizar, dado que an no se ha
decidido el entorno tecnolgico en que el sistema funcionar, el cual es un
resultado de la realizacin de la actividad DTS 3 ("Especificar el entorno
tecnolgico del sistema").
CLASE 2: PROTOTIPADO RAPIDO
Esta aproximacin se caracteriza por los siguientes hechos:
El entorno tecnolgico en que funcionar el sistema ya est
predefinido, y proporciona las utilidades que se han indicado en la
introduccin a este captulo. Esto evitar la realizacin de la
actividad DTS 3 ("Especificar el entorno tecnolgico del sistema").
El cdigo generado para las pantallas del sistema, as como el flujo
navegacional entre ellas y las definiciones y formatos de datos
utilizados en las mismas pantallas, productos obtenidos en la
actividad EFS 4 ("Definir interfases de usuario"), podrn ser
utilizables en los mdulos posteriores D1'5 ("Diseo Tcnico del
Sistema", y DCS (Desarrollo de Componentes del Sistema),
disminuyendo el esfuerzo en la realizacin de los mismos.
314 GESTION DE PROVEeros
Asimismo, la elaboracin del Manual de Usuario, producto del
Mdulo DPU ("Desarrollo de Procedimientos de Usuario"),
empezar una vez se hayan obtenido conjuntamente con el usuario,
prototipos en la actividad EFS 4 ("Definir interfases de usuario").
Tanto en este caso como el anterior, se puede ver que el ciclo de vida que
se sigue es el establecido por METRICA Versin 2 y se hace nfasis en
la realizacin de determinadas actividades de la Metodologa, dependiendo
bsicamente de las facilidades que proporcione el entorno tecnolgico. El
mbito de la aplicacin de ambas clases de prototipos, a todas las
funciones que dentro del sistema tienen un tratamiento interactivo o a una
parte representativa de las mismas, ser decisin del Jefe de Proyecto y
depender de factores tales como:
La complejidad de las funciones del sistema.
El grado de definicin de los requisitos por parte de los usuarios.
La disponibilidad de los usuarios a trabajar conjuntamente con el
equipo de proyecto.
La potencia del entorno tecnolgico de que se dispone.
Por ltimo, es importante destacar que se aplicarn tambin en estos dos
casos las consideraciones hechas para los ciclos de vida para proyecto
grande (PG) y proyecto pequeo (PP), segn el sistema de que se trate,
adems de los propios del prototipado.
CLASE 3: PROTOTIPOS EVOLUTIVOS
En este caso se realiza la construccin del sistema de una forma
incremental, es decir, en primer lugar se considera un subsistema o un
conjunto de funciones dentro del sistema en estudio y se construye un
prototipo, prototipo que ya funciona.
Este prototipo se va reflllando sucesivamente aadindole nuevas
funcionalidades.
Un posible modelo de adaptacin de este tipo de desarrollo, mediante
prototipos evolutivos, se representa en la figura.
GESTIN DE PROYECTOS 315
o
a..
~ I ~
a:
a..
o
a..
~
a:
a..
o
a..
1-
a:
a..
MAP . Metodologla METRICA Versin 2
316
ADAPTACION DELCICW DEVIDA DE PROTOTIPADO EVOLUTIVO
A LA METODOWGIA METRICA VERSION 2.
Como se representa en la figura anterior, la Metodologa METRICA
Versin 2 se usa como hilo conductor de los diferentes resultados
obtenidos mediante la utilizacin de prototipos.
A partir de una especificacin preliminar de los requisitos del sistema, se
desarrolla un prototipo siguiendo las fases de la Metodologa. Los
resultados de este prototipo ayudarn a refinar y completar los requisitos
del sistema. .
A continuacin se incorporarn nuevas funcionalidades al prototipo
construido. El nuevo prototipo resultante permite redefinir y completar la
especificacin funcional del sistema y completar los productos de la
misma, tal como vienen detallados en METRICA Versin 2.
Seguidamente, nuevos refinamientos del prototipo permitirn especificar
completamente la arquitectura global del sistema y el diseo final del
mismo.
Por ltimo, la finalizacin y aceptacin del prototipo, permite iniciar el
desarrollo del sistema definitivo, segn el proceso secuencial establecido
por METRICA Versin 2, y teniendo en cuenta que todos los productos
parciales obtenidos en el prototipo disminuirn drsticamente la carga de
trabajo en estos ltimos mdulos.
7.2.6. MAPA DE ACTIVIDADES "DM" (MODEW DE DESARROLLO
MODULAR)
DESCRIPCION
Este modelo es una variante de los modelos secuenciales estudiados,
adaptado a aplicaciones que se pueden descomponer en mdulos que se
pueden desarrollar con un alto grado de independencia.
CONSIDERACIONES
Este Mapa se combinar con los Mapas PP (Proyecto Pequeo) o
PG (Proyecto Grande), los cuales se utilizarn en el desarrollo de
cada uno de los mdulos o subsistemas identificados, dependiendo
de las caractersticas de; los mismos.
Con el fin de asegurar la coherencia de la informacin manejada
por el sistema global, es preciso desarrollar inicialmente el modelo
de datos global de todo el sistema. Este modelo se refinar
posteriormente con la elaboracin de las ''vistas'' que del modelo de
datos global tiene cada uno de los subsistemas, y que se obtendrn
en la actividad EFS 2 ("Construir el modelo de datos del nuevo
sistema") para cada uno de los subsistemas o mdulos.
MAPA DE ACfMDADES "DM" (DESARROLLO MODULAR)
Dadas las caractersticas de los proyectos para los que se aplica este Mapa
de Actividad, con un conjunto de especificaciones completamente
detalladas y definidas, se podr elaborar en la actividad ARS 3 ("Disear
el modelo lgico actual"), el modelo de datos global del sistema a
desarrollar. La elaboracin de este modelo es imprescindible, como se ha
dicho, para asegurar la consistencia de la informacin manejada por los
subsistemas.
Asmismo, se har especial nfasis en la realizacin de la actividad ARS
4 ("Estudiar Alternativas de Construccin"), ya que como resultado de esta
actividad se obtendr un Modelo lgico de procesos, donde se representa
la descomposicin del sistema en los diferentes subsistemas o mdulos que
se desarrollarn independientemente. Esto implica un alto grado de detalle
en la definicin de las interfases entre estos subsistemas.
El resto de los mdulos de la Metodologa se realizarn para cada uno de
los subsistemas identificados, siguiendo los mapas de actividades
especificados en PG (Proyecto Grande) o PP (Proyecto Pequeo),
dependiendo de las caractersticas de cada uno.
Se har un especial nfasis, en el desarrollo de cada uno de los
subsistemas o mdulos, en la realizacin de la Tarea DTS 1.3
("Descripcin de interfases con otros sistemas").
Por ltimo se proceder a la integracin de los diferentes subsistemas o
mdulos y se realizarn las pruebas de integracin, especificadas en la
Actividad DeS 3 ("Realizar pruebas de integracin").
La integracin de los diferentes mdulos exigir realizar en su totalidad
las actividades de la Fase 4 (Implantacin de Sistemas) para todo el
sistema, aunque se haya procedido a una implantacin por separado de
cada uno de los mdulos.
DM DESARROLLO MODULAR
........................................

(INICIO ')
AEaJSTQS llATOlI PlIOCESOS
DEL SISTEIM :t.w. fIm)IA DEL SSTEIlA r - lNTtAFASU

I EN1llE
I
IPROYECTO GRANDE 1--
I
I
I
ARS
I 1
I
1-4
.fPROYECTO PEQUEO _
I
I
MODULO ANALISIS
DE REQUISITOS
DEL SISTEMA
CICLO DE VIDA DE CADA UNO DE LOS MODULOS
IDENTIFICADOS, SEGUN SUS CARACTERISTICAS
8
I
1[5W
IlIIUEM8Y

________ ACEPTACICII
. I
1-4 _
-----------_ ..
D O
OD
PRUEBAS DE INTEGRACION ENTRE MODULOS
DEL SISTEMA
DEL SISTEMA GLOBAL
PllCXlUl:TO PllCllIUCIO
ACT1WIAD
--
'INAL
r-.
:"
ClalQA1llAIo\ CDDCIDIW. NOllOCUIEllTADO _ADO
:"
c..u
-
00
GESTION DE PROYEcrOS
APENDICE: PLANTILLA DE MAPA DE ACTIVIDADES
319
ARS 1
ARS2
ARS3
ARS4
Establecer el mbito y alcance del proyecto
Identificar y definir requisitos
Disear el modelo lgico actual
Estudiar Alternativas de construccin
EFS 1
EFS2
EFS3
EFS4
EFS 5
EFS6
Construir el modelo de procesos del u ~ o sistema
Construir el modelo de datos del nuevo sistema
Realizar el anlisis detallado del nuevo sistema
Definir interfases de usuario
Completar especificaciones del sistema
Completar especificaciones de entrega
DTS 1
DTS2
DTS3
DTS4
DTS5
Disear la arquitectura fsica del sistema
Disear la estructura fsica de datos del sistema
Especificar el entorno tecnolgico del sistema
Completar el plan de pruebas del sistema
Completar especificaciones de diseo
DCS 1
DCS2
DCS3
Preparar Entorno de Desarrollo, Pruebas y
Procedimientos de Operacin
Desarrollar y Probar Componentes del Sistema
Realizar Pruebas de Integracin
320 GESTIONDE PROYEcros
DPU 1 Completar Plan de Desarrollo de Procedimientos de
Usuario .
DPU 2 Elaborar Procedimientos de Usuario
DPU 3 Determinar Necesidades especiales para el
funcionamiento del sistema
DPU 4 Desarrollar Plan de Formacin de Usuarios
DPU 5 Consolidar Procedimientos de Usuario
PIA 1
PIA 2
PIA3
PIA4
Disear y realizar las Pruebas del Sistema
Actualizar el Plan de Implantacin
Realizar las Pruebas de Aceptacin
Establecer Procedimientos de Produccin
APENDICES
ANALISIS:
APUCACION
INFORMATICA:
erAVE AJENA:
CrAVE PRIMARIA:
CONTINGENCIA:
COSTE-BENEFICIO:
CONTROL DE
CALIDAD:
DIAGRAMA DE
CONTEXTO:
325
GLOSARIO DE TERMINOS
Conjunto de actividades que se realiza con objeto de
conocer en profundidad el funcionamiento del sistema en
estudio.
Equipo lgico (programas y datos utilizados y/o generados)
desarrollado con un fin especfico.
Atributo (simple o compuesto) que aparece en una entidad
y que es a su vez clave primaria en otra entidad.
Atributo (simple o compuesto) que identifica, de forma
unvoca, una entidad de datos.
Eventualidad o suceso posible que se presenta en el
funcionamiento del sistema, de modo no previsible.
Tcnica que se utiliza con objeto de evaluar la viabilidad de
un proyecto y permite valorar los costes estimados en el
desarrollo (Inversin, Recursos Humanos, etc.) y contrastar
dichos costes con los beneficios esperados (mejora de
Productividad, Atencin al Cliente, etc.).
Conjunto de actividades destinadas a comprobar que el
proyecto se ha desarrollado de acuerdo a la metodologa y
estndares establecidos, as como a garantizar que cumple
con los requisitos especificados.
Grfico que representa el sistema que se va a estudiar, as
como sus interfases con el exterior.
326 APENDlCES
DIAGRAMA DE FLUJO Diagrama que representa los flujos de informacin a travs
DE DATOS (DFD): del sistema, los procesos que los cambian o transforman
dichos flujos y los lugares donde se almacenan.
DIAGRAMA DE
ESTRUcruRA
DE DATOS (DED):
Diagrama que representa las entidades de datos del sistema
yla forma en que estas entidades se interrelacionan entre s.
DIAGRAMA DE Diagrama que representa la arquitectura del sistema que se
ESTRUcruRA DE est desarrollando y que se caracteriza por dividir dicho
CUADROS DE sistema en diferentes partes o mdulos que se comunican
CONSTANTINE (DEC): entre s mediante datos o mediante control.
ENTIDAD DE DATOS:
ENTIDAD EXTERNA:
ESPECIFICACION
DE PROCESOS
PRIMITIVOS:
EVENTO:
FLUJO DE DATOS:
Objetos identificables sobre los que el sistema guarda
informacin.
Objeto de un DFD que representa una fuente o destino de
la informacin que trata o produce el sistema y que, por
tanto, est fuera del mbito del mismo.
Descripcin de los procesos de un DFD en el ltimo nivel
de detalle, cuando no se pueden descomponer ms. En esta
descripcin se incluyen reglas de clculo y condiciones y
modos de acceso a los datos manejados por el proceso.
Suceso que activa los procesos de actualizacin de datos del
sistema.
Objeto de un DFD que representa el flujo de informacin
a o desde un proceso del DFD.
APENDICES
FORMAS NORMALES
(FN)
HISTORIA DE LA
VIDA DE IA
ENTIDAD:
MODELO DE DATOS:
3rT
El resultado de aplicar el proceso de normalizacin a las
estructuras de datos, con objeto de eliminar redundancias y
problemas en las operaciones de actualizacin de dichas
estructuras. En esta metodologa se recomienda llegar hasta
la tercera forma normal, segn el siguiente proceso:
1. Eliminar grupos repetitivos --- > 1 FN
2. 1 FN --- > Asegurar que los atributos dependen de
toda la clave --- > 2 FN
3. 2 FN --- > Eliminar dependencias transitivas -- > 3
FN
Tcnica que representa, para cada una de las entidades del
sistema, la actuacin especfica de todos los eventos
identificados sobre dicha entidad. Su objetivo es estudiar en
detalle la evolucin de las entidades de datos del sistema,
desde que son introducidas en el mismo, hasta que son
borradas.
Es la representacin de las necesidades de informacin de
la organizacin. Dentro. de la Metodologa METRICA
Versin 2, se utilizan distintos niveles de detalle en la
representacin de dichas necesidades:
Modelo conceptual de datos: en l se representan las
necesidades de informacin, sin tener en cuenta las
restricciones del equipo fsico y lgico del sistema
donde se implantar. Para ello se representan las
entidades (objetos sobre los cuales la organizacin
desea mantener informacin) y las relaciones entre
ellas.
Modelo lgico de datos: A partir del modelo de
datos y aplicndole una serie de refinamientos
sucesivos sobre las estructuras de datos se obtiene en
primera instancia un modelo lgico de datos.
328
MODELO ENTIDAD-
EVENTO:
APENDICES
A dicho modelo lgico de datos se le aplicarn las
tcnicas de normalizacin, hasta la tercera forma
normal, para obtener un conjunto de entidades
normalizadas.
Modelo fsico de datos: Est orientado a la forma en
que se almacenarn los datos en memoria.
Diagrama que representa la actuacin de los eventos
identificados sobre cada una de las entidades del sistema.
Esta actuacin de los eventos puede tener los siguientes
efectos sobre las entidades:
C: El evento introduce una entidad en el sistema.
M: El evento modifica alguno de los atributos de una
entidad de datos.
B: El evento borra la entidad de datos del sistema.
Para representar este modelo se utiliza la tcnica de la
Historia de la Vida de la Entidad (ver Gua de Tcnicas).
MODULO (de un DEC): Componente de un Diagrama de Estructura de Cuadros que
representa un programa o una serie de sentencias de
programa, con una funcin definida y un nombre que
expresa el propsito del mismo.
NIVEL DE
RESPONSABILIDAD: Dentro de Mtrica 2 se considera nivel de responsabilidad
como la funcin especfica que desempear cada uno de
los participantes en el proyecto. Dichos niveles se cambiarn
en funcin del mdulo de la Metodologa de que se trate.
Se considerarn los siguientes "niveles de responsabilidad":
Asistencia tcnica (A):
Consiste en las labores bsicas de soporte y ayuda en
la utilizacin e instalacin de equipo fsico y lgico.
APENDICES
OBJETIVO:
PROCEDIMIENTO:
PROCESO:
REQUISITOS:
329
Dotar recursos (D):
Provisin de los medios necesarios para el desarrollo
del producto (Recursos Humanos, Comunicaciones,
etc.)
Ejecucin (E):
Realizacin del trabajo.
Revisin informal (R):
Inspeccin y control de las tareas realizadas para
asegurar que se ajustan a las normas y estndares de
la instalacin, a la metodologa, etc.
Revisin formal (E):
Inspeccin de las tareas realizadas, con vistas a su
aceptacin formal, con la firma de los responsables.
Suministrar informacin (1):
Asesorar tcnicamente sobre diferentes aspectos del
desarrollo que impliquen la utilizacin de unos
estndares determinados y cuyo no cumplimiento
puede implicar na posteriori
n
la no aceptacin del
producto.
Finalidad muy definida y perseguida intencionadamente con
la realizacin del sistema.
Conjunto de tareas (manuales y automticas) que deben
realizar los usuarios para el uso correcto del nuevo sistema.
Objeto de un DFD que representa la transformacin de
flujos de datos de entrada en Flujos de Datos de Salida.
Caractersticas que ha de cumplir el sistema que se va a
desarrollar. El cumplimiento de dichos requisitos ser una
condicin bsica para la aceptacin final del sistema por
parte de los usuarios.
330
UNIDAD:
VAliDAR:
VERIFICAR:
APENDICES
Denominacin general de cualquiera de los Organismos,
departamentos, etc. constituyen una parte de la
estructura organizativa de la Administracin.
Garantizar que el sistema cumple los requisitos y objetivos
inicialmente especificados.
Asegurar la coherencia y de los modelos y tcnicas
utilizados.
APENDICES
ARS:
BP:
CASE:
DEC:
DCS:
DEO:
DFD:
DM:
DPU:
DTS:
EFS:
HVE:
MS:
PG:
333
ACRONIMOS UTILIZADOS EN LA GUIA DE REFERENCIA
Mdulo de Anlisis de Requisitos del Sistema.
Mapa de Actividades de proyectos "Basados en
"Computer-Aided Software Engineering". Ingeniera del Software asistida
por ordenador.
Diagrama de Estructura de Cuadros.
Mdulo de Desarrollo de Componentes del Sistema.
Mapa de Actividades de "Desarrollo Modular"
Mdulo de Desarrollo de Procedimientos de Usuario.
Mdulo de Diseo Tcnico del Sistema.
Mdulo de Especificacin Funcional del Sistema.
Historia de la Vida de las Entidades de Datos del Sistema.
Mapa de Actividades de "Mantenimiento de Sistemas".
Mapa de Actividades de "Proyectos Grandes"
334 APENDICES
PIA: Mdulo de Pruebas, Implantacin y Aceptacin del Sistema.
PP: Mapa de Actividades de "Proyectos Pequeos".
PT: Mapa de actividades de "Prototipado"
PSI: Fase de Plan de Sistemas de Informacin.
TI: Tecnologa de la Informacin.
BmUOGRAFIA RECOMENDADA
BIBLIOGRAFIA RECOMENDADA
S. Pollack, H.Hicks, and W. Harrison, Decision Tables - Theory and Practice
(New York, John Wiley & Sons, 1971)
MoA. J ackson, Principies o/ Program Design
(New York, Academic Press, 1975)
J.D. Wamier, The Logical Construction o/ Programs, 3rd ed.
(New York: Van Nostrand Reinhold, 1976)
E. Yourdon, Techniques o/ Program Structure and Design
(Englewood Cliffs, NJ.: Prentice-Ha11, 1975)
337
E. Yourdon and LL Constantine, Structured Design: Fundamentals 01 a Discipline 01
Computer Program and Systems Design, 2nd. ed.
(New York: Yourdon Press, 1978)
M. Page-Jones, The practical Guide to Structured Systems Design
v. Weinberg, Structured AnaIysis
T. DeMarco, Structured Analysis and Systems Specification
C. Gane and T. Sarson, Structured Systems AnaIysis: Tools and Techniques
B. Boehm, Software Engineering Economics
E. Yourdon, Modem Structured AnaIysis
I.T. HaWl)'szkiewycz, Introduction to Systems AnaIysis and Design
(Prentice-Hall o Australia, 1991)
P. Chen, Entity Relationship Approach to Systems AnaIysis and Design
(North Holland Publishing Co, 1980)
338 BmUOGRAFIA RECOMENDADA
J. Manin and C. c l u ~ Diagramming Techniques for AnaIysts and Programmers
(Englewood Cliffs, NJ.: Prentice-Hall, 1985)
J. Manin, Managing the Data Base Environment
J. Manin, Strategic Data-Planning Methodologies
CoJ. Date, An lntroduction to Database Systems, 4 ed.
(Addison Wesley Systems Prograrnming Series, 1986)
P. Ward and S. Mellor, Structured Development for Real-Time Systems
E. Yourdon, Managing the Systems Life Cycle
E. Yourdon, Managing the Structured Techniques
J. S. Hares, SSADM for the Advanced Practitioner
(Cbicbester: Jobn Wiley & Sons Ltd, 1990)
A. Collongues, J. Hugues and B. Laroche, MERlSE mthode de conception
(Paris: Dunod Informatique, 1987)
PROYECTOS PILOTO
10. PROYECOOS PILOTO
341
Como complemento a la realizacin de la Metodologa METRICA Versin 2 y
con el fin de comprobar su validez se llevaron a cabo dos proyectos piloto
utilizando la metodologa.
El primer proyecto piloto se desarroll en la Gerencia Informtica de la
Seguridad Social y se refiere al Sistema de Almacenamiento, Tratamiento y
Recuperacin de la Informacin (ATRIO) y el segundo fue realizado en el
Ministerio de Cultura y es relativo a la Gestin de Materiales de la Filmoteca
Espaola.
Los resultados de ambos proyectos fueron muy satisfactorios y estn a disposicin
de quien los solicite y pueden servir de experiencia previa a aquellos interesados
en la aplicacin prctica de METRlCA Versin 2.
Para obtener informacin adicional sobre los proyectos piloto basta ponerse en
contacto con el Servicio de Informacin Tecnolgica de la Subdireccin General
de Coordinacin Informtica del Ministerio para las Administraciones Pblicas.
EQUIPO RESPONSABLE DEL PROYECfO
11. EQUIPO RESPONSABLE DEL PROYECfO
Director del Proyecto:
D. Vctor Izquierdo Loyola
Subdirector General de Coordinacin Informtica
Jefe del Proyecto:
Da. MI Dolores Hemndez Maroto
Jefe de Area de Tecnologa
Grupo de Expertos:
D. Andrs Elhazaz Molina
Gerencia Informtica de la Seguridad Social
Da. Milagros Garda-Tenorio Damasceno
Ministerio de Asuntos Sociales
Da. Isabel Gonzlez Daz
Ministerio de Cultura
D. Miguel Joaqun Calvo
Instituto Nacional de Estadstica
Da. Adela Tello Sotes
Boletn Oficial del Estado
Da. Rosario Urndez Contreras
Ministerio de Adminisiraciones Pblicas
Colaboradores:
D. Alejandro Alvarez Shel1y
Auxiliar de Informtica
Da. Beatriz Madrid Obregn
Empresa consultora externa:
COOPERS & LYBRAND
345
P.V.P. 6.000 Dtas.

MAP
Ministerio
para las
Adm,"' straciones
Pblicas
AP
Ministerio
para las
Adm straciones
Pblicas
p.V.P. 6.000

Pblicas para las
,..
---
METODOLOGA
DE PLANIFICACIN Y
DE INFORMACIN
MTRICA VERSIN 2
GUA DE TCNICAS
METODOLOGA
DE PLANIFICACIN Y
DE INFORMACIN:
MTRICA VERSIN 2
GUA DE TCNICAS
MINISTERIO PARALAS ADMINISTRACIONES PUBLICAS
MADRID
1993
Coleccin: MANUALES
METRICA ~ es una iniciativa promovida por el Consejo Superior de Infor-
mtica, rgano colegiado encargado de la elaboracin ydesarrollo de la poltica
Edita:
ISBN: 84-7088-636-3 (Tomo III)
NIPO: 329-93-002-6
GUIA DE TECNICAS
METODOWGIA METRICA VERSION 2
GUIA DE TECNICAS
INDICE
1

O. IN1RODUCCION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3
1. DIAGRAMA DE FLUJO DE DATOS "............... 5
2. MODEUZACION DE DATOS 51
3. mSTORIA DE LA VIDA DE LAS ENTIDADES 85
4. EN1REVISTAS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 109
5. DISEO ESTRUCTURADO 121
6. ANALISIS COSTE-BENEFICIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 171
7. PRUEBAS .. 179
8. FACfORES CRITICOS DE EXITO 205
9. TECNICAS MATRICIALES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 219
10. EQUIPO RESPONSABLE DEL PROYECfO 241
GUIA DE TECNICAS
INTRODUCCION
3
La presente gua tiene como objetivo describir en detalle las distintas tcnicas utilizadas
en cada una de las actividades y tareas de la Metodologa Mtrica Versin 2.
Dentro de la Metodologa, se ha hecho especial nfasis en la utilizacin de tcnicas
grficas, las cuales presentan la ventaja de permitir una descripcin detallada de los
sistemas de una manera sencilla y fcilmente comprensible, mejorando la comunicacin,
tanto dentro del equipo de trabajo, como con los usua?0s.
Con el fin de permitir una utilizacin uniforme de las distintas tcnicas recomendadas
en la Metodologa, se da, para cada una de las mismas, una serie de consejos prcticos
para su desarrollo, y en el caso de las tcnicas grficas, la descripcin completa de los
distintos smbolos utilizados y el significado semntico de los mismos, adems se
incorporan ejemplos que ilustran el empleo de dichas tcnicas y facilitan la comprensin
de las mismas.
Por ltimo se relacionan las distintas actividades y t r ~ de la metodologa donde se
utiliza cada tcnica.
Es importante destacar en el caso de algunas tcnicas grficas, que hay que incidir en
el significado de la realidad que dichas tcnicas pretenden modelizar y no en la notacin
especfica de los iconos utilizados. As, por citar un ejemplo, en el caso de la tcnica de
Diagramas de Flujo de Datos, de uso ampliamente extendido, se utilizan diversos iconos
para representar los objetos del diagrama (procesos, entidades externas, almacenes), sin
embargo el significado de estos objetos es nico y las reglas que se utilizan para dibujar
el diagrama tambin. Es por ello que a la hora de implantar la Metodologa Mtrica
Versin i en una Organizacin concreta se podrn adaptar estos detalles a la cultura de
la misma, respetando sin embargo las reglas y restricciones especficas de las diversas
tcnicas.
DIAGRAMAS DE FLUJO DE DATOS
1. DIAGRAMAS DE FLUJO DE DATOS
INDICE
1.1. OBJETIVOS ..................................... 9
1.2. ELEMENTOS BASICOS DE WS
DIAGRAMAS DE FLUJO DE DATOS ............... 10
1.3. PRINCIPIOS FUNDAMENTALES DE
WS DIAGRAMAS DE FLUJO DE DATOS ........... 19
1.4. TECNICAS DE ESPECIFICACION DE
PROCESOS .................................... 23
1.5. TECNICAS PARA MEJORAR Y PROBAR
WS DIAGRAMAS DE FLUJO DE DATOS ........... 26
1.6. RECOMENDACIONES DE CODIFI-
CACION y CONSTRUCCION ...................... 32
1.7. UTILIZACION DE LA TECNICA
EN LA METODOWGIA METRICA 35
VERSION 2.
1.8. EJEMPLO DE CONSTRUCCION 36
7
1. DIAGRAMAS DE FLUJO DE DATOS
1.1. OBJETIVOS
9
Construir un modelo lgico del sistema que facilite la comprensin del mismo,
tanto por parte de los usuarios como del equipo de desarrollo.
Para ello se dividir el sistema en distintos niveles de detalle. Esta divisin
permitir:
Simplificar la complejidad del sistema, representando los diferentes
procesos sencillos de que consta un sistema complejo.
Repartir el trabajo entre los diferentes miembros del equipo de desarrollo.
Facilitar el mantenimiento del sistema.
Los fundamentos de la tcnica del Diagrama de Flujo de Datos (DFD) son los
siguientes:
Representar grficamente los lmites del sistema en estudio.
Mostrar el movimiento de los datos y la transformacin de los mismos a
travs del sistema.
Diferenciar las restricciones fsicas de las lgicas.
Para conseguir estos objetivos el resultado del anlisis debe ser:
GRAFICO.
WGICO, nunca referido a entornos fsicos.
PRECISO Y BREVE.
COMPRENSIBLE.
DEBIDAMENTE PARTICIONADO.
BIEN DOCUMENTADO.
NUNCA REDUNDANTE.
10
ESTABLECERA "QUE" FUNCIONES SE DEBEN DESARROLLAR,
SIN IMPUCAR "COMO".
NO AMBIGUO.
Como resultado se obtendr un modelo del sistema completamente independiente
de las restricciones fsicas del entorno, lo que facilitar su mantenimiento y
portabilidad.
En los Diagramas de Flujo de Datos, no se debern modelizar:
PROCEDIMIENTOS.
PUNTO DE INICIO Y DE TERMINACION DEL DFD.
CONDICIONES.
TRATAMIENTOS DE ERRORES POCO RELEVANTES.
1.2. ELEMENTOS BASICOS DE WS DIAGRAMAS DE FLUJO DE DATOS
En cualquier Diagrama de Flujos de Datos, aparecern los objetos siguientes:
ENTIDAD EXTERNA
PROCESO.
ALMACEN DE DATOS.
FLUJO DE DATOS.
Algunos de ellos podrn tener alguna restriccin con respecto nicamente al nivel
en el cual pueden o deben aparecer. Esto ya se detallar ms adelante.
La tcnica de representacin dar lugar a un DFD (Diagrama de Flujo de Datos)
en el que se irn detallando los principales procesos o acciones a desarrollar y
que se irn detallando en mayor medida segn se vaya bajando de nivel
(EXPLOSIONANDO) cada uno de esos procesos.
La comunicacin existente entre esas actividades se representa entre el resto de
los elementos.
MAP- Metodologa METRlCA Versin 2
DIAGRAMA DE FLUJO DE DATOS
11
El DIAGRAMA DE FLUJO DE DATOS (DFD) proporciona una representacin del
sistema a nivel lgico y conceptual.
Utiliza una notacin y unas reglas predeterminadas. La Figura siguiente nos muestra un
posible DFD para una biblioteca.
DATOS
LIBROS
ENCARGADO
DATOS
LIBROS
USUARIO
LIBROS
DATOS PRESTAMOS
DATOS PRESTAMOS
ENCARGADO
D3 PRESTAMOS
DATOS
REVISTAS
ENCARGADO
12
ENTIDAD EXTERNA
Las Entidades Externas representan entes ajenos a nuestra aplicacin, pero que aportan
o reciben informacin de la misma. Se representa mediante una elipse o un rectngulo
con un nombre significativo dentro.
Reglas de construccin:
1. Representa personas, organizaciones o sistemas que no pertenecen al sistema.
2. En el caso de que las entidades externas se comunicasen entre s, esto no se
contemplara en el diagrama, por estar fuera del mbito de nuestro sistema.
3. Puede aparecer en los distintos niveles de DFD.
4. Puede aparecer varias veces en un mismo diagrama, para evitar
entrecruzamientos de lneas.
5. Suministra informacin acerca de la conexin del sistema con el mundo exterior.
o
EXT2
GESTION ENCARGADO
DE BIBLIOTECA ...----.......
PROCESO
13
Es una actividad que transforma o manipula datos. Se representa mediante un
rectngulo, de la siguiente manera:
1 I LOCALIZACION
PROCESO
En la parte de PROCESO se expresa el nombre del proceso correspondiente.
Dependiendo del nivel de detalle en que nos encontremos dentro de un DFD, el nombre
del proceso simbolizar bien el sistema concreto (nivel sistema), bien el subsistema de
que se trate (nivel subsistema), o bien acciones concretas y detalladas en niveles
inferiores.
En la parte superior izquierda se coloca un nmero identificativo del proceso. Este
nmero permitir adems indicar el nivel del DFD en que nos encontramos; esto se
explicar ms en detalle cuando se hable de la descomposicin por niveles.
Es importante hacer nfasis en que este nmero no indica secuencia de realizacin del
proceso, dado que los DFD no representan una secuencialidad en el tratamiento de los
datos.
La parte de localizacin expresa la Unidad o rea dentro de la organizacin donde se
realiza este proceso.
1. Cuando un Flujo de datos entra en un proceso sufre una transformacin. Un
proceso no es ni origen ni final de los datos, slo lugar de transformacin de los
mismos. Por ello, cualquier flujo de datos que entre en un proceso ha de
transformarse (ver Figura DFD3).
2. Un proceso puede transformar un dato en varios.
3. Es necesario un proceso como intermediario entre una Entidad Externa y un
Almacn de Datos.
14
MAL BIEN
El
J
GESTlON
UBROS
03
ALMACEN DE DATOS
Un almacn de datos representa un depsito de informacin dentro del sistema.
Se representa dentro del DFD con la siguiente Figura:
NOMBRE
15
En la parte derecha se indica el nombre del almacn de datos. En la parte izquierda se
representa la identificacin de dicho almacn dentro del DFD.
En el captulo 1.6 se dan una serie de recomendaciones de codificacin y construccin
de los almacenes de datos.
En el caso de que dentro de un DFD aparezca repetido el mismo almacn de datos, se
puede representar de la siguiente forma:
D__
Es conveniente distinguir las diferentes utilidades que presentan los almacenes de datos.
En primer lugar, el almacenamiento permanente de datos, donde se guardan los datos
que sirven de referencia de uso del sistema, es decir, los datos permanentes, sobre los
que el sistema necesita guardar informacin (ALMACENES PRINCIPALES).
Por otra parte, el almacenamiento transitorio de los datos antes de ser usados por un
proceso. Para entender el significado de estos almacenes transitorios, se puede imaginar
la situacin del ejemplo de la Figura DFD5.
En este ejemplo el proceso RECOGER SOUCITUDES, que se ejecuta continuamente
a lo largo de la jornada, genera los datos de salida representados por el flujo de datos
SOLICITUDES. Estos datos constituyen los datos de entrada al proceso VALIDAR
SOLICITUD, que se ejecuta al final de la jornada, en el intervalo esos datos de solicitud
"reposaran" en el almacn SOLIC-PROV, cuya utilidad bsica es establecer una
sincronizacin en el funcionamiento de ambos procesos.
16
DSOLlCIT.DEFINIT.
I
VALIDAR
SOLICITUD
DOCUM.ENTRADA
RECOGER
SOLICITUD
I
SOLICITUD r--.-_----'-_SOLlcITUD ---1 f
~ I
Los almacenes transitorios suelen representar restricciones fsicas del sistema ypor tanto
en un DFD, que expresa la lgica de los tratamientos realizados por el sistema, en
muchos casos no ser necesario representarlos. Sin embargo hay ocasiones en que estos
almacenes simbolizan "ficheros de movimientos", donde se guardan los datos porque el
proceso siguiente necesita manejarlos todos al mismo tiempo (por ejemplo, en un
proceso que compara un conjunto de registros, ser necesario mantenerlos guardados en
un almacn transitorio, para que dicho proceso los lea todos al mismo tiempo). En este
caso s ser conveniente representarlos.
ror ltimo, para asegurar la consistencia entre todas las tcnicas utilizadas en la Fase
de Anlisis, se establecer una relacin precisa entre los almacenes de datos "principales"
de un DFD y las entidades de los Diagramas de Estructura de Datos (DED): cada
almacn principal de un DFD representa un conjunto completo de entidades del DED
(una o varias entidades), y cada entidad de un DED pertenece a un nico almacn
principal de un DFD; esto facilitar las validaciones cruzadas entre los dos diagramas.
1. Representa la informaci6n en reposo.
2. No puede crear, destruir ni transformar datos.
17
3. No puede estar comunicado directamente con otro Almacn o Entidad Externa.
4. El flujo de datos (Entrada o Salida) no lleva nombre cuando incide sobre su
contenido completo.
5. El almacn de datos aparecer por vez primera en aquel nivel en que sea
accedido por dos o ms procesos y en modo lectura y/o escritura.
6. No debe estar referido al entorno fsico ypor tanto, no se diferencian los ficheros
convencionales de las Bases de Datos.
7. No se representa la clave de acceso a ese almacn sino s6lo la operaci6n que se
realiza (lectura, escritura, actualizaci6n)
FLUJO DE DATOS
Los Flujos de Datos establecen la comunicaci6n entre procesos, almacenes y entidades
externas, y llevan informaci6n necesaria para esos objetos.
1. El concepto de flujo de datos es similar al de una "tubera" a travs de la cual
fluye una informaci6n de estructura conocida.
2. Los datos no pueden ser creados ni destruidos por un flujo de datos.
3. Sirve para conectar el resto de los componentes del DFD.
4. No es un activador de procesos.
5. Cuando un proceso almacena datos, la flecha de flujo de datos se indica en la
direcci6n del almacn de datos y a la inversa si es el proceso el que lee datos en
el almacn.
18
DOCUM. ENTRADA
"ACTUAUZACION"
DAlOS
UBAOS
ENCARGADO
=1 la
.---.---'---..L,
~ F I N I T
DATOS
REVISTAS
ENCARGADO
DIAGRAMAS DE FLUJO DE DATOS 19
1.3. PRINCIPIOS FUNDAMENTALES DE WS DIAGRAMAS DE FLUJO DE
DATOS
DESCOMPOSICION O EXPWSION POR NIVELES:
Los Diagramas de Flujo de Datos han de representar el Sistema de la forma ms
clara posible, por ello se basarn en el principio de descomposicin o explosin
en distintos niveles de detalle.
La descomposicin por niveles permite analizar el sistema desde el mbito
general al detalle, pasando por sucesivos niveles intermedios (filosofa de arriba
a abajo o "top-down").
La utilizacin de esta tcnica implica la descomposicin o explosin de cada
proceso en otro DFD.
El sistema deber contener:
Un diagrama de contexto (primer nivel).
Varios DFD en niveles intermedios.
Varios DFD en el ltimo nivel de detalle.
En la Figura siguiente se representan los distintos niveles que pueden surgir a la
hora de desarrollar nuestro sistema de informacin.
En cualquier momento puede aparecer un proceso que no necesite
descomponerse y es lo que se llama PROCESO PRIMITIVO (PP). En ellos, slo
se detallar la entrada y salida que tenga, adems de la descripcin asociada que
explique lo que realiza.
20
CONTEXTO
D.
, ,
, ,
,
,
,
,
,
,
,
,
\.
, ,
,
, ,
,
,
,
,
,
,
SUBSISTEMAS
".
El
El
".
,
...
,
...
,
,
, ...
".
...
".
,
...
".
, ...
...
".
". , ,
...
,
".
, ...
...
".
,
...
,
". ,
...
".
, ....
...
".
". ,
...
".
, ...
".
...
".
,
...
, , ...
FUNCIONES
FUNCIONES
O O
O
U
, ,
\ \
\
\ I I
, ,
\ I
\
\ I I
, ,
\ I
\
\ \ I
, ,
\ I \ \ \ I
, ,
\ \
\ \ \ I
,
\
\ ..
, ,
\ \ \ I I
, ,
\ \ \ \ \ I
, ,
\ I \ \
,
PROCESO
,
PROCESO
PROCESO
PROCESO
PRIMITIVO
PRIMITIVO
PRIMITIVC
PRIMITIVC
1.1.1 p
F
9
8
:.1
1.2.1 2.1.1
2.2.1
MAP- Metodologa METRICA Versi6n 2
El procedimiento a seguir para la representacin del sistema en diferentes niveles de
detalle se indica a continuacin:
1. Representar el Diagrama de Contexto.
2. Representar el DFD de primer nivel, indicando los distintos subsistemas o reas
funcionales en que se descompone nuestro sistema.
3. Descomponer cada uno de los procesos que aparecen en el DFD de primer nivel,
hasta llegar a un nivel suficiente de detalle.
4. Si es necesario, reagrupar y reorganizar los distintos subsistemas que se han
identificado inicialmente, Esto implicar reasignar procesos a otras reas
funcionales, o incluso crear nuevas reas funcionales, es decir, subir de nivel para
redefinir las reas funcionales o subsistemas.
5. Repetir el proceso de descomposicin hasta llegar a un nivel suficiente de detalle.
La identificacin de las reas funcionales o subsistemas se har atendiendo, entre otros,
a los siguientes criterios:"
Funciones organizativas o administrativas propias del sistema a desarrollar y
especficas de la problemtica de la Unidad.
Homogeneidad de las funciones realizadas por los procesos pertenecientes a un
rea funcional o subsistema.
Localizacin geogrfica de los procesos.
Procesos que actualicen los mismos almacenes de datos se colocarn en el mismo
subsistema o rea funcional.
El objetivo ltimo ser conseguir que las comunicaciones o enlaces entre distintos
subsistemas o reas funcionales sean lo ms reducidas y homogneas posibles.
Con el fin de asegurar la consistencia con otras tcnicas utilizadas en la Fase de Anlisis,
se recomienda llegar hasta cuatro niveles de descomposicin en los Diagramas de Flujo
de Datos:
1.
2.
NivelO:
Nivel 1:
Diagrama de contexto.
Subsistemas.
22
3.
4.
5.
Nivel 2:
Nivel 3:
Nivel 4:
Funciones de cada subsistema.
Subfunciones asociadas a cada uno de los eventos del sistema.
Procesos necesarios para el tratamiento de cada subfuncin.
Las ventajas de esta descomposicin son las siguientes:
Es comprensible para usuarios no informticos.
Los procesos en el ltimo nivel estn relacionados lgicamente.
Los procesos en el nivel 3, de eventos, estn separados en el tiempo.
Facilita las referencias cruzadas con otros productos obtenidos en la metodologa,
concretamente con el Catlogo de Eventos obtenido en la Tarea EFS 3.1
("Construccin del Modelo entidad-evento").
DIAGRAMA DE CONTEXTO
El objetivo es realizar una declaracin formal del dominio.
Un slo proceso representar el rea que se est estudiando.
El contexto queda definido por los flujos de entrada y salida y las entidades externas.
Las entidades externas han de aparecer en este nivel y no en ningn otro (salvo para
mejorar la comprensin del resto de los DFD).
El primer DFD que va a aparecer es el que se va a llamar DIAGRAMA DE
CONTEXTO Yes precisamente el grfico que va a proporcionar el mbito del proyecto
objeto de estudio. En l aparecer todo aquello que necesite o enve datos del o hacia
el sistema a desarrollar. Estos se representan por unos objetos que se'llaman Entidades
Externas.
El diagrama de contexto tendr la forma siguiente:
El proceso representa el SI que se va a desarrollar.
23
1.4. TECNICAS DE ESPECIFICACION DE PROCESOS.
Objetivo: DESCRIBIR LA LOGICA DE LOS PROCESOS.
Debern definirse en ms detalle slo las funciones o procesos primitivos, es
decir, aquellos que no se han descompuesto ms.
No se detallarn funciones que resulten obvias.
Cada especificacin de proceso debe describir cmo se logra transformar el flujo
de datos que llega en los flujos que salen.
Cada especificacin de proceso debe describir las normas que gobiernan la
transformacin, no el mtodo de implantar esas normas.
En todo caso, y como se indica en la gua de referencia de la Metodologa, se han
de incluir en la descripcin de los procesos de ltimo nivel los siguientes aspectos:
Modo de acceso de los procesos a las entidades de datos del sistema.
24 DIAGRAMAS DE FLUJO DE DATOS
Tipo de tratamiento (interactivo o por lotes).
Informacin sobre la frecuencia de ejecucin.
Caractersticas del proceso:
Actualizacin de datos del sistema.
Consultas e informes.
Realizacin de algoritmos especficos y descripcin de los mismos.
A ,la hora de describir los procesos de ltimo nivel de un DFD, se pueden utilizar las
siguientes tcnicas:
NARRATIVA TRADICIONAL.
LENGUAJE ESTRUCTURADO.
TABLAS DE DECISION.
ARBOLES DE DECISION.
A continuacin, se describen brevemente alguna de estas tcnicas.
NARRATIVA TRADICIONAL
Tiene la debilidad inherente del lenguaje natural como herramienta para especificar:
Imprecisa.
Redundante.
Uena de implicaciones y connotaciones.
Ejemplo:
"Para aplicar el descuento, el cliente debe tener una cifra de compra de ms de 3.000.000
de pesetas/ao y un buen historial de pagos o haber sido cliente ms de 5 aos".
Cul es el significado de la anterior descripcin narrativa?
3.000.000 pts. Yun buen historial?
3.000.000 pts y 5 aos?
Basta con los 5 aos?
Qu quiere decir un buen historial de pagos?
LEN.GUAJE ESTRUCfURADO
Debe ser comprensible para el informtico y el usuario.
Utiliza una sintaxis limitada sin llegar a ser tan rgida como una codificacin.
Las descripciones deben ser precisas y concisas, evitando la retrica del lenguaje.
Utilizar verbos precisos sin ambigedad, evitando, por ejemplo:
HACER, TRATAR, PROCESAR, CONTROLAR.
Los nombres utilizados deben estar definidos en el diccionario de datos.
25
Los adjetivos utUizados e ~ n ser auto-explicativos. Por ejemplo: VALIDO, ERRONEO.
No deben utilizarse los adjetivos, adverbios y verbos que expresan relatividad. Por
ejemplo: Incrementar, reducir, escaso, suficiente, etc.
Hay que indicar de forma inequvoca el objeto sobre el que debe aplicarse la accin.
SINTAXIS DEL LENGUAJE ESTRUCIURADO
Sentencias declarativas simples.
Construcciones de decisin.
Construcciones de repeticin.
Combinaciones de ambas.
Las acciones escritas de esta forma son fciles de leer y de entender.
Algunos ejemplos de Lenguaje Estructurado se detallan a continuacin:
26
SECUENCIA:
ACCION 1
ACCION 2
ACCION 3
ACCION 4
ACCION 5
DECISION
SI (CONDICION),
ENTONCES
ACCION 1
ACCION 2
CASO CONTRARIO,
ACCION 3
METODO DE WS CASOS
PARA CADA TRANSACCION
SELECCIONAR:
CASO l:ACCION 1
CASO 2:ACCION 2
CASO 3:ACCION 3
CONSEJOS PRACTICOS PARA UTILIZAR EL LENGUAJE ESTRUCTURADO:
La excesiva anidacin de sentencias condicionales (si/no) complica la comprensin de
las especificaciones.
Utilizar el mtodo de los casos cuando la lgica del proceso sea compleja, por existir
diversidad de opciones.
Evitar sentencias del tipo "HACER HASTA" o "HACER MIENTRAS".
Emplear expresiones positivas, evitando sentencias del tipo: "Si la transaccin no es
errnea..."
Evitar expresiones matemticas complejas.
1.5. TECNICAS PARA MEJORAR Y PROBAR WS DIAGRAMAS DE FLUJO DE
DATOS.
A continuacin se detallan una serie de pruebas para comprobar la validez de los
diagramas:
PRUEBAS DE CORRECCION
PRUEBAS DE UTILIDAD (COMPRENSION).
PRUEBAS DE COHESION.
PRUEBAS DE CORRECCION
En la descomposicin de un proceso puede que se nos olvide alguno de los Flujos de
Datos (FD) del nivel superior, o que el FD de ese nivel superior se descomponga pero
se incluya algn flujo que no debera aparecer o nos falte alguno.
Faltan flujos de datos requeridos por un proceso.
Flujos de datos de ningn valor para el proceso.
Faltan procesos.
Incoherencia entre niveles.
En los grficos siguientes se trata de dar una idea de qu es el cuadre entre niveles
sucesivos.
EJEMPLO 1
Ver si es correcto ellCuadre" de los Diagramas de Flujos de Datos siguientes:
8
M
Como resultado de la inspeccin visual, se detecta que en el proceso 3 del DFD de nivel
superior entran los flujos de datos M y N Ysale el flujo de datos T.
Sin embargo, en el DFD resultado de la descomposicin del proceso 3, representado en
la parte inferior de la Figura, el flujo de datos de entrada es N y los flujos de datos de
salida son T y S.
Esto indica una inconsistencia entre ambos niveles de detalle.
Hay que tener en cuenta que los flujos de datos son, como se ha definido, "tuberas" que
contienen un conjunto de datos, los cuales estn descritos en detalle en el diccionario
de datos del proyecto. Por esto puede ocurrir que aunque el nmero de flujos de datos
netos de entrada y salida no coincida de un nivel a otro, el contenido de dichos flujos
s lo haga, al ser distinta su denominacin en los distintos niveles, por ello ser necesario,
para comprobar la consistencia entre los distintos niveles, examinar el diccionario de
datos del proyecto.
PRUEBAS DE UTILIDAD
Estas pruebas son ms de sentido comn que de un estudio exhaustivo sobre los DFD.
Comprobar si el diagrama es legible.
Analizar la complejidad de la interfase.
Comprobar que los nombres asignados ayudan a comprender sin ambigedad el
DFD.
PRUEBAS DE COHESION
Si un proceso explosiona, el DFD al que da lugar ha de tener todos sus elementos
conectados. Si no, habr que redibujar el proceso del DFD padre.
Siempre que un diagrama de nivel inferior conste de elementos desconectados se
tendr que modificar el DFD "padre" y el DFD "hijo".
Comprobar la ausencia de redundancias.
Comprobar que no faltan procesos y que stos son totalmente coherentes.
EJEMPLO 2
29
En este DFD, el proceso 2 vemos que da lugar por descomposicin a dos grafos no
conectados. Dar una solucin, sobre el diagrama correspondiente.
A
4 I

I
.,
N
G-
1 I
B
-
P
H .,

I
5 I
J
.
t
I
t.-
2
I
F
e
H
--
K
E
3 I
o
L
30
El DFD explosin del proceso 2 es:
J
_t;TJ
K M
e
N
SOLUClON:
Descomponer en el nivel superior el proceso 2 en los procesos 2' y 2".
141 1
I

1
1
1 I
A
I
B
H
I 2' 1
I
I
p
J
t e
,,; 1
I F
r
I 3 I I
M
o 1{
I
I
1
1.,.. 1 1
L
E
I DFDI31
1
31
1.6. RECOMENDACIONES DE CODIFICACION y CONSTRUCCION
Es importante destacar que la utilizacin de las tcnicas estructuradas que se indican en
la Metodologa hace necesaria la existencia de un Diccionario de datos del proyecto,
donde se referencien y describan todos los objetos que aparecen en los grficos.
La existencia de este diccionario proporciona, entre otras, las siguientes ventajas:
Asegurar la consistencia de todos los objetos que se consideran en un Sistema.
Facilitar la reusabilidad de dichos objetos.
Se utiliza la expresin general "objeto" para indicar todos aquellos elementos
considerados y que son, entre otros:
Diagramas de Flujos de Datos.
Procesos.
Flujos de Datos.
Registros.
Elementos.
A la hora de describir estos objetos en el diccionario se utilizar un cdigo que
conjuntamente con el tipo de objeto de que se trate, permita identificar de forma nica
dicho objeto.
Para asignar este cdigo o identificador de los objetos (ID) es conveniente seguir una
normas de nomenclatura genricas para toda la Unidad.
Si se quiere clarificar el significado de los objetos utilizados, se podr utilizar un nombre
nemotcnico que indique su contenido. Este nombre nemotcnico o etiqueta ser libre,
y descriptivo de la naturaleza de dicho objeto.
A continuacin se indican una serie de recomendaciones generales para la codificacin
de los Diagramas de Flujo de Datos y los objetos que contienen.
Por ltimo, es importante mencionar que la existencia de herramientas CASE, que
permiten automatizar el diccionario del proyecto, facilitando las labores de
documentacin y mantenimiento de la informacin del proyecto.
1. CODIFICACION DE PROCESOS Y DFD
33
La codificacin de los DFD y de los procesos que contiene tendr la siguiente
estructura: AAXX..XX.
AA es un prefijo que indica la aplicacin de que se trate. Por ejemplo: BO
(Boletn Oficial); RH (Recursos Humanos).
XX..XX indica el nivel de DFD de que se trata. As, por ejemplo, para los
distintos niveles se proceder:
1. El Diagrama de contexto, que se puede nombrar o bien
CONTEXTO o bien segn el nombre del sistema que se trata de
describir.
2. El Diagrama de contexto contiene un slo proceso, cuyo
identificador es AAO. Este proceso Oexplosiona al DFD AAO.
3. El DFD AAO contiene los procesos AA1, AA2, AA3,..., hasta 7
9 como mximo, que identifican los subsistemas en que se divide
nuestro sistema.
4. Cada uno de estos procesos AA1, AA2, AA3,... explosionar a su
vez a los DFD AA1, AA2, AA3, ... que describen ms en detalle los
subsistemas que se han identificado.
5. El DFD AAX (siendo X = 1,2,3,...) contiene los procesos AAX.1,
AAX.2, AAX.3, ... hasta 9.
Cada uno de estos procesos AAX.Y (siendo Y =. 1, 2, 3,...)
explosiona a su vez al DFD AAX.Y. Por ejemplo el proceso AA2.3,
explosiona al DFD AA2.3. Este DFD AAX.Y contendr los
procesos AAX. Y.1, AAX.Y.2,..., que a su vez explosionan a los
DFD del mismo nombre y as sucesivamente.
6. Otras informaciones de inters sobre los procesos sern:
Localizacin de los procesos: se refiere al lugar de la unidad
donde se realiza este proceso.
Etiqueta de los procesos: indica el tratamiento que se realiza
con los flujos de datos que recibe el proceso, por lo cual se
etiquetarn con una frase simple que contenga un verbo
concreto que identifique el proceso principal al que se van
a someter los datos.
2. CODIFICACION y CONSTRUCCION DE ALMACENES DE DATOS
Los almacenes de datos se codificarn de la forma siguiente: AAXXX[/X]
AA: Prefijo que indica la aplicacin de que se trata.
XXX: Nmero secuencial.
[/X]: Opcional. Se utilizar en el caso de que en un nivel determinado de un
DFD se utilice un almacn genrico con un conjunto de datos, y se decida
desglosar estos datos en diferentes almacenes dentro de DFD de mayor
nivel de detalle.
As por ejemplo, en un DFD de nivel 1 se ha descrito el almacn.
AA2: Pedidos
que contiene datos de la cabecera de pedidos y de las distintas partidas de
pedido.
En DFD de mayor nivel de detalle, el desglose podra ser:
AA2/1:
AA2/2:
Cabecera de Pedidos.
Partida de Pedidos.
La etiqueta de los almacenes reflejar los datos que contiene: si el almacn
explosiona a una entidad de datos, su etiqueta ser el nombre de dicha entidad,
si explosiona a un Diagrama de Estructura de Datos su etiqueta ser el nombre
de dicho Diagrama de Estructura de Datos.
Para construir almacenes de datos dentro de nuestro sistema, se pueden seguir
las siguientes opciones:
1. Definir pocos almacenes de datos, cada uno de los cuales explosiona a un
2. Definir, desde el principio, tantos almacenes de datos como entidades de
datos se hayan identificado dentro del sistema y explosionar estos
almacenes a dichas entidades de datos. Si el nmero de almacenes no es
muy grande se escoger esta segunda opcin.
Como ya se ha indicado, los modelos de procesos (DFD) y de datos
(Diagrama de Estructura de Datos) han de ser consistentes entre s.
3. ENTIDADES EXTERNAS
1. Su identificador (ID) se compondr de dos caracteres: X9.
X: letra mayscula.
9: Dgito numrico.
2. Su etiqueta ser descriptiva de la naturaleza de dicha entidad.
4. FLUJOS DE DATOS
35
1. Su identificacin (ID) ser la siguiente: NOMBRE OBJET01/NOMBRE
OBJET02. As por ejemplo, un flujo de datos (FD) que conecte el
proceso AA1.1 con el proceso AA1.2, se codificar: 1.1/1.2. En la
identificacin se ha suprimido el cdigo del sistema AA, por ser
redundante.
2. La etiqueta de estos flujos de datos indicar la informacin que contienen.
1.7. UTILIZACION DE LA TECNICA EN LA METODOWGIA METRICA
VERSION2.
Esta tcnica se utilizar en las siguientes fases y actividades:
FASE O:
Tarea PSI 4.2:
FASE 1:
Tarea ARS 3.1:
Tarea ARS 4.1:
Tarea EFS 1:
("Diseo de la Jerarqua de Funciones").
ANALISIS DE SISTEMAS.
("Construccin del Modelo Lgico Actual de Procesos").
("Definicin de Alternativas").
("Construccin del Modelo de Procesos del Nuevo Sistema").
1.S. EJEMPW DE CONSTRUCCION
A continuacin se describir un ejemplo que pretende ilustrar la divisin en
niveles de los DFD, segn las recomendaciones contenidas en la descripcin de
la tcnica.
El caso en estudio es un Organismo Autnomo de la Administracin,
concretamente una Junta de Puerto, cuya labor bsica es gestionar el uso y
mantenimiento de las instalaciones portuarias. El mbito del sistema cubrir
solamente las reas de Gestin de Mercancas, Comisara del Puerto y
Mantenimiento de Instalaciones.
Una vez realizadas las entrevistas con los responsables del Organismo, as como
con los usuarios especializados en el funcionamiento de las distintas reas del
mismo se han identificado las siguientes entidades externas con que se relaciona
el Organismo:
EMPRESAS CONSIGNATARIAS DE BARCOS: que comunican a la Junta del
Puerto la entrada de los barcos, as como sus caractersticas (petrolero, granelero,
etc.), adems de solicitar la prestacin de determinados servicios (carga, descarga,
etc.). Esta entidad externa recibe de la Junta la facturacin de .todos los servicios
prestados por la misma al barco en cuestin (carga, descarga, almacenamiento,
gras, contenedores, atraque, etc.) ,
PROVEEDORES: proporcionan a la Junta los materiales necesarios para el
mantenimiento de las instalaciones portuarias, envan sus facturas y reciben pagos.
GESTION DE ALMACENES: en principio sta ser una de las funciones que
realiza la Junta y ser considerada como un sistema aparte. Enviar al sistema en
estudio informacin sobre disponibilidad y grado de ocupacin de los almacenes,
y recibir del sistema previsiones de demanda de dichos almacenes.
PERSONAL/OTP: engloba dos sistemas cuya responsabilidad es la gestin de
personal tanto interno como externo del Organismo (es personal externo el
gestionado por la Organizacin de Trabajos Portuarios: estibadores, etc.). Esta
entidad externa recibe del sistema en estudio la siguiente informacin:
Peticiones de personal.
Informacin de horas trabajadas.
Informacin de horas extraordinarias.

Notificacin de incidencias en el servicio.
37
Esta entidad externa enva al sistema informacin sobre disponibilidad de
personal (tanto especializado como no especializado).
El Diagrama de contexto ser pues el sigUiente:
INFORMACION
BARCOS
JPO
INFORMACION
ALMACENES
INFORMACION
MATERIALES
INFORMACION
PERSONAL
Dado que los flujos de datos entre el sistema y las entidades externas contienen
gran cantidad de informacin, desglosarlas en detalle y representarlas en el
diagrama de contexto creara confusin. Es conveniente darles un nombre
genrico y describir su contenido real en el diccionario de datos.
El diccionario de datos del proyecto se ir creando a medida que se representan
las diferentes vistas del sistema (DFD, Historia de vida de las entidades,
Diagrama de estructura de datos). Esta creacin "iterativa" es rpida si se dispone
de una herramienta CASE que permita automatizar dicho diccionario.
A continuacin, iremos entrando en el detalle de cada uno de los niveles de
descomposicin de un DFD, recomendados en la descripcin de la tcnica, y que
son:
Nivel 1:
Nivel 2:
Nivel 3:
Nivel 4:
Subsistema.
Funciones que realiza cada subsistema.
Subfunciones que tratan los eventos del sistema.
Procesos necesarios para el tratamiento de cada subfuncin.
Nivel 1: Subsistemas.
El mbito del sistema a desarrollar cubrir las siguientes Unidades o reas del
Organismo:
Comisara del Puerto.
Gestin de Mercancas.
Mantenimiento de instalaciones.
La identificacin de estos subsistemas viene dada en gran medida por la
estructura organizativa existente. Cabe la posibilidad de que, a medida que se va
incrementando el grado de detalle en la descripcin del sistema, aparezcan ciertas
disfuncionalidades como duplicacin de funciones, excesivos flujos de informacin
de ida y vuelta entre subsistemas, etc. Todo esto salta a la vista mediante la
tcnica del DFD, sin embargo no hay que olvidar que una reestructuracin de
funciones no es posible en muchos casos debido a restricciones legales, de
personal, etc. y que adems generalmente cae fuera de las responsabilidades del
equipo de analistas y del mbito del estudio.
Una vez identificados los diferentes subsistemas, se representan los flujos de
informacin entre ellos mismos. La comunicacin entre subsistemas viene descrita
siempre mediante almacenes de datos, dado que los almacenes simbolizan
tambin una ruptura temporal en el tratamiento, es decir, los subsistemas
representados funcionan independientemente en el tiempo. En el ejemplo, el
subsistema de Comisara introduce como flujos de datos de entrada en el almacn
de CARGUEROS con los siguientes datos:
Nombre de los barcos.
Caractersticas de los mismos.
Das de permanencia.
Facturacin de atraque.
Servicios solicitados.
Caractersticas de la mercanca.
Tiempo estimado de prestacin de servicios.
Esta informacin est contenida en el flujo de datos "Datos de barcos" de la
Figura.
El subsistema de gestin de mercancas introducira, en dicho almacn, para cada
barco:
Tipo de trabajos suministrados.
Facturacin de horas de trabajo.
Superficie ocupada en puerto.
Etc.
Esta informacin est contenida en el flujo de datos "Datos de trabajos
efectuados" de la Figura.
Toda esta informacin, que se contiene en la descripcin que se hace del
almacn, dentro del diccionario de datos del proyecto, es introducida en distintos
tiempos por dichos subsistemas y consultada (flujos de datos de salida del
almacn) tambin de forma aleatoria en el tiempo.
40
JPl
INFORMACION
BARCOS
INFORMACION
PERSONAL

ALMACENES
JP2
COMISARIA
DEL PUERTO
GESnON
DE MERCANCIAS

DATOS DE DATOS DE TRABAJOS
BARCOS EFECTUADOS
D2 SERVICIOS
JP3
MANTENIMIENTO
INSTALACIONES
INFORMACION
PERSONAL
Nivel 2: Funciones que realiza cada subsistema.
41
En este punto desarrollamos slo el subsistema "GESTION DE MERCANCIAS",
para el cual el analista ha identificado, basndose en las entrevistas realizadas y
en su experiencia personal, las siguientes funciones:
CARGADE MERCANCIAS: Engloba todas las tareas administrativas necesarias
para la carga de mercancas, en funcin de:
Las caractersticas del barco, proporcionadas por el almacn
CARGUEROS.
Las caractersticas de personal necesario, proporcionadas por la entidad
externa (que no se representa) PERSONAL/OTP y por el almacn de
datos de PERSONAL.
Las necesidades especficas de transporte, que dependern de las
caractersticas de las mercancas y de la distancia y tipo de los almacenes
disponibles, informacin esta ltima que es proporcionada por la entidad
externa GESTION DE ALMACENES;
Los contenedores utilizados, cuyo tipo y caractersticas implicarn la
eleccin de determinados tipos de gra.
DESCARGA DE MERCANCIAS: similar al de carga de mercancas.
PLANIFICACION DE ALMACEN: esta funcin comprende las tareas
administrativas de previsin de ocupacin y demanda de almacenes, informacin
que proporciona a la entidad externa "GESTION DE ALMACENES", a la vez
que recibe de dicha entidad externa informacin sobre la disponibilidad y grado
de ocupacin de dichos almacenes.
A continuacin se representa este nivel de funcin.
INFORMACION
ALMACENES
ORMACION
MACENES
ORMACION
INF
RSONAL
AL
JP2.2! MERCANCIAS
DESCARGA DE
MERCANCIAS
ES
-
-
INF
PE
INFORMACION
PERSONAL
JP2.11 MERCANCIAS

CARGA DE
MERCANCIAS
f
JPl ICARGUEROS
I JP4 I=NTENEDOR
11
P2.3 I MERCANCIAS
PLANIFICACION
ALMACEN
INFORMACION
ALMACENES
Nivel 3: Subfunciones que tratan los eventos del sistema.
43
Detallaremos aqu el tratamiento de la funcin JP2.1: CARGA DE
MERCANCIAS, que se ha descrito en lneas generales en el nivel anterior.
Las distintas subfunciones que se identifican en este nivel son:
ASIGNAR GRUAS
ASIGNAR PERSONAL
RESERVAR CONTENEDORES
ASIGNAR MATERIAL DE TRANSPORTE
ACfUALIZAR CARGA DE TRABAJOS
ELABORAR INFORMACION
Detallaremos a continuacin cada una de estas subfunciones.
ASIGNAR GRUAS:
Se asignan las gras necesarias, como consecuencia de los servicios
solicitados y segn las caractersticas de la mercanca y el tiempo estimado
de carga (informacin extrada del almacn de datos CARGUEROS) y en
funcin de la informacin contenida en el flujo de datos "Informacin de
almacenes" que contiene, entre otras cosas, lo siguiente:
Localizacin de almacenes.
Cantidad de mercancas que contiene.
Actualizndose as el almacn de datos GRUAS segn el esquema de la Figura:
INFORMACIOH
ALMACENES
ASIGNAR PERSONAL:
Se asigna el personal necesario para las labores de carga, para ello se necesitar
la siguiente informacin:
Informacin de personal proporcionada por la entidad externa
PERSONAL/OTP, que nos indica la cantidad de personal disponible, la
cualificacin del mismo, etc.
Informacin de la cantidad de mercanca (procedente del almacn
CARGUEROS).
Informacin de las gras asignadas, que es fundamental para saber qu
personal asignar, y procede del almacn GRUAS.
Con ello se actualiza el almacn de datos PERSONAL, como indica la Figura.
INFORMAClON
PERSONAl
f"'a'I ......-1

I PERSONAl I
P5 RUAS I JP. !cARGUEROS
DIAGRAMAS DE FLUJO DE'DATOS
RESERVAR CONTENEDORES:
45
Se asignan los contenedores necesarios para las labores de carga, en funci6n de
la siguiente informaci6n:
Caractersticas de la mercanca, procedente del almacn CARGUEROS.
Caractersticas de las gras (potencia, capacidad de carga, etc.),
procedente del almacn GRUAS.
Con ello se actualiza el almacn CONTENEDORES, segn el esquema de la
Figura:
ASIGNAR MATERIAL DE TRANSPORTE:
Se asigna el material de transporte necesario para llevar los contenedores desde
un lugar de almacenaje hasta el muelle donde est el material que se carga. Para
ello, se necesita la siguiente informaci6n:
Informaci6n sobre los contenedores, extrada del almacn de datos
CONTENEDORES, que tendr entre otras cosas:
Nmero de contenedores.
Tipo de contenedores.
Peso de contenedores.
Forma de contenedores.
Localizaci6n.
MAP - Metodologfa METRlCA Versin 2
Informacin de almacenes, procedente de la entidad externa GESTION
DE ALMACENES, que nos informar entre otras cosas de:
Localizacin de almacenes de la mercanca.
Caractersticas del muelle (existencia de vas de ferrocarril, etc.)
Con esta informacin se actualiza el almacn de datos TRANSPORlE, segn el
esquema de la Figura:
INFORMAClON
ALMACENES

ACTUALIZAR CARGA DE TRABAJOS:
Una vez realizados los trabajos solicitados por los consignatarios, se actualizar
el almacn de datos CARGUEROS, con los datos econmicos que se extraigan
de los almacenes de datos siguientes:
GRUAS
TRANSPORlE
PERSONAL
CONlENEDORES
segn el esquema de la Figura:
Como se puede ver en este nivel se han identificado un conjunto de subfunciones
que actualizan los almacenes de datos del sistema.
Si recordamos el concepto de evento como "suceso que activa los procesos de
actualizacin de datos del sistema", tendremos identificados y los describiremos
en el diccionario de datos del proyecto, los siguientes eventos:
Asignacin de gras.
Asignacin de personal.
Reserva de contenedores.
Asignacin de material de transportes.
Actualizacin de datos econmicos de los cargueros.
Estos eventos nos servirn de punto de partida para la elaboracin de la tcnica
de Historia de la Vida de la Entidad.
Por esta razn se ha denominado este nivel como "Nivel de subfunciones que
tratan los eventos del sistema".
Adems de estas subfunciones de actualizacin de datos, identificamos otra:
ELABORACION DE INFORMACION, que suministra a las entidades externas
PERSONALjOTP y GESTION DE ALMACENES la informacin extrada de
los almacenes de datos del sistema.
En la Figura siguiente se representa este nivel en conjunto.
48

t
JPI \cARGUEROS
ASIGNAR
GRUAS
JP2.1.1 1CAROA MERCANC.
INFORMACION
PERSONAL
---. P2.1.31 CARGAMERCANC.
RESERVAR
CONTENEDORES
r;;-r:_R_U_A_S --..IJP2.1.2
1
CARGA MERCANC.
L:..........L ASIGNAR
PERSONAL
EJ GRUAS
INFORMACION
ALMACENES
1
JP2.1 .41 CAROA MERCANC.
ASIGNAR
MAT.TRANSPORTES
INFORMACION
PERSONAL
INFORMACION
ALMACENES
! .

1 I ..... GRUAS I
!JP2.1.5 I CARGAMERCANC. 1-" C--'l IJP2.1.6 CARGAMERCANC.
ACTUALIZAR ELABORAR
CARGA TRABAJOS INFORMACION
L.-__""T"" --J .......---EJ PERSONAL
f

Nivel 4: Procesos necesarios para el tratamiento de cada subfuncin.
49
Se detalla en este nivel la subfuncin: ASIGNAR GRUA En funcin de los
requisitos de usuarios se han identificado los siguientes procesos que detallan esta
subfuncin:
Asegurar disponibilidad de la grua.
Elaborar una previsin de ocupacin.
Reservar material de grua.
Estos procesos estn lgicamente relacionados y se desencadenan en el momento
que se produce el evento "Asignacin de grua".
En general, en este nivel los procesos son ya muy elementales y en muchas
ocasiones no ser necesario llegar hasta este nivel de detalle. En la Figura
siguiente se representa el DFD que detalla el tratamiento realizado en este nivel.
Por ltimo es conveniente recalcar que los niveles de descomposicin a que se
llega en los DFD, as como la identificacin de funciones del sistema, dependen
bsicamente de la naturaleza del problema y de la. experiencia y juicio subjetivo
del analista, con lo cual las pautas que se han dado en esta gua son meramente
indicativas de cmo encarar de una forma metdica el anlisis de un sistema.
MODEUZACION DE DATOS
2. MODELlZACION DE DATOS
INDICE
2.1. INTRODUCCION " 55
2.2. OBJETIVOS 56
2.3. CONCEPTOS BASICOS 57
2.3.1. Los tres esquemas de la Arquitectura de Datos.
2.4. DEFINICIONES 60
2.5. ESTRATEGIAS DE DISEO 64
2.6. MODEW CONCEPTUAL ' 65
2.6.1. Introduccin.
2.6.2. Modelo entidad-relacin de CHEN.
2.6.3. Diagrama de estructura de datos.
2.6.4. Fases en la construccin del modelo conceptual.
2.7. MODELO WGICO: NORMALIZACION 75
2.7.1. Objetivos.
2.7.2. Conceptos bsicos.
2.7.3. Procedimiento de normalizacin.
2.7.4. Comparacin entre el diagrama de estructura
de datos y la estructura de registros normalizados.
2.8. REGLAS DE INTEGRIDAD 81
2.9. OPTIMIZACION DEL MODELO DE DATOS 81
2.10. UTILIZACION DE LAS TECNICAS EN LA
METODOLOGIA METRICA VERSION 2 82
53
MODELIZACION DE DATOS
2. MODEUZACION DE DATOS
2.1. INTRODUCCION.
55
En este captulo se tratarn las tcnicas: Modelo entidad-relacin de CHEN y
Diagrama de Estructura de Datos, las cuales estn orientadas a representar
grficamente las necesidades de informacin que posee la unidad. Estos grficos
se diferencian en la notacin y en los caminos que siguen para llegar a converger
en las estructuras de datos finales que se implantarn.
La comprensin de las necesidades del usuario es especialmente importante para
su posterior representacin, sin tener en cuenta en esta primera fase, las
necesidades de la tecnologa existente, ni otras restricciones.
Se quiere hacer especial nfasis en la diferencia existente entre Modelizacin de
Datos y Base de Datos.
La Modelizacin de Datos se orienta al conocimiento en profundidad de los datos
que va a manejar la unidad, con el fin de implantarlos de forma ptima.
La Base de Datos es un sistema de mantenimiento de registros basado en
ordenador, con un conjunto de programas que van a controlar el acceso y
recuperacin de la informacin.
MD + SGRD =RO
MD:
SGBD:
B.D.:
MODELO DE DATOS
SISTEMA GESTOR DE BASE DE DATOS
BASE DE DATOS
QUE ES UN MODELO DE DATOS?
Un Modelo de Datos es una representacin grfica orientada a la obtencin de
las estructuras de datos de una forma metdica y a la vez sencilla.
Es un "instrumento" que nos facilita la representacin de las necesidades del
usuario.
MAP - METRlCA Versin 2
56 MODELIZACION DE DATOS
VENTAJAS DE REALIZAR UN MODEW DE DATOS
Las ventajas de realizar una buena modelizacin de datos son, entre otras:
Control de los posibles errores desde el principio o, al menos, darse cuenta
de las deficiencias lo antes posible.
Obtencin de estructuras de datos independientes del entorno fsico.
Mejora del mantenimiento, por tener los datos localizados en las distintas
estructuras.
2.2. OBJETIVOS
El objetivo de la Modelizacin de Datos es el conocimiento profundo de los datos
que se van a manejar y de alguna forma agruparlos en unidades mayores que se
llamarn ENTIDADES. El Modelo de Datos debe ser una fiel representacin del
sistema de informacin objeto de estudio:
La estructura del Modelo de Datos debe ser el reflejo de la estructura del
sistema.
El contenido del Modelo de Datos debe representar el estado fin.al al que
quiere llegar el sistema.
Cualquier cambio en el sistema de informacin se debe reflejar en el
Modelo y viceversa.
En el Modelo de Datos debe aparecer representada toda la informacin
que necesita la unidad.
El Modelo de Datos representa la parte lgica de la informacin. Se dejan
a un lado restricciones del sistema en que se van a implantar los datos.
Por ello, es independiente del entorno fsico y debe proporcionar a los
usuarios toda la informacin que necesitan y en la forma en que la
necesitan.
Por tanto, podramos decir que el objetivo fundamental del Modelo de Datos es
la obtencin de estructuras no redundantes, sin inconsistencias, seguras e ntegras.
Al modelo que surge como primera aproximacin de ese mundo real se le llama
ESQUEMA CONCEPTUAL.
2.3. CONCEPTOS BASICOS
57
Cuando el usuario se plantea una serie de necesidades o cambios para su unidad,
es cuando el analista encargado del anlisis comienza a estudiar los datos. De la
narrativa tradicional o "mundo real" debe llegar grficamente al ESQUEMA
CONCEYfUAL de donde posteriormente podr deducirse el ESQUEMA
INTERNO Y el EX1ERNO (orientado a la mquina y al usuario
respectivamente).
As el esquema conceptual se considera como la "indireccin" entre los otros dos,
como indica la figura.
ESQUEMA INTERNO
_1
ESOUEMA EXTERNO
Cada uno de estos esquemas se podr representar mediante un conjunto de
modelos o tcnicas
58 MODEUZACION DE DATOS
2.3.1. WS TRES ESQUEMAS DE LA ARQUITECTURA DE DATOS
A ESQUEMA EXTERNO.
Visin de los datos por las aplicaciones informticas.
B. ESQUEMA CONCEPTUAL.
Fiel reflejo de la realidad, prescindlendo de los requisitos
informticos.
C. ESQUEMA INTERNO.
Forma de almacenar las estructuras que surgen.
Veamos cada nivel en mayor profundidad.
A ESQUEMA EXTERNO
El Esquema Externo es la visin que de los datos del sistema
tienen las aplicaciones informticas. As por ejemplo, existirn
distintos modelos o esquemas externos (una aplicacin COBOL,
PU, C, etc.) para el mismo esquema conceptual.
B. ESQUEMA CONCEPTUAL
. El Esquema Conceptual permite representar grficamente las
necesidades del usuario, sin tener en cuenta las restricciones del
equipo fsico y lgico propios del sistema en el que se va a hacer
la implantacin.
En este esquema, al analista slo le concierne el aspecto global de
la unidad o rea funcional que se trata, y en l se definen las
entidades de datos y las relaciones entre ellas.
Se realizar un grfico previo mediante el cual se representan las
entidades detectadas en principio y sus relaciones. Posteriores
entrevistas con el usuario podrn aportar mejor informacin y
habr que hacer correcciones sobre el grfico para subsanar
posibles deficiencias o errores.
Una vez realizado este grfico, se realizan sobre l una serie de
refinamientos dependiendo de la tcnica o modelo de
MODELIZACION DE DATOS 59
representacin utilizado. As, los refinamientos afectarn slo a las
estructuras de los datos en el modelo entidad-relacin de CHEN y
tambin al grfico en el caso del Diagrama de Estructura de Datos.
Una vez hecha este mejora, se establecern una serie de pasos para
llegar a estructuras de datos lo ms independientes posibles,
aplicando la tcnica de NORMALIZACION, con el fin de crear
una definicin ms rigurosa de las entidades de partida.
Este esquema debe ser independiente de los condicionamientos de
almacenamiento que se puedan tener.
C. ESQUEMA INTERNO.
El Esquema Interno est orientado a la forma en que se almacenan
las tablas en memoria.
Este esquema depende esencialmente de la memoria disponible y
de los Dispositivos de Almacenamientq de Acceso Directo que se
vayan a utilizar.
El conocimiento de las claves y el uso de ndices predefinidos poda
servir de ayuda para la localizacin ptima de los datos.
Es en este momento cuando se comenzar a pensar en el lenguaje
que se va a manejar y el equipo fsico en el que se implantar. Por
ello se encargar de esta fase una persona conocedora de las
posibles restricciones o limitaciones existentes, que ser el
ADMINISTRADOR del sistema.
La estructura que se va a obtener es, en general, transparente al
usuario.
60
ESQUEMA CONCEPTUAl
I N IEMPLEADO I
I EMPLEADO I
ESQUEMA EXTERNO
APUCACION COBOL
01 EMPl
02 EMPNO PIC X(6)
02 DEPTNO PIC X(4)
02 DEPTDESC PIC X(20)
TECNICA CHEN
TECNICA DIAGRAMA
ESTRUCTURA DE DATOS
APUCACION PUl
Del 1 EMP
2 EMP CHAR (6)
2 SAL AXED BIN (31)
(No intorell8do en otros datos de empleado)
ESQUEMA INTERNO
STORED EMP lENGTH .18
(No intorall8do en Departamento)
PREFIX TYPE. BYTE (6), OFFSET. O
EMP -rvPE .BYTE (6), OFFSET -6, INDEX EMP
NOM*TYPE. BYTE (15), OFFSET. 12
DIR .TYPE BYTE (10), OFFSET. 27
2.4. DEFINICIONES
Las tcnicas de Modelo de Datos que se tratarn, Modelo entidad-relacin de
CHENy Diagrama de Estructura de Datos, varan en la filosofa de la concepcin
del Esquema Conceptual y grficamente en los iconos que utilizan.
En la figura se representan grficamente ambas tcnicas:
MODELlZACION DE DATOS
..................
CM'"
..........
DI DATOS
61
A pesar de ser distinta la forma de representacin. vamos a ver que representan
la misma informacin.
Antes de ello, vamos a pasar a definir una serie de trminos vlidos para
cualquiera de las tcnicas utilizadas:
ENTIDAD: Representan objetos, personas... sobre las que se quiere guardar
informacin por ser relevante para nuestro sistema.
Un conjunto de entidades con las mismas caractersticas es lo que
forma un Tipo de Entidad.
As, por ejemplo, el Tipo de Entidad EMPLEADO contendr a
PEPE, JUAN... que son las Entidades que lo forman, con todas sus
caractersticas propias.
El tipo de entidad, internamente, se va a representar por medio de
una TABLA.
A partir de ahora se utilizarn indistintamente los trminos entidad
y tipo de entidad.
MAP Metodologa METRlCA Versi6n 2
62
ATRIBUTO:
Cada Tipo de Entidad tendr una serie de cara.ctersticas
que sern necesarias para describirla completamente. Cada
una de esas caractersticas van a ser los atributos de la
Entidad. En algunas ocasiones se llaman ELEMENTO o
CAMPO.
Ms formalmente, se puede definir un atributo de una
entidad como una unidad bsica e indivisible de informacin
acerca de dicha entidad, que sirve para identificarla o
describirla. Ejemplo: NOMBRE DEL EMPLEADO, DNI.
RELACION: Es la conexin que va a existir entre tipos de entidades.
TABLA: Representacin fsica de un Tipo de Entidad. Como se ver ms
adelante, un Tipo de Entidad podr dar lugar a una o varias tablas.
La informacin que contienen estar dispuesta en dos dimensiones.
FILA: Conjunto de atributos de una entidad. Se puede llamar
OCURRENCIA o TUPLA.
COLUMNA: Atributo elegido para el conjunto de entidades de un Tipo
de Entidad.
GRADO DE UNA TABLA: Nmero de columnas de una tabla.
CLAVE: Atributo o conjunto de atributos concatenados perteneciente al
mismo tipo de entidad que hacen nico el acceso a una entidad u
ocurrencia de la tabla, es decir, que determinan de forma nica una
entidad.
MODEUZACION DE DATOS 63
De la tabla que origina esa entidad alguno de los atributos debe
permitirnos el acceso nico a una fila, y puede ser un atributo o
concatenacin de atributos del dominio.
En un principio podemos pensar en la existencia de varias claves
sobre la misma tabla. Al conjunto de todas estas posibles claves se
les va a llamar, CLAVES CANDIDATAS, algunas de ellas pueden
no servir por no darnos una nica ocurrencia sobre la tabla
Una vez seleccionada la clave, podremos ver si est compuesta por
un nico atributo: CLAVE SIMPLE, o por un conjunto de atributos
CLAVE MULTIPLE o CONCATENADA
Otro concepto importante es el de CLAVE AJENA, esto es:
"Atributo de una tabla que es clave en otra".
Ser muy importante su localizacin para evitar inconsistencia de
la informacin contenida en las estructuras de datos: Integridad
Referencial.
OCURRENCIA DE
ENTIDAD: Cada uno de los posibles valores reales que puede tomar la clave
de una entidad. Se entiende por valor real aquel que tiene
existencia propia dentro del sistema en estudio.
CARDINALIDAD
DE LA
RELACION: Representa la participacin en la relacin de cada una de las
entidades afectadas, es decir, el nmero de las ocurrencias
de una entidad que se relacionan con ocurrencias de la otra
entidad.
Conceptualmente, se pueden identificar tres clases:
(1,1) Una ocurrencia de una entidad con una
ocurrencia de la otra entidad.
Por ejemplo, en nuestro contexto cultural, un
hombre slo est casado con una mujer y
viceversa.
(l,m) Una ocurrencia de una entidad con varias
ocurrencias de la otra entidad.
64
(m,n)
2.5. ESTRATEGIAS DE DISEO
Por ejemplo, una Unidad tiene varios
empleados y cada empleado est asignado
exclusivamente a una Unidad.
Varias ocurrencias de una entidad con varias
ocurrencias de la otra entidad.
Por ejemplo, un paciente puede tomar varias
medicinas y una medicina puede ser tomada por
distintos pacientes.
TOP-DOWN: "De arriba a abajo". Partimos de lo general para ir llegando
al detalle.
El usuario tiene una serie de necesidades y se va a llegar a
las estructuras de datos a implantar.
Se puede suponer que no existe nada hecho, esto es, ficheros
en uso que podemos aprovechar y por ello partimos de las
nuevas necesidades.
~ 1 I =o I ...
MODELlZACION DE DATOS 65
BOTfOM-UP: "De abajo a arriba". Lo normal es que ya se est trabajando
con una serie de ficheros y lo que quiere el usuario es
mejorar o modificar lo existente por ampliacin de los
servicios, por ejemplo.
.
USUARIO
ANAUSTA
ADMINISTRADOR:
NECESIDADES NUEVAS
DE USUARIO
2.6. MODEW CONCEPTUAL
2.6.1. INTRODUCCION
INDEPENDENCIA DEL ENTORNO FISICO
El hecho de realizar el Modelo de Datos, depurarlo y llegar a estructuras
independientes, no exige pensar en ningn momento en la Base de Datos
que se va a utilizar. Por ello se debe llegar a la forma ms depurada de
ese modelo y luego que sea el Administrador del Sistema el que se
encargue de optimizar su implantacin de acuerdo con las reglas que deba
cumplir la Base de Datos elegida. De esta implantacin ptima depender
el buen funcionamiento del manejo de los datos.
MAP - Metodologfa METRICA Versin 2
66 MODELIZACION lOE DATOS
MODELOLOGIOO
AE1ACIOHAI.
UTILIZACION EN LA METODOLOGIA
A continuacin se describirn dos tcnicas para construir el modelo
conceptual:
Modelo Entidad-Relacin de CHEN.
La derencia fundamental entre ambas es la existencia en el Modelo
Entidad-Relacin de relaciones n-arias (entre n entidades
simultneamente), esto hace que sea un modelo ms "cercano" a la
representacin del mundo real y por ello es ms aconsejable su utilizacin
cuando se quiere representar el modelo de iDIormacin del sistema a muy
alto nivel, como es el caso de un Plan de Sistemas. Este es el criterio que
se ha seguido en la Metodologa METRICA Versin 2: utilizar el Modelo
Entidad-Relacin de CHEN en la Fase Ode la Metodologa y el Diagrama
de Estructura de Datos en las Fases Posteriores.
Por otra parte, excepto la diferencia apuntada anteriormente, ambas
tcnicas siguen los mismos criterios en cuanto a construccin, por lo cual
se ha unificado la descripcin de dichos criterios en un slo apartado.
2.6.2. MODEW ENTIDAD-RELACION DE CHEN
67
Propuesto por CREN, es un Modelo N-ARIO, es decir, que las relaciones
pueden asociar una, dos o ms entidades. Se puede hablar de relaciones:
UNITARIAS:
BINARIAS:
TERNARIAS:
Una entidad consigo misma
Entidades relacionadas dos a dos.
Relacin entre tres entidades.
Los iconos utilizados en los grficos son:
AElACION fEAClAAIA
La cardinalidad se representa con un nmero cerca de la entidad y
representa el nmero de veces que sta puede aparecer. Se puede poner
la mnima y la mxima.
Para CREN existen dos tipos de entidades representables:
ENTIDAD REGULAR.
Aquella sobre la que se puede definir la clave primaria dentro de
sus propios atributos, es decir, aquellas entidades que se identifican
por s mismas.
ENTIDAD DEBIL.
Con sus atributos propios no se' puede encontrar la clave, por estar
asociada a otra entidad.
Se representan tanto grficamente como mediante la clave de esta
entidad, que est formada por:
La Clave de la entidad de la cual dependen.
Un atributo identificativo de la ocurrencia de la entidad
dbil.
ENTIDAD DEBlL
(COD-EMP',NOMBRE,OIR,ONI) ICOD-EMP",N-HIJO' ,NOM-Hl
REFINAMIENTO DEL MODELO ENTIDAD-RELACION DE CREN
Al modelo construido segn la tcnica de CREN, se le aplican una serie
de refinamientos sucesivos, mediante los cuales se obtienen un conjunto
de tablas. Estas tablas sern posteriormente normalizadas aplicando las
tcnicas de NORMALIZACION que se estudiarn ms adelante.
La figura siguiente representa grficamente el procedimiento a seguir para
refinar el modelo de CREN.
I
OBJETOS CClNCEPTUALES
I
T......
I
M{..
.
Q.AVE:.. CUV...

ElIb,&IrI el CLAVa.

Al ...trib A' Q.AVE:&

.
e.:a.b.IIl.1b 8.",1b e) ClAVE:. CCOMPlJistAI
Ala.trib A' ClAYE:.
El(b.PiJeCl,AVE:b
.
Q-..b.bCI ClAVE:a,b (COtoI"UESTA)
M ...... lIlo.. N
.
"'111'"
A{.... A)a.AVE:a
8(btrib8)QA\'E:b
D(d.'''DJa.AVE:d
C(a,b,dAlril C) Q.AVE:..b.61COMf'UESTA,
CU"..
2.6.3. DIAGRAMA DE ESTRUCTURA DE DATOS

69
Los Diagramas de Estructura de Datos tienen los siguientes elementos:
ENTIDAD: Se representa grficamente mediante un rectngulo.
RELACION ENTRE
ENTIDADES: Una lnea recta que une las entidades que estn
relacionadas. Esta lnea puede terminar en un tridente
o una flecha para indicar una cardinalidad de tipo m.
CARACTERISTICAS DEL DIAGRAMA DE ESTRUCTURA DE DATOS
Es un modelo binario, es decir, permite representar grficamente
las relaciones o asociaciones entre pares de entidades.
Se consideran slo relaciones del tipo (l,m), procedindose para los
otros tipos de relaciones, del modo siguiente:
En el caso de las relaciones de cardinalidad (1,1), se
agrupan las dos entidades en una sola, aadindose los
atributos de una entidad a la otra.
En el caso de relaciones de cardinalidad (m,n), se crea una
entidad auxiliar que sirve de nexo entre las dos entidades
iniciales, crendose as dos relaciones (l,m).
Un ejemplo de esto puede verse en la figura.
Dada la funcin de nexo que cumple esta entidad auxiliar, puede no tener
existencia real, por lo que pueden existir dificultades a la hora de
nombrarla, en este caso se recomienda denominarla como "Enlace Entidad
l/Entidad 2".
La clave de este entidad de enlace estar formada por la concatenacin
de las claves de cada una de las entidades originales.
En una relacin de cardinalidad (l,m) entre dos entidades, la
entidad en el extremo 1, se denomina MAESTRA, 'y la entidad en
el extremo M, se denomina DETALLE.
RELACIONES OPCIONALES Y EXCLUSIVAS
Sea una relacin entre dos entidades A y B, siendo A la entidad maestra
y B la entidad detalle.
Si para toda ocurrencia de A debe existir siempre al menos una
ocurrencia de B asociada, y a la inversa, para una ocurrencia de B
siempre existe una ocurrencia de A asociada, se dice que la
relacin es OBliGATORIA en ambos extremos.
Si para toda ocurrencia de A, pueden existir o no, una o varias
ocurrencias de B asociadas, pero para una ocurrencia de B siempre
ha de haber una ocurrencia de A asociada, se dice que la relacin
es OPCIONAL en la entidad maestra y OBliGATORIA en la
entidad detalle.
Si para una ocurrencia de A debe existir siempre al menos una
ocurrencia de B asociada, y para una ocurrencia de B puede existir
o no una ocurrencia de A asociada, esta relacin es
OBliGATORIA en la entidad maestra y OPCIONAL en la
entidad detalle.
Si para una ocurrencia de A puede existir o no una ocurrencia de
B asociada, y para una ocurrencia de B puede existir o no una
ocurrencia de A, esta relacin es OPCIONAL en ambos extremos.
Las relaciones opcionales en la entidad detalle se representan como indica
la figura
Se dice que unas relaciones entre varias entidades son EXCLUSIVAS, si
la existencia de una de esas relaciones entre dos entidades implica la no
existencia de las otras relaciones, como es el caso de la figura
2.6.4. FASES EN LA CONSTRUCCION DEL MODELO CONCEPTUAL
1. Identificar las entidades dentro del sistema
Para identificar las entidades el analista deber conocer el
funcionamiento del sistema en estudio. Para ello, deber basarse
principalmente en:
Reuniones con los usuarios implicados.
Estudio de la documentacin existente sobre el
funcionamiento de dicho sistema.
Estudio de las necesidades de informacin (reflejadas en el
anlisis de requisitos del sistema).
Estudio de los principales tipos de informacin manejados
por sistema actual.
Para ir encontrando las diversas entidades, servir de ayuda pensar
en:
Objetos reales (Mquinas, Edificios. Almacenes...).
Personas (Empleados, Funcionarios,...)
Actividades del sistema (Licencias, Albaranes,...)
Objetos abstractos (Categoras de personal,...)
2. Determinar las claves o identificadores de las entidades
73
Para determinar las claves, se obtendrn aquellos atributos que
identifiquen unvocamente cada ocurrencia de cada entidad. Si para
una entidad concreta hubiera varios, se elegir uno de ellos.
Lgicamente, este atributo o conjunto de atributos que constituyen
la clave, no podr tener valores sin informacin (nulos), ya que esto
no permitira determinar claramente una ocurrencia de entidad.
3. Establecer las relaciones entre las entidades. describiendo el grado
de las mismas.
Para establecer las asociaciones o relaciones entre entidades, se
estudia cada una de las asociaciones de una entidad con las dems
entidades identificadas, para ver si dichas asociaciones tienen
sentido e importancia para el sistema que se estudia.
Para el conjunto de relaciones que se haya obtenido, se estudiar
su cardinalidad.
Asimismo, en el caso del Diagrama de Estructura de Datos, se
estudiar si dicha relacin es opcional o si es exclusiva.
4. Dibujar el modelo de datos
Se dibujar el diagrama, utilizando los smbolos que se han
descrito.
5. Identificar y describir los atributos de cada entidad
Para identificar los atributos de cada entidad, habr que tener en
cuenta todas aquellas propiedades de cada entidad en las que el
sistema tenga inters.
6. Verificaciones
Se realizarn las verificaciones sobre el diagrama, eliminando del
mismo las relaciones que sean redundantes. Una relacin o
asociacin ser redundante si puede expresarse exactamente por
medio de una combinacin de varias asociaciones.
Es conveniente ser prudente a la hora de suprimir las relaciones
redundantes dado que su existencia puede obedecer a
especificaciones propias del sistema.
Para ilustrar esto ltimo supongamos el ejemplo de la figura.
En la figura anterior si todos los empleados pertenecen a un
servicio y todos los servicios a un departamento, la asociacin
directa de Departamento/Empleados es redundante.
En la figura siguiente, sin embargo, si se da la especificacin o
requisito de usuario de que un empleado puede trabajar en un
departamento sin pertenecer a l (en comisin de servJicio) esta
asociacin no sera redundante.
Por ltimo es conveniente transmitir una nota de tranquilidad con
respecto al diseo resultante, dado que el mismo ser validado y
contrastado a posteriori.
2.7. MODEW LOGICO: NORMALlZACION.
2.7.1. OBJETIVOS
Reducir las inconsistencias y redundancias de los datos.
Facilitar el mantenimiento de los datos y programas.
Evitar anomalas en operaciones de manipulacin de datos.
Reducir el impacto de los cambios en los datos.
2.7.2. CONCEPTOS BASICOS
75
El resultado del anlisis relacional de datos ser un conjunto de tablas
normalizadas o "relaciones" en el que se representarn todos los datos del
sistema.
El objetivo ser obtener un modelo lgico normalizado, que represente
"ENTIDADES NORMALIZADAS" Ylas "INTERRELACIONES" entre
ellas. Este modelo se comparar con el que se obtuvo mediante la tcnica
del Diagrama de Estructura de Datos y de esa comparacin se obtendr
el modelo lgico de datos definitivo del sistema.
Es conveniente matizar que las entidades normalizadas obtenidas pueden
diferir de las entidades que se han identificado inicialmente de una
manera subjetiva.
A continuacin se definen una serie de conceptos que sern tiles a la
hora de normalizar.
Dependencia funcional: Un atributo B depende funcionalmente de otro
atributo A, de la misma entidad si a cada valor de A le corresponde slo
un valor de B. Ejemplo: En la entidad EMPLEADO cuyos atributos son:
Nmero de Empleado (clave).
Nombre.
Categora.
Direccin.
Los atributos Nombre, Categora yDireccin dependen funcionalmente de
la clave Nmero de Empleado.
Dependencia funcional completa: Un atributo B tiene dependencia
funcional completa de un grupo de atributos A de la misma entidad, si B
depende funcionalmente de A pero no de ningn subconjunto obtenido de
los posibles atributos que forman A
Dependencia transitiva: Sean A, B Y C tres atributos (o grupos de
atributos) de una relacin. Si B depende funcionalmente de A y C de B,
pero A no depende funcionalmente de B se dice que C depende
transitivamente de A
Estas definiciones previas nos proporcionan un medio de definir el
procedimiento de normalizacin, y su sentido quedar claramente
explicado en el captulo siguiente, mediante un ejemplo.
2.7.3. PROCEDIMIENTO DE NORMALIZACION
Primera Forma Normal
Se dice qye una entidad est en primera forma normal (lFN) si no
contiene trolP0s repetitivos es decir. todos los atributos dependen
funcionalmente de la clave.
Ejemplo: sea un documento o albarn de pedidos de una unidad, que se
identificar inicialmente como la ENTIDAD PEDIDO, que contiene los
siguientes atributos:
Cdigo del Pedido.
Fecha del Pedido.
Cdigo del Proveedor.
Nombre del Proveedor.
Direccin del Proveedor.
Cdigo del material.
Descripcin del material.
Cantidad pedida del material.
Precio unitario del material.
La clave principal es: Cdigo del Pedido.
Evidentemente no se cumple la primera forma normal, ya que para un
mismo cdigo de pedido hay varios cdigos de material, es decir, el cdigo
de material no depende funcionalmente del cdigo de pedido.
MODEUZACION DE DATOS TI
Solucin: una vez identificados los atributos que no dependen
funcionalmente de la clave, se formar con ellos una nueva entidad y se
eliminarn de la antigua. La clave principal de la nueva entidad estar
formada por la concatenacin de uno o varios de sus atributos y la clave
principal de la antigua entidad.
En este caso quedar:
PEDIDO 1:
Cdigo del Pedido (K)
Fecha del Pedido.
PEDIDO 2:
Cdigo del Pedido (1)
Cdigo del Material (2)
Descripcin del material.
Cantidad pedida del Material.
Precio unitario del Material.
(K) indica que este atributo es clave principal nica.
(1) Y(2) indican que estos atributos estn concatenados para formar la
clave principal.
Se&Unda Forma Normal
Se dice Que una entidad est en Segunda Forma Normal (2FN) si est en
1FN y cada atributo Que no pertenezca a la clave tiene una dependencia
funcional completa de la clave.
Dicho de otra forma, si cada uno de los atributos de la entidad depende
de toda la clave.
Ejemplo: En la entidad PEDIDO 2, se observa que los atributos
"Descripcin del Material" y "Precio Unitario del Material" no tienen una
dependencia funcional completa de la clave, sino que la tienen slo de una
parte de la misma: "Cdigo del Material"
78
Solucin: Una vez identificados los atributos que no dependen
funcionalmente de toda la clave, sino slo de parte de la misma, se
formar con ellos una nueva entidad y se quitan de la antigua. La clave
principal de la nueva entidad estar formada por la parte de la antigua de
la que dependen funcionalmente.
PEDID02l:
Cdigo del pedido (l)
Cantidad Pedida del Material
Tercera Forma Normal
PEDIDO 22:
Cdigo del Material (K)
Descripcin del Material.
Precio Unitario.
Una entidad est en tercera forma normal (3FN) si est en segunda forma
normal y cada atributo que no pertenezca a la clave no depende
transitivamente de dicha clave; en otras palabras, si cada uno de los
atributos de la entidad dependen slo de la clave.
Ejemplo: En la entidad PEDIDOl, cuyos atributos se repiten a
continuacin:
PEDIDOl:
Cdigo del Pedido (K)
Fecha del Pedido.
se observa, revisando la defmicin dada anteriormente, la siguiente
dependencia transitiva:
Para un Cdigo del Pedido (A) hay un nico Cdigo del Proveedor
(B), es decir, B depende funcionalmente de A
Para un Cdigo del Proveedor (B), hay un nico Nombre del
Proveedor y Direccin del Proveedor (C), es decir, C depende
funcionalmente de B.
Para un Cdigo del Proveedor (B), hay varios Cdigos del Pedido'
(A).
Se observa, pues, que C depende transitivamente de A. Esta entidad
PEDID01 no est en 3FN.
Solucin: Una vez identificados los atributos que dependen de otro
atributo distinto de la clave (las dependencias transitivas), se formar con
ellos una nueva entidad y se quitarn de la antigua. La clave principal de
la nueva entidad ser el atributo del cual dependen. Este atributo, en la
entidad antigua, pasar a ser una clave ajena.
Se obtendr pues:
PEDIDOll: Cdigo del pedido (K).
Fecha del Pedido.
PEDID012: Cdigo del Proveedor (K)
Productos Obtenidos: Siguiendo el procedimiento de Normalizacin, se
han obtenido, a partir de la entidad PEDIDO, las siguientes entidades en
tercera forma normal:
PEDIDOll: Cdigo del Pedido (K)
Fecha del Pedido.
PEDIDO12: Cdigo del Proveedor (K)
PEDID021: Cdigo del Pedido (1)
Cantidad Pedida del Material.
80
PEDID022: Cdigo del Material (K)
Descripcin del Material.
Precio Unitario.
Se puede observar que a partir de la entidad no normalizada PEDIDO se
han obtenido cuatro entidades normalizadas. Las asociaciones entre ambas
vienen dadas mediante las claves comunes.
Se nombrarn las entidades normalizadas obtenidas, atendiendo a su
significado. En el ejemplo anterior: PEDID011 se llamar PEDIDO;
PEDID012 se llamar PROVEEDOR; PEDID022 se llamar
MA'!ERIAL y PEDID021 se llamar PEDIDO-MA'!ERIAL.
2.7.4. COMPARACION ENTRE EL DIAGRAMA DE ESTRUCTURA DE
DATOS Y LA ESTRUCTURA DE REGISTROS NORMALIZADOS
A partir de las entidades normalizadas obtenidas mediante la tcnica de
normalizacin, se puede obtener un Diagrama de Estructura de Datos
(DED), siguiendo el procedimiento que se indica a continuacin:
Cada entidad normalizada es una entidad del DED.
Las entidades normalizadas con clave compuesta se representan como
"entidades detalle" de las entidades que tienen las partes de esta clave
compuesta como clave primaria (PEDIDOn es detalle de PEDIDO12 y
PEDIDO 21 es detalle de PEDID022). (Recordar que una entidad detalle
es aquella que, en una conexin (1, m), entre dos entidades, est en el
extremo m).
Las entidades normalizadas con claves ajenas son detalle de las entidades
que tienen esa clave ajena como clave primaria (PEDID011 es detalle de
PEDID022).
Una aproximacin sistemtica para resolver las inconsistencias entre
ambos modelos ser la siguiente:
1. Revisar los nombres de las entidades, dado que al normalizar
puede ocurrir, como se ha dicho, que se creen entidades diferentes
de las existentes inicialmente.
2. Tener en cuenta que pueden aparecer entidades diferentes como
consecuencia de la diferente aproximacin al estudio de los datos
MAP -.Metodologa METRlCA Versin 2
81
seguida por ambas tcnicas. Resolver la conveniencia de incluir
estas entidades diferentes a la luz de los requisitos de usuario.
3. La tcnica del DED muestra una serie de smbolos, tales como
relaciones exclusivas o relaciones opcionales, que no aparecen en
el modelo normalizado. Dichas diferencias sern resueltas a la vista
de los requisitos de usuario.
2.S. REGLAS DE INTEGRIDAD
Para asegurar un acceso eficiente a los datos del sistema, es necesario tener en
cuenta las siguientes reglas de integridad:
INTEGRIDAD DE ENTIDAD
"La clave principal no puede tener valor nulo", es decir, tiene que contener dato.
Si se permite valor nulo, poda existir ms de un atributo con ese mismo valor,
con lo cual el acceso puede no ser nico.
INTEGRIDAD REFERENCIAL
"Si existe CLAVE AJENA, el valor ha de ser igual al atributo clave o bien ser
nulo".
Si se da de baja, habr que buscarlo en cualquier otro sitio que pueda aparecer
y si no se da de baja al registro completo, al menos se pondr el valor nulo a ese
atributo.
2.9. OPTIMIZACION DEL MODEW DE DATOS
Una vez obtenido el conjunto de tablas o entidades normalizadas en 3FN, es
necesario asegurar que este modelo de datos en 3FN satisface los requisitos de
rendimiento exigidos para el sistema, en cuanto a tiempos de respuesta.
En general, y como se indica en la Gua de Referencia de la Metodologa, se
estudiar la adecuacin del modelo de datos en 3FN a los requisitos de
rendimiento estipulados por las transacciones consideradas como crticas dentro
del sistema en desarrollo.
Este estudio puede llegar a la necesidad de desnormalizar el modelo de datos,
con el fin de reducir o simplificar el nmero de accesos a la base de datos, para
las transacciones crticas consideradas. Para ello se seguirn las recomendaciones
que a continuacin se indican:
Introducir redundancias en los elementos de datos.
Introducir elementos repetitivos.
Redefinir o aadir relaciones entre entidades para hacer ms directo el
acceso entre entidades.
Dividir entidades.
Modificar el tratamiento realizado por las transacciones crticas.
Combinar entidades, si los accesos para ellas son frecuentes dentro de la
misma transaccin.
Definir claves secundarias o ndices para permitir caminos de acceso
alternativos.
En cualquier caso, se ha de tener presente que la desnormalizacin puede
implicar problemas y anomalas en las operaciones de. manipulacin de datos. Por
esto, la decisin de proceder a la desnormalizacin ser competencia del
Administrador de la Base de Datos (si lo hubiera) o de la persona responsable
de la gestin de los datos dentro de la instalacin.
2.10. UTILlZACION DE LAS TECNICAS EN LA METODOLOGIA METRICA
VERSION 2
Como se ha sealado anteriormente, se recomienda utilizar el modelo entidad-
relacin de CHEN en el caso de que se quiera representar el modelo de
informacin del sistema a muy alto nivel, debido a su mayor riqueza
representativa (considera relaciones n-arias), por ello se utiliza este modelo en:
FASE O:
Tarea PSI 4.1:
Diseo del modelo conceptual de datos.
Por otro lado el Diagrama de Estructura de Datos se utiliza en las siguientes
actividades: .
MAP - MetodolOga METRICA Versin 2
FASE 1: ANALISIS DE SISTEMAS.
Tarea ARS 3.2: Diseo del Modelo Lgico Actual de Datos.
Tarea EFS 2.1: Construccin del Modelo de Datos.
La tcnica de normalizacin se utiliza, dentro del mdulo EFS, en la Tarea EFS
2.2. Normalizacin del Modelo de Datos.
Por ltimo, las recomendaciones para optimizar el modelo de datos se utilizarn,
dentro del mdulo DTS ("Diseo Tcnico del Sistema") en la Tarea DTS 2.2
("Optimizacin del modelo fsico de datos").
HISTORIA DE LA VIDA DE LAS ENTIDADES
3. HISTORIA DE LA VIDA DE LAS ENTIDADES
INDICE
3.1. IN1RODUCCION 89
3.2. OBJETIVOS DE LA TECNICA 89
3.3. DESCRIPCION DETALLADA DE LA TECNICA .. . . . . . . . . .. 90
3.4. PASOS EN LA CONSTRUCCION DE LA HISTORIA
DE LA VIDA DE LAS ENTIDADES (HVE) 97
3.5. INTERRELACION CON OTRAS TECNICAS 107
3.6. UTILIZACION DE LA TECNICA EN LA
METODOLOGIA METRICA VERSION 2 . . . . . . . . . . . . . . . .. 107
87
HISTORIA DE lA VIDA DE lAS ENTIDADES
3. HISTORIA DE LA VIDA DE LAS ENTIDADES
3.1. INTRODUCCION
89
La tcnica de la Historia de la Vida de las Entidades (HVE) permite describir
la evolucin de las entidades de datos del sistema. Esta visin evolutiva de los
datos sirve de complemento a las representaciones del sistema efectuadas hasta
ahora:
La visin esttica de los datos, que muestra las interrelaciones entre las
entidades de datos del sistema, proporcionada por el Diagrama de
Estructura de Datos (DED).
La visin dinmica de los datos, que muestra el proceso de los flujos de
datos, proporcionada por los Diagramas de Flujo de Datos (DFD).
La elaboracin de las HVE se basa en las entidades de datos, identificadas y
descritas en los Diagramas de Estructura de Datos, y en las transacciones o
eventos del sistema, identificados en los Diagramas de Flujo de Datos. Por este
motivo las HVE son un poderoso instrumento para verificar la exactitud de dichos
modelos (DED y DFD) Ygarantizar la coherencia entre las tres visiones del
sistema.
3.2. OBJETIVOS DE LA TECNICA
Obtener un registro de la secuencia de los cambios de las entidades en el
tiempo.
Obtener los requisitos de tratamiento de las entidades.
Establecer los estados posibles de las entidades para que tengan lugar
transacciones externas, as como los cambios de estado de las entidades
originados por dichas transacciones.
Poner de manifiesto las posibles interacciones que producen los eventos
o sucesos.
90 HISTORIA DE LA VIDA DE LAS ENTIDADES
3.3. DESCRIPCION DETALLADA DE LA TECNICA
ELEMENTOS
En la tcnica de la Historia de la Vida de las Entidades se consideran los
siguientes elementos:
Entidades de
datos: Cualquier objeto sobre el que el sistema guarda informacin.
Las entidades de datos estn caracterizadas por sus
atributos.
Se construir una HVE para cada entidad del sistema.
Mediante la HVE se describe la "sucesin de eventos" que
afectan a dicha entidad y cuyos efectos son, en lneas
generales: .
Crear o dar de alta la entidad en el sistema.
Modificar cualquier aspecto o caracterstica de la
entidad, es decir, modificar sus atributos.
Borrar o dar de baja la entidad del sistema.
Eventos: Cualquier suceso que activa a un proceso que actualiza datos
del sistema. Se pueden considerar tres tipos de eventos:
Eventos producidos en el exterior del sistema, por
ejemplo, solicitudes de altas o modificaciones de los
datos almacenados en el sistema. Estos eventos
"ponen en marcha" los procesos que realizan dichas
funciones de actualizacin.
Eventos peridicos: se identifican en los Diagramas
de Flujos de Datos, estudiando aquellos procesos que
actualizan los almacenes de datos, sin un estmulo
externo, con una periodicidad temporal. Por ejemplo:
En un sistema donde las entidades a las que no se
haya accedido en cierto tiempo, se archiven, se
identificara el evento peridico "Archivar entidades".
HISTORIA DE lA VIDA DE lAS ENTIDADES 91
Otro ejemplo sera la actualizacin peridica de los
valores de determinados atributos de una entidad.
Eventos reconocidos internamente, por ejemplo,
prerrequisitos que el sistema exige para activar el
proceso de actualizacin.
Los eventos se asocian a las entidades a las que afectan por medio de la
correspondencia existente entre los almacenes de datos representados en los DFD
y las entidades de datos del sistema, representadas en los DED:
Un almacn de datos corresponde a un conjunto completo de entidades
de datos (una o ms).
Efectos:
Los efectos describen el resultado de la accin de un evento sobre una entidad
determinada.
Un evento puede tener diferentes efectos sobre distintas entidades de datos, as
por ejemplo:
El evento: SOUClTUD APERTURA CUENTA BANCARIA tiene los efectos:
CREA ENTIDAD CUENTE (o lo actualiza si el cliente ya existe).
CREA ENTIDAD CUENTA.
Asimismo, un mismo evento puede tener diferentes efectos sobre la misma
entidad de datos, en diferentes tiempos. Por ejemplo:
Dentro de un Banco se tiene la entidad de datos CUENTA.
El evento SOLICITUD DE TRANSFERENCIA tiene lugar entre dos
ocurrencias de la entidad cuenta.
Para una ocurrencia hace un apunte en el DEBE.
Para la otra ocurrencia hace un apunte en el HABER.
92 HISTORIA DE LA VIDA DE LAS ENTIDADES
Los tres grandes tipos de efectos sobre una entidad son:
1: Insertar.
M: Modificar.
B: Borrar.
En el diagrama se representan los eventos y el efecto sobre la entidad de que se
trata dentro de una caja.
Nodo:
En la representacin grfica de la HVE, se utilizan los nodos como medio de
agrupar un conjunto de eventos que afectan a la entidad y estructurar as mejor
la figura. As por ejemplo, se podra introducir un nodo que agrupase a los
eventos que crean la entidad, otro nodo que agrupase a los eventos que la
modifican y otro que agrupase a los eventos que la borran.
Cajas vacas:
Representan el caso en que ningn evento afe<;ta a la entidad. Son tiles para
simbolizar, conjuntamente con la estructura de seleccin que se estudiar ms
adelante, los casos excepcionales en que una entidad puede verse afectada por un
evento determinado.
REPRESENTACION GRAFICA
Las HVE se representan de forma jerrquica, comenzando, en la parte superior
del diagrama, con la entidad cuyo ciclo de vida se va a representar.
A continuacin, dependiendo jerrquicamente de la entidad, se representan los
eventos que actan sobre la entidad y los efectos que tienen dichos eventos.
Como se ha indicado, se pueden introducir nodos para estructurar mejor la figura.
En la HVE se tienen los siguientes tipos de estructura:
Secuencia: Indica la sucesin temporal de los eventos sobre la entidad de que
se trata y se representa mediante cajas que se leen de izquierda a
derecha.
HISTORIA DE LA VIDA DE LAS ENTIDADES 93
Seleccin:
Iteracin:
Representa diferentes eventos alternativos en un momento dado
del ciclo de la vida de la entidad. Se representa mediante un (*).
Representa la repeticin de un evento o un conjunto de eventos
(un nodo) en un momento particular de la vida de la entidad. Se
representa mediante el smbolo: O
En la figura se representan estos tres tipos de estructura.
SEC........
"",...,"'"
SELECCION
Estructuras
paralelas: Este tipo de estructura se utiliza cuando, dentro de la historia de
la vida de la entidad, los eventos ocurren de forma simultnea en
el tiempo, o bien no se puede predecir exactamente su sucesin
secuencial. Esto se representa colocando este tipo de eventos
simultneos debajo de una barra, como indica la figura:
94
OTRAS CONVENCIONES
Salto: Dentro de la Historia de la Vida de la Entidad, existen eventos
cuyo resultado es la alteracin de la vida normal de esta entidad,
de manera que dicha entidad pasa a otro estado, dentro de los que
puede tener.
Por ejemplo, en el caso de la entidad TARJETA DE CREDITO.
Se produce el evento: NOTIFICACION DE PERDIDA DE LA
TARJETA
Cuyo efecto es: BLOQUEO DE LA TARJETA
Si en el caso de 5 das, el titular recupera la tarjeta y lo notifica, se
desbloquea la misma y puede operar normalmente con ella, si no,
se borra la tarjeta y el titular tendra que solicitar otra.
Esto se representa como indica la figura:
Se indica mediante Q: el estado en que se encuentra la entidad y
mediante R el estado a que salta, esto significa que el evento que
sigue en secuencia a la caja sealada con Q, es siempre la caja
sealada con R.
En el caso de que hubiese "saltos" entre varias cajas, se distinguirn
utilizando la notacin QX y RX siendo X un nmero.
Indicadores
de estado: Sirven para determinar el estado de una entidad antes y despus de
ser actualizada por un evento, as como para entender la secuencia
de los acontecimientos y definir los posibles errores del sistema.
La convencin para designar los indicadores de estado es comenzar
con el valor 1 e incrementarlo cada vez que un evento afecta a la
entidad.
96 HISTORIA DE lA VIDA DE lAS ENTIDADES
Para cada caja que indica el efecto de un evento sobre la entidad
de que se trata, se pueden definir una serie de valores de los
indicadores de estado de la entidad, para los cuales dicho evento
puede actuar sobre la entidad.
En el diagrama se representar de la forma X/Y, donde X indica
el o los posibles estados en que se debe encontrar la entidad para
que el evento pueda actuar sobre ella, e Y indica el estado en que
se encuentra la entidad despus de que el evento haya actuado.
En la figura se muestra un ejemplo de los indicadores de estado en
una HVE.
CUENTA
A9R'R
eTA.AB.
4'
TRANSACCION
.13
3.4. PASOS EN LA CONSTRUCCION DE LA HISTORIA DE LA VIDA DE LAS
ENTIDADES.
A continuacin se indican los pasos a seguir en la construccin de las HVE:
1. Identificacin de los eventos.
2. Construccin de la Matriz Entidad-Evento.
3. Construccin de HVE iniciales para todas las entidades.
4. Refinamiento de las HVE.
s. Adicin de los indicadores de estado.
Seguidamente se describirn en detalle cada uno de estos pasos.
Con el fin de clarificar cada uno de los pasos se estudiar el ejemplo siguiente:
El caso en estudio es una empresa de alquiler de vehculos, en la cual se quiere
mecanizar todo el proceso de reservas con el fin de agilizar la tramitacin de las
mismas.
En el mdulo EFS (Estudio Funcional del Sistema) del anlisis del sistema se ha
obtenido el siguiente Diagrama de Flujo de Datos:
IDI I cul'NltI
98
1.
IDENTIFICACION DE WS EVENTOS
El punto de partida para la elaboracin de las HVE ser la identificacin
de los eventos a partir de los DFD. Estos eventos causarn la creacin de
la entidad, su modificacin y, al final, el borrado de la misma.
El cumplimiento de los requisitos establecidos por el usuario, el estudio
de los atributos de las entidades de datos, as como el estudio de los
Diagramas de Estructura de Datos nos servirn de ayuda y comprobacin
de que se han considerado todos los eventos que afectan a las entidades
del sistema.
Para el caso en estudio que estamos siguiendo, a partir del estudio del
DFD representado y de los procesos de asignacin de conductores, se han
detectado los siguientes eventos:
El: Solicitud de reserva.
E2: Solicitud de reserva efectuada por cliente nuevo.
E3: Solicitud de confirmacin de reserva.
E4: Asignacin de un conductor a la reserva.
2. CONSTRUCCION DE LA MATRIZ ENTIDAD-EVENTO
La matriz entidad-evento es una tabla de la forma
EVENTOS
ENTIDADES
................... iiii
:::::::::::::: ::::: :::::1:::::;::::::1:::::1:::::
En las intersecciones fila/columna se coloca el efecto de un evento sobre
la entidad. Dichos efectos pueden ser:
1 (Insertar)
M (Modificar)
B (Borrar)
A la hora de considerar los eventos y sus efectos sobre las entidades ser
de utilidad el estudio de los Diagramas de Estructura de Datos (DED),
dado que permiten estudiar las posibles repercusiones que los eventos que
actan sobre una entidad tienen en las entidades relacionadas con ella, y
viceversa. Un ejemplo de esto lo constituye el caso en que un evento o
suceso, que provoca el borrado de una ocurrencia de una entidad borra,
asimismo, las ocurrencias de otra entidad asociada a la primera.
Para tener en cuenta lo anterior, se recomienda iniciar la representacin
de las HVE, para aquellas entidades que, en el DED, aparecen
representadas con una o varias entidades "maestro" y sin entidades
"detalle". Una entidad "maestro" es aquella que est en el extremo 1, y una
entidad "detalle" es la que est en el extremo n, en una relacin (l:n).
A continuacin se seleccionaran los "maestros" de estas entidades y as
sucesivamente, hasta que se alcanzasen las entidades sin entidad "maestro"
asociada.
Este mtodo, "de abajo a arriba", de estudio de los efectos de los eventos
sobre las entidades, proporciona informacin adicional sobre los posibles
efectos que los eventos que actan sobre la entidad detalle pudieran tener
sobre las entidades "maestro", lo que facilita la construccin de la HVE de
dichas entidades maestro. En la figura siguiente se representa este mtodo.
'OETALLE'
DEASAJOA
ARRIBA
DE ARRIBA
A ABAJO
100
mSTORIA DE LA VIDA DE LAS ENTIDADES
Es conveniente revisar la matriz entidad-evento para comprobar que:
Para cada entidad, hayal menos un evento que la crea.
Se satisfacen todos los requisitos de usuario.
Todos los eventos estn identificados.
La parte de la Matriz entidad-evento para el caso que nos ocupa ser:
EVENTOS
El E2
E3 E4
RESERVA
CONDUCTOR
CLIENTE
en
w
~ .
ffi
. . . .
tt,,tt
I
1: : M : M: :
. . . .
~ ~
. . . .
. . . .
M.
I I
. . . .
.......................................
. . . .
. . . .
. . . .
. . . .
..........- .
I
. . . .
. . . .
. . . .
Donde para completar esta matriz, se han tenido en cuenta los siguientes
requisitos que ha de cumplir el sistema:
Rl: Una vez que se hace la reserva, se asignar un conductor de la
empresa a este sistema.
R2: Una vez que se haya asignado el vehculo se confirmar la reserva
provisional.
3. CONSTRUCCION DE HVE INICIALES PARA TODAS LAS
ENTIDADES.
Para ello se selecciona, de la matriz entidad-evento, una entidad y los
8eventos que la afectan, y se representa grficamente la HVE, ordenando
los eventos segn los tres tipos de efectos (I,M,B), incluyendo selecciones
e iteraciones, dibujando nodos con el fin de estructurar mejor el grfico,
y, en fin, introduciendo saltos y estructuras paralelas, si es preciso.
La HVE obtenida para la entidad reserva, a partir de la matriz construida
en el caso anterior, ser:
El diagrama ilustra la utilizacin de las, cajas vacas dentro de una
estructura de seleccin: Dentro de la solicitud de reserva de alquiler de
vehculos, se indica si se requiere o no un conductor.
En este caso es preciso representar las dos posibilidades, es pues una
estructura de seleccin, una de las posibilidades implica la actuacin del
evento "Asignacin de conductor", la otra posibilidad no implica ninguna
variacin sobre la entidad, por ello se representa mediante una caja vaca.
102
4.
REFINAMIENTO DE LAS HISTORIAS DE LA VIDA DE LA ENTIDAD
Para ello se estudiarn en detalle los atributos que definen a la Entidad
de Datos para ver si todos estos atributos son creados por algn evento.
La Entidad de Datos Reserva, del ejemplo que se est siguiendo, tiene los
siguientes atributos:
RESERVA
N de Reserva
N de Cliente
Categora del vehculo
Fecha de recepcin
Fecha de confirmacin
Fecha de comienzo
Fecha de fin
Conductor requerido/NO
N de conductor
N de factura
(1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
(9)
(10)
Es conveniente plantear las siguientes preguntas para refinar la HVE:
Estn todos los atributos de la entidad creados por algunos de los
eventos identificados hasta ahora?
Parece evidente que todos los atributos, excepto nmero de factura,
han sido creados por los eventos:
Solicitud de Reserva: que introduce en el sistema los
atributos (1) (2) (3) (4) (6) (7) (8).
Confirmacin de Reserva, que introduce en el sistema el
atributo (5).
Asignacin de Conductor, que, en el caso de que se requiera
conductor, introduce en el sistema el atributo (9).
Se introducir pues, en la HVE de la entidad Reserva el Evento:
Envo de factura, que introduce en el sistema el atributo
(10).
La nueva HVE quedara como indica la figura:
103
Otra cuestin a estudiar para completar las HVE es considerar los
posibles cambios que pueden sufrir los elementos una vez que se
han creado. De la consideracin de los posibles cambios surge la
definicin de nuevos eventos.
As por ejemplo, en el caso que nos ocupa se podran considerar
cambios hechos por el cliente en los detalles de la reserva, como
por ejemplo alterar las fechas de comienzo y de fin de la misma,
exigiendo, como requisito del sistema, una confirmacin posterior.
De la consideracin de este nuevo evento:
PETICION DE CAMBIO
se construira la HVE como muestra la figura.
104
Donde se ha dado una estructura de iteracin, dado que los
cambios pueden ocurrir varias veces en el tiempo.
Adems se deben considerar los requisitos del sistema en cuanto al
borrado de las entidades, as por ejemplo, diversas consideraciones
legales o exigencias de usuario podran requerir que se guardase
informacin sobre la entidad durante un determinado tiempo antes
de su borrado. Esto implicara considerar un nuevo evento:
Archivo. En nuestro caso ejemplo existe como requisito de usuario
el guardar informacin sobre la entidad para referencias futuras.
Con esto la HVE sera como indica la figura:
Por ltimo, una vez construidas las HVE de este modo, se
completarn invirtiendo el mtodo de construccin utilizado
anteriormente, es decir, siguiendo los Diagramas de Estructura de
Datos de "arriba a abajo", con el fin de estudiar el efecto que el
borrado de las ocurrencias de las entidades "maestro" t n ~ sobre
las entidades "detalle".
Este efecto se puede resumir del modo siguiente:
No hay ningn efecto, lo que implica que no hay cambios en
la HVE.
Si se borra la entidad "maestro" se borra la entidad "detalle":
los eventos que implican un borrado de la entidad "maestro",
han de figurar en la HVE de la entidad "detalle".
No se puede borrar la entidad "maestro" hasta que no se
haya borrado la "entidad detalle": los eventos que borran la
entidad "detalle" se debern colocar antes del final de la
HVE de la entidad "maestro".
En el caso ejemplo que estamos siguiendo, se tiene la
siguiente ''vista'' del Diagrama de Estructura de Datos.
Si se borra la entidad CUENTE, todas las reservas
asignadas desaparecen. La HVE quedara pues:
106
5.
ADICION DE WS INDICADORES DE ESTADO.
Por ltimo, para completar la HVE se aadiran los indicadores de estado,
como se ha explicado anteriormente.
El ejemplo que se est siguiendo quedara:
3.5. INTERRELACION CON OTRAS TECNICAS.
107
Una vez realizada la Historia de Vida de las Entidades del Sistema, habr que
asegurar la coherencia de la vista del sistema obtenido mediante esta tcnica,
Vista "evolutiva", con las dems vistas del sistema, vista "esttica", obtenida
mediante el Diagrama de Estructura de Datos (DED) y vista "dinmica" obtenida
con el Diagrama de Flujo de Datos (DFD).
Para ello habr que comprobar:
Que existe un proceso dentro de los DFD del sistema que trate cada uno
de los eventos identificados en la HVE.
Que el modelo de datos, representado mediante el DED, permita reflejar
las repercusiones que la actuacin de un evento sobre una entidad tiene
sobre otras entidades del sistema.
Esta interrelacin entre las tres vistas del sistema permite asegurar la consistencia
del anlisis y convierte a la tcnica de la Historia de la Vida de las Entidades en
un poderosa herramienta para asegurar la calidad de dicho anlisis.
VERSION2
Esta tcnica se utiliza, dentro de la metodologa METRICA Versin 2, en los
siguientes puntos:
FASE 2:
Tarea EFS 3.1:
Tarea EFS 3.2:
ANAUSIS DE SISTEMAS
Construccin del Modelo Entidad-Evento.
Consolidacin de los Modelos de Datos y Procesos.
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
r j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
/ j
j
/ j
/ j
/ j
/ j
/ j
r j
/ j
/j
rj
I
j
j
j
j
J
ENTREVISTAS
4. ENTREVISTAS
INDICE
4.1. INTRODUCCION y OBJETIVOS 113
4.2. RECOMENDACIONES DE DESARROLW
113
4.2.1. Preparacin de guiones
4.2.2. Consolidacin de la entrevista
METODOWGIA METRICA VERSION 2 119
111
ENTREVISTAS
4. ENTREVISTAS
4.1. INTRODUCCION y OBJETIVOS
Las entrevistas constituyen el medio de obtener informacin sobre:
Los requisitos de usuario.
Funcionamiento del sistema actual.
Organizacin de la Unidad.
Responsabilidades y funciones de los usuarios.
113
Por esta razn la preparacin y realizacin de las entrevistas juega un papel
primordial en las primeras etapas del desarrollo de sistemas, ya que stas
permitirn sentar las bases sobre las cuales se desarrollar el futuro sistema.
En muchas ocasiones puede ser conveniente sustituir la tradicional entrevista
"cara a cara" con el usuario por reuniones en grupo con un conjunto de usuarios
especializados en las funciones a tratar por el sistema. Esto tiene especial
importancia en el caso de que un sistema abarque distintos sectores de la
Organizacin, como, por ejemplo, distintas unidades que realizan funciones
similares y el objetivo es crear un estndar para uilificar el procedimiento.
Asimismo, otro ejemplo en que ser de utilidad la realizacin de reuniones en
grupo es en la realizacin de un Plan de Sistemas de la Organizacin, dado que
en ese caso se plantean cuestiones como la especificacin de objetivos de la
Organizacin a largo plazo. Las posibles necesidades de informacin, las nuevas
funciones a desarrollar, etc. La realizacin de reuniones en grupo permite
establecer mejor las prioridades y objetivos de la Organizacin.
4.2. RECOMENDACIONES DE DESARROLLO DE ENTREVISTAS
A continuacin se darn unas recomendaciones generales sobre la tcnica de
entrevistas, haciendo nfasis en dos aspectos esenciales de las mismas:
Preparacin de guiones para las entrevistas.
Consolidacin de las entrevistas.
114 ENTREVISTAS
4.2.1. Preparacin de Guiones.
Antes de realizar una entrevista es imprescindible enviar al usuario a
entrevistar, un guin previo sobre los puntos a tratar. Dicho guin ha de
ser suficientemente detallado para cubrir todos los aspectos de inters, y
dar oportunidad al usuario a preparar documentacin sobre el sistema. Sin
embargo debe existir un compromiso en cuanto a la extensin del guin
o cuestionario previo, ya qpe un excesivo detalle en el mismo puede
provocar rechazo por parte de los usuarios.
Es importante elaborar el guin atendiendo al perfil y a las
responsabilidades del usuario a entrevistar. A continuacin, se exponen
una serie de consideraciones sobre los aspectos a tener en cuenta en
funcin de dicho perfil de usuarios:
1.- Entrevistas a los responsables de rea.
1.1.- Funciones que realiza su departamento o grupo.
1.2.- Sistemas de Informacin actuales (ya sean manuales o
mecanizados).
Entradas, salidas, funcionalidad.
1.3.- Relaciones o salidas a otros sistemas, definiendo:
Destino de los datos (departamento o grupo dentro
de un departamento, y si es posible el nombre del
sistema que recibe la salida, cuando sea informa-
tizado).
Datos enviados a otros sistemas.
Medios empleados (papel, intercambio electrnico de
datos, diskette, cinta magntica).
Frecuencia (tiempo real, varias veces al da,
diariamente, semanalmente, etc.).
1.4.- Nivel de satisfaccin tcnica con el sistema de informacin
actual. Se establecer una evaluacin global sobre los
siguientes aspectos:
Disponibilidad de los sistemas de informacin.
Tiempos de respuesta.
Facilidad de uso.
MAP-. Metodologa METRlCA Versi6n 2
ENTREVISTAS 115
La evaluacin se har de acuerdo a la siguiente escala:
1.5.- Identificar al resto de los usuarios del departamento o grupo
que debern participar en futuras entrevistas.
Al final de la entrevista, se levantar un acta de la reunin, donde
se resumirn los puntos tratados. El acta deber ser entregada a
todos los participantes de la reunin.
2.- Entrevistas al resto de los usuarios.
El objeto de estas entrevistas es detallar aspectos funcionales ms
concretos. El guin para estas entrevistas deber contemplar:
2.1.- Situacin Actual.
Descripcin de los sistemas de informacin actualmente
implantados (ya sean manuales o informatizados). Incluir:
2.1.1.-
2.1.2.-
Entorno ffsico/lgico existente.
Tipos de entradas. Por cada tipo:
Su origen (departamento, grupo o sistema - en
caso de que exista -, que lo genera).
Datos involucrados.
Soporte utilizado (papel, intercambio elec-
trnico de datos, diskette, cinta magntica).
diariamente, semanalmente).
116
2.1.3.-
2.1.4.-
2.1.5.-
2.1.6.-
2.1.7.-
2.1.8.-
ENTREVISTAS
Procesos y funciones realizados por dichos
sistemas.
Tipos de salida. Por cada uno:
Destino (departamento, grupo de
departamento o sistema que lo recibe - si
existe -).
Datos involucrados.
Soporte (papel, intercambio electrnico de
datos, diskettes, cinta magntica).
diariamente, semanalmente, etc)
Volumen de informacin manipulada.
}lor sistema de fuformacin, detallar los
sistemas de almacenamientos de datos
involucrados, y para cada uno de ellos especifi-
car:
Tipos de datos implicados.
Identificar para cada dato si es identificativo o
significativo.
Principales ventajas e inconvenientes.
Nivel de satisfaccin tcnica con los sistemas
actuales. La valoracin incluir aspectos
como:
Disponibilidad de los sistemas de informacin.
Tiempos de respuesta.
Facilidad de uso.
Tiempo de espera si se piden modificaciones.
Puede utilizarse la tabla anterior para ponderar la
evaluacin.
MAP- MetodolOga METRICA Versin 2
ENTREVISTAS 117
2.2.- Requisitos del Nuevo Sistema.
2.2.1.-
2.2.2.-
2.2.3.-
2.2.4.-
2.2.5.-
2.2.6.-
CONSIDERACIONES.
Nuevos procesos/funciones a realizar por el
sistema.
Prioridades de esos procesos/funciones.
Nuevas consultas deseadas, incluyendo:
Datos involucrados.
Origen y destino de esos datos.
Frecuencia.
Nuevos informes deseados.
Necesidades de seguridad sobre los datos.
Factores crticos de xito.
Debe tenerse en cuenta que lo expuesto en estas pginas es slo
una visin general de los aspectos ms relevantes que deben ser
tratados en cada tipo de entrevista. Para cada proyecto, deber
confeccionarse un guin detallado de las entrevistas que se realicen,
segn sea:
El tipo de proyecto.
El usuario entrevistado.
La experiencia del entrevistador y su conocimiento
del sistema analizado.
118 ENTREVISTAS
El guin de la entrevistas se entregar con suficiente antelacin al
responsable de usuarios, para que ste pueda garantizar su
distribucin a las personas involucradas.
En la realizacin de una entrevista, se abordarn los puntos a tratar
desde una visin general, al principio, para centrarse gradualmente
en aspectos ms detallados.
4.2.2 Consolidacin de la Entrevista.
Una vez realizada la entrevista con el usuario, es conveniente depurar y
consolidar los resultados de la misma para asegurar que se han comprendido bien
las especificaciones del usuario sobre el conjunto de procedimientos de trabajo
del sistema actual, as como sobre los requisitos que debe satisfacer el nuevo
sistema.
Para ello se utilizarn tcnicas de representacin para ilustrar el funcionamiento
del sistema actual, mediante un dibujo libre, que permita contrastar con el
usuario el flujo de la informacin a travs del sistema, as como las diversas
tareas y responsabilidades en el uso de esa informacin. Adems se especificarn
los requisitos de usuario de una forma sencilla y medible, de manera que se
pueda asignar prioridades a dichos requisitos, y se validarn conjuntamente con
el usuario dichas prioridades.
Por ltimo, en el caso de que se disponga de las herramientas necesarias, se
podrn elaborar prototipos o maquetas simples del nuevo sistema, en los que
figuren:
Las pantallas de que consta.
Los informes a obtener.
La simulacin de las funciones que realiza.
La apariencia externa del mismo.
Estos prototipos ayudarn al usuario a especificar y concretar sus necesidades.
ENTREVISTAS 119
4.3. UTILlZACION DE LA TECNICA EN LA METODOWGIA METRICA
VERSION 2
La tcnica de entrevistas se utiliza en las etapas iniciales del ciclo de vida de
sistemas, donde se recoge informacin sobre los requisitos a cubrir por el nuevo
sistema. As, se utiliza en todas las actividades de la Fase O: "Plan de Sistemas de
Informacin" y dentro de la Fase 1: "Anlisis del Sistema", en todas las actividades
del Mdulo ARS ("Anlisis de Requisitos del Sistema") y en las siguientes
actividades del Mdulo EFS ("Especificacin Funcional del Sistema"):
EFS 1:
EFS2:
EFS3:
EFS4:
EFSS:
Construir el modelo de procesos del nuevo sistema.
Construir el modelo de datos del nuevo sistema.
Realizar un anlisis detallado del nuevo sistema.
Definir interfases de usuario.
Completar especificaciones del sistema.
DISEO ESTRUcruRADO
INDICE
5. DISEO ESTRUCTURADO
5.1. OBJETIVOS DE LA TECNICA 125
5.2. DEFINICIONES 126
5.3. DISEO DE PROCESOS 127
5.3.1. Descripcin de la tcnica
5.3.2. Herramientas de diseo: Diagrama de
Estructura de Cuadros
5.3.3. Principios del Diseo Estructurado
5.3.4. Estrategias de diseo
5.4. EVALUACION y REFINAMIENTO DEL DISEO 150
5.5. UTIUZACION DE LA TECNICA EN LA
123
DISEO ESTRUCTURADO
5. DISEO ESTRUCTURADO
5.1. OBJETIVOS DE LA TECNICA
125
Obtener la estructura modular y los detalles de proceso del sistema partiendo
solamente de los "productos" obtenidos en la fase de" Anlisis del Sistema.
Cambiar la atencin del QU al CMO.
Obtener un diseo que no slo "funcione", sino que tambin sea mantenible,
mejore la reutilizacin y se pueda probar y entender fcilmente.
Utilizar herramientas grficas (Diagramas de Estructura de Cuadros) para
representar la estructura modular del sistema.
Se trata por tanto de conseguir que cada mdulo de la estructura en rbol que
se obtenga cumpla las siguientes caractersticas:
Mdulos de pequeo tamao.
El impacto de un cambio a realizar puede ser perfectamente aislado. Si el
tamao de los mdulos es reducido, una determinada modificacin
afectar a un nmero mayor de mdulos, sin embargo, la cantidad de
cdigo a considerar ser menor.
Independencia modular.
Cuanto mayor es la independencia de un mdulo es ms sencillo trabajar
con l, por tanto, el diseo debe reducir la comparticin de ficheros, de
datos, la de dispositivos, las interfases comunes con el Sistema Operativo
y las llamadas desde o hacia otros mdulos.
Caractersticas de Caja Negra.
La caracterstica de Caja Negra se aplica a cualquier sistema, programa o
mdulo para dar una visin exclusiva de sus entradas y salidas, sin tener
en cuenta los detalles de cmo se realiza el proceso. El uso de la Caja
Negra permite una visin ms fcil del conjunto, postponiendo la
consideracin de los detalles para una etapa posterior.
126 DISEO ESTRUCfURADO
Modelizacin conceptual.
Un sistema ser ms fcil de mantener si el modelo utilizado en su diseo
se ha basado en los conceptos lgicos de la organizacin, los cuales sern
ms familiares y comprensibles para el personal de mantenimiento que las
descripciones fsicas (equipo, organizacin de la unidad, cmo se realiza
el trabajo en la actualidad...)
Aislamiento de los detalles.
En un sistema existen partes que reflejan la filosofa y otras partes
que reflejan los detalles. Debido a que los detalles son ms
susceptibles de cambiar, ambas partes deben disearse por
separado para evitar que una variacin en los detalles afecte a la
filosofa del sistema.
5.2. DEFINICIONES
Una definicin posible de Diseo, es la que aparece en el Glosario de Trminos
de Calidad e Ingeniera del Software de la Asociacin Espaola de Control de
Calidad:
.'

sausfacerooos .'
, .
::"'::\..
Se considerarn dentro del diseo, dos partes, atendiendo al nivel de detalle:
DISEO DE ARQUITECTURA:
Proceso de definicin de la coleccin de componentes del sistema y sus
interfases.
DISEO DETALLADO:
Proceso de descripcin ms detallada de la lgica del proceso y de las
estructuras de datos.
DISEO ESTRUCfURADO
5.3. DISEO DE PROCESOS
127
Una vez finalizada la Fase de Anlisis del Sistema, se dispondr, al iniciar la Fase
de Diseo de un conjunto de especificaciones funcionales que describan, con
trminos precisos:
Las entradas que suministran al sistema las entidades externas.
Las salidas aportadas por el sistema a dichas entidades externas.
Las funciones descompuestas que se han de realizar por ese sistema.
El modelo de datos lgico del sistema.
Toda esta informacin estar almacenada en el diccionario del proyecto mediante
la descripcin de Diagramas de Flujo de Datos, Procesos, Flujos de Datos,
Diagramas de Estructuras de Datos, Entidades y Atributos.
Para pasar a construir el nuevo sistema es necesario convertir toda esta
informacin en especificaciones de programas.
Las tareas a realizar son:
Determinar qu mdulos implantarn los procesos terminales obtenidos
en la Fase Anlisis del Sistema.
Organizar la estructura de estos mdulos y definir las conexiones entre los
mismos.
Describir el pseudocdigo para cada mdulo.
Para ello se seguir el mtodo propuesto por CONSTANTINE: el Diagrama de
Estructura de Cuadros, que permite definir cundo, bajo qu condiciones y
cuntas veces se tienen que realizar los tratamientos identificados er! los
PROCESOS. Los datos se contemplan como la interfase entre tratamientos
sucesivos.
128 DISEO ESTRUcrURADO
5.3.1. DESCRIPCION DE LA TECNICA
El paso de la Fase de anlisis del sistema al diseo ser ms fcil si se ha
llegado a un nivel de detalle muy bajo en los Diagramas de Flujo de
Datos.
La estructura Constantine nos da una visin de Arquitectura del sistema.
Se trata pues, de no tener ninguna restriccin en cuanto al nmero de
objetos, siempre y cuando el dibujo pueda realizarse en una hoja, para no
perder la referencia, yen cualquier caso poder explosionar aquella funcin
que se descomponga.
5.3.2. HERRAMIENTAS DE DISEO: DIAGRAMA DE ESTRUCTURA DE
CUADROS
La herramienta ms importante utilizada es el DIAGRAMA DE
ESTRUCTURA DE CUADROS (Strueture Chart).
Este diagrama est compuesto por tres elementos bsicos:
Mdulos
Conexiones entre mdulos
Comunicacin entre mdulos
Cada uno de estos elementos bsicos se explican a continuacin.
MODULO
El mdulo representa un programa, subprograma o rutina, dependiendo
del lenguaje que se vaya a utilizar. Se representa en el Diagrama mediante
un rectngulo.
El diseo estructurado NO ha impuesto la restriccin de que un mdulo
tenga que ser compilado independientemente.
Se considera al mdulo como aquella parte de cdigo que se puede
llamar.
Es, por tanto, algo que admite parmetros de llamada y retorna algn
valor, si es preciso.
CONEXION
La conexin entre mdulos se representa mediante una lnea.
DISEO ESTRUcrURADO
MODULO
I
OBTENER
DATOS
CLIENTES
CONEXION
I
MODULO
A QUE LLAMA
I
B
MODULO
LLAMADO
En la figura se representa que:
129
A llama a B.
B hace su funcin.
B retonla a inmediatamente despus del lugar donde se produjo
la llamada a A a B.
El diagrama no dice nada sobre el cdigo A ni sobre el de B, lo nico
que sabe es que en A existe una sentencia del tipo CALL B.
COMUNICACION
Los signos para llevar a cabo la comunicacin entre mdulos son:
o--
FlAG
DATOS
130 DISEO ESTRUCI'URADO
Mediante los "flag" o controles, se puede representar:
Paso de control entre mdulos: un mdulo comunica a otro mdulo
que ha terminado su proceso y traspasa al mdulo llamado el
control del sistema.
Comunicacin de que se ha producido un error en el proceso.
Comunicacin de que se puede proceder a una operacin concreta,
por ejemplo, en el caso de una insercin de datos del sistema, un
mdulo puede "inspeccionar" los datos existentes y comunicar a
otro que el dato a insertar no existe. El "mdulo" insertara el dato,
etc.
En la figura siguiente OBTENER DATOS CLIENTE llama a
ENCONTRAR NOMBRE CLIENTE comunicndose la siguiente
informacin:
Nmero cuenta cliente (Dato).
Nombre cliente (Dato).
Nmero cuenta OK (Flag).
Qu diferencias existen entre datos y flags o controles?
(a) Los datos son la informacin compartida por los mdulos, tanto
por el llamado como por el que llama. La posicin de la flecha
(hacia arriba o hacia abajo) indica el sentido de la comunicacin.
Algo esencial es que los datos se van a procesar, mientras que los
controles no.
Los controles van a indicar el mdulo que llama la terminacin
EOF, o error del mdulo llamado y deben ir siempre en sentido
ascendente.
(b) Los datos tienen gran importancia para el sistema en s mismo,
hacia el exterior. Los flags tienen importancia en la comunicacin
de informacin en el interior; son los que sincronizan la operativa
de los mdulos.
DISEO ESTRUCI1JRADO 131
ERO
A
ero
OBTENER
DATOS
CUENTES
O.eRE 1
L1ENTE
HUM
1
eUENT
COAAE
ERO 1
NTA
RREtTO
ENCONTRAR
NOMBRE
CLIENTE
H
e
HUM
ellE
eo
OTROS SIMBOLOS
SECUENCIA:
Cuando un mdulo llama a varios, y esto se realiza solamente una vez, la
forma de representarlo es la siguiente:
132 DISEO ESTRUCTURADO
y la secuencia de ejecucin suele ser de izquierda a derecha y de arriba a
abajo.
En el ejemplo, la secuencia ser 1, 2 Y3.
Los mdulos inferiores son los que realizan las tareas correspondientes y
los superiores los que coordinan, por medio de los datos que se les va
entregando.
lTERACION:
Si adems de haber llamadas a varios mdulos, cada uno de estos mdulos
inferiores se ejecuta varias veces, se representa como iteracin con el
smbolo que aparece en la figura siguiente:
Este smbolo representa llamadas mltiples a los tres mdulos ms bajos
en la jerarqua, y en este caso se realizarn los tres en esa secuencia, un
nmero n de veces.
DISEO ESTRUcruRADO
DECISION:
133
Cuando existe una selecci6n de camino, el m6dulo superior tendr que
realizar una decisi6n. Grficamente se representa por medio de un
diamante que abarcar aquellas conexiones que formen parte de esta toma
de decisi6n:
CALCULAR
PREMJO
CALCULAR
PREMJO
ADULTO
CALCULAR
PREMIO
NIO
CALCULAR
CANTIDAD
MENSUAL
Decisi6n. El m6dulo CALCULAR PREMIO contiene una decisi6n del
tipo:
IF EDAD GT21
TREN CALL CALCULAR
PREMIO
ADULTO
ElSE CALL CALCULAR
PREMIO
NIO
Adems de los ya vistos anteriormente, hay otros objetos que forman parte
de la tcnica de Constantine como son:
MODULO PREDEFINIDO
Es un mdulo que est disponible en la librera del sistema o de la propia
aplicacin:
IMPRIMIR
CHEQUE
DE
PAGO
ALMACEN DE DATOS
Es la representacin fisica de dnde van a estar los datos en la realidad,
en nuestro sistema
DISPOSITIVO FISICO
Es cualquier dispositivo por el cual se puede recibir o enviar informacin
que necesite el sistema
LDEV,CE7
MAP - Metodologfa METRICA Versin 2
DISEO ESTRUCfURADO
E.IEMPW DE UN DIAGRAMA DE ESTRUCTURA COMPLETO
......
......
''''''...
135
AEMTA:lMOO
,.......
....,.....
o.",
............
........
...,.....
.....
,.....".""
POAlNtIU."lI)
...-
""....
"""
Sobre la figura anterior se pueden aadir cuatro detalles:
1. El mdulo CALCULAR REDUCCIONES NORMALES aparece
slo una vez, aunque tiene dos "padres":
Esto se hace para simplificar la escritura y el mantenimiento.
Escribir el mdulo slo una vez hace ms fcil comprobar el
nmero y tipo de parmetros con los que los mdulos padres
le llaman (consistencia de interfase).
136
2.
3.
DISEO ESTRUCfURADO
Se seguir un criterio de lectura de izquierda a derecha para
conocer el orden en que se realizan las llamadas a los mdulos.
Est permitido que un mdulo, por ejemplo el que realiza la
llamada, reconozca una variable con un nombre, y otro, por
ejemplo el llamado, la reconozca con uno diferente.
(En el grfico PAGO BRUTO POR HORAS YPAGO BRUTO
POR CONTRATO se refieren a lo mismo y pueden ser
reconocidos enCALCUIARDEDUCCIONESNORMALEScomo
PAGO BRUTO).
4. El nombre de un mdulo resume su funcin, es deciJr, lo que
realiza para su padre. No tiene que resumir la fimcin que realizan
sus hijos.
Este Diagrama de Estructura de Cuadros se basa en tres principios
fundamentales que vamos a ver a continuacin.
5.3.3. PRINCIPIOS DEL DISEO ESTRUCTURADO.
1. DESCOMPOSICION
La descomposicin es la separacin de una funcin en otras que estuvieran
contenidas en la primera.
La descomposicin consigue los siguientes objetivos:
(a) Reducir el tamao del mdulo.
(b) Hacer el sistema ms fcil de entender y modificar.
(En el ejemplo CALCULO SUELDO NETO POR HORAS se
compone de dos funciones. Si se tuviera que modificar una de ellas,
se tendra que tener cuidado en no tocar ninguna sentencia
relacionada con la otra)
En el diseo "top-down", de arriba a abajo, permite descomponer paso a
paso, segn se vaya observando que los mdulos realizan mltiples
funciones, acercndonos cada vez ms a la solucin ptima.
DISEO ESTRUCTURADO
ENITlA
CHEQUES
EMPLEADO
137
REOISTRO PAGO
....""DOS
OBTENER
REGISTRO ce
RNAL AEGlSTROS
EMPLEADOS
CALCUl..o\R
NETO
POANORAS
CALCutAA
NETO
POR CONTRATO
IMPRIMIR
CHEQUE
PAOO
138
(e)
DISEO ESTRUcruRADO
Minimizar la duplicidad de cdigo.
Se evita tener que realizar una funcin en ms de un mdulo.
(En la figura el mdulo CALCULAR DEDUCCION NORMAL
para CALCULO SUELDO NETO POR HORAS Y POR
NOMINA).
..""
,......
..........
""""""....
..........
(d) Crear mdulos tiles.
En la figura el mdulo VALIDAR CAMPO ALFABETICO puede
utilizarse en cualquier otra parte del sistema (o en otros sistemas
que se desarrollen). Por ejemplo, para hacer un chequeo en
provincias o ciudades).
DISEO ESTRUCTURADO
1
OBTENER
CAMPO
ALFABETlCO
SIGUIENTE
CAMPO
AlFABETlCO
CORRECTO
139
OBTENER
CAMPO
SIGUIENTE
CAMPO '" CAMPO
~ 't:F0RRECTO
VALIDAR
CAMPO
ALFABETICO
El problema puede surgir cuando el diseador se pregunte en qu
momento debe dejar de descomponer mdulos.
Se debe dejar de descomponer cuando no se encuentren funciones
bien definidas.
Se puede parar la descomposicin cuando la interfase con un
mdulo sea tan complicada como el mdulo en s mismo.
Un mdulo de mil lneas es malo, ya que trata demasiados asuntos en su
interior, pero mil mdulos de una lnea son peores.
2. JERAROUIA
Al dividir los mdulos jerrquicamente, es posible controlar el
nmero de ellos que interactan directamente con cualquiera de
los otros.
140
DISEO ESTRUCTURADO
El objetivo de aplicar una jerarqua de mdulos es conseguir
separar los mdulos que realizan tareas de clculo y edicin de
aquellos que toman decisiones y llaman a otros mdulos.
Se debe lograr un tipo de organizacin en donde los mdulos de
niveles medios y altos del diagrama ejerzan el trabajo de
coordinacin y manipulacin de los mdulos de niveles ms bajos,
que son los que deben realizar tareas de clculo y edicin.
3. INDEPENDENCIA
Si los mdulos individuales son completamente independientes
unos de otros, entonces el esfuerzo total implicado en el desarrollo
del sistema es una funcin lineal del nmero de mdulos del
sistema.
La definicin de mdulos est cerca de la idea de CAJA NEGRA:
mi mdulo no tiene que preocuparse de los detalles de la
construccin interna del resto de los mdulos.
Hay que ver a los mdulos solamente por su funcin y por su
apariencia externa.
5.3.4. ESTRATEGIAS DE DISEO
El paso de los Diagramas de Flujo de Datos (DFD), obtenidos en la Fase
Anlisis del Sistema, a los Diagramas de Estructura de Cuadros (DEC),
se puede hacer utilizando una serie de estrategias que ayuden a conseguir
una rpida derivacin hacia un buen diseo.
Habr que estudiar la forma del DFD sobre el que se vaya a realizar el
diseo y dependiendo de su estructura, utilizar una de las estrategias que
se describen a continuacin. El uso de una de las dos estrategias no
supone que la otra no pueda ser utilizada. Depender nicamente de la
forma del DFD y del peso de la actividad de los procesos.
A partir de esta primera estructura y utilizando las mtricas que se vern
en el siguiente apartado, se realizar la evaluacin y refinamiento del
diseo hecho, consiguindose, de esa forma, un diseo con una calidad
alta.
DISEO ESTRUCIURADO
Estas estrategias son:
Anlisis de Transformacin.
Anlisis de Transaccin.
141
El objeto de estas estrategias es desarrollar una representacin global de
la Arquitectura del Sistema. Una vez que se define la estructura, podemos
evaluar y refinar esta Arquitectura, vindola como un todo.
1. ANALISIS DE TRANSFORMACION
El "Anlisis de Transformacin" es una estrategia, no un algoritmo.
Si se siguen los pasos de un algoritmo los resultados estn
asegurados y son correctos, una estrategia consigue resultados
buenos, pero no perfectos en una primera aproximacin.
El anlisis de transformacin es un conjunto de pasos que permiten
obtener, a partir de un DFD con caractersticas de transformacin,
la estructura del sistema.
El DFD con caractersticas de transformacin es aqul en el que
se pueden distinguir tres zonas:
Flujo de llegada o entrada.
Flujo de transformacin o centro de transformacin.
Flujo de salida.
Esta divisin en tres partes va a facilitar que los datos que necesite
el sistema se recojan por los mdulos que se encuentren en la/s
rama/s de la izquierda, los datos que se intercambian en esa rama
sern ascendentes: informacin de entrada al sistema.
En las ramas centrales habr movimiento de informacin
compartida tanto ascendente como descendente porque aqu los
mdulos elaboran nuevos datos.
En la/s rama/s de la derecha, la informacin ya ser la definitiva
y el sentido de los datos debe ser descendente.
En algn caso particular puede suceder que alguna de las partes
sea vaca, esto es, no exista.
PASOS DEL ANALISIS DE TRANSFORMACION
(a) Aislar el centro de transformacin.
(b) Realizar "el primer niv.el de factorizacin" del Diagrama de
Estructura de Cuadros.
(c) Elaborar el "segundo nivel de factorizacin".
(d) Refinar la estructura del sistema utilizando medidas y guas de
diseo.
A continuacin se ver en detalle cada uno de estos pasos.
(a) Aislar el centro de transformacin.
El centro de transformacin es la parte del DFD que contiene las
funciones esenciales del sistema y es independiente de las
caractersticas particulares de la entrada y de la salida.
Para aislar el centro de transformacin habr que especificar los
lmites del flujo de llegada y salida.
Los lmites de flujo de llegada y salida estn abiertos a
interpretacin de cada uno y se pueden derivar soluciones de
diseo alternativas variando la colocacin de los lmites de flujo,
aunque una pequea variacin tendr poco impacto sobre la
estructura final.
En el ejemplo siguiente, se ha aislado uno de los posibles Centros
de Transformacin:
DISEO ESTRUCI'URADO
..
CENTRODE LA
TRANSFORMACION
143
(b) Realizar el primer nivel de factorizacin en Diagrama de
Estructura de Cuadros.
La estructura del programa debe representar una distribucin
descendente del control.
El resultado del paso de DFD (Diagrama de Flujo de Datos) a
DEC (Diagrama de Estructura) debe ser una estructura en la que
los mdulos de nivel superior toman las decisiones de ejecucin y
los mdulos de nivel inferior ejecutan la mayora del trabajo de
entrada, de clculo y de salida.
En el primer nivel de factorizacin aparecern subordinados a un
mdulo de control del sistema, tres m6dulos:
144
'.
DISEO ESTRUCfURADO
Mdulo controlador del proceso de la infonnacin de llegada.
Mdulo controlador del centro de transfonnacin.
Mdulo controlador del proceso de la infonnacin de salida.
Esto se representa en el diagrama siguiente.
...........
PRIMER NIVEL DE
fACTOR1ZAC10N
DISEO ESTRUcruRADO
(c) Elaborar el "segundo nivel de factorizacin",
145
El segundo nivel de factorizaci6n se realiza mediante la conversin
de las transformaciones de cada proceso de un DFD en los
mdulos correspondientes del diagrama de estructura.
Para ello se comienza en el lmite del centro de transformaci6n y
se va hacia afuera a lo largo de los caminos de llegada y salida.
SEGUNDO NIVEL DE
FACTORIZACION
EL
SISTEMA"

OBTENER
bt
OBTENER
t
LEER
OBTENER
d
o
LEER
MODULO
F
CENTRO
DE LA
TRANSFOR
MACION
MODULO
H
MODULO
I
PRODUCIR
ESCRIBIR
146
(d)
DISEO ESTRUcruRADO
Retinar la estructura del programa utilizando medidas y gua de
diseo.
Una estructura de programa puede siempre refinarse siguiendo los
criterios que se vern en el apartado 5.4, ms adelante.
Dos o ms mdulos asignados por los correspondientes procesos
creados en la Fase de Anlisis del Sistema se pueden continuar en
uno slo y un mdulo puede que se detalle (explote) en dos o ms
mdulos.
Los refinamientos estn dictados por consideraciones prcticas yde
sentido comn.
2. ANALISIS DE TRANSACCION
El anlisis de transaccin se aplica cuando un DFD toma una
forma en la que un dato determina la eleccin de uno o ms flujos
de informacin.
La transaccin es evaluada y, basndose en su valor, eR flujo se
inicia por uno de los muchos caminos de accin.
El centro de flujo de informacin desde el que emanan varios
caminos de accin se llama centro de transaccin.
DISEO ESTRUcruRADO
ESTRATEGIA
ANALISlS DE TRANSACClON
.PASOS DEL ANALISIS DE TRANSACCION:
(a) Identificar el centro de transaccin.
147
(b) Transformar el DFD en la estructura adecuada al proceso de
transacciones.
(c) Factorizar la estructura de cada camino de accin.
(d) Refinar la estructura del sistema utilizando medidas y gua de
diseo.
A continuacin se detallan cada uno de los pasos.
148
(a)
DISEO ESTRUCTURADO
Identificar el centro de transacciones.
La posici6n del centro de transacci6n puede descubrirse
inmediatamente a partir del DFD, viendo cul es el origen de una
serie de caminos de informaci6n que fluyen radialmente.
Cada camino de llegada y todos los caminos de acci6n deben
tambin aislarse. Cada camino de acci6n debe evaluarse en funci6n
de sus caractersticas individuales de flujo.
(b) Transformar el DFD en la estructura adecuada al proceso de
transacciones.
El flujo de transacciones se convierte en una estructura de
programa formada por una bifurcaci6n de entrada y una
bifurcaci6n de salida.
(e) Factorlzar la estructura de cada camino de accin.
La estructura de la bifurcaci6n de entrada se desarrolla de la
misma forma que el anlisis de transformaci6n, comenzando en el
centro de transacci6n y continuando desde el lmite hacia afuera a
lo largo del camino de llegada.
DISEO ESTRUCfURADO 149
Cada camino de flujo de accin del DFD se convierte en una
estructura que se corresponde con las caractersticas especficas del
flujo (flujo de transformacin o de transaccin).
Cada camino de accin estudiado se desarrolla usando los pasos de
diseo discutidos anteriormente.
(d) Refinar la estructura del programa utilizando medidas y guas de
diseo.
En la siguiente figura se ilustra el resultado de la aplicacin sucesiva de
estos pasos al DFD anterior.
E.IEMPW DE PASO DE UN DFD A DEC
5.4. EVALUACION y REFINAMIENTO DEL DISEO
Un buen diseo debe organizar la complejidad del problema de manera que el
esfuerzo asociado con su desarrollo, prueba, entendimiento y mantenimiento
pueda ser controlado y minimizado.
Para evaluar y mejorar el diseo obtenido con las estrategias mencionadas se
utilizan dos unidades de medida:
ACOPLAMIENTO.
COHESION.
Para mejorar la calidad del diseo tambin se pueden utilizar una serie de guas
o "consejos prcticos" que ayuden a conseguir este objetivo.
1. ACOPLAMIENTO
Se puede definir acoplamiento como el grado de interdependencia entre
los mdulos; depende del nmero de parmetros que se intercambian para
su comunicacin.
El objetivo que se debe conseguir es MINIMIZAR el acoplamiento, o lo
que es lo mismo, hacer que los mdulos sean tan independientes como sea
posible, aunque esto no siempre se consiga. Un bajo acoplamiento entre
los mdulos indica que se ha hecho una buena descomposicin del
sistema, aunque esto no ocurre siempre.
Uno de los puntos cruciales que hay que asegurar para conseguir un
acoplamiento mnimo es que el mdulo no tenga que preocuparse de.los
detalles de la construccin interna del resto de los mdulos (concepto de
CAJA NEGRA), ya que se trata de conseguir mdulos lo ms
independientes posibles.
Un bajo acoplamiento es deseable por las razones siguientes:
Cuantas menos conexiones existan entre dos mdulos, menos
oportunidad habr de que aparezca el "efecto onda" (un defecto de
un mdulo, puede aparecer afectando a otro).
Se desea tener posibilidad de cambiar un mdulo con el mnimo
riesgo de tener que cambiar otro, se, trata de que cada cambio
realizado afecte lo menos posible a otros mdulos.
DISEO ESTRUCfURADO 151
Mientras se est manteniendo un mdulo, es deseable no necesitar
preocuparse en los detalles internos (cdigo) de cualquier otro
mdulo.
Existen distintos niveles de acoplamiento segn el siguiente espectro:
(a) Acoplamiento Normal
De datos
Por estampado
De control
MEJOR
(b) Acoplamiento comn
(c) Acoplamiento por contenido PEOR
(a) ACOPLAMIENTO NORMAL
Ocurre cuando dos mdulos intercambian datos pero stos no
interfieren en la operativa normal de la funcin que realiza el
mdulo de nivel inferior.
(a.1) ACOPLAMIENTO DE DATOS.
Entre dos mdulos, el que llama y el llamado, ha de
establecerse al menos una comunicacin bsica por medio de
elementos.
I
OBTENER I
DATOS
CLIENTES
NUMERO
CUENTA
CORRECTO
NOMBRE t
CLIENTE O
1
NUMERO
CUENTA
CORRECTO
Este acoplamiento no da ningn tipo de problemas, pero hay
que controlar que los datos se generen lo ms cerca posible
del mdulo que los vaya a utilizar.
(a.2) ACOPLAMIENTO DE ESTAMPADO.
Ocurre si en la comunicacin entre mdulos se pasan datos
con estructura de registro. Este acoplamiento no es deseable
si el mdulo que recibe ese registro, necesita slo parte de los
elementos que se le pasan.
GISTRO
ENTE
OBTENER
NOMBRE
CLIENTES
STRO
1
TE
RE
DO
1
CLI
VALIDAR
NOMBRE
CLIENTE
REGI
CLlEN
VALI
DISEO ESTRUcruRADO
(a.3)
153
ACOPLAMIENTO DE CONTROL
Ocurre si los datos de comunicacin son controles. Ya se sabe
que los mdulos superiores coordinan y los de nivel inferior
realizan el trabajo, stos debern comunicar su estado. Este
tipo de acoplamiento no ser. nocivo si el control (flag) tiene
sentido ascendente ya que informar de la situacin en la que
se encuentra el mdulo inferior.
Sin embargo en el caso de la figura, el control tiene sentido
descendente, lo que implica una ruptura del principio de "caja
negra": el mdulo superior conoce detalles de la estructura
del mdulo inferior. Esto podra implicar problemas de
mantenimiento, si se cambiase el mdulo inferior.
I
IGUALAR I
REGISTROS
CUENTES
CONTROL T
DE TRABAJO
DEL MODULO
INFERIOR
t REGiSTRO
MAESTRO
t REGISTRO
oTRANSACCIONES
I
CONTROL I
ENTRlSAUDA
SISTEMA
(b) ACOPLAMIENTO COMUN
Se produce cuando un nmero indeterminado de mdulos (ms de
dos) hacen referencia a un rea comn de datos.
Alguno lenguajes de programacin lo permiten, pero no es
operativo puesto que en algn momento esos datos pueden ser
cambiados y al acceder otro mdulo puede no encontrar la
informacin correcta. Habra que ser muy estrictos en cuanto al
acceso, y la proteccin de ese rea.
154
(e)
DISEO ESTRUCfURADO
ACOPLAMIENTO DE CONTENIDO
Ocurre cuando un mdulo cualquiera, necesita o accede a una
parte de otro, rompiendo la jerarqua de funcionalidad de la
estructura.
Si ocurre esto, habr que evitarlo descomponiendo el mdulo al
que se accede o duplicando esa parte de cdigo en el mdulo que
llama.
FACTORES A WS OUE AFEeI'A EL ACOPLAMIENTO
...~ . : . : . ~ ~ .
..
: : : : : ; ; ~ : :
DE DATOS VARIABLE BUENA BUENA BUENO
POR VARIABLE MEDIA MEDIA MEDIO
ESTAMPADO
DE CONTROL MEDIO POBRE POBRE POBRE
COMUN MALO MEDIA MALA POBRE
POR MALO MEDIA MALA MALO
CONTENIDO
DISEO ESTRUcruRADO
2. COHESION
155
La cohesin se puede definir como la medida de la fuerza o relacin
funcional de los elementos de un mdulo, entendiendo por elementos a la
sentencia o grupo de sentencias que lo componen, a las definiciones de
datos o a las llamadas a otros mdulos.
Un mdulo coherente ejecuta una tarea sencilla en un programa o
procedimiento y requiere poca interaccin con otros procedimientos que
se ejecuten en otras partes del programa.
Un mdulo coherente slo debe hacer (idealmente) una cosa.
El objetivo que se intenta conseguir es obtener mdulos con una alta
cohesin.
Asegurar que los mdulos tienen una buena cohesin es la mejor manera
de minimizar el acoplamiento.
La escala de cohesin no es lineal. Esto significa que una cohesin baja,
es mucho "peor" que la de rango medio, la cual es casi tan "buena" como
una gran cohesin.
Los distintos niveles de cohesin son los siguientes:
FUNCIONAL
MEJOR
CAJA NEGRA
MANTENIBILIDAD
SECUENCIAL NO DEMASIADA
COMUNICACIONAL CAJA NEGRA
PROCEDURAL CAJA GRIS
TEMPORAL
LOGICA CAJA BLANCA
PEOR O
COINCIDENTAL MANTENIBILIDAD
TRANSPARENTE
156
a)
DISEO ESTRUCTURADO
COHESION FUNCIONAL.
Un mdulo con cohesin funcional contiene elementos que contribuyen a
la realizacin de una, y slo una, tarea funcional.
Ejemplos de mdulos funcionalmente coherentes son los que realizan el
clculo de coseno de un ngulo, leen un registro, etc.
Los sistemas construidos principalmente con acoplamiento normal y con
mdulos coherentes funcionalmente con los ms fciles de mantener.
b) COHESION SECUENCIAL.
Un mdulo realiza distintas tareas dentro de l en secuencia de forma que
las entradas de cada tarea son las salidas de la anterior.
c) COHESION COMUNICACIONAL.
Un mdulo realiza actividades paralelas usando los mismos datos de
entrada y de salida.
d) COHESION PROCEDURAL.
Igual que la secuencial, pero con paso de controles.
e) COHESION TEMPORAL.
Las actividades que realizan tienen un matiz temporal.
t) COHESION LOGICA
Si las actividades que realiza un mdulo tienen la misma categora, es algo
as como tener partes independientes dentro de ese mdulo.
g) COHESION COINCIDENTAL.
Un mdulo con cohesin coincidental es aquel cuyos elementos
DISEO ESTRUCI1JRADO 157
contribuyen a las actividades relacionndose mutuamente de una manera
poco significativa.
Los mdulos con cohesin coincidental violan el pnnClplo de
independencia y de caja negra de los mdulos, ya que es necesario que el
"padre" tenga conocimiento de la estructura interna de los mdulos "hijos".
FACTORES A LOS OUE AfECfA LA COHESION
FUNClONAL BUENO BUENA BUENA BUENA BUENO
SECUENCIAL BUENO BUENA BUENA BUENA BASI'. BUENO
COMUNICA. MEDIO MEDIA MEDIA MEDIA MEDIO
PROCEDURAL VARIABLE POBRE VARIABLE VARIABLE MAW
TEMPORAL POBRE MEDIA MEDIA MEDIA MAW
LGICA MALO MALA MALA POBRE MAW
COlNODENI'B MALO POBRE MALA MALA MAW
3. IDEAS PRACTICAS PARA MEJORAR EL DISEO
El objetivo que se trata de conseguir con estas lneas es ofrecer una serie
de ideas prcticas que puedan ayudar a mejorar la calidad de un diseo.
Estas ideas prcticas son las siguientes:
Hay que reducir el nmero de parmetros que intercambian los
mdulos tanto como sea posible, es mejor que los datos de
comunicacin que se pasen sean elementos de registros.
Hay que evitar pasar parmetros de un mdulo a otro, a menos
que tengan una utilidad prctica.
EJEMPLO 1
En el ejemplo del grfico REGISlRO MAESlRO se obtiene demasiado lejos
de donde se utiliza.
La solucin sera subordinar OBTENER MAESlRO CUENTE a
ACIUALIZAR MAESlRO.
,..,.....
.........
v......
COT&HliR
RE.Cl$TRO
M"ESTRO
a.,.....
VALIDAR
-
"'",.....
NSERTAR
.... UTAO
DISEO ESTRUCTURADO
EJEMPW2
159
Nunca pasar registros que contengan muchos campos cuando en realidad el
mdulo slo necesita algunos, ese paso introduce una complejidad extra y reduce
la flexibilidad.
REGISTRO CLIENTE contiene los campos: Nm. Licencia, Nm. Socio,
Gasolina Usada, Tipo ~ o h e Kms. Conducidos y Das Utilizados y el mdulo
CALCULAR PRECIO ALQUILER, slo necesita los tres ltimos.
EJEMPLO 3
Existe una tendencia a agrupar parmetros que no tienen relacin ninguna, en un
registro que los contenga. Esto lo nico que consigue es complicar el diseo.
Se tiene que evitar en lo posible que un mdulo "hijo" d rdenes al "padre".
1
ESCRIBIR
MENSI'.JE
'CUENTE NO EXISTE'
160
I
NUMERO
CUENTA
CLIENTE
PRODUCIR I
INFORME
DE PAGO
t NOMBRE
CLIENTE
r
DISEO ESTRUCTURADO
I
ENCONTRAR I
NOMBRE
Existen dos posibles soluciones para mejorarlo:
1. Incluir la escritura del mensaje de error en ENCONTRAR NOMBRE.
2. Que ENCONTRAR NOMBRE informe solamente que el nmero de
cuenta no se ha encontrado y el "padre" tome la decisin de qu hacer con
esa informacin.
OTROS CONSEJOS:
Se recomienda no utilizar variables globales por CINCO razones:
1.) Un defecto (o mala prctica al programar) de cualquier mdulo
que utiliza un rea global, puede transmitirse a cualquier otro
mdulo que utilice ese rea global.
2.) Los mdulos que se refieren a datos globales siempre los utilizan
con el mismo nombre disminuyendo la flexibilidad de los mdulos.
3.) Se introduce un tipo de distanciamiellto en el sistema en el tiempo.
Puede ser difcil entender cmo lleg a tomar un valor
determinado una variable.
DISEO ESTRUcrURADO 161
4.) Son ms difciles de entender al tener que saber qu datos se
utilizan en cada mdulo particular.
5.) Es difcil encontrar qu mdulos se deben cambiar cuando una
parte de los datos cambia.
No se debe compartir cdigo entre las actividades que estn incluidas en
un mdulo. Esto hace difcil modificar una' actividad sin cambiar la otra.
Se debe parar la descomposicin cuando no se encuentren funciones bien
definidas. No se debe crear un mdulo con una serie de lneas de cdigo
agrupadas aleatoriamente.
Se puede parar la descomposicin cuando la interfase con un mdulo sea
tan complicada como el mdulo en s mismo.
Se debern conseguir diseos lo ms equilibrados que sea posible. Puede
decirse que un diseo est equilibrado si y slo si, trata con datos lgicos
en su parte alta y con datos fsicos en su parte baja.
162 DISEO ESTRUcruRADO
EJEMPLO DE SISTEMA BIEN EQUILIBRADO
/
Un mdulo realiza una funcin y debe ser llamado por todos los mdulos que
requieran esa funcin.
Un mdulo de nivel inferior puede llamar a otro mdulo de nivel superior de
otra rama del diagrama.
Es desaconsejable que un mdulo de nivel inferior llame a otro de nivel superior
de la misma rama ya que esto puede dar lugar a bucles sin salida
DISEO ESTRUCTURADO
4. HEURISnCAS DEL DISEO
163
Las heursticas de diseo son un conjunto de recomendaciones que ayudan a
mejorar la estructura del sistema, optimizando la modularidad. La aplicacin de
estas recomendaciones depende en gran medida del diseo especfico, as como
de las caractersticas del equipo fsico donde se desarrolla el sistema.
Tamao de un mdulo.
El desarrollo del sistema de una estructura modular define la
funcionalidad propia de cada mdulo; sin embargo, es recomendable
revisar independientemente cada mdulo a efectos de optimizar su tamao
en nmero de sentencias, para facilitar el desarrollo tcnico del programa
y su posterior mantenimiento.
En general, podemos resumir diferentes versiones sobre el tamao ptimo
de un mdulo definiendo que el coste en el desarrollo y mantenimiento de
un sistema ser ptimo cuando su estructura est compuesta por mdulos
con un tamao comprendido entre 10 y 100 sentencias (CONSTANTINE).
Ambito de control.
Se llama mbito de control de un mdulo a todos los mdulos llamados
por l y a los llamados por stos, es decir, a todos los mdulos que hay por
debajo de l en esa rama del diagrama de descomposicin funcional.
Un mdulo que llama a muchos otros puede ser difcil de entender, y en
el otro extremo, si los mdulos forman una larga secuencia lineal, es
posible que pueda suprimirse alguno de ellos. Deben evitarse ambos
extremos:
- Ambito de control alto:
Normalmente se produce cuando no se tienen en cuenta los niveles
intermedios. El estudio de los grupos de mdulos subordinados que
permitan combinar sus funciones en una sola, puede solucionar el
problema.
- Ambito de control bajo:
Para optimizar una estructura de este tipo se deben revisar las
posibilidades de descomponer las funciones en subfunciones con
entidad propia, para formar nuevos mdulos, o por el contrario,
comprimir mdulos subordinados en el mdulo de nivel superior.
N.lBlTO I

DISEO ESTRUCfURADO
Ambito de efecto.
165
Este trlnino se aplica a los mdulos en los que interviene alguna decisin,
e identifica a los mdulos afectados por esa decisin.
El mbito de efecto debe estar contenido en el mbito de control del
mdulo que toma la decisin.
Si no se da ninguna norma, es decir, si hay mdulos en otras ramas del
diagrama de descomposicin funcional que dependen de esa decisin,
habr un flujo de control hacia arriba y hacia abajo por todo el diagrama
con el subsiguiente incremento en el acoplamiento, o incluso se puede dar
que la misma decisin se tome de nuevo en otra rama del diagrama.
Generalmente, existen tres soluciones a este problema:
1. Integrar el mdulo de nivel bajo en su mdulo superior, de manera
que la decisin quede situada en un nivel alto de la estructura.
2. Trasladar dentro de la estructura del mbito de efecto el mdulo
afectado por la decisin.
3. Extraer la decisin del mdulo de nivel bajo y ponerla en el
mdulo de nivel alto.
166
AMIlITOCONTROlJ
AMSITO EFECTO
DISEO ESTRUCI'URADO
AMBlm EFECTOFUERA DEL
AMBlTO CONTROL
DISEO ESTRUCfURADO
5. DEFINICION DE LOS PROGRAMAS
167
Por ltimo, el diseador debe agrupar todos los mdulos que ha definido
en distintos programas.
Existen en este sentido dos posturas muy contrastadas:
Construir un programa por cada mdulo.
Se garantiza que los campos de trabajo de un mdulo no sean
accesibles para otro para asegurar por tanto, que no se dan
acoplamientos patolgicos.
Como contrapartida el funcionamiento se hace ms lento, puesto
que los programas realizan continuas llamadas "CALL" a pequeos
programas. Adems, un programa que sea llamado por otros estar
cargado en memoria tantas veces como programas lo llamen.
Agrupar todos los' mdulos en un programa, asociando cada uno de
ellos a un prrafo.
Funcionamiento ms rpido, sin necesidad de realizar "CAlL".
Las desventajas son evidentes: desbordamientos de memoria,
encarecimiento de las modificaciones, rigidez, etc.
Criterios para definir proKI"amas.
Se deben clasificar los mdulos en programas teniendo en cuenta las
restricciones de equipo fsico y sistema operativo, de modo que el
resultado sea lo ms eficiente posible, con programas pequeos y
manejables. Los factores a tener en cuenta son:
Iteracin: Si un mdulo llama a otro iterativamente, se pueden
evitar muchos CALL poniendo ambos mdulos en el
mismo programa.
Volumen: Si se conoce el nmero de veces que un mdulo llama
a otro, se deben poner en el mismo programa
aquellos mdulos con un gran volumen de llamadas
entre ellos.
168
DISEO ESTRUCTURADO
Intervalo: Aquellos mdulos que en un pequeo intervalo tengan
una alta frecuencia de llamada deben ir en el mismo
programa.
Funcin opcional: Los mdulos que realicen funciones
secundarias u opcionales pueden ir en
programas independientes.
Ejecucin nica: Los mdulos que se ejecutan una nica vez
en el sistema deben ser programas
independientes.
Clasificacin: Los mdulos que sean entradas o salidas de un
proceso de clasificacin deben ser programas
independientes.
Documentacin del prolP"ama.
Cada programa de una aplicacin debe documentarse exhaustivamente con
el fin de facilitar su futuro mantenimiento por cualquier persona del
departamento de desarrollo. Para ello se deber disponer de la siguientes
informacin:
Estructuras de datos de los distintos ficheros de entrada y salida
que utiliza el programa.
Diagrama de correspondencias entre ficheros de entrada y salida.
Estructura del programa una vez integradas las estructuras de
entrada y salida.
Comentarios sobre el programa, indicando:
Colisiones detectadas y forma de resolverlas.
Normas especiales de ejecucin.
Limitaciones.
Tablas de decisin.
Usta detallada de operaciones.
DISEO ESTRUCTURADO 169
Estructura del programa conteniendo la asignacin de operaciones.
Lgica esquemtica (pseudocdigo).
Listado del programa fuente, compilado y sin errores.
Listado de referencias cruzadas para facilitar la bsqueda de
variables y entidades a lo largo del programa, cuando sea necesario
efectuar su mantenimiento.
Listado de ocupacin de memoria.
Cualquier otro listado que proporcione el compilador o sistema
operativo.
Documentacin de la prueba definitiva que se realiz para obtener
la aceptacin del programa, adjuntando juegos de ensayo,
condiciones de prueba, tiempo invertido, y resultados obtenidos.
s.s. UTILlZACION DE LA TECNICA EN LA METODOWGIA METRICA
VERSION2.
El Diseo estructurado se utiliza en la Fase 2: Diseo de Sistemas.
FASE 2: Diseo de Sistemas.
D1'8 1: DISEAR LA ARQUITECfURA FISICA DEL SISTEMA
1.1. Diseo de la Estructura Modular del Sistema.
1.2. Descripcin de interfases entre mdulos del Sistema.
1.3. Descripcin de interfases con otros Sistemas.
1.5. Definicin de componentes del Sistema.
Asimismo, puede ser conveniente utilizarla en la Fase 3: Construccin de
Sistemas, para los componentes del sistema que, por su criticidad o complejidad,
requieran una atencin especial.
FASE 3: Construccin del Sistema.
DCS 2.1.: Generacin del cdigo de los componentes del sistema.
ANALISIS COSTE-BENEFICIO
6. ANALISIS COSTE . BENEFICIO
INDICE
6.1. INTRODUCCION y OBJETIVOS 175
6.2. DESCRIPCION DE LA TECNICA . . . . . . . . . . . . . . . . . .. 175
173
ANALISIS COSTE-BENEFICIO
6. ANALISIS COSTE-BENEFICIO
175
La tcnica de anlisis coste-beneficio tiene como objetivo fundamental
proporcionar una medida de los costes en que se incurre en la realizacin de un
proyecto informtico y comparar' dichos costes previstos con los beneficios
esperados de la realizacin de dicho proyecto. Esta medida o estimacin servir:
Para valorar la necesidad y oportunidad de acometer la realizacin del
proyecto.
Para seleccionar la alternativa ms beneficiosa para la realizacin del
proyecto.
Para estimar adecuadamente los recursos 'econmicos necesarios en el
plazo de realizacin del proyecto.
Es de destacar la necesidad cada vez mayor de guiarse de criterios econmicos
y no slo tcnicos para la planificacin de trabajos y proyectos informticos. Por
ello en la Metodologa METRICA Versin 2 se hace una primera introduccin
sobre las tcnicas y mtodos de evaluacin de dichos criterios econmicos con el
fin de ayudar a los responsables de los proyectos informticos en los trabajos de
planificacin de proyectos y evaluacin de alternativas.
6.2. DESCRIPCION DE LA TECNICA
Para la realizacin del anlisis Coste-Beneficio se seguirn los siguientes pasos:
1.- Producir estimaciones de costes-beneficios.
2.- Determinar la viabilidad del proyecto y su aceptacin.
PRODUCIR ESTIMACIONES DE COSTES-BENEFICIOS
Se realizar una lista de lo requerido para implementar el sistema y una lista de
los beneficios del nuevo sistema.
En un anlisis de costes y beneficios se debern considerar aquellos aspectos
tangibles (medibles en valores como dinero, tiempo, etc.) y no tangibles (no
ponderables de una forma objetiva). En general, los costes suelen ser medibles
176 ANALISIS COSTE-BENEFICIO
y estimables en unidades econmicas, no as en cuanto a los beneficios, los cuales
pueden ser tangibles o no tangibles.
Estos beneficios no tangibles pueden ser:
El aumento de cuentas debido al mejor servicio a los clientes.
La mejora en la toma de decisiones debido a una mejora en el soporte
informtico.
En estos casos se deber estimar de una forma subjetiva la valoracin de dichos
beneficios.
Esta valoracin ser realizada por las reas correspondientes.
A menudo es conveniente dividir los costes estimados a lo largo de las fases del
proyecto, para ofrecer una informacin ms detallada de la distribucin de los
recursos de cara a la Direccin. Algunos costes tahgibles son:
Costes de equipo.
Costes de infraestructura: acomodacin necesaria del equipo, mobiliario
necesario, etc.
Costes de personal tanto para desarrollo como para realizar el trabajo del
nuevo sistema, as como formacin de todo el personal implicado.
Costes materiales.
Costes de conversin.
Costes de consultora.
DETERMINAR LA VIABILIDAD DEL PROYECTO
Se basar en uno de los mtodos siguientes:
Retomo de la Inversin
Este mtodo consiste en calcular el coste y el beneficio anual, sabiendo el
coste total al inicio del proyecto "CO. Este mtodo permite saber en qu
ao se recupera el coste total inicialmente estimado.
ANALISIS COSTE-BENEFICIO 177
Ao COSTE BENEFICIO BENEFICIO
NETO
O CO O
1 C1 B1 B1- C1
2 C2 B2 B2 - C2
n en Bn Bn- en
El ao de recuperacin de la inversin es cuando I: Ben. Neto = co.
valor Actual
Este mtodo permite tener en cuenta que un gasto invertido durante un
cierto tiempo produce un beneficio.
El mtodo consiste en determinar el dinero que es viable invertir
inicialmente para que se recupere la inversin en un perodo de tiempo
definido previamente.
El resultado depende del inters (r) utilizando en la evaluacin.
Se deber calcular, en primer lugar, el beneficio neto que se obtendr
cada ao. Dicho beneficio no es real, ya que se debe estimar el valor real
de dicha cantidad en el ao n.
Para ello se aplicar la frmula:
Valor Actual = Beneficio neto / (1 + r/100)'n = ao 1,..,i
Se deber estudiar en cuntos aos se recupera la inversin realizada
inicialmente, o bien, si en un perodo de aos fijado previamente se
retoma la inversin y, por tanto, es viable el proyecto.
Si la inversin es el CO, se determinar la viabilidad del proyecto
consultando la siguiente tabla:
178 ANAUSIS COSTE-BENEFICIO
Ao COSTE BENEFICIO VALOR ACTUAL
O CO
1 C1 B1 V.A
I
=(B
I
-C
I
)/(l +r/100)
2 C2 B2 V.A,. =(B
2
-c;)/(1+r/100?
V.Au =(B
n
-C
n
)/(l +r/100)n
n en Bn
El proyecto ser viable si I:VAi > CO a lo largo del perodo fijado.
VERSION2
El Anlisis Coste-Beneficio se utiliza en las siguientes actividades de la
e t o d o l o ~
FASE O:
TAREA PSI 5.3:
TAREA PSI 6.3:
FASE 1:
TAREA ARS 4.2:
Plan de Sistemas de Informacin.
Diagnstico de la situacin actual.
Determinacin de prioridades de desarrollo.
Anlisis del Sistema.
Seleccin de una alternativa.
PRUEBAS
7. PRUEBAS
INDICE
7.1. INTRODUCCION. . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 183
7.1.1 Realizacin de las pruebas
7.1.2 Principios bsicos de pruebas
7.2. DISEO DE JUEGOS DE PRUEBA. . . . . . . . . . . . . . .. 184
7.2.1 Tipos de prueba
7.2.2 Pruebas de tipo Caja Blanca
181
7.2.2.1
7.2.2.2
7.2.2.3
7.2.2.4
Prueba de cobertura de sentencias
Prueba de cobertura de condicin
Complejidad cic10mtica
Ventajas de las pruebas tipo Caja Blanca
7.2.3 Pruebas de tipo Caja Negra
7.2.3.1
7.2.3.2
7.2.3.3
7.2.3.4
Particiones de equivalencia
Anlisis de valores lmite
Valores tpicos de error
Valores imposibles
7.3. PRUEBAS UNITARIAS Y DE INTEGRCION 196
7.3.1 Desarrollo incremental
7.3.2 Estrategias de integracin
7.3.2.1
7.3.2.2
7.3.2.3
7.3.2.4
Estrategia de arriba a abajo (Top-Down)
Estrategia de abajo a arriba (Bottom-Up)
Estrategias combinadas
Comparacin de estrategias
182
PRUEBAS
7.4. PRUEBAS DEL SISTEMA Y DE ACEYfACION ...... 200
7.4.1 Pruebas globales
7.4.1.1 Pruebas funcionales
7.4.1.2 Pruebas de comunicaciones
7.4.1.3 Pruebas de rendimiento
7.4.1.4 Pruebas de volumen
7.4.1.5 Pruebas de sobrecarga
7.4.1.6 Pruebas de disponibilidad de datos
7.4.1.7 Pruebas de facilidad de uso
7.4.1.8 Pruebas de operacin
7.4.1.9 Pruebas de entorno
7.4.1.10 Pruebas de seguridad
7.4.2 Pruebas de aceptacin
7.5. PRUEBAS DE REGRESION ...................... 202
7.6. PLANIFICACION DE LAS PRUEBAS . ............. 202
7.7. TERMINACION DE LAS PRUEBAS . .............. 203
METODOLOGIA METRICA VERSION 2 ............ 204
PRUEBAS
7.1. INTRODUCCION
7. PRUEBAS
183
La prueba del equipo lgico es el mtodo usado ms a menudo para determinar
si ste funciona como debe. Probar no consiste en certificar que el equipo lgico
es correcto, antes bien, el objetivo principal de la prueba es ejecutar los
programas para encontrar errores.
El proceso de prueba es uno de los componentes de un conjunto de actividades
que permiten asegurar la calidad del equipo lgico, otras actividades que cabe
sealar en este sentido son:
El uso de una metodologa de desarrollo.
Las revisiones formales e informales.
Reuniones de revisin estructurada.
Gestin de la configuracin.
Uso de normas y estndares de desarrollo.
Pruebas estticas y dinmicas.
7.1.1 REALlZACION DE LAS PRUEBAS
Para cada sistema se efectuarn diferentes clases de prueba:
Pruebas Unitarias: Todos los Componentes del Sistema que
se desarrollen se prueban individualmente
para comprobar su correcto
funcionamiento.
Pruebas de integracin: Se prueba la integracin entre los
Componentes del Sistema para
demostrar que se pueden encajar
correctamente.
Pruebas de sistema: Se prueba el sistema globalmente.
184
PRUEBAS
7.1.2 PRINCIPIOS BASICOS DE PRUEBAS
Uno de los principios bsicos en la realizacin de las pruebas es que stas
han de ser llevadas a cabo por personas distintas a los diseadores de los
programas, tanto para evitar una simple verificacin de que el programa
funciona correctamente, como para comprobar que ese programa ha sido
concebido e interpretado correctamente.
Los casos de prueba deben ser escritos tanto para condiciones de entrada
invlidas o inesperadas como para condiciones vlidas y esperadas.
Un principio deducido de la experiencia y observacin de pruebas de
diferentes programas es que la probabilidad de encontrar errores
adicionales en una seccin del programa es proporcional al nmero de
errores ya encontrados en la misma seccin.
7.2. DISEO DE JUEGOS DE PRUEBA
7.2.1 TIPOS DE PRUEBA
Existen dos tipos de prueba:
PRUEBAS DE TIPO CAJA BLANCA, que permiten examinar la
estructura interna del programa.
PRUEBAS DE TIPO CAJA NEGRA, donde los casos de prueba
se disean considerando exclusivamente las entradas y las salidas
del sistema, sin preocuparse por la estructura interna del mismo.
A continuacin se describirn brevemente algunas tcnicas de diseo de
casos de prueba, dentro de estos dos tipos generales.
7.2.2 PRUEBAS DE TIPO CAJA BLANCA
Como se ha dicho, en este tipo de prueba se toma en consideracin la
estructura interna de los componentes del sistema. Se selecciona un
conjunto de caminos lgicos y se generan datos de prueba, determinando
los valores especficos que definen la ejecucin de esos caminos
seleccionados.
PRUEBAS 185
Se detallan seguidamente algunos criterios:
7.2.2.1 PRUEBA DE COBERTURA DE SENTENCIAS
Consiste en generar casos de prueba que permiten probar
cada sentencia dentro de un m6dulo, al menos una vez.
En la Figura 1 se muestra que este criterio se vera
satisfecho si los casos de prueba permitieran ejecutar
cualquier camino que contenga la secuencia A, B, C (donde
A, B, C representan bloques de c6digo). Esto ocurrira s610
si la condici6n es verdadera.
Este tipo de prueba no da una cobertura suficiente.
DIAGRAMA DE FLUJO IF-THEN-ELSE
Figura 1
186 PRUEBAS
PRUEBAS DE COBERTURA DE CONDICION
Consisten en disear juegos de prueba que consideren todos
los posibles valores de cada una de las condiciones.
En la figura anterior, los casos de prueba deben ejecutar por
tanto los caminos [A, B, C] y [A, C].
Evidentemente, este caso de prueba incluye al anterior.
La debilidad de este mtodo estriba en que no garantiza que
todos los caminos sean cubiertos. Por ejemplo, en un grupo
como el de la Figura 2, los caminos [D, E, G, H, K] Y[D, F,
G, J, K] cubren todas los ramas, pero los caminos [D, E, G,
J, K] Y[D, F, G, H, K] no.
El probar todos los caminos es un objetivo deseable, pero en
muchas ocasiones no se puede conseguir.
El nmero de caminos puede ser muy grande: si hay
bucles o repeticiones en el cdigo, el nmero de
posibles caminos podra ser conceptualmente infinito.
Alguno de los caminos puede ser imposible de ejecutar,
por ejemplo, en la figura 2 si el valor de X no se
cambia en los bloques E y G, el camino [D, E, G, J, K]
no se puede ejecutar nunca, ya que cada vez que la
condicin X > Oes verdad inmediatainente despus
del bloque D, debe ser tambin verdad en el bloque G.
El primer problema se soluciona ejecutando dos caminos
para cada bucle, uno que contenga el recorrido mnimo del
bucle (O 1 iteraciones, dependiendo de su estructura) y un
segundo que incluya al menos dos recorridos. En la Figura
3 se ejecutaran los caminos [L, N] y [L, M, ... M, N].
Es de destacar que estos criterios de diseo de casos de
prueba se pueden usar tanto en pruebas unitarias, como en
pruebas de integracin.
Por ejemplo, si en la Figura 1 el bloque B contiene una
llamada a otros Componentes del Sistema (CS), una prueba
PRUEBAS 187
que ejecutase un camino que contenga este bloque tambin
probar las interfases entre los CS.
EJEMPLO DE DIAGRAMA DE FLUJO MAS COMPLEJO
Figura 2
MAp Metodologa METRlCA Versin 2
188 PRUEBAS
L
v
F
M
N
EJEMPW DE ITERACION O BUCLE
Figura 3
PRUEBAS 189
7.2.2.3 COMPLEJIDAD CICWMATICA
McCabe sugiere el concepto de "Nmero Cic1omtico" para
definir otros criterios de prueba de caja blanca.
A partir de los diagramas de flujo de programa se dibujan
grficos de programa que contienen nodos que representan
bloques de cdigo y conexiones entre ellos, mostrando de
esta forma las ramas entre los bloques de cdigo. El Nmero
Cic1omtico NC de un programa (o de un mdulo de
implantacin) se define como:
e: nmero de conexiones
n: nmero de nodos
Se puede demostrar, de manera heurstica que cuanto mayor
es el nmero ciclomtico mayor es la complejidad del
programa. McCabe sugiere como criterio de cobertura de
caminos lgicos, el aadir al criterio de cobertura de
condicin el requisito de que, para un programa cuya
complejidad cic10mtica es NC, al menos se deban
seleccionar un nmero de caminos diferentes igual a NC.
En la Figura 4 se muestran los grficos de los programas de
las Figuras 2 y 3, as como el clculo del nmero ciclomtico.
190 PRUEBAS
GRAFICO DEL PROGRAMA DE LA FIGURA 2
Figura 4 (a)
GRAFICO DEL PROGRAMA DE LA FIGURA 3
Figura 4 (b)
PRUEBAS 191
7.2.2.4 VENTAJAS DE LAS PRUEBAS TIPO CAJA BLANCA
La principal ventaja a destacar es la posibilidad de verificar
que los criterios seleccionados han sido satisfechos.
Entre los inconvenientes se pueden observar los siguientes:
Se obtiene un nmero elevado de caminos posibles de
prueba y los criterios indicados anteriormente no
proporcionan muchos medios para cuantificar los
posibles errores que puedan existir en caminos no
probados.
No se podr nunca demostrar la correccin absoluta de
los programas, incluso aunque se pudieran probar
todos los caminos.
La dependencia del diseo de los casos de prueba de
la estructura interna del programa, hace que este
diseo vare mucho dependiendo del diseador del
programa.
7.2.3 PRUEBAS DE TIPO CAJA NEGRA
En este tipo de pruebas se disean los casos de prueba y los datos de
prueba a partir de las especificaciones funcionales, buscando probar
completamente:
Las funciones realizadas por el sistema.
El cumplimiento de los objetivos del sistema.
Las reacciones del sistema ante los estmulos exteriores.
Las transacciones manejadas por el sistema.
A continuacin se describen algunos criterios.
192
PRUEBAS
7.2.3.1 PARTICIONES DE EQUIVALENCIA
El gran problema en la elaboracin de juegos de prueba es
seleccionar el subconjunto de todas las entradas posibles al
programa.
Las dos propiedades que deben cumplir estos subconjuntos
son:
Reducir significativamente el nmero de los otros casos
de prueba.
Cubrir un conjunto extenso de otros casos de prueba
posibles.
La primera propiedad indica que se debe invocar el mayor
nmero posible de condiciones de entrada diferentes a fin de
minimizar el nmero total necesario de casos.
La segunda propiedad implica que se debe procurar partir el
dominio de entrada de un programa en un nmero finito de
clases de equivalencia. Con esto se pretende conseguir que
la prueba de un valor representativo de la clase de
equivalencia, sea equivalente a la prueba de otro caso de
prueba perteneciente a la misma clase de equivalencia.
La realizacin de casos de prueba por medio de particiones
de equivalencia consta de dos pasos:
1. Identificacin de las clases de equivalencia.
2. Definicin de los casos de prueba.
Las clases de equivalencia se identifican tomando cada
condicin de entrada (generalmente una sentencia o qase en
la especificacin) y dividindola en dos o ms grupos.
Para realizar esta tarea se puede emplear la tabla que
aparece en la Figura 5.
PRUEBAS 193
Condicin de entrada Clases de equivalencia Clases de equivalencia
vlidas invlidas
TABLA DE ENUMERACION DE LAS CLASES DE EQUIVALENCIA
Figura 5
En dicha tabla por cada condicin externa se establecen clases de
equivalencia vlidas, que representan las entradas vlidas al programa y
clases invlidas, que representan todos los otros estados posibles de la
condicin, es decir, los valores errneos de entrada.
El segundo paso es identificar los casos de prueba para cada clase de
equivalencia, esto se realiza en los pasos siguientes:
1. Asignar un nmero nico a cada clase de equivalencia.
2. Hasta que todas las clases de equivalencia hayan sido cubiertas por
casos de prueba, escribir un nuevo caso de prueba que cubra tantas
clases de equivalencia vlidas no cubiertas como sea posible.
3. Hasta que todas las clases de equivalencia invlidas hayan sido
cubiertas por casos de prueba, escribir un caso de prueba para
cubrir una y solo una de las clases de equivalencia no cubiertas.
Un ejemplo de clases de equivalencia, con su numeracin se muestran en
la Figura 6:
194
Condicin de entrada Clases de
equivalencia vlidas
PRUEBAS
Clases de
equivalencia
invalidas
Nmero de descriptores de uno (1). > uno(2) ninguno(3)
disposicin
1-6(4) Tamao del nombre de la disposicin 0(5). > 6 (6)
Nombre de la disposicin tiene letras(7) tiene algn otro
tiene nmeros(8) smbolo (9)
El nombre de la disposicin s (10) no (11)
comienza con una letra
Nmero de dimensiones 1-7 (12) 0(13), > 7 (14)
El lmite superior es una constante (15). el nombre del
una variable de elemento de una
entero (16) disposicin (17).
otro (18)
Nombre de variable del entero tiene letras (19) tiene algn otro
tiene nmeros (20) smbolo (21)
Variable del entero comienza con s (22) no (23)
una letra
Constante -65534-65535 (24) < -65534 (25)
> 65535 (26)
Umite superior especificado s (27) no (28)
Umite superior con respecto al lmite mayor (29) menor (31)
inferior igual (30)
Umite inferior especificado negativo (32) >0 (34)
0(33)
El lmite inferior es
Lneas mltiples
una constante (35).
una variable entera
(36)
s (39).
Figura 6
el nombre del
elemento de una
disposicin (37).
otro (38)
no (40)
PRUEBAS 195
7.2.3.2 ANALISIS DE VALORES LIMITE
Cuando el valor que toma una variable est en un rango
determinado, los errores suelen ocurrir en los extremos de
dicho rango. Por ejemplo, si una variable toma valores entre
20 y 10.000, se deben escoger los siguientes valores entre los
casos de prueba:
19 (justo debajo del rango)
20 (el lmite inferior)
21 (justo dentro del rango)
Un valor cualquiera de la mitad del rango
9.999 (justo debajo del lmite superior)
10.000 (el lmite superior)
10.001 (justo por encima del rango)
Si los recursos lo permiten, se podran aadir las pruebas
adicionales siguientes:
Valores negativos.
Al menos un valor positivo menor que 19.
Algn valor muy superior a 10.000.
El anlisis de valores lmite se diferencia del criterio de las
particiones de equivalencia en que no se selecciona un
elemento representativo de la clase de equivalencia, sino que
se seleccionan uno o ms elementos de manera que cada
margen de la clase de equivalencia es objeto de una prueba.
7.2.3.3 VALORES TIPICOS DE ERROR
Ciertos valores son una fuente de error bastante comn, as
que se deben especificar entre los datos de prueba. La
naturaleza y funcionalidad del sistema a probar determinan
cules son los valores susceptibles de causar problemas.
198 lPRUEBAS
Una ventaja de esta estrategia es que las interfases entre los mdulos son
probadas en una fase temprana y con frecuencia.
7.3.2.2 ESTRATEGIA DE ABAJO A ARRIBA (BOTI'OMUP)
En este caso se r ~ primero los componentes de ms bajo
nivel [E, F] Yse crean mdulos conductores para simular a
los mdulos que los llaman. A continuacin se desarrollarn
los mdulos B, C, D y se probarn. Por ltimo dichos
mdulos se combinarn con el mdulo A que los llama. Los
mdulos auxiliares son necesarios en raras ocasiones. Este
tipo de enfoque de las pruebas permite un desarrollo ms en
paralelo que el enfoque de arriba a abajo, pero presenta
mayores dificultades a la hora de planificar y de gestionar.
7.3.2.3 ESTRATEGIAS COMBINADAS
A menudo es til aplicar' las estrategias anteriores
conjuntamente. As, se desarrollarn partes del sistema de
forma "top-down", mientras que los componentes ms crticos
en el nivel ms bajo se desarrollarn ''bottom-up''. En este
caso es necesaria una planificacin cuidadosa y coordinada
de modo que los componentes individuales se "encuentren"
en el centro.
7.3.2.4. COMPARACION DE ESTRATEGIAS
En la siguiente tabla se representa un cuadro comparativo
entre ambos enfoques.
PRUEBAS
ENFOOUE DE ARRIBA A ABATO
199
1.
2.
3.
VENTAJAS
Ventajosa si aparecen fallos grandes
en la parte superior del programa
Una vez incorporadas las funciones
de entrada/salida, resulta fcil la
representacin de casos de prueba
La estructura previa del programa
permite demostraciones y ayuda a
mantener la moral
1.
.2.
3.
INCONVENIENTES
Se requieren mdulos auxiliares
Los mdulos auxiliares son a
menudo ms complicados de lo que
al principio parece
Antes de incorporar las funciones de
entrada/salida, la representacin de
los casos de prueba es difcil
VENTAJAS
4. Las condiciones de prueba pueden
ser imposibles, o muy difciles de
aear
5. La observacin de la salida de la
prueba es ms difcil
6. Puede dar lugar a pensar que prueba
y diseo se pueden superponer
7. Induce a retrasar la terminacin de
la prueba de ciertos mdulos
ENFOOUE DE ABATO A ARRIBA
INCONVENIENTES
1.
2.
Ventajosa si aparecen fallos grandes
en la parte inferior del programa
Las condiciones de la prueba son
ms fciles de aear
1.
2.
Se requieren mdulos impulsores
El programa, como una entidad, no
existe hasta que es agregado el
ltimo mdulo
3. Es ms fcil la observacin de los
resultados de la prueba
200 PRUEBAS
7.4. PRUEBAS DEL SISTEMA Y DE ACEPTACION
7.4.1. PRUEBAS GWBALES
Una vez que se han probado los componentes individuales y se han
integrado, se ha de probar el sistema global. En esta etapa pueden
distinguirse los siguientes tipos de pruebas, cada uno con un objetivo
claramente diferenciado:
7.4.1.1 PRUEBAS FUNCIONALES
Consisten en determinar que se han cumplido los objetivos
del sistema y .que ste realiza correctamente fcodas las
funciones que se han detallado en las especificaciones del
sistema.
7.4.1.2 PRUEBAS DE COMUNICACIONES
Determinan que las interfases entre los componentes del
sistema funcionan adecuadamente. Esto se refiere tanto a las
comunicaciones entre dispositivos remotos, como a las
interfases entre diferentes mdulos dentro del mismo
ordenador. Asimismo se han de probar las interfases
hombre/mquina.
7.4.1.3 PRUEBAS DE RENDIMIENTO
Consisten en determinar que los tiempos de respuesta estn
dentro de los intervalos establecidos en las especificaciones
del sistema.
7.4.1.4 PRUEBAS DE VOLUMEN
Consisten en examinar el funcionamiento del sistema cuando
est trabajando con grandes volmenes de datos, simulando
las cargas de trabajo esperadas.
7.4.1.5 PRUEBAS DE SOBRECARGA
Consisten en comprobar el funcionamiento del sistema en el
umbral lmite de los recursos, sometindole a cargas masivas.
El objetivo es establecer los puntos extremos en los
cuales el sistema empieza a operar por debajo de los
requisitos establecidos.
PRUEBAS 201
7.4.1.6 PRUEBAS DE DISPONIBILIDAD DE DATOS
Consisten en demostrar que el sistema puede recuperarse
ante fallos, tanto de equipo fsico como lgico, sin prdidas
indebidas de datos.
7.4.1.7 PRUEBAS DE FACILIDAD DE USO
Consisten en comprobar la adaptabilidad del sistema a las
necesidades de los usuarios, tanto para asegurarse de que se
acomoda al modo habitual de trabajo de stos, como para
determinar si les facilita su trabajo a la hora de introducir
datos en el sistema y de beneficiarse de las respuestas del
mismo.
7.4.1.8 PRUEBAS DE OPERACION
Consisten en comprobar los procedimientos de operacin,
incluyendo los procedimientos de inicio y fin de trabajo y la
facilidad de operacin.
7.4.1.9 PRUEBAS DE ENTORNO
Consisten en verificar las interacciones del sistema con otros
sistemas dentro del mismo entorno.
7.4.1.10 PRUEBAS DE SEGURIDAD
Consisten en verificar los mecanismos de control de acceso
al sistema para evitar alteraciones indebidas en los datos.
7.4.2 PRUEBAS DE ACEPTACION
Son aquellas pruebas que realiza el usuario con el objeto de comprobar
si el sistema es aceptable para l. Estas pruebas son del mismo tipo que
las mencionadas anteriormente, pero son determinadas por el usuario, en
lugar de serlo por el equipo de desarrollo.
Un tipo especial de estas pruebas es el de la ejecucin en paralelo con el
viejo sistema, para comparar los resultados producidos por ambas
ejecuciones.
202 PRUEBAS
7.5. PRUEBAS DE REGRESION
Cada vez que se hace una modificacin en el sistema tanto para corregir un error
como para aadir una mejora, se han de reejecutar una parte de las pruebas
previamente realizadas. No basta con probar slo los componentes modificados
o aadidos, o las funciones que en ellos se realizan; cualquier componente del
sistema puede haber sido afectado por el cambio y se ha de tener cuidado de no
introducir nuevos errores. Aunque la mayora de las pruebas de regresin tienen
lugar en la fase de mantenimiento, algunas pueden tener lugar en la fase de
implantacin del sistema.
Por ltimo hay que tener en cuenta que, a medida que se van resolviendo
problemas detectados durante las pruebas, puede ocurrir que haya que rehacer
las pruebas realizadas al principio.
7.6. PLANIFICACION DE LAS PRUEBAS
La Fase de Pruebas, por su envergadura e importancia, necesita una organizacin
seria y fiable.
Ante una fase de pruebas, se debe tomar como axioma que se van a encontrar
errores.
Los componentes de una planificacin sern:
Objetivos: Definir los objetivos de cada fase de las pruebas.
Criterios de terminacin: Especificar cuJ;ldQ se deben acabar las pruebas.
Cronologa: Fijar los tiempos necesarios para cada fase (diseo, escritura,
ejecucin).
Responsabilidades: Especificar los responsables de cada fase, as como
quin corregir los errores detectados.
Bibliotecas de casos de prueba y normas: Crear una sistemtica de
identificacin, escritura y almacenamiento de casos de prueba.
Herramientas: Establecer cules sern las herramientas de prueba que se
van a utilizar.
Tiempo de mquina: Determinar el tiempo de computacin que se
necesita .en cada fase del proyecto de prueba.
PRUEBAS 203
Configuracin del equipo: Detallar la necesidad de configuraciones
especiales de equipo o de algn perodo concreto.
Integracin: Describir el plan de integracin del sistema.
Mtodos de seguimiento: Especificar los mtodos que se han de utilizar
en las pruebas.
Depuracin: Definir un mecanismo para informar sobre los errores
detectados, para seguir el proceso de las correcciones y para incorporar
stas al sistema.
7.7. TERMINACION DE LAS PRUEBAS
Es dificil asegurar que el ltimo error detectado, era el nico que quedaba. Sin
embargo, existen mtodos para mostrar cundo est prximo el final. Los dos ms
comunes son:
Terminar la prueba cuando el tiempo establecido para la misma ha
expirado.
Terminar la prueba cuando todos los casos de prueba se ejecutan sin
detectar errores.
La inutilidad del primer mtodo no es necesario explicarla. El segundo mtodo
tampoco es ptimo porque predispone a generar casos de prueba sencillos y que
el programa los pase sin errores para finalizar la fase de pruebas lo antes posible.
Otros mtodos ms complicados de aplicar pero ms efectivos son:
Estimacin del nmero total de errores del programa.
Estimacin del porcentaje de estos errores que pueden encontrarse
fcilmente.
Estimacin de qu fraccin de errores se origina en procesos particulares
de diseo.
Para realizar cualquiera de estas estimaciones es necesario contar con una
historia o experiencia previa que permita definir <fichas estimaciones.
204 PRUEBAS
Un problema que puede surgir al utilizar estos mtodos de estimacin, es que
dicha estimacin sea demasiado alta (sobre-estimacin) y el programa tenga
menos errores de los estimados; entonces, nunca se terminaran las pruebas
porque nunca se llegara a ese lmite. Este problema se soluciona poniendo
tambin limitaciones de tiempo.
Otro criterio de terminacin es sealar grficamente el nmero de errores
encontrados por unidad de tiempo durante la fase de pruebas. Examinando la
forma de la curva se puede determinar a menudo si conviene continuar una fase
de prueba o terminarla.
PIA 1:
7.8. UTILlZACION DE LA TECNICA EN LA METODOWGIA METRICA
VERSION 2
Las tcnicas de prueba se utilizan en las diferentes fases, actividades y tareas de
la Metodologa METRICA Versin 2.
PRUEBAS UNITARIAS Y DE INTEGRACION.
FASE 3: CONSTRUCCION DE SISTEMAS.
DCS 2.2.: Preparacin, ejecucin y evaluacin de las pruebas
unitarias.
DCS 3.1: Preparacin y ejecucin de pruebas de integracin
PRUEBAS DEL SISTEMA Y DE ACEPTACION
FASE 4: IMPlANTACION DE SISTEMAS
DISEAR Y REAliZAR LAS PRUEBAS DEL
SISTEMA.
FACfORES CRITICOS DE EXITO
8. FACTORES CRITICOS DE EXITO
INDICE
8.1. INTRODUCCION y OBJETIVOS o o 209
8.2. DESCRIPCION DE LA TECNICA .... o'. o o o o. o. 209
8.2.1. Generalidades
8.2.2. Procedimiento de definicin de los
factores crticos de xito
8.3. UTIUZACION DE LA TECNICA EN
LA METODOWGIA o o o 218
1!J7
FACTORES CRITICOS DE EXITO
8. FACTORES CRITICOS DE EXITO
209
La tcnica de los Factores Crticos de Exito (FCE), resultado de los trabajos de
John F. Rockart, tiene como objetivo ayudar a la planificacin de las actividades
y recursos de cualquier Organizacin, as como delimitar las reas clave de la
misma facilitando la asignacin de prioridades dentro de ella.
Rockart defini los factores crticos de xito como "el nmero limitado de reas
en las cuales los resultados, si son satisfactorios, asegurarn un funcionamiento
competitivo y exitoso para la Organizacin.
Esta tcnica implica, para su aplicacin, los siguientes puntos bsicos:
Definir los objetivos globales de la Organizacin.
Definir una unidad de medida para evaluar el funcionamiento de la
Organizacin con respecto a esos objetivos.
Identificar los factores clave que contribuyen a ese funcionamiento.
Identificar las relaciones causa-efecto entre objetivos y factores clave.
8.2. DESCRIPCION DE LA TECNICA
8.2.1. GENERALIDADES
El anlisis de los Factores Crticos de Exito permite identificar aquellas
reas de la Organizacin, as como aquellos factores del entorno cuyo
funcionamiento adecuado o evolucin favorable permitirn la implantacin
con, xito de una estrategia determinada. Como consecuencia de la
identificacin de estas reas internas o factores externos se podr proceder
a una aplicacin adecuada de los recursos de la Organizacin con el fin de
conseguir una eficacia ptima de esta estrategia.
De lo anterior, se deduce que se deben considerar para la definicin de
los FCE tanto los factores externos como los internos de la Organizacin.
Con esta perspectiva, las siguientes definiciones permiten dar una idea del
significado de los FCE:
210 FACI'ORES CRITICOS DE EXITO
Una actividad dentro de la Organizacin que se debe realizar con
especial atencin.
Un suceso o eventualidad que ocurre en el entorno externo de la
Organizacin y sobre el cual se puede tener o no control.
Un rea de la Organizacin cuyo funcionamiento debe situarse a
un nivel competitivo con el entorno.
Es conveniente, para aclarar este concepto de los FCE, diferenciar entre
Factores de Exito y Factores Crticos de Exito:
Un Factor de Exito es algo que debe ocurrir (o debe no ocurrir) para
conseguir un objetivo. Este Factor de Exito se define como crtico si su
cumplimiento es absolutamente necesario para cumplir los objetivos de la
Organizacin, por lo cual requiere una especial atencin por parte de los
rganos gestores, con el fin de asegurar, que se dedican los mejores
recursos a la ejecucin o realizacin de dicho Factor de Exito.
Se puede justificar el establecer esta diferencia entre Factores de Exito
(FE) y Factores Crticos de Exito (FCE) por dos razones:
Desde un punto de vista puramente metodolgico, de aplicacin de
la tcnica, es ms efectivo el separar la consideracin de todos los
FE de la Organizacin, de la t:valuacin de cules son realmente
FCE.
Desde un punto de vista de eficacia dentro de la organizacin, la
definicin de un nmero demasiado elevado de FCE desvirtuara
el sentido de esta tcnica
Por ltimo, se debe hacer nfasis en la diferencia existente entre Factores
de Exito y Objetivos de la Organizacin:
Objetivos son los "fines" hacia los cuales se dirige el esfuerzo y el
trabajo de la Organizacin.
Factores de Exito, y como consecuencia FCE, son los "medios" o
requisitos que se deben cumplir para alcanzar los objetivos. Para
cada objetivo se debe definir al menos un Factor de Exito.
FACTORES CRITICaS DE EXITO 211
Esta distincin nos ayudar a la hora de delimitar y definir con claridad
los objetivos: estos sern importantes como un fin en s mismos. Si
consideramos un objetivo importante slo como medio de conseguir otros
objetivos, se considerar dicho objetivo como un Factor de Exito.
8.2.2. PROCEDIMIENTO DE DEFINICION DE WS FACfORES CRITICOS
DE EXITO.
A la hora de definir los Factores Crticos de Exito de la Organizacin, es
necesario que los objetivos que persigue la Organizacin estn claramente
definidos, dado que su especificacin servir de base para el estudio de los
FCE.
El anlisis de los FCE corresponder, por una parte, al equipo del
proyecto, el cual recoger informacin sobre la Organizacin y sus
objetivos mediante entrevistas con los gestores de la misma. Asimismo,
como resultado de estas entrevistas se obtendr una primera visin de los
directivos acerca de los medios o requisitos para alcanzar estos objetivos.
Estos requisitos permitirn obtener una lista inicial de los factores de
xito, la cual se depurar en etapas posteriores del anlisis.
Todas las labores de depuracin, refinamiento y consolidacin de los FCE
han de realizarse de forma conjunta por el equipo del proyecto y los
gestores de la Organizacin. Para ello ser conveniente realizar, ms que
entrevistas individuales, reuniones en grupo entre todos los gestores, dado
que as se obtendr un conjunto reducido de factores crticos de xito
desde una perspectiva "global" de la Organizacin, obviando de este modo
el peligro de una excesiva proliferacin de FCE, ocasionada por una visin
particularista de los gestores de sus reas concretas de responsabilidad
dentro de la Organizacin.
El procedimiento para un anlisis estructurado de los FCE constar de los
siguientes pasos:
1) Elaborar una lista de los objetivos de la Organizacin.
2) Depurar esta lista de objetivos.
3) Identificar los factores de xito.
4) Eliminar los factores de xito no crticos.
5) Agrupar los factores de xito de acuerdo con los objetivos.
212
6)
7)
8)
FACTORES CRITICOS DE EXITO
Identificar los componentes de estos factores de xito.
Seleccionar los factores crticos de xito.
Finalizar el estudio de los factores crticos de xito.
A continuacin, se realizar un estudio detallado de estos pasos:
1) Elaborar una lista de los objetivos de la Organizacin.
Se determinar la misin, metas y objetivos de la Organizacin. Es
conveniente ser explcitos en la especificacin de objetivos,
intentando cuantificarlos en la medida de lo posible.
Como ejemplo de una especificacin de objetivos de una
organizacin, podemos suponer, una Empresa que se plantease:
Alcanzar una cifra de ventas de 100 millones de pesetas.
Obtener un beneficio antes de impuestos de 20 millones.
Incrementar el margen bruto en las ventas en torno a un
10%.
Mantener los gastos de funcionamiento en un 20% de las
ventas.
2) Depurar la lista de objetivos.
En este paso se revisar la lista de objetivos obtenida en el paso
anterior para asegurar que dichos objetivos constituyen un fin en s
mismos y no meramente un medio para obtener otro objetivo de la
lista, en cuyo caso se considerara como un Factor de Exito.
En el ejemplo que sigue, los objetivos de "Incrementar el margen
bruto en las ventas en tomo al 10%" y "Mantener los gastos de
funcionamiento en un 20% de las ventas", son un medio para
conseguir los beneficios de 20 millones, por lo cual se eliminarn
de la lista de objetivos y se considerarn Factores de xito.
En este caso tendramos:
FACTORES CRITICaS DE EXITO 213
Objetivos Factores de xito
Alcanzar una cifra de
ventas de 100 millones
de pesetas.
Obtener un beneficio Incrementar el
antes de impuestos de margen bruto en las
20 millones de pesetas. ventas en tomo al
10%.
Mantener los gastos
de funcionamiento en
un 20% de las ventas.
3) Identificar los factores de xito.
Teniendo en cuenta el concepto de Factor de Exito como medio
necesario para alcanzar los objetivos especificados, se obtendr una
lista de factores de xito para cada uno de dichos objetivos,
contemplando tanto aquellos que dependen de la Organizacin
como aquellos externos que estn fuera de su control (legislacin,
comportamiento de la economa, etc.).
En este punto no es necesario preocuparse demasiado si se repiten
los factores de xito con los objetivos, o si un factor de xito para
un objetivo est estrechamente relacionado con otro objetivo. As,
en nuestro caso, y mediante entrevistas con los responsables de la
Organizacin se obtendra la siguiente tabla:
Objetivos Factores de Exito
Ventas de 100 Crecimiento del
millones mercado
Incrementar la cuota
de mercado
Beneficios antes de Incrementar ventas
impuestos de 20 Incrementar el margen
millones bruto en tomo al 10%
Mantener los gastos de
funcionamiento en un
20% de las ventas
214
4)
Eliminar los factores de xito no criticos.
Se utilizarn en este punto diferentes criterios para eliminar los
F.E., dependiendo de si los mismos estn dentro o fuera del control
de la Organizacin.
Como se ha dicho, esta seleccin ser realizada, mediante
reuniones en grupo, por los responsables de la Organizacin.
Los criterios que se seguirn son:
Factores de Exito dentro del control de la Organizacin.
Es el FE esencial para cumplir los objetivos?
Requiere especial cuidado en su realizacin, es decir,
recursos especialmente cualificados?
Si la respuesta a alguna de estas preguntas es "no", se eliminar el
FE de la tabla.
Factores de Exito fuera del control de la Organizacin.
Es el FE esencial para cumplir los objetivos?
Hay una probabilidad significativa de que el FE no ocurra?
Si no ocurre el FE Podran alterarse las estrategias con el
fin de minimizar el impacto de dicho incumplimiento,
suponiendo que hubiese suficiente tiempo disponible?
Si la respuesta a alguna de estas preguntas es "no" se elimina el FE
de la tabla. Esto se hace para no considerar aquellos FE que
ocurrirn casi con toda seguridad (en caso de una respuesta
negativa a la segunda pregunta) o aquellos FE cuyo no
cumplimiento impide cualquier tipo de accin correctiva (en el caso
de una respuesta negativa a la tercera pregunta).
En el ejemplo que se sigue, se decidi que el factor de xito
"Mantener los gastos de funcionamiento en un 20% de las ventas"
no exiga recursos especialmente cualificados para conseguirlo, por
lo cual se elimin de la lista.
FACfORES CRITICOS DE EXITO 215
millones mercado
Incrementar la cuota
de mercado
Beneficios antes de Incrementar ventas
impuestos de 20 Incrementar el margen
millones bruto en tomo al 10%
5) Agrupar los Factores de Exito de acuerdo con los objetivos.
Este paso permite depurar la tabla, dado que al analizar cada
objetivo por separado puede que los FE estn repetidos o sean
sinnimos de un objetivo.
En nuestro ejemplo el FE "Incrementar ventas" es sinnimo del
objetivo 'ventas de 100 millones", por 10 tanto se elimina.
millones mercado
Incrementar cuota de
mercado
Beneficios antes de Incrementar margen
impuestos 20 millones bruto
6) Identiticar los componentes de estos Factores de Exito.
En este paso se analizan los Factores de Exito para identificar 10
que se debe hacer para conseguir cada uno de estos FE
De la descomposicin de los FE se pueden encontrar componentes
que son verdaderamente crticos, mientras otros exigen menos
esfuerzo o recursos.
216 FACTORES CRITICaS DE EXITO
El objetivo de este anlisis es identificar de cinco a siete Factores
de Exito o componentes de estos factores que sean crticos, con el
fin ltimo de centrar el esfuerzo de la Organizacin en su
consecucin.
En el ejemplo que se est desarrollando se ha obtenido la siguiente
tabla:
Objetivos Factores de Euto Componentes de FE
Ventas 100 Crecimiento
millones del mercado
Incrementar Mejorar
cuota calidad
mercado
Mejorar
caractersticas
del producto
Beneficios Mejorar
antes de tiempos de
impuestos entrega
20 millones
Incrementar Reducir . Negociacin
margen costes laboral
bruto laborales.
. Automatiza-
cin
produccin
Mantener
incrementos
costes
material por
debajo de la
inflacin
7) Seleccionar los Factores Crticos de Exito.
217
Se usarn los criterios de seleccin ya especificados en el paso 4
para los niveles ms bajos de descomposicin, con el objeto de
obtener un nmero de FCE entre 5 y 7.
En la tabla siguiente se representan en negrita los FCE
seleccionados.
Objetivos Factores de Exito Componentes de FE
Ventas 100 Crecimiento
millones del mercado
Incrementar Mejorar
cuota calidad
mercado Mejorar
caractersticas
del producto
Beneficios Mejorar
antes de tiempos de
impuestos entrega
20 millones Incrementar Reducir . Negociacin
margen costes laboral
bruto laborales.
. Automatiza-
Mantener cin
incrementos produccin
costes
material por
debajo de la
Inflacin
8) Finalizar el estudio de los Factores Crticos de Exito.
En este paso se obtiene una lista final que representa las reas que
son cruciales para el xito de la Organizacin, y donde la direccin
debe enfocar su atencin.
Para los FCE controlables por parte de los directivos, se deben
asignar los recursos necesarios para garantizar su realizacin
o r r t ~ as como las herramientas e informacin necesarias para
218 FACTORES CRITICOS DE EXITO
dicha realizacin. Asmismo, se deben establecer procedimientos
que permitan asegurar un seguimiento y realimentacin sobre el
grado de cumplimiento de dichos Factores Crticos.
Para aquellos FCE no controlables, son absolutamente necesarios
procedimientos que permitanobtener informacin puntual sobre los
mismos. Estos procedimientos proporcionan seales de aviso de
manera que se puedan definir e implantar planes de contingencia.
8.3. UTILlZACION DE LA TECNICA EN LA METODOWGIA METRICA V.2
Esta tcnica se utiliza en la Fase O: "Plan de Sistemas de InformacJin" en la
tarea:
PSI 2.2: Identificacin de requisitos.
TECNICAS MATRICIALES
9. TECNICAS MATRICIALES
INDICE
9.1. INTRODUCCION 223
9.2. MATRIZ PROCESOS-ENTIDADES 224
9.3. ANAUSIS DE AFINIDAD 237
9.4. UTIUZACION DE LA TECNICA EN LA
221
9. TECNICAS MATRICIALES
9.1. INTRODUCCION
223
Dentro de la Metodologa METRICA Versin 2 se designa con el nombre de
tcnicas matriciales a la representacin cruzada de diferentes entidades u objetos
de inters para la Organizacin y que permitirn:
Conocer la realidad actual en cuanto a sus funciones, informacin
manejada, distribucin geogrfica, etc.
Sentar las bases para una posible reorgariizacin de las funciones con
objeto de aumentar su eficacia.
Definir nuevos sistemas de informacin para la Organizacin.
Ayudar a definir prioridades en el desarrollo de nuevos sistemas.
Las diferentes representaciones matriciales que se recogen en la metodologa son
las siguientes:
Matriz Procesos-Entidades de Datos: que permite representar el
tratamiento lgico de las funciones sobre los datos del sistema.
Matriz Procesos-Organizacin: que permite representar tanto la
distribucin geogrfica de las funciones de la Organizacin, como las
responsabilidades de los distintos departamentos en que se estructura.
Matriz Aplicaciones-Ficheros de Datos: que permite conocer la situacin
actual de los sistemas de informacin existentes, en cuanto a las
aplicaciones en funcionamiento y los datos que manejan.
Matriz Aplicaciones-Funciones: que permite representar el grado de
cobertura que las aplicaciones existentes tienen sobre las funciones que
desarrolla, o tiene previsto desarrollar la Organizacin.
Matriz Ficheros de Datos Actuales-Entidades de Datos: que permite
representar la adecuacin de los ficheros de datos existentes a las
necesidades de informacin de la Organizacin.
Como se puede observar en este conjunto de matrices, existe un grupo cuyo
objetivo bsico es realizar el estudio detallado de la situacin actual y el grado
224 TECNICAS MA1I'RICIALES
de satisfaccin de las necesidades de informacin de la Organizacin con los
sistemas existentes formado por:
Matriz Aplicaciones-Ficheros de Datos.
Matriz Aplicaciones-Funciones.
Matriz Ficheros de Datos actuales-Entidades de Datos.
Por otra parte, la Matriz Procesos-Organizacin, tiene una funcin meramente
descriptiva de la estructura organizativa: sus funciones, responsabilidades y
distribucin.
Por todo ello haremos nfasis en este estudio en la descripcin detallada de la
Matriz Procesos-Entidades de Datos, puesto que constituye el punto de partida
tanto para la identificacin de nuevos sistemas como para la asignacin de
prioridades a los mismos.
9.2. MATRIZ PROCESOS-ENTIDADES.
Para representar la Matriz Procesos-Entidades se seguirn los pasos siguientes:
1. Identificar los procesos de la Organizacin.
2. Identificar las entidades de datos de la Organizacin.
3. Representar de forma matricial los procesos frente a las entJidades de
datos.
4. Reorganizar la matriz.
5. Determinar subsistemas.
6. Asignar prioridades de desarrollo.
A continuacin se describen en detalle cada uno de los pasos:
1. Identificar los procesos de la Organizacin.
A partir de entrevistas y reuniones en grupo con los responsables de la
Organizacin se identifican los diferentes procesos de la misma. Se puede
establecer una jerarqua dentro de los diversos procesos:
Nivel funciones de la Organizacin.
Nivel procesos que detallan cada una de las funciones.
225
El grado de detalle a que se llega en la identificacin de los procesos en
que se descomponen las funciones, estar ntimamente relacionado con el
grado de detalle con que se definan las entidades de datos de la
Organizacin (resultado de la realizacin del paso 2).
El objetivo es obtener una Matriz Procesos-Entidades homognea en su
grado de detalle. Por ello los pasos 1 y 2 se realizarn simultneamente.
Un criterio recomendable para desglosar las funciones de la Organizacin
es fijarse en el ciclo de vida de los servicios y/o productos que
proporciona dicha Organizacin. As, se consideran cuatro etapas del ciclo
de vida del producto o servicio:
Etapa 1: Necesidades, planificacin, evaluacin y control.
Se engloban aqu todas las funciones y procesos que
determinan la cantidad que se requiere del producto o
recurso, la planificacin necesaria para obtener dichos
productos o recursos y la evaluacin y seguimiento de este
plan.
Etapa 2: Adquisicin o implantacin.
Comprende el conjunto de funciones y procesos que se
realizan con el fin de desarrollar un producto o servicio o para
obtener los recursos que sern utilizados en su desarrollo. Por
ejemplo: contratacin de personal en un Ministerio,
adquisicin de pelculas en una Filmoteca, etc.
Etapa 3: Mantenimiento.
Comprende el conjunto de funciones y procesos destinados a
formar, perfeccionar, modificar o mantener ]os recursos de
apoyo y a almacenar o controlar la evolucin del producto o
servicio. Por ejemplo: seguimiento de expedientes, seguimiento
de los servicios profesionales y trayectoria administrativa del
personal.
226 TECNICAS MATRICIALES
Etapa 4: Fin o Disposicin.
Se engloban aqu el conjunto de funciones y procesos que
ponen fin a la responsabilidad de la organizacin respecto a
un determinado producto o servicio o que determinan el uso
final de un recurso. Por ejemplo: el cese o jubilacin de
personal, la suspensin de un servicio por parte de un
Organismo Oficial.
Adems de considerar cada una de las cuatro etapas del ciclo de vida
mencionadas, ser conveniente fijarse en tres fuentes principales para
identificar los procesos:
(a) Procesos de planificacin y control.
(b) Procesos que tratan productos o servicios que produce o presta la
Organizacin.
En este caso se considera que la Organizacin tiene un grupo
principal de productos o servicios, o bien que la administracin de
los mismos sigue procesos similares.
Es conveniente fijarse previamente en los objetivos de la
Organizacin con el fin de especificar en detalle el producto o
servicio. Por ejemplo, en una Filmoteca un estudio en detalle
mostrara que el producto no son meramente las pelculas sino que
habra que considerar como servicios:
1. Fomento de la produccin nacional de pelculas.
2. Divulgacin de las artes cinematogrficas.
(c) Procesos que tratan los recursos de apoyo que necesita la
organizacin para producir o prestar servicios.
Se podran considerar cuatro recursos bsicos:
Materiales.
Finanzas.
Instalaciones.
Personal.
la evolucin del ciclo de vida de productos, servicios y recursos,
permitir obtener todos los procesos del tipo b) y c). En cuanto a los
procesos del tipo a), no es til considerar el ciclo de vida de los
productos y recursos dado que estos procesos no se orientan
nicamente a productos y recursos.
Una vez identificados todos los procesos se consolidarn, atendiendo a:
La necesidad de reducir inconsistencias de nivel, dado que pueden
haberse identificado funciones de la Organizacin, de un grado de
detalle distinto. A la hora de representarlos en una matriz convendr
tener claro el nivel de detalle que se quiera alcanzar y procurar que
los procesos identificados sean acordes con dicho nivel.
La posibilidad de agrupar procesos similares. Por ejemplo: el
proceso de compra de un producto ser similar al proceso de
adquisicin de un recurso: Esto implica la necesidad de combinarlos.
El resultado de la consolidacin ser, por ejemplo, una tabla del
tipo:
Planificacin de la
Organizacin.
Finanzas.
Planificacin de Productos.
Materiales.
Recursos Humanos.
Anlisis de mercado.
Revisin de la gama de productos.
Previsin de ventas.
Planificacin financiera.
Gestin de inmovilizado.
Financiacin.
Diseo de productos.
Poltica de precios.
Mantenimiento de
especificaciones de producto.
Recuentos de materiales.
Compras.
Recepcin.
Control de inversiones.
de personal.
Contratacin.
Formacin.
Incentivos.
228
2.
Identificacin de las entidades de datos de la Organizacin.
Se pueden considerar dos niveles de detalle en la identificacin de los
datos del sistema:
Clases de datos o agrupaciones lgicas de datos.
Entidades de datos.
En una primera aproximacin se pueden identificar clases de datos, o
categoras de informacin de tal forma que existan relaciones lgicas entre
ellas. Para ello, una vez identificados los procesos se identifican los datos
creados, controlados y utilizados en estos procesos, as como los datos
pertenecientes a ficheros comunes, etc. Dichos datos se agrupan para
formar las clases.
Dependiendo del grado de detalle alcanzado en la identificacin de los
procesos, nos quedaremos en este paso en las clases de datos identificados,
o se refinarn ms, llegando al nivel de entidades de datos.
Una entidad de datos es cualquier objeto sobre el que el sistema o la
Organizacin desea guardar informacin. Para su identificacin ser til
estudiar:
Los recursos utilizados por la Organizacin.
Los productos y servicios que presta.
Los documentos actualmente existentes.
Las necesidades futuras de informacin.
La identificacin de entidades dentro de una organizacin ha de ser
llevada a cabo por analistas expertos en el tipo de funciones o servicios
que realiza esta organizacin, en colaboracin con responsables de su
gestin.
Ejemplos de entidades pueden ser:
CLIENTE, EMPLEADO, FACTURA, HERRAMIENTA,
MAQUINA, VENDEDOR, UNIDAD ADMINISlRATIVA,...
TECNICAS MATRICIALES 229
Una vez identificadas las entidades de datos se puede dibujar un modelo
conceptual que represente asociaciones entre estas entidades (ver tcnica
de modelizacin de datos). A este nivel no es necesario, y en muchas
ocasiones no es factible en el caso de una gran Organizacin, describir con
mucho detalle las caractersticas de estas entidades, por lo cual slo se
definirn un par de atributos (O caractersticas que definan a las entidades)
de cada una. Por ejemplo, para la entidad empleado:
Nombre del empleado.
Categora.
3. Representar de forma matricial los procesos frente a las entidades de
datos.
Una vez identificados los procesos realizados por la Organizacin (paso 1)
y las entidades de datos o clases de datos utilizados por sta (paso 2), se
procede a representarlos en una matriz.
El .grado de detalle que se desee alcanzar en el conocimiento de la
Organizacin determinar qu es lo que se representa en la matriz. As
podramos representar:
Funciones - Clases de datos
Procesos - Entidades de datos.
Cuanto ms se detalle en la identificacin de los procesos, tanto ms
estable ser la matriz obtenida. Esto es as porque lo que se representa
son las actividades bsicas de la Organizacin y la informacin
"conceptual" que la misma maneja, y ambas son independientes de la
estructura organizativa existente y de la forma en que se manejan
actualmente los datos. Como consecuencia, se puede acometer un cambio
en la estructura de la organizacin sin modificar la matriz obtenida.
En la matriz se representar el tratamiento de los procesos sobre las
entidades de datos, mediante los smbolos:
C: Representa la creacin de los datos por los procesos.
U: Representa la utilizacin de los datos por los procesos.
Evidentemente, todas las entidades de datos han de ser creadas al menos
por un proceso. Esto nos proporciona un criterio adicional a la hora de
descomponer, puesto que si se identifica uD conjunto de datos (clase de
datos o entidad de datos) creado por ms de un proceso, puede ser
conveniente descomponer dicho conjunto de datos.
En la Figura 1 se representa una porcin de una Matriz Procesos-
Entidades de datos. Debido a que no se han representado todos los
procesos de la Organizacin aparecen entidades de datos no utilizadas ni
creadas.
4. Reorganizar la matriz
En este paso se modifica la secuencia de las entidades de datos (o clases
de datos) representadas en la matriz, con el siguiente criterio:
La entidad de datos creada por el primer proceso se mueve a la izquierda.
A continuacin se mueve a la izquierda la entidad de datos creada por el
segundo proceso (si existe).
El proceso contina para todas las entidades de datos. Como resultado
final se obtiene una matriz con la creacin de datos dispuesta en forma
triangular (es decir, las Coordenadas en la diagonal de la parte superior
izquierda a la inferior derecha).
En la Figura 2 se representa esta reorganizacin.
5. Determinar subsistemas.
En este paso se agrupan los procesos y datos en distintos subsistemas. La
definicin de los subsistemas no es un proceso algortmico, sino que
depende de la opinin subjetiva y experiencia del equipo de desarrollo.
Como resultado final se obtienen los derentes subsistemas que tienen
responsabilidad sobre la creacin y mantenimiento de las diferentes clases
o entidades de datos.
Aquellos procesos de uso de datos que quedan fuera de los subsistemas
seleccionados, representan un flujo de datos entre los diferentes
subsistemas.
En las Figuras 3, 4 Y 5 se representan los diferentes subsistemas
identificados, el flujo de comunicacin entre los mismos y una
denominacin de los posibles subsistemas a desarrollar.
==
(lI
8
Q.
1
&:
<:
(lI
...
5:
1:1
N
en
O
O
en
O
a:
1--'
a..
ENTIDADES

I
8

g
o

,2g
o
lI!
I
ffi o
l3 !11

g
5

!

;

"-"- ji:
N
W .. ffi
ANALlSlS DE MERCADO U U U U U
GAMA PROllUCTOS U U
PREVlSION VENTAS U C U U C U
U
U C
ADClUISICION CAPITAL U C U
DISEf'lO PRODUCTOS
U C C C
PFlECIOPFIODUCTOS U U C
ESPEClFIC.PROllUCTOS U C
REQUISITOS MATERIAL U U U U
ADClUISIC.MATERIAL
C U
U
F1ECEPCION MATERIAL
U U U U
CONTROL INVENTARIO
C U
PlANIFICAC.OPERAC U C
Iotj
- o
e
~
N
~
~
a
o
Q.
o
O"
~
~
~
<
(lI
...
21.
o-
I:l
N
en
O
en
w
O
oc
a..
ENTIDADES
~
<>
..:
!1
m
~
~ al ~
~
~
I
o
~ ~
~ ~
&g
ti ~ ?l
~ ?l
j
; ~ ~ s
l B ~
~ ~
lO lO
~
~ :>
I ~
i
:>
~
~
~ ~
a
2
~
Q.Q. :
Q. .. o Q. - ,
ANAUSIS DE MERCADO U U U
U U
GAMA PRODUCTOS U
U
PREVlSION VENTAS C C u u u U
PlANIRCAC.FINANCIERA C U
U
ADOUISICION CAPITAL U U C
DISEO PRODUCTOS u C
C C
PRECIO PRODUCTOS U C
U
ESPECIFIC.PRODUCTOS U C
REOUISITOS MATERIAL U U U U
ADOUISIC.MATERIAL
U
U
C
RECEPCION MATERIAL
U
U
U U
CONTROL INVENTARIO U
C
PlANIFlCAC.OPERAC
U C
233
(f)
W
O
O
t=
z
w
01HV'1VS
OOV31dn,
63.LSO:

SOl103d
SOOVd
":)NV:lti3n
"lN311N1
SVlN3/\

VNOZ
SVlN3/\
3lN31l::1
OSl!I1:)N
SOI'VlMl
SVN100vn
<>
1V1l13J.vn
<>
"lN311N1
<>
llOO30N3}
S3J.llVd
<>
0llJ.S3Yn
<>
"J.:lOOOlld
<>

0113SI0
SOJ.
<>
<>

-:lOOOlld

<>
0J.S3nd
<>
-nS311d
NOI:)v:)
:> <> <>
:> :>

I
ffi
i
8

!
g
8

i

g
I
a:
ti
lU
8
8

o
8
z
l!I
f

f f

o
8
ti

I
r
r 81

FIGURA 3
234
en
w
o
o
....
z
w
OIIfY1VS
OOY31dI'l:
S3J.SCY. ~
~ ~
SOOl03o:l
~ V d
"ONV:lY31'1
"lN3IIH1
SV1N:lA
~
~
VNOZ
SV1N:lA ~ ~
3lN3nO ~ ~
oQlno N
SOrt'1I\fIL
SVNII\OVI'I
o
1VI1l3J.VI'I
~ o
"lN3IIH1
1l0030N:lJ
~ o ~ ~
S3J.IlVd
o
0Il1S3VI'I
o
"lonOOlld
o
0lY3SI0
SOl
f
o o ~
-onOOlld
SVZNVNI:l
o
~
OlS3nd
o ~
~
-nS3lld
NOIOVO
~ ~ o o
~
-I:lINYld
~ ffi
...J
B
~
~
~
!
~
~
ffi
i
~
o ~
!
a:
~
;
g
~
ffi
I!!
r ::1
~ i5
~
~
>
~
z
~ ~
lE le
q
~
o
~
o
o
~
::1
fS
g ~
~
lE
~
: o
~
.2
8
o

~
:
i
~ lE
~
a
~ lE
~
~
6
8 ~ SI a: ~ a:
SOS3QOtjd
FIGURA 4
SOQla3d
"""....
:>
:>
:>
235
en
w
o
o
1-
Z
W
!

!

i
g ;/
Ili
8
i

lE

'"
g

> 11:

l!l

I
!
I
i
i

s g
i

:>
lIJ
lE

"
o 8
SOS300l::ld
m
FIGURAS
236
6.
Asignar prioridades de desarrollo.
Una vez identificados los subsistemas a desarrollar, se proceder a
determinar sus prioridades de desarrollo.
Puede ser conveniente para realizar esta tarea, clasificar los sistemas
identificados en los tipos siguientes:
Sistemas que realizan operaciones tpicas de proceso de datos; que
cubren el ncleo tradicional de tratamiento de datos, con tareas
predefinidas (clculo de nminas, sistemas de facturacin, etc.) y,
frecuentemente, un alto volumen de datos.
Sistemas de gestin de la informacin, definidos para facilitar
consultas sobre la informacin almacenada en el sistema,
proporcionar informes y, en resumen, facilitar la gestin autnoma
de la informacin por parte de los departamentos usuarios.
Sistemas de soporte a la toma de decisiones. Facilitan la labor de la
direccin, proporcionando una presentacin mejor de la informacin
para la toma de decisiones. Se caracteriza porque son sistemas sin
carga peridica de trabajo, es decir, su utilizacin no es predecible,
al contrario que en los dos casos anteriores, cuya utilizacin es
peridica.
Sistemas especiales. Como sistemas expertos, sistemas de
informacin para ejecutivos (EIS), etc.
La razn de considerar estos cuatro tipos de sistemas a la hora de asignar
prioridades radica en que, segn el tipo' de sistema, se requerir un
entorno tecnolgico o un sistema de soporte de datos (bases de datos,
ficheros) diferente.
En todo caso, cada vez se tiende ms al desarrollo de sistemas mixtos que
recogen particularidades propias de los cuatro grandes tipos sealados
anteriormente.
El uso de la tcnica matricial permite estudiar en detalle qu sistemas son
prerrequisitos para poder acometer el desarrollo de otros. Por ejemplo, en
el caso de los tres sistemas que se han identificado: Planificacin, Diseo
de Productos y Adquisicin, el Sistema de Adquisicin necesita
informacin generada por los dos primeros, por lo cual se desarrollara el
ltimo. En cuanto a stos, podra plantearse la posibilidad de dividirlos
TECNICAS MATRICIALES 137
con el fin de desarrollar en primer lugar los subsistemas que generan los
datos de uso comn.
Adems, para asignar prioridades se han de tener en cuenta criterios tales
como:
Beneficios potenciales.
Impacto en la organizacin.
Probabilidad de xito en la implantacin.
Demanda de los sistemas.
9.3. ANALISIS DE AFINIDAD
Otra utilidad que proporciona la tcnica matricial expuesta es la posibilidad de
agrupar las entidades identificadas para crear las diferentes bases de datos que
se utilizarn en la Organizacin. .
Para ello se puede aplicar el siguiente algoritmo en la Matriz Procesos-Entidades
de datos:
Sean dos entidades de datos El y Se denomina P(E) el nmero de procesos
que utilizan (usan o crean) la entidad El' Anlogamente es el nmero de
procesos que utilizan la entidad P(E
l
, ser el nmero de procesos que
utilizan las entidades E y
Se define como factor de afinidad de la entidad El con la entidad y se
representa por A(E
l
, al cociente:
= P(E
l
, / P(E)
Dos entidades que no son usadas por el mismo proceso tienen un factor de
afinidad cero. Dos entidades con un alto factor de afinidad deben estar en la
misma base de datos.
Una vez definido y calculado el factor de afinidad entre las entidades del sistema,
se realizarn agrupaciones entre estas entidades. En primer lugar se agrupan dos
a dos, para aquellas entidades que tienen entre s el factor de afinidad ms alto.
Por ejemplo, supongamos que se han calculado los factores de afinidad para todas
las entidades del sistema, y los ms grandes son los siguientes:
Estos pares de entidades forman el ncleo de agrupaciones.
El siguiente factor de afinidad es: A(Ez, Ea) = 0,85
Donde la entidad Ea forma parte ya de otra agrupacin con la entidad E
u
. Para
decidir si crea otra agrupacin aparte, o asignar la entidad ~ a la agrupacin
(E11' Ea> se utiliza el siguiente "Factor de afinidad ponderado":
A(Ez, ~ l X P(E
u
) + A(Ez, Ea) x P(Ea)
P(E
u
) + P(Ea)
Donde P(E
u
) =nmero de procesos que utilizan la entidad E
u
P(Es) = nmero de procesos que utilizan la entidad Es
Si este factor de afinidad ponderado es mayor que el resto de los factores de
afinidad entre las entidades del sistema consideradas dos a dos, se formar la
agrupacin (Ez, ~ l Ea)
En adelante, si se encuentran entidades con un factor de afinidad a ~ , En Ea,
se calcular el factor de afinidad ponderado de esta agrupacin.
En el caso de entidades que presenten entre s un factor de afinidad alto, pero
con la circunstancia de que dichas entidades estn previamente asignadas a otras
agrupaciones, se plantea la cuestin de combinar dichas agrupaciones. Por
ejemplo:
Sin embargo, se ha encontrado que E est agrupado con E
6
y E
4
con El.
En este caso se calcula el factor de afinidad ponderado de E a la agrupacin (El'
E
4
) Yal agrupamiento (El' E
4
, E
6
).
Dependiendo de si el valor de estos factores de afinidad ponderados es mayor
que el resto de los calculados para todas las entidades del sistema, se combinaran
ambas agrupaciones.
TECNlCAS MATRICIALES 239
Por ejemplo, se ha encontrado que dichos factores de afinidad ponderados son:
que son ms bajos que los factores de afinidad que se han calculado previamente.
En este caso, A(Eg, ~ = 0,74. En lugar de tomar una decisin con respecto a
la agrupacin de (R, EJ con (E
4
, El) seguiremos estudiando otras alternativas,
segn un orden estricto de factores de afinidad.
Por ltimo, aquellas entidades con un factor de afinidad muy bajo con el resto,
pueden implantarse como ficheros convencionales o bases de datos aisladas.
Es importante resaltar que este algoritmo del anlisis de afinidad puede agrupar
en una misma base de datos entidades que deberan estar separadas por razones
de seguridad, descentralizacin, consideraciones legales, etc., por lo cual se deben
ajustar los resultados de este algoritmo a estas consideraciones.
!J.4. UTILIZACION DE LA TECNICA EN LA METODOLOGIA METRICA
VERSION2
Las diferentes representaciones matriciales que se han mencionado en este
captulo, se utilizan en la Fase O. ("Plan de Sistemas de Informacin") en las
tareas siguientes:
TAREA PSI 4.3: Diseo de la arquitectura de la informacin
Matriz Procesos - Entidades.
Matriz Procesos - Organizacin.
TAREA PSI 5.1: Identificacin y descripcin de los sistemas existentes.
Matriz Aplicaciones - Ficheros de Datos.
TAREA PSI 5.3: Diagnstico de la situacin actual.
Matriz Aplicaciones - Funciones.
Matriz Ficheros de Datos Actuales - Entidades de
Datos.
MAP - Metodologia METRICA Versin 2
EQUIPO RESPONSABLE DEL PROYECfO
10. EQUIPO RESPONSABLE DEL PROYECTO
Director del Proyecto:
D. Vctor Izquierdo Loyola
Subdirector General de Coordinacin Informtica
Jefe del Proyecto:
Da. Ma Dolores Hernndez Maroto
Jefe de Area de Tecnologa
Grupo de Expertos:
D. Andrs Elhazaz Molina
Gerencia Informtica de la Seguridad Social
Da. Milagros Garca-Tenorio Damasceno
Ministerio de AsuntQS Sociales
Da. Isabel Gonzlez Daz
Ministerio de Cultura
D. Miguel Joaqun Calvo
Instituto Nacional de Estadstica
Da. Adela Tello Sotes
Boletn Oficial del Estado
Da. Rosario Urndez Contreras
Ministerio de Administraciones Pblicas
Colaboradores:
D. Alejandro Alvarez Shelly
Da. Beatriz Madrid Obregn
Empresa consultora externa:
COOPERS & LYBRAND
l\'IAP - Metodologa METRICA Versin 2
243
AP
Ministerio
para las
Adm straciones
Pblicas
p.V.P. 6.000

Pblicas para las
METODOLOGA
DE PLANIFICACIN Y
DE INFORMACIN
MTRICA VERSIN 2
GUA DE USUARIO
METODOLOGA
DE PLANIFICACIN Y
DE INFORMACIN:
MTRICA VERSIN2
GUA DE USUARIO
MADRID
1993
Coleccin: MANUALES
METRICA l(2. es una iniciativa promovida por el Consejo Superior de Infor-
mtica, rgano colegiado encargado de la elaboracin ydesarrollo de la poltica
Edita:
ISBN: 84-7088-634-7 (Tomo 1)
NIPa: 329-93-002-6
GUIA DE USUARIO
INDICE
INTRODUCCION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 3
FASE O:
FASE 1:
FASE 2:
FASE 3:
FASE 4:
PLAN DE SISTEMAS DE INFORMACION (PSI) . . . . . . . . . . . . . . .. 5
ANALISIS DE SISTEMAS 19
Mdulo Anlisis de Requisitos del Sistema (ARS) 21
Mdulo Especificacin Funcional del Sistema (EFS) .. . . . . . . . . . . .. 26
DISEO DE SISTEMAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35
Mdulo Diseo Tcnico del Sistema (DTS) 37
CONSTRUCCION DE SISTEMAS : . . . . . . . . . . .. 45
Mdulo Desarrollo de Componentes del Sistema (DCS) . . . . . . . . . . .. 47
Mdulo Desarrollo de Procedimientos de Usuario (DPU) 52
IMPLANTACION DE SISTEMAS 59
Mdulo Pruebas Implantacin y Aceptacin del Sistema (PIA) 61
GUIA DE USUARIO
INTRODUCCION
3
El objetivo de la Gua de Usuario de la Metodologa METRICA Versin 2 es proporcionar
a los utilizadores de la misma, un rpido acceso y un resumen sencillo, a la vez que completo,
de los principales mdulos, actividades y tareas que contempla la Metodologa.
Para lograr este objetivo, se ha diseado esta Gua de Usuario con los siguientes criterios:
Presentar, para cada mdulo, los grficos que representan la sucesin de las
actividades de dicho mdulo y las funciones y responsabilidades de los diferentes
rganos implicados.
Resumir, con un formato de tabla que facilite su fcil lectura, el contenido de las
distintas tareas, incluyendo los productos a obtener en cada una de ellas, as como las
tcnicas a utilizar para conseguir dichos productos.
Representar grficamente las actividades que, por su especial complejidad o gran
interrelacin con otras actividades de la Metodologa, as lo requieran.
Con ello se espera lograr un instrumento til Yeficaz a la hora de aplicar la Metodologa en
proyectos concretos.
GUIA DE USUARIO
FASES
VISION GENERAL DE LA METOOOlOGIA METRICA 2
4
PlAN DE SISTEMAS
DE INFORMACION
MAP . Metodologa METRICA Versin 2
ANAUSIS DE SISTEMAS DISEO DE SISTEMAS CONSTRUCClON DE SISTEMAS
S. Consolidar Procedimiento& de
Usuario
IMPLANTAClON
DE SISTEMAS
M
e
:2

O
u

;:J

fIl
;:J

w
Q
g

el
);
llo
:::;:
GUIA DE USUARIO
----------
ANALlSIS
PLAN
-6-
."
c:
Z
z ....
ESTRATEGICO o
DISEO
o
III
o
o o
--
m
.<
DE
----------
-A--
O
w
O e
z
z ....
ONSTRUCCION
:D
SISTEMAS <
O ...
r- eL
----------
DE ,A.-
INFORMACION ----------
IMPLANTACION
.... -
DOCUMENTO FIN DE FASE
PLAN DE MANTENIMIENTO
MAP - Metodologa MElRICA Versin 2
6
GUIA DE USUARIO 7
PLAN DE SISTEMAS DE INFORMACION (FASE O)
ACCIONES DE CONTROL
DECAUDAD

'V-.....
--

--

--
ACCIONES DE GESTION
DE PROYECTO
1.2 ..ntilicaci6n ala.uni'" atec:t.du
SEGUNIENTO VCONTROL
'.1 EIIborad6no. un pIIn
.,......-
1.3 Organizac:i6n de loa pancipanta
t.4 Planiicac:in tW proyacto
8.2 ......mientD d11lplan
.-
ACTIVIDADES
2.3 IdIntileacion de
Nec.idMlf.lnformaci6n
.REVlSAR SITUA-

'-.---:--::--:-:'. 5.' .......-

SiIInu.lIli....
5.2 AnAl Entoma
Tea'loI6gico ee;a,aJ
fiN
5.3IMgn61iico" ..
SituKi6n adual
LfENQ:' 9El GMACO
" REVISlON INFoRMAL
V (no,....ria Irma)
_ REVISION FORMAL
... (nsaria Irma)
MAP Metodologa ME1RICA Versin 2
8 GUIA DE USUARIO
PLAN
ACTIVIDADES
DE SISTEMAS
DE INFORMACION
1 2 3 4 5 6 7 8
COMITE DE DIRECCION
D,R R R F
DIRECTOR PROYECTO
R R R R R R R F
GRUPO DE CALIDAD
R F
GRUPO DE USUARIOS I I I I I I
DEPARTAMENTO DE TI
A A
...... ...... ....... ....... . ...... ...... . ....... .......
I I I I I I
EQUIPO DE PROYECTO
E E
Jefe de Proyecto
E E E E E E
...... ...... ....... . ...... ....... ....... ' ....... . ......
Componentes Equipo
E E E E E E E
CLAVES:
A .. Asistencia Tcnica
D .. Dotar Recursos
E .. Ejecucin
F .. Revisin Formal
R .. Revisin Informal
I .. SumInistra Informacin
ACTIVIDADES:
1. Definir Objetivos, Organizacin, Ambito
y Planificacin del Proyecto
2. Identificar las necesidades de informacin
de las Unidades afectadas
3. Identificar las Directrices de Gestin y Tcnlcas
4. Disenar la Arquitectura de la Informacin
5. Revisar la situacin actual de los Sistemas
de Informacin
6. Especificar los nuevos sistemas
7. Definir las alternativas tecnolgicas
8. Elaborar un Plan de Accin
GUIA DE USUARIO
9
PSI 1: DEFINIR OBJETIVOS,
ORGANIZACION, AMBITO y
PLANIFICACION DEL PROYECTO
1.1.:
1.2.:
ESPECIFICACION DE OBJETIVOS
IDENTIFICACION DE LAS
UNIDADES AFECTADAS
ESPECIFlCACION DETALLADA DE
OBJETIVOS DEL AREA
RECOPILACION DE ANTECEDENTES DEL
PLAN DE SISTEMAS
Plan estratgico existente
Plan de sistemas anterior
Planes de actuaci6n de la unidad
PERFIL GENERAL DE LA/S UNIDAD/ES
Informacin preliminar de servicios y
funciones realizadas
Distribucingeogrfica de las Unidades
Entrevistas con el Director del Proyecto
Entrevistas con los responsables de Ia/s
Unidad/es
1.3.: ORGANIZACION DE LOS
PARTICIPANTES
ORGANIZACION DE LOS DIFERENTES
EQUIPOS DE PARTICIPANTES
LISTA INICIAL DE PERSONAL
PARTICIPANTE
1.4.: PLANIFICACION DEL PROYECTO CRONOGRAMA DEL PROYECTO
GUIA DE USUARIO
PSI 2: IDENTIFICAR LAS NECESIDADES DE
INFORMACION DE LAS UNIDADES
AFECTADAS
2.1.: IDENTIFICACION DE FUNCIONES Y
OBJETIVOS
2.2.: IDENTIFICACION DE REQUISITOS
2.3.: IDENTIFICACION DE LAS
NECESIDAPES DE INFORMACION
DIAGRAMA DE CONTEXTO DE LA UNIDAD
REPRESENTACION GRAFICA
Funciones realizadas por la Unidad
Rujo de infonnacin a travs de ella
LISTA DE FUNCIONES Y OBJETIVOS DE LA
UNIDAD
LISTAINICIAL DE PROBLEMAS Y
NECESIDADES
LISTA INICIAL DE POSIBLES MFJORAS EN
LOS SISTEMAS DE INFORMACION (S.I.)
CATALOGO DE REQUISITOS CON SUS
PRIORIDADES
LISTA INICIAL DE PROBLEMAS Y
NECESIDADES
LISTA INICIAL DE POSIBLES MFJORAS EN
LOS S.I.
DOCUMENTACION DEL POSIBLE IMPACTO
DE LOS OBJETIVOS DE LA UNIDAD SOBRE
LOS S.I.
Posibles escenarios identificados
Entrevistas y reuniones en grupo con los
responsables de la Unidad
Diagramas de Rujo de Datos
Entrevistas con los responsables de la Unidad
Entrevistas y reuniones en grupo con los
responsables de la Unidad
Factores crticos de xito
Entrevistas y reuniones en grupo con:
Responsables de la Unidad
Responsables de tratamiento de la
infonnacin
10
GUIA DE USUARIO
PSI 3: IDENTIFICAR LAS DIRECTRICES DE
GESTION y TECNICAS
11
DIRECTRICES DE GESTION
DIRECTRICES TECNICAS
PSI 4: DISEAR LA ARQUITECTURA DE
LA INFORMACION
RECOPILACION DE POLmCAS y
DIRECTRICES DE GESTION
CATALOGO DE REQUISITOS
RECOPILACION DE POLmCAS y
DIRECTRICES TECNICAS
CATALOGO DE REQUISITOS
Entrevistas con:
Responsables y usuarios de la Unidad
infonnacin
Entrevistas con responsables de tratamiento de la
infonnacin
4.1.: DISEO DEL MODELO CONCEPTUAL LISTA DE ENTIDADES O CLASES DE DATOS
DE DATOS CON SUS DESCRIPCIONES
MODELO CONCEPTUAL DE DATOS DE LA
UNIDAD
4.2.: DISEO DE LA JERARQUIA DE CATALOGO DE FUNCIONES DE LA UNIDAD
FUNCIONES
DIAGRAMA DE DESCOMPOSICION
FUNCIONAL (DISEO DE LA JERARQUIA DE
FUNCIONES)
DIAGRAMA DE MODELO DE FUNCIONES DE
LA UNIDAD
Entrevistas con:
Responsables y usuarios de la Unidad
infonnacin
Modelo entidad-relacin
Entrevistas con responsables y usuarios de la
Unidad
Diagrama de Flujo de Datos (DFD)
(rUlA DE USUARIO
12
4.3.: DISEO DE LA ARQUITECfURA DE
LA INFORMACION
DISEO DE LA ARQUITECfURA LOGlCA
DE LA INFORMACION
DISEO DE UN MODELO ORGANIZATIVO
IDENTIFlCACION INICIAL DE NUEVOS
SISTEMAS
Tcnicas matriciales
Procesos-Entidades
Procesos-Organizacin
PSI S: REVISAR LA SITUACION AcruAL DE
5.1.:
5.2.:
IDENTIFICACION y DESCRIPCION
DE LOS SISTEMAS EXISTENTES
ANALlSIS DEL ENTORNO
TECNOLOGlCO ACfUAL
DESCRIPCION DE APLICACIONES
EXISTENTES
Funciones
Relaciones con otras aplicaciones
Posibilidades de adaptacin
Caractersticas tecnolgicas
CORRELACION APLICACIONES-FICHEROS
DE DATOS
PERFIL DE LOS COMPONENTES DEL
ENTORNO TECNOLOGlCO ACfUAL
Descripcin
Capacidad actual
Integracin con otros componentes
Utilizacin en periodos normales y crticos
Perspectivas de futuro
Entrevistas con personal de tratamiento de la
informacin.
Tcnicas matriciales
Aplicaciones-Ficheros de Datos
informacin
GUIA DE USUARIO
13
5.3.: DIAGNOSTICO DE LA SITUACION
ACTUAL
VALORACION DE LOS SISTEMAS
ACTUALES
Resumen AplicacionesFunciones
Resumen Ficheros de datos actuales-
Entidades de Datos
Coste de los sistemas actuales y valoracin
en funcin de los beneficios
PERFIL DE RECURSOS HUMANOS EN
UNIDADES DE TRATAMIENTO DE LA
INFORMACION
informacin
Tcnicas matriciales
Aplicaciones-Funciones
Ficheros de Datos Actuales-Entidades de
Datos
Anlisis coste-beneficio
PSI 6: ESPECIFICAR LOS NUEVOS
SISTEMAS
6.1.:
6.2.:
IDENTIFlCACION DE MEJORAS EN
LOS SISTEMAS ACTUALES
IDENTIFlCACION DE NUEVOS
SISTEMAS
LISTA DE APLICACIONES A ADAPTAR AL
NUEVO ENTORNO
Descripcin de las mejoras necesarias
LISTA DE APLICACIONES A MIGRAR AL
NUEVO ENTORNO
DESCRIPCION DE NUEVAS APLICACIONES
Tipo de sistema
Requisitos que satisface
Funciones que realiza
Entidades de datos que maneja
Entrevistas con:
Personal de tratamiento de la informacin
Usuarios y responsables de la Unidad
Entrevistas con los responsables y usuarios de la
Unidad
MAP Metodologia METRICA Versin 2
GUIA DE USUARIO
14
6.3.: DETERMINACION DE
PRIORIDADES DE DESARROLLO
DOCUMENTACION DE PRIORIDADES DE
IMPLANTACION
Entrevistas y reuniones en grupo con responsables
y usuarios de la unidad.
Anlisis Coste-Beneficio
6.4.: ESPECIFICACION DE LOS SISTEMAS ESPECIFICACION DE LOS SISTEMAS
Objetivos
Descripcin de funciones
Restricciones
ALTERNATIVAS DE vlPLANTACION
Entrevistas y reuniones en grupo
Usuarios
Responsables de la Unidad
Comit de Direccin
PSI 7: DEFINIR LAS ALTERNATIVAS
TECNOLOGICAS
7.1.:
7.2.:
IDENTIFICACION DE NECESIDADES VISION GENERAL DE LA
TECNOLOGICAS FUTURAS INFRAESTRUCTURA TECNOLOGICA
REQUERIDA
DEFINICION DE OPCIONES
TECNOLOGICAS DOCUMENTACION DE LAS
INFRAESTRUCTURAS TECNOLOGICAS
POTENCIALES
Ventajas e inconvenientes
Razones de rechazo y aceptacin
Entrevistas con responsables tcnicos de la
Unidad
Entrevistas:
Personal tcnico
informacin
PSI 8: ELABORAR EL PLAN DE ACCION
8.1.: ELABORACION DE UN PLAN DE
IMPlANTACION
8.2.: MANTENIMIENTO DEL PLAN DE
SISTEMAS
PLAN GLOBAL DE IMPLANTACION y
PLANES A CORTO PLAZO PARA
PROYECTOS PRIORITARIOS
PROCEDIMIENTOS PARA EL
MANTENIMIENTO DEL PLAN DE SISTEMAS
GUIA DE USUARIO
PSl1 :DEFINIR OBJETIVOS,ORGANI-
ZACIN,AMBITO y PLANIFI-
CACION DEL PROYECTO
Unidades afectadas
15
UNIDADES AFECTADAS
funciones y objetivos
r q u s ~ o s
necesidades de
infonnacin
MAP . Metodologa MElRICA Versin 2
GUIA DE USUARIO 16
PSIS:REVISAR LA SITUACION ACTUAL DE
15.1. Identificacin y descripcin
1- de los sistemas existentes
UNIDADES AFECTADAS
PSI6:ESPECIFICAR LOS NUEVOS
15.2. Anlisis del entorno tecnolgico
1-
actual
SISTEMAS
PSI4: DISEl'IAR LA ARQUITECTURA
DE LA INFORMACION
15.3. Diagnstico de la situacin
1
actual
GUIA DE USUARIO 17
PSI6:ESPECIFICAR LOS NUEVOS SISTEMAS
I
6.1. Identilicaci6n de mejoras en
los sistemas actuales
PSI7: DEFINIR LAS ALTERNATIVAS

PSI4: DISErilAR LA ARQUITECTURA
TECNOLOGICAS
DE LA INFORMACION
I
6.2. Identificacin de nuevas
I
7.1.IDENTIFICACION DE
sistemas
NECESIDADES
+
TECNOLOGICAS FUTURAS

I
6.3. Determinacin de prioridades
I
de desarrollo
7.2. DEFINICION DE
PSI5: REVISAR LA SITUACION ACTUAL
OPCIONES
DE LOS SISTEMAS DE
TECNOLOGICAS
INFORMACIO/':oI
I 6.4. Especificacin de los sistemas
J-
N

O

(j
:J

el)
:J
III
t:I
.!!
g
t>O
,g
Cl

.,
"
llo
<

GUIA DE USUARIO
INTERRELACION..QEb-PLAt'-JDESISTEMAS
CON LAFASEDEANALlSIS
20
PLAN
DE SISTEMAS
DE INFORMACION
DANTENIMIENT9 PLAN pE SISTEMAS!
LEYENDA DEL GRAFICO
ANALlSIS
DE REQUISITOS
DEL SISTEMA
ESPECIFICACION
FUNCIONAL
DEL SISTEMA
MODULO OACnllIDAD
PRODUCTO RESULTANTE
1 111
GUIA DE USUARIO
MODULO DE ANAUSIS DE REQUISITOS DEL SISTEMA (ARS)
21
ACCIONES DE CONTROL
DECAUDAD
'\l Aprobar requisito. y
objet_
.::.= .Aprabar
Recomendada fltanes
_ Revisar
.. SOlucin
Recomendada 'tstimac:iones
DE PROYECTO
SEGUIMIENTO y CONTROL

1.2 Identificacin Usuarios
Participantes
LEYENDA DEL GRAFICO
'iJ
REVlSION INFORMAL
(no necesaria fi'ma)
_ REVlSION FORMAL
... (necesaria firma)
2.1 Planificacin lJ realizaciOn
de Entrevistas
2.2 Identificacin de Problemas
yN_.
3.1 Cons1rUcci6n del Modelo
Lgico aCIU8J de Procesos
3.2 COnsU'Ucei6n del Modelo
L6gico actual de Datos

4.1 Definicin de
AJtemBtivu
4.2Se1eccildll
una A1lernativa
22
GUIA DE USUARIO
ANALlSIS
ACTIVIDADES
DE REQUISITOS
DEL SISTEMA 1 2
3
4
COMITE DE DIRECCION
D,R R F
DIRECTOR PROYECTO
R R R F
GRUPO DE CALIDAD F
GRUPO DE USUARIOS
I R I
DEPARTAMENTO DE TI
- ---- -- ---
- ---- - ----
Responsables Tcnicos I I
EQUIPO DE PROYECTO
Jefe de Proyecto
E E E E
- -- -- -- ---
- -- --
-----
Componentes Equipo
E E E
CLAVES:
D =Dotar Recursos
E =Ejecucin
F = Revisi6n Formal
I = Suministr. Informaci6n
ACTIVIDADES:
1. Establecer el Ambito y Alcance
del Proyecto
2. Identificar y definir Requisitos
3. Disear el Modelo Lgico Actual
4. Estudiar Alternativas de Construccin
GUIA DE USUARIO
23
MODULO: ANALISIS DE REQUISITOS DEL SISTEMA (ARS)
ARS 1: ESTABLECER EL AMBITO y
ALCANCE DEL PROYECTO
1.1.: DEANICION DEL PROYECfO
1.2.: IDENTIFlCACION USUARIOS
PARTICIPANTES
ARS 2: IDENTIFICAR Y DEFINIR
REQUISITOS
DESCRIPCION GENERAL DEL PROYECTO Entrevistas con responsable/s UIdad/es
Objetivos, Unidades implicadas,
Planificacin inicial, restricciones, equipo de
trabajo
LISTA DE USUARIOS PARTICIPANTES Entrevistas y reuniones con responsable/s Unidad/es
2.1.: PLANIFICACION Y REALIZACION DE PLAN DE ENTREVISTAS Entrevistas con responsables y usuarios de la/s
ENTREVISTAS CATALOGO DE REQUISITOS DEL SISTEMA Unidad/es
2.2.: IDENTIFICAClON DE PROBLEMAS Y MODELO FlSICO SISTEMA AcruAL Entrevistas con usuarios y tcnicos de tratamiento
NECESIDADES LISTA DE PROBLEMAS Y NECESIDADES DEL de infonnacin
SISTEMA AcruAL
CATALOGO DE REQUISITOS DEL SISTEMA,
CON PRIORIDADES
ARS 3: DISEAR El MODELO LOGICO
ACTUAL
3.1.: CONSTRUCCION DEL MODELO
LOGICO AcruAL DE PROCESOS
MODELO LOGICO AcruAL DE PROCESOS
CATALOGO DE REQUISITOS DEL SISTEMA
CON PRIORIDADES
Entrevistas con Usuarios del Sistema
Diagrama de Flujo de Datos (DFD)
GUIA DE USUARIO
24
MODULO: ANALISIS DE REQUISITOS DEL SISTEMA (ARS)
3.2.: CONSlRUCCION DEL MODELO
LOmCO AcruAL DE DATOS
ARS 4: ESTUDIAR ALTERNATIVAS DE
CONSTRUCCION
LISTA DE ENTIDADES DEL SISTEMA
y Abributos
MODELO LOmCO AcruAL DE DATOS DEL
SISTEMA
CATALOGO DE REQUISITOS DEL SISTEMA
CON PRIORIDADES
Entrevistas con usuarios del sistema
Diagrama de Estructura de Datos
4.1.: DEFINICION DE ALTERNATIVAS
4.2.: SELECCION DE UNA ALTERNATIVA
MAP - Metodologfa MElRICA Versin 2
DESCRIPCION GENERAL DE CADA Diagrama de Flujo de Datos
ALTERNATIVA
Modelo Lgico de Procesos

automticos
Infonnacin sobre productos en el
mercado
DESCRIPCION PARA CADA ALTERNATIVA DE Anlisis Coste-Beneficio
COSTES y BENEFICIOS ESPERADOS Entrevistas Comit de Direccin
DESCRIPCION DETALLADA DE LA
ALTERNATIVA SELECCIONADA
GUIA DE USUARIO 25
ARS 2: IDENTIFICAR Y DEFINIR
REQUISITOS
..
ARS3: DISEf;lAR EL MODELO LOGICO
ARS4: ESTUDIAR ALTERNATIVAS
ACTUAL
DE CONSTRUCCION
r3.1 .Construccin del modelo lgico
1--
r4.1. Definicin de alternativas
I
actual de procesos
1
r3.2. Diseo del modelo lgico
~
14.2. Seleccin de una
actual de datos
alternativa
LEYENDA DEL GRAFICO
""'---1 ACTIVIDAD O TAREA
~ ~ ~ ~ ~ ~ ~ ~
MAP Metodologa ME1RICA Versin 2
GUIA DE USUARIO 26
ACCIONES OE CONTROL
DECAUDAD
SEGUIMIENTOY CONTROL
1.1 01881\0 Diagrama
ConteXIo del Si&lema
12 ldentificac:i6n y Definici6n
de SUbsistemas
,.3 Especificecin de Inter-
fases con otros sistemas
1.4 Descripcin de Procesos
manuales
ACCIONES DE GESTlON
DE PROYECTO
ACTIVIDADES
8. COMPLETAR
1-----+1 PECIFICAClo-
NESENTREGA
8.' Preparacin Plan
Pruebes del sisteme
8.2 Especificeci6n del Plan
de Entrege del slsteme
8.3 Verificecln yVoJidadn
de Especificeci6n Funcionel
dolSIstem8
LEYENDA pEl GRAFlCO
n REVISiON INFORMAl.
V (no necesaria firma)
_ REVISION FORMAl
" (_efirmaj
GUIA DE USUARIO
ESPECI FICACION
ACTIVIDADES
FUNCIONAL
DEL SISTEMA
1 2 3 4 5 6
COMITE DE DIRECCION
F
DIRECTOR PROYECTO
R R
R
R R F
GRUPO DE CALIDAD
F
GRUPO DE USUARIOS I I I
I I R
DEPARTAMENTO DE TI
Especialistas en Sistemas A A
- ---
- - -- - - - -- - - --- -----
I I
EQUIPO DE PROYECTO
.Jefe de Proyecto E
E
E E
E
E
- --- - -- - - -- - - --- ----- - - --
Componentes Equipo
E
E E
E
E
27
CLAVES:
O=Dotar Recursos
E = Ejecucin
F = Revisin Formal
R =Revisin Informal
ACTIVIDADES:
1. Construir el Modelo de Procesos del Nuevo Sistema
2. Construir el Modelo de Datos del Nuevo Sistema
3. Realizar el Anlisis detallado del Nuevo Sistema
4. Definir Interfases de Usuario
5. Completar Especificaciones del Sistema
6. Completar Especificaciones de Entrega
GUIA DE USUARIO
FASE 1: ANALlSIS DEL SISTEMA
28
MODULO EFS: ESPECIFICACION FUNCIONAL DEL SISTEMA
EFS 1: CONSTRUIR EL MODELO DE
PROCESOS DEL NUEVO SISTEMA
1.1.: DISEO DEL DIAGRAMA DE DIAGRAMA DE CONTEXTO DEL SISTEMA Diagrama de Flujo de Datos
CONTEXTO DEL SISTEMA
DESCRIPCION DE USUARIOS, UNIDADES
DE LA ORGANlZACION O APLICACIONES
QUE DELIMITAN EL SISTEMA (ENTIDADES
EXTERNAS)
1.2.: IDENTIFICACION y DEFINICION DE DIAGRAMA DE FLUJO DE DATOS DE Diagramas de Flujo de Datos
SUBSISTEMAS SUBSISTEMAS, FUNCIONES.
SUBFUNCIONES y PROCESOS Entrevistas con Usuarios
ELEMENTALES
DESCRIPCION DE COMPONENTES DE DFD
Flujos de Datos
Almacenes de Datos
Procesos
CATALOGO INICIAL DE EVENTOS
1.3.: ESPECIFICACION DE INTERFASES DESCRIPCION DE INTERFASES CON OTROS Diagrama de Flujo de Datos
CON OTROS SISTEMAS SISTEMAS O SUBSISTEMAS
Entrevistas con Usuarios
1.4.: DESCRIPCION DE PROCESOS DESCRIPCION DE PROCESOS MANUALES
MANUALES
GUIA DE USUARIO
29
EFS 2: CONSTRUIR EL MODELO DE DATOS
DEL NUEVO SISTEMA
2.1.: CONSTRUCCION DEL MODELO DE DESCRIPCION DE ENTIDADES DE DATOS Y Entrevistas con Usuarios
DATOS SUS ATRIBUTOS Modelizacin de Datos
(Diagramas de Estructura de Datos)
MODELO DE DATOS DEL NUEVO SISTEMA
2.2.: NORMALIZACION DEL MODELO
DE DATOS
EFS 3: REALIZAR UN ANALISIS DETALLADO
DEL NUEVO SISTEMA
3.1.: CONSTRUCCION DEL MODELO
ENTIDAD-EVENTO
ENTIDADES DE DATOS NORMALIZADAS
MODELO LOGICO DE DATOS EN 3FN
CATALOGO DE EVENTOS
MODELO ENTIDAD-EVENTO
Modelizacin de Datos (Normalizacin)
Historia de la Vida de la Entidad (HVE)
Entrevistas con Usuarios
3.2.: CONSOLIDACION DE LOS DIAGRAMAS DE FLUJO DE DATOS DE
MODELOS DE DATOS Y PROCESOS BAJO NIVEL, REVISADOS
MODELO LOGICO DE DATOS EN 3FN
REVISADO
Interrelacin tcnicas HVE con DFD y Diagramas
de EstruetuFa de Datos
GUIA DE USUARIO
30
EFS 4: DEFINIR INTERFASES DE USUARIOS
4.1.: PRODUCCION DE PROTOTIPOS FORMATO Y REPRESENTACION Prototipado de pantallas y dilogos
PRELIMINARES y DIALOGaS JERARQUICA DE PANTALLAS DEL
SISTEMA Entrevistas con los usuarios
ASIGNACION DE PANTALLAS Y DIALOGaS
A LOS GRUPOS DE USUARIOS
DIALOGaS CR1T1COS DEL SISTEMA
PROTOTIPOS DE LOS DIALOGaS CRITICaS
4.2.: ESPECIFICAClaN DE INFORMES Y FORMATOS DE INFORMES Y
FORMULARIOS FORMULARIOS
EFS s: COMPLETAR ESPECIFICACIONES
DEL SISTEMA
5.1.: ESPECIFICACION DE REQUISITOS CATALOGO DE REQUISITOS DEL SISTEMA
DE SEGURIDAD Y CONTROL ACTUALIZADO
DE COPIAS DE RESPALDO, ACTUALIZADO
CONTINGENCIAS Y
RECUPERACION DE ERRORES
DE RENDIMIENTO ACTUALIZADO
GUIA DE USUARIO
31
EFS 6: COMPLETAR ESPECIFICACIONES DE
ENTREGA
6.1.: PREPARACION DEL PLAN DE
PRUEBAS DEL SISTEMA
6.2.: ESPECIFICACION DEL PLAN DE
ENTREGA DEL SISTEMA
6.3.: VERIFICACION y VALlDACION DE
LA ESPECIFICACION FUNCIONAL
DEL SISTEMA
PLAN DE PRUEBAS DE ACEPTACION DEL
SISTEMA
PLAN DE DESARROLLO Y ENTREGA DEL
NUEVO SISTEMA
PLAN DE ACEPTACION DEL NUEVO
SISTEMA
REVISION DE FECHAS Y COSTES
PREVISTOS
CONJUNTO COMPLETO DE
ESPECIFICACIONES FUNCIONALES DEL
SISTEMA REVISADO, VALIDADO Y
APROBADO
GUIA DE USUARIO 32
EFS 1: CONSTRUIR EL MODELODE PROCESOS
DEL NUEVO SISTEMA
ACTIVIDAD EFS 4:
DEFINIR INTERFASES
....1-----1... DE USUARIO
ACTIVIDAD EFS 3:
J4--_.1 REALIZAR EL ANALISIS
DETALLADO DEL NUEVOSISTEMA
ACTIVIDAD EFS 2:
CONSTRUIR EL MODELO DE
DATOS DEL NUEVOSISTEMA
1.4. Descrl>cin de procesos

manuales
MODULOARS:
DEL SISTEMA
LEYENDA DEL QRAFICO
c:::::J -enVIDAD OTAREA
~ ~ ~ ~
GUIA DE USUARIO
EFS 2: CONSTRUIR EL MODELO DE DATOS
DEL NUEVO SISTEMA
33
MODULOARS:
DEL SISTEMA
LEYENDADe.. OAAACO
c:::J ACnYIDAD oTAREA
E E Z Z I = ~
MAP - Metodologfa MElRICA Versin 2
2.1. Construccin del modelo

dedelos
12.2. Normafizaci6n del modelo de
delos
ACTIVIDAD EFS 1:
... , CONSTRUIR EL MODELO DE
PROCESOS DEL NUEVO SISTEMA
ACTIVIDAD EFS 3:
k---......, REALIZAR EL ANALISIS
ACTIVIDAD EFS 4:
DEFINIR INTERFASES
, ...1-----1 DE USUARIO
GUIA DE USUARIO 34
MODULOARS:
DEL SISTEMA
DEL QRAACO
c:JACfMOIDOTAREA

..
EFS 3: REALIZAR EL ANALISIS DETALLADO
DEL NUEVOSISTEMA
3.1. ConslrUcci6n del modelo
Entidad-EvenlD
3.2. Consolidacin de los modelos
de dalDs y procesos
ACTIVIDAD EFS 1:
.....1-----. CONSTRUIR EL MODELO DE
PROCESOS DEL NUEVOSISTEMA
ACTIVIDAD EFS 2:
.... CONSTRUIR EL MODELO DE
DATOS DEL NUEVOSISTEMA
ACTIVIDAD EFS 4:
DEFINIR INTERFASES
.... DE USUARIO
N
.s
5
>
Q
u

:J
en
:J
-a
l.ll
Q
,g
'8
s
1$
o
::iZ
el.
):
GUIA DE USUARIO
INtERRELAI0r\j6EI: PLAN .
. .
36
PLAN
DE SISTEMAS
DE INFORMACION

'-'L""'EYE=NOA""""'OE""LG""'RA""'F""'ICO"""""
c::JACTIVIDAOo TAREA
_ENN'ENTOPUNDESISTBolAS

FASE 2: DISEO DEL SISTEMA
DISElilO
TECNICO
DEL SISTEMA
GUIA DE USUARIO
ACCIONES DE CONTROL
DECAUDAO
ACCIONES DE GESTION
DE PROVECTO
ACTIVlOADES
1.1 Cite&> Eltruct.lra
moclIlardel .......
1.2 Dncripci6n de im.rta..
_.........
1.3 Dacripci6n deintefta..

_usuario
1.5 o.firici6n componen'"
et.I..m.
. EopodficacI6o._
...._--,-
MODULO DE DISEO TECNICO DEL SISTEMA (DTS)
SEGUIMIENTOV CONTROL
1- -.5.==-es.
NESDISEAo
5.1 PNpend6n ele p......
....nolo
S,2PfIIP&l'IlCi6n.p,-,"
,.,.
5.3 R.hi6n del Cbefto
T""''''''''''
, fiNge pe! ANFlGO

37
38
GUIA DE USUARIO
DISEO
ACTIVIDADES
TECNICO
DEL SISTEMA
1 2 3 4 5
COMITE DE DIRECCION
F
DIRECTOR PROYECTO
R F
GRUPO DE CALIDAD
F
GRUPO DE USUARIOS
DEPARTAMENTO DE TI
A A
E
--- -- -- ----- - - -- - - --
A
A
E
EQUIPO DE PROYECTO
Jefe de Proyecto
E
E E
E E
- -- -----
---- ----
Componentes Equipo
E E
E
E
CLAVES:
D - Dotar Recursos
E - Ejecucin
F - Revisin Formal
R - Revisin Informal
I - Suministra Informacin
ACTIVIDADES:
1. Disenar la Arquitectura Frsica del Sistema
2. Disenar la Estructura Frsica de Datos del Sistema
3. Especificar entorno tecnolgico del Sistema
4. Completar el Plan de Pruebas del Sistema
5. Completar Especificaciones de Diseno
GUIA DE USUARIO
39
DTS 1: DISEAR LA ARQUITECTURA FISICA
DEL SISTEMA
1.1.: DISEO DE LA ESTRUCTURA
MODULAR DEL SISTEMA
CONJUNTO DE ACTIVIDADES FISICAS DEL Diagrama de Estructura de Cuadros (DEC) de
SISTEMA Constantine
DETERMINACION INICIAL DE
ACTIVIDADES FISICAS CON
CARACTERISTlCAS COMUNES DE
DESARROLLO
DIAGRAMA DE ESTRUCTURA DE
CUADROS DE ALTO NIVEL, QUE MUESTRE
LA COMUNICACION ENTRE LOS
SUBSISTEMAS
DIAGRAMAS DE ESTRUCTURAS DE
CUADROS QUE MUESTREN EL
TRATAMIENTO DE CADA UNA DE LAS
ACTIVIDADES FISICAS DEL SISTEMA Y LA .
ESTRUCTURA DE LAS MISMAS
Transacciones y dilogos interactivos
Fases y cadenas de tratamiento por lotes
1.2.: DESCRIPCION DE INTERFASES DESCRIPCION DETALLADA DE Diagrama de Estructura de Cuadros (DEC) de
ENTRE MODUWS DEL SISTEMA INTERFASES Constantine
De datos
De control entre m6dulos
13.: DESCRIPCION DE INTERFASES CON DESCRIPCION DE INTERFASES CON OTROS Diagrama de Estructura de Cuadros (DEC) de
OTROS SISTEMAS SISTEMAS Constantine
MAP Metodologa METRICA Versi6n 2
GUlA DE USUARIO
40
1.4.: DESCRIPCION DE INTERFASES DE
USUARIO
1.5.: DEFINICION DE COMPONENTES
DEL SISTEMA
DTS 2.: DISEAR LA ESTRUCTURA FlSICA
2.1.: ELABORACION DEL MODELO
FISICO DE DATOS
2.2.: OPTIMIZACION DEL MODELO
FISICO DE DATOS
MAP Metodologfa METRICA Versin 2
DESCRIPCION DETALLADA DE
INTERFASES DE USUARIO
DEFINICION DE LOS COMPONENTES DEL
SISTEMA
DESCRIPCION DETALLADA DE CADA
COMPONENTE
MODELO DE DATOS FISICO
ESTIMACION DEL RENDIMIENTO DE LAS
TRANSACCIONES CRITICAS DEL SISTEMA
POSIBLE DESNORMALIZACION DEL
MODELO DE DATOS
Prototipos de pantallas y dilogos
Diagrama de Eslruclura de Cuadros
Diagrama de Eslruclura de Cuadros
Descripcin de cada componente: pseudocdigo,
lenguaje estructurado
Modelizacin Fsica de Datos
Oplimizacin del Modelo de Dalos
GUIA DE USUARIO
41
DTS 3.: ESPECIFICAR EL ENTORNO
TECNOLOGICO DEL SISTEMA
3.1.: DEFINICION DEL ENTORNO
TECNOLOGICO DEL SISTEMA
3.2.: ESPECIFICACION DE REQUISISTOS
DE COMUNICACIONES DEL
SISTEMA
3.3.: ESPECIFICACION DE REQUISITOS
DE OPERACION. SEGURIDAD y
CONTROL
DTS 4: COMPLETAR EL PLAN DE PRUEBAS
DEL SISTEMA
4.1.: DISEO DE PLANES DE PRUEBA
DEL SISTEMA
4.2.: DEFINICION DEL ENTORNO Y
LIMITACIONES DE PRUEBA
ESPECIFICAClON DEL ENTORNO
TECNOLOGICO DEL NUEVO SISTEMA
DISEO DE LA CONFIGURAClON DE LA
RED DE COMUNICACIONES DEL SISTEMA
PROCEDIMIENTOS DE OPERAClON DE
Peridicos
Mediante peticin
PROCEDIMIENTOS DE SEGURIDAD Y
CONTROL
Acceso
Copias de respaldo y recuperacin
DISEO DE PLANES DE PRUEBA DEL
SISTEMA
DEFINIClON DEL ENTORNO DE PRUEBAS
Diseo de Pruebas
GUIA DE USUARIO
42
DTS 5: COMPLETAR ESPECIFICACIONES DE
DISEO
5.1.: PREPARACION DE PLANES DE
CONSTRUCCION
5.2.: PREPARACION DE PLANES PARA
LA IMPLANTACION
5.3.: REVISION DEL DISEO TECNICO
DEL SISTEMA
ESPECIFICACION DEL PLAN DE
CONSTRUCCION
BORRADOR DE UN PLAN DE
IMPLANTACION
CONJUNTO COMPLETO DE
ESPECIFICACIONES DE DISEO REVISADO,
VALIDADO Y APROBADO
Tcnicas de Eslimacin
Tcnicas de ESlimacin
GUIA DE USUARIO 43
DOCUMENTO MODULO EFS DTS1 :DISEAR ARQUITECTURA FISICA
DEL SISTEMA
'./.L../
11.1 Diseo Estructura Modular
1-
~
DTS2: DISEAR ESTRUCTURA
FISICA DE DATOS
- ~
DEL SISTEMA
I 1.2 Descrip. int8rfases entra mdulos I
. ~ ~
.J,
I 1.3 Descrip,intarfases otros sistemas
I
i j ~
DTS3:ESPECIFICAR EL ENTORNO
TECNOLOGICO DEL
I
SISTEMA
I 1.4 Descripci6n Intarfases usuario
1-
1/ '// '/
~
1--
/ ~
1.5 Dafinicl6n componantes sistema
'/ '/
LEYEfO\ DEL ORAACO
[=::J ACl1VIDADOTAREA
~ ~
MAP Metodologa MElRICA Versin 2
GUIA DE USUARIO 44
DOCUMENTO MODULO EFS DTS2:DISEAR LA ESTRUCTURA FISICA
DTS1: DISEAR ARQUITECTURA
1 1 L L L L ~
4---
17777///7';
2.1 Elaboracin del ~
FISICA DEL SISTEMA
1"'/'/777777/77/A
Modelo Frslco
de Datos
f
2.2 Optimizacin
r 1 1 1 I I ~
del Modelo Frsico
V//"77/7 F/// /
14-
~ ~ ~ ~ A
de Datos DTS3: ESPECIFICAR EL ENTORNO
TECNOLOGICO
DEL SISTEMA
LEYENDA DEL GRAFICO
c:J ACTIVIDAD O TAREA
[7777'] PRODUCTO
~ RESULTANTE
GUIA DE USUARIO
46
PLAN
DE SISTEMAS
DE INFORMACION
DESARROLLO
DE PROCEDIMIENTOS
DE USUARIO
DESARROLLO
DE COMPONENTES
DEL SISTEMA
L"'CNUA DEL GRAFICO
O'cnVlDADoTAREA
1'7'7:1 PRODUCTO
RESULTANTE
MANTEN'IIEIITO PlAN DE SISTEMAS
GUIA DE USUARIO
ACCIONES DE CONTROL
DE CALIDAD
ACCIONES DE GESTION
DE PROYECTO
ACTIVIDADES
MODULO DE DESARROLLO DE COMPONENTES DEL SISTEMA (DeS)
'\1,RevllII
-===__.....,Pruobu
2. DESARROLlAR Y 3. REAUZAA
PROBAR COMPo. ~ PRUEBAS DE
NENTES SISTEMA INTEGRACION
2.1 Generacin del Cdigo 3.1 Proparacl6n y Ejecucl6n de las
de 101 COmpon..tes d. Sillema Pruebas de Integracin
22 Prepared6n. Ejecuci6n y 3.2 Evaluacin ydocumentacin de
Evaluacin de las Pruebas los res_de ras Pruebas
Unitarias de IntegrBCin
2.3 Documentacin
de los Componentes
delSisleme
LEYENpA gEL GBAACO
n REVlSION INFORMAL
V (noMenarialrma)
_ FIEVISIONFORMAL
.... (....-art.tnna)
47
48 GUIA DE USUARIO
DESARROLLO
ACTIVIDADES
DE COMPONENTES
DEL SISTEMA
1 2 3
COMITE DE DIRECCION
DIRECTOR PROYECTO
F
GRUPO DE CALIDAD
F
GRUPO DE USUARIOS
DEPARTAMENTO DE TI
Especialistas en Sistemas E
- - - -- - - -- - - --
E
EQUIPO DE PROYECTO
Jefe de Proyecto E
R R
- - - -- - - -- - - --
Componentes Equipo E
E
CLAVES:
A =Asistencia Tcnica
D = Dotar Recursos
E = Ejecucin
F = Revisin Formal
ACTIVIDADES:
1. Preparar Entorno de Desarrollo, Pruebas
y Procedimientos de Operacin
2. Desarrollar y Probar Componentes
del Sistema
3.Realizar Pruebas de Integracin
IDCS.21
GUIA DE USUARIO
49
MODULO DCS: DESARROLLO DE COMPONENTES DEL SISTEMA
DCS 1: PREPARAR ENTORNO DE
DESARROLLO, PRUEBAS Y
PROCEDIMIENTOS DE OPERACION
1.1.:
1.2.:
1.3.:
1.4.:
IMPLANTACION DE LA BASE DE
DATOS FISICA O FICHEROS DE
DATOS
PREPARACION DEL ENTORNO DE
DESARROLLO
PREPARACION DEL ENTORNO DE
PRUEBAS
DEFINICION DE PROCEDIMIENTOS
DE OPERACIONES DE
BASES DE DATOS FISICAS O FICHEROS
CONVENCIONALES PARA REALIZAR LA
CONSTRUCCION y LAS PRUEBAS
DESCRIPCION COMPLETA DEL ENTORNO
DE DESARROLLO
DESCRIPCION COMPLETA DEL ENTORNO
DE PRUEBAS
PROCEDIMIENTOS DE OPERACIONES DE
DCS 2: DESARROLLAR Y PROBAR
2.1.: GENERACION DEL CODIGO DE LOS DISEO DE LA ESTRUCTURA DEL CODIGO Diagramas de Estructura de Cuadros de
COMPONENTES DEL SISTEMA DE CADA COMPONENTE Constantine
CODIGO FUENTE DE LOS COMPONENTES
DEL SISTEMA
Tcnicas de Estructuracin de Programas
2.2.: PREPARACION, EJECUCION y
EVALUACION DE LAS PRUEBAS
UNITARIAS
PRUEBAS UNITARIAS DE LOS Tcnicas de Prueba
COMPONENTES DEL SISTEMA E INFORME
DE PRUEBA UNITARIA
GUIA DE USUARIO
50
MODULO DCS: DESARROLLO DE COMPONENTES DEL SISTEMA
2.3.: DOCUMENTACION DE LOS
COMPONENlES DEL SISTEMA
DCS 3: REALIZAR PRUEBAS DE
INTEGRACION
3.1.: PREPARACION y EJECUCION DE
PRUEBAS DE INTEGRAOON
3.2.: EVALUACION y DOCUMENTACION
DE LOS RESULTADOS DE PRUEBAS
DE INTEGRACION
DOCUMENTACION COMPLETA DE LOS
PRUEBAS DE INTEGRACION ENTRE Tcnicas de Prueba
COMPONENTES DEL SISTEMA E INFORME DE
DOCUMENTACION CONSOLIDADA DE LOS
COMPONENTES AFECTAOOS POR
CORRECCIONES
INFORMES DE PRUEBAS DE INTEGRACION
GUIA DE USUARIO 51
. ..' ESQUEMADEREALizACfoN:DE ..'.....'::,:
Y
. .. . " ' .. :.,',., :'.'.;..,,. ;
, ;.
DCS2. DESARROLLAR Y PROBAR COMPONENTES DEL SISTEMA
CORRECCIONES
RESULTADOS
lCORRECCIONES
RESULTADOS
PREPARACION. EJECUCION
y EVALUACION DE LAS
PRUEBAS UNITARIAS
DCS3. REALIZAR PRUEBAS DE INTEGRACION
2.3 DOCUMENTACION DE LOS
2.1 GENERACION DEL CODIGO
,... ..,CORRECCIONES _--------..,
3.1 PREPARACION y EJECUCION .... 1----- 3.2 EVALUACION y DOCUMEN
DE PRUEBAS DE INTEGRACION TACION DE RESULTADOS DE
RESULTADOS
C/) C/}
C
....J W
W :J
. Q a:
O Q..
U W
Z Q
U C/}
W W
1- Z
O O
1
m
o
C/) U
o:
o
z W
W Q..
fil'
:J
U
o
o
GUIA DE USUARIO
MODULO DE DESARROLLO DE PROCEDIMIENTOS DE USUARIO (DPU)
52
SEGUIMIENTO Y CONTROL
ACCIONES DE CONTROL
DE CALIDAD
ACCiONES DE GESTION
DE PROYECTO
ACTIVIDADES
[]
'\l,ReYlS8t Planes DesarraCo
Prooedimien1oa de Usuario
'\l.ReviS. EstAndares
doCaJidall
'\l.Revisar Procedimientos
de Usuario
LEYENDA DEl GRAF1CO
'7 REVlSION INFORMAL
V (no n.ellsana firma)
y ~ ~ ~ A L
~ Ap'obar AdclUi61c:i/ln do
.... Reanos para Usu.-ios
3.2 Eopoc:ilica<:i/ln
Recursos necesarios
~ Ap'obar Pro-
.. ceclmiem08
~ Ap'obar Pro-
... c:edimientos
'\l,Revi8W Planes
Fonnac:i6n
5.2 Conaolidac:i/ln Docu-
mWlta06n Procedi.
mientol de Uluarios
GUIA DE USUARIO
DESARROLLO
ACTIVIDADES
DE PROCEDIMIENTOS
DE USUARIO
1 2 3 4 5
COMITE DE DIRECCION R
D,F F
DIRECTOR PROYECTO
R
F
F
GRUPO DE CALIDAD
R
F
GRUPO DE USUARIOS
DEPARTAMENTO DE TI
A
- -- -- -- ----- ----- - - --
A
A
EQUIPO DE PROYECTO
Jefe de Proyecto
E
R E
E E
--- -- -- ----- - --- - - --
Componentes Equipo E E
53
CLAVES:
.O = Dotar Recursos
E = Ejecucin
F = Revisin Formal
ACTIVIDADES:
1.Completar Plan de Desarrollo
de Procedimientos de Usuario
2.Elaborar Procedimientos de Usuario
3.Determinar Necesidades especiales
de funcionamiento del Sistema
4.Desarrollar Plan de Formacin
de Usuarios
S.Consolidar Procedimientos de Usuario
GUIA DE USUARIO
54
MODULO DPU: DESARROLLO DE PROCEDIMIENTOS DE USUARIO
DPU 1: COMPLETAR EL PLAN DE
DESARROLLO DE PROCEDIMIENTOS
DE USUARIO
1.1.:
1.2.:
PREPARACION DE UN BORRADOR
DEL PLAN DE DESARROLLO DE
ESPECIFICACION DE CRITERIOS DE
CALIDAD Y ESTANDARES DE
BORRADOR DEL PLAN DE DESARROLLO
DE PROCEDIMIENTOS DE USUARIO
PLAN DE O N ~ T R U O N DE LOS
PROCEDIMIENTOS DE USUARIO,
INCLUYENDO:
Estndares (Formato, estilo, distribucin y
mantenimiento)
Criterios de control de calidad
DPU 2: ELABORAR PROCEDIMIENTOS DE
USUARIO
2.1.: DISEO DE LA ESTRUCTURA DE
2.2.: ELABORACION DE
PROCEDIMIENTOS DE 'USUARIO
DISEO DE LA ESTRUCTURA DE
PROCEDIMIENTOS DE USUARIO:
De conversin de datos
Instalacin
Produccin/operacin
MANUAL DE USUARIO DEL NUEVO
SISTEMA
Indice de contenido
Textos
Diagramas
Tablas
GUIA DE USUARIO
55
DPU 3: DETERMINAR NECESIDADES
ESPECIALES PARA EL
FUNCIONAMIENTO DEL SISTEMA
3.1.: IDENTIFlCACION DE PERFILES DE
USUARIO
3.2.: ESPECIFICACION DE RECURSOS
NECESARIOS
DPU 4: DESARROLLAR EL PLAN DE
FORMACION DE USUARIOS
DEFINICION DE PERFILES DE USUARIO
REQUERIDOS
ESPECIFICACION DE RECURSOS
NECESARIOS
Equipos
Consumibles
Recursos para el entorno de trabajo
4.1.:
4.2.:
IDENTIFlCACION DE REQUISITOS Y
RECURSOS NECESARIOS PARA LA
FORMACION DE USUARIOS
PREPARACION DE LOS
MATERIALES DE FORMACION DE
USUARIOS
PLAN DE FORMACION EN EL NUEVO
SISTEMA
Recursos necesarios
Costes previstos
Lista de personal
Necesidades de formacin especlficas por
perfiles identificados
Esquema general de los cursos
MATERIAL DE FORMACION PARA LOS
USUARIOS .
Formato apropiado
Secuencia lgica de contenidos
Consistencia con procedimientos de
usuario
Extensin temporal adecuada
GUIA DE USUARIO
DPU 5: CONSOLIDAR PROCEDIMIENTOS DE
USUARIO
5.1.: ORGANlZACION DE LA
DOCUMENTACION DE
5.2.: CONSOLIDACION DE LA
DOCUMENTACION DE
MAP - Metodologla METRICA Versin 2
56
DOCUMENTACION RECOPILADA
Procedimientos de usuario
Plan de Formacin de usuarios
CONSOLIDACION y REVISION DE LOS
GUIA DE USUARIO
DPU4:DESARROLLAR PLAN DE
DPU1:COMPLETAR EL PLAN FORMACION USUARIOS
DE DESARROLLO DE LOS
4.1 Identificacin de Requisitos
y Recursos necesarios para
Formacin de Usuarios
DPU2: ELABORAR LOS
4.2 Preparacin de los Materiales
de Formacin de Usuarios
DPU3:DETERMINAR NECESIDADES
ESPECIALES FUNCIONAMIENTO
DEL SISTEMA
(PERFILES DE USUARIO)
57
N
e
:5!
Q
<
'"
l.tl

Q
5
'O
"
I
::2
I:l.
GUlA DE USUARIO
60
PLAN
DE SISTEMAS
DE INFORMACION
PRUEBAS
IMPLANTACION
y ACEPTACION DEL SISTEMA
LEYENDA DEL GRAFICO
o ACTIVIDAD oTAREA
t22'J
11 1 ti
GUIA DE USUARIO
MODULO DE PRUEBAS.IMPLANTACION y ACEPTACION DEL SISTEMA (PIA)
61
o ACCIONES DE CONTROL
DE CALIDAD
ACCIONES DE GESTION
DE PROYECTO
'7AevlSBT resuhados
V Pruebas del Sistema
resultados
V Pruebas del Slatema
-Revisar resultados
T Prueba8 do Aceptacin
ACTIVIDADES
L.. -, 11-__"""T .....,r-__ Iof II------r------I-<FIN
0
1BAS SISTEMA 1 I ACEPTACION 1
1.1 Preparacin Pruebas 3.1 Preparacin Pruebas
del Sistema de Aceptaci6n
12Creacin enlllmO 3.2 Preparacin EnIllmO
de Pruebas del SIstema de Produa:i6n
1.3 Realizacin de las 3.3 Realizacin Pruebas
Pruebas del Sistema de Aceptaci6n
LEYENQA PE! GBAACO
n REVISION INFORMAL
V (no necesaria firma)
_ REVISION FORMAL
'f' (necesaria firma)
L..__-..I1 2. 11-__-'
"1 IMPlANTACION I
1- 2.1 R8Ylsin del Plan de
Implantacin
t- 2.2 Preparllcin del PIarl de
tr8bajo de Implantacin
.....
I DE PRODUCCION I
1- 4.1 Instalaci6n P_""lenlDs 81J1D.
maticos de Produa:i6n
1- 42 Installlci6n P_imienlDs
manual.. de Produa:in
1- 4.3 Inicio P_imienlDs
de Produa:i6n
62
GUIA DE USUARIO
PRUEBAS,IMPLANTACION
ACTIVIDADES
Y ACEPTACION
DEL SISTEMA
1 2 3 4
COMITE DE DIRECCION
I
F
DIRECTOR PROYECTO
I
F
GRUPO DE CALIDAD
R
E,F
GRUPO DE USUARIOS E,F
DEPARTAMENTO DE TI
E
R
E E
- - - --
----_. - -- --
- - - --
E R E E
EQUIPO DE PROYECTO
Jefe de Proyecto
E,R
E
E E
- - - -- - - - -- - - - -- - - ---
Componentes Equipo
E
CLAVES:
A: Asistencia Tcnica
D: Dotar Recursos
E: Ejecucin
F: Revisin formal
R: Revisin informal
1: Suministra informacin
ACTIVIDADES:
1. Disenar y Realizar Pruebas
del Sistema
2. Actualizar el Plan implantacin
3. Realizar Pruebas de Aceptacin
4. Estable'cer Procedimientos de 'Produccin
GUIA DE USUARIO
63
MODUW PIA: PRUEBAS, IMPLANTACION y ACEPTACION DEL SISTEMA
PIA 1: DlSEi'lAR y REALIZAR LAS PRUEBAS
DEL SISTEMA
1.1.: PREPARACION DE LAS PRUEBAS
DEL SISTEMA
1.2.: CREACION DEL ENTORNO DE
PRUEBAS DEL SISTEMA
13.: REALlZACION DE LAS PRUEBAS
DEL SISTEMA
PIA 2: ACTUALIZAR EL PLAN DE
lMPLANTACION
2.1.: REVISION DEL PLAN DE
IMPLANTACION
2.2.: PREPARACION DEL PLAN DE
TRABAJO DE IMPLANTACION
PLANES DE PRUEBA DEL SISTEMA
ENTORNO DE PRUEBAS DEL SISTEMA
PRUEBAS DEL SISTEMA E INFORME DE
PRUEBAS DEL SISTEMA Y APLlCACION
RESULTANTE
PLAN DE IMPLANTACION DEL SISTEMA
PLAN DE TRABAJO DE IMPLANTACION
Tcnicas de Prueba
GUIA DE USUARIO
64
MODULO PIA: PRUEBAS, IMPLANTACION y ACEPTACION DEL SISTEMA
P1A3: REALIZAR LAS PRUEBAS DE
ACEPTACION
3.1.: PREPARACION DE LAS PRUEBAS PRUEBAS DE ACEPTACION
DE ACEPTACION Revisin del Plan de Aceptacin en EFS
Revisin de casos de prueba especificados
3.2.: PREPARACION ENTORNO DE ENTORNO DE PRODUCCION
PRODUCCION
33.: REALIZACION DE LAS PRUEBAS PRUEBAS DE ACEPTACION E INFORME DE
DE ACEPTACION PRUEBAS DE ACEPTACION
INFORME DE PRUEBAS REALIZADAS
LISTA DE PROBLEMAS SIN RESOLVER
PIA 4: ESTABLECER PROCEDIMIENTOS DE
PRODUCCION
4.1.: INSTALACION DE PROCEDIMIENTOS AUTOMATICOS DE
PROCEDIMIENTOS AUTOMATICOS PRODUCCION
DE PRODUCCION
4.2.: INSTALACION DE PROCEDIMIENTOS MANUALES DE
PROCEDIMIENTOS MANUALES DE PRODUCCION
PRODUCCION
43.: INICIO DE PROCEDIMIENTOS DE FIRMA DE LOS USUARIOS RESPONSABLES
PRODUCCION DANDO POR IMPLANTADO EL NUEVO
SISTEMA
GUIA DE USUARIO
.'"O.':.... "'.. .... ..-.--
l,: .O:E:::.REAL1ZAG:Q:N::: .:.!.;...::
., ......
65
.
.,
:E
w
1-
00
00
Ci5
-J
OJ
W
W
el
:::J
O
a:
a.
(,)
w
Z el
00
w
w

1-
Z
O O
'Z (3
W
00

O
(,)
u:
O
6
1-
W
Z
a.
w
00
:E w
:::J
(,)
O
el
..
PIA1: DISEAR y REALIZAR LAS PRUEBAS DEL SISTEMA
CORRECCIONES
1.1 PREPARACION DE
1.3 REALlZACION DE
LAS PRUEBAS
LAS PRUEBAS
DEL SISTEMA
DEL SISTEMA
RESULTADOS
1.2 CREACION
DEL ENTORNO
DE PRUEBAS
GUIA DE USUARIO
ESQLJEMADE.REAbIZAOION DE PRUEBAS. DE ACEPTAC:ION'
.........
66
,.....-------..,CORRECCIONES,...--------..,
...J .z
z o
0 <:5 ......
5 .c:( ....

::l'. w:.:: ..

O .. (fY
..
()
'. : : :0:...
.' 5 0.'
W Z
g, O
'W (3
b<
o
Z .,U::'
W
'..' .. '.......... .... :..:.... W .i
-.. .3;:;>
"O'W'W
00
..
3.1 PREPARACION DE
LAS PRUEBAS
DE ACEPTACION
3.2 PREPARACION
DEL ENTORNO
DE PRODUCCION
RESULTADOS
3.3 REALlZACION DE
LAS PRUEBAS
DE ACEPTACION
GUIA DE USUARIO 68
PG PROYECTOS GRANDES

I FASE DE IMPLANTACION
\:=:J
FASES DE DISEfilo
YDESARROUO
DEL SISTEMA
(INICIO)
AEOlASlTOS

r--
I
I I
I
ARS
I
EFS
I
I I
1-6
I
1-4
FASE DE ANALISIS DEL SISTEMA

-{5P
I - TECNCA lNTEOAACtON
........ y
1- Da ......... 1- - ACE"ACION
I
@

I
...""""""'"
DTS Des ---
1-5
13
I PIA
k>
---- '--
l
1-4
I
DPU
I
I
15
1::- -1
I
GUIA DE USUARIO- 69
pp

ACTMOAO ACTMDAD NO OOCUaENT
OBL.IGATORIA CONDCIONAL
DE USUARIOS
FASES DE DISEflO
y DESARROLLO
DE SISTEMAS
(INICIO)
I
1
I
J
I

EFS
J
I ARS
I
1-6
J J t
1-3
FASE DE ANAlISIS DEL SISTEMA
[5;W

...........
TE<:MCO 1'ECHCA INT'EGRACION
1- - - "".....AClON
1- Da"''''''' 1-
I I
1
1
f
DTS Des

---
I
--f
1
15 1-3
PIA
----- ---
t
1-4
L.....-
-
J'
I
.J
DPU I
'5
.F"-I
- -,
1
GUIA DE USUARIO
MS MANTENIMIENTO DE SISTEMAS
~ ~
ACCION
.CAMBIO
r -- RECOMENDADA
I
I
I
I
I
PG
I
PP I
ARS
BP
ARS
2 4
EFS
DTS
ANALlSIS DE REQUISITOS
Des
~
ACTIVIDAD ACTIVIDAD FINAL FINAL
OBUGATOR!A CONO:CIONAL t ~ DOCUMENTADO DOCUMENTADO
70
GUIA DE USUARIO 71
BP BASADA PAQUETE
ACT1Y1DAD
C8U0ATORIA
DE SISTEMAS
FASE DE DESARROLLO DE SISTEMAS
'i5-J

(INICIO 1
_ _ _ _ _ _ _ _ REQUISITOS
_ _ R.IlClOOW. TECNICO __
I OB.SlSTEIlM. , _SI I
, ,
I
ARS
I I
EFS EFS
I I DTS
DTS
I I
1 3-6
I I
4-5 1-4 1

U
ESTUDIOS DE PAQUETES ESTANDAR
1...-..,
y DETERMINACION DEL ENTORNO TECNOLOGICO

----------------,
,
: I I
,
,
FASE DE ANALISIS DEL SISTEMA FASE DE DISEO DEL SISTEMA
,
I

S
:[7]
[?J
)
DE USUofJIOS DI: USUARIO I INTEORofrICDiI llEC..::"
PfIIODUeTO
PAOllUCTO
0lST"""...
,
I
I
_.
I
,
,
I
_...
I
I
,
I
----
-
- - ---
DPU
,
I
,
H
I
1-5
,'+
I PAUEIASV
, ,

________ 1 ACEP'fAClON
, ,
PIA ,
, ,
1-4
------------, I ,
- __ 1 I

1-3 I
D O
O
D
GUIA DE USUARIO 72
AO/i.Pl:AGIONDEL0IGLODE
EVOLlJTIVOALAMETODOLOGIAMe:TRICA2>
DESARROLLO COMPONENTES SiSTEMA
PRUEBAS,IMPLANTACION,ACEPTACION SISTEMA
!

GUIA DE USUARIO
DM DESARROLLO MODULAR
........................................

(INICIO 1
FEOUISIfOS DATOS
DEI. SSTBM DEL StSTEM\ DELSlSTDM r - IN1'ERFASEI

......... I IENTAESlSTE
I
IPROYECTO GRANDE
J-
I
I
I
ARS
I
I
I
1-4
IPROYECTO PEQUEO
I
I
-- ---
MODULO ANALISIS
DE REQUISITOS
DEL SISTEMA
CICLO DE VIDA DE CADA UNO DE LOS MODULOS
IDENTIFICADOS, SEGUN SUS CARACTERISTICAS
FASE DE ANALISIS DEL SISTEMA
9
I

c:J
CD-

I
1-4 _
------------,
D D
O
PRUEBAS DE INTEGRACION ENTRE MODULOS FASE DE IMPLANTACION
D
DEL SISTEMA
DEL SISTEMA GLOBAL
1'fIOClUCT. 1'fIOClUCT.
rn
"'.......
"""""'"
...... ......
_.....
_......
DOCUt&ffADO
MAP - Metodologa MElRICA VelSin 2
73

1993 - 092 - Metodología de Planificación y Desarrollo de Sistemas de Informacion PDF

Uploaded by

Document Information

Original Title

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

1993 - 092 - Metodología de Planificación y Desarrollo de Sistemas de Informacion PDF

Uploaded by

Copyright:

Available Formats

P.V.P. 6.000 Dtas.

DCS2. DESARROLlAR YPROBAR COMPONENTES DEL SISTEMA

1- 2.2 Plop.ad6n dol Plan do '.2 Instalad6n Ploctdimio"".

INTEOIIAClON TECNICA 000 _ero

DEL SISTEIM :t.w. fIm)IA DEL SSTEIlA r - lNTtAFASU

Al ...trib A' Q.AVE:&

2.6.3. DIAGRAMA DE ESTRUCTURA DE DATOS

PSI7: DEFINIR LAS ALTERNATIVAS

1.4. Descrl>cin de procesos

2.1. Construccin del modelo

DEI. SSTBM DEL StSTEM\ DELSlSTDM r - IN1'ERFASEI

You might also like