TICB2 - Planificacion Del Desarrollo

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.
Copia exclusiva de Jos Ignacio Mndez Yanes. Av de los Poblados 133, 7 - 3 - 28025 - Madrid - Tel. 917464968
B2G1T03 - PLANIFICACIN DEL DESARROLLO.
1. TCNICAS DE PLANIFICACIN ................................................................................................................................. 3

1.1. INTRODUCCIN A LA PLANIFICACIN DEL DESARROLLO .......................................................................... 3
1.2. HERRAMIENTAS BSICAS USADAS EN LA PLANIFICACIN ......................................................................... 3
1.3. APLICACIN DE LA TCNICA CPM....................................................................................................................... 4
1.3.1. ETAPA 1. IDENTIFICAR LAS TAREAS............................................................................................................... 4
1.3.2. ETAPA 2. AADIR RECURSOS Y TIEMPOS...................................................................................................... 5
1.3.3. ETAPA 3. ORDENAR LAS TAREAS..................................................................................................................... 5
1.3.4. ETAPA 4. CLCULO DEL CAMINO CRTICO .................................................................................................. 7
1.3.4.1. OBTENCIN DEL CAMINO CRTICO ........................................................................................................................... 8
1.4. DIFERENCIA FUNDAMENTAL ENTRE EL CPM Y EL PERT. .............................................................................. 8
1.5. USO DE APLICACIONES PARA LA PLANIFICACIN Y CONTROL DE PROYECTOS. ................................... 8
2. METODOLOGAS DE DESARROLLO: LA METODOLOGA MTRICA 3.......................................................... 8
2.1. INTRODUCCIN A LA METODOLOGA MTRICA 3 .......................................................................................... 8
2.1.1. QU ES UNA METODOLOGA? ...................................................................................................................... 9
2.1.2. PARA QU SIRVE?............................................................................................................................................ 9
2.1.3. OBJETIVOS.......................................................................................................................................................... 9
2.1.4. CARACTERSTICAS .......................................................................................................................................... 10
2.1.5. ESTRUCTURA ................................................................................................................................................... 10
2.2. PLANIFICACIN DE SISTEMAS DE INFORMACIN (PSI) ............................................................................... 11
2.2.1. DESCRIPCIN Y OBJETIVOS.......................................................................................................................... 11
2.2.2. ACTIVIDAD PSI 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIN ................................................. 12
2.2.3. ACTIVIDAD PSI 2: DEFINICIN Y ORGANIZACIN DEL PSI..................................................................... 13
2.2.4. ACTIVIDAD PSI 3: ESTUDIO DE LA INFORMACIN RELEVANTE............................................................. 13
2.2.5. ACTIVIDAD PSI 4: IDENTIFICACIN DE REQUISITOS............................................................................... 14
2.2.6. ACTIVIDAD PSI 5: ESTUDIO DE LOS SISTEMAS DE INFORMACIN ACTUALES.................................... 14
2.2.7. ACTIVIDAD PSI 6: DISEO DEL MODELO DE SISTEMAS DE INFORMACIN ........................................ 15
2.2.8. ACTIVIDAD PSI 7: DEFINICIN DE LA ARQUITECTURA TECNOLGICA............................................... 15
2.2.9. ACTIVIDAD PSI 8: DEFINICIN DEL PLAN DE ACCIN ............................................................................ 16
2.2.10. ACTIVIDAD PSI 9: REVISIN Y APROBACIN DEL PSI .............................................................................. 16
2.3. ESTUDIO DE VIABILIDAD DEL SISTEMA .......................................................................................................... 17
2.3.2. ACTIVIDAD EVS 1: ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA ................................................... 18
2.3.3. ACTIVIDAD EVS 2: ESTUDIO DE LA SITUACIN ACTUAL......................................................................... 18
2.3.4. ACTIVIDAD EVS 3: DEFINICIN DE REQUISITOS DEL SISTEMA ............................................................. 19
2.3.5. ACTIVIDAD EVS 4: ESTUDIO DE ALTERNATIVAS DE SOLUCIN............................................................. 20
2.3.6. ACTIVIDAD EVS 5: VALORACIN DE LAS ALTERNATIVAS ........................................................................ 21
2.3.7. ACTIVIDAD EVS 6: SELECCIN DE LA SOLUCIN..................................................................................... 22
2.4. ANLISIS DEL SISTEMA DE INFORMACIN..................................................................................................... 23
2.4.2. ACTIVIDAD ASI 1: DEFINICIN DEL SISTEMA............................................................................................ 24
2.4.3. ACTIVIDAD ASI 2: ESTABLECIMIENTO DE REQUISITOS ........................................................................... 25
2.4.4. ACTIVIDAD ASI 3: IDENTIFICACIN DE SUBSISTEMAS DE ANLISIS..................................................... 26
2.4.5. ACTIVIDAD ASI 4: ANLISIS DE LOS CASOS DE USO................................................................................. 26
2.4.6. ACTIVIDAD ASI 5: ANLISIS DE CLASES ...................................................................................................... 27
2.4.7. ACTIVIDAD ASI 6: ELABORACIN DEL MODELO DE DATOS ................................................................... 27
2.4.8. ACTIVIDAD ASI 7: ELABORACIN DEL MODELO DE PROCESOS............................................................ 28
2.4.9. ACTIVIDAD ASI 8: DEFINICIN DE INTERFACES DE USUARIO............................................................... 28
2.4.10. ACTIVIDAD ASI 9: ANLISIS DE CONSISTENCIA Y ESPECIFICACIN DE REQUISITOS ....................... 30
2.4.11. ACTIVIDAD ASI 10: ESPECIFICACIN DEL PLAN DE PRUEBAS............................................................... 32
2.4.12. ACTIVIDAD ASI 11: APROBACIN DEL ANLISIS DEL SISTEMA DE INFORMACIN............................ 32
2.5. DISEO DEL SISTEMA DE INFORMACIN ........................................................................................................ 33
TEMARIO-TICB-feb04 B2G1T03
Actualizado en febrero de 2004 Pgina 1 de 68

2.5.2. ACTIVIDAD DSI 1: DEFINICIN DE LA ARQUITECTURA DEL SISTEMA ................................................. 35
2.5.3. ACTIVIDAD DSI 2: DISEO DE LA ARQUITECTURA DE SOPORTE .......................................................... 37
2.5.4. ACTIVIDAD DSI 3: DISEO DE CASOS DE USO REALES............................................................................ 38
2.5.5. ACTIVIDAD DSI 4: DISEO DE CLASES ........................................................................................................ 39
2.5.6. ACTIVIDAD DSI 5: DISEO DE LA ARQUITECTURA DE MDULOS DEL SISTEMA................................ 40
2.5.7. ACTIVIDAD DSI 6: DISEO FSICO DE DATOS............................................................................................ 41
2.5.8. ACTIVIDAD DSI 7: VERIFICACIN Y ACEPTACIN DE LA ARQUITECTURA DEL SISTEMA................. 42
2.5.9. ACTIVIDAD DSI 8: GENERACIN DE ESPECIFICACIONES DE CONSTRUCCIN .................................. 43
2.5.10. ACTIVIDAD DSI 9: DISEO DE LA MIGRACIN Y CARGA INICIAL DE DATOS....................................... 45
2.5.11. ACTIVIDAD DSI 10: ESPECIFICACIN TCNICA DEL PLAN DE PRUEBAS............................................. 46
2.5.12. ACTIVIDAD DSI 11: ESTABLECIMIENTO DE REQUISITOS DE IMPLANTACIN..................................... 48
2.5.13. ACTIVIDAD DSI 12: APROBACIN DEL DISEO DEL SISTEMA DE INFORMACIN.............................. 48
2.6. CONSTRUCCIN DEL SISTEMA DE INFORMACIN........................................................................................ 49
2.6.2. ACTIVIDAD CSI 1: PREPARACIN DEL ENTORNO DE GENERACIN Y CONSTRUCCIN ................... 50
2.6.3. ACTIVIDAD CSI 2: GENERACIN DEL CDIGO DE LOS COMPONENTES Y PROCEDIMIENTOS........ 51
2.6.4. ACTIVIDAD CSI 3: EJECUCIN DE LAS PRUEBAS UNITARIAS ................................................................. 51
2.6.5. ACTIVIDAD CSI 4: EJECUCIN DE LAS PRUEBAS DEINTEGRACIN...................................................... 51
2.6.6. ACTIVIDAD CSI 5: EJECUCIN DE LAS PRUEBAS DEL SISTEMA............................................................. 52
2.6.7. ACTIVIDAD CSI 6: ELABORACIN DE LOS MANUALES DE USUARIO..................................................... 52
2.6.8. ACTIVIDAD CSI 7: DEFINICIN DE LA FORMACIN DE USUARIOS FINALES ...................................... 53
2.6.9. ACTIVIDAD CSI 8: CONSTRUCCIN DE LOS COMPONENTES Y PROCEDIMIENTOS DE MIGRACIN Y
CARGA INICIAL DE DATOS............................................................................................................................................. 53
2.6.10. ACTIVIDAD CSI 9: APROBACIN DEL SISTEMA DE INFORMACIN ....................................................... 54
2.7. IMPLANTACIN Y ACEPTACIN DEL SISTEMA.............................................................................................. 54
2.7.2. ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIN.................................................. 55
2.7.3. ACTIVIDAD IAS 2: FORMACIN NECESARIA PARA LA IMPLANTACIN ................................................. 56
2.7.4. ACTIVIDAD IAS 3: INCORPORACIN DEL SISTEMA AL ENTORNO DE OPERACIN............................. 57
2.7.5. ACTIVIDAD IAS 4: CARGA DE DATOS AL ENTORNO DE OPERACIN ..................................................... 57
2.7.6. ACTIVIDAD IAS 5: PRUEBAS DE IMPLANTACIN DEL SISTEMA.............................................................. 58
2.7.7. ACTIVIDAD IAS 6: PRUEBAS DE ACEPTACIN DEL SISTEMA .................................................................. 58
2.7.8. ACTIVIDAD IAS 7: PREPARACIN DEL MANTENIMIENTO DEL SISTEMA............................................... 59
2.7.9. ACTIVIDAD IAS 8: ESTABLECIMIENTO DEL ACUERDO DE NIVEL DE SERVICIO.................................. 59
2.7.10. ACTIVIDAD IAS 9: PRESENTACIN Y APROBACIN DEL SISTEMA ......................................................... 60
2.7.11. ACTIVIDAD IAS 10: PASO A PRODUCCIN.................................................................................................. 61
2.8. MANTENIMIENTO DE SISTEMAS DE INFORMACIN ..................................................................................... 61
2.8.2. ACTIVIDAD MSI 1: REGISTRO DE LA PETICIN ......................................................................................... 62
2.8.3. ACTIVIDAD MSI 2: ANLISIS DE LA PETICIN ........................................................................................... 63
2.8.4. ACTIVIDAD MSI 3: PREPARACIN DE LA IMPLEMENTACIN DE LA MODIFICACIN ....................... 63
2.8.5. ACTIVIDAD MSI 4: SEGUIMIENTO Y EVALUACIN DE LOS CAMBIOS HASTA LA ACEPTACIN ........ 64
3. CONCLUSIN ................................................................................................................................................................. 65
4. BIBLIOGRAFA .............................................................................................................................................................. 65
5. ESQUEMA RESUMEN ................................................................................................................................................ 66
1. TCNICAS DE PLANIFICACIN
1.1. INTRODUCCIN A LA PLANIFICACIN DEL DESARROLLO
El objetivo de la Planificacin del proyecto de Software es proporcionar un marco de trabajo que permita al gestor
hacer estimaciones razonables de recursos, costos y planificacin temporal. Estas estimaciones se hacen dentro
de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse regularmente a
medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del mejor caso, y peor
caso, de modo que los resultados del proyecto pueden limitarse.
El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a

estimaciones razonables.
Existen diversos tipos de planes:
Plan Descripcin
Plan de Desarrollo Describe la metodologa a utilizar en el desarrollo
del proyecto.
Describe los procedimientos de calidad, y los
Plan de Calidad estndares a utilizar en el proyecto.
Describe el enfoque los recursos y la planificacin

Plan de Validacin utilizada por la validacin.
Predice los requerimientos de mantenimiento del

Plan de Mantenimiento sistema, los costes de mantenimiento y el esfuerzo.
Describe como se adquirirn y desarrollarn los

Plan de Desarrollo Personal conocimientos y habilidades del personal.
Aunque hay que tener en cuenta que la planificacin conlleva una serie de problemas aadidos:
Es difcil estimar la longitud y dificultad de las tareas, por lo que la estimacin del coste es ms difcil.
La productividad no es proporcional al nmero de personas trabajando en una tarea.
Incluir personal en un proyecto en avance, retrasa el proyecto por sobrecargas en la comunicacin.
Lo inesperado siempre sucede. Es necesario considerar siempre contingencias.
1.2. HERRAMIENTAS BSICAS USADAS EN LA PLANIFICACIN
Aunque desde la antigedad se han realizado proyectos de gran envergadura como por ejemplo la construccin
de edificios pblicos, guerras, viajes, etc., no es hasta principios de este siglo cuando aparece el conocido
diagrama de Gantt en el que se refleja de forma esquemtica las tareas, su duracin y las fechas en que se
debern realizar. Trabajando sobre este diagrama el director de proyecto realizaba planificaciones y seguimiento
de un proyecto FIG.-1.
Dada la evolucin tecnolgica los seres humanos cada vez abordamos proyectos ms complejos, pero por otra
parte creamos tcnicas ms evolucionadas, completas y automticas para gestionar estos proyectos. La
construccin del misil Polaris, as como la solucin de los problemas en la gestin de la produccin de Dunlop
llevaron al desarrollo de las tcnicas conocidas como PERT (Tcnica para la Evaluacin y Revisin de
Programas) y CPM (Mtodo del Camino Crtico) que aportan a la programacin de proyectos tcnicas
matemticas.
Estas tcnicas surgieron de la necesidad de obtener algoritmos automatizables que ayudasen a los gestores de
proyectos complejos en la construccin de calendarios (programas). En el siguiente punto veremos mediante un
ejemplo como se aplica en el CPM.
4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9
Start
T4
T1
T2
M1
T7
T3
M5
T8
M3
M2
T6
T5
M4
T9
M7
T10
M6
T1 1
M8
T12
Finish
FIG-1
1.3. APLICACIN DE LA TCNICA CPM
El CPM se realiza sobre un proyecto en cuatro etapas, a continuacin se describe cada una de ellas:
1.3.1. ETAPA 1. IDENTIFICAR LAS TAREAS
Se deben identificar cada una de las tareas que forman parte del desarrollo del proyecto como muestra la FIG-2
Especificar
Necesidades
Diseo Base
Diseo de Datos
Aplicacin
Diseo
Programas
Desarrollo
Contabilidad Realizacin
esquemas
Codificacin
Codificacin
Programas
Pruebas
FIG-2
Si queremos realizar el proceso de forma manual, rellenaremos una ficha por cada actividad identificada. El
formato de la ficha ser el que se muestra en la FIG-3.
Especificacin de tarea
Nmero: 3.1.
Nombre: Diseo B.D.
Descripcin: Se diseara la base de datos, partiendo del modelo
entidad-relacin propuesto en el anlisis y con el
objetivo de tener un sistema funcionando sobre DB2.
Esfuerzo Estimado: 2 semanas/hombre
Entregables: Estructura de implementacin de la B.D.
:
FIG-3
1.3.2. ETAPA 2. AADIR RECURSOS Y TIEMPOS
A cada actividad se le asignarn recursos (personas, material, equipos, etc.) y tiempo estimado para su
realizacin, completando la ficha.
1.3.3. ETAPA 3. ORDENAR LAS TAREAS
En esta etapa se tienen que organizar las tareas en base al orden tcnico de ejecucin. As sabemos que hay que
hacer las especificaciones antes de disear el programa. Nos podemos plantear las siguientes preguntas para
ordenar las tareas:
Qu se puede hacer ahora?

Qu debe haberse hecho antes de esto?
Qu podra hacerse a la vez?
Qu debe seguir a lo que hacemos ahora?
Si se trata de calcular el Camino Crtico de forma manual ser interesante el pinchar todas las tareas en un
tablero de corcho, sealando mediante cuerdas la ordenacin de las tareas, ver FIG-4. Esta representacin es
conocida como red de precedencia, aunque su apariencia es diferente al grfico PERT en algunos programas
informticos se describe errneamente con este nombre.
FIG-4
Si tenemos un diagrama complejo, y queremos realizar los clculos de forma manual se puede utilizar el mtodo
que se describe a continuacin.
Este diagrama se compone de nodos y arcos, similares a las pegatinas comentadas anteriormente. Los nodos
representan a las tareas y la informacin necesaria para calcular sus fechas de realizacin. Los arcos indican las
precedencias entre tareas.
Vamos a representar cada nodo (tarea) como se ve en la FIG-5.
Etiqueta actividad Duracin

Inicio temprano DESCRIPCIN DE LA ACTIVIDAD Final temprano
Inicio tardo Final tardo
Mximo tiempo disponible Holgura
FIG-5
Donde:
DESCRIPCIN DE LA ACTIVIDAD es el nombre que le hemos dado a la actividad. Por ejemplo:

Codificacin Programa A
Etiqueta actividad es un nmero arbitrario y que identifica unvocamente a cada actividad.
Duracin es el tiempo que calculamos que se tardar en completar la tarea, teniendo en cuenta el
esfuerzo y los recursos asignados a la tarea. Por ejemplo una tarea que estimamos requerir seis das-
hombre de esfuerzo, si se realiza entre tres personas podra tener una duracin de dos das.
Inicio temprano es la fecha en que se podr comenzar la tarea si no se retrasa ninguna otra. Ms
adelante veremos como calcularla.
Final temprano es, en el caso de iniciarse la tarea en el inicio temprano, lo antes que puede finalizar,
respetando su duracin.
Inicio tardo es la fecha ms retrasada en la que puede comenzar la tarea para que se pueda completar el
proyecto en la fecha marcada como final del proyecto.
Final tardo es la fecha ms retrasada en la que puede terminar la tarea para que se pueda completar el
proyecto en la fecha marcada como final del proyecto.
Mximo tiempo disponible es el tiempo mximo que puede durar una tarea en caso de comenzar en su
Inicio temprano y concluir en su Final tardo.
Holgura es la diferencia entre el Mximo tiempo disponible y su Duracin
1.3.4. ETAPA 4. CLCULO DEL CAMINO CRTICO
Una vez tenemos todas las tareas con sus respectivas duraciones y las precedencias pasamos a dibujar una red
en la que aparezca para cada tarea una caja similar a la vista en el punto anterior con casi todos los campos
vacos. Entre ellas aparecern los arcos indicando precedencias, tendremos algo similar a la FIG-6.
Ahora calculamos las fechas tempranas. Para esto seguimos los siguientes pasos:
En aquellas tareas que no tienen ningn predecesor se le asigna a Inicio temprano el valor cero.
Si la tarea tiene predecesoras y todas estas tienen calculado su Final temprano se toma como Inicio
temprano el mximo de todos ellos.
El Final temprano de cada tarea se calcula como el Inicio temprano ms la Duracin.
Repetiremos estos pasos hasta que todas las tareas tengan sus fechas tempranas.
FIG-6
Para calcular las fechas tardas procederemos con los pasos que se describen a continuacin.
Se obtiene la fecha de finalizacin de proyecto ms tarda. Esta puede venir dada por algn tipo de
razones externas o puede que se nos pida que el proyecto termine lo antes posible, en este caso la fecha
de finalizacin ms tarda ser el mximo de los "Final temprano" de todas las tareas.
A aquellas tareas que no sean predecesoras de ninguna otra se les asigna como Final tardo la fecha de
finalizacin ms tarda del punto 4.
El Inicio tardo se calcula restando al Final tardo la Duracin.
En aquellas tareas que son predecesoras de otras se calcula el Final tardo como el mnimo de los Inicio
tardo de las tareas de que es predecesora.
Los otros dos campos de cada tarea: Mximo tiempo disponible y Holgura se calculan mediante las siguientes
frmulas:
Mximo tiempo disponible = Final tardo - Inicio temprano
Holgura = Mximo tiempo disponible - Duracin
1.3.4.1. OBTENCIN DEL CAMINO CRTICO
Llamamos camino crtico de una planificacin al conjunto de tareas que tienen Holgura cero. Siempre que se
solicita que el proyecto tenga la duracin mnima tendremos un camino crtico.
Se le llama camino crtico porque suele ser un camino que parte de una tarea que no tiene predecesoras y
atraviesa el grafo por tareas con holgura cero hasta terminar en una tarea que no es predecesora de ninguna
otra. Puede darse el caso de que con el "camino crtico" se puedan construir varias secuencias, partiendo de
tareas sin predecesoras y se alcancen tareas sin sucesoras.
A las tareas del camino crtico se les llama tareas crticas y esto se debe a que un retraso en cualquiera de ellas
lleva a un retraso del final del proyecto.
1.4. DIFERENCIA FUNDAMENTAL ENTRE EL CPM Y EL PERT.
Aunque en principio son similares los algoritmos de ambos mtodos, la asignacin de duraciones de las tareas
en el PERT es algo mas elaborada. En lugar de realizarse una sola estimacin se realizan tres estimaciones:
"tm" tiempo medio que se estima para la actividad,

"to" tiempo optimista, el que resultara de ir todo muy bien, y el
"tp" el tiempo pesimista, el que resultara si todo fuese mal en esta tarea.
A la tarea se le asigna como duracin el resultado de:
Duracin = ( to + 4 tm + tp) / 6
Por otra parte el grafo se construye de forma dual a la vista. Los arcos modelan las actividades o tareas, mientras
que los nodos modelan la relacin de precedencia de las tareas. As un nodo indica que los arcos que llegan a l
anteceden a los que salen de l.
1.5. USO DE APLICACIONES PARA LA PLANIFICACIN Y CONTROL DE PROYECTOS.
Como hemos indicado estos algoritmos se hicieron pensando en el uso de sistemas de cmputo automtico, as
que no es de extraar que existan muchas aplicaciones que den soporte a stos. Entre las ms conocidas que
funcionan sobre PC estn el CA-SuperProject y el MICROSOFT Project.
2. METODOLOGAS DE DESARROLLO: LA METODOLOGA MTRICA 3
2.1. INTRODUCCIN A LA METODOLOGA MTRICA 3
Antes de describir una metodologa, es necesario aclarar ciertas cuestiones, tales como:
Qu es una metodologa?
Para qu sirve?
Por que la respuesta a estas preguntas va a ser crucial para poder entender y evaluar toda la exposicin siguiente
sobre la metodologa Mtrica 3.
2.1.1. QU ES UNA METODOLOGA?
Segn el Diccionario de la Lengua Espaola de la Real Academia, metodologa es Ciencia del mtodo o
Conjunto de mtodos que se siguen en una investigacin cientfica o en una exposicin doctrinal. Aunque existe
otra un poco ms certera; Modo de decir o hacer con orden una cosa, parece que esto aclara algo ms, lo que
veremos en el tema es un modo o manera concreto (Mtrica 3) de hacer con orden una cosa (desarrollo de
sistemas de informacin).
El desarrollo de sistemas de informacin es, una tarea de resolucin de problemas, en la que el problema a
resolver consiste en traducir:
La situacin-problema a un sistema de representacin til para nuestros propsitos (anlisis de

requisitos).
La representacin resultante de la fase anterior en otra que vaya acercando los objetos, conceptos y
relaciones a una forma inteligible por nuestro dominio objetivo (mquinas, personas, otros sistemas de
informacin); de esta manera realizaremos el diseo, desde el cual, en un proceso de traduccin final,
codificaremos los programas de ordenador, las instrucciones para los usuarios, las interfaces con otros
sistemas, etc.
2.1.2. PARA QU SIRVE?
En primer lugar como gua; nos dice lo que tenemos que hacer, cmo, cundo y quin tiene que hacerlo;
adems, lo hace de manera completa; podremos saltarnos los pasos que consideremos convenientes
siempre que comprendamos la estructura del mtodo y podamos evaluar la conveniencia de utilizar
atajos.
En segundo lugar, determina los puntos del proceso en los que debemos detenernos y comprobar cmo
vamos, algo bastante importante y que evita la propagacin de los errores a travs del proceso.
En tercer lugar, permite que los conocimientos adquiridos en el desarrollo de sistemas de informacin se
plasmen en el mtodo que la organizacin utiliza para ello mediante su continua revisin y adaptacin y
pasen a ser patrimonio de la organizacin y no solo de las personas que llevan a acabo la tarea.
2.1.3. OBJETIVOS
La metodologa MTRICA Versin 3 ofrece a las Organizaciones un instrumento til para la sistematizacin de las
actividades que dan soporte al ciclo de vida del software dentro del marco que permite alcanzar los siguientes
objetivos:
Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los fines de la Organizacin
mediante la definicin de un marco estratgico para el desarrollo de los mismos.
Dotar a la Organizacin de productos software que satisfagan las necesidades de los usuarios dando una
mayor importancia al anlisis de requisitos.
Mejorar la productividad de los departamentos de Sistemas y Tecnologas de la Informacin y las
Comunicaciones, permitiendo una mayor capacidad de adaptacin a los cambios y teniendo en cuenta la
reutilizacin en la medida de lo posible.
Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software a
lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, as como las
necesidades de todos y cada uno de ellos.
Facilitar la operacin, mantenimiento y uso de los productos software obtenidos.
2.1.4. CARACTERSTICAS
La nueva versin de MTRICA contempla el desarrollo de Sistemas de Informacin para las distintas
tecnologas que actualmente estn conviviendo y los aspectos de gestin que aseguran que un Proyecto
cumple sus objetivos en trminos de calidad, coste y plazos.
Su punto de partida es la versin anterior de MTRICA de la cual se han conservado la adaptabilidad,
flexibilidad y sencillez, as como la estructura de actividades y tareas, si bien las fases y mdulos de
MTRICA versin 2.1 han dado paso a la divisin en Procesos, ms adecuada a la entrada-
transformacin-salida que se produce en cada una de las divisiones del ciclo de vida de un proyecto. Para
cada tarea se detallan los participantes que intervienen, los productos de entrada y de salida as como las
tcnicas y prcticas a emplear para su obtencin.
En la elaboracin de MTRICA Versin 3 se han tenido en cuenta los mtodos de desarrollo ms
extendidos, as como los ltimos estndares de ingeniera del software y calidad, adems de referencias
especficas en cuanto a seguridad y gestin de proyectos. Tambin se ha tenido en cuenta la experiencia
de los usuarios de las versiones anteriores para solventar los problemas o deficiencias detectados.
2.1.5. ESTRUCTURA
En una nica estructura la metodologa MTRICA Versin 3 cubre distintos tipos de desarrollo: estructurado y
orientado a objetos, facilitando a travs de interfaces la realizacin de los procesos de apoyo u organizativos:
Gestin de Proyectos, Gestin de Configuracin, Aseguramiento de Calidad y Seguridad.
La automatizacin de las actividades propuestas en la estructura de MTRICA Versin 3 es posible ya que sus
tcnicas estn soportadas por una amplia variedad de herramientas de ayuda al desarrollo.
Cada Proceso detalla las Actividades y Tareas a realizar.
Para cada tarea se indican:
Las tcnicas y prcticas a utilizar

Los responsables de realizarla
Sus productos de entrada y salida
La estructura de procesos es la siguiente:
PLANIFICACIN PSI
DESARROLLO
ESTUDIO DE VIABILIDAD EVS
ANLISIS ASI
DISEO DSI
CONSTRUCCIN CSI
IMPLANTACIN Y ACEPTACIN IAS
MANTENIMIENTO MSI
Los interfaces son los siguientes FIG-7:
FIG-7
2.2. PLANIFICACIN DE SISTEMAS DE INFORMACIN (PSI)
2.2.1. DESCRIPCIN Y OBJETIVOS
El Plan de Sistemas de Informacin tiene como objetivo la obtencin de un marco de referencia para el desarrollo
de sistemas de informacin que responda a los objetivos estratgicos de la organizacin. Este marco de
referencia consta de:
Una descripcin de la situacin actual, que constituir el punto de partida del Plan de Sistemas de
Informacin. Dicha descripcin incluir un anlisis tcnico de puntos fuertes y riesgos, as como el anlisis
de servicio a los objetivos de la organizacin.
Un conjunto de modelos que constituya la arquitectura de informacin.
Una propuesta de proyectos a desarrollar en los prximos aos, as como la prioridad de realizacin de
cada proyecto.
Una propuesta de calendario para la ejecucin de dichos proyectos.
La evaluacin de los recursos necesarios para los proyectos a desarrollar en el prximo ao, con el
objetivo de tenerlos en cuenta en los presupuestos. Para el resto de proyectos, bastar con una
estimacin de alto nivel.
Un plan de seguimiento y cumplimiento de todo lo propuesto mediante unos mecanismos de evaluacin
adecuados.
La perspectiva del plan debe ser estratgica y operativa, no tecnolgica.
Es fundamental que la alta direccin de la organizacin tome parte activa en la decisin del Plan de Sistemas de
Informacin con el fin de posibilitar su xito. La direccin debe convencer a sus colaboradores ms directos de la
necesidad de realizacin del plan; de su apoyo de forma constructiva, mentalizndose de que la ejecucin del
mismo requerir la utilizacin de unos recursos de los cuales son responsables.
La presentacin del Plan de Sistemas de Informacin y la constitucin del equipo supone el arranque del proyecto
y es fundamental que las ms altas instancias de la organizacin estn implicadas en ambos, dando el apoyo
necesario y aportando todo tipo de medios. Explicar el plan a las personas de la organizacin y a las unidades
organizativas afectadas sobre las que recaer el Plan, el apoyo de los altos directivos y la calificacin de los
recursos de las distintas unidades implicadas, sern factores crticos de xito del Plan de Sistemas de
Informacin.
El nivel de detalle con el que se har el estudio de la situacin actual depender de la existencia de
documentacin actual, de si hay personas que conozcan dicha documentacin y de la predisposicin a una
sustitucin total o parcial por sistemas de informacin nuevos. En cualquier caso, como paso previo para detectar
aspectos importantes que puedan afectar a la organizacin, es necesario investigar sus puntos fuertes, reas de
mejora, riesgos y amenazas posibles y hacer un diagnstico de los mismos.
Para la elaboracin del Plan de Sistemas de Informacin se estudian las necesidades de informacin de los
procesos de la organizacin afectados por el Plan, con el fin de definir los requisitos generales y obtener modelos
conceptuales de informacin. Por otra parte se evalan las opciones tecnolgicas y se propone un entorno.
Tras analizar las prioridades relacionadas con las distintas variables que afectan a los sistemas de informacin,
se elabora un calendario de proyectos con una planificacin lo ms detallada posible de los ms inmediatos.
Adems, se propone una sistemtica para mantener actualizado el Plan de Sistemas de Informacin para incluir
en l todos los cambios necesarios, garantizando el cumplimiento adecuado del mismo.
A continuacin se incluye un grfico que representa la secuencia de actividades del proceso PSI FIG-8.
FIG-8
Aunque los resultados de la actividad Estudio de informacin relevante (PSI 3) debern tenerse en cuenta para la
definicin de requisitos que se efecta en la actividad Identificacin de Requisitos (PSI 4), ambas podrn
realizarse en paralelo, junto con el Estudio de los Sistemas de Informacin actuales (PSI 3) .
2.2.2. ACTIVIDAD PSI 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIN
El objetivo de esta actividad es determinar la necesidad del Plan de Sistemas de Informacin y llevar a cabo el
arranque formal del mismo, con el apoyo del nivel ms alto de la organizacin. Como resultado, se obtiene una
descripcin general del Plan de Sistemas de Informacin que proporciona una definicin inicial del mismo,
identificando los objetivos estratgicos en los que apoya, as como el mbito general de la organizacin al que
afecta, lo que permite implicar a las direcciones de las reas afectadas por el Plan de Sistemas de Informacin.
Adems, se identifican los factores crticos de xito y los participantes en el Plan de Sistemas de Informacin,
nombrando a los mximos responsables.
A continuacin se incluye una tabla resumen con las tareas de la presente actividad:
2.2.3. ACTIVIDAD PSI 2: DEFINICIN Y ORGANIZACIN DEL PSI
En esta actividad se detalla el alcance del plan, se organiza el equipo de personas que lo va a llevar a cabo y se
elabora un calendario de ejecucin. Todos los resultados o productos de esta actividad constituirn un marco de
actuacin del proyecto ms detallado que en PSI 1 en cuanto a objetivos, procesos afectados, participantes,
resultados y fechas de entrega.
2.2.4. ACTIVIDAD PSI 3: ESTUDIO DE LA INFORMACIN RELEVANTE
El objetivo de esta actividad es recopilar y analizar todos los antecedentes generales que puedan afectar a los
procesos y a las unidades organizativas implicadas en el Plan de Sistemas de Informacin, as como a los
resultados del mismo. Pueden ser de especial inters los estudios realizados con anterioridad al Plan de Sistemas
de Informacin, relativos a los sistemas de informacin de su mbito, o bien a su entorno tecnolgico, cuyas
conclusiones deben ser conocidas por el equipo de trabajo del Plan de Sistemas de Informacin.
La informacin obtenida en esta actividad se tendr en cuenta en la elaboracin de los requisitos.
2.2.5. ACTIVIDAD PSI 4: IDENTIFICACIN DE REQUISITOS
El objetivo final de esta actividad va a ser la especificacin de los requisitos de informacin de la organizacin, as
como obtener un modelo de informacin que los complemente. Para conseguir este objetivo, se estudia el
proceso o procesos de la organizacin incluidos en el mbito del Plan de Sistemas de Informacin. Para ello es
necesario llevar a cabo sesiones de trabajo con los usuarios, analizando cada proceso tal y como debera ser, y
no segn su situacin actual, ya que sta puede estar condicionada por los sistemas de informacin existentes.
Del mismo modo, se identifican los requisitos de informacin, y se elabora un modelo de informacin que
represente las distintas entidades implicadas en el proceso, as como las relaciones entre ellas. Por ltimo, se
clasifican los requisitos identificados segn su prioridad, con el objetivo de incorporarlos al catlogo de requisitos
del Plan de Sistemas de Informacin.
2.2.6. ACTIVIDAD PSI 5: ESTUDIO DE LOS SISTEMAS DE INFORMACIN ACTUALES
El objetivo de esta actividad es obtener una valoracin de la situacin actual al margen de los requisitos del
catlogo, apoyndose en criterios relativos a facilidad de mantenimiento, documentacin, flexibilidad, facilidad de
uso, etc. En esta actividad se debe tener en cuenta la opinin de los usuarios, ya que aportarn elementos de
valoracin, como por ejemplo, su nivel de satisfaccin con cada sistema de informacin. Se seleccionan los
sistemas de informacin actuales que son objeto del anlisis y se lleva a cabo el estudio de los mismos con la
profundidad y el detalle que se determine conveniente en funcin de los objetivos definidos para el Plan de
Sistemas de Informacin. Este estudio permite, para cada sistema, determinar sus carencias y valorarlos
2.2.7. ACTIVIDAD PSI 6: DISEO DEL MODELO DE SISTEMAS DE INFORMACIN
El objetivo de esta actividad es identificar y definir los sistemas de informacin que van a dar soporte a los
procesos de la organizacin afectados por el Plan de Sistemas de Informacin. Para ello, en primer lugar, se
analiza la cobertura que los sistemas de informacin actuales dan a los requisitos recogidos en el catlogo
elaborado en las actividades Estudio de la Informacin Relevante (PSI 3) e Identificacin de Requisitos (PSI 4).
Esto permitir efectuar un diagnstico de la situacin actual, a partir del cual se seleccionan los sistemas de
informacin actuales considerados vlidos, identificando las mejoras a realizar en los mismos. Por ltimo, se
definen los nuevos sistemas de informacin necesarios para cubrir los requisitos y funciones de los procesos no
soportados por los sistemas actuales seleccionados. Teniendo en cuenta los resultados anteriores, se elabora el
modelo de sistemas de informacin vlido para dar soporte a los procesos de la organizacin incluidos en el
mbito del Plan de Sistemas de Informacin.
2.2.8. ACTIVIDAD PSI 7: DEFINICIN DE LA ARQUITECTURA TECNOLGICA
En esta actividad se propone una arquitectura tecnolgica que de soporte al modelo de informacin y de sistemas
de informacin incluyendo, si es necesario, opciones. Para esta actividad se tienen en cuenta especialmente los
requisitos de carcter tecnolgico, aunque es necesario considerar el catlogo completo de requisitos para
entender las necesidades de los procesos y proponer los entornos tecnolgicos que mejor se adapten a las
mismas.
2.2.9. ACTIVIDAD PSI 8: DEFINICIN DEL PLAN DE ACCIN
En el Plan de Accin, que se elabora en esta actividad, se definen los proyectos y acciones a llevar a cabo para la
implantacin de los modelos de informacin y de sistemas de informacin, determinados en las actividades
Identificacin de Requisitos (PSI 4) y Diseo del Modelo de Sistemas de Informacin (PSI 6), con la arquitectura
tecnolgica propuesta en la actividad Definicin de la Arquitectura Tecnolgica (PSI 7). El conjunto de estos tres
modelos constituye la arquitectura de informacin. Dentro del Plan de Accin se incluye un calendario de
proyectos, con posibles alternativas, y una estimacin de recursos, cuyo detalle ser mayor para los ms
inmediatos. Para la elaboracin del calendario se tienen que analizar las distintas variables que afecten a la
prioridad de cada proyecto y sistema de informacin. El orden definitivo de los proyectos y acciones debe
pactarse con los usuarios, para llegar a una solucin de compromiso que resulte la mejor posible para la
organizacin. Por ltimo, se propone un plan de mantenimiento para el control y seguimiento de la ejecucin de
los proyectos, as como para la actualizacin de los productos finales del Plan de Sistemas de Informacin.
2.2.10. ACTIVIDAD PSI 9: REVISIN Y APROBACIN DEL PSI
Esta actividad tiene como objetivo contrastar con los responsables de la direccin del Plan de Sistemas de
Informacin la arquitectura de informacin y el plan de accin elaborados anteriormente, para mejorar la
propuesta si se considera necesario y por ltimo, obtener su aprobacin final.
2.3. ESTUDIO DE VIABILIDAD DEL SISTEMA
Mientras que el Plan de Sistemas de Informacin tiene como objetivo proporcionar un marco estratgico que sirva
de referencia para los Sistemas de Informacin de un mbito concreto de una organizacin, el objetivo del Estudio
de Viabilidad del Sistema es el anlisis de un conjunto concreto de necesidades para proponer una solucin a
corto plazo, que tenga en cuenta restricciones econmicas, tcnicas, legales y operativas. La solucin obtenida
como resultado del estudio puede ser la definicin de uno o varios proyectos que afecten a uno o varios sistemas
de informacin ya existentes o nuevos. Para ello, se identifican los requisitos que se ha de satisfacer y se estudia,
si procede, la situacin actual.
A partir del estado inicial, la situacin actual y los requisitos planteados, se estudian las alternativas de solucin.
Dichas alternativas pueden incluir soluciones que impliquen desarrollos a medida, soluciones basadas en la
adquisicin de productos software del mercado o soluciones mixtas. Se describe cada una de las alternativas,
indicando los requisitos que cubre.
Una vez descritas cada una de las alternativas planteadas, se valora su impacto en la organizacin, la inversin a
realizar en cada caso y los riesgos asociados. Esta informacin se analiza con el fin de evaluar las distintas
alternativas y seleccionar la ms adecuada, definiendo y estableciendo su planificacin. Si en la organizacin se
ha realizado con anterioridad un Plan de Sistemas de Informacin que afecte al sistema objeto de este estudio, se
dispondr de un conjunto de productos que proporcionarn informacin a tener en cuenta en todo el proceso.
Las actividades que engloba este proceso se recogen en la siguiente figura FIG-9, en la que se indican las
actividades que pueden ejecutarse en paralelo y las que precisan para su realizacin resultados originados en
actividades anteriores.
FIG-9
2.3.2. ACTIVIDAD EVS 1: ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA
En esta actividad se estudia el alcance de la necesidad planteada por el cliente o usuario, o como consecuencia
de la realizacin de un PSI, realizando una descripcin general de la misma. Se determinan los objetivos, se inicia
el estudio de los requisitos y se identifican las unidades organizativas afectadas estableciendo su estructura.
Se analizan las posibles restricciones, tanto generales como especficas, que puedan condicionar el estudio y la
planificacin de las alternativas de solucin que se propongan. Si la justificacin econmica es obvia, el riesgo
tcnico bajo, se esperan pocos problemas legales y no existe ninguna alternativa razonable, no es necesario
profundizar en el estudio de viabilidad del sistema, analizando posibles alternativas y realizando una valoracin y
evaluacin de las mismas, sino que ste se orientar a la especificacin de requisitos, descripcin del nuevo
sistema y planificacin. Se detalla la composicin del equipo de trabajo necesario para este proceso y su
planificacin. Finalmente, con el fin de facilitar la implicacin activa de los usuarios en la definicin del sistema, se
identifican sus perfiles, dejando claras sus tareas y responsabilidades.
2.3.3. ACTIVIDAD EVS 2: ESTUDIO DE LA SITUACIN ACTUAL
La situacin actual es el estado en el que se encuentran los sistemas de informacin existentes en el momento en
el que se inicia su estudio. Teniendo en cuenta el objetivo del estudio de la situacin actual, se realiza una
valoracin de la informacin existente acerca de los sistemas de informacin afectados. En funcin de dicha
valoracin, se especifica el nivel de detalle con que se debe llevar a cabo el estudio. Si es necesario, se
constituye un equipo de trabajo especfico para su realizacin y se identifican los usuarios participantes en el
mismo.
Si se decide documentar la situacin actual, normalmente es conveniente dividir el sistema actual en

subsistemas. Si es posible se describir cada uno de los subsistemas, valorando qu informacin puede ser
relevante para la descripcin. Como resultado de esta actividad se genera un diagnstico, estimando la eficiencia
de los sistemas de informacin existentes e identificando los posibles problemas y las mejoras.
2.3.4. ACTIVIDAD EVS 3: DEFINICIN DE REQUISITOS DEL SISTEMA
Esta actividad incluye la determinacin de los requisitos generales, mediante una serie de sesiones de trabajo con
los usuarios participantes, que hay que planificar y realizar. Una vez finalizadas, se analiza la informacin
obtenida definiendo los requisitos y sus prioridades, que se aaden al catlogo de requisitos que servir para el
estudio y valoracin de las distintas alternativas de solucin que se propongan.
2.3.5. ACTIVIDAD EVS 4: ESTUDIO DE ALTERNATIVAS DE SOLUCIN
Este estudio se centra en proponer diversas alternativas que respondan satisfactoriamente a los requisitos
planteados, considerando tambin los resultados obtenidos en el Estudio de la Situacin Actual (EVS 2), en el
caso de que se haya realizado. Teniendo en cuenta el mbito y funcionalidad que debe cubrir el sistema, puede
ser conveniente realizar, previamente a la definicin de cada alternativa, una descomposicin del sistema en
subsistemas. En la descripcin de las distintas alternativas de solucin propuestas, se debe especificar si alguna
de ellas est basada, total o parcialmente, en un producto existente en el mercado. Si la alternativa incluye un
desarrollo a medida, se debe incorporar en la descripcin de la misma un modelo abstracto de datos y un modelo
de procesos, y en orientacin a objetos, un modelo de negocio y un modelo de dominio.
2.3.6. ACTIVIDAD EVS 5: VALORACIN DE LAS ALTERNATIVAS
Una vez descritas las alternativas se realiza una valoracin de las mismas, considerando el impacto en la
organizacin, tanto desde el punto de vista tecnolgico y organizativo como de operacin, y los posibles
beneficios que se esperan contrastados con los costes asociados. Se realiza tambin un anlisis de los riesgos,
decidiendo cmo enfocar el plan de accin para minimizar los mismos y cuantificando los recursos y plazos
precisos para planificar cada alternativa.
2.3.7. ACTIVIDAD EVS 6: SELECCIN DE LA SOLUCIN
Antes de finalizar el Estudio de Viabilidad del Sistema, se convoca al Comit de Direccin para la presentacin de
las distintas alternativas de solucin, resultantes de la actividad anterior. En dicha presentacin, se debaten las
ventajas de cada una de ellas, incorporando las modificaciones que se consideren oportunas, con el fin de
seleccionar la ms adecuada. Finalmente, se aprueba la solucin o se determina su inviabilidad.
2.4. ANLISIS DEL SISTEMA DE INFORMACIN
El objetivo de este proceso es la obtencin de una especificacin detallada del sistema de informacin que
satisfaga las necesidades de informacin de los usuarios y sirva de base para el posterior diseo del sistema. Al
ser MTRICA Versin 3 una metodologa que cubre tanto desarrollos estructurados como orientados a objetos,
las actividades de ambas aproximaciones estn integradas en una estructura comn.
En la primera actividad, Definicin del Sistema (ASI 1), se lleva a cabo la descripcin inicial del sistema de
informacin, a partir de los productos generados en el proceso Estudio de Viabilidad del Sistema (EVS). Se
delimita el alcance del sistema, se genera un catlogo de requisitos generales y se describe el sistema mediante
unos modelos iniciales de alto nivel. Tambin se identifican los usuarios que participan en el proceso de anlisis,
determinando sus perfiles, responsabilidades y dedicaciones necesarias. As mismo se elabora el plan de trabajo
a seguir.
La definicin de requisitos del nuevo sistema se realiza principalmente en la actividad Establecimiento de

Requisitos (ASI 2). El objetivo de esta actividad es elaborar un catlogo de requisitos detallado, que permita
describir con precisin el sistema de informacin, y que adems sirva de base para comprobar que es completa la
especificacin de los modelos obtenidos en las actividades Identificacin de Subsistemas de Anlisis (ASI 3),
Anlisis de Casos de Uso (ASI 4), Anlisis de Clases (ASI 5), Elaboracin del Modelo de Datos (ASI 6),
Elaboracin del Modelo de Procesos (ASI 7) y Definicin de Interfaces de Usuario (ASI 8).
Hay que hacer constar que estas actividades pueden provocar la actualizacin del catlogo, aunque no se refleja
como producto de salida en las tareas de dichas actividades, ya que el objetivo de las mismas no es crear el
catlogo sino definir modelos que soporten los requisitos.
Para la obtencin de requisitos en la actividad Establecimiento de Requisitos (ASI 2) se toman como punto de
partida el catlogo de requisitos y los modelos elaborados en la actividad Definicin del Sistema (ASI 1),
completndolos mediante sesiones de trabajo con los usuarios. Estas sesiones de trabajo tienen como objetivo
reunir la informacin necesaria para obtener la especificacin detallada del nuevo sistema. Las tcnicas que
ayudan a la recopilacin de esta informacin pueden variar en funcin de las caractersticas del proyecto y los
tipos de usuario a entrevistar. Entre ellas podemos citar las reuniones, entrevistas, Joint Application Design (JAD),
etc. Durante estas sesiones de trabajo se propone utilizar la especificacin de los casos de uso como ayuda y
gua en el establecimiento de requisitos. Esta tcnica facilita la comunicacin con los usuarios y en el anlisis
orientado a objetos constituye la base de la especificacin. A continuacin se identifican las facilidades que ha de
proporcionar el sistema, y las restricciones a que est sometido en cuanto a rendimiento, frecuencia de
tratamiento, seguridad y control de accesos, etc. Toda esta informacin se incorpora al catlogo de requisitos.
En la actividad Identificacin de Subsistemas de Anlisis (ASI 3), se estructura el sistema de informacin en

subsistemas de anlisis, para facilitar la especificacin de los distintos modelos y la traza de requisitos. En
paralelo, se generan los distintos modelos que sirven de base para el diseo. En el caso de anlisis estructurado,
se procede a la elaboracin y descripcin detallada del modelo de datos y de procesos, y en el caso de un
anlisis orientado a objetos, se elaboran el modelo de clases y el de interaccin de objetos, mediante el anlisis
de los casos de uso. Se especifican, asimismo, todas las interfaces entre el sistema y el usuario, tales como
formatos de pantallas, dilogos, formatos de informes y formularios de entrada.
En la actividad Anlisis de Consistencia y Especificacin de Requisitos (ASI 9), se realiza la verificacin y

validacin de los modelos, con el fin de asegurar que son:
Completos, puesto que cada modelo obtenido contiene toda la informacin necesaria recogida en el
catlogo de requisitos.
Consistentes, ya que cada modelo es coherente con el resto de los modelos.
Correctos, dado que cada modelo sigue unos criterios de calidad predeterminados en relacin a la tcnica
utilizada, calidad de diagramas, eleccin de nombres, normas de calidad, etc.).
En la actividad Especificacin del Plan de Pruebas (ASI 10), se establece el marco general del plan de pruebas,
inicindose su especificacin, que se completar en el proceso Diseo del Sistema de Informacin (DSI).
La participacin activa de los usuarios es una condicin imprescindible para el anlisis del sistema de
informacin, ya que dicha participacin constituye una garanta de que los requisitos identificados son
comprendidos e incorporados al sistema y, por tanto, de que ste ser aceptado. Para facilitar la colaboracin de
los usuarios, se pueden utilizar tcnicas interactivas, como diseo de dilogos y prototipos, que permiten al
usuario familiarizarse con el nuevo sistema y colaborar en la construccin y perfeccionamiento del mismo. En el
siguiente grfico FIG- 10 se muestra la relacin de actividades del proceso Anlisis del Sistema de Informacin,
tanto para desarrollos estructurados como para desarrollos orientados a objetos, distinguiendo las que se pueden
realizar en paralelo de aquellas que han de realizarse secuencialmente.
FIG-10
2.4.2. ACTIVIDAD ASI 1: DEFINICIN DEL SISTEMA
Esta actividad tiene como objetivo efectuar una descripcin del sistema, delimitando su alcance, estableciendo las
interfaces con otros sistemas e identificando a los usuarios representativos. Las tareas de esta actividad se
pueden haber desarrollado ya en parte en el proceso de Estudio de Viabilidad del Sistema (EVS), de modo que se
parte de los productos obtenidos en dicho proceso para proceder a su adecuacin como punto de partida para
definir el sistema de informacin.
2.4.3. ACTIVIDAD ASI 2: ESTABLECIMIENTO DE REQUISITOS
En esta actividad se lleva a cabo la definicin, anlisis y validacin de los requisitos a partir de la informacin
facilitada por el usuario, completndose el catlogo de requisitos obtenido en la actividad Definicin del Sistema
(ASI 1). El objetivo de esta actividad es obtener un catlogo detallado de los requisitos, a partir del cual se pueda
comprobar que los productos generados en las actividades de modelizacin se ajustan a los requisitos de usuario.
Esta actividad se descompone en un conjunto de tareas que, si bien tienen un orden, exige continuas
realimentaciones y solapamientos, entre s y con otras tareas realizadas en paralelo. No es necesaria la
finalizacin de una tarea para el comienzo de la siguiente. Lo que se tiene en un momento determinado es un
catlogo de requisitos especificado en funcin de la progresin del proceso de anlisis.
Se propone como tcnica de obtencin de requisitos la especificacin de los casos de uso de la orientacin a
objetos, siendo opcional en el caso estructurado. Dicha tcnica ofrece un diagrama simple y una gua de
especificacin en las sesiones de trabajo con el usuario.
2.4.4. ACTIVIDAD ASI 3: IDENTIFICACIN DE SUBSISTEMAS DE ANLISIS
El objetivo de esta actividad, comn tanto para anlisis estructurado como para anlisis orientado a objetos, es
facilitar el anlisis del sistema de informacin llevando a cabo la descomposicin del sistema en subsistemas. Se
realiza en paralelo con el resto de las actividades de generacin de modelos del anlisis. Por tanto, se asume la
necesidad de una realimentacin y ajuste continuo con respecto a la definicin de los subsistemas, sus
dependencias y sus interfaces.
2.4.5. ACTIVIDAD ASI 4: ANLISIS DE LOS CASOS DE USO
El objetivo de esta actividad, que slo se realiza en el caso de Anlisis Orientado a Objetos, es identificar las
clases cuyos objetos son necesarios para realizar un caso de uso y describir su comportamiento mediante la
interaccin dichos objetos. Esta actividad se lleva a cabo para cada uno de los casos de uso contenidos en un
subsistema de los definidos en la actividad Identificacin de Subsistemas de Anlisis (ASI 3).
Las tareas de esta actividad no se realizan de forma secuencial sino en paralelo, con continuas realimentaciones
entre ellas y con las realizadas en las actividades Establecimiento de Requisitos (ASI 2), Identificacin de
Subsistemas de Anlisis (ASI 3), Anlisis de Clases (ASI 5) y Definicin de Interfaces de Usuario (ASI 8).
2.4.6. ACTIVIDAD ASI 5: ANLISIS DE CLASES
El objetivo de esta actividad que slo se realiza en el caso de Anlisis Orientado a Objetos es describir cada
una de las clases que ha surgido, identificando las responsabilidades que tienen asociadas, sus atributos, y las
relaciones entre ellas. Para esto, se debe tener en cuenta la normativa establecida en la tarea Especificacin de
Estndares y Normas (ASI 1.3), de forma que el modelo de clases cumpla estos criterios, con el fin de evitar
posibles inconsistencias en el diseo. Teniendo en cuenta las clases identificadas en la actividad Anlisis de los
Casos de Uso (ASI 4), se elabora el modelo de clases para cada subsistema. A medida que avanza el anlisis,
dicho modelo se va completando con las clases que vayan apareciendo, tanto del estudio de los casos de uso,
como de la interfaz de usuario necesaria para el sistema de informacin.
2.4.7. ACTIVIDAD ASI 6: ELABORACIN DEL MODELO DE DATOS
El objetivo de esta actividad que se lleva a cabo nicamente en el caso de Anlisis Estructurado es identificar
las necesidades de informacin de cada uno de los procesos que conforman el sistema de informacin, con el fin
de obtener un modelo de datos que contemple todas las entidades, relaciones, atributos y reglas de negocio
necesarias para dar respuesta a dichas necesidades.
El modelo de datos se elabora siguiendo un enfoque descendente (top-down). A partir del modelo conceptual de
datos, obtenido en la tarea Determinacin del Alcance del Sistema (ASI 1.1), se incorporan a dicho modelo todas
las entidades que vayan apareciendo, como resultado de las funcionalidades que se deban cubrir y de las
necesidades de informacin del usuario. Es necesario tener en cuenta el catlogo de requisitos y el modelo de
procesos, productos que se estn generando en paralelo en las actividades Establecimiento de Requisitos (ASI
2), Identificacin de Subsistemas de Anlisis (ASI 3) y Elaboracin del Modelo de Procesos (ASI 7). Una vez
construido el modelo conceptual y definidas sus entidades, se resuelven las relaciones complejas y se completa
la informacin de entidades, relaciones, atributos y ocurrencias de las entidades, generando el modelo lgico de
datos. Como ltima tarea en la definicin del modelo, se asegura la normalizacin hasta la tercera forma normal
para obtener el modelo lgico de datos normalizado. Finalmente, si procede, se describen las necesidades de
migracin y carga inicial de los datos.
Esta actividad se realiza en paralelo, y con continuas realimentaciones, con otras tareas realizadas en las
actividades Establecimiento de Requisitos (ASI 2), Identificacin de Subsistemas de Anlisis (ASI 3), Elaboracin
del Modelo de Procesos (ASI 7) y Definicin de Interfaces de Usuario (ASI 8).
2.4.8. ACTIVIDAD ASI 7: ELABORACIN DEL MODELO DE PROCESOS
El objetivo de esta actividad, que se lleva a cabo nicamente en el caso de Anlisis Estructurado, es analizar
las necesidades del usuario para establecer el conjunto de procesos que conforma el sistema de informacin.
Para ello, se realiza una descomposicin de dichos procesos siguiendo un enfoque descendente (top-down), en
varios niveles de abstraccin, donde cada nivel proporciona una visin ms detallada del proceso definido en el
nivel anterior. Con el fin de facilitar el desarrollo posterior, se debe llegar a un nivel de descomposicin en el que
los procesos obtenidos sean claros y sencillos, es decir, buscar un punto de equilibrio en el que dichos procesos
tengan significado por s mismos dentro del sistema global y a su vez la mxima independencia y simplicidad.
Esta actividad se lleva a cabo para cada uno de los subsistemas identificados en la actividad Identificacin de
Subsistemas de Anlisis (ASI 3). Las tareas de esta actividad se realizan en paralelo y con continuas
realimentaciones con otras tareas ejecutadas en las actividades Establecimiento de Requisitos (ASI2),
Elaboracin del Modelo de Datos (ASI 6) y Definicin de Interfaces de Usuario (ASI 8).
2.4.9. ACTIVIDAD ASI 8: DEFINICIN DE INTERFACES DE USUARIO
En esta actividad se especifican las interfaces entre el sistema y el usuario: formatos de pantallas, dilogos, e
informes, principalmente. El objetivo es realizar un anlisis de los procesos del sistema de informacin en los que
se requiere una interaccin del usuario, con el fin de crear una interfaz que satisfaga todos los requisitos
establecidos, teniendo en cuenta los diferentes perfiles a quines va dirigido. Al comienzo de este anlisis es
necesario seleccionar el entorno en el que es operativa la interfaz, considerando estndares internacionales y de
la instalacin, y establecer las directrices aplicables en los procesos de diseo y construccin. El propsito es
construir una interfaz de usuario acorde a sus necesidades, flexible, coherente, eficiente y sencilla de utilizar,
teniendo en cuenta la facilidad de cambio a otras plataformas, si fuera necesario. Se identifican los distintos
grupos de usuarios de acuerdo con las funciones que realizan, conocimientos y habilidades que poseen, y
caractersticas del entorno en el que trabajan. La identificacin de los diferentes perfiles permite conocer mejor las
necesidades y particularidades de cada uno de ellos.
Asimismo, se determina la naturaleza de los procesos que se llevan a cabo (en lotes o en lnea). Para cada
proceso en lnea se especifica qu tipo de informacin requiere el usuario para completar su ejecucin realizando,
para ello, una descomposicin en dilogos que refleje la secuencia de la interfaz de pantalla tipo carcter o
pantalla grfica. Finalmente, se define el formato y contenido de cada una de las interfaces de pantalla
especificando su comportamiento dinmico. Se propone un flujo de trabajo muy similar para desarrollos
estructurados y orientados a objetos, coincidiendo en la mayora de las tareas, si bien es cierto que en orientacin
a objetos, al identificar y describir cada escenario en la especificacin de los casos de uso, se hace un avance
muy significativo en la toma de datos para la posterior definicin de la interfaz de usuario. Como resultado de esta
actividad se genera la especificacin de interfaz de usuario, como producto que engloba los siguientes elementos:
Principios generales de la interfaz.

Catlogo de perfiles de usuario.
Descomposicin funcional en dilogos.
Catlogo de controles y elementos de diseo de interfaz de pantalla.
Formatos individuales de interfaz de pantalla.
Modelo de navegacin de interfaz de pantalla.
Formatos de impresin.
Prototipo de interfaz interactiva.
Prototipo de interfaz de impresin.
2.4.10. ACTIVIDAD ASI 9: ANLISIS DE CONSISTENCIA Y ESPECIFICACIN DE REQUISITOS
El objetivo de esta actividad es garantizar la calidad de los distintos modelos generados en el proceso de Anlisis
del Sistema de Informacin, y asegurar que los usuarios y los Analistas tienen el mismo concepto del sistema.
Para cumplir dicho objetivo, se llevan a cabo las siguientes acciones:
Verificacin de la calidad tcnica de cada modelo.

Aseguramiento de la coherencia entre los distintos modelos.
Validacin del cumplimiento de los requisitos.
Esta actividad requiere una herramienta de apoyo para realizar el anlisis de consistencia. Tambin se elabora en
esta actividad la Especificacin de Requisitos Software (ERS), como producto para la aprobacin formal, por
parte del usuario, de las especificaciones del sistema. La Especificacin de Requisitos Software se convierte en la
lnea base para los procesos posteriores del desarrollo del software, de modo que cualquier peticin de cambio en
los requisitos que pueda surgir posteriormente, debe ser evaluada y aprobada.
2.4.11. ACTIVIDAD ASI 10: ESPECIFICACIN DEL PLAN DE PRUEBAS
En esta actividad se inicia la definicin del plan de pruebas, el cual sirve como gua para la realizacin de las
pruebas, y permite verificar que el sistema de informacin cumple las necesidades establecidas por el usuario,
con las debidas garantas de calidad. El plan de pruebas es un producto formal que define los objetivos de la
prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para elaborar
una planificacin paso a paso de las actividades de prueba. El plan se inicia en el proceso Anlisis del Sistema de
Informacin (ASI), definiendo el marco general, y estableciendo los requisitos de prueba de aceptacin,
relacionados directamente con la especificacin de requisitos.
Dicho plan se va completando y detallando a medida que se avanza en los restantes procesos del ciclo de vida
del software, Diseo del Sistema de Informacin (DSI), Construccin del Sistema de Informacin (CSI) e
Implantacin y Aceptacin del Sistema (IAS). Se plantean los siguientes niveles de prueba:
Pruebas unitarias.
Pruebas de integracin.
Pruebas del sistema.
Pruebas de implantacin.
Pruebas de aceptacin.
En esta actividad tambin se avanza en la definicin de las pruebas de aceptacin del sistema. Con la
informacin disponible, es posible establecer los criterios de aceptacin de las pruebas incluidas en dicho nivel, al
poseer la informacin sobre los requisitos que debe cumplir el sistema, recogidos en el catlogo de requisitos.
2.4.12. ACTIVIDAD ASI 11: APROBACIN DEL ANLISIS DEL SISTEMA DE INFORMACIN
2.5. DISEO DEL SISTEMA DE INFORMACIN
El objetivo del proceso de Diseo del Sistema de Informacin (DSI) es la definicin de la arquitectura del sistema
y del entorno tecnolgico que le va a dar soporte, junto con la especificacin detallada de los componentes del
sistema de informacin. A partir de dicha informacin, se generan todas las especificaciones de construccin
relativas al propio sistema, as como la descripcin tcnica del plan de pruebas, la definicin de los requisitos de
implantacin y el diseo de los procedimientos de migracin y carga inicial, stos ltimos cuando proceda.
Al ser MTRICA Versin 3 una metodologa que cubre tanto desarrollos estructurados como orientados a objetos,
las actividades de ambas aproximaciones estn integradas en una estructura comn. Las actividades de este
proceso se agrupan en dos grandes bloques.
En un primer bloque de actividades, que se llevan a cabo en paralelo, se obtiene el diseo de detalle del
sistema de informacin. La realizacin de estas actividades exige una continua realimentacin. En
general, el orden real de ejecucin de las mismas depende de las particularidades del sistema de
informacin y, por lo tanto, de generacin de sus productos.
En la actividad Definicin de la Arquitectura del Sistema (DSI 1), se establece el particionamiento fsico
del sistema de informacin, as como su organizacin en subsistemas de diseo, la especificacin del
entorno tecnolgico, y sus requisitos de operacin, administracin, seguridad y control de acceso. Se
completan los catlogos de requisitos y normas, en funcin de la definicin del entorno tecnolgico, con
aquellos aspectos relativos al diseo y construccin que sea necesario contemplar. Asimismo, se crea un
catlogo de excepciones del sistema, en el que se registran las situaciones de funcionamiento secundario
o anmalo que se estime oportuno considerar y, por lo tanto, disear y probar. Este catlogo de
excepciones se utiliza como referencia en la especificacin tcnica de las pruebas del sistema.
El particionamiento fsico del sistema de informacin permite organizar un diseo que contemple un
sistema de informacin distribuido, como por ejemplo la arquitectura cliente/servidor, siendo aplicable a
arquitecturas multinivel en general. Independientemente de la infraestructura tecnolgica, dicho
particionamiento representa los distintos niveles funcionales o fsicos del sistema de informacin. La
relacin entre los elementos del diseo y particionamiento fsico, y a su vez, entre el particionamiento
fsico y el entorno tecnolgico, permite una especificacin de la distribucin de los elementos del sistema
de informacin y, al mismo tiempo, un diseo orientado a la movilidad a otras plataformas o la reubicacin
de subsistemas.
El sistema de informacin se estructura en subsistemas de diseo. stos a su vez se clasifican como de

soporte o especficos, al responder a propsitos diferentes.
Los subsistemas de soporte contienen los elementos o servicios comunes al sistema y a la

instalacin, y generalmente estn originados por la interaccin con la infraestructura tcnica o la
reutilizacin de otros sistemas, con un nivel de complejidad tcnica mayor.
Los subsistemas especficos contienen los elementos propios del sistema de informacin,
generalmente con una continuidad de los subsistemas definidos en el proceso de Anlisis del
Sistema de Informacin (ASI).
Tambin se especifica en detalle el entorno tecnolgico del sistema de informacin, junto con su
planificacin de capacidades (capacity planning), y sus requisitos de operacin, administracin, seguridad
y control de acceso.
El diseo detallado del sistema de informacin, siguiendo un enfoque estructurado, comprende un

conjunto de actividades que se llevan a cabo en paralelo a la Definicin de la Arquitectura del Sistema
(DSI 1). El alcance de cada una de estas actividades se resume a continuacin:
Diseo de la Arquitectura de Soporte (DSI 2), que incluye el diseo detallado de los subsistemas de
soporte, el establecimiento de las normas y requisitos propios del diseo y construccin, as como la
identificacin y definicin de los mecanismos genricos de diseo y construccin.
Diseo de la Arquitectura de Mdulos del Sistema (DSI 5), dnde se realiza el diseo de detalle de
los subsistemas especficos del sistema de informacin y la revisin de la interfaz de usuario.
Diseo Fsico de Datos (DSI 6), que incluye el diseo y optimizacin de las estructuras de datos del
sistema, as como su localizacin en los nodos de la arquitectura propuesta.
En el caso de Diseo Orientado a Objetos, conviene sealar que el diseo de la persistencia de los
objetos se lleva a cabo sobre bases de datos relacionales, y que el diseo detallado del sistema de
informacin se realiza en paralelo con la actividad de Diseo de la Arquitectura de Soporte (DSI 2), y se
corresponde con las siguientes actividades:
Diseo de Casos de Uso Reales (DSI 3), con el diseo detallado del comportamiento del sistema de
informacin para los casos de uso, el diseo de la interfaz de usuario y la validacin de la divisin en
subsistemas.
Diseo de Clases (DSI 4), con el diseo detallado de cada una de las clases que forman parte del
sistema, sus atributos, operaciones, relaciones y mtodos, y la estructura jerrquica del mismo. En el
caso de que sea necesario, se realiza la definicin de un plan de migracin y carga inicial de datos.
Una vez que se tiene el modelo de clases, se comienza el diseo fsico en la actividad Diseo Fsico de
Datos (DSI 6), comn con el enfoque estructurado.
Una vez finalizado el diseo de detalle, se realiza su revisin y validacin en la actividad Verificacin y
Aceptacin de la Arquitectura del Sistema (DSI 7), con el objeto de analizar la consistencia entre los
distintos modelos y conseguir la aceptacin del diseo por parte de los responsables de las reas de
Explotacin y Sistemas.
El segundo bloque de actividades complementa el diseo del sistema de informacin. En l se generan

todas las especificaciones necesarias para la construccin del sistema de informacin:
Generacin de Especificaciones de Construccin (DSI 8), fijando las directrices para la construccin
de los componentes del sistema, as como de las estructuras de datos.
Diseo de la Migracin y Carga Inicial de Datos (DSI 9), en el que se definen los procedimientos de
migracin y sus componentes asociados, con las especificaciones de construccin oportunas.
Especificacin Tcnica del Plan de Pruebas (DSI 10), que incluye la definicin y revisin del plan de
pruebas, y el diseo de las verificaciones de los niveles de prueba establecidos. El catlogo de
excepciones permite, de una forma muy gil, establecer un conjunto de verificaciones relacionadas
con el propio diseo o con la arquitectura del sistema.
Establecimiento de Requisitos de Implantacin (DSI 11), que hace posible concretar las exigencias
relacionados con la propia implantacin del sistema, tales como formacin de usuarios finales,
infraestructura, etc.
Finalmente, en la actividad de Presentacin y Aprobacin del Diseo del Sistema de Informacin (DSI
12), se realiza una presentacin formal y aprobacin de los distintos productos del diseo.
En el siguiente grfico se muestra la relacin de actividades del proceso Diseo del Sistema de
Informacin (DSI), tanto para Desarrollos Estructurados como para Desarrollos Orientados a Objetos FIG-
11.
FIG-11
2.5.2. ACTIVIDAD DSI 1: DEFINICIN DE LA ARQUITECTURA DEL SISTEMA
En esta actividad se define la arquitectura general del sistema de informacin, especificando las distintas
particiones fsicas del mismo, la descomposicin lgica en subsistemas de diseo y la ubicacin de cada
subsistema en cada particin, as como la especificacin detallada de la infraestructura tecnolgica necesaria
para dar soporte al sistema de informacin.
El particionamiento fsico del sistema de informacin se especifica identificando los nodos y las comunicaciones
entre los mismos, con cierta independencia de la infraestructura tecnolgica que da soporte a cada nodo.
Con el fin de organizar y facilitar el diseo, se realiza una divisin del sistema de informacin en subsistemas de
diseo, como partes lgicas coherentes y con interfaces claramente definidas. Se establece una distincin entre
subsistemas especficos del sistema de informacin (en adelante, subsistemas especficos) y subsistemas de
soporte, con la finalidad de independizar, en la medida de lo posible, las funcionalidades a cubrir por el sistema de
informacin de la infraestructura que le da soporte.
En la mayora de los casos, los subsistemas especficos provienen directamente de las especificaciones de
anlisis y de los subsistemas de anlisis, mientras que los subsistemas de soporte provienen de la necesidad de
interaccin del sistema de informacin con la infraestructura y con el resto de los sistemas, as como de la
reutilizacin de mdulos o subsistemas ya existentes en la instalacin.
Debido a que la definicin de los subsistemas de soporte puede exigir la participacin de distintos perfiles
tcnicos, se propone el diseo de ambos tipos de subsistemas en actividades distintas, aunque en paralelo.
Una vez identificados y definidos los distintos subsistemas de diseo, se determina su ubicacin ptima de
acuerdo a la arquitectura propuesta. La asignacin de dichos subsistemas a cada nodo permite disponer, en
funcin de la carga de proceso y comunicacin existente entre los nodos, de la informacin necesaria para
realizar una estimacin de las necesidades de infraestructura tecnolgica que da soporte al sistema de
informacin. Este factor es especialmente crtico en arquitecturas multinivel o cliente/servidor, donde las
comunicaciones son determinantes en el rendimiento final del sistema. Se propone crear un catlogo de
excepciones en el que se especifiquen las situaciones anmalas o secundarias en el funcionamiento y ejecucin
del sistema de informacin, y que se ir completando a medida que se avance en el diseo detallado de los
subsistemas.
En esta actividad tambin se establecen los requisitos, normas y estndares originados como consecuencia de la
adopcin de una determinada solucin de arquitectura o infraestructura, que sern aplicables tanto en este
proceso como en la Construccin del Sistema de Informacin (CSI). Se detallan a su vez, de acuerdo a las
particularidades de la arquitectura del sistema propuesta, los requisitos de operacin, seguridad y control,
especificando los procedimientos necesarios para su cumplimiento.
Como resultado de esta actividad, se actualizan los catlogos de requisitos y normas, y se generan los siguientes
productos:
Diseo de la Arquitectura del Sistema, como producto que engloba el particionamiento fsico del sistema
de informacin y la descripcin de subsistemas de diseo.
Entorno Tecnolgico del Sistema, que a su vez comprende la especificacin del entorno tecnolgico, las
restricciones tcnicas y la planificacin de capacidades.
Catlogo de Excepciones.
Procedimientos de Operacin y Administracin del Sistema.
Procedimientos de Seguridad y Control de Acceso.
2.5.3. ACTIVIDAD DSI 2: DISEO DE LA ARQUITECTURA DE SOPORTE
En esta actividad se lleva a cabo la especificacin de la arquitectura de soporte, que comprende el diseo de los
subsistemas de soporte identificados en la actividad de Definicin de la Arquitectura del Sistema (DSI 1), y la
determinacin de los mecanismos genricos de diseo. Estos ltimos sirven de gua en la utilizacin de diferentes
estilos de diseo, tanto en el mbito global del sistema de informacin, como en el diseo de detalle.
El diseo de los subsistemas de soporte, conceptualmente, es similar al diseo de los subsistemas especficos,
aunque debe cumplir con unos objetivos claros de reutilizacin. De esta manera, se consigue simplificar y
abstraer el diseo de los subsistemas especficos de la complejidad del entorno tecnolgico, dotando al sistema
de informacin de una mayor independencia de la infraestructura que le da soporte. Con este fin, se aconseja la
consulta de los datos de otros proyectos existentes, disponible en el Histrico de Proyectos. Si esto no fuera
suficiente, se puede contar en esta actividad con la participacin de perfiles tcnicos, con una visin global de la
instalacin.
Esta actividad se realiza en paralelo al diseo detallado, debido a que existe una constante realimentacin, tanto
en la especificacin de los subsistemas con sus interfaces y dependencias, como en la aplicacin de esqueletos o
patrones en el diseo.
Los productos resultantes de esta actividad son:
Diseo Detallado de los Subsistemas de Soporte.

Mecanismos Genricos de Diseo y Construccin.
2.5.4. ACTIVIDAD DSI 3: DISEO DE CASOS DE USO REALES
Esta actividad, que se realiza solo en el caso de Diseo Orientado a Objetos, tiene como propsito especificar
el comportamiento del sistema de informacin para un caso de uso, mediante objetos o subsistemas de diseo
que interactan, y determinar las operaciones de las clases e interfaces de los distintos subsistemas de diseo.
Para ello, una vez identificadas las clases participantes dentro de un caso de uso, es necesario completar los
escenarios que se recogen del anlisis, incluyendo las clases de diseo que correspondan y teniendo en cuenta
las restricciones del entorno tecnolgico, esto es, detalles relacionados con la implementacin del sistema. Es
necesario analizar los comportamientos de excepcin para dichos escenarios. Algunos de ellos pueden haber
sido identificados en el proceso de anlisis, aunque no se resuelven hasta este momento. Dichas excepciones se
aadirn al catlogo de excepciones para facilitar las pruebas.
Algunos de los escenarios detallados requerirn una nueva interfaz de usuario. Por este motivo es necesario
disear el formato de cada una de las pantallas o impresos identificados.
Es importante validar que los subsistemas definidos en la tarea Identificacin de Subsistemas de Diseo (DSI 1.5)
tienen la mnima interfaz con otros subsistemas. Por este motivo, se elaboran los escenarios al nivel de
subsistemas y, de esta forma, se delimitan las interfaces necesarias para cada uno de ellos, teniendo en cuenta
toda la funcionalidad del sistema que recogen los casos de uso. Adems, durante esta actividad pueden surgir
requisitos de implementacin, que se recogen en el catlogo de requisitos.
Las tareas de esta actividad se realizan en paralelo con las de Diseo de Clases (DSI 4).
2.5.5. ACTIVIDAD DSI 4: DISEO DE CLASES
El propsito de esta actividad, que se realiza slo en el caso de Diseo Orientado a Objetos, es transformar el
modelo de clases lgico, que proviene del anlisis, en un modelo de clases de diseo. Dicho modelo recoge la
especificacin detallada de cada una de las clases, es decir, sus atributos, operaciones, mtodos, y el diseo
preciso de las relaciones establecidas entre ellas, bien sean de agregacin, asociacin o jerarqua. Para llevar a
cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno tecnolgico y el entorno de
desarrollo elegido para la implementacin.
Se identifican las clases de diseo, que denominamos clases adicionales, en funcin del estudio de los
escenarios de los casos de uso, que se est realizando en paralelo en la actividad Diseo de Casos de Uso
Reales (DSI 3), y aplicando los mecanismos genricos de diseo que se consideren convenientes por el tipo de
especificaciones tecnolgicas y de desarrollo. Entre ellas se encuentran clases abstractas, que integran
caractersticas comunes con el objetivo de especializarlas en clases derivadas. Se disean las clases de interfaz
de usuario, que provienen del anlisis. Como consecuencia del estudio de los escenarios secundarios que se est
realizando, pueden aparecer nuevas clases de interfaz.
Tambin hay que considerar que, por el diseo de las asociaciones y agregaciones, pueden aparecer nuevas
clases, o desaparecer incluyendo sus atributos y mtodos en otras, si se considera conveniente por temas de
optimizacin.
La jerarqua entre las clases se va estableciendo a lo largo de esta actividad, a medida que se van identificando
comportamientos comunes en las clases, aunque haya una tarea propia de diseo de la jerarqua. Otro de los
objetivos del diseo de las clases es identificar para cada clase, los atributos, las operaciones que cubren las
responsabilidades que se identificaron en el anlisis, y la especificacin de los mtodos que implementan esas
operaciones, analizando los escenarios del Diseo de Casos de Uso Reales (DSI 3). Se determina la visibilidad
de los atributos y operaciones de cada clase, con respecto a las otras clases del modelo.
Una vez que se ha elaborado el modelo de clases, se define la estructura fsica de los datos correspondiente a
ese modelo, en la actividad Diseo Fsico de Datos (DSI 6).
Adems, en los casos en que sea necesaria una migracin de datos de otros sistemas o una carga inicial de
informacin, se realizar su especificacin a partir del modelo de clases y las estructuras de datos de los sistemas
origen.
Como resultado de todo lo anterior se actualiza el modelo de clases del anlisis, una vez recogidas las decisiones
de diseo.
2.5.6. ACTIVIDAD DSI 5: DISEO DE LA ARQUITECTURA DE MDULOS DEL SISTEMA
El objetivo de esta actividad, que slo se realiza en el caso de Diseo Estructurado, es definir los mdulos del
sistema de informacin, y la manera en que van a interactuar unos con otros, intentando que cada mdulo trate
total o parcialmente un proceso especfico y tenga una interfaz sencilla.
Para cada uno de los subsistemas especficos, identificados en la tarea Identificacin de los Subsistemas de
Diseo (DSI 1.5), se disea la estructura modular de los procesos que lo integran, tomando como punto de
partida los modelos obtenidos en la tarea Validacin de los Modelos (ASI 9.3) del proceso de Anlisis del Sistema
de Informacin (ASI) y el catlogo de requisitos. Dicha estructura se ir completando con los mdulos que vayan
apareciendo como consecuencia del diseo de la interfaz de usuario, as como de la optimizacin del diseo
fsico de datos.
Durante el diseo de los mdulos, se pueden identificar caractersticas o comportamientos comunes relacionados
con accesos a las bases de datos o ficheros, lgica de tratamiento, llamadas a otros mdulos, gestin de errores,
etc. que determinen la necesidad de realizar su implementacin como subsistemas de soporte.
Adems, se analizan los comportamientos de excepcin asociados a los diferentes mdulos y a las interfaces
entre los mismos, intentando independizar en la medida de lo posible aqullos que presenten un tratamiento
comn. Dichas excepciones se incorporan al catlogo de excepciones.
En esta actividad, se consideran los estndares y normas establecidas para el diseo, aplicando, cuando
proceda, los mecanismos genricos de diseo identificados en la tarea Identificacin de Mecanismos Genricos
de Diseo (DSI 2.2).
Las tareas de esta actividad no se realizan de forma secuencial, sino en paralelo, con continuas realimentaciones
entre ellas y con las realizadas en las actividades Definicin de la Arquitectura del Sistema (DSI 1), Diseo de la
Arquitectura de Soporte (DSI 2) y Diseo Fsico de Datos (DSI 6).
2.5.7. ACTIVIDAD DSI 6: DISEO FSICO DE DATOS
En esta actividad se define la estructura fsica de datos que utilizar el sistema, a partir del modelo lgico de
datos normalizado o modelo de clases, de manera que teniendo presentes las caractersticas especficas del
sistema de gestin de datos concreto a utilizar, los requisitos establecidos para el sistema de informacin, y las
particularidades del entorno tecnolgico, se consiga una mayor eficiencia en el tratamiento de los datos.
Tambin se analizan los caminos de acceso a los datos utilizados por cada mdulo/clase del sistema en
consultas y actualizaciones, con el fin de mejorar los tiempos de respuesta y optimizar los recursos de mquina.
Las tareas de esta actividad se realizan de forma iterativa y en paralelo con las realizadas en las actividades
Definicin de la Arquitectura del Sistema (DSI 1), dnde se especifican los detalles de arquitectura e
infraestructura y la planificacin de capacidades, Diseo de la Arquitectura de Soporte (DSI 2), dnde se
determinan y disean los servicios comunes que pueden estar relacionados con la gestin de datos (acceso a
bases de datos, ficheros, reas temporales, sincronizacin de bases de datos, etc.), Diseo de Casos de Uso
Reales y de Clases (DSI 3 y 4), para desarrollo orientado a objetos, y Diseo de la Arquitectura de Mdulos del
Sistema (DSI 5), para desarrollo estructurado, dnde se especifica la lgica de tratamiento y las interfaces
utilizadas.
En el caso de diseo orientado a objetos, esta actividad tambin es necesaria. La obtencin del modelo fsico de
datos se realiza aplicando una serie de reglas de transformacin a cada elemento del modelo de clases que se
est generando en la actividad Diseo de Clases (DSI 4).
Asimismo, en esta actividad hay que considerar los estndares y normas establecidos para el diseo aplicando,
cuando proceda, los mecanismos genricos de diseo identificados en la tarea Identificacin de Mecanismos
Genricos de Diseo (DSI 2.2).
2.5.8. ACTIVIDAD DSI 7: VERIFICACIN Y ACEPTACIN DE LA ARQUITECTURA DEL SISTEMA
El objetivo de esta actividad es garantizar la calidad de las especificaciones del diseo del sistema de informacin
y la viabilidad del mismo, como paso previo a la generacin de las especificaciones de construccin.
Para cumplir dicho objetivo, se llevan a cabo las siguientes acciones:
Verificacin de la calidad tcnica de cada modelo o especificacin

Aseguramiento de la coherencia entre los distintos modelos
Aceptacin del diseo de la arquitectura por parte de Explotacin y Sistemas.
Esta actividad es compleja, por lo que es aconsejable utilizar herramientas de apoyo para la realizacin de sus
tareas.
2.5.9. ACTIVIDAD DSI 8: GENERACIN DE ESPECIFICACIONES DE CONSTRUCCIN
En esta actividad se generan las especificaciones para la construccin del sistema de informacin, a partir del
diseo detallado.
Estas especificaciones definen la construccin del sistema de informacin a partir de las unidades bsicas de
construccin (en adelante, componentes), entendiendo como tales unidades independientes y coherentes de
construccin y ejecucin, que se corresponden con un empaquetamiento fsico de los elementos del diseo de
detalle, como pueden ser mdulos, clases o especificaciones de interfaz.
La divisin del sistema de informacin en subsistemas de diseo proporciona, por continuidad, una primera
divisin en subsistemas de construccin, definiendo para cada uno de ellos los componentes que lo integran. Si
se considera necesario, un subsistema de diseo se podr dividir a su vez en sucesivos niveles para mayor
claridad de las especificaciones de construccin.
Las dependencias entre subsistemas de diseo proporcionan informacin para establecer las dependencias entre
los subsistemas de construccin y, por lo tanto, definir el orden o secuencia que se debe seguir en la construccin
y en la realizacin de las pruebas.
Tambin se generan las especificaciones necesarias para la creacin de las estructuras de datos en los gestores
de bases de datos o sistemas de ficheros.
El producto resultante de esta actividad es el conjunto de las especificaciones de construccin del sistema de
informacin, que comprende:
Especificacin del entorno de construccin.

Descripcin de subsistemas de construccin y dependencias.
Descripcin de componentes.
Plan de integracin del sistema de informacin.
Especificacin detallada de componentes.
Especificacin de la estructura fsica de datos.
2.5.10. ACTIVIDAD DSI 9: DISEO DE LA MIGRACIN Y CARGA INICIAL DE DATOS
Esta actividad slo se lleva a cabo cuando es necesaria una carga inicial de informacin, o una migracin de
datos de otros sistemas, cuyo alcance y estrategia a seguir se habr establecido previamente.
Para ello, se toma como referencia el plan de migracin y carga inicial de datos, que recoge las estructuras fsicas
de datos del sistema o sistemas origen implicadas en la conversin, la prioridad en las cargas y secuencia a
seguir, las necesidades previas de depuracin de la informacin, as como los requisitos necesarios para
garantizar la correcta implementacin de los procedimientos de migracin sin comprometer el funcionamiento de
los sistemas actuales.
A partir de dicho plan, y de acuerdo a la estructura fsica de los datos del nuevo sistema, obtenida en la actividad
Diseo Fsico de Datos (DSI 6), y a las caractersticas de la arquitectura y del entorno tecnolgico propuesto en la
actividad Definicin de la Arquitectura del Sistema (DSI 1), se procede a definir y disear en detalle los
procedimientos y procesos necesarios para realizar la migracin.
Se completa el plan de pruebas especfico establecido en el plan de migracin y carga inicial, detallando las
pruebas a realizar, los criterios de aceptacin o rechazo de la prueba y los responsables de la organizacin,
realizacin y evaluacin de resultados.
Asimismo, se determinan las necesidades adicionales de infraestructura, tanto para la implementacin de los
procesos como para la realizacin de las pruebas.
Como resultado de esta actividad, se actualiza el plan de migracin y carga inicial de datos con la informacin
siguiente:
Especificacin del entorno de migracin.

Definicin de procedimientos de migracin.
Diseo detallado de mdulos.
Especificacin tcnica de las pruebas.
Planificacin de la migracin y carga inicial.
Es importante considerar que una carga inicial de informacin no tiene el mismo alcance y complejidad que una
migracin de datos, de modo que las tareas de esta actividad se deben llevar a cabo en mayor o menor medida
en funcin de las caractersticas de los datos a cargar.
2.5.11. ACTIVIDAD DSI 10: ESPECIFICACIN TCNICA DEL PLAN DE PRUEBAS
En esta actividad se realiza la especificacin de detalle del plan de pruebas del sistema de informacin para cada
uno de los niveles de prueba establecidos en el proceso Anlisis del Sistema de Informacin:
Pruebas unitarias.
Pruebas de integracin.
Pruebas del sistema.
Pruebas de implantacin.
Pruebas de aceptacin.
Para ello se toma como referencia el plan de pruebas, que recoge los objetivos de la prueba de un sistema,
establece y coordina una estrategia de trabajo, y provee del marco adecuado para planificar paso a paso las
actividades de prueba. Tambin puede ser una referencia el plan de integracin del sistema de informacin
propuesto, opcionalmente, en la tarea Definicin de Componentes y Subsistemas de Construccin (DSI 8.2).
El catlogo de requisitos, el catlogo de excepciones y el diseo detallado del sistema de informacin, permiten la
definicin de las verificaciones que deben realizarse en cada nivel de prueba para comprobar que el sistema
responde a los requisitos planteados. La asociacin de las distintas verificaciones a componentes, grupos de
componentes y subsistemas, o al sistema de informacin completo, determina las distintas verificaciones de cada
nivel de prueba establecido.
Las pruebas unitarias comprenden las verificaciones asociadas a cada componente del sistema de informacin.
Su realizacin tiene como objetivo verificar la funcionalidad y estructura de cada componente individual.
Las pruebas de integracin comprenden verificaciones asociadas a grupos de componentes, generalmente

reflejados en la definicin de subsistemas de construccin o en el plan de integracin del sistema de informacin.
Tienen por objetivo verificar el correcto ensamblaje entre los distintos componentes.
Las pruebas del sistema, de implantacin y de aceptacin corresponden a verificaciones asociadas al sistema de
informacin, y reflejan distintos propsitos en cada tipo de prueba:
Las pruebas del sistema son pruebas de integracin del sistema de informacin completo. Permiten
probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las
especificaciones funcionales y tcnicas se cumplen.
Las pruebas de implantacin incluyen las verificaciones necesarias para asegurar que el sistema
funcionar correctamente en el entorno de operacin al responder satisfactoriamente a los requisitos de
rendimiento, seguridad y operacin, y coexistencia con el resto de los sistemas de la instalacin, y
conseguir la aceptacin del sistema por parte del usuario de operacin.
Las pruebas de aceptacin van dirigidas a validar que el sistema cumple los requisitos de funcionamiento
esperado, recogidos en el catlogo de requisitos y en los criterios de aceptacin del sistema de
informacin, y conseguir la aceptacin final del sistema por parte del usuario.
Las pruebas unitarias, de integracin y del sistema se llevan a cabo en el proceso Construccin del Sistema de
Informacin (CSI), mientras que las pruebas de implantacin y aceptacin se realizan en el proceso Implantacin
y Aceptacin del Sistema (IAS).
Como resultado de esta actividad se actualiza el plan de pruebas con la informacin siguiente:
Especificacin del entorno de pruebas.

Especificacin tcnica de niveles de prueba.
Planificacin de las pruebas.
2.5.12. ACTIVIDAD DSI 11: ESTABLECIMIENTO DE REQUISITOS DE IMPLANTACIN
En esta actividad se completa el catlogo de requisitos con aqullos relacionados con la documentacin que el
usuario requiere para operar con el nuevo sistema, y los relativos a la propia implantacin del sistema en el
entorno de operacin.
La incorporacin de estos requisitos permite ir preparando, en los procesos de Construccin del Sistema de
Informacin (CSI) e Implantacin y Aceptacin del Sistema (IAS), los medios y recursos necesarios para que los
usuarios, tanto finales como de operacin, sean capaces de utilizar el nueva sistema de forma satisfactoria.
2.5.13. ACTIVIDAD DSI 12: APROBACIN DEL DISEO DEL SISTEMA DE INFORMACIN
2.6. CONSTRUCCIN DEL SISTEMA DE INFORMACIN
En este proceso se genera el cdigo de los componentes del Sistema de Informacin, se desarrollan todos los
procedimientos de operacin y seguridad y se elaboran todos los manuales de usuario final y de explotacin con
el objetivo de asegurar el correcto funcionamiento del Sistema para su posterior implantacin.
Para conseguir dicho objetivo, en este proceso se realizan las pruebas unitarias, las pruebas de integracin de los
subsistemas y componentes y las pruebas del sistema, de acuerdo al plan de pruebas establecido.
Asimismo, se define la formacin de usuario final y, si procede, se construyen los procedimientos de migracin y
carga inicial de datos.
Al ser MTRICA Versin 3 una metodologa que cubre tanto desarrollos estructurados como orientados a objetos,
las actividades de ambas aproximaciones estn integradas en una estructura comn.
El producto Especificaciones de Construccin del Sistema de Informacin, obtenido en la actividad de Generacin

de Especificaciones de Construccin (DSI 8), es la base para la construccin del sistema de informacin. En
dicho producto se recoge la informacin relativa al entorno de construccin del sistema de informacin, la
especificacin detallada de los componentes y la descripcin de la estructura fsica de datos, tanto bases de
datos como sistemas de ficheros. Opcionalmente, incluye un plan de integracin del sistema de informacin, en el
que se especifica la secuencia y organizacin de la construccin de los distintos componentes.
En la actividad Preparacin del Entorno de Generacin y Construccin (CSI 1), se asegura la disponibilidad de la
infraestructura necesaria para la generacin del cdigo de los componentes y procedimientos del sistema de
informacin.
Una vez configurado el entorno de construccin, se realiza la codificacin y las pruebas de los distintos
componentes que conforman el sistema de informacin, en las actividades:
Generacin del Cdigo de los Componentes y Procedimientos (CSI 2), que se hace segn las
especificaciones de construccin del sistema de informacin, y conforme al plan de integracin del
sistema de informacin
Ejecucin de las Pruebas Unitarias (CSI 3), dnde se llevan a cabo las verificaciones definidas en el plan
de pruebas para cada uno de los componentes
Ejecucin de las Pruebas de Integracin (CSI 4), que incluye la ejecucin de las verificaciones asociadas
a los subsistemas y componentes, a partir de los componentes verificados individualmente, y la
evaluacin de los resultados.
Una vez construido el sistema de informacin y realizadas las verificaciones correspondientes, se lleva a cabo la
integracin final del sistema de informacin en la actividad Ejecucin de las Pruebas del Sistema (CSI 5),
comprobando tanto las interfaces entre subsistemas y sistemas externos como los requisitos, de acuerdo a las
verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema.
En la actividad Elaboracin de los Manuales de Usuario (CSI 6), se genera la documentacin de usuario final o
explotacin, conforme a los requisitos definidos en el proceso Diseo del Sistema de Informacin.
La formacin necesaria para que los usuarios finales sean capaces de utilizar el sistema de forma satisfactoria se
especifica en la actividad Definicin de la Formacin de Usuarios Finales (CSI 7).
Si se ha establecido la necesidad de realizar una migracin de datos, la construccin y pruebas de los

componentes y procedimientos relativos a dicha migracin y a la carga inicial de datos se realiza en la actividad
Construccin de los Componentes y Procedimientos de Migracin y Carga Inicial de Datos (CSI 8) FIG-12.
FIG-12
2.6.2. ACTIVIDAD CSI 1: PREPARACIN DEL ENTORNO DE GENERACIN Y CONSTRUCCIN
El objetivo de esta actividad es asegurar la disponibilidad de todos los medios y facilidades para que se pueda
llevar a cabo la construccin del sistema de informacin. Entre estos medios, cabe destacar la preparacin de los
puestos de trabajo, equipos fsicos y lgicos, gestores de bases de datos, bibliotecas de programas, herramientas
de generacin de cdigo, bases de datos o ficheros de prueba, entre otros.
Las caractersticas del entorno de construccin y sus requisitos de operacin y seguridad, as como las
especificaciones de construccin de la estructura fsica de datos, se establecen en la actividad Generacin de
Especificaciones de Construccin (DSI 8), y constituyen el punto de partida para la realizacin de esta actividad.
2.6.3. ACTIVIDAD CSI 2: GENERACIN DEL CDIGO DE LOS COMPONENTES Y PROCEDIMIENTOS
El objetivo de esta actividad es la codificacin de los componentes del sistema de informacin, a partir de las
especificaciones de construccin obtenidas en el proceso Diseo del Sistema de Informacin (DSI), as como la
construccin de los procedimientos de operacin y seguridad establecidos para el mismo.
En paralelo a esta actividad, se desarrollan las actividades relacionadas con las pruebas unitarias y de integracin
del sistema de informacin. Esto permite una construccin incremental, en el caso de que as se haya
especificado en el plan de pruebas y en el plan de integracin del sistema de informacin.
2.6.4. ACTIVIDAD CSI 3: EJECUCIN DE LAS PRUEBAS UNITARIAS
En esta actividad se realizan las pruebas unitarias de cada uno de los componentes del sistema de informacin,
una vez codificados, con el objeto de comprobar que su estructura es correcta y que se ajustan a la funcionalidad
establecida.
En el plan de pruebas se ha definido el entorno necesario para la realizacin de cada nivel de prueba, as como
las verificaciones asociadas a las pruebas unitarias, la coordinacin y secuencia a seguir en la ejecucin de las
mismas y los criterios de registro y aceptacin de los resultados.
2.6.5. ACTIVIDAD CSI 4: EJECUCIN DE LAS PRUEBAS DEINTEGRACIN
El objetivo de las pruebas de integracin es verificar si los componentes o subsistemas interactan correctamente
a travs de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida, y se ajustan a los
requisitos especificados en las verificaciones correspondientes.
La estrategia a seguir en las pruebas de integracin se establece en el plan de pruebas, dnde se habr tenido en
cuenta el plan de integracin del sistema de informacin, siempre y cuando se haya especificado en la tarea
Definicin de Componentes y Subsistemas de Construccin (DSI 8.2).
Esta actividad se realiza en paralelo a las actividades Generacin del Cdigo de los Componentes y
Procedimientos (CSI 2) y Ejecucin de las Pruebas Unitarias (CSI 3). Sin embargo, es necesario que los
componentes objeto de las pruebas de integracin se hayan verificado de manera unitaria.
2.6.6. ACTIVIDAD CSI 5: EJECUCIN DE LAS PRUEBAS DEL SISTEMA
El objetivo de las pruebas del sistema es comprobar la integracin del sistema de informacin globalmente,
verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el
resto de sistemas de informacin con los que se comunica.
En la realizacin de estas pruebas es importante comprobar la cobertura de los requisitos, dado que su
incumplimiento puede comprometer la aceptacin del sistema por el equipo de operacin responsable de realizar
las pruebas de implantacin del sistema, que se llevarn a cabo en el proceso Implantacin y Aceptacin del
Sistema.
2.6.7. ACTIVIDAD CSI 6: ELABORACIN DE LOS MANUALES DE USUARIO
2.6.8. ACTIVIDAD CSI 7: DEFINICIN DE LA FORMACIN DE USUARIOS FINALES
En esta actividad se establecen las necesidades de formacin del usuario final, con el objetivo de conseguir la
explotacin eficaz del nuevo sistema.
Para la definicin de la formacin hay que tener en cuenta las caractersticas funcionales y tcnicas propias del
sistema de informacin, as como los requisitos relacionados con la formacin del usuario final, establecidos en la
tarea Especificacin de Requisitos de Implantacin (DSI 11.2).
El producto resultante de esta actividad es la especificacin de la formacin de usuarios finales, que consta de los
siguientes elementos:
Esquema de formacin
Materiales y entornos de formacin.
En el proceso Implantacin y Aceptacin del Sistema (IAS), se unifican las especificaciones de formacin de cada
sistema de informacin implicado en la implantacin y se elabora un nico plan de formacin que est alineado
con el plan de implantacin del sistema.
2.6.9. ACTIVIDAD CSI 8: CONSTRUCCIN DE LOS COMPONENTES Y PROCEDIMIENTOS DE MIGRACIN

Y CARGA INICIAL DE DATOS
El objetivo de esta actividad es la codificacin y prueba de los componentes y procedimientos de migracin y

carga inicial de datos, a partir de las especificaciones recogidas en el plan de migracin y carga inicial de datos
obtenidos en el proceso Diseo del Sistema de Informacin.
Previamente a la generacin del cdigo, se prepara la infraestructura tecnolgica necesaria para realizar la
codificacin y las pruebas de los distintos componentes y procedimientos asociados, de acuerdo a las
caractersticas del entorno de migracin especificado en el plan de migracin y carga inicial de datos.
Finalmente, se llevan a cabo las verificaciones establecidas en la especificacin tcnica del plan de pruebas
propio de la migracin.
2.6.10. ACTIVIDAD CSI 9: APROBACIN DEL SISTEMA DE INFORMACIN
2.7. IMPLANTACIN Y ACEPTACIN DEL SISTEMA
Este proceso tiene como objetivo principal la entrega y aceptacin del sistema en su totalidad, y la realizacin de
todas las actividades necesarias para el paso a produccin del mismo.
En primer lugar, se revisa la estrategia de implantacin que ya se determin en el proceso Estudio de Viabilidad
del Sistema (EVS). Se estudia su alcance y, en funcin de sus caractersticas, se define un plan de implantacin y
se especifica el equipo que lo va a llevar a cabo. Conviene sealar la participacin del usuario de operacin en las
pruebas de implantacin, del usuario final en las pruebas de aceptacin, y del responsable de mantenimiento.
Las actividades previas al inicio de la produccin incluyen la preparacin de la infraestructura necesaria para
configurar el entorno, la instalacin de los componentes, la activacin de los procedimientos manuales y
automticos asociados y, cuando proceda, la migracin o carga inicial de datos. Para ello se toman como punto
de partida los productos software probados, obtenidos en el proceso Construccin del Sistema de Informacin
(CSI) y su documentacin asociada. Se realizan las pruebas de implantacin y de aceptacin del sistema en su
totalidad. Responden a los siguientes propsitos:
Las pruebas de implantacin cubren un rango muy amplio, que va desde la comprobacin de cualquier
detalle de diseo interno hasta aspectos tales como las comunicaciones. Se debe comprobar que el
sistema puede gestionar los volmenes de informacin requeridos, se ajusta a los tiempos de respuesta
deseados y que los procedimientos de respaldo, seguridad e interfaces con otros sistemas funcionan
correctamente. Se debe verificar tambin el comportamiento del sistema bajo las condiciones ms
extremas.
Las pruebas de aceptacin se realizan por y para los usuarios. Tienen como objetivo validar formalmente
que el sistema se ajusta a sus necesidades.
Asimismo, se llevan a cabo las tareas necesarias para la preparacin del mantenimiento, siempre y cuando se
haya decidido que ste va a efectuarse. En cualquier caso, es necesario que la persona que vaya a asumir el
mantenimiento conozca el sistema, antes de su incorporacin al entorno de produccin.
Adems hay que determinar los servicios (y niveles para cada uno) que requiere el sistema que se va a implantar,
y el acuerdo que se adquiere una vez que se inicie la produccin. Hay que distinguir entre servicios de gestin de
operaciones (servicios por lotes, seguridad, comunicaciones, etc.) y servicios al cliente (servicio de atencin a
usuario, mantenimiento, etc.) que se deben negociar en cuanto a recursos, horarios, coste, etc. Se fija el nivel con
el que se prestar el servicio como indicador de la calidad del mismo.
Conviene sealar que la implantacin puede ser un proceso iterativo que se realiza de acuerdo al plan
establecido para el comienzo de la produccin del sistema en su entorno de operacin. Para establecer este plan
se tiene en cuenta:
El cumplimiento de los requisitos de implantacin definidos en la actividad Establecimiento de Requisitos

(ASI 2) y especificados en la actividad Establecimiento de Requisitos de Implantacin (DSI 11).
La estrategia de transicin del sistema antiguo al nuevo.
Finalmente, se realizan las acciones necesarias para el inicio de la produccin. En el siguiente grfico FIG-13 se
muestra la relacin de actividades de este proceso.
FIG-13
2.7.2. ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIN
En esta actividad se revisa la estrategia de implantacin para el sistema, establecida inicialmente en el proceso
Estudio de Viabilidad del Sistema (EVS). Se identifican los distintos sistemas de informacin que forman parte del
sistema objeto de la implantacin. Para cada sistema se analizan las posibles dependencias con otros proyectos,
que puedan condicionar el plan de implantacin.
Una vez estudiado el alcance y los condicionantes de la implantacin, se decide si sta se puede llevar a cabo.
Ser preciso establecer, en su caso, la estrategia que se concretar de forma definitiva en el plan de
implantacin.
Se constituye el equipo de implantacin, determinando los recursos humanos necesarios para la propia
instalacin del sistema, para las pruebas de implantacin y aceptacin, y para la preparacin del mantenimiento.
Se identifican, para cada uno de ellos, sus perfiles y niveles de responsabilidad.
2.7.3. ACTIVIDAD IAS 2: FORMACIN NECESARIA PARA LA IMPLANTACIN
En esta actividad se prepara y se imparte la formacin al equipo que participar en la implantacin y aceptacin
del sistema. Se realiza tambin el seguimiento de la formacin de los usuarios finales, cuya imparticin queda
fuera del mbito de MTRICA Versin 3. De esta forma, se asegura que la implantacin se va a llevar a cabo
correctamente.
Se determina la formacin necesaria para el equipo de implantacin, en funcin de los distintos perfiles y niveles
de responsabilidad identificados en la actividad anterior. Para ello, se establece un plan de formacin que incluye
los esquemas de formacin correspondientes, los recursos humanos y de infraestructura requeridos para llevarlo
a cabo, as como una planificacin que queda reflejada en el plan de formacin.
La formacin para que los usuarios finales sean capaces de utilizar el sistema de manera satisfactoria ha sido
establecida, previamente, en la actividad Definicin de la Formacin de Usuarios Finales (CSI 7). En esta
actividad, se analizan los esquemas de formacin definidos segn los diferentes perfiles, y se elabora un plan de
formacin que est alineado con el plan de implantacin.
2.7.4. ACTIVIDAD IAS 3: INCORPORACIN DEL SISTEMA AL ENTORNO DE OPERACIN
En esta actividad se realizan todas las tareas necesarias para la incorporacin del sistema al entorno de
operacin en el que se van a llevar a cabo las pruebas de implantacin y aceptacin del sistema.
Mientras que las pruebas unitarias, de integracin y del sistema se pueden ejecutar en un entorno distinto de
aqul en el que finalmente se implantar, las pruebas de implantacin y aceptacin del sistema deben ejecutarse
en el entorno real de operacin. El propsito es comprobar que el sistema satisface todos los requisitos
especificados por el usuario en las mismas condiciones que cuando se inicie la produccin.
Por tanto, como paso previo a la realizacin de dichas pruebas y de acuerdo al plan de implantacin establecido,
se verifica que los recursos necesarios estn disponibles para que se pueda realizar, adecuadamente, la
instalacin de todos los componentes que integran el sistema, as como la creacin y puesta a punto de las bases
de datos en el entorno de operacin. Asimismo, se establecen los procedimientos de explotacin y uso de las
bases de datos de acuerdo a la normativa existente en dicho entorno.
2.7.5. ACTIVIDAD IAS 4: CARGA DE DATOS AL ENTORNO DE OPERACIN
Teniendo en cuenta que los sistemas de informacin que forman parte del sistema a implantar pueden mejorar,
ampliar o sustituir a otros ya existentes en la organizacin, puede ser necesaria una carga inicial y/o una
migracin de datos cuyo alcance depender de las caractersticas y cobertura de cada sistema de informacin
implicado. Por tanto, la necesidad de una migracin de datos puede venir determinada desde el proceso Estudio
de Viabilidad del Sistema (EVS), en la actividad Seleccin de la Solucin (EVS 6). All se habr establecido la
estrategia a seguir en la sustitucin, evaluando las opciones del enfoque de desarrollo e instalacin ms
apropiados para llevarlo a cabo.
En cualquier caso, en la actividad Diseo de la Migracin y Carga Inicial de Datos (DSI 9) se habrn definido y
planificado los procesos y procedimientos necesarios para llevar a cabo la migracin, realizndose su codificacin
en la actividad Construccin de los Componentes y Procedimientos de Migracin y Carga Inicial de Datos (CSI 8).
2.7.6. ACTIVIDAD IAS 5: PRUEBAS DE IMPLANTACIN DEL SISTEMA
La finalidad de las pruebas de implantacin es doble:
Comprobar el funcionamiento correcto del mismo en el entorno de operacin.

Permitir que el usuario determine, desde el punto de vista de operacin, la aceptacin del sistema
instalado en su entorno real, segn el cumplimiento de los requisitos especificados.
Para ello, el responsable de implantacin revisa el plan de pruebas de implantacin y los criterios de aceptacin
del sistema, previamente elaborados. Las pruebas las realizan los tcnicos de sistemas y de operacin, que
forman parte del grupo de usuarios tcnicos que ha recibido la formacin necesaria para llevarlas a cabo.
Una vez ejecutadas estas pruebas, el equipo de usuarios tcnicos informa de las incidencias detectadas al
responsable de implantacin, el cual analiza la informacin y toma las medidas correctoras que considere
necesarias para que el sistema d respuesta a las especificaciones previstas, momento en el que el equipo de
operacin lo da por probado.
2.7.7. ACTIVIDAD IAS 6: PRUEBAS DE ACEPTACIN DEL SISTEMA
Las pruebas de aceptacin tienen como fin validar que el sistema cumple los requisitos bsicos de
funcionamiento esperado y permitir que el usuario determine la aceptacin del sistema. Por este motivo, estas
pruebas son realizadas por el usuario final que, durante este periodo de tiempo, debe plantear todas las
deficiencias o errores que encuentre antes de dar por aprobado el sistema definitivamente.
Los Directores de los Usuarios revisan los criterios de aceptacin, especificados previamente en el plan de
pruebas del sistema, y dirigen las pruebas de aceptacin final que llevan a cabo los usuarios expertos. A su vez,
stos ltimos deben elaborar un informe que los Directores de los Usuarios analizan y evalan para determinar la
aceptacin o rechazo del sistema.
2.7.8. ACTIVIDAD IAS 7: PREPARACIN DEL MANTENIMIENTO DEL SISTEMA
El objetivo de esta actividad es permitir que el equipo que va a asumir el mantenimiento del sistema est
familiarizado con l antes de que el sistema pase a produccin. Para conseguir este objetivo, se ha considerado
al responsable de mantenimiento como parte integrante del equipo de implantacin. Por lo tanto, se habr tenido
en cuenta su perfil al elaborar el esquema de formacin correspondiente.
Una vez que el responsable de mantenimiento ha recibido la formacin necesaria y adquirido una visin global del
sistema que se va a implantar, se le entregan los productos que sern objeto del mantenimiento. De esta manera,
obtiene de una forma gradual un conocimiento profundo del funcionamiento y facilidades que incorpora el
sistema, que van a permitirle acometer los cambios solicitados por los usuarios con mayor facilidad y eficiencia.
Se reduce, en consecuencia, el esfuerzo invertido en el mantenimiento.
Es importante resaltar que la existencia de una configuracin del software permite reducir el esfuerzo requerido y
mejora la calidad general del software a mantener, aunque no garantiza un mantenimiento libre de problemas.
Una pobre configuracin del software puede tener un impacto negativo sobre su facilidad de mantenimiento.
2.7.9. ACTIVIDAD IAS 8: ESTABLECIMIENTO DEL ACUERDO DE NIVEL DE SERVICIO
Antes de la aprobacin definitiva del sistema por parte del Comit de Direccin es conveniente:
Determinar los servicios que requiere el mismo.

Especificar los niveles de servicio con los que se va a valorar la calidad de ese prestacin.
Definir qu compromisos se adquieren con la entrega del sistema.
Para ello, en primer lugar, se negocia entre los mximos responsables del usuario y de operacin qu servicios y
de qu tipo se van a prestar. Una vez acordados, se detallan los niveles de servicio definiendo sus propiedades
funcionales y de calidad. Se establece cules de ellas son cuantificables y qu indicadores se van a aplicar. Es
importante sealar que los niveles de servicio son especficos para cada uno de los subsistemas que componen
el sistema de informacin, y dependen del entorno de operacin y de la localizacin geogrfica en que se
implante un sistema de informacin concreto, pudiendo haber servicios bsicos para todo el sistema o especficos
para un subsistema de informacin concreto.
Por ltimo, se establece formalmente el acuerdo de nivel de servicio, considerando los recursos necesarios,
plazos de restablecimiento del servicio, coste y mecanismos de regulacin que estn asociados a cada servicio
especificado anteriormente.
Segn el mbito y el alcance de los tipos de servicio que se vayan a prestar, se determinar los productos del ciclo
de vida del software necesarios para poder establecer el acuerdo de nivel de servicio.
2.7.10. ACTIVIDAD IAS 9: PRESENTACIN Y APROBACIN DEL SISTEMA
Una vez que se han efectuado las pruebas de implantacin y de aceptacin, y que se ha fijado el acuerdo de nivel
de servicio, el Comit de Direccin debe formalizar la aprobacin del sistema. Para esto, se lleva a cabo una
presentacin general del sistema al Comit de Direccin y se espera la confirmacin de su aprobacin.
2.7.11. ACTIVIDAD IAS 10: PASO A PRODUCCIN
Esta actividad tiene como objetivo establecer el punto de inicio en que el sistema pasa a produccin, se traspasa
la responsabilidad al equipo de mantenimiento y se empiezan a dar los servicios establecidos en el acuerdo de
nivel de servicio, una vez que el Comit de Direccin ha aprobado el sistema.
Para ello es necesario que, despus de haber realizado las pruebas de implantacin y de aceptacin del sistema,
se disponga del entorno de produccin perfectamente instalado en cuanto a hardware y software de base,
componentes del nuevo sistema y procedimientos manuales y automticos.
En funcin del entorno en el que se hayan llevado a cabo las pruebas de implantacin y aceptacin del sistema,
habr que instalar los componentes del sistema total o parcialmente. Tambin se tendr en cuenta la necesidad
de migrar todos los datos o una parte de ellos.
Una vez que el sistema ya est en produccin, se le notifica al responsable de mantenimiento, al responsable de
operacin y al Comit de Direccin.
2.8. MANTENIMIENTO DE SISTEMAS DE INFORMACIN
El objetivo de este proceso es la obtencin de una nueva versin de un sistema de informacin desarrollado con
MTRICA Versin 3 Versin 2, a partir de las peticiones de mantenimiento que los usuarios realizan con motivo
de un problema detectado en el sistema, o por la necesidad de una mejora del mismo.
En este proceso se realiza el registro de las peticiones de mantenimiento recibidas, con el fin de llevar el control
de las mismas y de proporcionar, si fuera necesario, datos estadsticos de peticiones recibidas o atendidas en un
determinado periodo, sistemas que se han visto afectados por los cambios, en qu medida y el tiempo empleado
en la resolucin de dichos cambios. Es recomendable, por lo tanto, llevar un catlogo de peticiones de
mantenimiento sobre los sistemas de informacin, en el que se registren una serie de datos que nos permitan
disponer de la informacin antes mencionada.
En el momento en el que se registra la peticin, se procede a diagnosticar de qu tipo de mantenimiento se trata.

Atendiendo a los fines, podemos establecer los siguientes tipos de mantenimiento:
Correctivo: son aquellos cambios precisos para corregir errores del producto software.
Evolutivo: son las incorporaciones, modificaciones y eliminaciones necesarias en un producto software
para cubrir la expansin o cambio en las necesidades del usuario.
Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo,
cambios de configuracin del hardware, software de base, gestores de base de datos, comunicaciones,
etc.
Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en
cualquiera de sus aspectos: reestructuracin del cdigo, definicin ms clara del sistema y optimizacin
del rendimiento y eficiencia.
Estos dos ltimos tipos quedan fuera del mbito de MTRICA Versin 3 ya que requieren actividades y perfiles
distintos de los del proceso de desarrollo.
Una vez registrada la peticin e identificado el tipo de mantenimiento y su origen, se determina de quin es la
responsabilidad de atender la peticin. En el supuesto de que la peticin sea remitida, se registra en el catlogo
de peticiones de mantenimiento y contina el proceso. La peticin puede ser denegada. En este caso, se notifica
al usuario y acaba el proceso.
Posteriormente, segn se trate de un mantenimiento correctivo o evolutivo, se verifica y reproduce el problema, o

se estudia la viabilidad del cambio propuesto por el usuario. En ambos casos se estudia el alcance de la
modificacin. Hay que analizar las alternativas de solucin identificando, segn el tipo de mantenimiento de que
se trate, cul es la ms adecuada. El plazo y urgencia de la solucin a la peticin se establece de acuerdo con el
estudio anterior.
La definicin de la solucin incluye el estudio del impacto de la solucin propuesta para la peticin en los sistemas
de informacin afectados. Mediante el anlisis de dicho estudio, la persona encargada del Proceso de
Mantenimiento valora el esfuerzo y coste necesario para la implementacin de la modificacin.
Las tareas de los procesos de desarrollo que va a ser necesario realizar son determinadas en funcin de los
componentes del sistema actual afectados por la modificacin. Estas tareas pertenecen a actividades de los
procesos Anlisis, Diseo, Construccin e Implantacin.
Por ltimo, y antes de la aceptacin del usuario, es preciso establecer un plan de pruebas de regresin que
asegure la integridad del sistema de informacin afectado.
La mejor forma de mantener el coste de mantenimiento bajo control es una gestin del Proceso de Mantenimiento
efectiva y comprometida. Por lo tanto, es necesario registrar de forma disciplinada los cambios realizados en los
sistemas de informacin y en su documentacin. Esto repercutir directamente en la mayor calidad de los
sistemas resultantes.
La estructura propuesta para el Proceso de Mantenimiento de MTRICA Versin 3 comprende las siguientes
actividades:
2.8.2. ACTIVIDAD MSI 1: REGISTRO DE LA PETICIN
El objetivo de esta actividad es establecer un sistema estandarizado de registro de informacin para las
peticiones de mantenimiento, con el fin de controlar y canalizar los cambios propuestos por un usuario o cliente,
mejorando el flujo de trabajo de la organizacin y proporcionando una gestin efectiva del mantenimiento. Es
importante asignar responsabilidades para evitar la realizacin de cambios que beneficien a un usuario, pero que
produzcan un impacto negativo sobre otros muchos. Por tanto, es necesario, que todas las peticiones de
mantenimiento sean presentadas de una forma estandarizada, que permita su clasificacin y facilite la
identificacin del tipo de mantenimiento requerido.
Una vez que la peticin ha sido registrada, que ha determinado el tipo de mantenimiento y los sistemas de
informacin a los que inicialmente puede afectar, se comprueba su viabilidad, de acuerdo a las prestaciones de
mantenimiento establecidas para dichos sistemas de informacin.
2.8.3. ACTIVIDAD MSI 2: ANLISIS DE LA PETICIN
En esta actividad se lleva a cabo el diagnstico y anlisis del cambio para dar respuesta a las peticiones de
mantenimiento que han sido aceptadas en la actividad anterior.
Se analiza el alcance de la peticin en lo referente a los sistemas de informacin afectados, valorando hasta que
punto pueden ser modificados en funcin del ciclo de vida estimado para los mismos y determinando la necesidad
de desviar la peticin hacia el proceso Estudio de Viabilidad del Sistema (EVS) o Anlisis del Sistema de
Informacin (ASI), en funcin del impacto sobre los sistemas de informacin afectados.
El enfoque de este estudio vara segn el tipo de mantenimiento, teniendo en cuenta que en el caso de un
mantenimiento correctivo que implique un error crtico debe abordarse el cambio de forma inmediata sin
profundizar en el origen del mismo. No obstante, una vez reanudado el servicio, es imprescindible analizar el
problema y determinar cul es la solucin definitiva.
2.8.4. ACTIVIDAD MSI 3: PREPARACIN DE LA IMPLEMENTACIN DE LA MODIFICACIN
Una vez finalizado el estudio previo de la peticin y aprobada su implementacin, se pasa a identificar de forma
detallada cada uno de los elementos afectados por el cambio mediante el anlisis de impacto. Este anlisis tiene
como objetivo determinar qu parte del sistema de informacin se ve afectada, y en qu medida, dejando
claramente definido y documentado qu componentes hay que modificar, tanto de software como de hardware.
Con el resultado de este anlisis se dispone de los datos cuantitativos sobre los que aplicar los indicadores
establecidos. Esto permitir fijar un plan de accin, valorando la necesidad de realizar un reajuste de dichos
indicadores, con el fin de cumplir el plazo mximo de entrega.
Una vez aceptado el plan de accin, se activan los correspondientes procesos de desarrollo para llevar a cabo la
implementacin de la solucin. Al mismo tiempo, se especifican las pruebas de regresin con el fin de evitar el
efecto onda en el sistema, una vez realizados los cambios.
2.8.5. ACTIVIDAD MSI 4: SEGUIMIENTO Y EVALUACIN DE LOS CAMBIOS HASTA LA ACEPTACIN
Se realiza el seguimiento de los cambios que se estn llevando a cabo en los procesos de desarrollo, de acuerdo
a los puntos de control del ciclo de vida del cambio establecidos en el plan de accin. Durante este seguimiento,
se comprueba que slo se han modificado los elementos que se ven afectados por el cambio y que se han
realizado las pruebas correspondientes, especialmente las pruebas de integracin y del sistema. Del resultado
obtenido se hace una evaluacin del cambio para la posterior aprobacin.
Una vez finalizado el cambio en desarrollo, se realizan las pruebas de regresin que especificadas en la actividad
anterior, comprobando que ningn sistema no modificado, pero con posibilidades de verse afectado, ha variado
su comportamiento habitual. Se informa si ha habido incidencias con el fin de que se resuelvan del modo ms
conveniente. Se evalan las pruebas.
La aprobacin de la peticin se realiza al finalizar las pruebas de regresin, y despus de comprobar que todo lo
que ha sido modificado o puede verse afectado por el cambio, funciona correctamente Con el cierre de la peticin
se podrn incluir en el catlogo, si se considera oportuno, parte de la informacin obtenida durante el proceso de
mantenimiento que pueda facilitar posteriores anlisis.
3. CONCLUSIN
Como se ha dicho ya, el objetivo de la Planificacin del proyecto de software es proporcionar un marco de trabajo
que permita al gestor hacer estimaciones razonables de recursos, costos y planificacin temporal. Para conseguir
este objetivo se debe realizar un proceso de descubrimiento de la informacin que lleve a estimaciones
razonables.
Para llevar a cabo la planificacin es necesario el uso de tcnicas y herramientas que permitan gestionar estos
proyectos. Estas tcnicas no son ms que algoritmos que ayudan a construir calendarios y planificaciones. Para
conseguir una planificacin es necesario pasar por diversas etapas, cada una de ellas ofrece ms informacin y
permite ajustar cada tarea con el tiempo empleado, las tareas precedentes, los recursos asignados a cada una de
ellas y el tiempo invertido en todo el proyecto.
Una metodologa es el "Modo de decir o hacer con orden una cosa". Sirve principalmente para guiarnos durante
el proceso de desarrollo de sistemas de informacin, nos dice lo que debemos hacer, cmo hacerlo cundo y
quin lo har. Es una gua tambin para determinar los puntos de comprobacin.
La metodologa Mtrica 3 es un instrumento pasa sistematizar las actividades que dan soporte al ciclo de vida del
software. Est dividida en procesos, estos a su vez se dividen en actividades y stas por ltimo en tareas.
4. BIBLIOGRAFA
De Cos Castillo, M. Teora general del proyecto. Editorial Sintesis.1995.

Cotterell, M, Hughes,B. Software project management. ITP (Thomson Publishing Inc.) 1995.
Lock, D. Gestin de proyectos. Paraninfo, 1990.
Microsoft Press. Microsoft Project para windows 95 paso a paso. McGraw-Hill 1995.
Page-Jones, M. Practical Projec Management. Dorset House, 1985.
DeMarco, Tom, Lister, Peopleware. Dorset House, 1987.
Referencia Mtrica 3
5. ESQUEMA RESUMEN
Como hemos visto el objetivo de la planificacin del desarrollo proporcionar un marco de trabajo que permita al
gestor hacer estimaciones razonables de recursos costos y planificacin temporal. Estas estimaciones se hacen
dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberan actualizarse
regularmente medida que progresa el proyecto. Adems las estimaciones deberan definir los escenarios del
mejor caso, y peor caso, de modo que los resultados del proyecto pueden limitarse.
Para realizar estas estimaciones y planificaciones se usan una serie de herramientas que faciliten el trabajo, por
ejemplo el diagrama de Gantt, las tcnicas conocidas como PERT (Tcnica para la Evaluacin y Revisin de
Programas) y CPM (Mtodo del Camino Crtico).
La tcnica CPM consta de 4 tareas principales:
Etapa 1. Identificar las tareas. Se deben identificar cada una de las tareas que forman parte del
desarrollo del proyecto.
Etapa 2. Aadir recursos y tiempos. A cada actividad se le asignarn recursos (personas, material,
equipos, etc.) y tiempo estimado para su realizacin, completando la ficha.
Etapa 3. Ordenar las tareas. En esta etapa se tienen que organizar las tareas en base al orden tcnico de
ejecucin. As sabemos que hay que hacer las especificaciones antes de disear el programa. Nos
podemos plantear las siguientes preguntas para ordenar las tareas:
Qu se puede hacer ahora?
Qu debe haberse hecho antes de esto?
Qu podra hacerse a la vez?
Qu debe seguir a lo que hacemos ahora?
Etapa 4. Clculo del camino crtico. Cuando tengamos todas las tareas con sus respectivas duraciones y
las precedencias pasamos a dibujar una red en la que aparezca para cada tarea una caja similar a la vista
en el punto anterior con casi todos los campos vacos.
Primero se calculan las fechas tempranas. Para esto seguimos los siguientes pasos:
En aquellas tareas que no tienen ningn predecesor se le asigna a Inicio temprano el valor cero.
Si la tarea tiene predecesoras y todas estas tienen calculado su Final temprano se toma como Inicio
temprano el mximo de todos ellos.
El Final temprano de cada tarea se calcula como el Inicio temprano ms la Duracin.
Repetiremos estos pasos hasta que todas las tareas tengan sus fechas tempranas.
A continuacin las fechas tardas.
Se obtiene la fecha de finalizacin de proyecto ms tarda. Esta puede venir dada por algn tipo de
razones externas o puede que se nos pida que el proyecto termine lo antes posible, en este caso la
fecha de finalizacin ms tarda ser el mximo de los "Final temprano" de todas las tareas.
A aquellas tareas que no sean predecesoras de ninguna otra se les asigna como Final tardo la fecha
de finalizacin ms tarda del punto 4.
El Inicio tardo se calcula restando al Final tardo la Duracin.
En aquellas tareas que son predecesoras de otras se calcula el Final tardo como el mnimo de los
Inicio tardo de las tareas de que es predecesora.
Para obtener el camino crtico necesitamos calcular tambin la Holgura y el mximo tiempo disponible.
Mximo tiempo disponible = Final tardo - Inicio temprano
Holgura = Mximo tiempo disponible - Duracin
Llamamos camino crtico de una planificacin al conjunto de tareas que tienen Holgura cero. A las tareas
del camino crtico se les llama tareas crticas y esto se debe a que un retraso en cualquiera de ellas lleva
a un retraso del final del proyecto.
Una metodologa es un modo o manera concreto de hacer con orden una cosa (desarrollo de sistemas de
informacin). Nos sirve como gua; nos dice lo que tenemos que hacer, cmo, cundo y quin tiene que hacerlo;
adems, lo hace de manera completa; podremos saltarnos los pasos que consideremos convenientes siempre
que comprendamos la estructura del mtodo y podamos evaluar la conveniencia de utilizar atajos.
Tambin determina los puntos del proceso en los que debemos detenernos y comprobar cmo vamos, algo que
es muy importante y que evita la propagacin de los errores a travs del proceso.
Y por ltimo permite que los conocimientos adquiridos en el desarrollo de sistemas de informacin se plasmen en
el mtodo que la organizacin utiliza para ello mediante su continua revisin y adaptacin y pasen a ser
patrimonio de la organizacin y no solo de las personas que llevan a acabo la tarea.
La metodologa Mtrica 3 tiene unos objetivos claros:
Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los fines de la Organizacin
mediante la definicin de un marco estratgico para el desarrollo de los mismos.
Dotar a la Organizacin de productos software que satisfagan las necesidades de los usuarios dando una
mayor importancia al anlisis de requisitos.
Mejorar la productividad de los departamentos de Sistemas y Tecnologas de la Informacin y las
Comunicaciones, permitiendo una mayor capacidad de adaptacin a los cambios y teniendo en cuenta la
reutilizacin en la medida de lo posible.
Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software a
lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, as como las
necesidades de todos y cada uno de ellos.
Facilitar la operacin, mantenimiento y uso de los productos software obtenidos.
Sus caractersticas son:
La nueva versin de MTRICA contempla el desarrollo de Sistemas de Informacin para las distintas
tecnologas que actualmente estn conviviendo y los aspectos de gestin que aseguran que un Proyecto
cumple sus objetivos en trminos de calidad, coste y plazos.
Su punto de partida es la versin anterior de MTRICA de la cual se han conservado la adaptabilidad,
flexibilidad y sencillez, as como la estructura de actividades y tareas, si bien las fases y mdulos de
MTRICA Versin 2.1 han dado paso a la divisin en Procesos, ms adecuada a la entrada-
transformacin-salida que se produce en cada una de las divisiones del ciclo de vida de un proyecto. Para
cada tarea se detallan los participantes que intervienen, los productos de entrada y de salida as como las
tcnicas y prcticas a emplear para su obtencin.
En la elaboracin de MTRICA Versin 3 se han tenido en cuenta los mtodos de desarrollo ms
extendidos, as como los ltimos estndares de ingeniera del software y calidad, adems de referencias
especficas en cuanto a seguridad y gestin de proyectos. Tambin se ha tenido en cuenta la experiencia
de los usuarios de las versiones anteriores para solventar los problemas o deficiencias detectados.
En una nica estructura la metodologa MTRICA Versin 3 cubre distintos tipos de desarrollo: estructurado y
orientado a objetos, facilitando a travs de interfaces la realizacin de los procesos de apoyo u organizativos:
Gestin de Proyectos, Gestin de Configuracin, Aseguramiento de Calidad y Seguridad.
La automatizacin de las actividades propuestas en la estructura de MTRICA Versin 3 es posible ya que sus
tcnicas estn soportadas por una amplia variedad de herramientas de ayuda al desarrollo.
Cada Proceso detalla las Actividades y Tareas a realizar. Para cada tarea se indican:
Las tcnicas y prcticas a utilizar

Los responsables de realizarla
Sus productos de entrada y salida
Le estructura de procesos es la siguiente:
PLANIFICACIN PSI
DESARROLLO
ESTUDIO DE VIABILIDAD EVS
ANLISIS ASI
DISEO DSI
CONSTRUCCIN CSI
IMPLANTACIN Y ACEPTACIN IAS
MANTENIMIENTO MSI

TICB2 - Planificacion Del Desarrollo

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TICB2 - Planificacion Del Desarrollo

Enviado por

Direitos autorais:

Formatos disponíveis

www.haztefuncionario.com Material registrado. Prohibida su reproduccin.

B2G1T03 - PLANIFICACIN DEL DESARROLLO.

1. TCNICAS DE PLANIFICACIN ................................................................................................................................. 3

2.5.1. DESCRIPCIN Y OBJETIVOS.......................................................................................................................... 33

1.1. INTRODUCCIN A LA PLANIFICACIN DEL DESARROLLO

El Objetivo de la planificacin se logra mediante un proceso de descubrimiento de la informacin que lleve a

Existen diversos tipos de planes:

Describe el enfoque los recursos y la planificacin

Predice los requerimientos de mantenimiento del

Describe como se adquirirn y desarrollarn los

1.2. HERRAMIENTAS BSICAS USADAS EN LA PLANIFICACIN

1.3. APLICACIN DE LA TCNICA CPM

1.3.1. ETAPA 1. IDENTIFICAR LAS TAREAS

1.3.2. ETAPA 2. AADIR RECURSOS Y TIEMPOS

1.3.3. ETAPA 3. ORDENAR LAS TAREAS

Qu se puede hacer ahora?

Vamos a representar cada nodo (tarea) como se ve en la FIG-5.

Etiqueta actividad Duracin

DESCRIPCIN DE LA ACTIVIDAD es el nombre que le hemos dado a la actividad. Por ejemplo:

1.3.4. ETAPA 4. CLCULO DEL CAMINO CRTICO

Mximo tiempo disponible = Final tardo - Inicio temprano

Holgura = Mximo tiempo disponible - Duracin

1.3.4.1. OBTENCIN DEL CAMINO CRTICO

1.4. DIFERENCIA FUNDAMENTAL ENTRE EL CPM Y EL PERT.

"tm" tiempo medio que se estima para la actividad,

A la tarea se le asigna como duracin el resultado de:

1.5. USO DE APLICACIONES PARA LA PLANIFICACIN Y CONTROL DE PROYECTOS.

2. METODOLOGAS DE DESARROLLO: LA METODOLOGA MTRICA 3

2.1. INTRODUCCIN A LA METODOLOGA MTRICA 3

2.1.1. QU ES UNA METODOLOGA?

La situacin-problema a un sistema de representacin til para nuestros propsitos (anlisis de

2.1.2. PARA QU SIRVE?

Facilitar la operacin, mantenimiento y uso de los productos software obtenidos.

Cada Proceso detalla las Actividades y Tareas a realizar.

Para cada tarea se indican:

Las tcnicas y prcticas a utilizar

La estructura de procesos es la siguiente:

Los interfaces son los siguientes FIG-7:

2.2. PLANIFICACIN DE SISTEMAS DE INFORMACIN (PSI)

2.2.1. DESCRIPCIN Y OBJETIVOS

La perspectiva del plan debe ser estratgica y operativa, no tecnolgica.

2.2.2. ACTIVIDAD PSI 1: INICIO DEL PLAN DE SISTEMAS DE INFORMACIN

2.2.3. ACTIVIDAD PSI 2: DEFINICIN Y ORGANIZACIN DEL PSI

2.2.4. ACTIVIDAD PSI 3: ESTUDIO DE LA INFORMACIN RELEVANTE

La informacin obtenida en esta actividad se tendr en cuenta en la elaboracin de los requisitos.

2.2.5. ACTIVIDAD PSI 4: IDENTIFICACIN DE REQUISITOS

2.2.6. ACTIVIDAD PSI 5: ESTUDIO DE LOS SISTEMAS DE INFORMACIN ACTUALES

2.2.7. ACTIVIDAD PSI 6: DISEO DEL MODELO DE SISTEMAS DE INFORMACIN

2.2.8. ACTIVIDAD PSI 7: DEFINICIN DE LA ARQUITECTURA TECNOLGICA

2.2.9. ACTIVIDAD PSI 8: DEFINICIN DEL PLAN DE ACCIN

2.2.10. ACTIVIDAD PSI 9: REVISIN Y APROBACIN DEL PSI

2.3. ESTUDIO DE VIABILIDAD DEL SISTEMA

2.3.1. DESCRIPCIN Y OBJETIVOS

2.3.2. ACTIVIDAD EVS 1: ESTABLECIMIENTO DEL ALCANCE DEL SISTEMA

2.3.3. ACTIVIDAD EVS 2: ESTUDIO DE LA SITUACIN ACTUAL

Si se decide documentar la situacin actual, normalmente es conveniente dividir el sistema actual en

2.3.4. ACTIVIDAD EVS 3: DEFINICIN DE REQUISITOS DEL SISTEMA

2.3.5. ACTIVIDAD EVS 4: ESTUDIO DE ALTERNATIVAS DE SOLUCIN

2.3.6. ACTIVIDAD EVS 5: VALORACIN DE LAS ALTERNATIVAS

2.3.7. ACTIVIDAD EVS 6: SELECCIN DE LA SOLUCIN

2.4. ANLISIS DEL SISTEMA DE INFORMACIN

2.4.1. DESCRIPCIN Y OBJETIVOS

La definicin de requisitos del nuevo sistema se realiza principalmente en la actividad Establecimiento de

En la actividad Identificacin de Subsistemas de Anlisis (ASI 3), se estructura el sistema de informacin en