Eurometodo v1

CONSEJO SUPERIOR
DE INFORMÁTICA
EUROMÉTODO v1
SECRETARÍA DE ESTADO PARA LA ADMINISTRACIÓN PÚBLICA
Consejo Superior de Informática

Eurométodo v1
MINISTERIO DE ADMINISTRACIONES PÚBLICAS

MADRID
1997
Advertencia importante
La presente obra es la traducción al español del documento "Euromethod version

1" desarrollado por la Comisión Europea, y no una adaptación de dicho
documento a la situación española y en particular a la legislación nacional sobre
contratos. Su punto de vista es general, esto es, aplicable a cualquier situación de
contratación de sistemas y servicios informáticos tanto por empresas del sector
privado como por organizaciones del sector público, en cualquier lugar de la Unión
Europea.
En particular, por lo que se refiere al ámbito de las AA.PP., algunas

consideraciones y ejemplos del método pudieran no ser conformes con lo previsto
en la Ley de Contratos de las Administraciones Públicas o sus normas de
desarrollo. Naturalmente. En estos y en todos los demás casos, los compradores
públicos deberán atenerse a lo dispuesto en la Ley.
Cómo utilizar este libro

Con este libro se pretende satisfacer las necesidades de un gran número de
personas, tanto las de aquellos lectores que deseen saber más de Eurométodo
como las de quienes precisen una orientación detallada en aspectos concretos de
Eurométodo.
Teniendo en cuenta esta doble funcionalidad, el contenido del libro sigue un orden
lógico: se describe el marco de Eurométodo, se presentan los conceptos clave y se
ofrece una orientación exhaustiva en torno a todos los aspectos de Eurométodo,
tanto desde el punto de vista del cliente como del proveedor.
A continuación se describen brevemente la estructura del libro, las funciones
asociadas y los símbolos especiales que se utilizan.
Estructura del libro

A continuación se presentan todas las secciones del libro.
Acerca de Eurométodo
En este apartado se pretende proporcionar al lector una visión general de
Eurométodo; su concepto, alcance y objetivos en el contexto de la adquisición de
sistemas de información y servicios asociados.
Índice
El diseño del índice permite que el lector que ya esté familiarizado con
Eurométodo encuentre de inmediato el tema que desea consultar, al tiempo que
presenta la estructura de Eurométodo a aquellos lectores que desean conocerla
más a fondo.
Capítulo 1 – Presentación de conceptos

Este capítulo presenta los conceptos clave y las funciones que se utilizan en
Eurométodo, en el contexto de una organización y su sistema de información, de
manera que el lector los pueda comprender de inmediato.
Capítulo 2 – El proceso de adquisición

El capítulo 2 pretende ser una guía sobre el empleo de Eurométodo. En este
capítulo se describen a grandes rasgos los principales procesos en que intervienen
los clientes y los proveedores, y se hace referencia a otros apartados del libro que
ofrecen más información de cada tema.
El capítulo 2 es el punto de partida aconsejado para aquellos lectores que
pretendan utilizar Eurométodo de guía en un determinado proceso de adquisición
de sistemas de información y servicios asociados. Este capítulo permitirá al lector
buscar en todo el libro, gracias a las referencias a otros capítulos y anexos de
interés.
© Proyecto Eurométodo 1996 i

Eurométodo versión 1
Capítulo 3 – Entregables
El capítulo 3 presenta los entregables de Eurométodo e identifica sus contextos –
entregables de nivel contractual, nivel de gestión y nivel operativo.
Capítulo – Técnicas de planificación de la adaptación

El capítulo 4 se ocupa de la planificación de la adaptación (es decir, la planificación
del proceso de adaptación de un sistema de información) y describe con todo
detalle las técnicas para llevar a cabo esta planificación.
Capítulo 5 – Descripción y planificación de servicios

La finalidad del capítulo 5 es similar a la del capítulo anterior, aunque éste se
centra en la planificación de la prestación de servicios (es decir, la planificación de
un proceso que un proveedor ofrece como servicio).
Anexos
Los anexos contienen información detallada y plantillas que se utilizan al aplicar
Eurométodo.
Diccionario
El diccionario contiene las definiciones de todos los términos y conceptos
utilizados en Eurométodo.
Funciones
Eurométodo identifica dos funciones clave comunes a la organización del cliente y
a la del proveedor. La importancia de estas funciones se pone de manifiesto
siempre que un cliente y un proveedor se relacionan. Se trata del responsable
contractual y del responsable de proyecto o servicio:
• Un responsable contractual es:
la persona o personas con la facultad de resolver o concluir una cuestión
abierta con respecto a un contrato específico. Un responsable contractual
representa a la organización del cliente y el otro representa a la organización
del proveedor. No es necesario, ni siquiera deseable, que una misma persona
desempeñe la función de responsable contractual durante todo el proceso de
adquisición.
• Un responsable de proyecto o servicio es:
abierta con respecto a un servicio o proyecto específicos. De nuevo, un
responsable de servicio representa a la organización del cliente y el otro
representa a la organización del proveedor. No es necesario, ni siquiera
deseable, que una misma persona desempeñe la función de responsable de
proyecto o de servicio durante todo el proceso de adquisición.
Dado que estas funciones existen tanto en la organización del cliente como en la
del proveedor, se identifican las cuatro funciones clave siguientes:
ii © Proyecto Eurométodo 1996

• responsable contractual del cliente

• responsable de proyecto o servicio del cliente
• responsable contractual del proveedor
• responsable de proyecto o servicio del proveedor
Símbolos especiales
A continuación se explican los símbolos especiales que se utilizan en este libro.
Iconos de función
El capítulo 2 orienta al lector, según su función, mediante unos iconos situados en
los márgenes, como el del ejemplo que se ofrece a continuación. En este caso la
función que se indica es la de responsable contractual del proveedor, ya que se
destaca la sección situada en la fila superior (responsable contractual) y la columna
de la derecha (organización del proveedor).
Contrato
SC
CC
Cliente Suministrador
CP SP
CS SS
Proyecto o provisión de
servicios
En general, las funciones se indican al inicio de cada apartado y se vuelven a

destacar posteriormente cuando el tema principal del texto cambia. Mediante el
símbolo (þ apartado: título) se hace referencia a otras partes del libro que pueden
orientar a los responsables de proyecto/servicio.
Icono de compra pública

Cuando el texto trata de normas de compra pública que revisten especial interés
para quienes intervienen en compras del sector público, se llama la atención del
lector mediante el icono que aparece al margen.
Texto al margen
El uso de ‘texto al margen’ es otra manera de llamar la atención del lector sobre
ciertos contenidos, destacando determinados mensajes clave incluidos en el texto,
lo que permite al lector localizar la información de especial interés.
© Proyecto Eurométodo 1996 iii

Texto específico sobre adaptaciones/servicios

En los capítulos 1 y 2:
• Cuando aparece información específica sobre adaptaciones, el inicio del texto se
señala con el símbolo A y el final con el símbolo A .
• Cuando aparece información específica sobre servicios, el inicio del texto se
señala con el símbolo S y el final con el símbolo S .
Definiciones
Las definiciones importantes se ilustran de la siguiente manera:
Definición Definición del término o concepto
Esta convención no se emplea en el capítulo 1, que contiene un gran número de

definiciones.
iv © Proyecto Eurométodo 1996

La necesidad de Eurométodo
La piedra angular de toda organización moderna es la disponibilidad de Los sistemas de
información oportuna, relevante y fácilmente accesible. El aspecto de la información son
organización que proporciona, utiliza y distribuye esta información, junto con los la clave del éxito
recursos organizativos asociados, tanto técnicos como humanos, se denomina
sistema de información (SI). Todas las organizaciones, sean del sector privado o
del sector público, poseen sistemas de información que les ayudan a gestionar sus
actividades. Un sistema de información puede basarse en documentos impresos, o
bien estar total o parcialmente automatizado, es decir, informatizado. Estos
sistemas de información son la clave del éxito y, a menudo, de la supervivencia, de
muchas organizaciones.
La dinámica de la vida moderna provoca continuos cambios en las actividades
comerciales de todos los tipos de organizaciones (incluyendo las
administraciones públicas). Para hacer frente a estos cambios se precisan
sistemas de información cada vez más potentes y flexibles.
La adquisición de un sistema de información que cubra nuevas necesidades del La adquisición
negocio no es una tarea trivial. Incluye definir el objetivo de la adquisición, de un sistema de
desarrollar una estrategia para su implementación, contratar por partes el objetivo información no
de la adquisición, e integrar estas partes en un sistema de información completo y es una tarea
trivial
en los procesos de negocio de la organización que realiza la adquisición.
Orientar adecuadamente estos aspectos durante la adquisición aumenta
significativamente la probabilidad de éxito.
Gestión de riesgos
La evolución de la tecnología contribuye a un aumento de las oportunidades, pero
también a un incremento de los riesgos que hay que gestionar.
La ‘complejidad’ y la ‘incertidumbre’ son factores importantes que contribuyen
a la aparición de riesgos en una adquisición. La nueva tecnología crea nuevas
oportunidades, pero también genera nuevos riesgos. No obstante, el principal
riesgo potencial reside en los factores humanos.
Un sistema informático puede variar en complejidad, desde un único PC con una Gestionar la
aplicación sencilla e independiente hasta un sistema heterogéneo distribuido que complejidad y la
contenga numerosas aplicaciones complejas que interactúen entre sí. incertidumbre
La incertidumbre dependerá del tipo de aplicación, aspectos organizativos, la

tecnología utilizada, etc. Las aplicaciones de uso común en numerosas
organizaciones y de fácil comprensión prácticamente no encierran riesgos. Las
aplicaciones nuevas y/o específicas proporcionan una ventaja competitiva, pero
pueden presentar mayores riesgos.
© Proyecto Eurométodo 1996 v

Las tecnologías evolucionan con rapidez y con ellas aumenta la variedad de

soluciones posibles. Hoy en día los diseñadores de sistemas de información se
enfrentan a sistemas distribuidos, interfaces gráficas de usuario, nuevos sistemas de
almacenamiento de datos, integración de aplicaciones técnicas y de gestión,
integración de paquetes, multimedios, etc. En el futuro puede que se enfrenten a la
realidad virtual y otras nuevas tecnologías que, si bien crean nuevas oportunidades,
también generan sus propios riesgos que hay que gestionar.
Gestionar los Cada vez más un sistema de información se percibe como un sistema complejo que
aspectos incluye aspectos humanos y sociales, donde la tecnología no es más que una parte
humanos del conjunto. El principal riesgo potencial reside en estos aspectos humanos; por
ejemplo, la migración de sistemas heredados tiene complejas implicaciones
organizativas que deben tomarse en consideración.
Entendimiento mutuo
Clarificar el Una adquisición efectiva de un sistema de información y los servicios asociados

estado final requiere descripciones claras del estado final deseado y de la situación actual. Es
deseado importante que el cliente y el proveedor entiendan del mismo modo la situación
actual y el sistema de información y los servicios asociados a adquirir.
La apertura del mercado único europeo y el mercado mundial emergente son el
resultado de una predisposición política a incrementar el volumen de negocios
entre las naciones y así contribuir al crecimiento económico de la sociedad.
En el campo de los sistemas de información, la apertura del mercado sólo se
podrá alcanzar completamente si se eliminan los obstáculos al entendimiento
mutuo entre los clientes y proveedores de distintos países. Estos obstáculos se
deben, en parte, a la existencia de gran número de métodos, cada uno con unos
conceptos y un vocabulario propios.
Unificar la La comunicación entre cliente y proveedor se ve dificultada cuando la terminología
terminología en utilizada se interpreta de manera distinta por cada uno de ellos.
las
comunicaciones Para asegurar la introducción de los sistemas modernos y los servicios asociados es
entre cliente y preciso que participen muchas personas con diferentes funciones,
proveedor responsabilidades, experiencias y conocimientos básicos. Una comunicación
efectiva es esencial para un entendimiento mutuo.
Control de las expectativas y de los costes
Cuidado con las A menudo se subestiman los costes de adquisición o mejora de un sistema de
expectativas que información y los gastos de mantenimiento. Una razón importante de ello es que
aumentan de las expectativas tienden a aumentar durante el proceso de producción, a veces de
forma forma inconsciente. El control de tales expectativas precisa una gestión cuidadosa
inconsciente
de las decisiones que afectan al desarrollo, diseño, construcción e instalación y
operación del sistema de información nuevo o mejorado. El proceso de decisión
debe planificarse y realizarse con cuidado, contando con la intervención del cliente
y del proveedor.
vi © Proyecto Eurométodo 1996

Objetivos de Eurométodo
Eurométodo se ha diseñado para ayudar a las organizaciones en la adquisición de Eurométodo
sistemas de información efectivos y de los servicios asociados en distintas ayuda a
situaciones. Anima a los clientes y proveedores a controlar los costes y los plazos gestionar los
previstos, gestionar los riesgos y mejorar el entendimiento mutuo. riesgos
A través de la consecución de estos objetivos, la Comisión Europea pretende

fomentar la apertura del mercado de sistemas de información, mejorar la movilidad
de las personas entre los distintos países, facilitar la organización de proyectos
internacionales y ayudar a los clientes a valorar las ofertas de los proveedores.
Los objetivos de Eurométodo son:
• ayudar al entendimiento mutuo entre clientes y proveedores de proyectos y
servicios de sistemas de información dentro de un mercado internacional
abierto, proporcionando asesoramiento apoyado por un conjunto de
conceptos y terminología que utilizarán en las transacciones
• mejorar la adquisición de sistemas de información y servicios, teniendo
presente la situación del problema y los riesgos asociados
• proporcionar un marco para la unificación de la terminología de los
métodos.
Destinatarios
Eurométodo
Para sacar el máximo partido de Eurométodo, lo mejor es que tanto el cliente debe utilizarse a
como el proveedor lo utilicen a nivel contractual. Sin embargo, aunque sólo una de nivel contractual
las partes comience a utilizarlo, ello ya supone una mejora en la planificación y en
la supervisión.
Así pues, quienquiera que esté a cargo de la adquisición u obtención de un sistema
de información y los servicios asociados, deberá utilizar Eurométodo.
La alta dirección debería fomentar el uso de Eurométodo por parte del personal
directivo, con lo que se garantizaría que obtienen la información necesaria para
adoptar decisiones estratégicas y que utilizan el mejor sistema disponible para
llevar a cabo la adquisición de manera eficiente.
Los directores de proyectos y servicios deberían utilizar las técnicas de
Eurométodo cuando proceda, y deberían estar familiarizados con Eurométodo a fin
de valorar y reconocer las necesidades a nivel contractual.
Los agentes de proyectos y servicios deberían comprender la terminología de
Eurométodo para evitar malentendidos entre ellos y sus directores.
Ventajas de utilizar Eurométodo

Tanto los clientes como sus proveedores pueden beneficiarse potencialmente del
uso de Eurométodo.
© Proyecto Eurométodo 1996 vii

Al tomar en consideración todo el sistema de información, y no sólo el software,

Las
adquisiciones de
Eurométodo ayuda a proporcionar soluciones adecuadas a las necesidades del
sistemas de negocio y a los imperativos técnicos y organizativos.
información Eurométodo se ha desarrollado para ser utilizado tanto en el sector público como
deberán
adecuarse a las
en el privado.
necesidades del
negocio Ventajas para los clientes Ventajas para los proveedores
Formulación más clara de los Mejor comprensión de las necesidades del

requisitos cliente
Mejora de la gestión de riesgos Visión más clara del sistema de
información del cliente
Orientación al seleccionar la Mayor facilidad para que los clientes
modalidad de adquisición más aprueben las decisiones claves de diseño
adecuada para una situación concreta
del problema
Mejor comprensión de las ofertas de Determinación del enfoque más adecuado
los proveedores para la realización de un proyecto o la
prestación de un servicio
Evaluación más sencilla de las ofertas Selección de los métodos, técnicas y
de los proveedores herramientas adecuadas
Aceptación más sencilla de servicios y Aceptación más sencilla de servicios y
sistemas, gracias a una mejor sistemas, gracias a una mejor
planificación y definición de los planificación y definición de los
requisitos requisitos
Mejora del proceso de decisión en Mejora de la gestión de riesgos asociados
relación con los entregables y servicios a un proyecto y/o prestación de servicios
Evitar limitarse a un único proveedor Mejor información para controlar las
expectativas y los costes
Evitar limitarse a un método específico
Mejor información para controlar los

costes
Control más sencillo de las
expectativas
Ventajas de utilizar Eurométodo
Eurométodo como marco
Eurométodo Uno de los principales obstáculos para conseguir un entendimiento mutuo es la

aplica el punto gran diversidad de métodos que utilizan distintos conceptos y terminología. Estos
de vista de la métodos suelen utilizar un vocabulario que procede de la ingeniería de software y
adquisición que puede resultar de difícil comprensión para los usuarios del sistema de
información, los responsables de la adquisición y los responsables contractuales.
Para solventar este problema, Eurométodo toma en consideración las adaptaciones
y prestaciones de servicios desde el punto de vista de la adquisición, en lugar del
punto de vista de la ingeniería.
viii © Proyecto Eurométodo 1996

Eurométodo proporciona un marco en el que describir, utilizar, perfeccionar y

Un marco
unificar los distintos métodos, como por ejemplo los métodos de reingeniería de abierto para
procesos de negocio, métodos de desarrollo de sistemas de información y métodos utilizar y
de gestión de proyectos y servicios. unificar métodos
Potencialmente cualquier método se puede utilizar junto con Eurométodo en una
adquisición, siempre que se ajuste a la situación. Eurométodo está abierto a
técnicas estructuradas, técnicas orientadas a objetos, técnicas de ingeniería de
procesos de negocio, técnicas de infraestructura de TI, etc. Gracias a su diseño,
está abierto a las mejoras que se introduzcan en estas técnicas en el futuro.
La única condición es estar familiarizado con la terminología de Eurométodo. Un
diccionario de enlace permite comprender los tipos de entregables que propone un
método, sin haber recibido formación específica acerca de ese método. Ya existen
diccionarios de enlace entre varios métodos y Eurométodo. Traducen la
terminología específica del método a la terminología de Eurométodo, al tiempo
que especifican en qué situaciones son adecuadas las técnicas que propone el
método.
Eurométodo proporciona un marco, es decir, un conjunto de conceptos y una
terminología:
• para mejorar la relación cliente-proveedor
• para unificar los métodos.
Eurométodo como método

La adquisición tiene lugar en tres niveles:
• en el nivel de prestación de servicios o producción del proyecto, los agentes
utilizan una gran variedad de métodos y herramientas para tareas como el
desarrollo del sistema de información, aseguramiento de la calidad, gestión
de la configuración y manejo del ordenador
• en el nivel de gestión del servicio o proyecto, los agentes cuentan con el
apoyo de métodos y herramientas de gestión de proyectos
• Eurométodo se ha diseñado para ser utilizado a nivel contractual por la
gestión de adquisiciones, en especial dentro de la gestión de contratos.
Eurométodo proporciona un método para definir, planificar y ejecutar la Eurométodo es
adquisición de un sistema de información y los servicios asociados. un método para
ser utilizado a
Se utiliza para valorar y determinar: nivel contractual
• la situación del problema y los riesgos asociados
• el objetivo de la adquisición
• la estrategia de la adquisición, la adaptación del sistema de información y
la prestación de servicios
• el plan de entregas que describa las relaciones cliente-proveedor a nivel
contractual, incluyendo el intercambio de entregables.
© Proyecto Eurométodo 1996 ix

Eurométodo no se ocupa de aspectos legales ni es un método para el desarrollo

de un sistema de información ni para la prestación de un servicio.
x © Proyecto Eurométodo 1996

Capítulo 1
Presentación de conceptos
Índice
1 PRESENTACIÓN DE CONCEPTOS............................................................................13
1.1 ORGANIZACIONES Y SUS SISTEMAS DE INFORMACIÓN .......................................................13
1.1.1 Organizaciones y sus procesos............................................................................13
1.1.2 Sistemas de información .....................................................................................14
1.1.3 Adaptaciones de sistemas de información ...........................................................14
1.1.4 Servicios .............................................................................................................15
1.2 ADQUISICIONES.............................................................................................................15
1.2.1 Dominio objetivo ................................................................................................15
1.2.2 Objetivo de la adquisición ..................................................................................16
1.2.3 Estrategia y plan de adquisición .........................................................................16
1.2.4 Relación cliente-proveedor .................................................................................16
1.2.5 Contrato .............................................................................................................17
1.2.6 Compra...............................................................................................................17
1.2.7 Modelo del proceso de adquisición .....................................................................18
1.2.8 Organización de la adquisición...........................................................................20
1.2.9 El plan de entregas .............................................................................................22
1.3 FUNCIONES EN LAS ADQUISICIONES ................................................................................22
1.4 ENTREGABLES ..............................................................................................................24
1.5 PLANES Y PROCESOS DE ADAPTACIÓN .............................................................................25
1.5.1 Procesos dentro de las adaptaciones...................................................................25
1.5.2 Planificación de la adaptación............................................................................27
1.6 PLANES Y PROCESOS DE LA PRESTACIÓN DE SERVICIOS.....................................................28
1.6.1 Procesos dentro de la prestación de servicios .....................................................29
1.6.2 Plan de prestación de servicios...........................................................................29
2 EL PROCESO DE ADQUISICIÓN...............................................................................30
2.1 INICIO DEL PROCESO DE ADQUISICIÓN .............................................................................30
2.1.1 Definición del objetivo de la adquisición ............................................................31
2.1.2 Planificación de la adquisición...........................................................................35
2.2 CONDUCCIÓN DE UN PROCESO DE COMPRA ......................................................................57
2.2.1 Licitación............................................................................................................59
2.2.2 Seguimiento del contrato ....................................................................................79
2.2.3 Cumplimentación del contrato ............................................................................92
3 ENTREGABLES ............................................................................................................96
3.1 TIPOS DE ENTREGABLES .................................................................................................96
3.1.1 Entregables del dominio contractual...................................................................96
3.1.2 Entregables de gestión........................................................................................96
3.1.3 Entregables del dominio objetivo........................................................................97
3.2 ENTREGABLES DEL DOMINIO CONTRACTUAL ...................................................................97
3.2.1 Entregables de licitación ....................................................................................98
3.2.2 Entregables de punto de decisión......................................................................106
3.3 ENTREGABLES DE GESTIÓN ..........................................................................................109
3.3.1 Entregables de gestión del proyecto..................................................................109
3.3.2 Entregables de gestión del servicio ...................................................................116
3.4 ENTREGABLES DEL DOMINIO OBJETIVO .........................................................................120
3.5 ELEMENTOS OPERATIVOS.............................................................................................121
3.6 ELEMENTOS DESCRIPTIVOS ..........................................................................................123
3.6.1 Perfiles de los elementos descriptivos ...............................................................123
3.6.2 Visiones y propiedades funcionales...................................................................124
3.6.3 Propiedades de calidad.....................................................................................135
3.6.4 Propiedades de la inversión ..............................................................................138
© Proyecto Eurométodo 1996 11

3.6.5 Alcance ............................................................................................................ 138

3.6.6 Nivel de detalle................................................................................................. 139
3.6.7 Nivel de acuerdo............................................................................................... 141
3.6.8 Grado de formalismo ........................................................................................ 142
3.6.9 Cuantificación .................................................................................................. 142
3.6.10 Simulación........................................................................................................ 142
3.6.11 Identificación de la versión del sistema/servicio ............................................... 143
3.6.12 Soluciones alternativas..................................................................................... 143
3.6.13 Estado de calidad de un elemento descriptivo................................................... 144
4 TÉCNICAS DE PLANIFICACIÓN DE LA ADAPTACIÓN...................................... 145
4.1 GESTIÓN DEL RIESGO .................................................................................................. 145
4.2 ANÁLISIS DE RIESGOS .................................................................................................. 148
4.2.1 Documentar el estado inicial y el estado final .................................................. 149
4.2.2 Valorar los factores situacionales..................................................................... 154
4.2.3 Evaluar la incertidumbre y complejidad generales ........................................... 161
4.2.4 Analizar la probabilidad de riesgos .................................................................. 162
4.2.5 Identificar los riesgos críticos........................................................................... 167
4.3 DISEÑO DE UNA ESTRATEGIA DE ADAPTACIÓN............................................................... 169
4.3.1 Selección de contramedidas.............................................................................. 170
4.3.2 Análisis de las opciones estratégicas ................................................................ 175
4.3.3 Seleccionar las opciones estratégicas ............................................................... 182
4.3.4 Analizar las repercusiones de la estrategia....................................................... 191
4.4 PLANIFICACIÓN DE LOS PUNTOS DE DECISIÓN ................................................................ 193
4.4.1 Derivar la secuencia básica de puntos de decisión ........................................... 197
4.4.2 Adaptar la secuencia básica a las contramedidas ............................................. 206
4.4.3 Describir los puntos de decisión ....................................................................... 208
4.5 DESCRIPCIÓN DE LOS ENTREGABLES ............................................................................. 210
4.5.1 Describir perfiles de elementos descriptivos ..................................................... 210
4.5.2 Establecer enlaces con los productos del método.............................................. 216
4.6 VALORACIÓN DE UN PLAN DE ADAPTACIÓN ................................................................... 216
4.6.1 Valorar la descripción de la situación .............................................................. 217
4.6.2 Valorar la idoneidad de la estrategia de adaptación......................................... 218
4.6.3 Valorar la idoneidad de los puntos de decisión................................................. 218
5 DESCRIPCIÓN Y PLANIFICACIÓN DE SERVICIOS ............................................ 221
5.1 DESCRIPCIÓN DE SERVICIOS ......................................................................................... 222
5.1.1 Identificar el tipo de servicio ............................................................................ 222
5.1.2 Descripción de las propiedades de un servicio.................................................. 226
5.2 PLANIFICACIÓN DE SERVICIOS ...................................................................................... 230
5.2.1 Análisis de riesgos............................................................................................ 231
5.2.2 Diseño de la estrategia de prestación del servicio ............................................ 234
5.2.3 Planificación de puntos de decisión.................................................................. 235
12 © Proyecto Eurométodo 1996

Capítulo 1
1 Presentación de conceptos
Este capítulo presenta al lector los conceptos de Eurométodo, describe el contexto
en el que opera Eurométodo y los conceptos clave que determinan el vocabulario y
la sintaxis de un proceso de adquisición de Eurométodo.
Así pues, todos los lectores deberán leer al menos una vez el presente capítulo, sin
importar la(s) función(es) que desempeñen.
1.1 Organizaciones y sus sistemas de información

Las organizaciones son sistemas humanos, es decir, grupos estructurados de Organización
personas que posiblemente utilizan máquinas (inclusive ordenadores) y coordinan
sus esfuerzos de cara a la consecución de ciertos objetivos. Las personas precisan
información para llevar a cabo sus procesos cognitivos, y las organizaciones
precisan información para que las personas puedan comunicarse entre sí.
1.1.1 Organizaciones y sus procesos

Se puede concebir una organización como un conjunto de agentes que ejecutan Recursos de
unos procesos utilizando (y actualizando) recursos de información (véase figura información
1.1). Por recursos de información se entiende la totalidad de la información que
está disponible dentro de la organización. Esta información es relevante para la
estructura, funcionamiento y evolución de la organización y de su entorno
(clientes, proveedores, mercado, reglamentos, etc.).
Los procesos se pueden describir según diferentes niveles de detalle:
• por sus objetivos, imperativos y características de calidad (por ejemplo, Proceso
entregar cierto producto a un cliente sin sobrepasar un plazo y un coste
determinados, y para plena satisfacción del cliente)
• por sus resultados (por ejemplo, el producto que se entrega)
• por sus actividades (o subprocesos) (por ejemplo, el proceso de entrega
consistirá en sacar el producto del almacén, comprobar sus características,
seleccionar el medio de transporte).
Los procesos de estado estable sustentan el funcionamiento diario de la Proceso de
organización, es decir, la consecución de sus objetivos con respecto a su entorno. estado estable
Suelen ser continuos e incluyen actividades que se repiten periódicamente durante
la vida de la organización. Permanecen en el mismo estado estable durante largos
períodos de tiempo, o sólo experimentan ligeros cambios.
Los procesos de adaptación ajustan la organización a los cambios del entorno. El Proceso de
objetivo de una adaptación es cambiar la organización y/o estudiar y preparar este adaptación
cambio. Cada adaptación es un proceso específico con un principio y un final, y
representa un estado de transición en la organización, es decir, traslada la
organización de un estado inicial a un estado final en un tiempo determinado. Una
adaptación se define por sus estados inicial y final y por el camino que lleva del uno
al otro.

Organización
Dominio objetivo
Recursos de información
utilizan
utilizan
Agentes
ejecutan
Procesos
Figura 1.1: Organización y dominio objetivo
1.1.2 Sistemas de información
Sistema de El sistema de información (SI) se define como el aspecto de la organización que

información proporciona, utiliza y distribuye información. Por tanto, se trata de un aspecto de
un sistema humano, que posiblemente incluye sistemas informáticas y automatiza
ciertos elementos.
Sistema El sistema informático (CS) es la parte automatizada del sistema de información.
informático Puede incluir uno o más ordenadores o periféricos, y software que ejecuta el
proceso de datos.
1.1.3 Adaptaciones de sistemas de información

Una adaptación del sistema de información puede ser cualquier tipo de
modificación (corrección, perfeccionamiento, mejora, automatización, introducción
o incorporación de un nuevo sistema informático, etc.) de un SI para satisfacer las
necesidades de una organización.
Este proceso incluye:
• desarrollo del sistema
• mantenimiento del sistema
• diseño del sistema
• ingeniería inversa
• reingeniería de procesos
• instalación de sistemas
Capítulo 1
• diversas clases de estudios

El estado inicial de una adaptación del SI es la situación del SI al inicio de la Estado inicial
adaptación, más los conocimientos disponibles en ese momento acerca de este SI y
las versiones futuras del mismo.
El estado final de una adaptación del SI es la situación del SI al final de la Estado final
adaptación, más los conocimientos acerca de este SI y las versiones futuras del
mismo que se consiguen al final de la adaptación.
La vida de un SI suele incluir varias adaptaciones, por ejemplo, uno o más estudios
de análisis de cambios1, y uno o más proyectos de descripción, construcción e
instalación del sistema.
Eurométodo proporciona los medios para definir, con flexibilidad, los estados
inicial y final de una adaptación, e incluye ejemplos de estados iniciales y finales
típicos.
1.1.4 Servicios
Un servicio es un proceso que una persona o una organización ejecuta para otra. Servicio
Más concretamente, en el sector público, el término servicio se utiliza para
referirse a aquellos procesos que representan un valor económico no relacionado
con la producción de bienes materiales. La Directiva de Servicios de la CE
proporciona una clasificación de los servicios [92/50/CEE].
Dentro de Eurométodo se abordan dos tipos de servicios, que corresponden a los
tipos de procesos que se han mencionado anteriormente: los servicios de
adaptación y los servicios de estado estable.
En esta guía, todo ‘servicio de estado estable’ se designará normalmente con la Servicio de
palabra ‘servicio’, y todo ‘servicio de adaptación’ se llamará ‘adaptación’, como estado estable
ocurre en la práctica habitual.
Servicio de
adaptación
1.2 Adquisiciones
El proceso de adquisición (o simplemente adquisición) es el proceso de obtención
de un sistema o servicio, o cualquier combinación de ambos.
1.2.1 Dominio objetivo

Cuando una organización posee ciertas necesidades del negocio relativas a varios Dominio
de sus procesos, la parte que se ve afectada se denomina dominio objetivo (véase objetivo
figura 1.1). El dominio objetivo es la parte de la organización que se ve afectada
por una adaptación o un servicio. El dominio objetivo puede ser una empresa, una
administración pública o una parte de alguna de estas entidades.
1 También se considerará una adaptación un proyecto cuyo único resultado sea una mejora de
los conocimientos y de la documentación acerca del sistema existente o del diseño de un
futuro sistema.
Las necesidades del negocio pueden formar parte de una estrategia de negocio (por
Necesidades del
negocio
ejemplo, el desarrollo de una aplicación estratégica), o pueden derivarse de las
necesidades de personas interesadas del dominio objetivo (por ejemplo, mejorar los
aspectos ergonómicos, funcionalidad o mantenimiento de un sistema informático),
o ser el resultado de imperativos externos (por ejemplo, cambios de la normativa
legal).
Con la integración de los sistemas informáticos y los procesos de negocio, la
adquisición de servicios asociados a sistemas de información se ha convertido en
una tarea compleja. Para definir estas necesidades, la adquisición tiene que
comenzar en el nivel de estrategia del negocio.
1.2.2 Objetivo de la adquisición
Objetivo de la El objetivo de la adquisición viene definido por un conjunto coherente de requisitos

adquisición del sistema y del servicio que satisfacen las necesidades del negocio seleccionadas
en el dominio objetivo. Ejemplos de objetivos de la adquisición: un proceso
empresarial perfeccionado, una nueva estructura organizativa, una nueva aplicación
informatizada, un servicio perfeccionado de operación del sistema informático.
El objetivo de la adquisición se utiliza para dirigir el proceso de adquisición, que
comienza con la formulación de una estrategia de adquisición.
1.2.3 Estrategia y plan de adquisición
Estrategia de La estrategia de adquisición determinará el número y tipos de adaptaciones,

adquisición prestaciones de servicios y contratos que se precisan para lograr el objetivo de la
adquisición.
Descomponer una adquisición en un conjunto de adquisiciones más pequeñas
(denominadas ‘compras’) es, por una parte, una manera de gestionar los riesgos y,
por otra, permite una mayor competencia y evita a un único proveedor.
Plan de El plan de adquisición documenta la estrategia de adquisición y define la
adquisición organización y la coordinación de las distintas compras.
1.2.4 Relación cliente-proveedor
Cliente El proceso de adquisición se gestiona dentro de las relaciones cliente-proveedor. El

cliente es la persona u organización responsable del objetivo de la adquisición, que
ha decidido contratar prestaciones de servicios o adaptaciones. El cliente puede ser
o no la organización del dominio objetivo. En este último caso, el cliente actuará
en nombre de la organización del dominio objetivo o de su propietario.
Proveedor El proveedor es la persona u organización que suministra un sistema o servicio al
cliente.
En las adquisiciones complejas pueden intervenir más de un proveedor, siendo
cada uno de ellos responsable de un subconjunto de sistemas y servicios. Los
proveedores, a su vez, pueden tener subcontratistas que les proporcionen varios
servicios y sistemas – véase figura 1.2. En estas circunstancias, el proveedor actúa
como cliente para estos subcontratistas.

Capítulo 1
1.2.5 Contrato
Un contrato es un acuerdo vinculante con valor legal entre dos partes, o un
acuerdo similar dentro de una organización, para el suministro de servicios o Contrato
sistemas. Una organización puede precisar varios contratos para la adquisición de
los sistemas y servicios que necesite.
Cliente
Contrato 1 Contrato 2 Contrato 3
Suministrador 1 Suministrador 2 Suministrador 3
Subcontrato 1.1 Subcontrato 1.2
Subcontratista 1 Subcontratista 2
Figura 1.2: Adquisición con múltiples relaciones cliente-proveedor
1.2.6 Compra
La compra es el proceso de preparación de un contrato y obtención de los sistemas
y servicios que se definen en dicho contrato.
En la figura 1.3 se puede observar que un contrato puede regular la compra de
varios servicios de adaptación y de estado estable.

Adquisición
Compra 1
Licitación Contrato 1
Adaptación 1
Servicio 1
Adaptación 1.2
Servicio 1.2
Compra 2
Licitación Contrato 2
Adaptación 2.1
Servicio 2.1
Figura 1.3: La relación entre adquisición, compra, adaptación y servicio de estado

estable
1.2.7 Modelo del proceso de adquisición
Inicio de la La adquisición comienza como un proceso del cliente y posteriormente incluye

adquisición procesos cliente-proveedor en los que posiblemente intervienen varios proveedores
y contratos. La primera actividad del cliente es el inicio de la adquisición, que
permite definir con mayor precisión el objetivo de la adquisición en base a las
necesidades del negocio, formular los requisitos de los servicios y sistemas
necesarios, elaborar la estrategia de adquisición y planificar la adquisición en base a
un análisis de la situación y al objetivo de la adquisición.
Riesgo La estrategia de adquisición se elabora en un marco de gestión de riesgos. Un
riesgo es la posibilidad de exposición a las consecuencias adversas de eventos
futuros.
Gestión de La gestión de riesgos es un enfoque sistemático para reducir la probabilidad de
riesgos riesgos y/o limitar los daños causados por dichos riesgos.
Un resultado importante del inicio de la adquisición es el desglose de la adquisición
completa en un conjunto de compras, cada una de las cuales se ocupa de un
subconjunto de los sistemas y servicios.
Para cada contrato, el proceso de compra es una secuencia de tres procesos:
Proceso de • El proceso de licitación:
licitación está encaminado a seleccionar un proveedor y una oferta para los servicios y
sistemas en cuestión, y a acordar con el proveedor seleccionado un contrato
que defina las entregas y las responsabilidades de ambas partes. El proceso
de licitación se compone de los siguientes subprocesos: preparación de la

Capítulo 1
petición de ofertas, preparación de las ofertas, selección del proveedor,

preparación del contrato. Estos subprocesos no tienen por qué ser ejecutados
en el orden de la figura 1.4: pueden coincidir en el tiempo, y pueden
producirse iteraciones de grupos de dichos subprocesos.
• El proceso de seguimiento del contrato: Proceso de
está encaminado a supervisar las prestaciones de servicios y el desarrollo de seguimiento del
los sistemas definidos en el contrato, es decir, asegurar que los servicios y contrato
sistemas entregados son conformes con los requisitos especificados en el
contrato. Este proceso puede considerarse un proceso de decisión: en ciertos
momentos, el cliente y el proveedor toman decisiones relativas a los servicios
y sistemas entregados, costes, calendario y otras cuestiones contractuales.
Un tipo de decisión importante es la aceptación por parte del cliente de un
sistema entregado por el proveedor. Es preciso coordinar los diferentes
contratos.
• El proceso de cumplimentación del contrato: Proceso de
está encaminado a poner término al contrato. Comprueba que se han cumplimentación
realizado efectivamente todas las entregas, y que se han cumplido las del contrato
obligaciones de ambas partes, y cumplimenta todas las cuestiones pendientes
(por ejemplo, el pago, transmisión de la propiedad, garantía) antes de
cancelar el contrato.

Inicio de la
Adquisición
Licitación
Preparación de la Licitación
petición de ofertas Licitación
Preparación de la
petición de ofertas Preparación de la
Preparación de petición de ofertas
las ofertas Preparación de
las ofertas Preparación de
Selección del las ofertas
suministrador Selección del
suministrador Selección del
Preparación del suministrador
contrato Preparación del
contrato
Preparación del
contrato
Seguimiento del contrato
Seguimiento del contrato
Ejecución del punto
de decisión Seguimiento del contrato
Ejecución del punto
de decisión Ejecución del punto
de decisión
Cumplimentación del contrato
Cumplimentación Cumplimentación del contrato

administrativa Cumplimentación del contrato
Cumplimentación
administrativa
Cumplimentación
Compra 1 administrativa
Compra 2
Compra n
Figura 1.4: El modelo del proceso de adquisición
1.2.8 Organización de la adquisición

En un momento dado, la adquisición incluye al personal del proveedor. El personal
del cliente y del proveedor desempeñará diferentes funciones en esa organización.
Proyecto de Un equipo organizado de personas, denominado organización de servicios, es el
organización de que se hace cargo del servicio contratado. La organización de servicios
servicios proporciona resultados que deberán satisfacer los requisitos formulados por el
cliente (véase figura 1.5). Una organización temporal denominada ‘proyecto’ es la
encargada de llevar a cabo una adaptación que realiza un proveedor para un
cliente.

Capítulo 1
Se suelen definir tres niveles (en las adquisiciones de pequeña envergadura, una
misma persona puede estar a cargo de más de un nivel).
• La función de prestación de servicios o producción del proyecto proporciona Prestación de
al cliente el servicio o sistemas que precisa, por ejemplo: ingeniería de servicios
procesos de negocio, manejo de un sistema informático, mantenimiento de Producción del
redes, desarrollo de software. Para ello utiliza recursos (pericia, proyecto
conocimientos, productos, etc.) del proveedor y a veces del cliente.
• La función de gestión del servicio o del proyecto planifica y supervisa el Gestión del
servicio o la producción. Organiza el equipo, asigna recursos a las tareas y servicio
garantiza que se satisface la calidad requerida dentro del plazo y del Gestión del
proyecto
presupuesto pactados.
• La función de gestión de la adquisición controla la adquisición y sus
diferentes contratos. Es responsable de los requisitos del servicio y del
Gestión de la
sistema que se reflejan en la petición de ofertas, las ofertas y los contratos. adquisición
Controla si los servicios y el sistema satisfacen los requisitos y adopta las
medidas oportunas en caso contrario. En una adquisición compleja, este nivel Gestión del
puede desglosarse en gestión de la adquisición y gestión del contrato, y contrato
pueden participar distintas personas en la gestión de los diversos contratos.
º
Adquisición de S.I.
Satisfacción de
Gestión de la requisitos
Requisitos Adquisición
(incluida la
gestión del
contrato)
Eurométodo
Objetivos
Información
Requisitos
Planes
Proveedor 1
Cliente
Organización
Servicio/Proyecto
Gestión del Proveedor 1

Servicio/
proyecto
Normativa
Información
Planes
Productos
Pericia
Conocimiento Realización Productos
del servicio Pericia
Productos o proyecto
Conocimiento
Servicios
Servicio/Proyecto
Proveedor 2
Organización 2
Figura 1.5: Estructura de una organización de la adquisición

1.2.9 El plan de entregas
Punto de Un proceso específico de supervisión del contrato se representa como una

decisión secuencia de puntos de decisión. Un punto de decisión es un momento en que el
cliente, posiblemente junto con el proveedor, toma decisiones sobre las
adaptaciones y la prestación de servicios. Un punto de decisión se caracteriza por
las decisiones que se toman, las funciones involucradas en estas decisiones y los
entregables que se intercambian. Existen entregables de insumo, que sirven de
condición necesaria o de base para las decisiones, y entregables de producto, es
decir, informes de puntos de decisión.
El plan de entregas define la relación contractual cliente-proveedor durante el
seguimiento del contrato. Consolida los planes de adaptación y planes de
prestación de servicios de un contrato, haciendo especial hincapié en las
interdependencias entre los planes.
Plan de entregas El plan de entregas define la secuencia de puntos de decisión del proceso de
seguimiento del contrato. Durante el proceso de licitación se producen varias
versiones del plan de entregas. En la petición de ofertas se da un plan de entregas a
los proveedores potenciales y éstos lo devuelven en respuesta a la licitación. Será
una de las bases para la selección del proveedor y es parte integrante del contrato.
1.3 Funciones en las adquisiciones

En la organización del cliente y en la del proveedor se identifican dos funciones
clave que adquieren relevancia siempre que un cliente y un proveedor se
relacionan. Estas funciones son las de responsable contractual y responsable de
proyecto o de servicio:
• un responsable contractual es:
abierta con respecto a un contrato específico. Un responsable contractual
representa a la organización del cliente y otro a la organización del
proveedor. No es necesario, ni siquiera deseable, que la misma persona actúe
como responsable contractual durante todo el proceso de adquisición.
• un responsable de proyecto o de servicio es:
abierta con respecto a un servicio o proyecto específicos. De nuevo, un
responsable de servicio representa a la organización del cliente y otro a la
organización del proveedor. No es necesario, ni siquiera deseable, que la
misma persona actúe como responsable de proyecto o de servicio durante
todo el proceso de adquisición.
El comportamiento de estos tipos de función clave se ve afectado por la imposición
de directrices o imperativos externos, o por la aportación de la pericia apropiada.
Es decir, existen otros tipos de funciones cuya finalidad es aportar los insumos
relativos a la dirección organizativa, o aportar la pericia concreta que se precisa en
el proceso de adquisición. Estos otros tipos de funciones son los correspondientes
a los responsables organizativos y la pericia operativa, que se encuentran en las
organizaciones de los clientes y de los proveedores:

Capítulo 1
• Un responsable organizativo es:

la persona o grupo de personas con la facultad para resolver o concluir una
cuestión abierta en relación con los requisitos estratégicos de la
organización. Así pues, en un nivel determinado, cualquier decisión que
adopte un responsable contractual puede verse afectada por varios
responsables organizativos de su organización. En consecuencia, uno de los
responsables organizativos puede imponer una decisión al responsable
contractual. Son ejemplos de responsable organizativo: alta dirección,
responsable financiero, responsable jurídico, responsable de gestión de
calidad.
• Una pericia operativa es:
la persona o grupo de personas que desempeñan una tarea o actúan como
creadores de opinión en base a su pericia, cualificación o conocimientos
relativos a un tema en concreto. Cuando realizan su trabajo, los responsables
de un proyecto/servicio utilizan varios recursos especializados existentes en
sus organizaciones, es decir, utilizan pericia operativa. Son ejemplos de
pericia operativa: pericia comercial, pericia en sistemas de información,
pericia técnica, pericia de usuario, pericia en aseguramiento de la calidad,
pericia en gestión de configuraciones, pericia en manejo de sistemas, pericia
en gestión de redes, etc.
Las funciones están representadas gráficamente en la figura 1.6.
A pesar de que existe un cierto grado de simetría en cuanto a los tipos de pericia
que precisan proveedor y cliente, los requisitos pueden ser distintos para las
organizaciones de uno y otro.
Las funciones que identifica Eurométodo sirven para representar a los responsables
y a sus responsabilidades en una adquisición, además de las cualificaciones y los
conocimientos que proporcionan. En una adquisición concreta puede ser una única
persona o un grupo de personas (en especial, la pericia operativa suele venir
aportada por un grupo de personas, por ejemplo el equipo del proyecto) quien
desempeñe cada una de las funciones. En ocasiones, una única persona desempeña
diversas funciones; por ejemplo, una persona que gestiona el trabajo del proveedor
puede, por tanto, desempeñar funciones de responsable de servicio y participar al
mismo tiempo en el trabajo aportando pericia operativa.

Responsables de la Responsables de la
Organización Organización
- Alta direccion Responsable Responsable - Alta dirección

- Responsable del contrato del contrato - Responsable
financiero del cliente del proveedor financiero
- Responsable jur¡dico - Responsable jurídico
- Responsable de - Responsable de
gestión de calidad gestión de calidad
Apoya Apoya
Pericia operativa Pericia operativa
- Pericia operativa en: - Pericia operativa en:

. Sistema de Responsable del Responsable del . Sistema de
información servicio/proyecto servicio/proyecto información
. Calidad del cliente del proveedor . Calidad
. Gestión de . Gestión de
configuración configuración
. Operación del . Operación del
sistema sistema
. Etc. . Etc.
Figura 1.6: Funciones de una adquisición
1.4 Entregables
Un entregable es un producto que se intercambia entre el proveedor y el cliente
para satisfacer una determinada finalidad en una adquisición.
Entregable
Los entregables tienen que definirse perfectamente y evitar ambigüedades.
Eurométodo clasifica los entregables en distintos tipos y define un conjunto de
propiedades para cada uno de estos tipos (véase capítulo 3). Estas propiedades se
utilizan para caracterizar los entregables que se precisan, con independencia de un
método específico.
La figura 1.7 muestra los tipos de entregables (y los subtipos):
• entregables del dominio contractual, que se utilizan para definir y controlar el
proceso contractual de la compra de un sistema de información
• entregables de gestión, que se utilizan para planificar y controlar proyectos y
prestaciones de servicios
• entregables del dominio objetivo, que consisten en sistemas o documentos
relativos al dominio objetivo.

Capítulo 1
Entregable
Entregable Entregable
Entregable
del dominio del dominio
de gestión
del contrato objetivo
Entregable Entregable
Elemento Elemento
para la de punto de Plan Informe
operativo descriptivo
licitación decisión
Figura 1.7: Tipos de entregables
1.5 Planes y procesos de adaptación

A
Se trata de otra visión de un proyecto, distinta a la visión que representa el
control jerárquico (véase figura 1.5), que considera la organización como un
conjunto de procesos que cooperan para lograr los objetivos de la adaptación.
Esta visión se utiliza para elaborar modelos organizativos y corresponde a los
procesos que se describen en [ISO/LCP]. Algunos de estos procesos son
especialmente relevantes para la relación cliente-proveedor, ya que afectan
directamente a los entregables y se utilizan para definir las opciones de la estrategia
de adaptación (véase apartado 4.3.2: Análisis de las opciones de estrategia).
1.5.1 Procesos dentro de las adaptaciones

Al nivel de producción del proyecto, existen los siguientes procesos:
• desarrollo: Desarrollo
encaminado a desarrollar los entregables que precisa una adaptación.
• aseguramiento de la calidad: Aseguramiento
consiste en todas las actividades sistemáticas y planificadas que se precisan de la calidad
para generar una confianza suficiente en que un producto o servicio satisfará
los requisitos de calidad que se hayan impuesto [ISO 8402].
A nivel de gestión del proyecto, estos dos procesos son respectivamente el control
del desarrollo y el control de calidad.

Otro proceso que afecta directamente a los entregables es la gestión de la

Gestión de la
configuración
configuración, una disciplina que utiliza la dirección y supervisión técnica y
administrativa para identificar y documentar las características funcionales y físicas
de un elemento de configuración, controlar los cambios de estas características,
registrar y comunicar el proceso de cambio y la situación de su implementación y
verificar el cumplimiento de los requisitos especificados [IEEE-610.12]
Para una relación completa de los procesos, el lector puede consultar la norma ISO
sobre Procesos del Ciclo Vital [ISO-LCP].
Desarrollo
El desarrollo de un SI según los requisitos del cliente abarca tres procesos: un
proceso de descripción, un proceso de construcción y un proceso de instalación.
Estos procesos pueden afectar al SI o a un subsistema específico (por ejemplo, el
sistema informático).
Proceso de • Proceso de descripción:
descripción encaminado a diseñar un sistema que satisfaga los requisitos utilizando
descripciones, las cuales pueden basarse en un lenguaje natural, modelos o
prototipos.
Proceso de • Proceso de construcción:
construcción encaminado a realizar y probar el sistema, cuando éste aún se considera un
artículo artificial que todavía no es operativo.
Proceso de • Proceso de instalación:
instalación encaminado a poner en funcionamiento el sistema, es decir, a hacer que la
organización del dominio objetivo migre al uso del sistema.
Para realizar un sistema o subsistema pueden ser necesarias varias versiones: el
desarrollo de cada versión se produce tras un ciclo vital típico, que aparece
representado esquemáticamente en la figura 1.8. Esta figura muestra los diferentes
estados de una versión del sistema y las posibles transiciones.
Diseñado Construído Instalado
Evaluado
Figura 1.8: Ciclo vital de una versión del sistema

Para mayor simplificación, el estado ‘evaluado’ subsume los resultados de pruebas,
verificaciones y validaciones. Para más información, consulte las normas ISO sobre
Procesos del Ciclo Vital del Software [ISO-LCP].
Algunos métodos de desarrollo de SI proponen un modelo de proceso (por
ejemplo, modelo en cascada) basado en una secuencia de fases que corresponden al
diseño, construcción e instalación. Estas fases forman la base para la planificación
de las adaptaciones de SI. Desafortunadamente, estos modelos de fases han
demostrado ser impracticables en situaciones complejas e inciertas. En la mayoría

Capítulo 1
de las adaptaciones, los tres procesos se ejecutan en paralelo, con picos de

actividad en cada uno de ellos.
El imperativo de secuencia entre diseño, construcción e instalación se mantiene
únicamente para una versión parcial, pero no para todo el proyecto.
La planificación y control efectivos de los proyectos requiere cierta flexibilidad al
definir el proceso de desarrollo más adecuado para una situación dada.
1.5.2 Planificación de la adaptación

La planificación de la adaptación consiste en varias técnicas que conducen a la
creación del plan de adaptación (véase capítulo 4) y se utilizan dentro del proceso
general de adquisición.
El enfoque situacional
En Eurométodo, para seleccionar la estrategia se utiliza un enfoque flexible para la Enfoque
resolución de problemas denominado enfoque situacional. Este enfoque está situacional
encaminado a mejorar la efectividad del proceso de adquisición, adaptándolo a
cada situación del problema. Un proceso de adquisición adaptado es aquél que
maximiza las posibilidades de lograr el éxito en la adaptación, al tiempo que
minimiza los riesgos y los costes.
Situación del problema determina

(necesidad de adaptación Estrategia de gestión
de un sistema de se adapta a de riesgos
información)
Figura 1.9: La estrategia de gestión de riesgos depende de la situación del

problema
En el enfoque situacional, la estrategia de gestión de riesgos y los planes de
adaptación se adaptan a la situación, a su complejidad e incertidumbre, y
contribuyen a la reducción de los riesgos en dicha situación.
En un enfoque situacional es preciso valorar las propiedades de una situación del
problema, calcular sus consecuencias posibles y proponer estrategias adecuadas
(véase figura 1.9). Estas estrategias ayudan a reducir los riesgos inherentes a la
situación.
Análisis de riesgos
Las propiedades relevantes de la situación del problema a la hora de determinar la Factores de
estrategia más adecuada para la resolución del problema se denominan factores situación
situacionales.
Los valores de los factores situacionales dependen de la complejidad y las
Complejidad
incertidumbres asociadas al SI (dominio objetivo) y a la organización del proyecto
(dominio del proyecto). Por regla general, el valor de cada factor de situación Incertidumbre
puede alcanzar tres niveles: complejidad o incertidumbre alta, baja o media.

Los valores atribuidos a cada uno de los factores de situación se utilizan para
Riesgos
identificar los riesgos. A partir de la identificación de los riesgos es posible
determinar las estrategias más adecuadas.
La estrategia de adaptación
Estrategia de Las adaptaciones tienden a ser complejas, por lo que se requiere una planificación
adaptación cuidadosa para garantizar un resultado favorable. Los planes son necesarios para
gestionar los proyectos y predecir los costes, pero para diseñar un plan adecuado
es preciso determinar una estrategia apropiada.
La estrategia de adaptación es el enfoque que pretende conseguir los objetivos de
una adaptación, al tiempo que gestiona de manera eficaz los riesgos inherentes a
cierta situación del problema.
La estrategia para una adaptación en concreto sirve de orientación para el
diseño de los planes y la selección de los métodos que se van a utilizar para esa
adaptación.
Opciones estratégicas
Opciones Eurométodo proporciona recomendaciones (heurísticas) para la selección de las
estratégicas opciones estratégicas en función de las características de la situación del problema.
Estas recomendaciones representan la experiencia de la buena práctica y se pueden
Heurísticas para
la estrategia utilizar para determinar una estrategia de adaptación o para valorar si una
estrategia se adapta a la situación del problema.
Secuencia de puntos de decisión

Secuencia de La secuencia de puntos de decisión para un proyecto en particular depende de la
puntos de estrategia de adaptación que se haya elegido. Eurométodo propone varias plantillas
decisión de secuencias de puntos de decisión para diferentes opciones estratégicas. Estas
plantillas pueden servir de ejemplos que pueden volver a utilizarse al diseñar el plan
de adaptación para un proyecto en concreto.
Eurométodo se centra en las decisiones y los entregables, pero no establece
directamente las actividades a ejecutar ni las técnicas a utilizar. De este modo se
preserva la ventaja competitiva de un método concreto que ofrezca un
proveedor para el desarrollo del SI.
Plan de adaptación
Plan de Un plan de adaptación es un plan para una adaptación singular que se lleva a cabo
adaptación dentro de la compra de un SI. Define la situación del problema, incluyendo el
estado inicial y el estado final de la adaptación, la estrategia de adaptación, la
secuencia de puntos de decisión y los entregables durante el seguimiento del
contrato. Cada plan de entregas incluye uno o más planes de adaptación. A
1.6 Planes y procesos de la prestación de servicios

S
La prestación de servicios incluye varios procesos que deben planificarse
dentro del plan de prestación de servicios.

Capítulo 1
1.6.1 Procesos dentro de la prestación de servicios

Normalmente los servicios constan de tres procesos distintos:
• un proceso de adaptación: instalación del servicio
• un proceso de estado estable: ejecución del servicio
• un proceso de adaptación: retirada del servicio.
La ejecución del servicio se refiere al proceso estable que proporciona el Ejecución del
proveedor al cliente, a diferencia de los procesos de instalación del servicio y servicio
retirada del servicio, que se emprenden a modo de adaptaciones en una única
ocasión, sin que exista continuidad.
La naturaleza de la instalación del servicio puede variar considerablemente entre un Instalación del
servicio y otro. Las cuestiones importantes son la situación de conocimiento acerca servicio
de los sistemas y servicios actuales y su anterior estado, y la fase en que tienen
lugar las transferencias de personal (si es que tienen lugar en algún momento).
La cancelación de una prestación de servicios suele tener lugar a través de una Retirada del
adaptación separada, denominada retirada del servicio. El objetivo de la retirada servicio
del servicio es anular la responsabilidad del proveedor sobre la prestación del
servicio. Si el proveedor tiene que devolver a los clientes (o a otro proveedor que
se haga cargo del servicio) el control directo y la responsabilidad sobre el servicio,
deberá hacerlo de manera que los niveles de servicio se vean mínimamente
afectados. No obstante, a veces el servicio simplemente se suprimirá, si deja de ser
necesario.
1.6.2 Plan de prestación de servicios

Un plan de prestación de servicios es un plan para la prestación de un único Plan de
servicio o de un grupo de servicios asociados dentro de la compra de un sistema de prestación de
información. Define el estado inicial y el estado final de la instalación del servicio y servicios
de la retirada del servicio, la estrategia de prestación del servicio, la secuencia de
puntos de decisión y los entregables durante el seguimiento del contrato.
S

2 El proceso de adquisición
Este capítulo contiene orientaciones en torno al proceso de adquisición. Deberán
leerlo los responsables contractuales y los responsables de proyecto del cliente y
del proveedor. Los lectores que ya estén familiarizados con Eurométodo pueden
abordar directamente el proceso sobre el que precisan orientaciones (por ejemplo,
Selección de proveedores).
El proceso de adquisición (o adquisición, en su forma abreviada) es el proceso de
obtención de un sistema o servicio, o cualquier combinación de ambos.
La adquisición comienza como un proceso del cliente al que posteriormente siguen
varios procesos cliente-proveedor que posiblemente incluyen varios proveedores y
varios contratos. La primera actividad del cliente es el inicio de la adquisición, que
consiste en definir con más precisión el objetivo de la adquisición en base a las
necesidades del negocio, establecer los requisitos de los servicios y sistemas que se
precisan, elaborar la estrategia de adquisición y planificar la adquisición en base a
un análisis de la situación y del objetivo de la adquisición.
Un resultado importante del inicio de la adquisición es el desglose de la totalidad
de la adquisición en un conjunto de compras, cada una de las cuales se ocupa de un
subconjunto de los sistemas y servicios.
Para cada contrato, el proceso de compra es una secuencia de tres procesos:
licitación, seguimiento del contrato y cumplimentación del contrato, véase figura
1.4.
A continuación figuran orientaciones acerca de:
• el inicio del proceso de adquisición
• la conducción de un proceso de compra.
2.1 Inicio del proceso de adquisición

El inicio del proceso de adquisición es el primer proceso
que el responsable contractual del cliente ejecuta en una CC SC
CP SP
adquisición. Consiste en la definición del objetivo de la CS SS
adquisición y la planificación de la adquisición, véase figura
2.1. El resultado final es un plan de adquisición que refleja una estrategia de
adquisición y un claro entendimiento de las necesidades de sistemas y servicios que
definen el objetivo de la adquisición.
Interacciones En la práctica, la planificación de la adquisición revela siempre un cierto grado de
entre el análisis imprecisión en el objetivo de la adquisición, que precisa un análisis más detallado
de los requisitos de la adaptación y de los requisitos del servicio. Por tanto, se produce una
y la interacción continua entre la definición del objetivo de la adquisición (análisis de
planificación de
la adquisición los requisitos) y la planificación de la adquisición.
La viabilidad, programa y costes de la adquisición afectarán al propósito del
objetivo de la adquisición: ésta es otra característica de la interacción entre la

Capítulo 2
El proceso de adquisición
definición del objetivo de la adquisición y la planificación de la adquisición. La

figura 2.1 ilustra estas interacciones.
Necesidades del negocio

Definición aproximada del
objetivo de la adquisición
Inicio de la adquisición
Definición del objetivo Planificación de la

de la adquisición adquisición
Objetivo de la adquisición Plan de adquisición

(requisitos de sistemas y
servicios)
Figura 2.1: Inicio de la adquisición: productos y actividades.

El plan de adquisición es el factor de éxito más crítico de una adquisición. Lo más
probable es que una adquisición mal planificada fracase. Sin embargo, es posible
que incluso un buen plan experimente cambios durante el proceso de adquisición.
Hasta el propio objetivo puede modificarse durante este proceso. Por tanto, el
cliente tendrá que garantizar una gestión rigurosa de la versión del objetivo y del
plan de adquisición durante todo el proceso de adquisición.
En situaciones complejas e inciertas, el inicio de la adquisición es una tarea Las actividades
complicada que no puede llevarse a cabo como una secuencia estricta de no se realizan en
actividades. La secuencia de actividades descrita a continuación es un ejemplo. una secuencia
estricta
2.1.1 Definición del objetivo de la adquisición
Objetivo: Entender de forma suficientemente clara los requisitos de los sistemas y

servicios que conforman el objetivo de la adquisición.
Insumos: Necesidades del negocio, definición aproximada del objetivo de la
adquisición
Actividades:
1. Definir el dominio objetivo (posiblemente identificar subdominios).
2. Definir con mayor precisión el objetivo de la adquisición en términos de
requisitos de sistemas y servicios.
3. Analizar los costes y beneficios.
4. Analizar los intereses y a los interesados.
Productos: Objetivo de la adquisición

Figura 2.2: Actividades para definir el objetivo de la adquisición

(realizadas por el responsable contractual del cliente)2.
La finalidad de la definición del objetivo de la adquisición es producir un conjunto
coherente de requisitos de sistemas y servicios derivado de las necesidades
patentes del negocio y del objetivo preliminar de la adquisición, previo al inicio de
la adquisición. Los atributos importantes del objetivo de la adquisición que se
valorarán son: intereses, interesados, costes y beneficios.
La definición aproximada del objetivo de la adquisición puede derivarse, por
ejemplo, de un plan estratégico de negocio o de sistema de información.
Las actividades descritas en la figura 2.2 las realiza el responsable contractual del
cliente al definir el objetivo de una adquisición.
2.1.1.1 Definir el dominio objetivo (posiblemente

identificar subdominios) Definir el
dominio objetivo
El dominio objetivo de la adquisición (véase apartado 1.2) tiene con precisión
que definirse con precisión. Una definición incorrecta del mismo
puede comportar consecuencias adversas, tales como:
• no se identifican las interfaces adecuadas con otros sistemas
• no se identifican todos los agentes afectados por la adquisición
• no se calculan de forma adecuada los costes y beneficios de la adquisición
• no se identifican todos los riesgos relevantes
No siempre es sencillo relacionar las necesidades del negocio con un dominio
objetivo formalmente definido.
A
En el caso de una adaptación (por ejemplo, una adaptación del sistema de
información), puede que resulte difícil trazar los límites de la zona de repercusión
de la adaptación, ya que puede ser mayor que la organización en cuestión e incluir
a los clientes de esa organización, otros proveedores, etc. A
S
En cuanto a los servicios, es preciso determinar qué procesos deben
contratarse. Entre las consideraciones que afectan a estas decisiones se encuentran:
los costes previstos, beneficios económicos, pericia disponible, dependencia de
proveedores, pérdida de cualificaciones, flexibilidad. S
2 Estas actividades suelen realizarse en paralelo, existiendo interacciones entre ellas e

iteraciones de las mismas.

Capítulo 2
Si el dominio objetivo es complejo, vale la pena desglosarlo en subdominios, que

Pueden utilizarse
posteriormente pueden utilizarse para desglosar la adquisición en partes más subdominios
pequeñas y sencillas de gestionar. para desglosar la
Si la definición del dominio objetivo no es suficientemente precisa, se recomienda adquisición en
partes más
llevar a cabo un análisis de las necesidades, véase la siguiente actividad. sencillas de
gestionar
2.1.1.2 Definir con mayor precisión el objetivo de la adquisición
El objetivo de la adquisición no siempre se ha definido con la precisión suficiente Definir las

antes del inicio de la adquisición. La definición del objetivo de la adquisición debe necesidades con
identificar los entregables y servicios necesarios y definir sus requisitos: precisión
suficiente
• A
descripciones de sistemas:
− elementos descriptivos de los requisitos de los elementos operativos (el
resultado del análisis de requisitos) A
• S
descripciones de los servicios:
− elementos descriptivos de los requisitos de los servicios
(þ 5.1, Descripción de los servicios). S
En la práctica es difícil evaluar en qué momento el nivel de precisión llega a ser Experimentar
suficiente. Muchas veces el cliente se da cuenta de que los requisitos de los con el nivel de
sistemas y servicios son insuficientes para determinar los costes, beneficios y detalle de los
riesgos de la adquisición. También pueden ser insuficientes para la planificación de requisitos
la adquisición o la redacción de un documento de petición de ofertas. Asimismo,
también pueden ser insuficientes para que los proveedores potenciales presenten
sus ofertas.
Cuando es preciso definir con mayor claridad el objetivo de la adquisición, se
recomienda realizar un análisis de requisitos utilizando un método apropiado para
ello, por ejemplo un método de reingeniería de procesos de negocio o un método
de análisis de requisitos de un sistema de información.
En realidad, reducir el alcance del objetivo de la adquisición no es una opción que La modificación
pueda contemplar el responsable contractual. Así pues, cualquier modificación del del alcance se
alcance deberá ser gestionada al nivel de alta dirección de la organización. En gestiona en el
primer lugar habrá que reducir los riesgos, véase planificación de la adquisición. Si nivel de alta
dirección
falla algún medio de reducción de riesgos, probablemente será necesario revisar la
estrategia del SI y que en el nivel de alta dirección se tome decisión de revisar el
objetivo de la adquisición.
2.1.1.3 Analizar costes y beneficios
Los costes y beneficios de la adquisición deben evaluarse a nivel organizativo. Es Evaluar los
preciso hacer hincapié en que la incertidumbre de los requisitos de sistemas y costes y
servicios siempre da lugar a unas estimaciones poco fiables. Puede que la beneficios
definición aproximada del objetivo de la adquisición ya incluya una aproximación a
los costes y beneficios, aunque si es preciso éstos deberán analizarse y
documentarse con mayor profundidad mediante este proceso.

Los beneficios dependen principalmente de los requisitos de los sistemas y

Considerar una
adquisición
servicios y de su fecha de entrega. Es preciso identificar todos los beneficios,
como una incluyendo los que no se pueden cuantificar. En la medida de lo posible, habrá que
inversión evaluar los beneficios en términos financieros o en términos cuantificables
utilizando unidades. La evaluación de los beneficios debe considerarse una
inversión de la organización del cliente y basarse en los métodos y prácticas
disponibles. La identificación de los beneficios también puede basarse en analogías
con adquisiciones similares en organizaciones similares.
Los costes dependerán, además de otros factores, de los requisitos de sistemas y
servicios y de la estrategia de adquisición, véase Planificación de la adquisición.
Identificar los Es importante identificar todos los costes relacionados con la adquisición y no sólo
costes de todos los relativos a la compra de soportes físicos y al desarrollo de soportes lógicos.
los procesos Otros ejemplos de costes son: gestión de la adquisición, gestión del proyecto y del
necesarios servicio, aseguramiento de la calidad, preparación de los datos de prueba,
formación, instalación del sistema y del servicio. La relación de procesos de la
norma ISO sobre Procesos del Ciclo Vital [ISO-LCP] puede utilizarse como lista
de comprobación de las actividades que pueden plantearse en una adquisición.
2.1.1.4 Analizar los intereses y a los interesados
Identificar y Los interesados son aquellos agentes a quienes afecta la adquisición y que
anunciar los determinarán el éxito o el fracaso de la misma. Estos agentes deben ser
beneficios a identificados y sus intereses satisfechos. Es preciso clarificar y anunciar los
todos los beneficios de la adquisición. Si un agente no percibe ningún beneficio es probable
interesados
que mantenga una actitud negativa frente a la adquisición.
Puede realizarse un análisis para identificar los lados fuertes, los puntos débiles, las
oportunidades y las amenazas de la adquisición para cada agente (lo que en inglés
se denomina un análisis SWOT). Éste es un importante insumo del análisis de
riesgos.

Capítulo 2
2.1.2 Planificación de la adquisición
Objetivo: Definir una estrategia de adquisición adaptada a la situación, planificar

los principales puntos de decisión de la adquisición y establecer la organización de la
adquisición.
Insumos: Definición del objetivo de la adquisición (requisitos del sistema y del
servicio).
Actividades:
1. Determinar los escenarios generales de las adaptaciones y prestaciones de
servicios.
2. Analizar los riesgos.
3. Diseñar una estrategia de adquisición en el marco de la gestión de riesgos:
3.1
• Decidir el cambio de varios factores de situación.
• Decidir el cambio o puntualización de los requisitos antes de la
licitación.
• Decidir la estrategia con respecto a las normas.
3.2.
• Decidir los tipos de proveedores: internos o externos.
• Determinar los tipos de licitación (abierta, restringida, negociada).
• Determinar el tipo de relación con los proveedores (licitación en una fase,
en varias fases).
• Determinar la flexibilidad de los contratos (capacidad para modificarlos o
puntualizarlos).
3.3.
• Identificar los contratos y los imperativos de secuencia (uno o varios
contratos).
3.4.
• A
Decidir si comprar o desarrollar. A
• A
Determinar los requisitos de la estrategia de adaptación. A
3.5.
• S
Determinar el tipo de mecanismo del servicio. S
• S
Determinar los requisitos de la estrategia de prestación del servicio.
S
4. Planificar los principales puntos de decisión de la adquisición.

5. Establecer la organización del cliente dentro de la adquisición
(por ejemplo, decidir si se utiliza ayuda externa para la gestión de la
adquisición).
Productos: Plan de adquisición, inclusive una estrategia de adquisición.

Figura 2.3: Actividades encaminadas a elaborar un plan de adquisición

(realizadas por el responsable contractual del cliente)3.
3 Estas actividades suelen wejecutarse en paralelo, existiendo interacciones entre ellas e

iteraciones de las mismas.

Capítulo 2
La planificación de la adquisición comenzará por determinar los escenarios

generales de las adaptaciones y del plan de prestación de servicios, para analizar
posteriormente los riesgos y diseñar una estrategia de adquisición en el marco de la
gestión de riesgos y, finalmente, planificar los principales puntos de decisión de la
adquisición y establecer la organización de la adquisición.
Las actividades descritas en la figura 2.3 las lleva a cabo el responsable contractual
del cliente al elaborar un plan de adquisición.
2.1.2.1 Determinar los escenarios generales de las adaptaciones y las

prestaciones de servicios
Una vez se ha definido el objetivo de la adquisición (requisitos de los sistemas y Elaborar los
servicios, costes, beneficios, etc.), el responsable contractual del cliente tiene que escenarios de
planificar las entregas de las adaptaciones y prestaciones de servicios a nivel global. acuerdo con las
Los escenarios globales de las adaptaciones y del plan de prestación de servicios prioridades y las
dependencias
dependen de las prioridades y las dependencias entre las entregas. entre las entregas
Estas dependencias pueden ser:
• técnicas (por ejemplo, puede que sea preciso adquirir soportes físicos antes
de la instalación del software)
• funcionales (por ejemplo, es necesario desarrollar un SI de gestión del cliente
antes que una base de datos que proporcione estadísticas acerca de clientes)
• relativas a la reutilización (por ejemplo, el desarrollo de objetos reutilizables
deberá preceder al desarrollo de sistemas que los van a utilizar).
Las prioridades pueden ser:
• estratégicas (por ejemplo, cierta aplicación proporcionará una ventaja
competitiva)
• económicas (por ejemplo, una adaptación del sistema de información
reducirá los costes operativos de una función)
• políticas (por ejemplo, cierto departamento se encuentra en una posición más
fuerte que otro, por lo que sus peticiones se consideran más importantes).
Pueden generarse varios escenarios de planificación, que se evaluarán y utilizarán
al diseñar la estrategia de adquisición, para garantizar que el plan de adquisición
tenga en cuenta las principales prioridades y dependencias.
2.1.2.2 Analizar los riesgos
Es preciso analizar la situación para identificar los riesgos que intervienen en la Analizar la
adquisición. situación
Definición Un riesgo es la posibilidad de exposición a las consecuencias

adversas de sucesos futuros.
Los factores situacionales son aquellas particularidades de la situación que generan

riesgos y que deben tenerse en cuenta al diseñar la estrategia de adquisición.

Eurométodo proporciona una lista de comprobación de los factores situacionales y

orientaciones para valorarlos. A (þ 4.2.2-3: Valorar los factores situacionales,
Evaluar la incertidumbre y complejidad generales) A
S S
(þ 5.2.1.3: Documentar la apreciación de la situación)
El análisis de Puede que algunos de estos factores situacionales no sean relevantes durante el
riesgos deberá inicio de la adquisición, cuando sólo se toman en consideración las cuestiones más
adaptarse a la estratégicas: probablemente adquieran relevancia cuando se planifiquen con mayor
situación y detalle adaptaciones específicas y prestaciones de servicios durante los procesos de
reiterarse
durante la
licitación. En ocasiones, los factores situacionales sólo se pueden valorar bajo
adquisición ciertos supuestos, como por ejemplo la disponibilidad de tecnología de desarrollo o
la capacidad del equipo de proyecto. La situación cambiará con el tiempo y puede
que también haya que cambiar los supuestos, por ejemplo habrá que volver a
valorar la capacidad del equipo de proyecto cuando se seleccione la tecnología
utilizada y las modalidades de adaptación. Así pues, será necesario repetir el
análisis de riesgos periódicamente en el transcurso de la adquisición.
Identificar la Eurométodo proporciona orientaciones para evaluar la probabilidad de riesgos,
probabilidad y el pero no para valorar la magnitud de su impacto negativo (consecuencias adversas),
impacto de los que está fuertemente relacionada con la naturaleza y especificidad de la
riesgos organización del dominio objetivo. La magnitud del impacto negativo debe
valorarse desde una perspectiva de negocio: supervivencia, funcionamiento
efectivo y evolución de la organización del dominio objetivo. En algunos casos, la
repercusión se puede valorar en términos económicos (costes, oportunidades
perdidas, etc.).
A
(þ4.2.4-5: Analizar la probabilidad de riesgos, Identificar los riesgos críticos)
A
S S
(þ 5.2.1.3: Documentar la apreciación de la situación)
El análisis de riesgos es una parte de la gestión de riesgos, como muestra la figura
2.4.

Capítulo 2
Análisis de Riesgos
Análisis de la Identificación de
Situación Factores riesgos
situación
situacionales
Probabilidad e
Probabilidad de Análisis de impacto impacto de los
riesgos riesgos
Diseñar la estrategia de gestión de riesgos
Seleccionar
contramedidas para Contramedidas
los factores para los factores
situacionales situacionales
Seleccionar la
estrategia de la Estrategia de
adaptación adaptación
Seleccionar
opciones
Seleccionar la
estrategia de Estrategia de
provisión de provisión de
servicios servicios
Seleccionar otras
opciones de la Otras opciones de
adquisición la adquisición
Figura 2.4: Análisis de riesgos y diseño de la estrategia de gestión de riesgos

dentro de la planificación de la adquisición
2.1.2.3 Diseñar la estrategia de adquisición
La gestión de riesgos se compone del análisis de riesgos, la planificación de la

gestión de riesgos y el seguimiento de riesgos. El tema del análisis de riesgos ya se
ha tratado anteriormente. Un plan de gestión de riesgos deberá reflejar una
estrategia de gestión de riesgos que represente la selección entre diferentes
opciones al objeto de reducir la probabilidad y las repercusiones de los riesgos,
véase figura 2.4. En este apartado se considerará el diseño de una estrategia de
gestión de riesgos como clave para el diseño de la estrategia de adquisición.
El contexto de una gestión de riesgos se caracteriza por el conjunto de opciones
disponibles para la gestión del riesgo. No todas las opciones están abiertas para el
responsable contractual del cliente, sino que algunas pueden estar sometidas a
imperativos y políticas a nivel organizativo. Por ejemplo, las administraciones
públicas tienen que aplicar los reglamentos nacionales e internacionales en materia
de compras públicas.

La figura 2.5 presenta los distintos tipos de opciones de la estrategia de

adquisición. El texto subsiguiente proporciona orientación acerca de las diferentes
opciones. La figura 2.5 indica los niveles facultados para seleccionar las distintas
opciones: niveles de organización, adquisición, contrato, proyecto/servicio.
Nivel de gestión Organización Adquisición Contrato Proyecto/

Servicio
Opción de gestión de riesgos
1 Cambiar los factores de situación x x o o
Cambiar o puntualizar los x x x x
requisitos
Estrategia con respecto a las x x
normas
2 Proveedores internos o externos x x o o
Tipos de licitación x x
Interacciones con los proveedores x x
Flexibilidad de los contratos x x x o
3 Uno o varios contratos x x
A Comprar o desarrollar x x o
4
Enfoque de la instalación del x x
sistema
Enfoque de la construcción del x x
sistema
Enfoque de la descripción x x x
A Enfoque del control del proyecto x x x x
5 S Tipos de mecanismos de servicio x x
Enfoque de la instalación del x x x

servicio
Enfoque de retirada del servicio x x x
S Enfoque de control del servicio x x x x
Figura 2.5: Opciones de gestión de riesgos y niveles de gestión en los que aquellas
pueden estar abiertas a una decisión4.
Por regla general, el nivel de gestión podrá tomar decisiones relativas a una opción
si las consecuencias de sus decisiones no repercutirán fuera de su esfera de acción.
4 Una casilla con una ‘x’ indica que la selección de la opción se realiza en ese nivel en
muchas organizaciones. Una ‘o’ indica que en algunas organizaciones esa opción puede
seleccionarse en ese nivel. Cuando aparecen varias cruces en relación a un tipo de opción,
significa que será la política particular de cada organización la que determine el nivel
apropiado.

Capítulo 2
Por ejemplo, un proyecto sólo podrá tomar decisiones relativas a una opción si las
consecuencias de estas decisiones no afectan a otros proyectos. Si sucede que es
preciso tomar decisiones relativas a una opción, y no se está en el nivel apropiado
para ello, probablemente será el síntoma de que la adquisición se encuentra ante un
grave problema.
Tomando como insumos los escenarios de planificación y el análisis de riesgos, se Seleccionar las
pueden elaborar varios escenarios estratégicos, cada uno de los cuales dará como opciones
resultado un conjunto de opciones seleccionadas. El responsable contractual del
cliente deberá seleccionar las opciones, en base a:
• la eficiencia de la opción
• el coste (y dificultad) de la opción
• el retraso de la obtención de los resultados.
El responsable contractual del cliente deberá comprobar si las opciones Comprobar si las
seleccionadas son suficientes para reducir los distintos riesgos, y si son coherentes opciones reducen
entre sí. Normalmente, una opción contempla varios riesgos (por ejemplo, un los riesgos y su
enfoque de instalación evolutivo contempla la mayoría de riesgos relativos a la coherencia
global
incertidumbre de la situación). Para cada estrategia se recomienda confeccionar
una matriz que relacione los riesgos identificados con las opciones seleccionadas
que los abordan (véase figura 2.6) y comprobar que se han abordado todos los
riesgos. Las opciones pueden conllevar sus propios riesgos, los cuales deberán ser
analizados (probabilidad y repercusión) e incluidos en la matriz.
Opción Opción 1 Opción 2 Opción 3 Opción 4 …
Riesgo
Riesgo 1 x
Riesgo 2 x
Riesgo 3 x x
Riesgo 4 x
Riesgo 5 x
.....
Figura 2.6: Ejemplo de una matriz que relaciona las opciones seleccionadas con los
riesgos.
Esta matriz resume la estrategia de gestión de riesgos.
Los escenarios estratégicos deberán considerarse a la luz de su eficiencia, sus
costes y el retraso en obtener resultados. Seguidamente se selecciona la estrategia
más adecuada de gestión de riesgos como base de la planificación y organización
de la adquisición.
A continuación se explican las diferentes opciones y se formulan algunas

orientaciones de cara a su selección.

Opción: Decidir el cambio de varios factores de situación

En el capítulo 4 El análisis de la situación puede revelar factores situacionales cuyos valores
figuran ejemplos indiquen un alto grado de incertidumbre o complejidad. Puede que algunos de
de estos factores sean difíciles de cambiar por ser inherentes al problema. No
contramedidas a obstante, puede que exista alguna posibilidad de mejorar otros factores antes de
factores
situacionales iniciar una compra. En el capítulo 4 figura una lista de las posibles medidas para
cambiar valores específicos de factores situacionales. Las explicaciones que
fundamentan los valores otorgados a los factores situacionales pueden reflejar tales
posibilidades de mejora.
(þ 4.3.1: Seleccionar contramedidas)
Ejemplo • Formación de las personas que participarán en la

adaptación del SI como agentes del mismo, si se considera
que su capacidad o motivación son bajas.
• Uso de asesoría externa si se considera que la capacidad de
los agentes del SI es baja y no hay posibilidad de
mejorarla.
Opción: Decidir el cambio o puntualización de los requisitos antes de la

licitación
Los requisitos se pueden puntualizar o modificar en distintos niveles de gestión, en
función de los siguientes criterios: el nivel de detalle del requisito en cuestión, el
alcance de la repercusión de la modificación de los requisitos y el nivel estratégico
del requisito en cuestión (por ejemplo, se puede decidir acerca de los requisitos
ergonómicos en el nivel de proyecto, o adoptar una decisión al respecto en el nivel
organizativo, si ello se considera apropiado desde un punto de vista estratégico).
Seleccionar el En el nivel de adquisición, si se considera que los requisitos del sistema y del
nivel de detalle servicio no son suficientes para realizar la adquisición porque introducen en el
apropiado de los proceso una incertidumbre ingestionable, podrá llevarse a cabo un análisis más
requisitos estricto de los requisitos antes de la licitación. Además de eliminar la
incertidumbre, este análisis mejorará las descripciones de los servicios o los estados
iniciales de cualquier adaptación posterior.
S
Puede iniciarse una adaptación con la finalidad de producir descripciones de los
servicios antes de solicitar ofertas de prestación de servicios. El propósito de
producir descripciones de los servicios es:
• comprender el proceso/servicio actual
• entender perfectamente el tipo de servicio que se solicita, los motivos para
contratar ese servicio y los principales problemas e imperativos
• ser capaz de supervisar el servicio contratado. S
Si la organización del cliente no es capaz de realizar esa tarea (por ejemplo, debido
a la falta de recursos o de capacidad), la puede encargar a un proveedor.

Capítulo 2
Resumen • Procede encargar un análisis de requisitos cuando la

disponibilidad o claridad de los requisitos es baja y la
capacidad del equipo de adquisición del cliente es baja.
Opción: Decidir la estrategia con respecto a las normas

La decisión de aplicar las normas se suele tomar a nivel organizativo. En las
administraciones públicas es preciso aplicar la Decisión sobre Normas de la CE si
el ‘responsable contractual’ (el cliente) adquiere la propiedad de unos productos
que entran dentro del ámbito de aplicación de dicha Decisión. Tal Decisión sobre
Normas no afecta a aquellos productos que permanecen en propiedad del
proveedor [87/95/CEE].
Los motivos para utilizar las normas son: garantizar que las soluciones sean ¿Por qué utilizar
abiertas, evitar limitarse a un único proveedor y solución, maximizar la normas?
interoperabilidad de los sistemas y utilizar un lenguaje común universal para
expresar los requisitos y las soluciones.
Por regla general, el responsable contractual del cliente tendrá que determinar qué
normas son aplicables en la adquisición prevista y cómo deben aplicarse. Conviene
facilitar orientaciones a este respecto a nivel organizativo. Las guías EPHOS
[EPHOS] también ayudan a orientarse.
Opción: Determinar los tipos de proveedores: internos o externos

Los proveedores pueden ser internos o externos a la organización del cliente. En
algunos casos, la selección viene limitada por los imperativos de una política
organizativa.
Procede utilizar proveedores externos si: ¿Cuándo utilizar
proveedores
• la capacidad del equipo de proyecto del cliente es baja (por ejemplo, el externos?
equipo del cliente no posee experiencia, hay pocos expertos en SI, el equipo
se dedica al mantenimiento de sistemas ya existentes, se requieren
conocimientos técnicos especiales, se precisa una elevada flexibilidad en la
asignación de recursos)
• existe el riesgo de que aumente el coste del proyecto y se produzcan retrasos
en la entrega: puede ser útil obtener algún compromiso por parte de los
proveedores externos (en especial mediante contratos a precio fijo)
• la novedad del objetivo o de la tecnología de desarrollo precisan una pericia
que sólo se puede hallar en el exterior
• la pronunciada heterogeneidad de los agentes o su actitud negativa exige la
intervención de un tercero, que se considera neutral, en el juego político de la
organización
• S
la contratación de servicios produce algún beneficio, véase apartado 5.1:
Descripción de los servicios (propiedades de la inversión). S

Opción: Determinar los tipos de licitación
La Directiva de Servicios de la CE (92/50/CEE) define cuatro procedimientos de

adjudicación:
• procedimiento abierto: en el que todos los proveedores interesados pueden
presentar una oferta
• procedimiento restringido: en el que sólo pueden presentar una oferta
aquellos proveedores que hayan sido invitados por el responsable contractual
del cliente; este conjunto de proveedores candidatos puede determinarse a
partir de los conocimientos sobre el mercado que posea el cliente, a partir de
un estudio de mercado o mediante una preselección a través de una
convocatoria
• procedimiento negociado: en el que el responsable contractual del cliente
consulta a los proveedores que él seleccione y negocia los términos del
contrato con uno o más de ellos
• concurso de diseños: en el que el responsable contractual del cliente adquiere
un plan o diseño seleccionado por un jurado en un concurso que puede o no
otorgar premios.
La Directiva de Servicios estipula reglas para la elección de un proceso de
adjudicación. En las compras dirigidas por ‘responsables contractuales’ públicos y
otras organizaciones a quienes afecte la Directiva (los clientes), sólo podrá
utilizarse el procedimiento negociado antes que el procedimiento abierto o el
restringido si se cumplen las circunstancias que establece la Directiva y que
permiten su uso, por ejemplo, cuando debido a la existencia de derechos exclusivos
sólo un proveedor puede ejecutar las adaptaciones o prestar los servicios.
Los Incluso para aquellas organizaciones que no estén sujetas a la Directiva de
procedimientos Servicios y a sus transposiciones a nivel nacional, la situación normal debería ser el
abiertos o procedimiento abierto o restringido, que permiten al cliente extraer el máximo
restringidos beneficio de un mercado competitivo. El procedimiento negociado sólo deberá
suponen el
máximo
utilizarse cuando la incertidumbre de la situación dificulte la determinación de los
beneficio para el requisitos de los sistemas y servicios (por ejemplo, estimar los costes), cuando la
mercado selección de los posibles proveedores se vea restringida por la propia naturaleza
competitivo del problema o cuando la urgencia dificulte el uso de un proceso de licitación más
formal.
Opción: Determinar el tipo de relación con los proveedores

En situaciones complejas o inciertas, una manera de mejorar la situación actual
antes de presentar la petición de ofertas es recabar información por anticipado
acerca de los proveedores potenciales, lo que no siempre está permitido por los
reglamentos públicos. No obstante, estos ejercicios más complejos se pueden
considerar un proceso de licitación en el que se introducen iteraciones,

Capítulo 2
denominado proceso de licitación multifásico. Los ejemplos siguientes ilustran

estos escenarios.
Ejemplos: • Se puede elaborar una lista reducida de proveedores en base a

la evaluación de miniofertas incluidas dentro de las ofertas
que se reciben en una petición de ofertas.
Las miniofertas están menos elaboradas que las ofertas
completas y permiten a los proveedores a quienes no se va a
adjudicar el contrato reducir los costes de su participación en
el proceso de licitación. A continuación se solicita una oferta
completa a los proveedores que forman parte de esta lista
reducida.
En este ejemplo, el proceso de licitación se compone de una

primera fase que incluye la preparación de la petición de
ofertas, preparación de las ofertas y selección del proveedor;
y posteriormente una segunda fase que incluye la preparación
de la petición de ofertas, preparación de las ofertas, selección
del proveedor y preparación del contrato.
• Se puede elaborar una lista reducida de proveedores en base a

una evaluación de las ofertas que se reciben tras una petición
de ofertas. A continuación el cliente contrata y financia a los
proveedores seleccionados para que realicen un estudio de la
compra del sistema, investigando y desarrollando distintos
aspectos de la solución que propongan. Posteriormente, estas
ofertas, mejor definidas, son valoradas por el cliente, que
selecciona la mejor y adjudica el contrato al proveedor
correspondiente.
En este ejemplo, el proceso de licitación se compone de una

primera minifase de compra que incluye la preparación de la
petición de ofertas, preparación de las ofertas, selección del
proveedor, preparación del contrato, seguimiento del contrato
y cumplimentación del contrato; y posteriormente una
segunda fase, que incluye la preparación de las ofertas,
selección del proveedor y preparación del contrato.
• Los escenarios anteriores se pueden combinar en un proceso

de licitación en tres fases.
Los procesos de licitación en varias fases proporcionan al cliente información

adicional acerca de la adaptación o prestación de servicios previstas. En
consecuencia, disminuirá la incertidumbre y mejorarán las descripciones de los
servicios o el estado inicial de la adaptación, posiblemente en grado suficiente para
permitir su gestión. Un inconveniente es que este tipo de procesos es mucho más
lento que los procesos de licitación monofásicos, por lo que no resulta adecuado
cuando el calendario es muy apretado.

Por regla general, las condiciones en que puede utilizarse la licitación en varias
fases se regulan a nivel organizativo (por ejemplo, los reglamentos de compra
pública). Durante la licitación, el cliente deberá garantizar que todos los
proveedores reciben el mismo trato y que ninguno de ellos obtiene una ventaja
competitiva injusta al tener acceso a más información que el resto. También se
recomienda que el cliente financie a los proveedores, ya que la finalidad de su
trabajo dentro del proceso de licitación en varias fases es contribuir a un mejor
entendimiento del problema por parte del cliente.
Resumen: • Un proceso de licitación multifásico es apropiado cuando

la incertidumbre y/o complejidad son elevadas y no existe
un calendario apretado.
Opción: Determinar la flexibilidad de los contratos

La flexibilidad de un contrato es la capacidad para modificar o puntualizar ciertos
elementos contractuales, tales como los requisitos de sistemas y servicios, los
costes y el calendario, durante el proceso de seguimiento del contrato. Puede que
estos elementos no se hayan definido con total claridad al firmar el contrato y se
deban puntualizar o revisar en el transcurso del contrato.
En el plan de entregas que planifica el proceso de supervisión del contrato, la
modificación o puntualización de los elementos contractuales se lleva a cabo
mediante puntos de decisión de inversión. Básicamente, una decisión de inversión
determina si se debe o no invertir en modificar una organización o un sistema de
información (consultar apartado 4.4).
Planificar el Estos puntos de decisión de inversión deberán determinarse y planificarse antes o
control de los al inicio del proceso de licitación. De otro modo, existe el riesgo de que se
cambios produzcan cambios contractuales no controlados durante la supervisión del
contractuales contrato. En otras palabras, cualquier procedimiento y condición para cambiar o
puntualizar los elementos contractuales, por ejemplo los requisitos y el calendario y
su repercusión en los costes, deberán definirse perfectamente en el contrato.
Los contratos flexibles no suelen fijar un precio de manera estricta: deberá ser
posible volver a determinar el precio. El precio deberá poder aumentarse o
disminuirse en los puntos de decisión de inversión, para ajustarlo mediante unos
procedimientos y parámetros (por ejemplo, costes de puntos de función, costes de
mano de obra, carga de trabajo, capacidad, costes de los recursos) que se han
fijado en el contrato. En general, se acuerdan los límites inferior y superior del
precio al objeto de proteger al cliente y al proveedor del riesgo de costes
impredecibles derivados de la ejecución del proyecto/prestación del servicio.

Capítulo 2
Importante: • Flexibilidad no significa falta de control.

La posibilidad de aplicar contratos flexibles se determina a nivel organizativo.
Normalmente las condiciones en que son aplicables se definen de manera estricta a
nivel organizativo (por ejemplo, mediante reglamentos nacionales para
administraciones públicas).
Cuando el responsable contractual del cliente puede utilizarlos, los contratos
flexibles suponen una manera de gestionar la incertidumbre sin tener que cambiar
de proveedores en el transcurso de la adquisición o programar secuencias de
contratos, lo que prolonga el proceso e incrementa los costes.
Resumen: • Los contratos flexibles son apropiados cuando la

incertidumbre es elevada y existe un calendario apretado.
Opción: Identificar contratos e imperativos de secuencia (uno o varios contratos)

El responsable contractual del cliente deberá decidir si conviene o no realizar la
adquisición mediante uno o varios contratos ejecutados en paralelo o
sucesivamente.
Esta decisión puede verse influenciada por dos factores.
• Los imperativos del reglamento interno de la organización pueden motivar la
elección de una cierta serie de contratos (por ejemplo, limitaciones
presupuestarias de contratos o años fiscales, necesidad de utilizar contratos
con un precio fijo).
• Depende de la incertidumbre de la situación; el uso de una serie de contratos ¿Cuándo utilizar
en lugar de un único contrato puede: una serie de
− proporcionar la flexibilidad necesaria para la clarificación y evolución de contratos?
los requisitos de sistemas y servicios de acuerdo con las necesidades del
negocio en el transcurso de la adquisición: esto resulta especialmente útil
cuando la claridad, disponibilidad y estabilidad de los requisitos es baja, y
en general en todas las situaciones inciertas en las que existe el riesgo de
evolución de los requisitos.
− proporcionar al cliente un medio para controlar los costes, incluso aunque
éstos no sean totalmente predecibles al inicio de la adquisición: ello
resulta útil en todas las situaciones inciertas en las que existe el riesgo de
que surjan costes impredecibles para la organización, el proyecto o la
prestación del servicio.
Si el responsable contractual del cliente decide utilizar una serie de contratos, o los
imperativos le obligan a ello, podrá llevar a cabo la licitación de cada uno de ellos
describiendo cada compra en términos de su plan de entregas.
CC SC
CP SP
CS SS
A
A continuación se aborda con mayor detalle la cuestión de las relaciones entre
las adaptaciones de SI y la secuencia de contratos.

La experiencia demuestra que ciertas combinaciones de estado inicial y estado final

tienden a dar como resultado proyectos difíciles de controlar. Ello se debe
¿Cómo gestionar principalmente a que el estado inicial no se elabora lo suficiente al objeto de reducir
un estado inicial las incertidumbres, que deben ir resolviéndose a medida que se avanza hacia el
insuficiente? estado final. Se pueden utilizar distintas estrategias para gestionar estas
incertidumbres:
Utilizar • Los enfoques de instalación o construcción evolutivos (véase Opción:
contratos Determinar los requisitos de la estrategia de adaptación) permiten la
flexibles clarificación progresiva de los requisitos en base a la utilización o ensayo de
las sucesivas versiones del SI; un único contrato puede contemplar varias
versiones del SI si las cláusulas contractuales son suficientemente flexibles
como para puntualizar los requisitos y costes durante la vida del contrato; de
no ser así, podrá utilizarse una serie de contratos, cada uno de los cuales se
referirá a una versión del SI.
División en • Si se utilizan las modalidades de instalación o construcción de una vez o
varios contratos incremental, podrá dividirse la adquisición en una secuencia de contratos,
cada uno de los cuales ayudará a reducir las incertidumbres: su estado final
se utilizará como estado inicial del siguiente contrato; en otras palabras, cada
contrato proporciona un mayor conocimiento de los requisitos del SI, los
costes y los planes futuros para sucesivas adaptaciones y contratos.
En el caso de una serie de contratos de adaptación, normalmente el estado inicial
de cada adaptación se puede derivar directamente del estado final de la adaptación
anterior. Este escenario queda representado en la figura 2.7.
Sistema de Sistema de
Un solo contrato
Información Información
Actual / / / / Deseado
Licitación Seguimiento Finalización
Múltiples contratos
/ / / / / / /
Licitación Seguimiento Finalización Licitación Seguimiento Finalización
Objetivo de la
adquisición
Figura 2.7: Consecución del objetivo de la adquisición mediante un único contrato

o mediante varios contratos de adaptación.

Capítulo 2
A pesar de que cada adaptación del sistema de información se encarga de resolver

un problema concreto, se observa un conjunto de estados iniciales y finales típicos
que apoyan la secuencia de los contratos de adaptación. Los estados
iniciales y
La noción de estados finales típicos indica que existen ciertas combinaciones de finales típicos
entregables que suelen aparecer como estados finales de una adaptación del SI. pueden apoyar la
Ello se debe a que globalmente proporcionan un resultado útil a un cliente. secuencia de los
contratos
La noción de estados iniciales típicos indica que existen ciertas combinaciones de
un SI de un cliente y de sus elementos descriptivos asociados que normalmente se
encuentran al inicio de una adaptación del SI.
Las figuras 2.8 y 2.9 contienen descripciones abreviadas de los estados iniciales y
finales típicos. En el anexo A figuran descripciones más detalladas, además de los
perfiles de los entregables de los estados iniciales y finales típicos. En el apartado
3.6 aparecen descripciones de los entregables del dominio objetivo.
Algunos de los estados iniciales y finales típicos consisten en combinaciones
similares de entregables. En este caso se da el mismo nombre al estado inicial típico
y al estado final típico.
N.B. Los estados iniciales y finales típicos simplemente proporcionan ejemplos de puntos
iniciales y finales de adaptaciones de SI. No recomiendan una secuencia de puntos de
decisión dentro de una única adaptación del SI. Por este motivo se utiliza siempre la
expresión ‘estados iniciales y finales típicos’ y se evita cualquier forma abreviada de la
misma, ya que podría transmitir una impresión incorrecta.

Estado final típico Finalidad Entregables del dominio objetivo

Documentación del sistema Que la documentación llegue a una Elementos descriptivos detallados que se
de información situación en que pueda servir de insumo refieren a las prácticas de trabajo y la
útil para posteriores adaptaciones del SI; o arquitectura del CS del SI actualmente
Resolver incertidumbres debidas a un operativo.
escaso conocimiento del sistema
informático (CS) o del SI existente.
Análisis de cambios del SI Proporcionar documentación de apoyo a Elementos descriptivos globales que se
las decisiones, por ejemplo para cambios refieren a las visiones de los procesos del
de las prácticas de trabajo. negocio, de la información del negocio y de
El SI actual no experimenta ningún las prácticas de trabajo.
cambio.
Análisis de cambios del CS Proporcionar documentación de apoyo a Elementos descriptivos globales que se
las decisiones, por ejemplo para refieren a las visiones de los procesos de
inversiones en soportes físicos del CS o en negocio, de la información del negocio, de
software de aplicación. las prácticas de trabajo y de la arquitectura
El SI actual no experimenta ningún del CS.
cambio.
Diseño detallado del negocio Elementos descriptivos detallados que
contemplan las visiones de la información
Proporcionar documentación de apoyo a
del negocio, de los procesos del negocio y
las decisiones y documentos de entrada
de las prácticas de trabajo de una nueva
para posibles adaptaciones posteriores del
versión del SI.
SI. Con ello representa al mismo tiempo
un estado inicial típico de una adaptación Elementos descriptivos globales que se
del SI; y un posible punto de división de refieren a los datos, las funciones y la
una adaptación del SI en varias otras. arquitectura del CS, e ilustran la viabilidad
del diseño de negocio detallado.
Diseño técnico detallado El SI actual no experimenta ningún Elementos descriptivos detallados que se
cambio. refieren a las prácticas de trabajo y a los
datos, funciones y arquitectura del CS de
una nueva versión del SI.
SI probado Se construye y se prueba una nueva Elementos operativos de una nueva versión
versión del SI, que sólo tiene que del SI, que pueden sustituir a varios o a
instalarse en el dominio objetivo. Suele todos los elementos operativos del SI
aparecer, por ejemplo, cuando la actualmente operativo.
instalación del CS es tan compleja que
Elementos descriptivos detallados de las
debe gestionarse como una adaptación
prácticas de trabajo y de la arquitectura del
aparte del SI, o cuando la naturaleza de
CS de la nueva versión del SI.
los cambios organizativos del dominio
objetivo aconseje al cliente llevarlos a
cabo internamente.
El SI actual no experimenta ningún
cambio.
SI instalado Cambiar el SI para satisfacer las Una nueva versión operativa del SI, en la
necesidades del negocio seleccionadas. que varios o todos los elementos operativos
Asimismo, se produce la documentación son sustituidos por otros nuevos.
de diseño de la nueva versión del SI para Elementos descriptivos detallados de las
apoyar su mantenimiento y desarrollo prácticas de trabajo y de la arquitectura del
adicional. CS de la nueva versión del SI.
Figura 2.8: Estados finales típicos de adaptaciones del SI.

Los estados finales típicos pueden incluir planes para posteriores adaptaciones del
SI.

Capítulo 2
Estado inicial típico Estado final precursor típico Entregables del dominio objetivo
SI no documentado Ninguno - puede ocurrir si, durante un No existe documentación de apoyo; o
período de tiempo, se ha modificado el bien
sistema operativo sin que se haya
Documentación rudimentaria o de baja
registrado ninguno de los cambios
calidad; o bien
realizados.
Documentación que ya no es coherente
con la versión actual operativa del SI.
SI documentado Un estado final similar al de SI Descripción detallada de las prácticas
instalado o al de la documentación del de trabajo y de la arquitectura del
SI. sistema informático del SI actualmente
operativo.
Descripción del Un estado final similar al de análisis de Elementos descriptivos de carácter
problema cambios del SI o al de análisis de global e informal relativos a los
cambios del sistema informático. procesos e información del negocio y a
las prácticas de trabajo y la arquitectura
del sistema informático del SI
actualmente operativo y otros futuros.
Diseño global Un estado final similar al de análisis de Elementos descriptivos de carácter
cambios del SI o al de análisis de global y semiformal relativos a los
cambios del sistema informático. procesos del negocio, la información
del negocio, las prácticas de trabajo y la
arquitectura del sistema informático del
futuro SI; pueden ser simulaciones.
Diseño detallado del Un estado final similar al de diseño Elementos descriptivos detallados de la
negocio detallado del negocio. información del negocio y de las
prácticas de negocio y de trabajo de una
nueva versión del SI.
Elementos descriptivos globales
relativos a los datos, funciones y
arquitectura del sistema informático,
que ilustran la viabilidad del diseño
detallado del negocio.
Diseño técnico Un estado final similar al de diseño Elementos descriptivos detallados de
detallado técnico detallado. las prácticas de trabajo y de los datos,
funciones y arquitectura del sistema
informático de una nueva versión del
SI.
SI probado Un estado de SI probado en que se ha Los elementos operativos que
construido, pero no instalado, una constituyen la nueva versión del SI.
nueva versión del SI, por ejemplo
Elementos descriptivos detallados de
debido a que la instalación en sí misma
las prácticas de trabajo y de la
es compleja y difícil de realizar.
arquitectura del sistema informático de
la nueva versión del SI.
Figura 2.9: Estados iniciales típicos de adaptaciones del SI.

Todos los estados iniciales típicos incluyen el SI actualmente operativo y, por
tanto, sus elementos operativos. Incluyen un plan de adaptación y pueden incluir
también planes de proyecto relativos a la adaptación prevista del SI.

Procedimiento El siguiente procedimiento puede utilizarse para dividir una adaptación del SI en
para definir una varios contratos cuando se utiliza la modalidad de una vez o la modalidad
secuencia de incremental:
contratos
1. Documentar el estado inicial y el estado final previstos de la adaptación del SI.
(þ 4.2.1: Documentar el estado inicial y el estado final)
2. Confrontar las descripciones de los estados inicial y final previstos de la
adaptación del SI con los estados inicial y final típicos apropiados, véase figuras
2.8 y 2.9.
3. Comprobar si esta combinación de estados inicial y final típicos constituye
alguna de las combinaciones no recomendables, véase figura 2.10. En este caso,
existe un riesgo en la adaptación del SI y habrá que tomar en consideración una
posible división de dicha adaptación.
La tabla de la figura 2.10 indica a partir de qué estados iniciales típicos suele
tener lugar la progresión hacia los distintos estados finales típicos en una única
adaptación del SI, y para cuáles deberá tomarse en consideración una división
de la adaptación del SI. Estos estados iniciales y finales típicos determinan
puntos en los que una adaptación del SI podría dividirse en otras dos
adaptaciones del SI; la primera de ellas finalizaría con el estado final típico y la
segunda continuaría con el estado inicial típico.

Capítulo 2
Estado Documentación del Análisis de Análisis de Diseño Diseño Sistema de Sistema de

final sistema de cambios del cambios del detallado del técnico información información
Estado información sistema de sistema negocio detallado probado instalado
inicial información informático
Sistema de _ _ _ ! ! ! !
información no
documentado
Sistema de _ _ _ ! ! ! !
información
documentado
Descripción del - _ _ _ ! ! !
problema
Diseño - _ _ _ _ ! !
global
Diseño detallado del - - - _ _ _ _

negocio
Diseño técnico - - - - _ _ _
detallado
Sistema de - - - - - _ _
información probado
Leyenda: _ Normalmente una única adaptación del SI.
! Deberá tomarse en consideración la división de la adaptación del SI o
un control explícito de los cambios contractuales.
- Combinación no válida.
Figura 2.10: Combinaciones de estados iniciales y finales típicos

Al analizar la adaptación del SI prevista mediante la comparación de los estados Comprobar la
inicial y final con los estados inicial y final típicos, se obtiene una primera impresión viabilidad de la
de los riesgos asociados a las adaptaciones del SI. No se trata de un juicio secuencia de
absoluto, sino simplemente de una señal inicial. Siempre pueden existir factores contratos
situacionales concretos que pueden alterar ese juicio. Por ejemplo:
• es posible que una adaptación del SI que se inicie con la descripción del
problema y finalice con el SI instalado se pueda gestionar correctamente,
aunque en la tabla esta combinación se califica de crítica; por ejemplo, si el
dominio objetivo es muy pequeño o los requisitos del SI se conocen
perfectamente.
• es posible que una adaptación del SI que se inicie con un diseño detallado del
negocio y finalice con un diseño técnico detallado, combinación que en
términos generales se caracteriza por ser gestionable, sea muy difícil de
gestionar, simplemente porque la situación del proyecto sea muy complicada;
por ejemplo, debido a un elevado número de subcontratos, resistencia a la
aceptación de la adaptación del SI, interfaces externas, etc.

Resumen: • Dividir la adquisición en varios contratos resulta apropiado

cuando la incertidumbre es elevada y no existe un
calendario apretado.
A
Opción: Decidir si comprar o desarrollar
CC SC En ocasiones se puede elegir entre comprar (por ejemplo, un paquete de software
CP SP
CS SS
disponible en el mercado) o desarrollar específicamente un producto (por ejemplo,
software) que satisfaga los requisitos. Puede existir una política general a nivel
organizativo acerca de esta opción (por ejemplo, únicamente se deciden desarrollos
específicos si no hay ningún producto adecuado disponible).
¿Cuándo La compra es aconsejable cuando:
comprar?
• existen productos con suficientes referencias y proveedores fiables (un
ejemplo típico es el dominio contable)
• la especificidad del SI no es muy elevada y los productos cubren la mayoría
de funcionalidades que se requieren
• la capacidad de los agentes es baja, es decir, el cliente posee un conocimiento
insuficiente de la aplicación
• el riesgo de integración del producto en el SI existente es bajo
• el presupuesto es ajustado
• el calendario es apretado.
¿Cuándo El desarrollo de productos resulta adecuado cuando:
desarrollar?
• el mercado no ofrece productos con referencias y proveedores fiables
• la especificidad del SI es elevada
• el riesgo de integración del producto en el SI existente es elevado
• existe el riesgo de limitarse a un único proveedor. A
A
Opción: Determinar los requisitos de la estrategia de adaptación
La estrategia de adaptación se compone de las modalidades de instalación,
construcción, descripción y control del proyecto. En el apartado 4.3 se explican
estas modalidades y se ofrecen orientaciones para seleccionar entre las opciones
disponibles. En concreto, se indica cómo reducir los riesgos derivados de la
complejidad y la incertidumbre seleccionando las modalidades apropiadas. (þ
4.3.2-3: Analizar y seleccionar las opciones estratégicas)
Establecer los Al inicio de la adquisición, el responsable contractual del cliente suele establecer
requisitos del los requisitos del enfoque de la instalación: de una vez, incremental o evolutiva. El
enfoque de la enfoque de la instalación se refiere al momento en que las distintas partes y
instalación del versiones de los sistemas pasan a estar disponibles en la organización.
sistema

Capítulo 2
El responsable contractual del cliente también podrá establecer requisitos relativos

al enfoque de la construcción y, más raramente, al enfoque de la descripción si se
precisa un enfoque uniforme en el nivel de adquisición. Muchas veces estas
cuestiones se dejan a elección de los proveedores en sus ofertas, es decir, al nivel
de gestión del contrato.
Las decisiones relativas al enfoque de control del proyecto se pueden adoptar a
distintos niveles, en función del nivel de normalización de los procedimientos de
control del proyecto que utiliza la organización, la especificidad de la adquisición,
contrato o proyecto (por ejemplo, un proyecto que no sea muy estratégico podrá
estar menos controlado que uno que sea estratégico). A
S
Opción: Determinar el tipo de prestación del servicio
Clarificar las En cuanto a los servicios, existen las siguientes opciones:
responsabilidades
del cliente y del
• ubicación: en la sede del cliente o en la del proveedor
proveedor, y la • compartir (o no) el servicio entre varios clientes
base para los
pagos • propiedad de los elementos operativos: cliente o proveedor
• personal empleado por el cliente o proveedor
• pagos: con o sin gastos garantizados,
− en base al tiempo y los materiales,
− o un precio fijo
− o propiedades cuantitativas, como la carga de trabajo
− o beneficios para el cliente.
Las instalaciones y cancelaciones de servicios pueden significar que muchos
elementos físicos, desde mobiliario de oficina hasta un gran sistema informático
central, ya no son necesarios o deben trasladarse. Entre otras cosas, habrá que
definir qué bienes internos y externos ya no serán necesarios, cuáles deben
devolverse o venderse y a quién. Es preciso definir el valor residual de los bienes
redundantes y las responsabilidades de las partes que intervienen. S
S
Opción: Determinar los requisitos de la estrategia de prestación del servicio
La estrategia de prestación del servicio se compone de los enfoques de la
instalación del servicio, la cancelación del servicio y el control del servicio. En el
apartado 5.2 se explican estos enfoques y se ofrecen orientaciones para seleccionar
entre las opciones disponibles.
El personal que interviene directamente en el servicio también suele participar en la
instalación y la retirada del mismo. Pueden surgir conflictos y problemas de moral
y de motivación, que pueden evitarse mediante una planificación detallada y una
gestión activa. Por supuesto, el propio personal deberá ser informado de todas las
actividades y planes relativos a la instalación y cancelación del servicio. (þ 5.2:
Servicios de planificación)

Al inicio de la adquisición, el responsable contractual del cliente suele establecer

Establecer los
requisitos del
los requisitos de los enfoques de la instalación del servicio: de una vez, incremental
enfoque de la o evolutiva, con cobertura geográfica global o regional. Pueden establecerse
instalación del diferentes requisitos para diferentes servicios o grupos de servicios.
servicio
Normalmente, los enfoques de cancelación del servicio se decidirán durante el
proceso de compra.
Las decisiones relativas al enfoque del control del servicio pueden adoptarse en
distintos niveles, en función del nivel de normalización de los procedimientos de
control del servicio que utiliza la organización, la especificidad de la adquisición, el
contrato o prestación de servicios (por ejemplo, una prestación de servicios que no
sea muy estratégica podrá estar menos controlada que una que sea estratégica). S
2.1.2.4 Planificar los principales puntos de decisión de El plan de

la adquisición adquisición
deberá reflejar la
El responsable contractual del cliente deberá planificar y estrategia
organizar los principales puntos de decisión de la adquisición en
base a:
• los requisitos de sistemas y servicios (el objetivo de la adquisición)
• los escenarios de adaptación y de prestación del servicio (planes globales de
entregas)
• factores de situación y riesgos (apreciación de la situación)
• estrategia de adquisición (opciones seleccionadas de gestión de riesgos).
Planificar las El plan de adquisición deberá incluir las compras previstas y otras actividades del
compras cliente, por ejemplo el cambio de los factores situacionales, cambio o
necesarias y las puntualización de los requisitos o adquisición de ayuda externa. El plan podrá
actividades del evolucionar durante el proceso de adquisición, es decir, el nivel de detalle variará y
cliente
será mayor para las actividades y compras a corto plazo.
Las decisiones relativas a una compra documentada en un plan de adquisición se
relacionan en la figura 2.11.

Capítulo 2
Decisiones relativas a una compra:

• requisitos de los sistemas y servicios
• calendario, costes, beneficios, intereses e interesados
• tipo de proveedor
• tipo de licitación
• relaciones con los proveedores
• flexibilidad del contrato
• estrategia en cuanto a las normas
• A requisitos de cada adaptación:
− estado inicial y estado final
− comprar o desarrollar
− apreciación de la situación
− estrategia de adaptación, en particular los enfoques de la
instalación del sistema y del control del proyecto
− puntos de decisión de inversión y principales entregables
intermedios A
• S requisitos de las prestaciones de servicios:
− tipo de prestación del servicio
− estrategia de prestación del servicio, en particular los enfoques
de la instalación del servicio y del control del servicio. S
Figura 2.11: Plan de adquisición: decisiones relativas a una compra
2.1.2.5 Coordinar la organización del cliente dentro de la adquisición
El responsable contractual del cliente deberá coordinar la organización que llevará Asignar
a cabo la adquisición. Para ello deberá identificar las distintas funciones que se funciones a las
precisen (los responsables de proyecto y de servicio del cliente y los diferentes personas
expertos, véase capítulo 1) y asignarlas a personas. Es preciso comprobar que estas
personas estarán disponibles cuando sean necesarias en el transcurso de la
adquisición.
También habrá que identificar y programar la intervención de los agentes de la
organización y del SI que participen en la adquisición.
Opción: Decidir el uso de ayuda externa a la gestión de la adquisición

La ayuda externa proporciona experiencia y mano de obra al responsable ¿Cuándo utilizar
contractual del cliente para la gestión de la adquisición. Esta ayuda externa a la ayuda externa?
gestión de la adquisición es apropiada cuando:
• la capacidad del equipo del cliente es baja (por ejemplo, escasa o nula
experiencia en la adquisición de un SI, falta de tiempo disponible, falta de
recursos)
• la elevada heterogeneidad de los agentes o su actitud negativa precisa un
punto de vista externo, no influenciado por el conocimiento de la trayectoria
y los conflictos internos del cliente

• el SI es complejo (por ejemplo, un dominio objetivo de gran tamaño, una

gran distribución)
• el objetivo o la tecnología de desarrollo son muy novedosos
• los proyectos son complejos (por ejemplo, un proyecto de gran envergadura,
muchos subcontratistas)
• la contratación de los procesos es compleja, por ejemplo dificultades de
acceso a fuentes externas.
2.2 Conducción de un proceso de compra
CC SC
CP SP
CS SS
Una compra es el proceso de obtención de las adaptaciones y prestaciones de

servicios que se definen en un contrato. Una compra puede incluir:
• una única adaptación
• varias adaptaciones
• una única prestación de servicio (incluyendo las adaptaciones de instalación
del servicio y cancelación del servicio)
• varias prestaciones de servicios (incluyendo la instalación y cancelación de
los servicios)
• varias adaptaciones y prestaciones de servicios.
Mantener Los requisitos de una compra se definen al inicio de la adquisición y se documentan
actualizados el en un plan de adquisición, véase figura 2.11 en el apartado 2.1: Inicio de la
objetivo y el adquisición. Durante el proceso de compra es posible que los requisitos de la
plan de compra evolucionen. El plan de adquisición deberá mantenerse actualizado
adquisición
mediante el control de la gestión de las versiones. Incluso la definición del objetivo
de la adquisición deberá revisarse para adecuarla a las puntualizaciones y
modificaciones que se produzcan durante el proceso de compra. Ello exigirá la
coordinación entre los responsables de gestión a nivel de adquisición y a nivel
contractual.
Una secuencia Tal y como se explica en el capítulo 1, véase figura 1.4: Modelo del proceso de
de tres procesos adquisición, un proceso de compra es una secuencia de tres procesos:
de compra
• Licitación.
Proceso encaminado a seleccionar un proveedor y una oferta para las
adaptaciones y prestaciones de servicios en cuestión, y a acordar con el
proveedor seleccionado un contrato que defina las entregas y las
responsabilidades de ambas partes.
• Seguimiento del contrato.
Proceso encaminado a supervisar las adaptaciones y prestaciones de servicios
definidas en el contrato, es decir, asegurar que los entregables y servicios son
conformes a los requisitos especificados en el contrato.

Capítulo 2
• Cumplimentación del contrato.

Proceso encaminado a finalizar el contrato.
A continuación se formulan orientaciones sobre la utilización de Eurométodo en
estos tres procesos.

CC SC
CP SP
CS SS
2.2.1 Licitación
Actividades del cliente Actividades del proveedor
Preparación de la
petición de ofertas
Petición de ofertas
Preparación de
las ofertas
Selección del
Respuesta
proveedor
Informe de evaluación
Preparación del de proveedores
Preparación del
contrato
contrato
Contrato
• Preparación de la petición de ofertas.

La finalidad de esta actividad es obtener la primera versión de los requisitos de
compra del sistema de información, para incorporarlos al entregable de petición
de ofertas. La relación cliente-proveedor se inicia con este entregable.
• Preparación de las ofertas.
Los proveedores envían al cliente un entregable que describe una solución
propuesta que satisface sus requisitos de compra del sistema de información. Esta
oferta incluirá versiones más elaboradas de los planes que contiene la petición de
ofertas.
• Selección del proveedor.
En base a una evaluación, se comunica al proveedor que haya presentado la
oferta más apropiada, que ha sido seleccionado. En caso de que no se prefiera a
ningún proveedor en concreto, se considerarán posibles alternativas, como una
nueva petición de ofertas.
• Preparación del contrato.
El proveedor seleccionado y el cliente podrán negociar posibles modificaciones y
ampliaciones de la oferta antes de pactar el contenido final del contrato. A

Capítulo 2
continuación, ambas partes firmarán el contrato.
Figura 2.12: Actividades e intercambio de entregables dentro de un proceso de

licitación
(ejecutadas por los responsables contractuales y del proyecto/servicio)
El proceso de licitación está encaminado a seleccionar un proveedor y una oferta

para unos requisitos de compra del SI (descripciones del sistema y los servicios;
plan de entregas, plan del proyecto y plan de servicio) y acordar con el proveedor
seleccionado un contrato que defina las entregas y responsabilidades de ambas
partes.
El proceso de licitación encierra las siguientes actividades: preparación de la
petición de ofertas, preparación de las ofertas, selección del proveedor y
preparación del contrato, véase figura 2.12. Estas actividades las realiza el cliente o
el proveedor o ambos; y en ellas se elabora una descripción de los procesos
previstos de seguimiento y cumplimentación del contrato. El proceso previsto de
seguimiento del contrato se documenta dentro de un plan de entregas contractual.
Todas estas actividades incluyen la elaboración de documentos que se intercambian
como parte de la relación cliente-proveedor, véase también la figura 2.12.
Las actividades de licitación no tienen por qué ejecutarse en el orden de la figura
2.12: pueden coincidir en el tiempo y pueden producirse iteraciones de grupos de
ellas, véase figura 2.13. En el apartado 2.1.2.3: Opción: Determinar las relaciones
con los proveedores, figuran ejemplos de iteraciones
Proceso de licitación Proceso de

Iteración de actividades
supervisión
Preparación del contrato
de la petición Preparación Selección del Preparación
de ofertas de la oferta proveedor del contrato
describe describe valora describe

Plan de entregas
realizado en
Plan de entregas
del proceso de supervisión del contrato
Puntos de decisión del proceso de supervisión del contrato
Figura 2.13: El proceso de licitación: posible iteración de actividades.

Un resultado importante: el plan de entregas.
Desde el punto de vista contractual, el proceso de licitación concluye con la firma
del contrato, que es cuando comienza el proceso de seguimiento del contrato.

La producción del proyecto o prestación del servicio puede iniciarse con la firma
Diferentes
prácticas de
del contrato o como resultado de que el cliente presente al proveedor una carta de
negocio a nivel intenciones; en función de la práctica de negocio a nivel nacional.
nacional En ciertas situaciones, como dentro del dominio público, el cliente y el proveedor
tendrán que cumplir los reglamentos nacionales y europeos. Eurométodo ayuda al
cliente a realizar estas actividades de acuerdo con estos reglamentos, en su caso.
2.2.1.1 Preparación de la petición de ofertas

CC SC
CP
CS
SP
SS
Objetivo: Producir una petición de ofertas que documente los requisitos del
cliente respecto al objetivo y el plan de adquisición, y que constituya una base
suficiente para que los proveedores interesados presenten ofertas.
Insumos: Plan de adquisición
Actividades:
– Definir el dominio objetivo de la compra del SI
– Determinar los objetivos del contrato y los requisitos de los sistemas y
servicios
– Determinar los imperativos y procedimientos organizativos (normas
aplicables, arquitectura, etc.)
– Determinar el plan de entregas necesario
– Determinar los imperativos que previsiblemente afectarán al plan del
proyecto y al plan de servicio (calendario, disponibilidad de los recursos del
cliente, etc.)
– Determinar los imperativos financieros/presupuesto
– Definir las cláusulas legales del contrato
– Definir la modalidad de evaluación del proveedor
– Determinar las instrucciones para los proveedores que presentan ofertas
– Definir los requisitos acerca de las características de la organización del
proveedor
– Presentar la petición de ofertas
Productos: Petición de ofertas
Figura 2.14: Actividades encaminadas a preparar una petición de ofertas

(ejecutadas por el responsable contractual y el responsable de proyecto/servicio del
cliente).
El responsable contractual y el responsable de proyecto/servicio del cliente deberán
elaborar una petición de ofertas con el contenido definido en el apartado 3.2.1:
Entregables de licitación. Puede utilizarse la plantilla del anexo D.1 para facilitar el
trabajo. Las actividades a realizar para elaborar una petición de ofertas se
relacionan en la figura 2.14. Estas actividades corresponden a las propiedades que

Capítulo 2
se definen en el apartado 3.2.1. A continuación figuran orientaciones sobre la

manera de llevar a cabo estas actividades.
En la práctica, la preparación de la primera petición de ofertas dentro de una
adquisición puede integrarse en el inicio de la adquisición, es decir, se integran las
actividades similares dentro del inicio de la adquisición y la preparación de la
petición de ofertas.
Definir el dominio objetivo de la compra

El dominio objetivo será el mismo que el definido en el inicio de la adquisición o un Definir con
subconjunto de éste. En caso de que existan varios contratos dentro de la mayor precisión
adquisición, el dominio objetivo de esta compra podrá ser un subconjunto del el dominio
dominio objetivo de toda la adquisición, es decir, habrá que definir este objetivo
subconjunto.
Determinar los objetivos del contrato y los requisitos de sistemas y servicios

Es preciso definir con mayor precisión los requisitos de sistemas y servicios (que se Definir con
establecen al inicio de la adquisición) incluidos dentro del alcance de este contrato. mayor precisión
Esta actividad puede llevarla a cabo el cliente con o sin ayuda de proveedores, en los requisitos de
función de las relaciones con los proveedores dentro del proceso de licitación, sistemas y
servicios
véase apartado 2.1.2.3: Opción: Determinar las relaciones con los proveedores.
Los requisitos de los sistemas y servicios se componen de: Requisitos de
sistemas y
• A
descripciones de los sistemas, que definen los elementos operativos. servicios
Elementos descriptivos que deben incorporarse a las adaptaciones; pueden
incluir elementos descriptivos del estado inicial y de futuros SI. El nivel de
detalle de cada elemento descriptivo depende de la finalidad de la
descripción. (þ 3.6: Elementos descriptivos) A
• S
descripciones de los servicios.
Elementos descriptivos que definen los servicios que deben prestarse. Pueden
incluir las actividades a realizar, las comunidades de usuarios a las que se van
a prestar los servicios, etc. Para cada servicio, el nivel de detalle de la
descripción del servicio puede variar, desde una simple descripción hasta la
propia elaboración del nivel de servicio.
(þ 5.1: Descripción de los servicios) S
En la práctica, la elaboración de los requisitos de los sistemas y servicios puede
evolucionar durante el proceso de licitación, véase apartado 2.1.2.3: Opción:
Determinar los tipos de licitación.
Determinar los imperativos y procedimientos organizativos

Durante la elaboración de los requisitos de los sistemas, servicios y plan de Determinar los
entregas, el cliente deberá identificar cualquier imperativo técnico u organizativo imperativos
que afecte a las adaptaciones y prestaciones de servicios propuestas. Ejemplos de organizativos
estos imperativos: arquitectura técnica y de datos de la empresa, además de normas
de ingeniería de sistemas adoptadas y guías de estilo de la documentación. Véase
también el apartado 2.1.2.1: Determinar los escenarios generales de adaptaciones

y prestaciones de servicios, donde figuran ejemplos de prioridades y dependencias

entre entregas.
Determinar el plan de entregas necesario

Diferentes El plan de entregas que incluye una petición de ofertas puede presentar diferentes
niveles de niveles de detalle, en función del nivel disponible de conocimientos acerca de las
detalle adaptaciones y prestaciones de servicios necesarias, obtenidos al inicio de la
adquisición.
Establecer los A
Para cada adaptación necesaria, el nivel de detalle del plan de adaptación
requisitos de los incluido en el plan de entregas puede variar, desde un simple análisis de riesgos
planes de
hasta la propia definición de la estrategia de adaptación y la elaboración de cada
adaptación
decisión y de cada entregable identificados. Las técnicas de planificación de la
adaptación descritas en el capítulo 4 deberán utilizarse para elaborar un plan de
adaptación:
1. Análisis de riesgos (preceptivo).
El resultado es una apreciación y descripción de la situación del problema: el
estado final y el estado inicial de la adaptación, los valores de los factores de
situación y los riesgos críticos. El cliente deberá solicitar que el plan de
adaptación propuesto por el proveedor aborde todos los riesgos críticos. (þ
4.2: Análisis de riesgos)
2. Definir la estrategia de adaptación (opcional)
Da como resultado los requisitos de los enfoques del desarrollo, la modalidad
de control del proyecto y las contramedidas para reducir los riesgos. Debería
centrarse en los riesgos más críticos. (þ 4.3: Diseño de una estrategia de
adaptación)
3. Definir los puntos de decisión y los entregables (opcional)
Da como resultado los requisitos de la secuencia y contenido de los puntos de
decisión, incluyendo los entregables que servirán de condiciones previas o de
base para las decisiones.
(þ 4.4-5: Planificación de los puntos de decisión, descripción de los
entregables) A
Establecer los S
Para cada servicio o grupo de servicios asociados, el nivel de detalle del plan de
requisitos de los prestación de servicios necesario puede variar, desde una descripción de la
planes de
situación del problema hasta la propia elaboración del plan de instalación del
prestación de
servicios servicio, ejecución del servicio y cancelación del servicio. Para ello podrán
utilizarse las orientaciones del capítulo 5:
1. Describir la situación del problema (opcional).
Da como resultado los estados inicial y final de la instalación y la cancelación
del servicio, los factores situacionales y los riesgos críticos. (þ 5.2.1: Análisis
de riesgos)
2. Describir la estrategia de prestación del servicio (opcional).
Da como resultado los requisitos de los enfoques de la instalación del servicio,
la cancelación del servicio y el control del servicio. (þ 5.2.2: Diseño de una
estrategia de prestación del servicio)

Capítulo 2
3. Planificar los puntos de decisión (opcional)

Da como resultado descripciones de la secuencia y del contenido de los puntos
de decisión dentro de la prestación del servicio. (þ 5.2.3: Planificación de los
puntos de decisión) S
A los riesgos que se mencionan en los capítulos 4 y 5 pueden añadirse los riesgos Considerar los
específicos que conlleva la preparación de la petición de ofertas. Ejemplos de este riesgos
tipo de riesgos: específicos de la
petición de
• ningún proveedor responde a la petición de ofertas, debido a que las ofertas
organizaciones de los proveedores consideran que una compra de un sistema
de información es, por ejemplo, inviable o demasiado arriesgada
económicamente
• los importes y los costes que indican las ofertas son muy elevados, debido a
que los proveedores han tenido que adoptar importantes medidas de
prevención para asumir los riesgos financieros calculados
• fracaso de la compra del SI, por ser inviable
• es imposible controlar los importes y los costes.
Todos estos riesgos deberán tenerse en cuenta al realizar el análisis de riesgos. Una Posible cambio
posible contramedida para reducir los riesgos es revisar el plan de adquisición, es del plan de
decir, cambiar los requisitos de esta compra. adquisición
Finalmente, los requisitos de los puntos de decisión incluidos en los planes de Establecer los
adaptación y de prestación de servicios deberán reunirse en un conjunto de requisitos del
requisitos de los puntos de decisión dentro de la supervisión del contrato. Ello punto de
deberá complementarse con los requisitos del punto de decisión de decisión de
cumplimenta-
cumplimentación del contrato, por ejemplo, los requisitos de organización, ción del contrato
procedimientos y funciones que intervienen.
Determinar los imperativos que previsiblemente afectarán al plan del proyecto y

al plan de servicio
Ninguna compra de un SI se produce totalmente desligada de los procesos de Clarificar las
negocio que tienen lugar en la organización del cliente. Así pues, al preparar la interfaces de los
petición de ofertas deberá consultarse a los responsables organizativos al objeto de procesos de
identificar cualquier imperativo organizativo o de planificación, como por ejemplo negocio
la interrupción de los pagos, la presentación del producto y fechas de
implementación de la reorganización. La relación de propiedades del plan del
proyecto y del plan de servicio que se ofrece en el apartado 3.3 puede utilizarse
para analizar los posibles imperativos. (þ 3.3: Entregables de gestión)
Determinar los imperativos financieros/presupuesto

Conviene realizar una estimación del presupuesto para la compra, ajustándose al Estimación del
presupuesto de la adquisición. Este presupuesto debería especificarse de alguna presupuesto
manera en la petición de ofertas. Así pues, al preparar la petición de ofertas es
conveniente consultar al responsable financiero, al objeto de identificar cualquier
imperativo financiero u organizativo relativo al plan de negocio de la organización,
véase apartado 2.1.1.3: Analizar los costes y beneficios.
Definir las cláusulas jurídicas del contrato

Definir las Ejemplos de cláusulas jurídicas:
cláusulas
jurídicas • criterios de aceptación de la adaptación y la prestación del servicio
necesarias • condiciones de pago
• garantías de cumplimiento de las obligaciones
• limitación de la responsabilidad
• derechos de propiedad intelectual
• propiedad de los dispositivos físicos, software, licencias, etc.
• seguridad y confidencialidad
• condiciones de finalización del contrato (por ejemplo, quiebra del proveedor)
• normativa aplicable
• en caso de conflicto, quién actuará como árbitro independiente
• control de la subcontratación.
Determinar el enfoque de la evaluación del proveedor

Determinar los Los criterios que se aplicarán para evaluar y seleccionar un proveedor deberán
criterios documentarse en la petición de ofertas. Deberán tenerse en cuenta los siguientes
relevantes de aspectos para la selección de los criterios relevantes:
selección del
proveedor • sistemas y servicio propuestos
• A
aspectos del plan de adaptación:
idoneidad de: análisis de riesgos, estrategia de adaptación, puntos de
decisión, entregables A
• S
aspectos del plan de prestación de servicios:
idoneidad de: análisis de riesgos, estrategia de prestación del servicio, puntos
de decisión, entregables S
• otros aspectos contractuales
por ejemplo: precio, métodos propuestos, cualificaciones de los agentes que
intervienen en la producción de los proyectos y las prestaciones de servicios.
Graduar los Es preciso determinar el enfoque de la evaluación de las ofertas para cada criterio
criterios seleccionado. En la medida de lo posible deberán utilizarse mediciones
cuantitativas. Como no es posible expresar todos los beneficios con una única
medida, como por ejemplo el dinero, es preciso diseñar una tabla de evaluación
(una matriz para la evaluación de ofertas) al objeto de tener en cuenta esos
beneficios de acuerdo con la estrategia del negocio y la gestión. Esta tabla de
evaluación y su justificación deberán estar documentadas para garantizar que la
selección del proveedor sea imparcial. En el apartado 2.2.1.3: Selección del
proveedor figura más información a este respecto (comparación de ofertas).

Capítulo 2
Asimismo, el cliente deberá indicar qué requisitos son obligatorios, incluyendo esta
Indicar los
información en las descripciones de los sistemas, en las descripciones de los requisitos
servicios y en el plan de entregas necesario. preceptivos
Determinar las instrucciones para los proveedores que presentan ofertas

Al preparar la petición de ofertas, es preciso tener en cuenta qué instrucciones Planificar las
habrá que dar a los proveedores. Ejemplos de instrucciones: relaciones con
los proveedores
• Fecha límite para la presentación de ofertas
• Número de copias de la oferta
• Criterios de conformidad, por ejemplo que las ofertas presentadas deberán
utilizar la terminología de Eurométodo
• Procedimientos de intercambio durante la preparación de las ofertas, por
ejemplo, reuniones con todos los proveedores interesados.
Cuando una organización esté sujeta a los reglamentos de las Directivas de
Servicios [92/50/CEE], deberá asegurarse de que cumple sus requisitos, por
ejemplo, enviando a todos los proveedores potenciales conocidos todas las
respuestas a una cuestión en concreto
• Indicación de los métodos propuestos por el proveedor y existencia de
diccionarios de enlace para estos métodos.
Definir los requisitos de las características de la organización del proveedor

Es posible controlar, en términos generales, la idoneidad de una organización Extraer los
haciendo una indicación al respecto en la petición de ofertas: ‘Se invita a criterios de las
proveedores cuyas organizaciones reúnan las siguientes características: registro normas o de la
según la norma EN 29000, capitalización de 1 MECU, etc.’. Otra posibilidad es capacidad de
proceso y
que los criterios para valorar la capacidad de los procesos organizativos se métodos de
extraigan de las especificaciones actualmente disponibles sobre capacidad de evaluación
proceso y evaluación de madurez.
Publicación de la petición de ofertas

El cliente publica el anuncio en el Diario Europeo (en su caso) o en diarios y
periódicos de ámbito profesional, y remite sendos ejemplares de los requisitos de
compra del SI a todos los proveedores interesados o sólo a los proveedores
seleccionados, en función del procedimiento que se siga.
El cliente publicará un anuncio en el Diario Europeo si:
• la organización del cliente se encuentra en la Unión Europea, y

• está sujeta a los reglamentos europeos relativos a las compras públicas de
servicios, y
• el valor de la adquisición, o de la agregación de adquisiciones, supere los
umbrales CE/OMC.

En esta situación, las organizaciones de proveedores interesadas en el contrato que

se propone podrán solicitar más información al respecto. El cliente deberá remitir
entonces sendos ejemplares de los requisitos de compra del SI a:
• las organizaciones de proveedores interesadas, o bien

• aquellas organizaciones de proveedores que se ajusten a un conjunto de
criterios predefinidos (por ejemplo, certificación ISO 9001).
Si se desea una licitación restringida o negociada [92/50/CEE], el proceso será más
sencillo, ya que los requisitos de compra del sistema de información sólo se
proporcionan a los proveedores que han sido seleccionados para participar en el
proceso de licitación.
El responsable contractual del cliente y el responsable de un proyecto/servicio
deberán confeccionar una oferta con el contenido que se describe en el apartado
3.2.1: Entregables de licitación. Para facilitar el trabajo, puede utilizarse la plantilla
del anexo D.2. Las actividades para confeccionar una oferta se relacionan en la
figura 2.15. Estas actividades corresponden a las propiedades que se definen en el
apartado 3.2.1. A continuación figuran indicaciones sobre la manera de realizar
estas actividades.

Capítulo 2
2.2.1.2 Preparación de las ofertas
Objetivo: Presentar una oferta competitiva que satisfaga los requisitos del cliente CC SC
tal y como se especifican en la petición de ofertas. CP SP

SS
CS
Insumo: Petición de ofertas

Actividades (si se decide participar):
- Definir el dominio objetivo (punto de vista del proveedor)
- Determinar los objetivos, requisitos y soluciones
- Determinar el plan de entregas propuesto
- Determinar la organización y los planes del proyecto y del servicio
- Determinar los precios y los costes
- Pormenorizar las cláusulas legales propuestas
- Describir las características de la organización del proveedor
- Presentar las ventajas de la oferta
Producto: Oferta
Figura 2.15: Actividades de preparación de una oferta

(ejecutadas por el responsable contractual del cliente y el responsable del
proyecto/servicio)
El responsable contractual del cliente y el responsable del proyecto/servicio
deberán:
1. decidir si la organización del proveedor debe participar en el proceso de Decidir si se
licitación y presentar una oferta a la organización del cliente. presenta la oferta
1. elaborar una oferta completa, incluyendo el plan de entregas propuesto, las En caso
cláusulas jurídicas o comentarios a las cláusulas jurídicas que exige el cliente. afirmativo:
La preparación de la oferta consiste en una valoración y cumplimentación de elaborar una
los requisitos de compra del SI descrito por el cliente en la petición de oferta
ofertas.
Definir el dominio objetivo (punto de vista del proveedor)

El dominio objetivo descrito en la oferta deberá ser idéntico al que se define en la Clarificar la
petición de ofertas del cliente. No obstante, al presentar su oferta, un proveedor apreciación del
puede interpretar el dominio objetivo de manera diferente (por ejemplo, debido a dominio objetivo
una apreciación del dominio objetivo a raíz de contactos previos con otros clientes
de la misma área de negocio), o puede verse limitado por las tecnologías
disponibles.

Determinar los objetivos, requisitos y soluciones

Clarificar la El proveedor deberá clarificar la apreciación de los objetivos y requisitos y
apreciación de proporcionar descripciones de la solución propuesta para los sistemas y servicios
los objetivos y que se solicitan en la petición de ofertas.
requisitos
Describir las Las descripciones de las soluciones consisten en elementos descriptivos que
soluciones de describen los entregables de los elementos operativos (sistemas) y los servicios.
sistemas y Las propiedades de un elemento descriptivo que se mencionan en el apartado 3.6,
servicios Elementos descriptivos, pueden utilizarse como lista de comprobación para realizar
las descripciones. En el apartado 5.1 se ofrece asesoramiento acerca de la
descripción de los servicios.
S
Si lo solicita el cliente, las descripciones de los servicios deberán indicar los
métodos que el proveedor propone utilizar al ejecutar los servicios.
(þ 3.6: Elementos descriptivos; 5.1: Descripción de los servicios) S
Determinar el plan de entregas propuesto

Una parte fundamental del plan de entregas propuesto consistirá en que el
proveedor revisará el plan de entregas que precisa el cliente y definirá todos los
detalles adicionales al mismo que sean apropiados para la solución que se oferta.
El proveedor deberá centrarse en:
• los estados inicial y final de cada adaptación

• los estados inicial y final de cada instalación y cancelación de un servicio
• los entregables y decisiones.
Confeccionar un Para ello, el proveedor tomará como base la valoración que él mismo haya
plan basado en realizado de la situación del problema. El proveedor deberá generar una estrategia
una estrategia de completa de gestión de riesgos para las adaptaciones y prestaciones de servicios.
reducción de
riesgos El siguiente procedimiento puede utilizarse para confeccionar un plan de entregas.
A A
1. Elaborar un plan de adaptación para cada adaptación.
S
2. Elaborar uno o varios planes de prestación de servicios que cubran todos los
servicios ofertados. S
3. Analizar y documentar las dependencias entre los planes de adaptación y de
prestación de servicios.
4. Agregar las secuencias de puntos de decisión incluidos en los planes de
adaptación y de prestación de servicios, para formar una única secuencia de los
principales puntos de decisión a nivel contractual.
5. Describir el(los) punto(s) de decisión de cumplimentación del contrato.
6. Documentar el plan de entregas.

Capítulo 2
Paso 1: Elaborar un plan de adaptación para cada adaptación

A
Para cada adaptación que se identifique, el plan de adaptación incluido en el
plan de entregas deberá contener una estrategia de adaptación completa que
contemple todos los riesgos, y una descripción detallada de cada punto de decisión
y de cada entregable. Para ello, el proveedor podrá basarse en uno de los dos
escenarios posibles para utilizar las técnicas de planificación de la adaptación que
se describen en el capítulo 4.
(þ 4.1-5: Análisis de riesgos, Diseño de una estrategia de adaptación,
Planificación de los puntos de decisión, Descripción de los entregables)
• Utilizar todas las técnicas de Eurométodo: Cómo utilizar las
Aplicar el apartado 4.1-5 con el escenario 1 del apartado 4.1: extraer una técnicas de
secuencia básica de puntos de decisión basada en las opciones estratégicas de planificación de
la adaptación
Eurométodo.
descritas en el
• Utilizar todas las técnicas excepto las opciones estratégicas de Eurométodo capítulo 4
(que se sustituirán por un modelo de proceso del método elegido):
Aplicar los apartados 4.1-5 excepto los apartados 4.3.2-3, y con el escenario
2 del apartado 4.4.1: extraer una secuencia básica de puntos de decisión
basada en un modelo de proceso del método.
Asimismo, si lo solicita el cliente, el proveedor deberá indicar qué métodos
propone utilizar y si existe un diccionario de enlace. De este modo, el cliente sabe
cómo se utilizan en la adaptación los métodos específicos propuestos. También
pueden ser necesarios los métodos al nivel de entregables. A
Paso 2: Elaborar uno o varios planes de prestación de servicios

S Utilizar las
Para cada servicio o grupo de servicios asociados deberá elaborarse un plan de
prestación de servicios utilizando las orientaciones del apartado 5.2: Planificación orientaciones del
capítulo 5 en
de la prestación de servicios. El plan de prestación de servicios deberá incluir la
materia de
instalación del servicio, la ejecución del servicio y la cancelación del servicio que planificación de
propone el proveedor. Habrá que prestar especial atención a la realización de un servicios
análisis específico de todos los puntos que presenten dificultades en las
instalaciones de servicios.
(þ 5.2.1-3: Análisis de riesgos, Diseño de la estrategia de prestación del servicio,
Planificación de los puntos de decisión) S
Paso 3: Analizar y documentar las dependencias

Analizar y documentar las dependencias de calendario entre los puntos de decisión Analizar los
debidas a los requisitos impuestos sobre la secuencia de decisiones a adoptar, o los requisitos de
sistemas y servicios a entregar. Este análisis de las dependencias es la base de la calendario de las
agregación de las secuencias de puntos de decisión. decisiones y
entregas
Paso 4: Agregar las secuencias de puntos de decisión
Las secuencias de puntos de decisión deberán agregarse de acuerdo con las Minimizar el
dependencias que existan entre ellas. Deberá minimizarse el número de puntos de número de
puntos de
decisión

decisión a fin de elaborar un plan viable para que los responsables contractuales
intervengan en la supervisión del contrato, es decir, agregar lo máximo posible.
Paso 5: Describir el punto de decisión de cumplimentación del contrato

Clarificar los El punto de cumplimentación del contrato deberá describirse siguiendo las
requisitos de orientaciones del apartado 4.4.3: Descripción de los puntos de decisión. Esto
cumplimentación incluye la descripción de los objetivos, funciones que intervienen, condiciones
del contrato previas, bases para las decisiones, organización y calendario. Se puede utilizar la
plantilla del anexo D para facilitar esta tarea.
(þ 4.4.3: Descripción de los puntos de decisión, anexo D.21: Descripción de los
puntos de decisión)
Paso 6: Documentar el plan de entregas

El plan de entregas, inclusive los planes de adaptación y los planes de prestación de
servicios, deberá documentarse utilizando el asesoramiento que ofrece el apartado
3.2.1 y las plantillas del anexo D. (þ 3.2.1: Entregables de licitación, anexos D.5:
Plan de entregas, D.6: Plan de adaptación, D.7: Plan de prestación de servicios)
Determinar la organización y los planes del proyecto y del servicio

Clarificar los Ninguna compra de un sistema de información se produce totalmente desligada de
imperativos los procesos de negocio que están teniendo lugar en la organización. Al preparar la
relativos a la oferta deberá consultarse a los responsables organizativos apropiados, al objeto de
subcontratación identificar cualquier imperativo organizativo, por ejemplo en los niveles de
obtención de recursos para el proyecto y el servicio, o en las fechas de
implementación de la reorganización.
Proponer Estos imperativos, junto con los imperativos de la organización del cliente
organizaciones y (descritos en la petición de ofertas), se toman en consideración al elaborar la
planes del organización y el plan del proyecto y del servicio. Pueden utilizarse como lista de
proyecto y del comprobación las propiedades del plan del proyecto y del plan de servicio que se
servicio
describen en el apartado 3.3: Entregables de gestión.
(þ 3.3: Entregables de gestión)
Determinar los importes y los precios

Puede haber Deberá consultarse a los responsables financieros y de marketing a fin de identificar
diferencias entre cualquier programa organizativo de fijación de precios e imperativos financieros
la fijación de relativos a los importes y los costes. La fijación de precios y el cálculo de costes
precios y el pueden verse afectados por distintas políticas: políticas de ventas y políticas de
cálculo de costes
estimación de costes. Cuando sea posible deberán utilizarse herramientas
automatizadas de estimación, referencias anteriores y técnicas de analogía, a fin de
elaborar un buen programa de cálculo de costes.
CC SC Existen cuatro métodos básicos para estimar los costes de las adaptaciones:
CP SP
CS SS • Por analogía con experiencias previas:
Las estimaciones se basan en los costes de adquisiciones similares. Este
método precisa una capitalización de experiencias de adquisición y una
Métodos de clasificación de estas experiencias según los parámetros que influyen en los
estimación de
costes.
costes a utilizar
Capítulo 2
• Modelos matemáticos:
Las estimaciones se basan en un modelo matemático que calcula los costes a
partir de ciertos parámetros como el número de líneas de código de software,
el número de funciones del sistema de información y su complejidad, etc. El
análisis de puntos de función es un ejemplo popular de este método. Estos
modelos matemáticos tienen que ser calibrados para reflejar la especificidad
de la situación. También tienen que actualizarse para reflejar la evolución de
los últimos avances en tecnologías de la información, métodos, herramientas,
etc. Hay que tener cuidado al seleccionar un método cuyos parámetros
puedan ser evaluados durante el inicio de la adquisición: por ejemplo, el uso
del análisis de puntos de función precisa un conocimiento suficiente del
número de funciones que intervienen en la adquisición y de su nivel de
complejidad.
• Por desglose de tareas:
Las estimaciones se basan en un desglose detallado de las tareas que tienen
lugar en la adaptación o servicio, y se obtienen sumando los costes de cada
una de las tareas. Los costes de cada tarea se estiman por analogía con tareas
similares o mediante un modelo matemático.
• Por opinión experta:
Las estimaciones se obtienen consultando a expertos y alcanzando un
consenso.
Algunos métodos permiten evaluar otros datos además de los costes, como son el CC SC
SP
esfuerzo y la duración. CP
CS SS
Si se utiliza más de un método de estimación de costes las estimaciones serán más

fiables.
Es preciso documentar los supuestos y los parámetros aplicados (por ejemplo,
tecnologías utilizadas, número de funciones, complejidad de las funciones, plazos
previstos, tasa de mano de obra, tasa de inflación, cambio de moneda) a fin de
comprobar, negociar y posiblemente revisar las estimaciones en el transcurso de la
adquisición.
Puntualizar las cláusulas jurídicas propuestas

Deberá consultarse al responsable jurídico para valorar las cláusulas jurídicas que Valorar las
solicita el cliente en la petición de ofertas. Se ofrecen ejemplos de cláusulas legales cláusulas
en las condiciones de finalización, criterios de aceptación, garantía, limitación de la jurídicas
responsabilidad, condiciones de pago, confidencialidad, derechos de propiedad, necesarias
transmisión de propiedad y personal, etc. (véase también el apartado 2.2.1.1
Definición de las cláusulas jurídicas del contrato)

Describir las características de la organización del proveedor

El proveedor Deberá incluirse una indicación de la idoneidad de la organización, que demuestre
puede hacer que reúne las características definidas en la petición de ofertas, tales como:
referencia a
certificados • registro ISO 9000/EN 29000
reconocidos
internacional-
• fiscalización corporativa
mente • presencia en la lista de proveedores cualificados del cliente (si se permite)
• resultados de evaluaciones recientes de capacidad de proceso y de madurez
• perfiles del personal que interviene
• experiencia en proyectos o servicios similares.
Presentar las ventajas de la oferta

Hacer hincapié El proveedor deberá presentar un resumen de aquellas características de la oferta
en los lados que considere más ventajosas de las soluciones propuestas.
fuertes
2.2.1.3 Selección del proveedor
Objetivo: Seleccionar la oferta mejor y más rentable entre todas las recibidas.
CC SC
Insumos: Ofertas CP SP
CS SS
Actividades:
Para cada oferta:
• Valorar la organización del proveedor5
• Valorar la oferta del proveedor, por ejemplo:
– comprensión de la situación del problema
– soluciones
– plan de entregas
– organización y planes del proyecto
– importes y precios
– cláusulas legales del contrato.
• Comparar las ofertas
• Seleccionar la mejor oferta e informar a los proveedores
Productos: Informe de evaluación del proveedor y notificaciones a los
proveedores
Figura 2.16: Actividades para seleccionar un proveedor.

(ejecutadas por el responsable contractual del cliente)
5 En los procedimientos de licitación restringido y negociado es posible que las

organizaciones de proveedores ya hayan sido evaluadas, en cuyo caso ahora simplemente se
puntualizará esa evaluación. En un proceso de licitación abierto, ésta será la primera
ocasión en que se evaluará a un proveedor.

Capítulo 2
La selección del proveedor consiste en decidir qué proveedor se selecciona en base

a las evaluaciones de las ofertas. La modalidad de evaluación, por ejemplo los
criterios de evaluación y sus grados de importancia, se han determinado en la
preparación de la petición de ofertas. Hay dos decisiones principales que deben
adoptarse:
• En primer lugar, qué ofertas cumplen los requisitos efectivamente (y en
particular, todos los que sean obligatorios). Esta decisión incluye una
evaluación de la situación financiera y la capacidad técnica del proveedor.
• En segundo lugar, es preciso valorar cuál de los proveedores que han
presentado ofertas válidas ofrece la solución económicamente más ventajosa
para los requisitos de compra del SI.
Las ofertas deberán ser completas y correctas desde el punto de vista formal. No se
permite a los proveedores influir o participar en la selección. El resultado de la
selección deberá documentarse en un informe de evaluación del proveedor, tal
como se describe en el apartado 3.2.1, Entregables de licitación y en la plantilla
del anexo D.3. En base al informe de evaluación del proveedor, deberá notificarse
a cada uno de los proveedores que presentan una oferta el resultado del proceso de
selección.
A continuación se ofrece asesoramiento sobre las actividades mencionadas en la

figura 2.16.
Valorar la organización del proveedor

La idoneidad de una organización se suele controlar, en términos generales, Valorar en
haciendo una indicación al respecto en la petición de ofertas (‘Se invita a términos
proveedores cuyas organizaciones reúnan las siguientes características: registro generales la
según la norma EN 29000, capitalización de 1 MECU, etc.’), o bien queda capacidad y
madurez de los
acreditada por la presencia del proveedor en la lista de proveedores cualificados proveedores
del cliente, si ésta se permite. La capacidad de los procesos organizativos puede
valorarse utilizando los criterios extraídos de las especificaciones actualmente
disponibles sobre capacidad de proceso y evaluación de la madurez.
Valorar la oferta del proveedor

La oferta del proveedor deberá valorarse a la luz de los criterios que se hayan Acordar una
determinado en la preparación de la petición de ofertas. Para cada criterio el puntuación para
equipo de evaluación del cliente deberá acordar una puntuación, teniendo en cada criterio
cuenta el grado de importancia. El resultado deberá ser una matriz de evaluación
como la del ejemplo de la figura 2.17.
Es razonable conceder a los proveedores la oportunidad de entrevistarse con el Recibir
cliente durante la evaluación de proveedores y presentar sus ofertas oralmente. presentaciones
Para que todos tengan las mismas oportunidades, el cliente deberá establecer un orales y realizar
límite de tiempo para las entrevistas. Estas reuniones no deberán convertirse en visitas de
referencia
‘discusiones’; se trata de presentaciones de las ofertas, no negociaciones. Muchas
veces también podrá ser una buena idea visitar otras organizaciones que utilicen las

soluciones propuestas después de la entrevista con los proveedores que presentan

la oferta.
Evaluar el plan El ejercicio de evaluación de la idoneidad del plan de adaptación y del plan de
de adaptación y prestación de servicios es muy similar al ejercicio de definición de dichos planes.
el plan de Supone un correcto entendimiento de la situación del problema, aunque puede que
prestación de se hayan identificado riesgos distintos debido a diferencias a la hora de calificar los
servicios
factores situacionales. Dado que la calificación es subjetiva, tiene la máxima
importancia entender su justificación. De este modo se suelen resolver muchos
malentendidos entre el proveedor y el cliente. Cada plan de adaptación deberá
comprobarse de acuerdo con las técnicas de evaluación de la planificación de la
adaptación descritas en el capítulo 4, y cada plan de prestación de servicios deberá
comprobarse de acuerdo con las indicaciones del capítulo 5.
(þ 4.6: Evaluación de un plan de adaptación; 5.2: Servicios de planificación)
Criterios de evaluación Impor- Oferta 1 Oferta 2

tancia
Idoneidad del precio 15 13 11
Idoneidad del calendario 8 7 6
Entendimiento del problema del cliente 12 8 11
Idoneidad del análisis de situación (incluyendo los riesgos) 10 2 9
Idoneidad de la estrategia de gestión de riesgos propuesta 10 3 9
Idoneidad de la secuencia de puntos de decisión 8 5 7
Idoneidad de los entregables 8 5 7
Idoneidad de los métodos propuestos 5 3 4
Idoneidad de la modalidad de gestión de proyecto 5 4 4
Idoneidad de la modalidad de garantía de calidad 7 5 6
Idoneidad de la modalidad de gestión de configuración 2 0 1
Idoneidad de la pericia del equipo de proyecto 10 7 8
Idoneidad de las prestaciones de servicios 10 5 6
Total 110 67 89
Figura 2.17: Ejemplo de una matriz de evaluación de ofertas

(no se incluye la evaluación de la organización del proveedor).
Comparar las ofertas

El resultado de la evaluación de cada oferta mediante una matriz como la de la
figura 2.17 puede proporcionar una primera impresión de cuál es la mejor oferta.
Esta evaluación deberá complementarse con la evaluación general de la
organización del proveedor, para obtener el resultado final de la comparación de
ofertas.
Realizar una Se recomienda el uso sistemático de los criterios de evaluación en la petición de
comparación ofertas. Diferentes personas y grupos de trabajo pueden encargarse de aspectos
general concretos y elaborar una recomendación escrita. Una vez se han evaluado todos
sistemática de los aspectos, podrá llevarse a cabo la comparación general. De este modo se
todos los
aspectos explicitan la evaluación de los aspectos individuales y la valoración final general, al
tiempo que se facilita la gestión de los conflictos de interés que surgen a menudo.

Capítulo 2
Seleccionar la mejor oferta e informar a los proveedores que han presentado

oferta
Deberá seleccionarse la mejor oferta en base al proceso de comparación. Es Utilizar una
importante que la conclusión se base en una evaluación unificada de todo el equipo evaluación
de evaluación. Puede surgir el problema de que varias de las personas que unificada
intervienen en la evaluación, que informan de distintos aspectos, tengan una
opinión muy definida respecto a que una oferta en concreto es claramente la mejor
para el aspecto concreto que les concierne. Sin embargo, no tendrán en cuenta
otros aspectos que escapan a su apreciación. Un proceso de comparación
sistemático como el que se ha descrito anteriormente facilitará una evaluación
unificada.
Todos los resultados y conclusiones de la evaluación deberán constar en un Elaborar un
informe de evaluación del proveedor, cuya finalidad será: informe de
evaluación del
• documentar con quién se debe celebrar el contrato proveedor
• describir el modo en que se ha llevado a cabo la evaluación
• resumir de los puntos clave de la evaluación en que se basa la decisión
• proporcionar un historial e información con fines de auditoría de la compra
del SI.
El informe de evaluación del proveedor constituye la base para las notificaciones
que informan a los proveedores de si han sido seleccionados o rechazados.
2.2.1.4 Preparación del contrato

CC SC
CP SP
Objetivo: Acordar un contrato coherente con los requisitos actuales y que permita CS SS
garantizar el máximo provecho de los fondos presupuestados.

Insumo: Oferta seleccionada
Actividades:
• Alcanzar el acuerdo entre el cliente y el proveedor en torno a:
– objetivos, requisitos y soluciones
– plan de entregas
– organización y planes del proyecto
– importes y precios
– cláusulas legales del contrato
• Firmar el contrato
Producto: Contrato
Figura 2.18: Actividades de preparación de un contrato

(ejecutadas por los responsables contractuales del cliente y del proveedor).
Durante la preparación del contrato, el proveedor y el cliente negocian la forma
final del contrato. Este proceso finaliza con la firma formal del contrato o bien con Firma formal o
la retirada de una de las partes del proceso contractual. Las negociaciones se retirada del
caracterizan por la consideración de las cuestiones conocidas relativas a aspectos proceso de
licitación
técnicos, financieros, de gestión y de calidad, y se lleva a cabo dentro del marco

jurídico de los contratos.
En ciertas situaciones, existirán contratos preliminares que se habrán preparado y
discutido con cada uno de los proveedores que formen parte de la lista en una fase
anterior del proceso de licitación, por ejemplo antes de adoptar la decisión de
adjudicar un contrato al proveedor cuya oferta resulte ganadora (la selección del
proveedor). No obstante, la preparación del contrato corresponde al momento en
que ha finalizado la oferta técnica completa, incluyendo el plan de entregas
contractual.

Capítulo 2
En caso de que la adjudicación de contratos públicos esté sujeta a los reglamentos

de la UE sobre compras públicas y se utilice el procedimiento abierto o restringido,
no se permitirá ningún tipo de negociación posterior a la licitación acerca de
aspectos fundamentales de los contratos, en particular los precios, cuya variación
podría desvirtuar la competitividad. Se permiten discusiones con los proveedores
con la finalidad de clarificar la oferta y los requisitos del cliente, siempre que ello
no conlleve una discriminación de algún proveedor o limite la competitividad. En
esta situación, en función de los resultados de cualquier discusión y clarificación
permitidas, el plan de entregas y las descripciones de los sistemas y servicios
incluidas en la oferta deberán incorporarse al contrato sin sufrir modificaciones
substanciales (aparte de las aclaraciones y añadidos permitidos que se hayan
acordado como resultado de la evaluación de la oferta por parte del cliente). No
existen restricciones a las negociaciones posteriores a la licitación cuando los
contratos se adjudican según el procedimiento negociado.
Tal y como refleja la figura 2.18, las actividades realizadas durante la preparación
del contrato consisten en alcanzar un acuerdo entre el cliente y el proveedor y
firmar el contrato. A continuación se dan orientaciones acerca de las respectivas
funciones del cliente y del proveedor en estas actividades.
Alcanzar el acuerdo entre el cliente y el proveedor

Cada negociación que se emprende6 se caracteriza por la necesidad de una Clarificar o
clarificación, o una solicitud de modificación, de la oferta. Las solicitudes de modificar la
modificación pueden proceder del cliente o del proveedor. oferta del
proveedor
Cuando convenga, la propuesta de contrato del proveedor seleccionado podrá
puntualizarse en los siguientes aspectos, por ejemplo: objetivos, requisitos y
soluciones, plan de entregas, organización y planes del proyecto, importes y
precios, cláusulas legales del contrato.
(þ 3.2.1: Entregables de licitación; anexo D.4: Contrato)
La oferta técnica podrá puntualizarse de todas o de algunas de las maneras
siguientes:
• incorporando los resultados de las negociaciones contractuales en torno a las
soluciones de los sistemas y servicios, por ejemplo puntualizando cada una
de las descripciones de los servicios contractuales, incluyendo las tareas y
responsabilidades de la organización del servicio y del responsable del
servicio
6 En aquellas situaciones contractuales en que no se permita ningún tipo de negociación y no

se pueda tomar la oferta como base del contrato, la única opción disponible es repetir todo
el proceso de licitación.
• A
llevando a cabo actividades de planificación detalladas acerca de las
adaptaciones, como por ejemplo:
− puntualizar la secuencia de puntos de decisión.
− identificar los entregables
− establecer correspondencias adicionales relevantes con otros métodos o
técnicas
− obtención de recursos del proyecto A
• S
llevando a cabo actividades de planificación detalladas acerca de los
servicios, como por ejemplo:
− clarificar las consecuencias para el cliente de la obtención del servicio
− para cada servicio o grupo de servicios asociados, describir la estrategia
contractual de prestación del servicio. S
CC SC El objetivo del cliente es adjudicar un contrato que sea coherente con los requisitos
CP SP
CS SS
actuales y que permita garantizar el máximo provecho de los fondos
presupuestados. El responsable contractual del cliente deberá:
• identificar los puntos fuertes y débiles de la oferta seleccionada
• realizar un análisis de las repercusiones de todo cambio propuesto y solicitar
una modificación de la oferta
• revisar la versión final del contrato
• decidir si el proveedor seleccionado y el contrato propuesto aún satisfacen
los intereses de la organización del cliente.
CC SC
CP SP
CS SS
El objetivo del proveedor es obtener un contrato que esté de acuerdo con los
requisitos de compra del sistema de información negociados con el cliente, al
tiempo que se mantienen los beneficios comerciales identificados en la oferta
original. El responsable contractual del proveedor deberá:
• llevar a cabo un análisis de las repercusiones de un cambio propuesto y

elaborar el plan de entregas, el plan de servicio y el plan del proyecto según
las modificaciones introducidas
• decidir si el contrato propuesto aún satisface los intereses de la organización
del proveedor.
CC SC
CP SP
CS SS
Firmar el contrato

Capítulo 2
Una vez se ha alcanzado al acuerdo final entre el cliente y el proveedor, deberá

firmarse el contrato.
2.2.2 Seguimiento del contrato

El proceso de seguimiento del contrato está encaminado a supervisar las CC SC
adaptaciones y prestaciones de servicios definidas en el contrato, es decir, CP SP
CS SS
asegurarse de que los entregables y los servicios son conformes a los requisitos
especificados.
Al pasar del proceso de licitación al proceso de seguimiento del contrato, la
responsabilidad del cliente sobre la compra del SI pasa de dirigir el proceso a Un proceso
controlar un proceso que dirige el proveedor. dirigido por el
proveedor
A partir de ese, momento la cooperación entre el cliente y el proveedor tiene lugar
en dos niveles separados:
• En el nivel contractual, el proveedor colabora formalmente con el cliente en
todos los puntos de decisión del plan de entregas. En este caso, el cliente
supervisa y controla las actividades del proveedor.
• En el nivel de proyecto/servicio, el cliente proporciona los recursos que
permiten la retroalimentación de los procesos de realización del proyecto y
prestación del servicio. Es decir, el cliente colabora con el proveedor
aportando pericia operativa a la organización del proyecto/servicio a fin de
satisfacer los requisitos del plan de entregas. En este caso, el cliente
garantiza que cumple con sus propias responsabilidades oportunamente.
Este tipo de cooperación es un proceso impulsado por decisiones. En determinados Un proceso
momentos, el cliente y el proveedor toman decisiones relativas a las entregas impulsado por
(entregables y servicios), costes, calendario y otros asuntos contractuales. La decisiones
relación cliente-proveedor en esta situación se define en el plan de entregas, véase
figura 2.19.
Proceso de licitación Proceso de seguimiemnto del contrato
Ejecución de un
punto de decisión
define
El plan de entregas
se realiza en
Plan de entregas
para el proceso de seguimiento del contrato
Puntos de decisión del proceso de seguimiento del contrato
Figura 2.19.: Función del plan de entregas en el seguimiento del contrato

En el proceso de seguimiento del contrato, el plan de entregas sirve de guía para la

Decisiones validación de las entregas y la ejecución de los puntos de decisión. Este proceso se
relativas al subdivide en un conjunto de decisiones relativas al dominio contractual, al dominio
dominio objetivo y al dominio del proyecto/servicio, es decir, relativas al sistema de
contractual, al información que se adapta, al nivel de servicio que se alcanza.
dominio objetivo
y al dominio del A
En las adaptaciones, estas decisiones son cruciales para el cliente, ya que
proyecto/servicio
determinarán las propiedades del estado final del SI, y son igualmente importantes
para el proveedor, ya que determinan el sentido de la adaptación, sus posibilidades
de éxito, costes, etc. A
S
Asimismo, las prestaciones de servicios requieren que se adopten decisiones
acerca de la situación (por ejemplo, la calidad) del servicio prestado y acerca de las
mejoras necesarias para incrementar el nivel de servicio. S
Algunas de las decisiones adoptadas pueden motivar modificaciones del plan de
entregas debidas a cambios de los valores de los factores situacionales, por ejemplo
que el trabajo progresa más deprisa o más despacio de lo esperado.
Ejecución del La ejecución del punto de decisión es el proceso por el que la organización del
punto de cliente emite juicios y adopta decisiones en base a la situación de la compra del SI
decisión en cualquier momento dado. La descripción de los puntos de decisión dentro del
plan de entregas es la que determina la finalidad del punto de decisión, las
actividades a realizar en el punto de decisión, y quién las realiza.
Un punto de decisión se asocia a uno o más intercambios de entregables
procedentes del proveedor o del cliente, y con uno o más servicios prestados por el
proveedor. Estos entregables se especifican en la descripción de los puntos de
decisión, bien como condiciones necesarias, bien como las bases para las
decisiones.
Condición Los entregables especificados como condiciones necesarias deberán entregarse
necesaria: un antes del inicio de la ejecución del punto de decisión. Puede tratarse de entregables
hito de los del dominio objetivo o de entregables de gestión del proyecto y del servicio, y se
entregables utilizan para señalar un momento claramente definido en el contrato. En la
preparación de la toma de decisiones, es preciso comprobar que todos los
entregables sean conformes al plan de entregas. Eurométodo proporciona
orientaciones de cara a este proceso.
Una propuesta La base de una decisión puede consistir en una propuesta de punto de decisión
de punto de (preceptiva) y un informe de situación del contrato. El resultado del punto de
decisión es decisión deberá documentarse siempre en un informe de punto de decisión.
preceptiva
Descripción de Cuando se entrega un conjunto de entregables, el plan de entregas ya ha definido
los puntos de claramente cuáles son las finalidades del punto de decisión asociado y cuáles son
decisión las funciones necesarias. De este modo se consigue una visibilidad mucho mayor de
la progresión del contrato y de las decisiones que deben adoptarse en materia de
inversión, diseño o aceptación de un sistema.
En la figura 2.20 se relacionan las actividades asociadas a la ejecución de un punto
de decisión, y seguidamente se formulan orientaciones para dichas actividades.

Capítulo 2
Objetivo: Evaluar la progresión de la compra del SI y adoptar las decisiones

apropiadas relativas a los entregables y servicios entregados.
Insumos: Contrato (plan de entregas), entregables del dominio objetivo,
entregables de gestión del proyecto y del servicio.
Actividades:
– Validar los entregables del dominio objetivo
– Validar los entregables de gestión del proyecto y del servicio
– Proponer decisiones (alternativas) (propuesta de punto de decisión)
– Informar de la situación del contrato (informe de situación del contrato)
– Adoptar decisiones y comunicarlas (informe de punto de decisión)
– Llevar a cabo las acciones que determinen las decisiones
Productos: Informe de punto de decisión
Figura 2.20: Actividades encaminadas a ejecutar un punto de decisión

dentro del seguimiento del contrato
(ejecutadas por los responsables de un proyecto/servicio).
2.2.2.1 Validar los entregables del dominio objetivo
CC SC
CP SP
CS SS
A
Los entregables del dominio objetivo se componen de elementos operativos
(sistemas) y elementos descriptivos (descripciones del sistema y descripciones de
los servicios), véase apartado 3.4: Entregables del dominio objetivo. Los
procedimientos para garantizar la calidad de los entregables del dominio objetivo
antes de su entrega deberán especificarse en las descripciones de los sistemas
(propiedades de calidad) o en los perfiles de los elementos descriptivos (estado de
calidad), véase apartado 3.6: Elementos descriptivos, y apartado 4.5: Descripción
de los entregables. La organización, procedimientos y calendario de validación
deberán especificarse en la descripción de los puntos de decisión, véase apartado
4.4.3: Describir los puntos de decisión.
La mayoría de los entregables del dominio objetivo los entrega el proveedor al Repercusiones
cliente. En ocasiones es posible que el cliente tenga que realizar una entrega al de la falta de
proveedor. Son ejemplos de ello la entrega de soportes físicos del dominio calidad de los
objetivo, los productos del estado inicial o los paquetes en que se basará la entregables del
cliente
adaptación. En estas circunstancias, el cliente deberá garantizar la calidad antes de
la entrega y el proveedor deberá validar la entrega. La situación generada cuando
la entrega no se realiza a entera satisfacción del proveedor encierra potencialmente
el mismo tipo de repercusiones que la situación en que el cliente rechaza las
entregas que ha realizado el proveedor. A continuación se dan orientaciones acerca
de la situación que se produce cuando el proveedor efectúa una entrega al cliente.

SC
Cuando concluye la fase de producción de varios entregables, el proveedor deberá
CC
CP SP valorar si su estado es suficientemente bueno para entregarlos. La función del
SS
CS proveedor es entregar los entregables que satisfacen las expectativas del cliente,
recibir la aprobación de dichos entregables y, por tanto, el permiso para continuar
con la adaptación. El responsable contractual del proveedor deberá valorar si los
entregables cumplen los requisitos del contrato antes de entregarlos a la
organización del cliente. De ser así, el responsable contractual decide efectuar la
entrega formal.
CC SC Al recibir los entregables, el responsable de proyecto del cliente tiene la función de
SP
CP
CS SS controlarlos, a fin de garantizar que son coherentes con el objetivo de la
adaptación, que consiste en que los entregables finales sean los que precisa la
organización; y de este modo cumplir los requisitos definidos en el contrato. Las
descripciones de los sistemas y los perfiles de los elementos descriptivos también
sirven de base para validar los sistemas y los elementos descriptivos,
respectivamente, después de su entrega. Los siguientes elementos se utilizan como
base para validar entregables:
• La descripción asociada de los puntos de decisión
• Las descripciones asociadas de los sistemas o los perfiles de los elementos
descriptivos
• El estado de calidad de cada entregable para comprobar si cumplen los
requisitos de compra del sistema de información determinados para esta
decisión.
Lista de La siguiente lista de comprobación puede utilizarse para validar los entregables del
comprobación dominio objetivo:
para la (þ 3.5: Elementos operativos; 3.6: Elementos descriptivos)
validación de los
entregables del • ¿Se ha conseguido que el entregable cumpla por completo los requisitos del
dominio objetivo punto de decisión?
• ¿Se ha demostrado que el entregable es idóneo para esta situación, tal y
como afirma el proveedor?
• ¿ Cubren los elementos descriptivos todas las visiones y propiedades
funcionales necesarias para satisfacer los requisitos de la descripción del
punto de decisión?
• ¿Abordan los elementos descriptivos todas las propiedades de calidad y de
inversión necesarias para satisfacer los requisitos de la descripción del punto
de decisión?
• El alcance, nivel de detalle, nivel de acuerdo y grado de formalismo de los
elementos descriptivos, ¿son coherentes con los que se especifican en la
descripción del punto de decisión?
• ¿Se simulan los elementos descriptivos (por ejemplo, con un prototipo) si lo
requiere la descripción del punto de decisión?

Capítulo 2
• La versión del sistema (ya sea actual o futura) que contemplan los elementos
descriptivos, ¿es coherente con la que se especifica en la descripción del
punto de decisión? ¿Existen soluciones alternativas si se solicitan?
• ¿Se han observado todas las normas de coherencia interna y externa de los
elementos descriptivos?
Ejemplo: Una de las reglas de coherencia es que cada uno de los

elementos de datos de un modelo de datos debe aparecer al
menos en una función automatizada. Una de las
comprobaciones de coherencia de la revisión de calidad del
modelo de datos del futuro sistema antes mencionado podría
consistir en verificar que cada elemento de datos se contempla
al menos en una función automatizada.
• ¿Poseen los elementos operativos la funcionalidad y las características de

calidad necesarias? Para validar este aspecto deberán utilizarse métodos de
comprobación, técnicas y herramientas adecuados.
El resultado de la validación deberá documentarse en un informe del proyecto. El
resultado de la validación es la base para elaborar la propuesta de punto de
decisión, véase el siguiente apartado. A
2.2.2.2 Validar los entregables de gestión del proyecto y del servicio
Los responsables del proyecto/servicio del proveedor7 deberán elaborar los CC SC
entregables de gestión del proyecto y del servicio (informes y planes) que exige la CP SP
CS SS
descripción del punto de decisión y entregarlos a los responsables contractuales del
cliente y del proveedor.
S CC SC
Los informes de servicio deberán basarse en mediciones sistemáticas de la
CP SP
calidad de los servicios prestados (los niveles de servicio realizados), por ejemplo CS SS
una medición de referencia realizada por el propio personal del cliente en intervalos
regulares, o deberán repetirse si se considera que el servicio es insuficiente, véase
capítulo 5: Descripción y planificación de servicios. S
Los responsables contractuales deberán validar los planes e informes. Para ello
podrá utilizarse la siguiente lista de comprobación.
• ¿Se ha conseguido que los entregables cumplan por completo los requisitos
del punto de decisión?
• ¿Se ha demostrado que los entregables son idóneos para esta situación, tal y
como afirman el proveedor y los responsables del proyecto/servicio?
7 En ciertos casos, esta tarea la desempeñan los responsables del proyecto/servicio del
proveedor por sí solos, y en otros, los responsables del cliente y del proveedor
conjuntamente. Ello deberá clarificarse en el plan de entregas.
• ¿Incluyen los entregables todas las propiedades y alcanzan el estado de

calidad necesario para satisfacer los requisitos de la descripción de los puntos
de decisión?
La supervisión de una adaptación consiste en supervisar un proceso de cambio
durante el cual van apareciendo entregables del dominio objetivo, mientras que la
supervisión de una prestación de servicios consiste, sobre todo, en garantizar que
un cierto estado, el nivel de servicio pactado, no varía, a menos que ello se solicite
de forma específica.
Generalmente esto significa que la validación de los entregables del dominio
objetivo es una parte fundamental de la supervisión de las adaptaciones
(proyectos), mientras que la supervisión de las prestaciones de servicios tiene lugar
principalmente tomando como base los informes de servicio.
2.2.2.3 Proponer decisiones (alternativas) (propuesta de punto de

decisión)
CC SC Los responsables del proyecto/servicio del proveedor8 deberán elaborar propuestas

CP SP
CS SS
de decisiones, por ejemplo proponer y recomendar varias soluciones para el SI y
los servicios o varios escenarios para las adaptaciones y prestaciones de servicios.
Estas recomendaciones son parte de una propuesta de punto de decisión, pero se
basan en entregables del dominio objetivo y entregables de gestión del
proyecto/servicio (planes e informes).
(þ 3.2.2: Entregables del punto de decisión; anexo D.8: Plantilla de propuesta de
punto de decisión)
Temas de Se abordan temas de planificación como la estimación, organización,
planificación y programación, empleo de personal, coordinación y cálculo de costes, además de
control que temas de control como la supervisión, medición, análisis de la desviación, análisis
deben abordarse de progresión y evaluación, al objeto de desarrollar una conjunto adecuado de
propuestas dentro de la propuesta de punto de decisión.
Decisiones sobre las adaptaciones

Valorar la A
En cuanto a las adaptaciones, las técnicas de planificación de la adaptación
situación del pueden utilizarse para evaluar las repercusiones de problemas concretos; es decir,
problema
el punto de partida para el desarrollo de las propuestas de decisión pasa por una
valoración de la situación del problema. Ello puede dar lugar a que los valores de
los factores de situación difieran de los valores establecidos antes de que se
produjeran los problemas. (þ 4.2.2: Evaluar los factores de situación)
Tipos de Dentro de una propuesta de punto de decisión, el cliente o el proveedor pueden
opciones de proponer varios tipos de opciones:
decisiones
• continuar el proceso de producción según los planes existentes
8 En ciertos casos, esta tarea la desempeñan los responsables del proyecto/servicio del

Capítulo 2
• modificar ligeramente el plan del proyecto

• repasar varios o todos los entregables
• modificar o clarificar los requisitos de compra del SI, registrando los avances
realizados en la comprensión de los objetivos y requisitos contractuales; ello
puede requerir la modificación del contrato
• realizar modificaciones técnicas importantes que precisen cambios radicales
de los requisitos de compra del SI, de los planes y del propio contrato; lo que
motivará una renegociación del contrato
• exigir la suspensión de la concertación contractual.
Si la opción elegida requiere modificaciones del contrato, ello deberá reflejarse en
un informe de situación del contrato, véase la siguiente actividad. A continuación
se estudia con más detalle la opción de repaso de los entregables.
En una situación normal del proyecto, al entregar los entregables se tiene la certeza Opción: repasar
absoluta de que el cliente los aprobará. Sin embargo, es posible que esto no suceda los entregables
siempre en el caso de proyectos vivos, por lo que en determinadas circunstancias
será inevitable repasar los entregables.
Las técnicas de planificación de la adaptación explican cómo minimizar el riesgo de
un repaso no planificado, desarrollando planes de adaptación que se ajusten a una
determinada situación del proyecto y que por tanto se adapten a las situaciones que
se produzcan. Por ejemplo, una situación del problema en la que los requisitos
evolucionan con rapidez puede gestionarse utilizando un plan de adaptación
desarrollado en base a un enfoque experimental de la descripción y un enfoque
evolutivo de la construcción.
(þ 4.3.3: Seleccionar las opciones estratégicas)
No obstante, existen muchas razones por las que un entregable puede entregarse
sin cumplir todos los requisitos previstos. Ello puede deberse a carencias de la
organización del cliente o de la del proveedor. Los siguientes ejemplos provocarían
un repaso de los entregables:
• Los entregables no eran conformes a los requisitos.

• Los rápidos cambios que experimentaron las circunstancias de la
organización del cliente no se tuvieron en cuenta en su totalidad, de manera
que los entregables reflejaban una situación del problema obsoleta.
El repaso de los entregables precisará que los responsables de proyecto del cliente
y del proveedor:
• garanticen que la entrega de los entregables será la esperada.

• valoren la repercusión de los retrasos y los problemas de obtención de
recursos en la adaptación.
• propongan cambios en el plan del proyecto. A

Decisiones sobre las prestaciones de servicios

Necesidad de S
Durante la prestación del servicio, el cliente o el proveedor pueden solicitar un
adaptación de los cambio en el servicio.
servicios
La implementación de estos cambios puede o no formar parte de la prestación del
servicio, en función del plan de prestación de servicios y de la importancia del
cambio. Si el cambio no es importante, puede gestionarse dentro de un servicio de
gestión de cambios.
Si el cambio es demasiado importante, habrá que llevar a cabo una instalación del
servicio. Esto se gestiona mediante un cambio formal del contrato, si éste posee la
flexibilidad suficiente, o bien se celebra un contrato adicional. Normalmente los
contratos de servicio prevén esta flexibilidad. S
2.2.2.4 Informar de la situación del contrato (informe de situación del

contrato)
Los responsables de un proyecto/servicio del proveedor9 deberán elaborar un

informe de situación del contrato cuando así lo requiera la descripción del punto de
decisión, o cuando la situación exija decisiones relativas al contrato.
(þ 3.2.2: Entregables del punto de decisión; anexo D.9: Informe de situación del
contrato)
Habrá que informar de la situación general de todas las adaptaciones y prestaciones
de servicios que se están llevando a cabo actualmente. Cualquier desviación del
plan de entregas deberá reflejarse en el informe, junto con las propuestas de
acciones correctivas y cambios del plan de proyecto y del plan de servicio. Todas
las propuestas de modificación del contrato deberán estar argumentadas. Pueden
producirse cambios del plan de entregas, de las descripciones de los sistemas, de
las descripciones de los servicios o de otros elementos del contrato.
Deberá presentarse y explicarse todo desacuerdo entre el responsable de proyecto
del cliente y el del proveedor para que lo resuelvan los responsables contractuales.
CC SC En los siguientes capítulos figura más información sobre la necesidad de un control
CP SP
CS SS
de los cambios contractuales, incluyendo los casos de renegociación del contrato y
cumplimentación anormal del contrato.
Control de cambios contractuales

Planificado bajo El control de cambios contractuales puede planificarse en el plan de entregas: éste
contratos es el caso de los contratos flexibles, véase apartado 2.1.2.3: Opción: determinar la
flexibles flexibilidad de los contratos, donde el plan de entregas incluye puntos de decisión
de inversión específicos para puntualizar los requisitos de compra del SI. El control
de cambios deberá realizarse de acuerdo con los procedimientos de control de los
cambios especificados en el contrato.
9 En ciertos casos esta tarea la desempeñan los responsables del proyecto/servicio del

Capítulo 2
Importante: • El proceso de control de los cambios contractuales

debe estar descrito en el contrato.
El control de los cambios contractuales también puede ser activado durante el
proceso de seguimiento del contrato, ya sea por el cliente, ya sea por el proveedor,
cuando se detectan riesgos técnicos o de planificación que no se pueden gestionar
claramente con la solución técnica del contrato existente. A menudo, el control de
los cambios contractuales tiene lugar tras la evaluación de varios entregables o de
la propia realización del proyecto/prestación del servicio, en la que se identifican
cambios contractuales a fin de reducir una amenaza.
El control de los cambios contractuales consiste en que ambas partes contratantes Pequeños
acuerdan cambios de los requisitos del SI o de otros elementos del contrato. cambios del
Normalmente estos cambios suponen una pequeña modificación o clarificación de contrato
un requisito ya existente. En la inmensa mayoría de los casos, los cambios
efectuados no repercuten substancialmente en el contenido y la intención del
contrato. Simplemente se registran los avances que se producen en la comprensión
de los objetivos y los requisitos contractuales.
La siguiente lista de comprobación permite identificar situaciones en las que puede
ser necesario un control de los cambios contractuales.
• ¿Algún aspecto de la solución técnica precisa una mayor clarificación?
• ¿Alguna parte del proceso de seguimiento del contrato ha generado la
necesidad de llevar a cabo alguna mejora o actualización de los requisitos de
compra del SI?
• ¿Alguna de las especificaciones del contrato ya no es aplicable a la compra
del SI y conviene eliminarla para evitar posibles confusiones?
En base a la experiencia podrán identificarse otras situaciones. Ejemplos de los
cambios que pueden efectuarse:
• llevar a cabo un nuevo análisis de la situación del problema y comprobar si
las conclusiones iniciales acerca de las estrategias de adaptación y de
prestación de servicios siguen siendo válidas.
Los cambios de los planes deberán efectuarse en base a este análisis. Por ejemplo:
• posponer algunas de las entregas definidas en el plan de adaptación y en el
plan de prestación de servicios
• redefinir las responsabilidades dentro del plan de adaptación o del plan de
prestación de servicios
• introducir puntos de decisión adicionales.
En ciertas circunstancias puede que se precisen cambios técnicos importantes que Renegociación
requieran modificaciones radicales de los planes y del propio contrato. No del contrato
obstante, cualquier renegociación de asuntos contractuales, por ejemplo el
calendario jurídico y financiero, deberá gestionarse en base a las prácticas
empresariales habituales (que se encuentran fuera del alcance de Eurométodo).
Normalmente, las modificaciones del contrato tienen que ser firmadas por personas
equiparables a las que firmaron los contratos originales.
La Directiva de Servicios (92/50/CEE) establece que si un cliente introduce algún

cambio fundamental en un requisito después de presentar la petición de ofertas,
deberá volver a presentarla. Si después de haberse adjudicado el contrato se
identifica uno o más requisitos adicionales distintos de los que incluía la petición de
ofertas original, dichos requisitos sólo podrán adjudicarse al proveedor original sin
necesidad de volver a presentar una petición de ofertas en le caso de que por
razones imprevistas se hayan hecho absolutamente necesarios para la ejecución del
contrato, o por motivos técnicos o económicos imperiosos causarían grandes
perjuicios al cliente si se adjudicara el contrato a otro proveedor dentro de un
límite del 50% del valor original del contrato.
Posibles escenarios en los que puede hacerse necesaria la renegociación del
contrato:
• el cliente detecta que los requisitos de los entregables y servicios
mencionados en el contrato ya no concuerdan con los objetivos del negocio
y, por tanto, desea cambiarlos al objeto de garantizar que reciba los
entregables y servicios necesarios
• el cliente detecta que el proveedor no cumple los requisitos de los
entregables y servicios
• el proveedor detecta que las expectativas reales del cliente no son coherentes
con los requisitos establecidos y, por tanto, desea introducir cambios
significativos en el contrato a fin de evitar riesgos al aceptar el trabajo
• el proveedor determina que el desarrollo del sistema o la prestación de
servicios no es viable.
En los entornos jurídicos en que los contratos estén sujetos a las reglas de la
UE relativas a las compras públicas, o a ciertas circunstancias excepcionales,
no se permitirá ningún tipo de renegociación (que no ampliación) del contrato
si no se vuelve a presentar una petición de ofertas. En tal situación, los
requisitos de compra del SI serán invariables para toda la duración del
contrato.
Cumplimentación En las siguientes situaciones se considera que las prestaciones de una de las partes
anormal del contratantes perjudica a la progresión del contrato.
contrato
• Se considera que las prestaciones del proveedor son parcial o totalmente
insatisfactorias de cara a la consecución de los objetivos del contrato. Por
consiguiente, el cliente podrá solicitar que se suspenda el acuerdo
contractual con el proveedor.
• Resulta que una de las partes contratantes ha incumplido el contrato.
En estas circunstancias, es posible que el control de los cambios contractuales
junto con una renegociación del contrato no sea suficiente para salvar la situación.
Entonces podrá recurrirse a la cumplimentación del contrato como parte de la
cancelación de la compra del SI, véase apartado 2.2.3: Cumplimentación del
contrato.

Capítulo 2
2.2.2.5 Adoptar decisiones y comunicarlas (informe de punto de

decisión)
El propio proceso de toma de decisiones es un proceso cooperativo en el que CC SC
participan activamente el responsable contractual del cliente y el del proveedor. CP SP

CS SS
Son posibles varios procesos de toma de decisiones, por ejemplo:

• El responsable contractual del cliente es quien toma las decisiones, mientras que
el responsable contractual del proveedor actúa como asesor y controla si las
decisiones del cliente son conformes a los acuerdos contractuales.
• El responsable contractual del cliente y el del proveedor comparten la
responsabilidad de la toma de decisiones.
Se aplicarán la organización y procedimientos previstos en la descripción del punto
de decisión. Podrán utilizarse todas las técnicas de toma de decisiones: decisiones
en grupo, simulaciones, previsiones, análisis de riesgos, análisis de costes y
beneficios, etc.
(þ 4.4.3: Describir los puntos de decisión)
Informar de las decisiones

Los responsables de proyecto/servicio del cliente y del proveedor deberán registrar CC SC
conjuntamente todas las decisiones que contenga un informe de punto de decisión CP SP

CS SS
y distribuirlo convenientemente.
(þ 3.2.2: Entregables del punto de decisión; anexo D.10: Informe de punto de
decisión)
Es preciso documentar con todo rigor cualquier cambio que se produzca en los Registrar los
requisitos de compra del sistema de información, ya se haya decidido a raíz de un cambios de los
control planificado de cambios contractuales (en un punto de decisión de requisitos
inversión), ya se haya acordado al amparo de un control de los cambios
contractuales activado por las circunstancias. Para asegurar una cumplimentación
efectiva del contrato es importante una gestión estricta de las versiones.
2.2.2.6 Llevar a cabo las acciones que determinen las decisiones
Los entregables del dominio objetivo y los planes del proyecto y del servicio CC SC
CP SP
deberán revisarse de acuerdo con las decisiones. Asimismo, en el informe de punto CS SS
de decisión podrán identificarse varias acciones correctivas. Estas acciones podrá
realizarlas, por ejemplo, la organización del proveedor a fin de mejorar sus
procesos.
De este modo, las decisiones pueden motivar la instigación de un programa de Puede iniciarse
mejora de procesos que se desarrolle paralelamente a las adaptaciones y las un programa de
prestaciones de servicios. Las cuestiones relativas a la mejora de procesos podrán mejora de
tratarse con las técnicas definidas en las especificaciones actualmente disponibles procesos
sobre evaluación de la capacidad y la madurez del proceso.

Como Eurométodo ofrece los medios para clarificar el proceso de entrega y la

Registrar las
experiencias
adopción de decisiones que comporta, proporciona un marco ideal en el que reunir
para utilizarlas las experiencias de adaptaciones y prestaciones de servicios. En particular, facilita
en compras el registro de todo lo necesario en un entregable que contenga un producto
futuras particular del método para soportar una decisión particular, y, a la inversa, lo que
no es necesario. Así pues, el cliente y el proveedor tienen los medios para utilizar
sus observaciones como ayuda para adaptar el proceso de toma de decisiones a la
medida de las exigencias de futuros contratos. Por consiguiente, podrá mejorarse la
descripción de los entregables necesarios en futuras compras.
Cómo mejorar la Para cada punto de decisión deberán tenerse en cuenta los siguientes aspectos.
descripción de
los puntos de • ¿Qué partes del entregable (y por tanto los productos del método que lo
decisión constituyen) se ha observado que facilitan el proceso de toma de decisiones?
• ¿Se ha observado en el entregable algún concepto que no facilite el proceso
de toma de decisiones?
• ¿Cumple el entregable con igual efectividad todos los requisitos de la
descripción del punto de decisión?
• Para aquellos aspectos de la descripción del punto de decisión que el
entregable no cumplió con efectividad, ¿qué habrá que hacer en el futuro
para obtener un entregable de mejor calidad?

Capítulo 2
2.2.3 Cumplimentación del contrato

Objetivo: Garantizar que se han resuelto satisfactoriamente todas las cuestiones CC SC
técnicas y comerciales pendientes relativas a este contrato de compra del SI CP SP

CS SS
Insumo: Informe del proyecto e informe de gestión del servicio.

Actividades:
• Informar de la situación del contrato (informe de situación del contrato)
– aspectos técnicos, comerciales y jurídicos
– dependencias de otras actividades
• Adoptar las decisiones de cumplimentación del contrato
• Informar de las decisiones (informe de cumplimentación del contrato).
Producto: Informe de cumplimentación del contrato
Figura 2.21: Actividades encaminadas a cumplimentar un contrato

(ejecutadas por los responsables contractuales del cliente y del proveedor).
Con la cumplimentación del contrato se pretende el cierre formal de todos los
entregables y los asuntos pendientes del contrato, de manera que se pueda cancelar
de forma efectiva el acuerdo contractual entre un cliente y un proveedor.
Representa el final de todas las adaptaciones y servicios contemplados en el
contrato y, por tanto, el final de la relación temporal cliente-proveedor que se
inició con motivo de la compra del SI.
Los responsables contractuales deberán comprobar que se han realizado La
efectivamente todas las entregas y que ambas partes han cumplido todas sus cumplimentación
obligaciones. Todas las cuestiones pendientes (por ejemplo, pagos, transmisión de del contrato es
la propiedad, garantía, etc.) deberán resolverse antes de cancelar el contrato. La un proceso
administrativo
cumplimentación del contrato es un proceso administrativo que controla si se han
cumplido de forma satisfactoria todos los requisitos de compra del SI.
Las actividades encaminadas a la cumplimentación del contrato se relacionan en la
figura 2.21.
Normalmente, la cumplimentación del contrato precisa la cumplimentación del plan
de entregas, que se produce cuando concluyen todos los entregables y decisiones
contractuales, véase figura 2.22.

Proceso de seguimiento Proceso de cumplimentación

Ejecución del
punto de decisión n Cumplimentación
del contrato
Plan de entregas
concluido en
Punto de decisión de cumplimentación del contrato
dentro del plan de entregas
Figura 2.22: Función del plan de entregas en la cumplimentación del contrato.
2.2.3.1 Informar de la situación del contrato (informe de situación del

contrato)
CC SC
CP SP
CS SS
En base al informe de proyecto y al informe de gestión del servicio, los

responsables del proyecto/servicio del proveedor10 deberán elaborar un informe
final de situación del contrato que sustente las decisiones de cumplimentación del
contrato. Los siguientes elementos de la lista de comprobación deberán tenerse en
cuenta al desarrollar la base para estas decisiones:
(þ 3.2.2: Entregables del punto de decisión; anexo D.9: Informe de situación del
contrato)
Aspectos • Aspectos técnicos:
técnicos − ¿Han finalizado todos los planes de adaptación y los planes de prestación
de servicios?
− ¿ Se han modificado todos los elementos operativos de acuerdo con los
resultados de las pruebas de recepción a fin de garantizar que el sistema
operativo funciona perfectamente?
− ¿Se ha proporcionado a ambas partes toda la información de planificación
previamente pendiente acerca de futuras adaptaciones y prestaciones de
servicios en estudio?
10 En ciertos casos esta tarea la desempeñan los responsables del proyecto/servicio del

Capítulo 2
− ¿Se ha cumplimentado y entregado toda la documentación de revisión de

calidad?
− ¿Se ha ultimado y entregado toda la documentación de usuario?
• Aspectos comerciales y jurídicos: Aspectos
− ¿Se han abonado todos los subcontratos? comerciales y
− ¿Se han emitido todas las facturas a las organizaciones pertinentes? jurídicos
− ¿Se han presentado todas las declaraciones de costes?
− ¿Se han completado todos los trámites de transmisión de la propiedad?
A menudo, la cumplimentación del contrato puede ejecutarse paralelamente a una Dependencias
o más actividades. Por ejemplo, se pueden iniciar nuevas negociaciones respecto a otras
contractuales (o quizá presentar una nueva petición de ofertas) para abordar el actividades
tema de las relaciones poscontractuales, es decir, iniciar una nueva compra de un
sistema de información o finalizar el servicio de mantenimiento o de garantía. Otro
ejemplo es el caso de una cancelación anormal de la compra del SI. En este caso, la
ejecución de este proceso puede tener lugar al mismo tiempo que la renegociación
del contrato.
Estas relaciones deberán tenerse en cuenta al desarrollar la propuesta de punto de
decisión, a fin de garantizar que la relación con el proveedor sea coherente y
gestionable.
2.2.3.2 Adoptar decisiones de cumplimentación del contrato
Las decisiones de cumplimentación basadas en el informe de situación del contrato CC SC
deberán adoptarse teniendo en cuenta los aspectos técnicos y comerciales en el CP SP

CS SS
contexto de una cumplimentación programada o no programada, tal y como se
menciona en el apartado 2.2.2.4: Informar de la situación del contrato.
En cualquiera de las dos situaciones, el responsable contractual del cliente deberá
trabajar en cooperación con el responsable contractual del proveedor, al objeto de
ir cancelando todos los aspectos técnicos, de gestión y financieros de la adaptación
de una manera progresiva y controlada, tal y como recomienda el informe de
situación del contrato.
El responsable contractual del cliente cancela la relación contractual con el CC SC
proveedor sin olvidar las repercusiones en el negocio de las tareas residuales de CP SP

CS SS
tipo técnico y comercial, y registra todas las experiencias importantes relativas a la
compra del SI.
El responsable contractual del proveedor asegura que el contrato expira en el
momento debido, dejando una puerta abierta a posibles oportunidades de negocio
en el futuro.
2.2.3.3 Informar de la cumplimentación del contrato

(informe de cumplimentación del contrato)
Los responsables del proyecto/servicio del cliente y del proveedor

deberán colaborar en la realización de un informe de cumplimentación del contrato,
véase una descripción del mismo en el apartado 3.2.3: Entregables del punto de
decisión. La finalidad del informe es registrar todas las decisiones adoptadas
durante la cumplimentación del contrato y reflejar hasta qué punto el contrato ha
conseguido sus objetivos de negocio, incluyendo los beneficios previstos; además
de identificar las lecciones a extraer en vista de futuras compras de un SI.
(þ 3.2.3: Entregables del punto de decisión: Informe de cumplimentación del
contrato)
El informe de cumplimentación del contrato no se presenta hasta el final del
período del contrato. Antes de que expire el contrato es posible que hayan
finalizado una o más adaptaciones y servicios.
Registrar las ¿Qué lecciones deben extraerse de esta compra del SI para ser utilizadas en
experiencias futuras compras de SI?
para utilizarlas
en futuras Eurométodo proporciona un marco que permite extraer experiencias para su uso
compras de SI posterior en un contrato, dominio objetivo o dominio del proyecto/servicio, y
registrar posteriormente lo que se precisa para sustentar el proceso de toma de
decisiones que requieren las relaciones cliente-proveedor. Este marco puede
aplicarse en la cumplimentación del contrato para considerar en su totalidad la
compra del SI.
El cliente dispone de los medios para utilizar sus propias observaciones a fin de
establecer los requisitos de futuras adaptaciones y prestaciones de servicios, y de
ese modo formular mejor las exigencias del proceso de toma de decisiones de
futuras compras de un SI.
El proveedor dispone de los medios para utilizar sus propias observaciones a fin de
desarrollar futuros procesos de producción, y de ese modo cumplir mejor las
exigencias del proceso de toma de decisiones de futuras compras de un SI.
Asimismo, el cliente y el proveedor tienen la oportunidad adicional, dentro del

proceso de cumplimentación del contrato, de realizar una síntesis de toda la
relación cliente-proveedor, y de esta manera contar con una referencia de lo que
sería la buena práctica en esta área tan compleja.
El objetivo es aprender de la experiencia: para sustentar el proceso de decisión
en futuras compras de SI, y para evitar el riesgo de que la calidad de los SI o
servicios adaptados que se compren sea mala o insuficiente.

Capítulo 2
Esta revisión de cumplimentación del contrato puede utilizar de nuevo las listas de
comprobación relativas a las lecciones extraídas de cada punto de decisión del
proceso de seguimiento del contrato.

3 Entregables
En este capítulo se formulan orientaciones para la descripción de entregables.
Deberían leerlo los responsables de proyecto de los clientes y de los proveedores.
En el transcurso de una adquisición se suele acceder a él desde los capítulos 2, 4 y
5 a través de las referencias apropiadas.
Los conceptos de entregables de Eurométodo permiten caracterizar los entregables
que intercambian clientes y proveedores en toda compra de SI. Todos los
entregables, tanto los entregables de adaptación como los entregables de
prestación de servicios, se describen con el mismo conjunto de conceptos.
3.1 Tipos de entregables

Se definen tres tipos de entregables:
• entregables del dominio contractual
• entregables de gestión
• entregables del dominio objetivo.
En los siguientes capítulos se explican estos tipos de entregables.
3.1.1 Entregables del dominio contractual

Los entregables del dominio contractual se utilizan para definir y controlar el
proceso contractual de compra de un SI.
Existen dos tipos de entregables del dominio contractual:
• entregable de licitación, y
• entregable de punto de decisión.
3.1.2 Entregables de gestión

Los entregables de gestión se utilizan para planificar y controlar los proyectos y las
prestaciones de servicios. Los entregables de gestión se dividen en dos tipos:
• los entregables de gestión del proyecto se utilizan para planificar y controlar
los proyectos de adaptación
• los entregables de gestión del servicio se utilizan para planificar y controlar
las prestaciones de servicios.
Existen dos tipos de entregables de gestión:
• un plan, o
• un informe.

d
od
m
e
n
lii
Capítulo 3
Entregables
3.1.3 Entregables del dominio objetivo

Los entregables del dominio objetivo son sistemas o documentos relacionados con
el dominio objetivo de una adquisición. Los puede entregar el proveedor al cliente,
o viceversa.
Existen dos tipos de entregables del dominio objetivo:
• elemento operativo:
un sistema (o componente de un sistema) entregado que es o será instalado
como parte del dominio objetivo.
• elemento descriptivo:
un documento entregado que recoge conocimientos relativos al dominio
objetivo.
Los elementos descriptivos pueden utilizarse para describir sistemas y
servicios. Un elemento descriptivo facilita el proceso de toma de decisiones
relativas a una adaptación o prestación de servicios, es decir, especifica lo
que debería hacer y cómo debería ser el diseño de la organización del
dominio objetivo y/o su sistema de información.
La figura 3.1 muestra los principales tipos de entregables arriba mencionados.
Figura 3.1: Principales tipos de entregables.
3.2 Entregables del dominio contractual

Un contrato es un acuerdo vinculante con valor legal entre dos partes (o un
acuerdo similar dentro de una organización), para el suministro de un servicio o
para el suministro, desarrollo, producción, manejo o mantenimiento de un sistema
[ISO-LCP].

Por tanto, el dominio contractual es la suma de aquellas partes de la organización

del cliente y del proveedor que se encuentran vinculadas temporalmente por los
requisitos particulares de un contrato de compra de un sistema de información.
Dentro de una adquisición pueden existir varias compras de SI. Una compra de SI
puede contener una o más adaptaciones o prestaciones de servicios.
Dentro de una compra de SI, los entregables del dominio contractual sustentan la
relación entre:
• un cliente y su proveedor a nivel contractual, es decir, la función de gestión
del contrato dentro de la gestión de la adquisición
• el responsable contractual y el responsable del proyecto/servicio.
Existen dos tipos de entregables del dominio contractual:
• entregable de licitación, y
• entregable del punto de decisión.
El contenido preceptivo de todo entregable del dominio contractual se puede
caracterizar mediante un subconjunto de propiedades del dominio contractual. Es
decir, estas propiedades representan el contenido lógico de todo entregable del
dominio contractual.
3.2.1 Entregables de licitación

Un entregable de licitación se produce como parte del proceso de licitación dentro
de una compra de SI. Los entregables de licitación establecen requisitos para todas
las adaptaciones y prestaciones de servicios de una compra de SI.
Plantillas En el anexo D figuran plantillas para todos los entregables del dominio contractual.
3.2.1.1 Tipos de entregables de licitación
Petición de ofertas (þAnexo D.1)

Es el entregable que contiene aquellas partes de los requisitos de compra de SI que
se facilitan a los proveedores potenciales. Los requisitos de compra de SI
contienen descripciones del sistema, descripciones de los servicios, el plan de
entregas y los planes de proyecto/servicio (opcional).
Oferta (þAnexo D.2)

Es el producto que contiene la propuesta técnica de un proveedor potencial para
satisfacer los requisitos de adaptación o de servicio de una adquisición en concreto,
tal como se definen en la petición de ofertas.
Informe de evaluación del proveedor (þAnexo D.3)

Es el producto que registra los resultados de la selección del proveedor. Contiene
la puntuación otorgada a cada proveedor potencial según los criterios de
evaluación del proveedor. Registra qué oferta es la mejor y la más rentable en la
práctica. En él se basan las notificaciones que se envían a cada proveedor para
comunicarle si ha sido aceptado o rechazado.

Capítulo 3
Entregables
Contrato (þAnexo D.4)

Un acuerdo vinculante con valor legal entre dos partes (o un acuerdo similar
dentro de una organización), para el suministro de un servicio o para el suministro,
desarrollo, producción, manejo o mantenimiento de un sistema.
Los siguientes planes se presentan como elementos de los entregables de

licitación arriba descritos. Cada plan experimenta una transformación: de la
versión solicitada se pasa a la versión propuesta, y de ella a la versión
contractual, a medida que se adquieren más conocimientos y la compra del SI
avanza a través del proceso de licitación.
Plan de entregas (þAnexo D.5)

Como parte integrante de la petición de ofertas, la oferta o el contrato en versiones
cambiantes: versión solicitada, versión propuesta, versión contractual.
Se trata del entregable que define la relación contractual cliente-proveedor durante
una compra de un SI. Cada contrato, oferta y petición de ofertas contienen un solo
plan de entregas.
El contenido de un plan de entregas se describe en la figura 3.2 y las relaciones
entre los planes que incluye un plan de entregas se indican en la figura 3.3.
Plan de adaptación (þAnexo D.6)

Un plan de adaptación es un plan para una adaptación singular que se lleva a cabo
dentro de una compra de SI. Define la situación del problema incluyendo el estado
inicial y el estado final de la adaptación, la estrategia de adaptación, la secuencia de
puntos de decisión y los entregables durante el seguimiento del contrato. Cada plan
de entregas contiene uno o más planes de adaptación.
Como parte de una adaptación también se pueden producir planes de adaptación
para futuras adaptaciones del SI. Por ejemplo, un plan para una adaptación que
lleve a cabo el diseño detallado de un SI, o que ejecute la construcción o
instalación del SI, mientras se realiza un estudio de viabilidad del mismo en la
adaptación actual.
En Eurométodo, el término plan de adaptación suele designar la adaptación actual.
Si el plan de adaptación se refiere a una adaptación futura, se utiliza un término
específico: plan de adaptación de una futura adaptación, o plan de adaptación
futura.
Plan de prestación de servicios (þAnexo D.7)

Un plan de prestación de servicios es un plan para la prestación de un único
servicio o de un grupo de servicios asociados dentro de una compra de SI. Define
el estado inicial y el estado final de la instalación del servicio y de la cancelación
del servicio, la estrategia de prestación del servicio, la secuencia de puntos de
decisión y los entregables durante el seguimiento del contrato.

Los planes de entregas, los planes de adaptación y los planes de prestación de

servicios contienen descripciones de puntos de decisión. La plantilla de estas
descripciones figura en el anexo D.21.

Capítulo 3
Entregables
Plan Contenido
Para cada plan de entregas • Suma de puntos de decisión relativos a cada
adaptación y cada prestación de servicios que tiene
lugar en una compra de SI.
• Punto de decisión relativo al proceso de
cumplimentación del contrato.
• Planes de adaptación de una compra de SI.
• Planes de prestación de servicios de una compra de
SI.
• Dependencias entre todos los planes de adaptación y
los planes de prestación de servicios de una compra
de SI.
Para cada plan de adaptación • Situación del problema
Una descripción del estado inicial y del estado final, y
una descripción de los factores de situación y los
riesgos
• Estrategia de adaptación (opcional)
− enfoques del desarrollo para la descripción,
construcción e instalación
− enfoque del control del proyecto
− contramedidas para reducir los riesgos
• Secuencia de puntos de decisión
La secuencia de los puntos de decisión necesarios.
• Descripción de los puntos de decisión
Descripciones de los puntos de decisión necesarios y
de los entregables asociados
Para cada plan de prestación • Situación del problema
de servicios − Resumen del servicio
− Estado inicial y estado final de la instalación del
servicio
− estado inicial y estado final de la cancelación del
servicio
− apreciación de la situación (factores de situación y
riesgos)
• Estrategia de prestación del servicio
− enfoques de la instalación y cancelación
− enfoque del control del servicio
− contramedidas para reducir los riesgos
• Secuencia de puntos de decisión
La secuencia de los puntos de decisión necesarios.
• Descripciones de los puntos de decisión
Descripciones de los puntos de decisión necesarios y
de los entregables asociados
Figura 3.2: Contenido de un plan de entregas

Figura 3.3: Relaciones entre el plan de entregas, el plan de adaptación y el plan de

3.2.1.2 Propiedades de los entregables de licitación
La figura 3.4 refleja una relación completa de las propiedades del dominio
contractual que deben aparecer en cada uno de los entregables de licitación.

Capítulo 3
Entregables
Entregable de licitación Petición de Oferta Informe de Contrato

ofertas evaluación
Propiedad contractual Descripción del
proveedor
Suma de las descripciones del √ √ √
Representación del __
dominio objetivo para cada (Visión del
dominio objetivo de la
adaptación y cada prestación de proveedor)
compra de SI
servicios dentro de la compra de
SI.
Proporciona el contexto esencial √ √ √ √
Objetivos de negocio,
en el que tiene lugar una compra (+ solución)
necesidades y objetivos
de SI
de la adquisición
Por ejemplo, normas, √ √
Imperativos y __ __
arquitectura, etc.
procedimientos
(estratégicos)
organizativos
El conjunto formado por el plan
Requisitos de compra de
de entregas, las descripciones de
SI:
los sistemas, las descripciones de
los servicios, el plan de proyecto
y el plan de servicio, que
describen los requisitos de una
compra en particular dentro de
una adquisición
Plan de Entregable del dominio √ √ √
__
contractual que define las (Solicitado) (Propuesto) (Contrato)
entregas adaptaciones contractuales y las
prestaciones de servicios durante
una compra
Descripciones Descripciones de los entregables √ √ √
__
de los elementos operativos (Global/ (Detallada) (Detallada)
de los sistemas (elementos descriptivos) de que detallada)
dispone el proyecto; esto puede
incluir los elementos
descriptivos del SI en su estado
inicial y de futuros SI
Descripciones Descripciones de los servicios o √ √ √
__
procesos (elementos (Global/ (Detallada) (Detallada)
de los servicios descriptivos) de que dispone la detallada)
prestación de servicios; esto
puede incluir los elementos
descriptivos de
servicios/procesos en su estado
inicial y de futuros
servicios/procesos
Plan de Para adaptaciones: planes de √ √ √
__
desarrollo, planes de (Opcional) (Opcional) (Opcional)
proyecto y plan aseguramiento de la calidad,
del servicio planes de gestión de
configuración.
Para servicios: planes de nivel de
servicio , planes de recursos de
servicio, planes de funciones de
servicio
Por ejemplo, interrupción del √ √
Imperativos ___ __
pago, lanzamiento de producto y (Opcional)
organizativos que
fechas de implementación de la
pueden afectar al plan
reorganización.
del proyecto
Imperativos sobre costes, fechas √ __
Imperativos financieros / __ __
de pago, etc.
presupuesto


ofertas evaluación
proveedor
Cargos y costes • Los cargos y costes que __ √ √

percibe o acumula un
proveedor al cumplir los
requisitos de una compra de
SI.
• Procedimiento de variación
de cargos durante el período
del contrato
Cláusulas jurídicas • Criterios de adaptación y √ √ __ √
• Condiciones de pago
• Garantías de cumplimiento
de las obligaciones
• Limitación de la
responsabilidad
• Derechos de propiedad
intelectual
• Propiedad del hardware,
software y licencias
• Seguridad y
confidencialidad
• Condiciones de rescisión del
contrato
• Normativa aplicable
• En caso de conflicto, quién
actuará como árbitro
independiente
• Control de la
subcontratación
etc.
Orientación y referencias acerca √ __
Instrucciones a los __ __
del formato, modo de envío y
licitantes
fechas límite
Por ejemplo, situación √ √ √ __
Características
financiera, experiencia de (Requisitos) (Conformida (Conformida
organizativas del
negocio, experiencia con el d) d)
proveedor
dominio, certificado ISO9000
Enfoque de evaluación • Tabla de evaluación √ __ √ __

del proveedor (criterios, atributos y (Completo)
justificaciones)
• Procedimiento para realizar

la evaluación de las ofertas
Descripciones del proyecto y de __ √ √
Organización del __
las organizaciones de servicios (Opcional)
proveedor
Establecer las funciones y __ __ √ __
Funciones y
responsabilidades de la pericia
responsabilidades del
operativa y del responsable
equipo de evaluación
organizativo en la selección del
proveedor
Declaración de qué proveedor se __ __ √ __
Recomendaciones
prefiere; y recomendaciones para
acerca del proveedor
mejorar la oferta
preferido

Capítulo 3
Entregables

ofertas evaluación
proveedor
Procedimientos para proponer, √ √ __ √
Procedimientos de
aprobar y llevar a cabo cualquier (Opcional) (Opcional)
control de cambios
cambio del contrato, incluyendo
contractuales
cambios de los requisitos de los
entregables y servicios,
calendario, importes y otras
condiciones contractuales
Autorización del contrato por los __ __ __ √
Firmas del contrato
responsables contractuales o la
alta dirección
Figura 3.4: Propiedades del dominio contractual en los entregables de licitación

3.2.2 Entregables de punto de decisión

Un entregable de punto de decisión sustenta la relación cliente-proveedor y el
proceso de toma de decisiones como parte del seguimiento del contrato durante las
adaptaciones y prestaciones de servicios.
3.2.2.1 Tipos de entregables de punto de decisión
Propuesta de punto de decisión (þAnexo D.8)

Un entregable que define los costes y beneficios de diferentes negocios, y las
opciones técnicas y financieras a considerar en un punto de decisión. Una
propuesta de punto de decisión puede proponer opciones relativas a una
adaptación, una prestación de servicios o ambas.
Como base de una decisión, describe el posible resultado de un punto de decisión
en los términos de las decisiones (y recomendaciones) hechas en ese punto de
decisión; por ejemplo, soluciones alternativas para soportes físicos y lógicos.
Informe de situación del contrato (un subtipo de propuesta de punto de decisión)

(þAnexo D.9)
Un entregable que describe la situación de un contrato con respecto a los requisitos
contractuales definidos en el plan de entregas, para su consideración en un punto
de decisión. Es decir, el informe de situación del contrato informa de todas las
adaptaciones y prestaciones de servicios definidas en el plan de entregas.
Este informe facilita la valoración de los riesgos asociados a la compra y la
definición de las acciones correctivas necesarias en el seguimiento del contrato.
Informe de punto de decisión (þAnexo D.10)

Un entregable que describe el resultado de un punto de decisión en los términos de
las decisiones (y recomendaciones) hechas en ese punto de decisión. Un informe de
punto de decisión puede incluir decisiones relativas a una adaptación, una
prestación de servicios o ambas.
Informe de cumplimentación del contrato (un subtipo de informe de punto de

decisión) (þAnexo D.11)
Un entregable que registra si el contrato ha satisfecho efectivamente sus objetivos
de negocio, incluyendo los beneficios previstos, e identifica lecciones a extraer en
vista de futuras compras de SI y gestiones contractuales.
El informe de cumplimentación del contrato no se presenta hasta el final del
período contractual. Antes de ese momento es posible que hayan finalizado una o
más adaptaciones y prestaciones de servicios, es decir, la cumplimentación de una
adaptación no implica necesariamente la cumplimentación del contrato.

Capítulo 3
Entregables
3.2.2.2 Propiedades de los entregables de punto de decisión
En la figura 3.5 aparece una relación completa de las propiedades del dominio
contractual que deben aparecer en cada uno de los entregables de punto de
decisión.

Entregables de punto de decisión Propuesta Informe de Informe de Informe de

de punto de situación punto de cumplimentación
Propiedad contractual Descripción decisión del contrato decisión del contrato
Objetivos del contrato Resumen de los objetivos del __ __ __ √

negocio, necesidades y objetivos
de la adquisición y requisitos de
compra de SI definidos en el
contrato.
Descripción del punto Según se describe en el plan de √ √ √ √
de decisión entregas.
Grupo destinatario del Público a quien va dirigido este __ __ √ √

informe informe.
Opciones de decisión Las opciones de decisión pueden √ __ √ __
ser de negocio, financieras, (Seleccionadas)
técnicas, de gestión y
organizativas.
Para cada opción pueden
abordarse los siguientes asuntos:
• Objetivos de alto nivel que

se han logrado
• Objetivos y requisitos de
punto de decisión que se han
cumplido
• Importancia relativa de cada
requisito cumplido
• Análisis de costes/beneficios
• Análisis de las
repercusiones
• Beneficio actualizado /
costes de oportunidad
Decisiones adoptadas Selección y/o modificación de __ __ √ __

las opciones de decisión que se
tienen en cuenta en el punto de
decisión. Las decisiones pueden
ser de inversión, de diseño y de
aceptación de un sistema
Desviaciones respecto Las desviaciones con respecto a: __ √ __ __
al plan de entregas
• Calidad
• Calendario
• Presupuesto
• Disponibilidad de recursos
Asuntos nuevos de la • Problemas detectados __ √ __ __

compra de SI durante la prestación de
servicios, el desarrollo del
SI o el proceso de
aseguramiento de la calidad.
• Riesgos detectados durante
la prestación de servicios, el
desarrollo del SI o el
proceso de aseguramiento
de la calidad.
Propuestas de acciones Opciones de decisión acerca de __ √ __ __

correctivas acciones correctivas a nivel (si se
contractual. precisan)
Propuestas para Opciones de decisión acerca de __ √ __ __

cambiar el plan de cuestiones relativas al plan de (si se
entregas entregas. precisan)

Capítulo 3
Entregables
Entregables de punto de decisión Propuesta Informe de Informe de Informe de

de punto de situación punto de cumplimentación
Propiedad contractual Descripción decisión del contrato decisión del contrato
Propuestas para el Opciones de decisión acerca de __ √ __ __

control de los cambios temas contractuales de carácter (si se
contractuales general. precisan)
Descripción de la Deberán tenerse en cuenta los __ __ __ √

cumplimentación siguientes aspectos:
• plazos y recursos de compra
• identificar los problemas

que puedan surgir durante el
proceso de licitación y el
proceso de seguimiento del
contrato
• revisar el proceso de
gestión de riesgos
• identificar las lecciones de

gestión contractual a
extraer durante el
seguimiento del contrato
Figura 3.5: Propiedades del dominio contractual de los entregables de punto de

decisión
3.3 Entregables de gestión

Los entregables de gestión del servicio y de gestión del proyecto describen el
dominio de gestión con respecto a las prestaciones de servicios y las adaptaciones.
Pueden ser entregados por el proveedor al objeto de que el cliente controle y
confíe en el contenido y la calidad de los servicios y adaptaciones suministrados.
También puede entregarlos el cliente al proveedor al objeto de definir los
requisitos del cliente con respecto al servicio y la organización del proyecto.
Se definen dos tipos de entregables de gestión: planes e informes. Para cada
prestación de servicios y cada proyecto habrá planes e informes específicos; por
ejemplo, un informe de nivel de servicio.
3.3.1 Entregables de gestión del proyecto

Los entregables de gestión del proyecto se utilizan para planificar y controlar los
proyectos.
Sus objetivos son:
• describir el modo de trabajar
• garantizar que se alcanzan los objetivos de la adaptación
• mantener el control y la confianza en el contenido y calidad de los
entregables del dominio objetivo
• facilitar al cliente-proveedor la toma de decisiones relativas a la progresión
del proyecto
• supervisar el proyecto.

Al desarrollar los entregables de gestión para una adaptación, deberán tenerse en

cuenta las siguientes heurísticas:
• los planes del proyecto demasiado detallados no suelen cumplirse
• un proyecto sólo será gestionable si los factores utilizados para su predicción
son relevantes y afectan a aspectos globales
• a fin de basar un proyecto en la realidad, es preciso medirlo.
Existen dos vías de adquisición de conocimientos acerca de un proyecto:
• Planificación; es decir, definir qué se ha de conseguir, cómo y cuándo se
debe realizar el trabajo: estimación, organización, programación, obtención
de recursos, coordinación, cálculo de costes.
• Control; es decir, medir el proyecto y seguir su evolución: seguimiento,
medición, análisis de desviaciones, análisis de progresión, evaluación.
En base a estas actividades pueden identificarse dos tipos de entregables de
gestión:
• plan del proyecto
Un plan es el compromiso de cumplir unos objetivos identificados en
términos de entregables, calendario, recursos, esfuerzos y costes.
Proporciona orientación acerca de cómo conseguir los objetivos y establece
las bases para gestionar el proyecto de acuerdo con sus imperativos, recursos
y capacidades.
• informe del proyecto
Un informe es una valoración de la situación del proyecto y de la idoneidad
de los entregables del dominio objetivo. En otras palabras, refleja la
productividad del proyecto, todo análisis de defectos y el análisis de la
situación; además propone acciones correctivas midiendo los esfuerzos,
costes, progresión y calidad. Como resultado de todo ello, emite señales de
aviso de problemas potenciales del proyecto. Es decir, proporciona una
visión real de la progresión, mediante la supervisión y revisión de los
resultados, y una base para emprender acciones (para corregir desviaciones
importantes respecto del plan).
Para cada entregable se abordan tres procesos (desarrollo, aseguramiento de la
calidad y gestión de la configuración, que puede considerarse ortogonal con
respecto a los anteriores).
Se puede definir un conjunto de propiedades que caracterizan los conocimientos
adquiridos relativos a los entregables de gestión del proyecto (véase figuras 3.6 y
3.7). En primer lugar se identifican y definen globalmente las propiedades de los
planes e informes. En segundo lugar, se identifican propiedades adicionales de los
planes e informes de garantía de calidad y de gestión de la configuración (véase
figuras 3.8 y 3.9).

Capítulo 3
Entregables
Plan del proyecto

Propiedades Subpropiedades Descripción
Objetivos de la Debe manifestar con claridad el objetivo de la
adaptación adaptación y establecer el enlace con el plan de
adaptación.
Imperativos y Debe establecer los supuestos en que se basa el
suposiciones proyecto, los acontecimientos externos de que
depende el proyecto y los imperativos que rigen la
evolución del proyecto.
Organización Estructura de subdivisión Debe describir la estructura interna y externa del
organizativa proyecto mediante dispositivos gráficos como
organigramas o tablas, al objeto de representar las
Grupos afectados
líneas de mando, responsabilidades y
Dependencias comunicaciones del proyecto.
Organizaciones externas, Debe identificar los límites organizativos y las
límites e interfaces interfaces entre el proyecto y otras entidades, como
la organización del cliente, organizaciones
Gestión de
subcontratadas o cualquier otra organización con la
subcontratistas
que el proyecto mantenga algún tipo de
interacción.
Funciones y su Tipos de pericia en SI Debe identificar, definir y manifestar las funciones
responsabilidad y responsabilidades.
Entregables Estructura de subdivisión Debe relacionar todos los elementos a entregar al
del producto cliente.
Diagrama de flujo del Los productos del trabajo se subdividen de manera
producto que se puedan supervisar y controlar fácilmente, y
se desglosan en función de la granularidad
Requisitos de entrega
necesaria para lograr los objetivos.
Actividades Estructura de subdivisión Debe especificar los paquetes de trabajo para las
del trabajo actividades a realizar.
Red de actividades Puede utilizarse un diagrama que represente la
división de las actividades en subactividades, para
Multiestructura del
representar las relaciones jerárquicas entre los
proyecto
paquetes de trabajo.
Prioridades
Las actividades se dividen de manera que se
puedan supervisar y controlar con facilidad.
Las relaciones entre las actividades se especifican
para explicar las interdependencias entre ellas.
Existen varias técnicas, como listas de
dependencias, redes de actividades y el método de
vía crítica, que pueden utilizarse para representar
las dependencias.

Plan del proyecto

Tamaño Tamaño del sistema Se realizan estimaciones del tamaño del SI y del
sistema informático de acuerdo con los
Tamaño del proyecto
conocimientos disponibles acerca de la situación del
Reparto del esfuerzo problema.
Se realizan estimaciones del esfuerzo, coste y
calendario relativos al proyecto.
Se documentan las fuentes, bases y supuestos en que
se fundamentan las estimaciones.
Se preparan repartos del esfuerzo, coste y personal
entre las tareas.
Calendario Diagrama Gantt, plazos Se prepara el calendario de las distintas actividades,
teniendo en cuenta las relaciones de precedencia, y
Fechas, hitos
las fechas de puntos de decisión del plan de
adaptación. Puede expresarse en tiempo absoluto de
calendario o en incrementos basados en un hito
clave.
Recursos Estructura de subdivisión Se facilitan estimaciones de los recursos humanos
de los recursos humanos necesarios para finalizar el proyecto. Especifica el
número y el tipo de personal que se precisa, además
Perfil
de los niveles de cualificación necesarios, fechas de
Dotación de personal inicio, duración, métodos de obtención, formación,
conservación y reducción de personal.
Disponibilidad
Presupuesto Estructura de subdivisión Se especifica la asignación de los fondos
de la contabilidad de presupuestados a las actividades, es decir, el perfil
costes de costes.
Infraestructura Normas de ingeniería Se facilitan estimaciones de los recursos no
humanos que se precisan para finalizar el proyecto,
Herramientas, métodos y
como horas de ordenador, software de apoyo,
técnicas
ordenadores y material informático, oficinas,
Instalaciones infraestructura de viajes y comunicaciones.
Procedimientos Se especifica el lenguaje de programación,
notaciones, herramientas, técnicas y métodos a
Dispositivos físicos y
utilizar para elaborar los entregables, además de las
software
normas, políticas y procedimientos que determinan
el desarrollo de los mismos.
Gestión de Se identifican y valoran los factores de riesgo
riesgos asociados al proyecto. Se definen mecanismos para
controlar los distintos factores de riesgo.
Medidas de Se implementan planes de emergencia.
emergencia
Mecanismos Mecanismo de Se define el mecanismo de información, formatos de
de control información informe, flujo de información, mecanismos de
revisión y auditoría y otras técnicas para controlar
Formatos de informe
que se cumple el plan.

Capítulo 3
Entregables
Figura 3.6: Propiedades de un plan del proyecto
Informe del proyecto

Entregables Esfuerzo utilizado Las unidades reales de los resultados entregados se
comparan periódicamente con la entrega estimada en
Coste utilizado
el plan en términos de esfuerzo, coste y calendario
Calendario utilizado utilizados.
Actividades Esfuerzo utilizado Los gastos reales en que se ha incurrido para
finalizar el trabajo, junto con el esfuerzo, coste y
Coste utilizado
calendario utilizados, se comparan con las
Calendario utilizado estimaciones del plan, a fin de identificar
desviaciones potenciales.
Procedimientos
aplicados
Recursos Uso de los recursos del El esfuerzo, la capacidad y el personal utilizados se
cliente comparan con las estimaciones del plan, a fin de
identificar desviaciones, conflictos y problemas. Se
Uso de los recursos del
identifican además las dependencias entre grupos.
proveedor
Pericia, capacidad y
competencia de las
personas
Presupuesto Presupuesto utilizado Se estiman los fondos presupuestados utilizados
hasta el momento.
Infraestructura Utilización Se mide la utilización de los recursos que forman
parte de la infraestructura. Se identifican los
Problemas y necesidades
problemas y necesidades relativos a la
infraestructura.
Gestión de la Esfuerzo de repaso Se estima el esfuerzo y el tiempo empleado para el
baja calidad trabajo de repaso.
Tiempo de repaso
Desviaciones Exceso de coste Se miden y comunican las desviaciones de los
valores reales respecto de los valores de base.
Exceso de esfuerzo
Se determinan y analizan las causas.
Incumplimiento del
calendario
Seguimiento Se analizan los riesgos, se detectan nuevos riesgos y
de riesgos se valoran contramedidas.
Propuestas de Acciones para ajustar el Si se producen desviaciones respecto del plan se
acciones rendimiento emprenden acciones correctivas, que pueden incluir
correctivas la revisión del plan o del contrato para reflejar la
Acciones para ajustar el
situación actual o la replanificación del trabajo
(si se precisan) plan
restante, o acciones para mejorar el rendimiento.
Acciones para ajustar el
contrato
Acciones para ajustar la
infraestructura
Figura 3.7: Propiedades de un informe del proyecto

Planes del proyecto

Propiedades Subpropiedades específicas del Subpropiedades específicas de
aseguramiento de la calidad la gestión de la configuración
Entregables Requisitos de calidad Elementos de configuración
Requisitos de configuración
Actividades Tipos específicos de actividades del Tipos específicos de actividades
plan: del plan:
Revisiones Control de las interfaces
Auditorías Identificación de la configuración
Inspección del código Control de la configuración
Ensayos Contabilidad del estado de la
configuración
Mantenimiento y conservación de
los registros de calidad Auditorías y revisiones
Recopilación y conservación de
registros
Infraestructura Procedimientos y normas de calidad Procedimientos y normas de
gestión de configuración
Métodos y herramientas de calidad
Métodos y herramientas de
gestión de configuración
Figura 3.8: Propiedades adicionales de los planes de aseguramiento de la calidad y

los planes de gestión de la configuración
Informes del proyecto

Propiedades Subpropiedades específicas del Subpropiedades específicas de
aseguramiento de la calidad la gestión de la configuración
Entregables Estado de calidad Situación de la configuración
Fallos y defectos de conformidad Solicitudes de cambio y su estado
detectados (aceptadas, ..)
Figura 3.9: Propiedades adicionales de los informes de aseguramiento de la calidad

y los informes de gestión de la configuración
Contexto considerado
Los planes tienen dos finalidades posibles: pueden definir el dominio del proyecto
de la adaptación actual o el dominio del proyecto de una futura adaptación. Este
último caso se utiliza cuando una adaptación tiene que dar lugar a una adaptación
posterior.
Estado de calidad
Los mecanismos de aseguramiento de la calidad pueden aplicarse para demostrar
que un entregable de gestión del proyecto es conforme con los criterios de calidad
definidos.

Capítulo 3
Entregables
Para cada entregable específico de gestión del proyecto deberá definirse el

mecanismo de aseguramiento de la calidad a aplicar. La figura 3.10 muestra un
ejemplo de dos estados de calidad de un entregable.
Estado Descripción
Entregable en estado revisado Se ha comprobado que se ha realizado el entregable
Entregable en estado validado Se ha comprobado en detalle y formalmente de que se ha
realizado el entregable, p. ej.: una inspección
Figura 3.10: Descripción de estados de calidad
Perfil del entregable de gestión del proyecto

El contenido del entregable viene reflejado en un perfil del entregable de gestión
del proyecto, véase figura 3.11. (þAnexos D.12 y D.13)
El perfil del entregable de gestión de proyecto proporciona una lista de las
propiedades y subpropiedades del entregable de gestión del proyecto. No es
preciso mencionar todas las propiedades, sino únicamente las que sean relevantes.
El contexto considerado y el estado de calidad se especifican para todo el
entregable de gestión del proyecto.
Nombre del plan/informe del proyecto
Contexto:
Estado de calidad:
Propiedades Subpropiedades
Propiedad 1 Subpropiedad 1.1
Subpropiedad 1.2
Subpropiedad 1.3
.....
Propiedad 3 .....
Figura 3.11: Perfil del entregable de gestión del proyecto
3.3.2 Entregables de gestión del servicio

Los entregables de gestión del servicio se utilizan para planificar y gestionar la
prestación de servicios. Se definen dos tipos de entregables de gestión del servicio:
planes de servicio e informes de servicio.
Planes de servicio
Un plan de servicio es el compromiso de cumplir los objetivos identificados en
términos de niveles de servicio, plazos, recursos, esfuerzos y costes.
La prestación de servicios consiste en la instalación del servicio, la ejecución del
servicio y la cancelación del servicio (véase 5.2.). La instalación y la cancelación
del servicio son tipos especiales de adaptaciones que pueden planificarse utilizando
un plan del proyecto (véase apartado sobre entregables de gestión del proyecto).
De forma similar, toda adaptación que tuviera lugar durante el proceso de

ejecución del servicio para mejorar el nivel de servicio podrá planificarse utilizando
un plan del proyecto.
La ejecución del servicio precisa diferentes tipos de planes con diferentes
propiedades, en función de:
• el tipo de servicio (véase 5.1. y [ITIL]).
• la organización del servicio: por ejemplo, ¿comparten el servicio varios
clientes o está destinado a uno solo?
Puede identificarse un conjunto de propiedades con la finalidad de caracterizar los
conocimientos adquiridos para los entregables de gestión del servicio (véase
figuras 3.12 y 3.13). Eurométodo no propone subpropiedades, aunque éstas
podrán utilizarse: su definición deberá tener en cuenta el tipo de servicio.
Plan de servicio
Propiedades Descripción
Objetivos del servicio Debe determinar claramente el objetivo del servicio y establecer
el enlace con el plan de prestación de servicios.
Nivel de servicio Debe especificar el nivel de servicio y su evolución.
Imperativos y supuestos Debe determinar los supuestos en que se basa el servicio, los
acontecimientos externos de que depende el servicio y los
imperativos que rigen la evolución del servicio.
Organización Debe describir la estructura interna y externa de la organización
de servicios, a fin de representar las líneas de mando,
responsabilidad y comunicación del servicio.
Debe identificar los límites organizativos y las interfaces entre el
servicio y otras entidades, como la organización del cliente,
organizaciones subcontratadas o cualquier otra organización con
la que la organización de servicios mantenga algún tipo de
interacción.
Funciones y su Deben identificar, definir y mencionar las funciones y
responsabilidad responsabilidades.
Elementos operativos Deben identificar los elementos operativos que constituyen el
objeto del servicio, su volumen (capacidad) y otras
características, y su evolución.
Actividades Deben especificar las actividades que deben llevarse a cabo.
Pueden representarse las relaciones jerárquicas entre las
actividades.
Las actividades se dividen de manera que se puedan supervisar y
controlar con facilidad.
Las relaciones entre las actividades se especifican para explicar
las interdependencias entre ellas.

Capítulo 3
Entregables
Plan de servicio
Tamaño Se realizan estimaciones relevantes para el servicio acerca del
tamaño del SI y del CS.
Se realizan estimaciones del esfuerzo, coste y calendario
relativos al servicio.
Se documentan las fuentes, bases y supuestos en que se
fundamentan las estimaciones.
Se preparan repartos del esfuerzo, coste y personal entre las
tareas.
Calendario Se prepara el programa de las distintas actividades, teniendo en
cuenta las relaciones en precedencia, y las fechas de puntos de
decisión que precisa el plan de prestación de servicios. Puede
expresarse en tiempo absoluto de calendario o en incrementos
basados en hitos clave.
Recursos Se facilitan estimaciones de los recursos humanos necesarios
para prestar el servicio con el nivel de servicio que se precisa.
Especifica el número y el tipo de personal que se precisa y su
origen (cliente o proveedor), además de los niveles de
cualificación necesarios, fechas de inicio, duración, métodos de
obtención, formación, conservación y reducción de personal.
Presupuesto Se especifica la asignación de los fondos presupuestados a las
actividades.
Infraestructura Se facilitan estimaciones de los recursos no humanos que se
precisan para prestar el servicio, como horas de ordenador,
software de apoyo, ordenadores y material informático, oficinas,
infraestructura de viajes y comunicaciones.
Se realiza una estimación de la capacidad que deben tener estos
recursos y de su evolución.
Gestión de riesgos Se identifican y valoran los factores de riesgo asociados al
servicio. Se definen mecanismos para controlar los distintos
factores de riesgo.
Acciones de emergencia Se implementan planes de emergencia.
Mecanismos de control Se define el mecanismo de información, formatos de informe,
flujo de información, mecanismos de revisión y auditoría y otras
técnicas para controlar que se cumple el plan.
Figura 3.12: Propiedades de un plan de servicio

Informe de servicio
Nivel de servicio Informa del rendimiento real de un servicio comparando unos
indicadores clave con el nivel de servicio que se precisa.
Elementos operativos Se comparan los volúmenes reales y otras características de los
elementos operativos con las estimaciones del plan.
Actividades Los gastos reales en que se ha incurrido para finalizar el trabajo,
junto con el esfuerzo, coste y calendario utilizados, y se
comparan con las estimaciones del plan a fin de identificar
desviaciones potenciales.
Recursos El esfuerzo, capacidad y personal utilizados se comparan con las
estimaciones del plan, a fin de identificar desviaciones,
conflictos y problemas.
Presupuesto Se estiman los fondos presupuestados utilizados hasta el
momento.
Infraestructura Se mide la utilización de los recursos que forman parte de la
infraestructura. Se identifican los problemas y necesidades
relativos a la infraestructura.
Gestión de la baja calidad Se valoran las medidas de gestión de una calidad insuficiente.
Desviaciones Se miden y comunican las desviaciones de los valores reales
respecto de los valores de base.
Se determinan y analizan las causas.
Seguimiento de riesgos Se analizan los riesgos, se detectan nuevos riesgos y se valoran
contramedidas.
Propuestas de acciones Si se producen desviaciones respecto del plan se emprenden
correctivas acciones correctivas, que pueden incluir la revisión del plan o
del contrato para reflejar la situación actual o la replanificación
(si se precisan)
del trabajo restante, o acciones para mejorar el rendimiento.
Figura 3.13: Propiedades de un informe de servicio
Contexto considerado
Los planes tienen dos finalidades posibles: pueden definir el servicio actual o un
servicio futuro.
Estado de calidad
De forma similar a los entregables de gestión del proyecto, pueden aplicarse
mecanismos de aseguramiento de la calidad para demostrar que un entregable de
gestión del servicio es conforme con los criterios de calidad definidos.
Perfil del entregable de gestión del servicio

El contenido del entregable viene reflejado en un perfil del entregable de gestión
del servicio, véase figura 3.14. (þAnexos D.14 y D.15)

Capítulo 3
Entregables
El perfil del entregable de gestión del servicio proporciona una lista de las
propiedades (y subpropiedades, si son relevantes) que aborda el entregable de
gestión del servicio. Tal y como se ha explicado anteriormente, el perfil deberá
ajustarse al tipo de servicio y a la organización.
El contexto que se considera y el estado de calidad se especifican para todo el
entregable de gestión del servicio.
Tipo y nombre del plan/informe de servicio
Contexto:
Estado de calidad:
Propiedades Subpropiedades (opcional)
Subpropiedad 1.2
Subpropiedad 1.3
.....
Propiedad 3 .....
Figura 3.14: Perfil del entregable de gestión del servicio
3.4 Entregables del dominio objetivo

Los entregables del dominio objetivo son aquellos entregables relacionados con el
dominio objetivo de una adquisición, que entrega el proveedor al cliente o
viceversa.
Existen dos tipos de entregables del dominio objetivo:
• elemento operativo:
un sistema (o componente del sistema) que es o será instalado como parte
del dominio objetivo.
• elemento descriptivo:
un entregable que recoge conocimientos sobre el dominio objetivo.
Los elementos descriptivos facilitan la toma de decisiones relativas a una
adaptación o una prestación de servicios, es decir, especifican qué debería
hacer y cómo debería ser el diseño de la organización del dominio objetivo
y/o su sistema de información.
La figura 3.15 representa los tipos de entregables del dominio objetivo arriba
mencionados.

Figura 3.15: Tipos de entregables del dominio objetivo

Un elemento operativo es un sistema (sistema de información, sistema informático
o parte de alguno de ellos) entregado que será instalado dentro del dominio
objetivo. Cuando un sistema entregado funciona en el dominio objetivo, puede
utilizarse para adquirir conocimientos a utilizar en la definición de futuras versiones
del mismo: en ese caso, se dice que se ha desarrollado con un enfoque de
instalación evolutiva (cf. capítulo 4). Cuando un sistema entregado se está
construyendo, antes de que entre en funcionamiento en el dominio objetivo, puede
someterse a ensayos con objeto de adquirir conocimientos para la definición de
versiones posteriores del mismo: en ese caso, se dice que se ha desarrollado con un
enfoque de construcción evolutiva (cf. capítulo 4).
Un sistema que únicamente se utiliza para adquirir conocimientos acerca de
aspectos o requisitos del dominio objetivo se considera una simulación (por
ejemplo, un prototipo) y, por tanto, un elemento descriptivo. Si, por cualquier
motivo, se decide instalar una simulación como parte del dominio objetivo, se
considera que se construirá un elemento operativo en base a la simulación: éste no
es más que un caso especial de construcción a base de descripciones.
3.5 Elementos operativos

Un elemento operativo es un sistema (o componente de un sistema) que es o será
instalado como parte del dominio objetivo. Por tanto, los elementos operativos
están encaminados a contribuir al funcionamiento del dominio objetivo.
A continuación se relacionan los tipos de componentes del sistema que suelen
aparecer en toda adaptación de un SI. Se pueden utilizar estos tipos para
caracterizar elementos operativos:
• instalaciones:
local, cableado, suministro eléctrico
• soporte físico:
ordenadores, dispositivos de red, unidades de almacenamiento, dispositivos
de entrada-salida, etc.

Capítulo 3
Entregables
• software de sistema:
software independiente de la aplicación que soporta la ejecución del software
de aplicación [ISO-2382-20]; por ejemplo, sistemas operativos, sistemas de
gestión de bases de datos, supervisores de transacciones, herramientas.
• software de aplicación:
un programa de software específico para la solución de un problema de
aplicación [ISO-2382-20], cuyas características vienen determinadas por la
especificación del sistema de información. Este concepto incluye paquetes de
aplicación que se adaptan a la especificación del sistema de información y
que, por tanto, pueden utilizarse.
• Datos físicos:
los datos físicos del dominio objetivo. Será preciso migrar estos datos en
caso de sustitución del sistema informático.
• manuales de usuario y de operador:
documentación escrita que facilita el uso y manejo del sistema informático
por los agentes humanos del sistema de información.
• descripciones de trabajos:
instrucciones que los agentes humanos de un sistema de información tienen
que seguir en su trabajo.
• programas de formación y/o migración:
los productos que facilitan la migración a una nueva versión del sistema de
información y la educación de los agentes humanos.
• agentes formados:
los agentes humanos que han sido formados de cara a sus nuevas
circunstancias (por ejemplo, el uso de un nuevo sistema informático).
Para cada elemento operativo:
• es preciso identificar la versión del sistema: puede ser el sistema actual o una
futura versión del sistema. Es preciso identificar la versión del sistema sin
ambigüedades. Deberá añadirse un texto explicativo si la simple mención del
sistema actual o futuro da lugar a ambigüedades.
• deberá especificarse el estado de calidad.
El estado de calidad de un elemento operativo se refiere a su conformidad
con los criterios de calidad definidos en los procedimientos aplicables de
aseguramiento de la calidad. Los procedimientos de aseguramiento de la
calidad para los elementos operativos pueden basarse en pruebas unitarias,
pruebas específicas de propiedades de calidad (rendimiento, seguridad, etc.),
pruebas de integración, validaciones de usuario, evaluaciones de uso, etc.
Por regla general, algunas descripciones de elementos operativos ya existen o han
sido planificadas. Estos elementos descriptivos pueden describirse utilizando los
perfiles de elementos descriptivos presentados en el apartado 3.6. La versión del
sistema que posee el perfil del elemento descriptivo se utilizará para establecer el
enlace con el elemento operativo pertinente.

3.6 Elementos descriptivos

Un elemento descriptivo es un entregable del dominio objetivo que recoge
conocimientos sobre el dominio objetivo. Los elementos descriptivos pueden
utilizarse para describir sistemas de información dentro de adaptaciones o servicios
del sistema de información.
Estos conocimientos se caracterizan por:
• el conjunto de propiedades del dominio objetivo (propiedades funcionales, de
calidad y de inversión) que se describen.
• otras características: alcance, nivel de detalle, nivel de acuerdo, grado de
formalismo, cuantificación, simulación, versión del sistema, soluciones
alternativas y estado de calidad.
3.6.1 Perfiles de los elementos descriptivos

Para describir un elemento descriptivo se utiliza un perfil específico (véase figura
3.16, þAnexo D.16).
El perfil del elemento descriptivo identifica el elemento descriptivo con un nombre:
Eurométodo no determina su estructura.
El perfil del elemento descriptivo proporciona la lista de visiones y propiedades
(funcionales, de calidad, de inversión) del elemento descriptivo. No es preciso
mencionar todas las propiedades que caracterizan una visión, sino únicamente las
que sean relevantes.
Las propiedades de calidad y de inversión pueden calificarse mediante una
propiedad funcional específica, por ejemplo, seguridad de los datos, facilidad de
uso de la interfaz hombre-ordenador, eficiencia de una tarea.
El alcance, nivel de detalle, nivel de acuerdo, grado de formalismo, cuantificación,
simulación, versión del sistema, soluciones alternativas y estado de calidad (véase
apartados 3.6.5 a 3.6.13) pueden especificarse alternativamente para cada
propiedad, para cada visión o para la totalidad del elemento descriptivo. Si se
especifican a nivel de una visión, son válidos para todas las propiedades que
comprende esa visión. Si se especifican a nivel de un elemento descriptivo, son
válidos para todas las visiones y propiedades que comprende el elemento
descriptivo.
Los valores definidos por los usuarios y que figuran en cada columna deberán
remitir al texto explicativo que acompaña a la tabla (véase apartados 3.6.5. a
3.6.13).

Capítulo 3
Entregables
Nombre del elemento descriptivo

Características, alcan deta- acuer- forma- cuantifi simula versión alter- estado
visiones y -ce lle do lismo -cación -ción del sis- nativas de
propiedades tema calidad
Propiedades
funcionales
Visión-1
Propiedad
funcional 1-1
Propiedad
funcional 1-2
…
Visión-2
Propiedad
funcional 2-1
Propiedad
funcional 2-2
Propiedad
funcional 2-3
…
Propiedades de
calidad
Propiedad de
calidad 1
Propiedad de
calidad …
Propiedades de la
inversión
Propiedad de la
inversión 1
Propiedad de la
inversión …
Texto explicativo
......................................................................................................................................................
......................................................................................................................................................
......................................................................................................................................................
............
Figura 3.16: Perfil del elemento descriptivo
3.6.2 Visiones y propiedades funcionales

El tipo de conocimiento del dominio objetivo que contiene un elemento descriptivo
viene determinado por la visión que adopta la persona que realiza esta descripción.
Eurométodo define seis de estas visiones, cada una de las cuales se caracteriza por
tener una finalidad concreta y un conjunto de propiedades funcionales. Una

propiedad funcional es un tipo de conocimiento de un dominio objetivo.
Las visiones definen los conceptos y la terminología que se utilizan para
caracterizar el conocimiento del dominio objetivo.
En la Versión 1 de Eurométodo, las seis visiones se clasifican en visiones del
sistema de información y visiones del sistema informático11.
El SI es el aspecto de la organización que utiliza y produce información. Las
visiones del SI definen la representación de los recursos de información, los
agentes que los utilizan y producen, sus procesos y las relaciones entre ellos. Las
visiones del SI se representan gráficamente en la figura 3.17.
Figura 3.17: Visiones del sistema de información

Varios de los agentes del dominio objetivo pueden ser soportados o sustituidos por
un sistema informático. Esto significa que algunas de sus tareas, o todas ellas, las
realiza total o parcialmente un sistema informático. Todo esto se describe en la
visión de las prácticas de trabajo que define las propiedades funcionales que
11 Actualmente, las visiones de Eurométodo permiten la representación del sistema de

información pero no del resto de aspectos de la organización; por ejemplo, los procesos
asociados a flujos de materiales, financieros o energéticos.

n
o
e
d
g
e
o
lci
Capítulo 3
Entregables
caracterizan los conocimientos acerca de la selección de tareas y el subconjunto de

recursos de información que están informatizados.
Las visiones del sistema informático definen la representación de la estructura y
funcionalidad del sistema informático, y describen los conocimientos acerca del
modo en que se automatizan las tareas y se estructura el sistema informático (véase
figura 3.18).
Figura 3.18: Visiones del sistema de información y del sistema informático

Las visiones del sistema de información y las visiones del sistema informático
(véase figura 3.18) abarcan las propiedades funcionales de un sistema de
información y de su sistema informático, que se precisan para facilitar la toma de
decisiones relativas a:
• los requisitos del sistema de información en cuestión
• el diseño del sistema de información en cuestión
• la simulación (prototipo) del sistema de información en cuestión.
Visión de la información del negocio

La finalidad de la visión de la información del negocio es representar los recursos
de información del dominio objetivo, independientemente de cómo éstos se
implementan y utilizan en las prácticas de trabajo reales. Abarca las propiedades
funcionales que representan los conocimientos relativos a los elementos de
información, su semántica, las relaciones entre ellos y su evolución.

Las propiedades funcionales definidas en la visión de la información del negocio

están representadas en la figura 3.19.
Visión de los procesos del negocio

La finalidad de la visión de los procesos del negocio es representar los procesos del
dominio objetivo, independientemente de cómo éstos se llevan a cabo por agentes
en las prácticas de trabajo reales. Abarca las propiedades funcionales que
representan los conocimientos sobre los procesos, las relaciones entre ellos, los
eventos y las condiciones que los activan y el uso de los recursos de información.
Las propiedades funcionales definidas en la visión de los procesos del negocio
están representadas en la figura 3.20.
La visión de la información del negocio junto con la visión de los procesos del
negocio abarcan las propiedades que definen una visión de un sistema de
información independiente de los agentes (humanos o automatizados) que llevan a
cabo los procesos del dominio objetivo y utilizan los recursos de información.
Visión de las prácticas de trabajo

La finalidad de la visión de las prácticas de trabajo es representar a los agentes y el
modo en que ejecutan los procesos en el dominio objetivo y hacen uso de los
recursos de información.
La visión de las prácticas de trabajo utiliza el concepto de tarea: una tarea es (una
parte de) un proceso que realiza un agente.
La visión de las prácticas de trabajo abarca aquellas propiedades funcionales que
representan conocimientos sobre los agentes, su estructura organizativa, su
ubicación física, las tareas mediante las cuales realizan los procesos del negocio y
la posible automatización de estas tareas. Esto incluye la descripción estática y
dinámica de la interfaz hombre-ordenador.
Las propiedades funcionales definidas en la visión de las prácticas de trabajo están
representadas en la figura 3.21.
Visión de los datos del sistema informático

La finalidad de la visión de los datos del sistema informático es representar la parte
automatizada de los recursos de información. Abarca aquellas propiedades
funcionales que caracterizan los conocimientos relativos a los datos que
representan los recursos de información que contiene el sistema informático, y las
dependencias estáticas y dinámicas de esos datos.
Las propiedades funcionales definidas en la visión de los datos del sistema
informático están representadas en la figura 3.22.
Visión de las funciones del sistema informático

La finalidad de la visión de las funciones del sistema informático es representar las
partes automatizadas de las tareas de los agentes, con independencia de cualquier
unidad de proceso.

Capítulo 3
Entregables
La visión de las funciones del sistema informático utiliza el concepto de función:

una función12 es una parte de un proceso ejecutado por el sistema informático, es
decir, el cometido del sistema informático dentro del sistema de información.
Algunas funciones corresponden a una tarea automatizada específica (o partes de
ella), y otras soportan un determinado número de tareas automatizadas, o todas
ellas. Estas funciones de soporte son necesarias para el funcionamiento del sistema
informático.
La visión de las funciones del sistema informático abarca aquellas propiedades
funcionales que representan conocimientos sobre las funciones que desempeña el
sistema informático, el uso de los datos que contiene el sistema informático y las
interfaces de datos.
Las propiedades funcionales definidas en la visión de las funciones del sistema
Visión de la arquitectura del sistema informático

La finalidad de la visión de la arquitectura del sistema informático es representar
las unidades de proceso del sistema informático, su estructura y sus características
físicas.
Una unidad de proceso es un procesador incluido en el sistema informático. Una
unidad de proceso del sistema informático es análoga a un agente.
La visión de la arquitectura del sistema informático abarca aquellas propiedades
funcionales que representan los conocimientos relativos a las unidades de proceso
del sistema informático, sus ubicaciones, sus conexiones y la distribución de los
datos y funciones que utilizan.
Comprende también aquellas propiedades funcionales que representan los
conocimientos acerca del soporte físico, el software del sistema y el software de
aplicación que constituyen el sistema informático.
Las propiedades funcionales definidas en la visión de la arquitectura del sistema
Propiedades funcionales de la visión de la información del negocio
Elementos de La identificación de la información que contienen los recursos de

información información del dominio objetivo
Gamas de valores Posibles valores que pueden adoptar los elementos de información al
ocurrir
Dependencias Las dependencias estáticas entre los elementos de información, por
estáticas ejemplo:
12 En la bibliografía, el término función se utiliza con distintos ignificados. En el contexto de

visiones y propiedades funcionales, el significado de función se ciñe al sistema informático,
es decir, se utiliza con el sentido de “función computerizada”.
Propiedades funcionales de la visión de la información del negocio
• Relaciones; por ejemplo relaciones binarias o n-arias,

relaciones de agregación13, relaciones de generalización14
• Restricciones entre relaciones; por ejemplo, igualdad,

exclusión, inclusión, cardinalidades, dependencias funcionales
Evolución de los La evolución de los elementos de información, en términos de cambios
elementos que pueden experimentar desde que ocurren hasta que se borran. Esto
incluye los eventos que activan estos cambios, las dependencias
dinámicas entre estos cambios (por ejemplo, secuencia, alternativa,
iteración) y los eventos generados por estos cambios
Figura 3.19: Propiedades funcionales de la visión de la información del negocio
Propiedades funcionales de la visión de los procesos del negocio

Procesos del negocio Identificación de los procesos del dominio objetivo y sus objetivos
Y para cada proceso del negocio
Eventos activadores del Los eventos que pueden desencadenar el proceso del negocio, y su
negocio origen
Condiciones de Las condiciones que deben cumplirse para desencadenar el proceso
activación del negocio
Eventos generados por Los eventos generados por el proceso del negocio, y su destino
el negocio
Desglose del proceso del El desglose del proceso del negocio en subprocesos. Los
negocio subprocesos pueden considerarse como procesos y describirse del
mismo modo, y también se pueden desglosar
Dependencias Las dependencias dinámicas entre los subprocesos del proceso del
dinámicas negocio, por ejemplo, secuencia, alternativa, iteración, paralelismo,
sincronización, dependencias de información
Reglas del negocio Las reglas comerciales que rigen el proceso del negocio
Uso y generación de La información que utiliza y genera el proceso del negocio
información
Figura 3.20: Propiedades funcionales de la visión de los procesos del negocio
13 Las relaciones entre un elemento de información agregado y los elementos de información

que lo componen.
14 Las relaciones entre un elemento de información y sus subtipos (elementos de información
especializados). A veces se denomina relación ISA o herencia (simple o múltiple).

Capítulo 3
Entregables
Propiedades funcionales de la visión de las prácticas de trabajo

Agentes Identificación de los agentes (humanos y sistemas informáticos) del
dominio objetivo; y su cualificación o capacidad, necesidades de
formación, etc.
Ubicaciones Las ubicaciones donde trabajan los agentes
Estructura organizativa Las relaciones organizativas entre los agentes, incluyendo la agregación de
actores en unidades organizativas (las unidades organizativas también se
consideran agentes)
Comunicaciones La comunicación entre los agentes
Necesidades y derechos de Las necesidades de acceso a la información y los derechos de acceso
acceso (de los agentes) necesarios para cada agente, es decir, las visiones externas de los agentes
respecto a los recursos de información
Tareas Identificación de las tareas del sistema de información y sus objetivos
Y para cada tarea
Reglas de la tarea Las reglas o procedimientos por los que se rige la tarea
Automatización El modo en que se lleva a cabo la tarea: de forma manual, automatizada o
interactiva. Una tarea interactiva es ejecutada en parte por agentes
humanos y en parte por el sistema informático. Los detalles de la
automatización se definen en el desglose de la tarea
Desglose de la tarea El desglose de la tarea en subtareas. Las subtareas pueden considerarse
como tareas y describirse de igual modo, y se pueden desglosar a su vez
Una tarea interactiva se puede desglosar en subtareas manuales y
automatizadas. Una tarea automatizada no se suele desglosar (se podría
desglosar en la visión de las funciones automatizadas)
Uso y generación de la La información (automatizada y no automatizada) que utiliza y genera la
información tarea
Dependencias dinámicas Las dependencias dinámicas respecto a otras tareas y entre las subtareas de
la tarea, por ejemplo secuencia, alternativa, iteración, paralelismo,
sincronización, dependencias de información
Eventos organizativos Los eventos que pueden activar la tarea y su origen
activadores
Eventos organizativos Los eventos generados por la tarea y su destino
generados
Condiciones de activación Las condiciones que deben cumplirse para desencadenar la tarea
Agente ejecutante El agente que lleva a cabo la tarea
Gestor El agente que controla la tarea
Recursos Los recursos necesarios para llevar a cabo la tarea
Interfaz estática hombre- La información que debe pasar por la interfaz hombre-ordenador
ordenador (incluyendo la definición de diseños de pantalla, informes impresos, etc.) y
los eventos organizativos generados por una tarea manual y que activan
una tarea automatizada, o los generados por una tarea automatizada y que
activan una tarea realizada por un agente humano
Comportamiento de la Condiciones de activación de la interfaz hombre-ordenador.
interfaz hombre-ordenador
El comportamiento de la interfaz hombre-ordenador también depende de
las dependencias dinámicas entre las tareas automatizadas y las manuales
Figura 3.21: Propiedades funcionales de la visión de las prácticas de trabajo

Propiedades funcionales de la visión de los datos de ordenador

Datos retenidos Los datos retenidos en el ordenador que representan los elementos
de información automatizados, y otros datos necesarios para el
funcionamiento del sistema informático
Gamas de valores Posibles valores que pueden adoptar los datos al ocurrir
Dependencias estáticas Las dependencias estáticas entre los datos, por ejemplo:
• Relaciones; por ejemplo, relaciones binarias o n-arias,
relaciones de agregación, relaciones de generalización
• Restricciones entre relaciones; por ejemplo, igualdad,

exclusión, inclusión, cardinalidades, dependencias
funcionales
Evolución de los datos La evolución de los datos en términos de cambios que pueden
experimentar desde que ocurren hasta que se borran, incluyendo los
eventos que activan estos cambios, las dependencias dinámicas
entre estos cambios (por ejemplo, secuencia, alternativa, iteración)
y los eventos generados por estos cambios
Figura 3.22: Propiedades funcionales de la visión de los datos de ordenador
Propiedades funcionales de la visión de las funciones automatizadas

Funciones Identificación de las funciones del sistema informático y su
finalidad.
Y para cada función
Mensajes de entrada Los mensajes que pueden activar la función y su origen
Condiciones de Las condiciones que deben cumplirse para desencadenar la función
activación
Mensajes de salida Los mensajes generados por la función y su destino
Desglose de la función El desglose de la función en subfunciones. Las subfunciones pueden
considerarse como funciones y describirse del mismo modo, y se
pueden desglosar a su vez
Dependencias Las dependencias dinámicas entre las subfunciones de la función;
dinámicas por ejemplo, secuencia, alternativa, paralelismo, iteración,
sincronización, dependencias de datos
Reglas de la función Las reglas o procedimientos por los que se rige la función
Acceso a los datos Los datos retenidos que utiliza y actualiza (crea, borra o modifica)
la función
Figura 3.23: Propiedades funcionales de la visión de las funciones automatizadas

Capítulo 3
Entregables
Propiedades funcionales de la visión de la arquitectura del sistema informático

Unidades de proceso Identificación de las unidades de proceso del sistema informático y
sus tipos
Ubicaciones Las ubicaciones donde se encuentran las unidades de proceso
Estructura La estructura del sistema informático que muestra las relaciones
entre las unidades de proceso
Distribución de los La distribución del almacenamiento de datos en unidades de
datos proceso
Distribución de las La distribución de las funciones en unidades de proceso. La
funciones asignación de una función a las unidades de proceso puede requerir
un mayor desglose de esta función que el que se ha efectuado en la
visión de las funciones del sistema informático
Comunicación externa Los enlaces de comunicación externa de las unidades de proceso
con los sistemas informáticos de otros sistemas de información
Comunicación interna Los enlaces de comunicación interna entre las unidades de proceso
del sistema informático
Y para cada unidad de proceso:
Descripción del soporte Los datos técnicos del soporte físico en que se implementa la
físico unidad de proceso (por ejemplo, tipo de procesador, volumen de la
memoria, velocidad de transmisión, capacidad de almacenamiento)
Descripción del Los datos técnicos del software del sistema en que se implementa la
software del sistema unidad de proceso (sistemas operativos, sistemas de bases de datos,
supervisores de transacciones, sistemas de gestión de red,
compiladores, etc.)
Descripción de la • Datos físicos: la descripción de la implementación de los
aplicación datos almacenados con el soporte físico y el soporte lógico
específicos del sistema.
• Programas: la descripción de la implementación de las

funciones con el soporte físico y el soporte lógico específicos
del sistema. Los programas se pueden desglosar en función
de las unidades de proceso, por ejemplo, interfaces hombre-
ordenador en unidades de proceso locales y gestión de
accesos de datos en unidades de proceso centrales
Figura 3.24: Propiedades funcionales de la visión de la arquitectura del sistema

informático
Reglas de coherencia entre las visiones
Las distintas visiones no son independientes unas de otras, sino que están ligadas
por un conjunto de reglas de coherencia. Cualquier descripción coherente de un
sistema de información deberá cumplir estas reglas.
En este apartado se definen las reglas de coherencia fundamentales entre las
propiedades funcionales antes mencionadas y, por tanto, entre la visión del sistema
de información y la visión del sistema informático, que deben respetarse si se desea
elaborar una descripción coherente del sistema de información. Estas reglas se
establecen en términos generales, y deberán puntualizarse al utilizar las técnicas de
modelado específicas.
Visión de los procesos del negocio y visión de la información del negocio

• Cada elemento de información deberá ser utilizado o actualizado (creado,
modificado, borrado) al menos por un proceso del negocio.
• Es preciso describir cada elemento de información que pueda ser utilizado o
actualizado (creado, modificado, borrado) por un proceso del negocio.
• Debe existir una relación entre el conjunto de eventos que activan los
cambios de los elementos de información y el conjunto de eventos del
negocio.
• La evolución de los elementos de información deberá mantener la coherencia
con la dinámica de los procesos de negocio15.
Visión de las prácticas de trabajo y visión de los procesos del negocio

• Cada proceso del negocio debe realizarse mediante una o varias tareas.
• Cada evento del negocio deberá corresponder al menos a un evento
organizativo.
• La dinámica de las tareas16 debe ser coherente con la dinámica de los
procesos del negocio.
• La información que utilice y genere una tarea debe ser coherente con la
información que utilice y genere la parte del proceso del negocio que aquélla
realice.
• Las necesidades y derechos de acceso a la información que posea un agente
deberán ser coherentes con la información que utilicen y generen las tareas
que aquél realiza y, por tanto, con la información que utilicen y generen los
procesos de negocio realizados por estas tareas.
• Las reglas de la tarea deberán ser coherentes con las reglas del negocio.
• La comunicación entre los agentes deberá ser coherente con la dinámica de
las tareas que desempeñan y, por tanto, con la dinámica de los procesos de
negocio realizados por estas tareas.
Visión de las prácticas de trabajo y visión de la información del negocio

• Las visiones externas de los agentes deberán ser coherentes con la
descripción de los elementos de información y sus dependencias estáticas.
• Cada elemento de información deberá ser utilizado o actualizado (creado,
modificado, borrado) al menos por una tarea.
15 La dinámica de los procesos de negocio se expresa a través de los eventos y condiciones del
negocio que activan los cambios, los eventos del negocio que se generan y las dependencias
dinámicas.
16 La dinámica de las tareas se expresa através de los eventos y condiciones organizativas que
activan los cambios, los eventos organizativos que se generan y las dependencias
dinámicas.

Capítulo 3
Entregables
• Es preciso describir cada elemento de información que pueda ser utilizado o

actualizado (creado, modificado, borrado) por una tarea.
Visión de los datos del sistema informático y visión de la información del

negocio
• Los datos retenidos en el sistema informático deberán corresponder a
elementos de información o bien serán necesarios para el funcionamiento del
sistema informático.
• Las gamas de valores de los datos deberán ser coherentes con las gamas de
valores de los elementos de información.
• Las dependencias estáticas entre los datos deberán ser coherentes con las
dependencias estáticas entre los elementos de información.
• La evolución de los datos deberá ser coherente con la evolución del elemento
de información.
Visión de las funciones del sistema informático y visión de las prácticas de

trabajo
• Cada tarea automatizada deberá corresponder a una función.
• La dinámica de las funciones17 deberá ser coherente con la dinámica de las
tareas.
• Los datos retenidos que utilice y actualice una función deberán ser
coherentes con los elementos de información que utilicen y actualicen las
correspondientes tareas automatizadas.
• Las reglas de las funciones deberán ser coherentes con las correspondientes
reglas de las tareas automatizadas.
• Los eventos organizativos que forman parte de la interfaz hombre-ordenador
deberán corresponder a los mensajes de entrada y salida de las funciones.
Visión de las funciones del sistema informático y visión de los datos del
sistema informático
• Cada uno de los datos retenidos deberá ser utilizado y actualizado (creado,
modificado, borrado) al menos por una función.
• Debe describirse cada uno de los datos retenidos que pueda ser utilizado o
actualizado (creado, modificado, borrado) por una función.
• La evolución de los datos deberá ser coherente con la dinámica de las
funciones.
17 La dinámica de las funciones se expresa a través de los mensajes de entrada y salida, las
condiciones desencadenantes y las dependencias dinámicas.
Visión de la arquitectura del sistema informático y visión de las funciones del

• Cada función deberá ser asignada al menos a una unidad de proceso.
• Los enlaces de comunicación de las unidades de proceso deberán permitir el
intercambio de mensajes entre las funciones distribuidas.
• Cada función deberá ser realizada por el soporte físico, el software del
sistema o el software de aplicación.
Visión de la arquitectura del sistema informático y visión de los datos del

• Cada uno de los datos retenidos deberá ser asignado al menos a una unidad
de proceso.
• Los enlaces de comunicación de las unidades de proceso deberán permitir
que se mantengan las dependencias estáticas y dinámicas de los datos
(expresadas en la evolución de los datos) cuando se distribuyen.
• Cada uno de los datos retenidos deberá corresponder al menos a un dato
físico.
Visión de la arquitectura del sistema informático y visión de las prácticas de

trabajo
• Las ubicaciones de las funciones deberán ser coherentes con las ubicaciones
de los agentes que se relacionan con ellas.
3.6.3 Propiedades de calidad

Las propiedades de calidad se utilizan para describir y valorar la calidad del
sistema. Pueden utilizarse para caracterizar procesos o servicios, además de
sistemas; aunque su definición exacta, unidad de medida y métrica asociada pueden
depender del contexto.
Una propiedad de calidad puede referirse a:
• la totalidad del sistema de información.
En este caso, define un imperativo general que afecta a cada uno de los
componentes del sistema o al sistema en su totalidad.
Por ejemplo: ‘El nuevo sistema de información deberá ser capaz de gestionar
el 250% de la carga máxima del sistema actual.’
• la totalidad del sistema informático.
componentes del sistema informático o al sistema informático en su totalidad.
Por ejemplo: ‘El nuevo sistema informático deberá proteger todos los
accesos a los datos con un nivel de seguridad 2.’
• un proceso o servicio.
componentes del proceso/servicio o al proceso/servicio en su totalidad.

Capítulo 3
Entregables
Por ejemplo: ‘El servicio de ayuda contestará el 90% de las consultas en un

minuto.’
• varias propiedades funcionales.
En este caso, define un imperativo que afecta a todos los casos de esa
propiedad funcional.
Por ejemplo: ‘Todo el software de aplicación debe poder trasladarse a los
sistemas operativos X, Y, Z.’
• un ejemplo de una propiedad funcional.
En este caso, define un imperativo que afecta únicamente al ejemplo
especificado de la propiedad funcional.
Por ejemplo: ‘El agente ejecutante de la tarea Cambiar-Situación-Financiera
debe tener el nivel de autorización 1.’
La siguiente relación de propiedades de calidad (véase figura 3.25) se ha extraído
de la Norma ISO-9126 [ISO-9126] y sus subcaracterísticas tienen en cuenta el
modelo ISO ampliado [KSP]. En las definiciones se utiliza el término “sistema”,
que puede entenderse como un sistema de información, un sistema informático o
un proceso/servicio.

Eficiencia La relación entre el nivel de prestaciones del sistema (o de un

componente) y el volumen de recursos utilizados en condiciones
declaradas. La eficiencia puede referirse al comportamiento en el tiempo
(tiempo de respuesta, tiempo de proceso, velocidad de proceso) y al
comportamiento de los recursos (cantidad de recursos utilizados y
duración de esta utilización).
Ejemplos de indicadores del comportamiento en el tiempo: tiempo de
proceso, capacidad de proceso, tiempo de inversión, tiempo de respuesta,
tiempo transcurrido en la CPU, tiempo de ejecución en la CPU, tiempo de
proceso entrada/salida, tiempo de proceso de la red, velocidad.
Ejemplos de indicadores del comportamiento de los recursos: nivel de
ocupación de la comunicación, nivel de ocupación de memoria, nivel de
ocupación del procesador, nivel de ocupación de archivos, uso de la CPU,
uso de la memoria, uso del canal de entrada/salida, uso de archivos, uso de
la red.
Funcionalidad La funcionalidad está relacionada con la existencia de un conjunto de
funciones y sus propiedades específicas. Las funciones satisfacen las
necesidades declaradas o implícitas.
Son subcaracterísticas de la funcionalidad: idoneidad, precisión,
interoperabilidad, conformidad, rastreabilidad y seguridad. Este último
término se define a continuación.
Seguridad Capacidad de un sistema (o de un componente) para impedir todo acceso
no autorizado, sea accidental o deliberado, a los programas y los datos.
Es una subcaracterística de la funcionalidad.
Fiabilidad Capacidad de un sistema (o un componente) para mantener su nivel de
rendimiento en unas condiciones declaradas y durante un período de
tiempo declarado.
Para evaluar la fiabilidad se utiliza a menudo el tiempo medio sin fallo. La
fiabilidad se puede determinar definiendo el nivel de protección contra los
fallos y las medidas necesarias para la recuperación tras un fallo.
Son subcaracterísticas de la fiabilidad: madurez, tolerancia a los fallos,
recuperabilidad, disponibilidad, degradabilidad.
Mantenibilidad La mantenibilidad está relacionada con el esfuerzo necesario para realizar
modificaciones específicas en el sistema (o en un componente). La
modificación puede incluir correcciones, mejoras o adaptaciones a cambios
del entorno y de los requisitos y especificaciones funcionales.
Son subcaracterísticas de la mantenibilidad: las posibilidades de análisis,
modificación, estabilidad, comprobación, gestión y reutilización.
Portabilidad La capacidad del sistema (o de uno de sus componentes) para ser
transferido de un entorno a otro.
Son subcaracterísticas de la portabilidad: adaptabilidad, instalabilidad,
conformidad, reemplazabilidad.
Facilidad de uso La facilidad de uso está relacionada con el esfuerzo necesario para el uso
del sistema (o de uno de sus componentes) por los agentes.
Son subcaracterísticas de la facilidad de uso: los grados de comprensión,
aprendizaje, operabilidad, explicitud, personalización, atractivo, claridad,
ayuda y facilidad de uso.

Capítulo 3
Entregables
Figura 3.25: Propiedades de calidad

Esta lista no pretende ser exhaustiva. En ciertas adaptaciones, para determinados
servicios y en organizaciones concretas pueden identificarse otras propiedades de
calidad.
3.6.4 Propiedades de la inversión

Las propiedades de la inversión se refieren a los costes y beneficios de un sistema
(sistema de información o sistema informático), un proceso/servicio o un
componente de uno de los anteriores.
En las definiciones de la siguiente lista de propiedades de la inversión (véase figura

3.26) se ha utilizado el término “sistema”, que puede entenderse como un sistema
de información, un sistema informático o un proceso/servicio.
Coste Los costes de producción, mantenimiento y explotación del sistema o de

un componente individual
Beneficio Los beneficios que aporta un componente a otro componente del nivel
superior que lo contiene o al sistema; o los beneficios que el sistema aporta
al negocio de la organización
Riesgo Los riesgos asociados a la producción, mantenimiento y explotación del
sistema o de un componente individual.
Figure 3.26: Propiedades de la inversión
3.6.5 Alcance
El alcance determina qué parte del dominio objetivo queda cubierta por el
elemento descriptivo.
Para cada elemento descriptivo, visión o propiedad funcional en particular, el perfil
del elemento descriptivo deberá contener un conjunto de valores y un texto
explicativo que describa el alcance.
Los tipos de alcance posibles son:
• alcance íntegro:
un elemento descriptivo que describe el dominio objetivo en su totalidad; por
ejemplo, la descripción de todos los procesos del dominio objetivo.
• alcance parcial:
un elemento descriptivo que describe únicamente un subconjunto del
dominio objetivo; por ejemplo, la descripción de un proceso del dominio
objetivo. En este caso se precisará un conjunto de elementos descriptivos
similares para conseguir un alcance íntegro. Si el alcance es parcial, es
preciso definir con más detalle la cobertura del dominio objetivo en términos
cuantitativos (por ejemplo, los procedimientos más importantes que
representan el 80% del dominio objetivo) o en términos cualitativos (por
ejemplo, área de negocio, unidad organizativa, o grupo de procesos del
dominio objetivo).

Para una adaptación particular podrán definirse, si es preciso, varios alcances

parciales al objeto de facilitar una secuencia de decisiones asociadas en esa
adaptación.
3.6.6 Nivel de detalle

El nivel de detalle caracteriza el volumen de conocimientos que contiene el
elemento descriptivo. Este volumen, es decir, el detalle que se incluye o se excluye,
puede variar entre un producto totalmente desarrollado y un producto parcialmente
desarrollado.
explicativo que describa el nivel de detalle.
El nivel de detalle se caracteriza por el nivel de abstracción con respecto a los dos
mecanismos generales de abstracción: agregación (desglose) y generalización
(especialización).
Así pues, el nivel de detalle de un elemento descriptivo puede caracterizarse por:
• el grado de desglose, o
• el grado de especialización.
En una adaptación específica, los clientes y proveedores podrán identificar otros
medios para caracterizar el nivel de detalle necesario en función de los métodos
utilizados, en particular en función de las técnicas de modelado utilizadas.
N.B. En el modelo de proceso del método de un proveedor, los elementos

descriptivos suelen considerarse desde varios niveles de detalle distintos,
aunque sólo algunos de ellos se entregarán al cliente como entregables.
Grado de desglose
El grado de desglose indica hasta qué punto un sistema (dominio objetivo, sistema
de información o sistema informático) o un proceso/servicio está desglosado en el
Los grados de desglose se definen del modo siguiente:
• un elemento descriptivo posee un alto grado de desglose si todas las partes
del sistema (o proceso/servicio) que recoge están completamente
desglosadas y descritas. Una descripción se suele considerar completa si ya
no se precisa un mayor desglose para la construcción del sistema y no es
necesario añadir más elementos a la descripción.
• un elemento descriptivo posee un bajo grado de desglose si no se han
identificado y descrito todos los niveles jerárquicos.
Varias propiedades funcionales se describen utilizando el desglose jerárquico, para
lo cual el grado de desglose se refiere al número de niveles de desglose. Por
ejemplo:
• procesos del negocio incluidos en la visión correspondiente

Capítulo 3
Entregables
• tareas, agentes o estructuras organizativas incluidos en la visión de las

prácticas de trabajo
• funciones incluidas en la visión de las funciones automatizadas
• unidades de proceso incluidas en la visión de la arquitectura del sistema
informático.
Ejemplo: Puede considerarse que un entregable que describe el primer nivel de
desglose de una función posee un bajo grado de desglose. Si se describe la
totalidad del desglose de la función y se proporcionan descripciones de todas las
funciones que no están a su vez desglosadas, se puede considerar que existe un alto
grado de desglose.
Algunas propiedades funcionales se describen utilizando técnicas no jerárquicas.
En este caso, el grado de desglose suele referirse a los elementos de la técnica que
deben describirse o se pueden omitir. Por ejemplo:
• elementos de información incluidos en la visión de la información del negocio
• datos retenidos incluidos en la visión de los datos del sistema informático.
Para una adaptación en particular pueden definirse, si es preciso, varios grados de
desglose, al objeto de facilitar una secuencia de decisiones asociadas en esa
adaptación.
Grado de especialización
El grado de especialización indica si el elemento descriptivo describe:
• un sistema (dominio objetivo, sistema de información o sistema informático)
o proceso/servicio generalizado y, por tanto, simplificado
• o bien el sistema (o proceso/servicio) en toda su especificidad y con todos
sus comportamientos especiales.
Los grados de especialización se definen del modo siguiente:
• un elemento descriptivo posee un alto grado de especialización si se
identifican y describen todos los subtipos de las propiedades que recoge
(procesos, eventos, agentes, etc.) o los casos especiales
• un elemento descriptivo posee un bajo grado de especialización si no se
identifican y describen todos los subtipos de las propiedades que recoge
(procesos, eventos, agentes, etc.) o los casos especiales. Únicamente se
describen los casos normales o generales.
Ejemplo: Puede considerarse que un elemento descriptivo que describe un proceso
de venta en el que se definen todos los casos especiales (clientes nacionales e
internacionales, diferentes condiciones de crédito, pedidos urgentes y normales,
etc.), posee un alto grado de especialización. Si únicamente se describen los casos
más habituales (cliente nacional, pedido normal, etc.), puede considerarse que
existe un bajo grado de especialización.

Para una adaptación en particular pueden definirse, si es preciso, varios grados de

especialización, al objeto de facilitar una secuencia de decisiones asociadas en
dicha adaptación.
El nivel de detalle y el alcance de un entregable pueden combinarse de diferentes
maneras con objeto de obtener la base adecuada para una decisión; por ejemplo,
una decisión acerca de:
• la viabilidad, coste y beneficios de un sistema suele precisar un alcance
íntegro y un bajo grado de desglose y de especialización
• la idoneidad de una interfaz hombre-ordenador relativa a una tarea
determinada precisará un alcance parcial y un alto grado de desglose y de
especialización.
3.6.7 Nivel de acuerdo

El nivel de acuerdo se ocupa del aspecto social de la descripción del sistema (o
proceso/servicio). Indica hasta qué punto los agentes del dominio objetivo están de
acuerdo con las descripciones.
Normalmente, estos agentes poseen diferentes puntos de vista acerca del dominio
objetivo, su sistema de información y sus necesidades, debido a diferencias
psicológicas, políticas, funcionales, geográficas y culturales. Estos puntos de vista
revelan contradicciones, coincidencias parciales y lagunas. Cuando se intenta
integrar estos puntos de vista surgen conflictos, aunque éstos no son siempre
negativos, ya que pueden ayudar a identificar problemas y estimular la creatividad.
Es preciso gestionar los conflictos e incoherencias al objeto de integrar los puntos
de vista en un conjunto coherente de descripciones que expresen los requisitos del
dominio objetivo y su sistema de información.
El nivel de acuerdo deberá indicar:
• qué agentes del dominio objetivo participan en el acuerdo en torno al
Los agentes que se ocupan de las descripciones pueden variar con el tiempo,
según las visiones que cubra el elemento descriptivo y otras características.
Por ejemplo, a los usuarios de un sistema informático les afectará
principalmente la visión de las prácticas de trabajo, mientras que a los
agentes encargados del mantenimiento y operación de ese sistema
informático les interesará sobre todo la visión de la arquitectura del sistema
informático.
• qué procedimientos de gestión del acuerdo se utilizan.
Deberán indicar cómo organizar la participación de los agentes, y la
cooperación y negociaciones entre los agentes, cómo resolver las
incoherencias y gestionar los conflictos, y qué tipo de acuerdo se espera
respecto a la descripción.
Para cada elemento descriptivo, visión o propiedad funcional en particular, el
perfil del elemento descriptivo incluirá un conjunto de valores y un texto
explicativo que describa los dos puntos anteriores.

Capítulo 3
Entregables
3.6.8 Grado de formalismo

El grado de formalismo describe el tipo de lenguaje de representación que debe
utilizarse para el elemento descriptivo.
explicativo que describa el grado de formalismo.
Los grados de formalismo se dividen en:
• formal
si el lenguaje de representación se basa en sistemas matemáticos o de cálculo
lógico.
• semiformal
si el lenguaje de representación se basa en notaciones gráficas cuyos
símbolos poseen un significado definido, o en una notación textual que
consiste en un conjunto limitado de construcciones con un significado y una
sintaxis definidos.
• informal
si el lenguaje de representación se basa en un lenguaje natural, ilustraciones
gráficas, animación, etc.
Los lenguajes formales y semiformales pueden parafrasearse en un lenguaje natural
para que las descripciones sean más sencillas de utilizar. La necesidad de
parafrasear también puede indicarse en el texto que describe el grado de
formalismo.
3.6.9 Cuantificación
Es posible cuantificar los sistemas, procesos, servicios y sus propiedades (por
ejemplo, información, datos, tareas, funciones, recursos, unidades de proceso,
software). La cuantificación puede expresarse en términos de volumen, capacidad,
carga de trabajo, esfuerzos, recursos, utilización, tiempo, duración, frecuencia, etc.
del elemento descriptivo deberá contener un valor que indique si el sistema o
proceso/servicio descrito está o debería estar cuantificado, y que haga referencia a
un texto que explique el tipo de cuantificación. Deberán indicarse las unidades de
medida y la métrica.
3.6.10 Simulación
Una simulación es una representación artificial de un sistema real. La simulación es
una manera importante de aprender acerca del comportamiento y el rendimiento de
un sistema. Asimismo, para la mayoría de los agentes del dominio objetivo es más
sencillo entender un sistema que utilice simulaciones que otro que utilice
especificaciones abstractas.
Las simulaciones también pueden utilizarse en relación con procesos/servicios.

Ejemplos de simulación: un prototipo, una maqueta de interfaz hombre-ordenador,

una animación de un proceso, un escenario, una simulación estadística, un repaso
de una especificación.
Un prototipo es un modelo o implementación preliminar adecuado para la
evaluación del diseño, rendimiento y potencial de producción de un sistema; o para
una mejor comprensión o determinación de los requisitos [ISO-2382-20]. El
sistema a que se hace referencia suele formar parte del sistema informático. Un
prototipo, mientras se encuentra en funcionamiento, no es una parte del sistema
informático del dominio objetivo, sino un medio especial para recoger
conocimientos acerca de este sistema informático.
Una maqueta de interfaz hombre-ordenador simula el comportamiento externo de
una parte de un sistema informático que interactúa con un ser humano.
Una animación es una visión de un proceso en acción: permite que una persona
interactúe con el proceso mediante el envío de mensajes y visualice el estado del
proceso (normalmente utilizando una interfaz hombre-ordenador).
El término escenario suele referirse a la simulación del funcionamiento de una
organización. Un escenario puede considerarse como una historia en la que actúan
personas que representan a los agentes del dominio objetivo. Los escenarios
pueden utilizarse para simular procesos/servicios.
del elemento descriptivo deberá contener un valor que indique si el sistema o
proceso/servicio descrito está o debería estar simulado, y que haga referencia a un
texto que explique el tipo de simulación. Es posible simular las propiedades
funcionales y las propiedades de calidad al objeto de definir sus requisitos o para
comprobar que cumplen los requisitos definidos.
La solicitud de una simulación no significa que el entregable deba utilizar un
lenguaje de descripción formal, ni siquiera si la simulación se realiza utilizando un
lenguaje de descripción formal. Más aún, el lenguaje que utilicen los agentes del
proyecto para desempeñar sus tareas no tiene por qué ser el mismo que el que se
utiliza para los entregables de los clientes.
3.6.11 Identificación de la versión del sistema/servicio

Es preciso identificar la versión del sistema o servicio que se describe: puede
tratarse del sistema/servicio actual o de una versión futura del mismo.
El sistema/servicio puede evolucionar entre el momento en que se elabora el perfil
del elemento descriptivo y el momento en que se realiza la descripción. Asimismo,
puede evolucionar durante la realización de la descripción. Por tanto, es preciso
identificar sin ambigüedades la versión del sistema/servicio que se describe. Se
precisará un texto explicativo cuando la simple mención del sistema/servicio actual
o futuro no baste para eliminar las ambigüedades.
3.6.12 Soluciones alternativas

Cuando se utiliza el elemento descriptivo para el diseño de una futura versión del
sistema/servicio, puede que sea preciso describir más de una solución posible. Por

Capítulo 3
Entregables
tanto, para cada elemento descriptivo, visión o propiedad en particular, el perfil del
elemento descriptivo deberá contener un valor que indique si se precisan
soluciones alternativas y, de ser así, un texto explicativo que describa las
características de estas soluciones.
3.6.13 Estado de calidad de un elemento descriptivo

El estado de calidad de un elemento descriptivo se refiere a si cumple los criterios
de calidad que definen los procedimientos aplicables de garantía de calidad.
Las revisiones e inspecciones son ejemplos de procedimientos de calidad. Para la
simulación, el procedimiento de calidad deberá especificar qué requisitos y
propiedades de calidad se utilizarán para medir la simulación.
Para cada elemento descriptivo en particular, el perfil del elemento descriptivo
deberá contener un valor que indique el procedimiento de garantía de calidad y los
criterios de calidad que se han aplicado o deberían aplicarse.
El estado de calidad que se precisa en un determinado punto de decisión depende
del tipo de decisión. Ciertos tipos de decisiones no requieren la comprobación de
determinados requisitos de calidad o la aplicación de los últimos procedimientos de
calidad.

Capítulo 4
Técnicas de planificación de la adaptación
4 Técnicas de planificación de la adaptación

Este capítulo contiene orientaciones para la planificación de adaptaciones, de
manera que se ciñe estrictamente a ellas. Debe ser leído por los responsables de
proyecto de los clientes y de los proveedores. En el transcurso de una adquisición
se suele acceder a él desde el capítulo 2 a través de las referencias
correspondientes.
Definición Una técnica es un conjunto de heurísticas y procedimientos que

explican cómo crear un grupo de uno o más productos en una
notación especificada. Una técnica es un medio para conseguir
objetivos específicos de manera más fácil, rápida, segura, precisa o,
en algunos casos, de manera más adecuada [EM-DC].
Las técnicas de planificación de la adaptación se utilizan para elaborar un plan de

adaptación para una adaptación singular del SI. El contenido de un plan de
adaptación se describe en el apartado 3.2. Un plan de adaptación puede
evolucionar, pasando por distintas versiones. En una situación típica, el cliente crea
una versión inicial al preparar la petición de ofertas; los proveedores crean
versiones elaboradas como parte de las ofertas; y el cliente, junto con el proveedor
seleccionado, crean una versión final como parte del contrato. Es importante que el
contrato incorpore un plan de adaptación, ya que determina el estado inicial y el
estado final y define los requisitos contractuales de cada una de las entregas en la
adaptación del SI. Durante la adaptación del SI, lo normal es que el plan de
adaptación permanezca invariable, aunque las decisiones acerca de cambios en el
contrato pueden motivar su modificación.
Las técnicas de planificación de la adaptación mencionadas en este capítulo pueden Técnicas para
aplicarse cuando ya se tiene una idea general de cómo va a ser una adaptación planificar una
singular del SI, es decir, se ha perfilado el punto de partida (estado inicial) y el adaptación
objetivo (estado final), y podrán aplicarse de nuevo en cualquier momento durante singular del SI
una adquisición. El capítulo 2 contiene orientaciones acerca de cuándo y cómo
utilizar las técnicas.
(þ 2: El proceso de adquisición)
4.1 Gestión del riesgo

adversas de eventos futuros [EM-DC].
Las técnicas de planificación de la adaptación mencionadas en este capítulo se

centran en la gestión del riesgo mediante puntos de decisión a nivel contractual. Es
preciso planificar la secuencia de puntos de decisión para reducir la probabilidad de
riesgo y las consecuencias adversas de los eventos.

En toda situación existen cuatro aspectos que contribuyen al riesgo: complejidad,

incertidumbre, opciones y consecuencias.
Situación Se puede hablar de una situación arriesgada cuando ésta es compleja o incierta y
arriesgada y encierra varias opciones alternativas, y cuando algunas opciones pueden ofrecer
situación atada más beneficios que otras. La incertidumbre puede referirse a la probabilidad de que
tenga lugar un evento o a la severidad de las repercusiones de este evento. Cuando
no existen opciones, un gestor no se enfrenta a una situación arriesgada, sino a una
atada, o al menos que escapa a su control. Es preciso comprender tanto la
probabilidad de un evento como sus repercusiones, al objeto de tener una
apreciación real de las oportunidades y riesgos que conlleva cualquier opción.
En general, una adaptación del SI es un proceso arriesgado. La planificación de la
adaptación contiene varias opciones alternativas a seleccionar. Eurométodo
proporciona listas de factores situacionales que pueden implicar complejidad e
incertidumbre. Estas listas pueden utilizarse para identificar los riesgos críticos y
para comprender mejor los motivos subyacentes a estos riesgos.
Gestión de Cada nivel de gestión posee un alcance diferente y distintas opciones que afectan a
riesgos en cada los distintos tipos de riesgos. Las decisiones a nivel de alta dirección, relativas a la
nivel de gestión planificación de la adquisición, afectan a los objetivos generales de negocio y a la
asignación de los recursos necesarios para conseguir estos objetivos. Ello puede
dar lugar a asignaciones inadecuadas de los recursos (riesgos de infrafinanciación).
Las decisiones a nivel de gestión del contrato, relativas a la planificación de la
adaptación, se ocupan de dar cumplimiento a los requisitos existentes con los
recursos disponibles. Ello puede dar lugar a unos niveles de productividad
inadecuados (riesgos de infraprestación).
Las técnicas de planificación de la adaptación mencionadas en este capítulo se
refieren principalmente a las decisiones a nivel de gestión del contrato; es decir, la
reducción de los ‘riesgos de infraprestación’.
Disciplina en la Los gestores que obtienen resultados favorables en la gestión de los riesgos
toma de mantienen un alto nivel de disciplina a la hora de adoptar decisiones; ello no
decisiones significa que sean dogmáticos y burocráticos, sino que el gestor:
• se asegura que se delimita debidamente el alcance de la situación
• identifica y valora los riesgos
• identifica opciones válidas para reducir el riesgo a un nivel aceptable
• recoge información apropiada y válida para valorar el riesgo y las opciones y
para supervisar el riesgo
• utiliza razonamientos bien fundados al realizar los intercambios
• se decide por una línea de acción concreta.
Eurométodo proporciona técnicas para apoyar un enfoque disciplinado de la toma
de decisiones en el nivel contractual de una adaptación del sistema de información.

Capítulo 4
La gestión de riesgos se compone de tres subprocesos:

Procesos dentro
• Análisis de riesgos. de la gestión de
Los riesgos de un plan o una política propuestos se identifican y valoran de riesgos
forma sistemática. Durante la identificación se explicitan los supuestos
relativos a la situación. Eurométodo proporciona técnicas que sustentan el
análisis de riesgos.
• Planificación de la gestión de riesgos.
Se identifican opciones alternativas para gestionar los riesgos; por ejemplo,
opciones estratégicas del proyecto. Se seleccionan las opciones y se planifica
una línea de acción apropiada. Eurométodo proporciona técnicas que
soportan la elección de una estrategia de adaptación y la planificación de
puntos de decisión.
• Supervisión de riesgos.
Define un medio para medir si las contramedidas tienen éxito o no. Además
de otras actividades de seguimiento, la línea de acción determinada se
comprueba continuamente, al tiempo que se definen y planifican medidas
correctivas. Eurométodo proporciona orientación acerca de la planificación
de los puntos de decisión de la supervisión de riesgos, y técnicas para la
evaluación de la situación actual de un plan de adaptación.
Los procesos de análisis y planificación se suelen dividir en fases. El motivo de esta No extraer
separación es garantizar que las decisiones de planificación se basan en toda la conclusiones
información relevante que se ha recopilado durante el análisis de riesgos. Las precipitadas
soluciones para la reducción de riesgos no deberán llegar demasiado pronto. Es
muy fácil proponer soluciones simples para situaciones complejas y actuar antes de
que se hayan podido recopilar y analizar todos los datos. Recuerde: Para obtener
buenas respuestas es preciso hacer buenas preguntas.
Eurométodo se centra en las causas primordiales de los riesgos, los factores de Comprender los
situación, en lugar de en sus efectos, ya que es vital comprender estas causas factores de
primordiales si se desea que la línea de acción seleccionada obtenga un resultado situación
favorable. El mejor enfoque es eliminar las fuentes de riesgo siempre que sea
posible, por ejemplo, modificando los factores situacionales.
La gestión de riesgos es compleja, ya que existen interacciones entre los riesgos. Interacciones
No es frecuente hallar un riesgo único; lo más habitual es un grupo de riesgos. Los entre los riesgos
efectos de un riesgo pueden ser la causa de otro, o una causa puede dar lugar a
varios riesgos. La reducción de un riesgo hace a menudo que aumente otro. Por
ejemplo, las medidas para minimizar el riesgo de baja calidad de los productos
suelen implicar un aumento de los costes del proyecto. Las técnicas de
Eurométodo cubren sólo algunas de estas interacciones de riesgos. Por lo tanto,
las técnicas deberán complementarse con la experiencia del gestor.
La figura 4.1 ofrece una visión general de las técnicas que proporciona
Eurométodo. Las dependencias de datos entre estas técnicas son similares a las
dependencias que se ilustran y explican en el apartado 2.2.

Técnicas (pasos) Insumo y resultados

Análisis de riesgos: Insumo: Información acerca de la situación del
problema, incluyendo las líneas generales de
1. Documentar el estado inicial y el estado
un plan de adaptación: objetivo, estado inicial,
final.
requisitos de puntos de decisión.
2. Valorar los factores de situación.
Resultados:
3. Evaluar la incertidumbre y complejidad
Apreciación y descripción de una situación del
generales.
problema: estados inicial y final, factores
4. Analizar la probabilidad de riesgos. situacionales y riesgos (probabilidades y
repercusiones).
5. Identificar los riesgos críticos.
Diseño de una estrategia de adaptación: Insumo: Información acerca de la situación del
problema, incluyendo los factores situacionales
1. Seleccionar las contramedidas.
y los riesgos (probabilidades y repercusiones).
2. Analizar las opciones estratégicas.
Resultados:
3. Seleccionar las opciones estratégicas.
Descripción de una estrategia de adaptación:
4. Analizar las repercusiones de la estrategia. opciones estratégicas, contramedidas
necesarias.
Planificación de los puntos de decisión: Insumo: Información acerca de la situación del
problema y la estrategia de adaptación
1. Extraer la secuencia básica de puntos de
(opciones de estrategia y contramedidas).
decisión.
Resultados:
2. Adaptar la secuencia básica a las
contramedidas. Descripción de la secuencia y contenido de los
3. Describir los puntos de decisión.
Descripción de los entregables: Insumo: Descripciones de los puntos de
decisión con los requisitos de los entregables.
1. Definir los perfiles de los elementos
descriptivos. Resultados:
2. Establecer un enlace con los productos del Descripciones de los puntos de decisión con los
método. perfiles de los entregables y referencias a los
productos del método.
Valoración del plan de adaptación: Insumo: Un plan de adaptación e información
acerca de la situación actual.
1. Valorar la descripción de la situación.
Resultados:
2. Valorar la idoneidad de la estrategia.
Valoración de la idoneidad de un plan de
3. Valorar la idoneidad de los puntos de
adaptación en la situación actual.
decisión.
Figura 4.1: Técnicas de planificación de la adaptación en una adaptación singular

del sistema de información.
4.2 Análisis de riesgos

Tanto los clientes como los proveedores pueden utilizar las técnicas de análisis de
riesgos descritas en este apartado, aunque cada uno de ellos tendrá objetivos
diferentes.

Capítulo 4
El cliente puede utilizar estas técnicas para valorar de una forma clara y sistemática
las características y los riesgos de la situación del problema.
Un proveedor que dude entre presentar o no una oferta podrá utilizar las técnicas
para comprender y valorar mejor la situación del problema.
Tanto el cliente como el proveedor pueden utilizar las técnicas en el curso de una
adaptación del SI cuando sea preciso cambiar los planes o planificar futuras
adaptaciones del SI.
La finalidad de las técnicas de análisis de riesgos es comprender los aspectos
relevantes de la situación de una adaptación presente o futura del SI, para estar
en condiciones de emprender las acciones adecuadas.
El análisis de riesgos se sustenta en los factores situacionales definidos en Eurométodo
Eurométodo. Para valorar los factores situacionales, es importante comprender proporciona
bien las expectativas actuales con respecto a los resultados y el punto de partida de definiciones de
la adaptación del SI. Para ello deberá documentarse el punto de partida (estado los factores
situacionales
inicial) y el objetivo (estado final). La valoración de los factores situacionales es la
base para la evaluación de la incertidumbre y la complejidad de la situación. Los
riesgos pueden extraerse de los factores situacionales y de la incertidumbre y
complejidad generales. Posteriormente, se identificará la importancia de los riesgos
analizando las probabilidades y repercusiones de los mismos.
Los resultados obtenidos con este análisis de la situación del problema representan
un insumo para la definición de la estrategia de adaptación y la planificación de los
4.2.1 Documentar el estado inicial y el estado final

Se trata de una técnica que permite documentar el estado inicial y el estado final de Estados iniciales
una adaptación del SI en un plan de adaptación. En apartado 2.2 se indica cómo y finales típicos
definir una adaptación viable del SI en términos de un estado inicial y un estado
final. En el apartado 2.2 se definen los estados iniciales y finales típicos y se explica
qué combinaciones son gestionables y cuáles son difíciles de gestionar.
Definición El estado inicial de una adaptación del SI es el estado del sistema de

información y los conocimientos disponibles sobre el mismo al
comienzo de la adaptación del SI.
El estado final de una adaptación del SI es el estado del sistema de

información y los conocimientos sobre el mismo al final de la
adaptación del SI [EM-DC].
En la práctica, las descripciones de los estados inicial y final suelen producirse en

paralelo, aunque aquí se relacionan en su orden natural:
1. Documentar el estado inicial.
Comprender y describir el contenido y calidad de los elementos descriptivos y
de los elementos operativos que estarán disponibles para los agentes del
proyecto que realicen la adaptación del SI.

2. Documentar el estado final.

¿Qué
descripciones
Analizar qué elementos descriptivos y qué elementos operativos precisará y
utilizará el utilizará el cliente cuando haya finalizado esta adaptación del SI. Bosquejar los
cliente después elementos operativos y describir los elementos descriptivos en forma de
de la adaptación perfiles, como se explica en el capítulo 3.
del SI?
Documentar el estado inicial
Es posible que Es posible que algunos productos del estado inicial ya existan, y otros vayan a
algunos producirse antes del inicio de la adaptación del SI; por ejemplo, a raíz de otra
productos del adaptación del SI o de un proceso de licitación. Estas expectativas deberán
estado inicial no documentarse en base a los planes actuales y demás información relevante.
existan aún
Los elementos descriptivos del estado inicial pueden describir elementos operativos
que ya se utilizan en el estado inicial o elementos operativos futuros, por ejemplo
los elementos operativos que deberían construirse e instalarse en esta adaptación
del SI. Las descripciones de futuros elementos operativos pueden utilizarse para
comprender los cambios que precisa el SI operativo, y para comprender el SI en su
estado final. Por consiguiente, pueden utilizarse para documentar el estado final.
Desglosar en Para documentar el estado inicial, normalmente es preciso desglosar en subsistemas
subsistemas el SI en su estado inicial o futuro y, en aquellas situaciones en que sea posible y
procedente, describir el estado inicial de cada uno de los subsistemas. Los
subsistemas pueden definirse mediante un mayor desglose del dominio objetivo en
dominios objetivos de menor tamaño.
Elementos Para cada subsistema podrá utilizarse el siguiente procedimiento:
operativos y
elementos
1. Valorar qué descripciones de elementos operativos utilizados o construidos en
descriptivos del el estado inicial, son relevantes para esta adaptación del SI.
estado inicial − Describir los elementos operativos mediante una visión general basada en
la información disponible en la situación actual.
− Describir los elementos descriptivos mediante sus perfiles, véase apartado
4.5.1.
2. Valorar qué descripciones de futuros elementos operativos son relevantes para
ser utilizadas en esta adaptación del SI.
− Describir los elementos descriptivos mediante sus perfiles, véase apartado
4.5.1.
Documentar el estado final

Para documentar el estado final, normalmente es preciso desglosar en subsistemas
el SI en su estado final y, en aquellas situaciones en que sea posible y procedente,
definir el estado final de cada uno de los subsistemas. Pueden existir diferentes
tipos de elementos descriptivos relativos a los subsistemas.
Para cada subsistema podrá utilizarse el siguiente procedimiento:
Elementos 1. Describir los elementos operativos utilizados o construidos en el estado final
operativos del mediante un resumen de los elementos descriptivos existentes en la situación
estado final actual. El resumen deberá centrarse en:

Capítulo 4
− los elementos operativos que van a cambiarse en el SI en su estado inicial,

y los nuevos elementos operativos que van a construirse e instalarse.
− los manuales y documentación de apoyo que se precisan para garantizar
que el nuevo SI funciona con eficiencia y sin problemas.
− los datos que se hallan en el sistema de información existente y que deben
convertirse en nuevos elementos operativos del nuevo sistema de
información (migración de datos).
− los elementos operativos que se van a construir, pero no instalar.
− las interfaces necesarias entre los nuevos elementos operativos, instalados
como parte de esta adaptación del SI, y los elementos operativos que se
utilizan actualmente
− la nueva organización y los nuevos agentes que se introducirán, como por
ejemplo el inicio de un servicio o la cancelación de un servicio.
2. Describir los perfiles de las descripciones que deberían estar disponibles en el Elementos
estado final. descriptivos del
− Los elementos descriptivos que se precisan para mantener de forma eficaz estado final
el sistema de información en su estado final. Deberá definirse la política de
mantenimiento de estos elementos descriptivos, por ejemplo: quién es
responsable de este mantenimiento.
− Los elementos descriptivos que van a utilizarse tras la finalización de esta
adaptación del SI al objeto de continuar desarrollando de manera eficiente
el sistema de información en su estado final. Siempre que sea posible
deberán utilizarse los planes disponibles acerca de desarrollos ulteriores.
3. Si esta adaptación del SI dará como resultado propuestas de futuras Planes del estado
adaptaciones del SI, es preciso describir: final
− los requisitos de los planes apropiados para estas futuras adaptaciones del
SI, incluyendo los requisitos de los perfiles de los elementos descriptivos
presentes en el estado final.
Listas de comprobación
Las figuras 4.2 y 4.3 muestran una visión general de los productos que pueden
estar disponibles al inicio y al final de una adaptación del SI. Estas figuras pueden
utilizarse como listas de comprobación al documentar los estados inicial y final.

Productos al inicio de la adaptación Productos al final de la

del SI: adaptación del SI:
Productos del estado inicial Productos del estado final
Versión del Sistema de Futuro sistema de Sistema de Futuro

sistema información en información información en sistema de
estado inicial estado final información
Producto
Elementos operativos 1. 2. 11. 12.

Elementos Elementos Elementos Elementos
operativos operativos operativos operativos
utilizados en el construidos, pero utilizados en el construidos,
estado inicial que aún no se estado final pero que aún
utilizan no se utilizan
Elementos 3. 4a. 13. 14a.

descriptivos
Descripciones de Descripciones de Descripciones Descripciones
1: elementos 2: elementos de 11: de 12:
operativos operativos elementos elementos
utilizados en el construidos, pero operativos operativos
estado inicial que aún no se utilizados en el construidos,
utilizan. estado final pero que aún
no se utilizan.
4b.
14b.
Descripciones de
11 y 12: futuros Descripciones
elementos de futuros
operativos elementos
operativos.
Perfiles de elementos 5. 6a. 15. 16a.

descriptivos de planes
Perfiles de 3: Perfiles de 4a y Perfiles de 13: Perfiles de 14a
de adaptación
descripciones de 4b: descripciones y 14b:
elementos descripciones de de elementos descripciones
operativos futuros elementos operativos de futuros
utilizados en el operativos utilizados en el elementos
estado inicial estado final operativos.
6b.
16b.
Perfiles de 13,
14a y 14b: Perfiles de
elementos futuros
descriptivos del elementos
estado final descriptivos
Figura 4.2: Productos de los estados inicial y final relacionados con las versiones
del sistema.

Capítulo 4
Productos al inicio de la adaptación del Productos al final de la

SI: adaptación del SI:
Productos del estado inicial Productos del estado final
Adaptación del SI Adaptación actual del sistema de Futura adaptación del sistema
información de información
Producto
que comienza en el estado inicial que comienza en el estado
final o más tarde
Planes de adaptación Un plan de adaptación que incluya: Posiblemente planes de
adaptación para futuras
• Descripciones del estado inicial
adaptaciones del SI
- Resumen de 3 y 4a:
descripciones de elementos
operativos utilizados o
construidos en el estado
inicial.
- 5, 6a: perfiles de los
elementos descriptivos
disponibles en el estado
inicial.
• Descripciones del estado final
- Resumen de 4b:
descripciones de elementos
operativos utilizados o
construidos en el estado
final.
- 6b: perfiles de los elementos
descriptivos del estado final.
- Requisitos de los planes de
adaptación presentes en el
estado final, por ejemplo,
requisitos de 15, 16a, 16b:
perfiles del estado final y
futuros elementos
descriptivos.
Planes del proyecto Posiblemente un plan del proyecto que Posiblemente planes de
incluya: proyecto para futuras
• plan de desarrollo adaptaciones del SI
• plan de garantía de calidad
• plan de gestión de la configuración
Figura 4.3: Productos de los estados inicial y final relacionados con adaptaciones
del SI.
(Los números remiten a la figura 4.2)

4.2.2 Valorar los factores situacionales
Definición Los factores situacionales son aquellas particularidades de la

situación del problema que pueden utilizarse para determinar la
estrategia más adecuada para resolver el problema. Se incluyen
aquellas propiedades que pueden influir en los distintos tipos de
eventos inciertos que puedan ocurrir y sus consecuencias adversas
[EM-DC].
El análisis de los factores situacionales según Eurométodo puede utilizarse para

predecir los riesgos de una situación y para determinar la estrategia de adaptación
más apropiada a fin de evitar o contener dichos riesgos.
Lista de El análisis de los factores de situación utiliza una lista de comprobación para
comprobación adquirir conocimientos acerca de una situación del problema. Los conocimientos
para adquirir pueden adquirirse analizando documentos y/o entrevistando a los agentes clave del
conocimientos sistema de información. Es preciso planificar con cuidado las entrevistas y tener en
cuenta los siguientes puntos:
• ¿Quién va a llevar a cabo el análisis de los factores situacionales?
En general, se recomienda que el análisis de los factores situacionales corra a
cargo de más de una persona.
• ¿Cómo redactar las preguntas?
El análisis de los factores situacionales deberá adaptarse siempre a la
situación y las preguntas deberán redactarse de manera que la persona
entrevistada comprenda los factores y los motivos de las preguntas.
Estas entrevistas deberían proporcionar información que justifique los valores de
los factores situacionales y, por tanto, exponga los riesgos. Se precisan los valores,
por ejemplo, complejo y cierto, y la relación de elementos, para explicar y justificar
estos valores.
Las preguntas Las figuras 4.4 a 4.6 proporcionan una visión general de los factores situacionales,
pueden derivarse sus definiciones, influencia en los riesgos y valores. El anexo B contiene
de las descripciones detalladas de los factores. La estructura de las descripciones se
definiciones del muestra en la figura 4.7. De estas descripciones se pueden extraer las preguntas
anexo B
que deben plantearse al objeto de adquirir los conocimientos necesarios para
determinar los valores de los factores situacionales.
Dividir en Cuando las respuestas relativas a un factor situacional son poco claras o demasiado
subsistemas o generales, normalmente indican que el alcance del SI que se está investigando es
subfactores demasiado grande. En este caso el sistema de información deberá dividirse en
subsistemas, y deberán investigarse los factores de situación para cada subsistema.
Otro modo de reducir la complejidad de las preguntas es dividir un factor

Capítulo 4
situacional en subfactores que puedan investigarse de forma independiente.

Eurométodo especifica subfactores de varios de los factores situacionales 18.
Los anexos D.17 y D.18 contienen plantillas de tablas de factores situacionales que Documentar y
pueden utilizarse para registrar los factores situacionales marcando con una señal justificar los
los valores apropiados para la situación del problema en cuestión. De este modo se valores de los
obtiene una visión general de la situación del problema, que puede utilizarse para la factores
situacionales
definición de una estrategia de adaptación adecuada. Las tablas de factores
situacionales deberán estar respaldadas por una explicación y justificación de los
valores seleccionados. La lista de factores situacionales no es definitiva ni
exhaustiva. Contiene ejemplos que pueden utilizarse y mejorarse en base a la
experiencia personal y organizativa.
Las tablas de factores situacionales resaltan el carácter abierto de Eurométodo, al
tener filas vacías en las que pueden describirse otros factores situacionales.
Se recomienda que las personas que lleven a cabo la valoración de los factores Sistematizar y
situacionales registren su propia experiencia señalando: utilizar la propia
experiencia
• qué factores situacionales adicionales (actualmente no definidos en
Eurométodo) es importante tener en cuenta, y cómo pueden influir en los
riesgos y en la estrategia de adaptación
• cómo determinar los factores situacionales relevantes (por ejemplo, en forma
métrica, como tamaño del proyecto), adaptados a sus situaciones típicas del
problema; y los métodos para adquirir los conocimientos necesarios en una
organización
• qué factores situacionales son los más importantes; por ejemplo, en forma de
grados de importancia a aplicar a los diferentes factores.
Clasificación de los factores situacionales

En apoyo de la valoración de los factores situacionales, éstos se organizan en una
matriz bidimensional: el dominio y la caracterización de los conocimientos.
La dimensión del dominio determina qué parte de la organización debe Dominio
investigarse. Se consideran dos dominios: objetivo y
factores del
• Dominio objetivo. dominio del
La parte de la organización para la cual debe adaptarse el SI. Los factores proyecto
del dominio objetivo se dividen en dos categorías:
− sistema de información: propiedades del sistema de información en
general.
− sistema informático: propiedades específicas del sistema informático del
sistema de información.
• Dominio del proyecto.
18 Los subfactores deberán tenerse en cuenta al evaluar el factor. No obstante, no suele existir
ningún algoritmo o regla para deducir el valor en base a los valores de los distintos
subfactores.

La organización que realiza la adaptación del sistema de información. Los

factores del dominio del proyecto se dividen en cuatro categorías:
− tarea del proyecto: propiedades relativas a la tarea y subtareas
(asignaciones de trabajo bien definidas y sujetas a responsabilidad).
− estructura del proyecto: propiedades relativas a la estructura (sistemas de
comunicación, responsabilidades y flujos de trabajo en el proyecto).
− agentes del proyecto: propiedades relativas a los agentes del proyecto
(personas que realizan partes del proyecto).
− tecnología del proyecto: propiedades relativas a la tecnología (métodos,
técnicas y herramientas) utilizada en el proyecto.
Factores de La otra dimensión, la caracterización de los conocimientos, divide los
complejidad e conocimientos adquiridos para gestionar la situación del problema en las categorías
incertidumbre de complejidad e incertidumbre. Todo factor situacional puede afectar a los riesgos
y la idoneidad de una estrategia de adaptación, bien directamente, bien a través de
su contribución a la incertidumbre y complejidad generales de la situación:
• la complejidad puede considerarse la dificultad hallada al gestionar los
conocimientos disponibles. La escala de complejidad de una situación es:
simple⇒moderada⇒compleja19.
• la incertidumbre puede considerarse la falta de conocimientos disponibles. La
escala de incertidumbre de una situación es: cierta⇒moderada⇒incierta.
19 Normalmente se utiliza una escala de tres niveles. Si hay más niveles surgen dificultades al
asignar un valor al factor cuando se analiza la situación del problema y al asociar una
estrategia de adaptación a cada uno de los valores. La reducción dos niveles supone una
clasificación demasiado generalizada, en la medida en que proponen casos extremos y no
permiten expresar una situación normal o neutra.

Capítulo 4
Dominio Factor de Breve descripción e influencia en los riesgos simple moderada compleja
objetivo complejidad
Sistema de Heterogeneidad Los agentes pueden ser heterogéneos por motivos baja media alta
información de los agentes organizativos, políticos o individuales. Ejemplos de
agentes: usuarios, gestores, socios, operadores y
máquinas.
êConflictos en los requisitos.
êLa adaptación del SI no se acepta.
Tamaño del Puede expresarse en número de áreas de negocio y pequeño medio grande
dominio número de unidades organizativas.
objetivo êPérdida de control del proyecto.
Tamaño de la Número de sedes geográficas. pequeño medio grande
distribución êEl sistema de información no funciona.
êPérdida de control del proyecto.
Complejidad Los recursos de información del dominio objetivo. baja media alta
de la Por ejemplo pueden expresarse en número de
información entidades, atributos y relaciones.
êEl sistema de información no funciona.
Complejidad Subfactores: número de procesos de negocio e baja media alta
de los procesos interfaces, y complejidad de las reglas y algoritmos
de negocio del negocio.
Sistema Complejidad Los datos que representan la información y se baja media alta
informático de los datos almacenan en un ordenador. Por ejemplo, pueden
expresarse en número de entidades, atributos y
relaciones.
Complejidad Las partes de los procesos que son ejecutadas por baja media alta
de las un ordenador. Por ejemplo, pueden estimarse
funciones utilizando el Análisis de Punto de Función.
automatizadas êEl sistema de información no funciona.
Complejidad Ejemplos de subfactores: eficiencia, seguridad, baja media alta
de las fiabilidad, mantenibilidad, portabilidad y facilidad
propiedades de de uso.
calidad êEl sistema de información no funciona.
Número de El número de copias del sistema informático que una pocas muchas
replicaciones debe instalarse.
del sistema ê Pérdida del control del proyecto.
informático
Complejidad La tecnología utilizada como plataforma de los baja media alta
de la tecnología dispositivos físicos y el software del sistema
objetiva informático.
Figura 4.4: Factores de complejidad relativos al dominio objetivo.

Dominio Factor de Breve descripción e influencia en los cierta mode- incierta

objetivo incertidumbre riesgos rada
Sistema de Actitud de los agentes Subfactores: percepción de la necesidad, pos. neutral neg.
información compromiso, motivación.
êFalta de participación de los agentes.
êLa adaptación del sistema de información no es
aceptada.
Habilidad de los Capacidad, experiencia, cualificaciones, alta mediana baja
agentes disponibilidad.
êSistema de información inadecuado.
Estabilidad del Subfactores: políticos, legales, de mercado, de alta mediana baja
entorno negocios y de estabilidad financiera.
êRequisitos variables (cambio del objetivo)
Formalidad de la La información puede estar formalizada y descrita alta mediana baja
información por datos.
êRequisitos irrealizables.
Formalidad de los Los procesos pueden estar formalizados y alta mediana baja
procesos del negocio parcialmente realizados por ordenador.
êRequisitos irrealizables.
Estabilidad de la Número y tipos de cambios previstos. alta mediana baja
información y de los êRequisitos variables (cambio del objetivo)
procesos del negocio
Especificidad del Tipo estándar frente a tipo específico. alta mediana baja
sistema de êRequisitos irrealizables.
información
Grado de La comprensión del sistema de información por alto mediano bajo
comprensión del parte del agente.
sistema actual êSistema de información incorrecto.
êCostes impredecibles.
Importancia Oportunidades estratégicas que ofrece el sistema de alta mediana baja
estratégica información.
êRepercusiones en el negocio de un fallo.
Importancia de los Repercusiones en la estructura de la organización y alta mediana baja
cambios organizativos las tareas de los agentes.
êLa adaptación del SI no es aceptada.
êCostes impredecibles para la organización.
Disponibilidad, Los requisitos son las condiciones esenciales que alta mediana baja
claridad y estabilidad debe satisfacer un SI.
de los requisitos êRequisitos inciertos e irrealizables.
êIncertidumbre en las interfaces con otros
sistemas.
Calidad de las Las especificaciones son descripciones definitivas. alta mediana baja
especificaciones êSistema de información inadecuado.
existentes êCostes impredecibles para el proyecto.
Sistema informático Importancia de los Importancia del cambio y repercusión en la alta mediana baja
cambios tecnológicos adaptación del SI.
êDeficiencias de calidad.
êCostes impredecibles para la organización.
Novedad de la Una medida del carácter innovador de la tecnología alta mediana baja
tecnología objetiva objetiva con respecto al estado de la técnica.
êDeficiencias de calidad.
êCostes impredecibles para el proyecto.
Figura 4.5: Factores de incertidumbre relativos al dominio objetivo.

Capítulo 4
Dominio Factor de Breve descripción simple mode- compleja

del proyecto complejidad rada
Tarea del Tamaño del proyecto Por ejemplo, número de meses o años de trabajo. pequeño mediano grande
proyecto êPérdida de control del proyecto.
Complejidad de la Una medida de la dificultad de la migración en todas las baja mediana alta
migración sedes operativas del dominio objetivo.
Estructura del Número de Se refiere al control del proyecto que se precisa para ninguno pocos muchos
proyecto subcontratistas gestionar recursos externos del proyecto.
Número de Se refiere al control del proyecto que se precisa para ninguna pocas muchas
interfaces con otras gestionar interfaces externas con otras adaptaciones del SI.
adaptaciones del SI êPérdida de control del proyecto.
Agentes del Número de agentes Número de interesados que se relacionan con la adaptación pequeño mediano grande
proyecto del proyecto del SI, como usuarios, expertos, personal de desarrollo,
clientes, gestores, etc.
Tecnología del Complejidad de la La complejidad de utilizar la tecnología del proyecto para baja mediana alta
proyecto tecnología del realizar la tarea de desarrollo.
proyecto êPérdida de control del proyecto.
Dominio del Factor de Breve descripción e influencia en los riesgos cierta mode- incierta
proyecto incertidumbre rada
Tarea del Innovación de la Una medida de la innovación que supone la adaptación del baja mediana alta
proyecto adaptación del SI respecto del estado de la técnica.
sistema de êSistema de información inviable.
información êCostes impredecibles del proyecto.
Idoneidad de los Debido a estimaciones erróneas o a la urgencia del - normal ajustada
programas proyecto.
êBaja calidad de los entregables; aumento de los costes.
Idoneidad del êBaja calidad de los entregables. - normal ajustada
presupuesto êRetrasos en la entrega.
Estructura del Dependencia de êDeficiencias en las tareas que se realizan externamente. nula baja alta
proyecto subcontratistas êPérdida de control del proyecto.
Dependencia de Por ejemplo, interfaces comunes, integración común. nula baja alta
otras adaptaciones êRequisitos variables; problemas de integración.
del SI
Formalidad del Conformidad con las reglas y procedimientos definidos. alta mediana baja
contexto cliente- ê Requisitos variables.
proveedor êLa adaptación del sistema de información no es
aceptada.
Agentes del Capacidad del Subfactores: cualificaciones, conocimientos, capacidad, alta mediana baja
proyecto equipo de proyecto experiencia, compromiso y disponibilidad.
êSI inadecuado; la adaptación del SI no es aceptada.
êNecesidad de profundos conocimientos de informática.
êBaja calidad, retrasos, costes impredecibles.
Tecnología del Innovación de la Con respecto a los últimos avances tecnológicos. baja mediana alta
proyecto tecnología del êBaja calidad, retrasos, costes impredecibles.
proyecto
Disponibilidad de la Subfactores: entrega, apoyo y accesibilidad. alta mediana baja
tecnología del êBaja calidad, retrasos, costes impredecibles.
proyecto apropiada
Figura 4.6: Factores de complejidad e incertidumbre relativos al dominio del

proyecto.

Nombre del factor situacional
• Explicación: breve descripción del factor y definiciones de

conceptos para explicarlo.
• Valores a utilizar en la valoración del factor.
• Subfactores, si el factor se compone de varios subfactores.
• Orientación adicional, si Eurométodo contiene más
orientaciones sobre la valoración operativa.
• Riesgos de consecuencias adversas en relación a ciertos
valores del factor. Estos riesgos son inherentes a la situación
del problema que describe el factor situacional que posee ese
valor. Por consiguiente, cada riesgo se describe en términos de
los eventos inciertos que pueden ocurrir en la situación del
problema:
– Para los factores de complejidad, los riesgos afectan a la
gestión (pérdida de control del proyecto) y al diseño (el
sistema de información no funciona o es incapaz de
gestionar la complejidad).
– Para los factores de incertidumbre se mencionan los
riesgos de cada uno de ellos.
• Acciones de inhibición, cuando existen medidas concretas que
posiblemente inhiben los riesgos al cambiar el valor individual
del factor situacional. El valor del factor situacional se cambia
al abordar el problema subyacente. Las acciones de inhibición
propuestas son ejemplos, y no son posibles para todos los
factores situacionales, por ejemplo, la complejidad y
formalidad de la información y los procesos del negocio.
• Observaciones que permiten a usuarios específicos registrar
información adicional.
Figura 4.7: Estructura de las descripciones de factores situacionales del anexo B.

Los elementos se incluyen sólo si son de interés, es decir, en algunas descripciones
de factores situacionales pueden faltar algunos elementos.

Capítulo 4
4.2.3 Evaluar la incertidumbre y complejidad generales

Una vez se han determinado los valores de los factores de situación, deberá
prestarse especial atención a los factores que contribuyen a la complejidad general
o a la incertidumbre general de la adaptación del SI. Normalmente estos factores
ejercerán una gran influencia en la definición de la estrategia de adaptación
apropiada, tal y como se explica en el apartado 4.3.
Ejemplo La adaptación del SI es incierta, en especial debido a los siguientes

factores asociados al dominio objetivo:
• Escasa estabilidad del entorno: por ejemplo, los requisitos legales
cambian a menudo.
• Alta especificidad del sistema de información: no existen paquetes
que se puedan entregar sin modificaciones.
• Elevada importancia estratégica de los cambios tecnológicos.
• La descripción de los requisitos del nuevo sistema de información es
insuficiente para estimar con exactitud el volumen de trabajo y los
siguientes factores relativos al dominio del proyecto:
• El calendario y el presupuesto son ajustados.
Los siguientes factores disminuirán la incertidumbre de la adaptación
del SI y deberán tenerse en cuenta al planificar la adaptación:
• La actitud de los agentes del sistema de información es positiva.
• La formalidad de la información es alta.
• Existe un adecuado nivel de conocimiento y comprensión del
sistema actual.
• Los cambios organizativos no son importantes.
• La calidad de las especificaciones del sistema informático actual es
alta.
• Se espera que la capacidad del equipo de proyecto sea alta.
Puede utilizarse el siguiente procedimiento:

Procedimiento
1.Elaborar una lista con todos los factores que posean los
valores ‘complejo’ e ‘incierto’, a ser posible en orden
decreciente de influencia en la complejidad e incertidumbre generales.
2. Evaluar todos los factores que tengan un valor moderado y describir toda
influencia en la complejidad e incertidumbre generales.
3. Elaborar una lista con todos los factores que posean los valores ‘simple’ y
‘cierto’. Evaluar en qué medida estos factores contrarrestan la complejidad e
incertidumbre generales. Esta lista también puede utilizarse para valorar si una
estrategia de adaptación es viable y apropiada.

La lista de factores situacionales no es definitiva ni exhaustiva.

Contiene ejemplos que pueden utilizarse y mejorarse en base a la experiencia
personal y organizativa.
4. Utilizar la pericia existente en el seno de la organización para complementar la
lista de factores situacionales y evaluar su influencia en la complejidad y la
incertidumbre.
5. Utilizando los resultados de los cuatro pasos anteriores, determinar la
complejidad e incertidumbre generales de la adaptación del SI.
La complejidad de una adaptación del SI se denomina ‘complejidad general’ y la
escala de factores de complejidad, dividida en los tres niveles simple, moderado y
complejo, se utiliza para indicar los valores. Análogamente, los valores de la
‘incertidumbre general’ pueden ser: cierto, moderado o incierto.
La influencia de un factor en la complejidad o incertidumbre generales puede
analizarse valorando los riesgos que puede causar este factor; véanse los siguientes
apartados. Las heurísticas acerca de la valoración de riesgos se basan en ocasiones
en la complejidad e incertidumbre generales, es decir, existen interdependencias
entre las distintas técnicas de análisis de riesgos, que deberían utilizarse en paralelo
y/o de forma iterativa.
4.2.4 Analizar la probabilidad de riesgos

adversas de eventos futuros [EM-DC].
Eurométodo proporciona una lista de riesgos que se describen a modo de

Listas de riesgos consecuencias adversas que pueden producirse. Los riesgos se refieren a las
de prestación y prestaciones del proyecto, y pueden deberse a la complejidad y la incertidumbre de
sus orígenes la situación. Eurométodo indica los orígenes de estos riesgos en forma de valores
de factores situacionales. Los riesgos y los ejemplos de relaciones entre riesgos y
factores situacionales están representados en las figuras 4.8 y 4.9. Los riesgos
aparecen en el orden en el que tendrán lugar en una adaptación del SI. Asimismo,
se utilizan dos riesgos generales en las técnicas:
• Un riesgo general del dominio del proyecto: pérdida del control del proyecto.
• Un riesgo general del dominio objetivo: el sistema de información no
funciona.
Gravedad de los La gravedad de los riesgos viene determinada por:
riesgos
• la probabilidad de que tengan lugar eventos con consecuencias adversas.
• las repercusiones de esas consecuencias, por ejemplo, repercusiones en los
costes, el calendario y la calidad de los entregables.
En este apartado describe una técnica para analizar la probabilidad del riesgo. En el
siguiente apartado se comentan las técnicas para valorar las repercusiones de los
riesgos. En la práctica, la probabilidad y las repercusiones se analizan en paralelo.
Esta separación hace hincapié en los dos aspectos del análisis de riesgos.

Capítulo 4
El análisis de las probabilidades de riesgo deberá documentarse utilizando la

Una técnica para
plantilla del anexo D.19. La figura 4.10 ofrece un ejemplo de probabilidades de analizar las
riesgo. Puede utilizarse el siguiente procedimiento: probabilidades
1. Elaborar una lista de los factores situacionales que implican incertidumbre de de riesgo
la situación. Esta lista puede proceder del apartado 4.2.3, paso 1.
2. Marcar con una X los riesgos asociados, de acuerdo con las relaciones que
muestran las figuras 4.8 y 4.9, y marcar también con una X los riesgos
generales, si son relevantes.
3. Sumar la complejidad global si ésta aumentará la probabilidad de algún riesgo,
y marcar los riesgos asociados.
De este modo se obtiene una primera indicación de la probabilidad de riesgos, en
base a un análisis de los factores situacionales, como se ha explicado en los
apartados 4.2.2 y 4.2.3. Si no se ha realizado este análisis, el procedimiento puede
comenzar en el punto 4.
4. Repasar la lista de riesgos y analizarlos uno por uno a la luz de la información
adicional acerca de la situación, procedente de documentos o entrevistas:
− Si el riesgo ya ha tenido lugar, marcar con el signo !
− Si se precisa alguna acción para prevenir el riesgo, marcar con el signo -
− Si es preciso valorar las repercusiones, marcar con el signo ? en la
columna de repercusiones.
La lista de riesgos no es definitiva ni exhaustiva. Contiene ejemplos que pueden
utilizarse y mejorarse en base a la experiencia personal y organizativa.
5. Utilizar la pericia existente en el seno de la organización para complementar Complementar
las listas de riesgos y factores de situación, y repetir los puntos 1-4. con la propia
experiencia

Factores del dominio objetivo La actitud de los agentes del SI es negativa

que implican incertidumbre La capacidad de los agentes del SI es baja
La estabilidad del entorno es baja
La formalidad de la información es baja
La formalidad de los procesos de negocio es baja
Baja estabilidad de la información/procesos de negocio
La especificidad del SI es alta
La comprensión del SI es baja
La importancia estratégica es alta

Los cambios organizativos son
importantes
Requisitos inciertos
Baja calidad de las especificaciones

Cambios tecnológicos
Riesgo importantes
Tecnología objetiva
(consecuencias adversas) novedosa
Requisitos inciertos o inviables X X X X X
Incertidumbre en las interfaces con otros
X
sistemas
Requisitos variables X X X
Costes impredecibles para la organización X X X X
Costes impredecibles para el proyecto X X X

Falta de participación de los agentes del
X
dominio objetivo
Deficiencias en las tareas realizadas
externamente
Retrasos en la entrega
Baja calidad de los entregables
Incremento de los costes del proyecto
Problemas de integración
Deficiencias de calidad X X
Necesidad de profundos conocimientos de
informática
Sistema de información incorrecto o
X X X X X X X X X X
inviable
Adaptación del sistema de información no
X X X
aceptada por los agentes
Repercusiones en el negocio del fallo del
X X
proyecto
Figura 4.8: Riesgos causados por la incertidumbre del dominio objetivo.

Capítulo 4
Factores del dominio del La novedad de la adaptación del SI es alta

proyecto que implican La idoneidad del calendario es ajustada
incertidumbre
La idoneidad del presupuesto es ajustada
La dependencia de los subcontratistas es alta

La dependencia de otras adaptaciones del SI es alta
La formalidad del contexto cliente-proveedor es baja
La capacidad del equipo del proyecto es baja
La novedad de la tecnología del proyecto es alta

La disponibilidad de tecnología apropiada es
baja
Riesgo
(consecuencias adversas)
Requisitos inciertos o inviables
sistemas
Requisitos variables X X
Costes impredecibles para la

organización
Costes impredecibles para el proyecto X X X X
dominio objetivo
X
externamente
Retrasos en la entrega X X X X
Baja calidad de los entregables X X X X X
Incremento de los costes del proyecto X
Problemas de integración X
Deficiencias de calidad
Necesidad de profundos conocimientos
X
de informática
X X
inviable
Adaptación del sistema de información
X X
no aceptada por los agentes
proyecto
Figura 4.9: Riesgos asociados a la incertidumbre del dominio del proyecto.

Factor Baja estabilidad del entorno

que implica riesgo Alta especificidad del SI
Elevada importancia estratégica
Incertidumbre en relación con la descripción de los requisitos
Alta importancia de los cambios tecnológicos
Alta novedad de la tecnología objetivo
Calendario ajustado
Presupuesto ajustado
Complejidad global
Riesgo
(consecuencias adversas) Probabilidad Repercusiones
Requisitos inciertos o inviables X X !+ ?
X + ?
sistemas
Requisitos variables X X -
Costes impredecibles para la organización X X + ?
Costes impredecibles para el proyecto X -

-
dominio objetivo
-
externamente
Retrasos en la entrega X + ?
Baja calidad de los entregables X X -
Incremento de los costes del proyecto X -
Problemas de integración X + ?
Deficiencias de calidad X + ?
Necesidad de profundos conocimientos de
X -
informática
X X X + ?
inviable
Adaptación del sistema de información no
X -
X + ?
proyecto
Riesgos generales:
Pérdida de control del proyecto X X X X X -
El sistema de información no funciona X X X X X X X -
Figura 4.10: Probabilidades de riesgo: ejemplo de un análisis según Eurométodo.

(X: factor que aumenta la probabilidad; !: el evento ha ocurrido; +: se precisa una
acción; -: se ha emprendido una acción; ?: valorar las repercusiones).

Capítulo 4
4.2.5 Identificar los riesgos críticos

Deberá prestarse especial atención a los riesgos con muchas probabilidades de Riesgos con alta
ocurrir y graves repercusiones en la adaptación del SI. Estos riesgos se denominan probabilidad y
riesgos críticos. Los riesgos críticos deberían influir en la definición de la estrategia graves
de adaptación y de los puntos de decisión, y conviene que estén documentados en repercusiones
el plan de adaptación.
Las repercusiones de los riesgos dependen en gran medida del contexto de la
adaptación del SI, y son específicas de ese contexto. Los riesgos incluidos en la
lista de comprobación de Eurométodo se describen por los tipos de repercusiones;
por ejemplo, incremento de los costes, retrasos de la entrega y baja calidad de los
entregables. Esta técnica describe un procedimiento general para la identificación
de los riesgos críticos en base a una valoración de las repercusiones y
probabilidades.
Los riesgos críticos deberán identificarse por: Descripción de
los riesgos
• El principal tipo de repercusión críticos
Por ejemplo, el nombre en la lista de riesgos de Eurométodo.
• Descripción de la repercusión.
La repercusión deberá expresarse mediante ejemplos. Si es posible, deberá
incluirse algún tipo de medida de las consecuencias. Estas medidas se
denominan indicadores de riesgo.
• Indicación del nivel de aceptación: el nivel de repercusiones tolerable.
El nivel de aceptación representa un insumo para el seguimiento de la
adaptación del SI. El nivel de aceptación puede expresarse, por ejemplo,
mediante un requisito mínimo relativo al riesgo, o mediante cifras relativas a
una medida que constituyan un límite superior; por ejemplo, costes.
El siguiente procedimiento puede utilizarse para cualquier riesgo cuya valoración Procedimiento
se considere importante de acuerdo con la técnica descrita en el apartado 4.2.4:
1. Describir ejemplos de las consecuencias adversas y, si es posible, algún tipo de
medida de estas consecuencias, es decir, indicadores de riesgo.
2. Valorar la gravedad:
− Grado de repercusión potencial: puede utilizarse una escala de tres
grados: repercusión alta, mediana o baja.
− Probabilidad: puede utilizarse una escala de tres grados: probabilidad alta,
mediana o baja.
3. Identificar los riesgos críticos, es decir, los riesgos que poseen una alta
repercusión y una alta probabilidad.
4. Definir el nivel de aceptación de los riesgos críticos.
5. Documentar los riesgos críticos en la forma antes descrita.

Ejemplo • Requisitos inciertos o inviables.

Ejemplo de repercusión:
Puede resultar difícil completar la adaptación del sistema de
información. La aceptación de los entregables puede ser causa de
conflictos.
Nivel de aceptación:
Un requisito mínimo es que el nuevo sistema informático pueda
sustituir completamente al sistema actual y que los procedimientos
del dominio objetivo puedan realizarse de forma eficiente.
• Retrasos de la entrega.
Ejemplos de repercusión:
La motivación de los agentes del sistema de información. Su número
puede disminuir y su actitud tornarse negativa. Algunas
organizaciones del dominio objetivo pueden iniciar sus propias
adaptaciones del sistema de información y los problemas de
integración aumentarán.
Se puede aceptar cierto retraso respecto a los plazos actuales, pero
la sustitución del sistema informático actual deberá haber finalizado
a más tardar un año después de la fecha prevista.
• Repercusiones en el negocio del fallo del proyecto.
Ejemplos de repercusión:
El cliente puede ser criticado con motivo de una auditoría publica.
Estas críticas públicas pueden aparecer en los medios de
comunicación, y el futuro profesional de las personas que ocupan
cargos de responsabilidad puede verse seriamente afectado.
No se puede aceptar ningún tipo de crítica adversa procedente de
una auditoría oficial.

Capítulo 4
4.3 Diseño de una estrategia de adaptación

Una vez se han definido los factores situacionales relevantes y los riesgos críticos,
tal y como se explica en el apartado precedente, es posible analizarlos y definir una
estrategia de adaptación adecuada. Este apartado ofrece técnicas útiles en este
proceso20.
Definición Una estrategia de adaptación es el enfoque encaminado a conseguir

los objetivos de una adquisición o de una adaptación del SI, al
tiempo que gestiona de manera eficaz los riesgos inherentes a cierta
situación del problema [EM-DC].
Las siguientes técnicas permiten la selección de una estrategia de adaptación

adecuada que consistirá en:
• determinación de contramedidas apropiadas Contenido de
una estrategia de
• un enfoque del desarrollo para la descripción, construcción e instalación adaptación
• un enfoque de control del proyecto.
Definición Una estrategia para un proceso es el enfoque encaminado a alcanzar

los objetivos del proceso, es decir, un enfoque apropiado para
gestionar de manera eficaz la complejidad e incertidumbre inherentes
al proceso [EM-DC].
El siguiente procedimiento puede utilizarse para seleccionar una estrategia de

adaptación apropiada en base a un análisis de riesgos:
1. Seleccionar countramedidas para la complejidad y la incertidumbre utilizando: Heurísticas para
− las heurísticas que proporciona Eurométodo. contramedidas
− la experiencia personal y organizativa.
• Véase apartado 4.3.1: Selección de contramedidas.
2. Valorar los efectos de las contramedidas sobre los factores situacionales y los
riesgos críticos, y documentar la valoración de la situación que deberá
constituir la base para la selección de las opciones de estrategia en los
próximos pasos.
• Véase apartado 4.2: Análisis de riesgos.
3. Analizar las opciones estratégicas que proporciona Eurométodo. Opciones y
heurísticas para
Véase apartado 4.3.2: Opciones estratégicas. la estrategia
4. Seleccionar las opciones estratégicas utilizando las heurísticas de Eurométodo
y la experiencia personal y organizativa.
20 Las técnicas se basan en los conceptos definidos en Eurométodo, los cuales sustentan las
cuestiones de tipo técnico relativas a la planificación de la adaptación. Las demás
cuestiones, por ejemplo de tipo financiero y legal, que pueden ser vistas de distinta manera
por el cliente y el proveedor, no se contemplan.

• Véase apartado 4.3.3: Selección de las opciones estratégicas.

Las opciones 5. Analizar las repercusiones de las opciones estratégicas elegidas.
estratégicas
pueden crear
Véase apartado 4.3.4: Análisis de las repercusiones de las contramedidas.
riesgos La valoración de la situación que supone la base para la selección de las
contramedidas y las opciones estratégicas puede haber cambiado. Por
consiguiente, quizá sea preciso repetir los pasos 1-5 hasta que la estrategia de
adaptación resultante sea adecuada para su finalidad.
La estrategia de adaptación seleccionada será la base para la posterior planificación
de los puntos de decisión, véase apartado 4.4. La estrategia comporta la
justificación de la secuencia y contenido de los puntos de decisión. Así pues, la
estrategia deberá documentarse como parte del plan de adaptación. Las
heurísticas de las técnicas no son definitivas ni exhaustivas. Se trata de
ejemplos que pueden utilizarse y mejorarse a la luz de la experiencia personal y
organizativa. Las heurísticas no contienen relaciones complejas, como por
ejemplo dependencias, entre los factores situacionales.
4.3.1 Selección de contramedidas

Esta técnica proporciona heurísticas para gestionar los riesgos motivados por la
complejidad y la incertidumbre de una situación. Las heurísticas elaboran
propuestas de requisitos de los puntos de decisión y los recursos. Estos requisitos
deberán tenerse en cuenta al planificar de los puntos de decisión.
Las heurísticas pueden hallarse en tres tablas:
• contramedidas para reducir riesgos: Figura 4.11
• contramedidas para cambiar los factores de incertidumbre individuales:
Figura 4.12
• contramedidas para gestionar la complejidad: Figura 4.13.
En una situación típica, la resolución de los riesgos causados por la complejidad
tiene que ver con un único factor situacional, mientras que la resolución de los
riesgos causados por la incertidumbre tiene en cuenta una combinación de factores
situacionales. Por lo tanto, las heurísticas para gestionar la complejidad están
relacionadas con factores de situación individuales, mientras que las heurísticas
para gestionar la incertidumbre están relacionadas con los riesgos causados por la
incertidumbre.

Capítulo 4
Riesgo Contramedidas para minimizar el riesgo
Requisitos inciertos o ê Crear o utilizar un buen nivel de comprensión del sistema de

inviables información existente.
ê Adoptar decisiones iniciales acerca de las descripciones del
futuro sistema de información; por ejemplo, realizar un
análisis de requisitos riguroso y añadir al plan de adaptación
puntos de decisión acerca de los requisitos del futuro sistema
de información, e implementar un sistema de control de los
requisitos.
ê Llevar a cabo un programa de formación para las personas
que son agentes en la adaptación del sistema de información.
ê Utilizar métodos formales para el análisis de requisitos.
Incertidumbre de las ê Utilizar normas publicadas.
interfaces con otros
sistemas ê Crear normas propias y utilizarlas.
ê Involucrar en el control del proyecto a la gerencia de un SI
asociado.
Requisitos variables ê Prestar mucha atención al diseño y construcción de un
sistema de información adaptable, es decir, el plan de calidad
deberá contener criterios de calidad acerca de la
adaptabilidad.
ê Implementar, junto con el cliente, un sistema riguroso de
control de cambios
ê Planificar los puntos de decisión de inversión, revisando los
requisitos.
Costes impredecibles ê Disminuir la incertidumbre relativa a los costes incluyendo en
para la organización el plan de adaptación puntos de decisión acerca de estos
costes, y ello en una fase inicial de la adaptación del sistema
de información.
ê Utilizar asesoramiento profesional.
Costes impredecibles ê Rehacer las especificaciones, es decir, añadir al plan de
para el proyecto adaptación puntos de decisión relativos a la aprobación de las
especificaciones del futuro sistema de información.
ê Revisar las especificaciones actuales con los agentes del
ê Planificar los puntos de decisión de inversión, clarificando los
requisitos y los costes.
Falta de participación ê Obtener el apoyo y la responsabilidad de participación de la.
de los agentes del alta dirección
dominio objetivo
ê Investigar y analizar la motivación de los agentes del
dominio.
ê Motivar a los agentes, por ejemplo, haciendo que los
beneficios sean comprensibles y visibles.
ê Involucrar a los agentes, por ejemplo, aumentando su
información.

Riesgo Contramedidas para minimizar el riesgo
Deficiencias técnicas ê Incluir al proveedor externo en la fase de diseño y no sólo

de las tareas describir los entregables, sino también para qué se utilizan.
realizadas
externamente ê Controlar la producción externa.
Retrasos de la ê Planificar opciones alternativas.

entrega ê Planificar puntos de decisión de inversión que permitan una
revisión de las expectativas.
ð Asignar más personal al equipo del proyecto.
ð Asignar personal más capacitado al equipo del proyecto.
Baja calidad de los ê Utilizar una definición clara y mensurable de la calidad que
entregables se precisa.
ê Formar el equipo del proyecto; por ejemplo, formar a los
agentes del sistema de información que participen en la
adaptación del SI.
ê Prolongar los plazos.
Incremento de los ê Controlar frecuentemente el presupuesto.
costes del proyecto ê Planificar puntos de decisión de inversión que permitan una
revisión de las expectativas.
Problemas de ê Utilizar métodos formales para especificar las partes del SI.
integración ê Involucrar al cliente en la coordinación de las distintas
adaptaciones del SI.
Deficiencias de ê Controlar los requisitos de las propiedades de calidad.
calidad ê Utilizar un experto en el sistema de información que posea
conocimientos técnicos de alto nivel.
ê Elaborar prototipos para la simulación de las propiedades de
calidad.
Necesidad de ê Estudiar una posible división de la adaptación del SI,
profundos aplazando los elementos punteros.
conocimientos de ê Estudiar el uso de soluciones normalizadas.
informática
Desarrollo de un ê Verificar lo antes posible que la funcionalidad del futuro SI
sistema incorrecto será igual de buena que la funcionalidad del SI actual, es
decir, los requisitos de la secuencia, finalidades y entregables
de puntos de decisión.
ê Elaborar declaraciones de requisitos, prototipos y
especificaciones del futuro SI.
ê Recopilar experiencias procedentes de SI similares.
ê Elaborar prototipos para la simulación de las propiedades del
SI.
ê Utilizar la ingeniería inversa, es decir, añadir al plan de
adaptación puntos de decisión asociados al aumento del grado
de comprensión del SI actual, mediante descripciones del
mismo.
Adaptación del SI no ê Crear o mantener una actitud positiva de los agentes.
aceptada por los
agentes ê Elaborar prototipos para la simulación de las propiedades de
las prácticas de trabajo.
Repercusiones en el ê Conceder prioridad a los riesgos críticos y atender por
negocio del fallo del separado los riesgos más urgentes.
proyecto ê Dividir el sistema en partes más pequeñas.

Capítulo 4
Figura 4.11: Contramedidas para reducir riesgos
Factor de Contramedidas para cambiar los factores individuales

incertidumbre
La actitud de los ê Involucrar a los agentes, por ejemplo, aumentando su
agentes del SI es información, participación e influencia en la adaptación del SI.
negativa
ê Motivar a los agentes, por ejemplo, haciendo que los beneficios
sean comprensibles y visibles.
La habilidad de los ê Formar a los agentes, es decir, llevar a cabo un programa de
agentes del SI es formación de las personas que son agentes en la adaptación del
baja SI.
La comprensión del ê Utilizar la ingeniería inversa, es decir, añadir al plan de
SI actual es baja adaptación puntos de decisión asociados al aumento del nivel
de comprensión del sistema de información actual, mediante
descripciones del mismo.
La disponibilidad o ê Realizar un análisis de requisitos riguroso, es decir, añadir al
claridad de los plan de adaptación puntos de decisión acerca de declaraciones
requisitos de la de requisitos del futuro SI, e implementar un sistema de control
adaptación del SI es de requisitos.
baja
La calidad de las ê Rehacer las especificaciones, es decir, añadir al plan de
especificaciones adaptación puntos de decisión acerca de la aprobación de las
actuales es baja especificaciones del futuro SI.
ê Revisar las especificaciones actuales con los agentes del SI.
La capacidad del ê Formar al equipo del proyecto, por ejemplo, llevar a cabo un
equipo del proyecto programa de formación para las personas que son agentes en la
es baja adaptación del SI.
ê Asignar personas más capacitadas al equipo del proyecto.
Figura 4.12: Contramedidas para cambiar factores situacionales individuales.

Factor de Contramedidas para gestionar la complejidad

complejidad
El tamaño del ê Dividir la adaptación del SI en varias adaptaciones con
dominio objetivo es dominios objetivos más pequeños.
grande
La complejidad de ê Utilizar la visión de la información del negocio en las
la información del descripciones del SI a fin de sustentar decisiones iniciales
SI es alta acerca de la información del negocio.
ê Utilizar expertos en el SI que posean una elevada cualificación
en este dominio de aplicación.
La complejidad de ê Utilizar la visión de los procesos del negocio en las
los procesos de descripciones del SI a fin de sustentar decisiones iniciales
negocio del SI es acerca de los procesos de negocio.
alta ê Utilizar expertos en el SI que posean una elevada cualificación
en este dominio de aplicación.
Complejidad de los ê Clarificar las interfaces al principio del proceso de descripción
procesos de y describirlas en las descripciones del SI.
negocios debido a ê Comprobar a fondo las interfaces externas.
que existen
demasiadas ê Planificar los cambios necesarios en cada SI externo que
interfaces externas interviene en la adaptación del SI.
con otros SI ê Planificar la construcción, ensayo e instalación de las interfaces
en coordinación con los responsables de los SI externos que
intervienen en la adaptación del SI.
La complejidad de ê Aprobar descripciones de propiedades de calidad mediante los
las propiedades de puntos de decisión iniciales de la adaptación del SI.
calidad es alta ê Adoptar decisiones iniciales acerca del intercambio entre las
propiedades funcionales y las propiedades de calidad.
ê Producir prototipos como parte de las descripciones.
El tamaño del Es decir, el esfuerzo de desarrollo que se precisa es considerable para
proyecto es grande las organizaciones que intervienen.
ê Dividir la adaptación del SI en varias adaptaciones cubiertas
mediante subcontratos.
La complejidad de Es decir, el esfuerzo y complejidad de la migración del SI en su
la migración es alta estado inicial al SI en su estado final es grande.
ê Gestionar la migración por pasos, utilizando interfaces
intermedias definidas que enlacen con el SI operativo existente.
Dependencia de un ê Planificar la adaptación del SI en coordinación con los
gran número de responsables de las demás adaptaciones del SI.
interfaces con otras ê Clarificar las interfaces (interfaces de sistema externo,
adaptaciones del SI interfaces de migración, etc.) al inicio del proceso de
adaptación del SI y describirlas en los planes y descripciones
del SI.
ê Informar de estas interfaces al aprobarse las transacciones de la
situación y del plan.
La complejidad de ê Utilizar una tecnología segura, bien conocida y madura.
la tecnología es alta ê Utilizar expertos en el SI que posean un alto nivel de
cualificación técnica.
Figura 4.13: Contramedidas para gestionar la complejidad.

Capítulo 4
4.3.2 Análisis de las opciones estratégicas

Eurométodo proporciona un conjunto de opciones para los enfoques del desarrollo Definir opciones
y de control del proyecto. Estas opciones pueden adaptarse al contexto de la estratégicas
organización y mejorarse en base a la experiencia, para obtener opciones específicas para
estratégicas específicas para la organización. De momento, Eurométodo no la organización
proporciona orientación para realizar estas mejoras. En este apartado se explican
las opciones de Eurométodo.
4.3.2.1 Enfoque del desarrollo
En Eurométodo, un enfoque del desarrollo es la combinación de un enfoque de la

descripción, un enfoque de la construcción y un enfoque de la instalación. La figura
4.11 proporciona una visión general de las opciones de un enfoque del desarrollo.
Enfoque de la descripción
Definición La descripción de un sistema de información es un proceso o el

resultado de ese proceso: el proceso de análisis y diseño del sistema
de información. La descripción incluye la determinación de los
requisitos. El resultado de un proceso de descripción es una
descripción que puede definir la organización, las características
esenciales y las necesidades de soporte físico y de soporte lógico
[EM-DC].
Una modalidad de la descripción proporciona el enfoque cognitivo a seguir al

producir uno o más elementos descriptivos, y el enfoque social que se precisa entre
los agentes del proyecto y los agentes del SI.
El enfoque cognitivo que se utiliza para elaborar las descripciones del sistema es Opciones del
la manera en que se procesa la información para tomar las decisiones de diseño del enfoque
proyecto. Existen dos opciones: cognitivo
• Enfoque analítico.
Cuando la información se procesa de forma analítica, la información
disponible se simplifica mediante la abstracción, al objeto de alcanzar una
comprensión más profunda e invariable. Se utiliza el enfoque analítico para
gestionar la complejidad de la información. En el enfoque analítico, el
sistema de información se describe principalmente utilizando cierto grado de
formalismo.
• Enfoque experimental.
Cuando se utiliza el enfoque experimental, los agentes del proyecto aprenden
de experimentos que generan nuevos conocimientos. La finalidad es reducir
la incertidumbre generando más información. Los experimentos pueden estar
basados, por ejemplo, en prototipos, maquetas, pruebas de referencia de los
servicios u otro tipo de técnicas de visualización de escenarios.
Puede que sea preciso combinar ambos tipos de enfoque cognitivo. Un enfoque
analítico para reducir la complejidad puede introducir nuevas fuentes de

incertidumbre que requieran contramedidas experimentales, y a la inversa, un

enfoque experimental para reducir la incertidumbre puede introducir nuevas
fuentes de complejidad que requieran contramedidas analíticas. Por tanto, sólo el
enfoque cognitivo primario formará parte de la estrategia del proyecto.
Opciones del El enfoque social es la manera en que los agentes del proyecto colaboran con los
enfoque social agentes del sistema de información en la tarea de descripción. Existen dos
opciones:
• Conducido por experto.
En una cooperación conducida por expertos, los agentes del proyecto (los
expertos) producen descripciones a la luz de su propia pericia, entrevistas y
observaciones de los agentes del sistema de información. Las descripciones
pueden facilitarse seguidamente a los agentes del SI para que las comenten o
aprueben.
• Participativo.
En un enfoque participativo, los agentes del proyecto elaboran las
descripciones en estrecha colaboración con algunos o con todos los agentes
del SI, por ejemplo en seminarios con presentaciones, discusiones y
decisiones de diseño. El Diseño de Aplicación Conjunto (DAC) es un
ejemplo de una técnica que puede utilizarse en un enfoque participativo. Este
tipo de enfoque permite la adquisición de conocimientos, el refinamiento de
los requisitos y la simplificación de los cambios organizativos.
Opciones del La opción por un enfoque de la descripción fijará requisitos de los entregables que
enfoque de intercambian el cliente y el proveedor, y de los métodos y técnicas utilizados en la
descripción adaptación del sistema de información. El cliente y el proveedor deberán
seleccionar una de las cuatro posibles combinaciones de opciones de enfoque
cognitivo y opciones de enfoque social:
1. Enfoque analítico y cooperación conducida por expertos.
2. Enfoque analítico y enfoque participativo.
3. Enfoque experimental y cooperación conducida por expertos.
4. Enfoque experimental y enfoque participativo.

Capítulo 4
Modalidad de desarrollo Opciones estratégicas
Enfoque de la descripción 1. Analítico:

– enfoque cognitivo • uso de abstracciones y especificaciones
2. Experimental:
• uso de experimentos y prototipos.
Enfoque de la descripción 1. Conducido por expertos:
– enfoque social • separación entre producción y valoración
2. Participativo:
• colaboración para la producción y valoración.
Enfoque de la construcción 1. Construcción de una vez:
• una única versión que se construye y se prueba
de una sola vez.
2. Construcción incremental:
• las partes se construyen y se prueban en varias
etapas sucesivas.
• no se producen cambios de las descripciones
después de la primera construcción.
3. Construcción evolutiva:
• las versiones se construyen y se prueban en varias
etapas sucesivas.
• es posible introducir cambios en las descripciones
en función de los resultados de las pruebas.
Enfoque de la instalación 1. Instalación de una vez:
– cobertura del sistema • una única versión que se instala de una vez.
2. Instalación incremental:
• las partes se instalan en varias etapas sucesivas.
• no se producen cambios de las descripciones
después de la primera instalación.
3. Instalación evolutiva:
• las versiones se instalan en varias etapas sucesivas.
• es posible introducir cambios de las descripciones
en función de la experiencia adquirida con el uso.
Enfoque de la instalación 1. Instalación global
– cobertura geográfica • instalación en todas las ubicaciones de una vez.
2. Instalación local
• paso a paso en un número creciente de ubicaciones.
Figura 4.14: Opciones estratégicas para un enfoque de desarrollo.

Enfoque de la construcción
Definición La construcción de un sistema de información (inclusive la

organización) es el proceso que consiste en traducir un elemento
descriptivo en elementos operativos. Incluye el ensayo de los
elementos operativos [EM-DC].
Un enfoque de la construcción define la manera en que se va a construir y probar el

sistema de información. La selección de un enfoque de la construcción consiste en
adoptar decisiones acerca de los pasos a partir de los cuales se construye y se
prueba el sistema de información, es decir, decisiones acerca de la secuencia y tipo
de las partes o versiones del sistema de información que el proyecto debe construir,
probar y entregar al cliente.
El cliente y el proveedor deberán seleccionar uno de los tres Opciones del
enfoques de la construcción siguientes: enfoque de la
construcción
1. Construcción de una vez:
La totalidad del SI se construye (y se prueba) en una sola versión –
normalmente al utilizar soluciones normalizadas que no precisan
modificaciones.
2. Construcción incremental:
El SI se construye (y se prueba) en partes sucesivas. Cada parte contiene un
subconjunto de funcionalidades del SI. Los requisitos del SI instalado se
definen completamente antes de la primera construcción y no pueden ser
modificados posteriormente.
3. Construcción evolutiva:
El SI se construye (y se prueba) en versiones sucesivas. Entre dos versiones,
las descripciones del SI pueden cambiar en función de los resultados de las
pruebas. Cada versión puede contener un subconjunto o la totalidad de las
funcionalidades.
Enfoque de la instalación
Definición La instalación de un sistema de información es el proceso que

consiste en hacer que el sistema de información sea operativo en el
dominio objetivo [EM-DC].
La determinación de un enfoque de la instalación consiste en tomar decisiones

acerca de las versiones del sistema de información que deberían instalarse en el
dominio objetivo, y la secuencia de estas instalaciones.
El cliente y el proveedor deberán seleccionar una de las siguientes Opciones del
tres opciones de cobertura del sistema: enfoque de la
instalación para
1. Instalación de una vez: la cobertura del
La totalidad del SI se instala (y se utiliza) en una sola versión. sistema

Capítulo 4
2. Instalación incremental:
El SI se instala (y se utiliza) en partes sucesivas. Cada parte contiene un
subconjunto de funcionalidades del SI. Los requisitos del SI instalado se
definen completamente antes de la primera instalación y no pueden ser
modificados posteriormente.
3. Instalación evolutiva:
El SI se instala (y se utiliza) en versiones sucesivas. Entre dos versiones, las
descripciones del SI pueden cambiar en función de la experiencia adquirida
con el uso del SI. Cada versión puede contener un subconjunto o la totalidad
de las funcionalidades.
Conviene señalar que normalmente los requisitos de una versión deben fijarse
durante un período de tiempo entre la construcción y la instalación, pero después
de la instalación pueden modificarse e influyen en la descripción de la siguiente
versión.
Paralelamente a estas tres modalidades de cobertura del sistema, existe la cobertura Opciones de
geográfica de cada tipo de instalación. El cliente y el proveedor deberán cobertura
seleccionar una de las siguientes dos opciones de cobertura geográfica: geográfica en la
modalidad de la
1. Instalación global. instalación
Una nueva versión del sistema de información se instala de una sola vez en
todas las ubicaciones del dominio objetivo.
2. Instalación local.
Una nueva versión del sistema de información se instala en varias etapas,
cubriendo cada vez más ubicaciones del dominio objetivo.
Así pues, el primer paso de la instalación de una versión poseerá una cobertura
geográfica limitada, por ejemplo, tan sólo una sección, un departamento o una
oficina. Este paso puede utilizarse como instalación piloto con la finalidad de
perfeccionar la versión del sistema de información y mejorar el proceso de
instalación antes de que los cambios influyan en la totalidad del dominio
objetivo. Así, los siguientes pasos pueden aumentar la cobertura geográfica,
representando el último paso la cobertura total del dominio objetivo.
Las dos opciones de cobertura geográfica pueden combinarse con cualquiera de los
tres enfoques de cobertura del sistema: de una vez, incremental o evolutivo.
4.3.2.2 Enfoque del control del proyecto
Definición El control del proyecto es el conjunto de procesos relativos al

seguimiento de la progresión del proyecto, es decir, su orientación,
calidad y utilización de recursos, en relación con los planes del
proyecto [EM-DC].
Aspectos del
Se tienen en cuenta tres aspectos del control del proyecto: frecuencia, formalidad y
control del
responsabilidad del cliente: proyecto
• Frecuencia.

La frecuencia de los puntos de decisión cliente-proveedor que tienen lugar en

el proceso de control.
• Formalidad.
El grado de formalidad de la organización, procedimientos y disciplinas que
utiliza el proceso de control.
Ejemplo Un alto grado de formalidad del control del proyecto puede

abarcar, por ejemplo:
• Aprobaciones periódicas de la situación y del plan.
• Requisitos formalmente definidos acerca del contenido de
los informes de gestión.
• Entregables del dominio objetivo formalmente definidos,
con plazos y procedimientos de aprobación definidos.
• Uso de una métrica definida para determinar la progresión
y la calidad del proyecto.
• Uso de una técnica de inspección definida para controlar la
calidad del código.
• Procedimientos de control de configuración formalmente
definidos.
• Responsabilidad del cliente .

La definición de la responsabilidad del cliente sobe los procesos relativos al
control del proyecto. Por regla general, se asume que el proveedor es
responsable de todos los procesos, a menos que la responsabilidad del cliente
se defina de forma explícita en el contrato.

Capítulo 4
Ejemplo La responsabilidad del cliente puede definirse, por

ejemplo, de las siguientes maneras:
• El cliente es responsable del control de la
configuración de los requisitos.
• El cliente es responsable del control de calidad de las
descripciones con respecto a los requisitos y
necesidades del negocio.
• El cliente es responsable de generar de casos
experimentales que contemplen situaciones críticas
desde la perspectiva de los procesos de negocio.
• El cliente es responsable de la preparación de la
organización para la instalación del nuevo sistema de
información operativo.
• El cliente es responsable de la obtención de cualquier
acuerdo que tenga lugar en la organización en
relación con los requisitos del sistema de
información.
En este contexto, la modalidad de control del proyecto es el enfoque utilizado para Modalidad de
el control de la frecuencia y formalidad de las medidas de control del proyecto, y la control del
responsabilidad de su realización. proyecto
El control del proyecto puede dividirse en tres procesos: desarrollo del sistema de
información, garantía de calidad y gestión de la configuración, todos ellos definidos
por Eurométodo. Por consiguiente, existen tres procesos distintos de control del
proyecto:
1. Control del desarrollo.
Proceso de gestión de proyectos necesario para controlar la realización de las
tareas del proyecto en el proceso de desarrollo del SI.
2. Control de calidad.
Técnicas y actividades utilizadas para satisfacer los requisitos de calidad. El
control de calidad incluye técnicas y actividades encaminadas a la supervisión
de un proceso y a la eliminación de las causas de un rendimiento insatisfactorio
en todas las etapas del ciclo de calidad, en aras de la eficacia económica.
3. Control de la configuración.
Se trata de un elemento de la gestión de la configuración, que consiste en la
evaluación y coordinación, aprobación o rechazo e implementación de
cambios en los elementos de configuración después del establecimiento formal
de su identificación.
Para cada uno de los procesos de control del proyecto arriba definidos, el cliente y Opciones del
el proveedor deberán seleccionar una de las opciones relativas a los tres aspectos enfoque del
que considera Eurométodo. La figura 4.12 ofrece una visión general al respecto. control del
proyecto

Procesos de control del proyecto Aspectos de control del Opciones estratégicas

proyecto
• Control del desarrollo Frecuencia Intervalos o fechas con los

• Control de la calidad extremos de frecuentemente y
raramente
• Control de la configuración
Formalidad Grados de formalidad con los
extremos de formal e informal
Responsabilidad del Responsabilidades del cliente

cliente sobre a los diferentes procesos.
Figura 4.15: Opciones estratégicas para un enfoque del control del proyecto.
4.3.3 Seleccionar las opciones estratégicas
La instalación es El principal objetivo de la mayoría de adaptaciones del SI consiste en introducir

‘el momento de cambios en el SI operativo, mediante la instalación de elementos operativos nuevos
la verdad’ o modificados que pueden incluir nuevo personal y nuevas estructuras
organizativas. La instalación de la nueva versión del sistema de información es lo
que permite a los agentes del SI utilizar los resultados de una adaptación del SI. La
instalación es ‘el momento de la verdad’ de la adaptación del SI. Por lo tanto, la
definición de un enfoque de la instalación adecuado tiene una importancia decisiva
para conseguir un resultado favorable.
Al definir el enfoque de la instalación es preciso proceder con sumo cuidado y
atención.
Interdepen- El enfoque de la instalación debe estar influido por los factores situacionales. No
dencias entre obstante, los conocimientos relativos a la situación pueden resultar insuficientes
enfoques del para seleccionar un enfoque de la instalación. En este caso, la adaptación del
desarrollo sistema de información deberá incluir actividades encaminadas a obtener los
conocimientos necesarios para adoptar decisiones acerca de un enfoque de la
instalación adecuado, es decir, los entregables de los puntos de decisión iniciales
relativos a la descripción del sistema de información deberán sustentar la definición
de un enfoque de la instalación adecuado, o lo que es lo mismo, la selección del
enfoque de la instalación puede establecer varios imperativos y requisitos sobre
otros enfoques. De forma similar, el enfoque de la construcción puede establecer
imperativos sobre el enfoque de la descripción. Así pues, se recomienda
seleccionar el enfoque del desarrollo en el orden siguiente: enfoque de la
instalación, enfoque de la construcción y, finalmente, enfoque de la descripción, y
comprobar que existe coherencia entre las opciones seleccionadas.
Procedimiento Puede utilizarse el siguiente procedimiento para seleccionar las opciones
estratégicas relativas al desarrollo y al control del proyecto:
1. Seleccionar un primer enfoque de desarrollo ‘en borrador’, basado en una
valoración general de los factores situacionales y los riesgos críticos, y en las
heurísticas que proporciona Eurométodo.

Capítulo 4
2. Revisar y justificar el enfoque de desarrollo utilizando las heurísticas detalladas

que proporciona Eurométodo y la experiencia en el seno de la organización.
3. Seleccionar un enfoque de control del proyecto utilizando las heurísticas
detalladas que proporciona Eurométodo y la experiencia en el seno de la
organización.
4. Comprobar que se mantiene la coherencia entre las opciones estratégicas
seleccionadas y corregir la selección efectuada.
4.3.3.1 Paso 1: Seleccionar un primer enfoque de desarrollo ‘en

borrador’
• Insumo:
Una valoración general de los factores situacionales y los riesgos críticos.
• Resultado:
Las opciones de estrategia de desarrollo que resultan más adecuadas de
acuerdo con las heurísticas generales que reflejan las figuras 4.16 y 4.17:
− heurísticas generales relativas a la idoneidad de los enfoques de la
instalación/construcción
− heurísticas generales relativas a la idoneidad de las modalidades de la
descripción.

Ejemplo El enfoque de la descripción en el análisis de requisitos es:

• Analítico, porque:
La situación es, sobre todo, compleja. Varios factores
situacionales contrarrestan las incertidumbres (es decir, el
enfoque experimental está menos justificado), y resultan útiles al
utilizar el enfoque analítico:
– La comprensión del sistema actual es alta.
– La calidad de las especificaciones actuales es alta.
– La capacidad del equipo de proyecto es alta.
• Participativo, porque:
– La complejidad de la información y de los datos es alta.
– La capacidad de los agentes que intervienen es alta.
– La especificidad del sistema de información es alta.
– La importancia de los cambios tecnológicos es alta.
Los enfoques de la construcción y de la instalación son:
• Evolutivos, porque:
– El calendario es ajustado y existe incertidumbre en relación
con:
− la alta especificidad del sistema de información
− la descripción del futuro sistema
− la baja estabilidad del entorno.
Factor situacional Enfoque de la instalación/construcción

Calendario Complejidad Incertidumbre De una vez Incremental Evolutivo
Normal Simple Cierto X
Incierto X
Complejo Cierto X
Incierto X
Ajustado Simple Cierto X X
Incierto X
Complejo Cierto X
Incierto X
Heurísticas generales:
• La construcción/instalación de una vez es adecuada cuando el calendario es
normal y la situación es simple y cierta.
• El enfoque evolutivo es adecuado cuando la situación es incierta.
• El enfoque incremental es adecuado cuando la situación es compleja y
cierta.
• El enfoque incremental o evolutivo es adecuado cuando el calendario es
ajustado, es decir, es preciso instalar algo lo más rápidamente posible.
Figura 4.16: Heurísticas generales acerca de la idoneidad de

los enfoques de la instalación y la construcción.

Capítulo 4
Enfoque social Conducido por expertos Participativo

Enfoque cognitivo
Analítico Cuando la situación es Cuando la complejidad de la
compleja, excepto cuando la información o de los procesos de
complejidad de la negocio es alta.
información o de los procesos
de negocio es alta.
Experimental Cuando la situación es Cuando la situación es incierta y

incierta y el enfoque la habilidad de los agentes del
participativo no es adecuado. sistema de información es
suficientemente alta y la idoneidad
del calendario es normal.
Figura 4.17: Heurísticas generales acerca de la idoneidad de los enfoques de la

descripción.
4.3.3.2 Paso 2: Revisar y justificar el enfoque del desarrollo
• Insumo:
Una propuesta preliminar de un enfoque del desarrollo, y una valoración de
la situación en forma de factores situacionales y la complejidad e
incertidumbre generales.
• Resultado:
Enfoques de la descripción, construcción e instalación apropiados para esta
adaptación del SI, y su justificación.
Estos enfoques deberán seleccionarse, revisarse y justificarse utilizando las
heurísticas detalladas que proporciona Eurométodo y la experiencia acumulada en
el seno de la organización.
Es posible que, para que sean realistas, las opciones estratégicas requieran la Para que una
existencia de ciertas condiciones en la situación. Por ejemplo, para obtener un opción
resultado favorable, el enfoque experimental y el enfoque evolutivo exigen estratégica sea
conocimientos de gestión de proyectos; y el enfoque participativo requiere que el realista, es
preciso que se
equipo de proyecto tenga capacidad de comunicación. Estas condiciones también pueda ejecutar
deberán analizarse y tenerse en cuenta al seleccionar las opciones estratégicas.
1. Seleccionar la opción estratégica para la cobertura del sistema por las
instalaciones.
El enfoque que se selecciona por defecto es el de una vez, con el cual la
gestión del proyecto es más sencilla, es decir, se reduce el riesgo general de
pérdida de control del proyecto. Los enfoques incremental o evolutivo deberán
seleccionarse en función de los factores situacionales particulares, véase las
heurísticas de la figura 4.18.
2. Seleccionar la opción estratégica para la cobertura geográfica de las
instalaciones.

El enfoque que se selecciona por defecto es la instalación global, es decir, se

instala una versión del sistema de información en todas las ubicaciones y de
una vez. Puede utilizarse el enfoque de la instalación local, es decir, la
instalación gradual cubriendo cada vez más ubicaciones, para gestionar una
situación del problema compleja; véase las heurísticas de la figura 4.18.
3. Seleccionar la opción estratégica para la construcción.
El enfoque que se selecciona por defecto es el de una vez, con el cual la
gestión del proyecto es más sencilla, es decir, se reduce el riesgo general de
pérdida de control del proyecto. Los enfoques incremental o evolutivo deberán
seleccionarse en función de los factores situacionales particulares; véase las
4. Seleccionar las opciones estratégicas para la descripción.
En la práctica, no suele darse el caso de que pueda aplicarse sólo una de las
opciones de enfoque de la descripción. Por regla general, existen casos en los
que el enfoque seleccionado se combina con alguno de los demás. Por
consiguiente, los enfoques primarios cognitivo y social deberán definirse como
parte de la estrategia de adaptación; véase las heurísticas de la figura 4.18.

Capítulo 4
Opciones de Descripción analítica

estrategia de desarrollo Descripción experimental
Descripción conducida por expertos
Descripción participativa
Construcción incremental
Construcción evolutiva
Instalación incremental
Instalación evolutiva
Factores situacionales Instalación local
Actitud negativa de los agentes del SI X Precisa cualificación adecuada
La habilidad de los agentes del SI es alta + Agentes del SI pueden utilizarse como
agentes del proyecto
La habilidad de los agentes del SI es baja X
Alta heterogeneidad de los agentes del SI X
Gran tamaño del dominio objetivo X
Gran tamaño de la distribución X
Baja formalidad de la inf./proc.de neg. X
Alta complejidad de la inf./proc.de neg. X
Baja estabilidad de la inf./proc.de neg. X
La especificidad del SI es alta X
Importantes cambios organizativos X X
Los requisitos son inciertos X
Los cambios tecnológicos son importantes X
Alta complejidad de la tecnología objetivo X
Alta novedad de la adaptación del SI X X
Calendario ajustado X X X X X Instalar algo lo más rápido posible
Calendario no ajustado +
Alta complejidad de las prop. de calidad X
Muchas replicaciones del sist. informático X
Baja capacidad del equipo de proyecto X
Alta novedad de la tecnol. del proyecto X
Alta complejidad de la migración X
Alta dependencia de otros proyectos X
Presupuesto ajustado X Requiere cualificación adecuada
Factores generales:
Adaptación del SI compleja X X X X X
Adaptación del SI incierta X X X
Figura 4.18: Heurísticas acerca de la idoneidad de los enfoques del desarrollo.

Los enfoques que se seleccionan por defecto son la construcción/instalación de una
vez y la instalación global.
(+: este factor es necesario; X: este factor se contempla)

4.3.3.3 Paso 3: Seleccionar y justificar un enfoque de control del

proyecto
• Insumo:
Una valoración de la situación en forma de factores situacionales y la
complejidad e incertidumbre generales
• Resultado:
Un enfoque de control del proyecto que sirve para esta adaptación del
sistema de información, y su justificación
• Orientación:
Confrontar los factores situacionales con las heurísticas de la figura 4.19 y
seleccionar el enfoque más apropiado.
Generalmente se prefiere siempre un alto grado de formalidad en el control de
calidad, aunque los procedimientos que se aplican pueden ser más o menos
complicados en función del tamaño del proyecto.

Capítulo 4
Opciones de Control frecuente del desarrollo

control del proyecto Control frecuente de la calidad
Control frecuente de la configuración
Control formal del desarrollo
Control formal de la calidad
Control formal de la configuración
Factores situacionales Responsabilidad del cliente
Actitud negativa de los agentes del SI X Involucrar a los agentes del SI apropiados
La habilidad de los agentes del SI es baja X
Alta heterogeneidad de agentes del SI Gestionar los conflictos y los cambios organizativos
Gran tamaño de la distribución del SI Controlar los cambios de los requisitos
La estabilidad del entorno es baja X X X Proporcionar conocimientos y adoptar decisiones
Baja formalidad de la inf./proc.de neg. X Proporcionar conocimientos y adoptar decisiones
Baja estabilidad de la inf./proc.de neg. X X X Controlar los cambios de los requisitos
Alta especificidad del SI X Proporcionar conocimientos y adoptar decisiones
Baja comprensión del SI actual X Proporcionar conocimientos y adoptar decisiones
La importancia estratégica es alta X X Proporcionar conocimientos y adoptar decisiones
Importantes cambios organizativos X X Gestionar los conflictos y los cambios organizativos
Requisitos inciertos X X X Describir los requisitos
Baja calidad de las especificaciones X X
Cambios tecnológicos importantes X X
Alta novedad de la tecnología objetivo X
Alta novedad de la adaptación del SI X X Proporcionar conocimientos y adoptar decisiones
Calendario ajustado X X
Presupuesto ajustado X X
Alta dependencia de subcontratistas X X X X
Alta dependencia de otros proyectos X X X Coordinar los proyectos
Bajo contexto formal cliente-proveedor X
Baja capacidad del equipo de proyecto X
Alta novedad de tecnología del proyecto X X
Baja disponibilidad de la tecnol.del proyecto X X
Muchas replicaciones del sistema X
Alta complejidad de la migración X X X
Muchos agentes del proyecto X X X X X X
Alta complej. de la tecnol. del proyecto X X
Factores generales:
Adaptación del SI compleja X X X
Adaptación del SI incierta X X
Figura 4.19: Heurísticas acerca de la idoneidad de las opciones de control del

proyecto.
(X: la opción aborda este factor)

4.3.3.4 Paso 4: Comprobar que se mantiene la coherencia entre las

opciones estratégicas elegidas y corregir la selección efectuada
1. Utilizando las heurísticas de la figura 4.20, comprobar que la combinación

seleccionada de opciones estratégicas es viable.
2. Utilizando las mismas heurísticas, corregir la selección efectuada y, utilizando
las heurísticas del paso 2, controlar los cambios.
Enfoque de la De una Incre- Evolutivo

construcción vez mental
Observaciones
Enfoque de la
instalación
De una vez X X X Tras la construcción puede realizarse una
prueba final de recepción de la totalidad del
sistema de información y posteriormente una
instalación de una vez
Incremental X Tras la construcción de una vez puede
realizarse una prueba final de recepción de la
totalidad del sistema de información y
posteriormente una instalación sucesiva de las
partes, o bien:
Tras la construcción de una vez de cada una
de las partes puede realizarse una prueba de
recepción y la instalación de esa parte
X Tras la construcción incremental de cada una
de las partes puede realizarse una prueba de
X Tras la construcción evolutiva de cada una de
las partes puede realizarse una prueba de
Evolutivo - - X Un enfoque de instalación evolutivo implica
un enfoque de construcción evolutivo, ya que
los requisitos de la construcción pueden
cambiar en función de la experiencia
adquirida con el uso del SI
• Una cooperación conducida por expertos puede ser más sencilla de planificar y controlar que
un enfoque participativo.
• Un enfoque participativo puede ser más sencillo de controlar cuando se utiliza un enfoque
de instalación evolutivo.
Figura 4.20: Dependencias entre las opciones estratégicas.

(X: la combinación es posible; -: la combinación no es posible)

Capítulo 4
4.3.4 Analizar las repercusiones de la estrategia

Tras seleccionar las contramedidas y las opciones estratégicas, conviene
comprobar si se han contemplado todos los riesgos críticos. Se recomienda crear
una matriz que relacione los riesgos críticos identificados y las opciones y
contramedidas seleccionadas – véase el boceto de la figura 4.21 y la plantilla del
anexo D.20. Las opciones estratégicas seleccionadas pueden incrementar algunos
riesgos, los cuales deberán ser analizados (probabilidad y repercusiones) e
incluidos en la matriz, si son críticos. La figura 4.22 contiene ejemplos de riesgos
que pueden verse incrementados según las opciones estratégicas seleccionadas.
Para analizar los riesgos pueden utilizarse las técnicas del apartado 4.2 Análisis de
riesgos.
Opciones estratégicas Enfoque cognitivo de la descripción: analítico o experimental

Enfoque social de la descripción: conducido por expertos o participativo
Enfoque de la construcción: de una vez, incremental o evolutivo
Enfoque de la instalación: de una vez, incremental o evolutivo
Enfoque de la instalación: global o local

Control del desarrollo:
Control de la calidad:
Control de la configuración:
Responsabilidad del cliente
Riesgos críticos Contramedidas
Riesgo 1 - - - + -
Riesgo 2 - - + - - -
Riesgo 3 +
Riesgo 4 - + + -
...
Justificación:
Figura 4.21: Diseño general de una matriz que relaciona las opciones seleccionadas
con los riesgos críticos.
Esta matriz resume la estrategia de adaptación.
(-: la opción reducirá el riesgo; +: la opción aumentará el riesgo)

Opciones estratégicas Descripción analítica

Descripción experimental
Descripción conducida por expertos
Descripción participativa
Instalación de una vez
Instalación incremental
Instalación evolutiva
Instalación total
Instalación local
Control frecuente del proyecto
Control formal del proyecto
Descripción del cliente
Riesgo Construcción del cliente
(consecuencias adversas) Instalación del cliente
Requisitos inciertos o inviables +
Incertidumbre en las interfaces con otros + +
sistemas
Requisitos variables + + + +
Costes impredecibles para la organización + + + +
Costes impredecibles para el proyecto + + + + + + +
Falta de participación de los agentes del + + + + +
dominio objetivo
Deficiencias de las tareas realizadas + + +
externamente
Retrasos de la entrega + + + + + + + +
Baja calidad de los entregables + + +
Incremento de los costes del proyecto + + + + + + + + + +
Problemas de integración + + +
Deficiencias de la calidad + + + + + +
Necesidad de profundos conocimientos de + +
informática
Sistema de información incorrecto o + +
inviable
Adaptación del sistema de información no + + + + +
Repercusiones en el negocio del fallo del +
proyecto
Riesgos generales:
Pérdida de control del proyecto + + + + + + +
El sistema de información no funciona + + + + + +
Figura 4.22: Riesgos que pueden verse aumentados por las opciones estratégicas.
(+: la opción estratégica aumentará el riesgo)

Capítulo 4
4.4 Planificación de los puntos de decisión

Definición Un punto de decisión en una adaptación del sistema de información
es un momento en que el cliente, posiblemente junto con el
proveedor, toma decisiones sobre la adaptación del SI. Un punto de
decisión se caracteriza por las decisiones que se toman, las funciones
involucradas en estas decisiones y los entregables que se
intercambian. Estos entregables sirven de condiciones previas o de
base para las decisiones a tomar. [EM-DC].
Planificación de los puntos de decisión apropiados a nivel de gestión contractual

La finalidad de las técnicas descritas en este apartado consiste en definir los puntos
de decisión apropiados a nivel de gestión contractual en una adaptación del sistema
de información.
• Insumo:
− comprensión de los estados inicial y final, y de los riesgos críticos
− una estrategia de adaptación: opciones estratégicas y contramedidas
− otras informaciones acerca de la situación, por ejemplo, factores
situacionales.
• Resultados:
− descripción de la secuencia de puntos de decisión; véase un esquema
general en la figura 4.23.
− descripción de cada uno de los puntos de decisión; véase la estructura en
la figura 4.24.
Mes a partir del 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

inicio del proyecto
Punto de decisión
<Punto de decisión 1> ∆
<Punto de decisión 2> ∆
etc.
Figura 4.23: Esquema general de una secuencia de puntos de decisión.

Una vez se han definido el estado inicial, el estado final y una estrategia de
adaptación, es posible definir una secuencia de puntos de decisión ajustada a la
situación del problema. La secuencia y contenido de los puntos de decisión deberá
reflejar la estrategia. Este apartado describe técnicas para definir estos puntos de
decisión ajustados.
Las técnicas deberán utilizarse en el orden siguiente: Secuencia de
técnicas para
1. Derivar la secuencia básica de puntos de decisión. definir puntos de
Esto puede basarse en opciones estratégicas que utilicen la terminología de decisión
Eurométodo, véase apartado 4.3.2-4, o en opciones estratégicas de otros ajustados
métodos.

2. Adaptar la secuencia básica para incorporar las contramedidas.

En el apartado 4.3.1 figuran ejemplos de contramedidas.
3. Describir los puntos de decisión.
En una descripción de puntos de decisión deberán señalarse todos los
entregables que deban entregarse a partir del anterior punto de decisión. Se
distinguen dos tipos de entregables:
– Base de decisión: los entregables que sirven de base para las decisiones a
nivel contractual.
– Condiciones necesarias: el resto de entregables que deben entregarse.
Posteriormente deberá añadirse la descripción detallada de los entregables,
utilizando las técnicas que se describen en el siguiente apartado.
Decisiones En una adaptación del SI pueden adoptarse varios tipos de decisiones. En un punto
acerca del de decisión pueden tomarse decisiones de distintos tipos. Los tres tipos de decisión
dominio principales son:
objetivo,
dominio del • Decisiones sobre cuestiones inherentes al dominio objetivo de la adaptación
proyecto y del SI
dominio es decir, sobre el sistema de información que se pretende adaptar.
contractual
• Decisiones sobre cuestiones inherentes al dominio del proyecto
es decir, sobre la organización y los planes para llevar a cabo el trabajo.
• Decisiones sobre cuestiones inherentes al dominio contractual
es decir, sobre cuestiones contractuales.
La finalidad de un punto de decisión deberá estar relacionada con estos tres tipos
de decisiones; véase la estructura de la figura 4.24.
1. Finalidad u objetivo.
1.1. Finalidad del dominio objetivo.
1.2. Finalidad del dominio del proyecto.
1.3. Finalidad del dominio contractual.
2. Funciones involucradas.
3. Entregables.
3.1. Condiciones necesarias: entregables del dominio objetivo y
entregables de gestión de proyecto.
3.2. Bases de decisión: propuesta de punto de decisión, informe de
situación del contrato, etc.
4. Programa organizativo y calendario.
5. Costes.
Anexo Perfiles de los entregables necesarios.
Figura 4.24: Estructura de la descripción de un punto de decisión.

Capítulo 4
Las decisiones sobre el dominio objetivo pueden clasificarse en tres subtipos:

Heurísticas
• decisiones de inversión generales acerca
de los tipos de
• decisiones de diseño decisión del
dominio objetivo
• decisiones de aceptación del sistema.
El contenido de los entregables que se utilizan para tomar una decisión dependerá
del tipo de decisión. Así pues, resulta útil caracterizar la finalidad de una decisión
indicando su tipo, ya que así se obtiene cierta orientación acerca de qué entregables
se precisan para tomar la decisión; véase las heurísticas generales de la figura 4.25.
El apartado 4.5 Definición de entregables, describe heurísticas más detalladas.

Tipo de decisión Finalidad Entregables
Decisión de inversión Decidir si se invierte o no en un Elementos descriptivos que

sistema de información nuevo (o fundamentan la valoración de:
modificado). beneficios, costes y riesgos.
La decisión de inversión inicial se Además de estas propiedades de la
revisa o pormenoriza en base a la inversión, las descripciones
información adicional que se deberán abarcar las propiedades
obtiene durante la adaptación del funcionales y de calidad que
SI. Otro caso es cuando la influyan en estos elementos.
adaptación del SI está encaminada
a proporcionar la información
necesaria para tomar una decisión
de inversión (planificación
estratégica, análisis de cambios,
etc.).
Decisión de diseño Decidir si un sistema de Elementos descriptivos cuyas

información nuevo (o modificado) características dependen del
es aceptable tal y como se ha enfoque, como se explica en el
descrito. apartado 4.4.1. Potencialmente
pueden precisarse todas las
propiedades funcionales y de
calidad. Ello dependerá del área de
interés.
Informes de garantía de calidad
que muestran los resultados del
control de calidad aplicados a los
elementos descriptivos.
Decisión de aceptación Existen dos tipos de decisiones de Elementos operativos que se

del sistema aceptación del sistema: prueban o se instalan.
• Decidir la aceptación de un Una descripción definitiva y
sistema de información actualizada del sistema de
construido y probado. información, si no se ha elaborado
y comprobado anteriormente.
• Decidir la aceptación de un
sistema de información Informes de garantía de calidad
instalado y operativo. que muestran los resultados de las
pruebas del sistema construido, o
validaciones del sistema instalado.
Informes de gestión de la
configuración.
Figura 4.25: Heurísticas generales acerca de las decisiones sobre el dominio

objetivo.

Capítulo 4
4.4.1 Derivar la secuencia básica de puntos de decisión

La secuencia de puntos de decisión deberá reflejar el enfoque del desarrollo y el
enfoque de control del proyecto que forman parte de la estrategia de adaptación.
Esta técnica proporciona heurísticas y ejemplos sobre la manera de definir puntos
de decisión en función de las opciones estratégicas seleccionadas. Se distinguen
dos escenarios:
1. Derivar una secuencia básica en base a las opciones estratégicas de Dos escenarios
Eurométodo.
Los puntos de decisión se definen utilizando las opciones estratégicas que
proporciona Eurométodo para la descripción, construcción, instalación y
control del proyecto, véase apartado 4.3.2.
2. Derivar una secuencia básica en base a un modelo de proceso del método.
Los puntos de decisión se definen por el modelo de proceso seleccionado para
el desarrollo del SI o por el método de gestión del proyecto aplicado en el
proyecto.
Posteriormente, en ambos escenarios, deberán tenerse en cuenta las contramedidas
definidas en la estrategia de adaptación, véase apartado 4.4.2.
4.4.1.1 Escenario 1: Derivar una secuencia básica en base a las opciones

estratégicas de Eurométodo
Para cada una de las opciones estratégicas de desarrollo definidas en el apartado El anexo C
4.3.2, Eurométodo proporciona un ejemplo de una secuencia de puntos de incluye ejemplos
decisión, como el de la figura 4.26. Estos ejemplos pueden utilizarse para definir de secuencias de
una secuencia básica de puntos de decisión. El anexo C contiene todos los puntos de
decisión
ejemplos. Los ejemplos relativos a modalidades de la descripción se basan en las
Puede utilizarse el siguiente procedimiento, el cual supone que el sistema de
información en cuestión se divide en subsistemas, y que pueden existir diferentes
opciones estratégicas en relación con los diferentes subsistemas. En caso de que no
exista un desglose en subsistemas, el paso uno se lleva a cabo una sola vez.
1. Para cada subsistema con una estrategia diferente, proceder de la siguiente Procedimiento
manera:
1.1. Combinar los ejemplos de secuencias asociados a los enfoques de
desarrollo en una única secuencia.
1.2. Mejorar los puntos de decisión con las finalidades del dominio del
proyecto, de acuerdo con el enfoque de control del proyecto que se ha
seleccionado. Si es preciso, añadir puntos de decisión. La figura 4.28
describe heurísticas para la influencia de los enfoques de control del
proyecto en la planificación de los puntos de decisión.
2. Combinar las secuencias para los subsistemas en una única secuencia para toda
la adaptación del SI.

En las figuras 4.29–31 figuran sendos ejemplos de combinaciones de puntos de

decisión para adaptaciones del SI. Los puntos de decisión se definen utilizando los
ejemplos de secuencias de puntos de decisión relativos a las opciones estratégicas
seleccionadas:
• Un ‘enfoque en cascada’,
de una descripción del problema a un sistema de información instalado.
• Un ‘enfoque modular’,
de una descripción del problema a un sistema de información probado.
• Un ‘enfoque de versión’,
de un diseño global a un sistema de información instalado.

Capítulo 4
Descripción analítica y conducida por expertos

Nº Finalidad Entregables
1. Perfil del elemento descriptivo:
Decisiones de diseño sobre:
• información del negocio/propiedades del proceso
marco lógico global del • propiedades de calidad, por ejemplo, seguridad
negocio • propiedades de la inversión, por ejemplo, costes, beneficios,
riesgos
• alcance íntegro, abierto a soluciones técnicas alternativas
• texto con ilustraciones gráficas
• futuro SI, sin simulación
• bajo grado de desglose y especialización
• propiedades de las prácticas de trabajo
diseño global de las prácticas • propiedades de calidad, por ejemplo, eficiencia, facilidad de
de trabajo uso
• propiedades de la inversión, por ejemplo, costes, beneficios
• futuro sistema de información, sin simulación
• propiedades del sistema informático
diseño global del sistema • propiedades de calidad, por ejemplo, fiabilidad, portabilidad
informático • propiedades de la inversión, por ejemplo, costes, riesgos
• propiedades de las prácticas de trabajo
diseño detallado de las • propiedades de calidad, por ejemplo, eficiencia, facilidad de
prácticas de trabajo uso
• alcance íntegro, soluciones técnicas alternativas
• alto grado de desglose y especialización
• propiedades del sistema informático
diseño detallado del sistema • propiedades de calidad, por ejemplo, eficiencia, facilidad de
informático uso
• alcance íntegro, soluciones técnicas alternativas
• alto grado de desglose y especialización
Figura 4.26: Ejemplo de secuencia de puntos de decisión.

Enfoque de la Heurísticas acerca de puntos de decisión

descripción
Enfoque Enfoque Marco del Nivel Solución Número de
cognitivo social negocio abstracto total puntos de
frente a frente a frente a decisión
sistema nivel solución
técnico concreto parcial
Analítico Conducido Del marco De abstracto De total Conjunto
por expertos del negocio a concreto a parcial mínimo
al sistema
técnico
Participativo Del marco Abstracto y Principal- Conjunto
del negocio concreto en mente de suficiente
al sistema paralelo total a
técnico parcial
Experimental Conducido Marco del De concreto De total Conjunto
por expertos negocio y a abstracto a parcial mínimo
sistema
técnico en
paralelo
Participativo Marco del De concreto Total y Conjunto
negocio y a abstracto parcial en suficiente
sistema paralelo
técnico en
paralelo
Heurísticas generales acerca de los entregables que sustentan las decisiones:
• Las decisiones sobre el marco del negocio se sustentan en las visiones del
• Las decisiones sobre el sistema técnico se sustentan en las visiones del sistema
informático.
• Las decisiones sobre un nivel abstracto se sustentan en las visiones del sistema
de información independientes de los agentes (visión del sistema de
información y visión de los procesos del negocio) y en las visiones del sistema
informático independientes de la unidad de proceso (visión de los datos del
sistema informático y visión de las funciones del sistema informático).
• Las decisiones sobre un nivel concreto se sustentan en la visión de las
prácticas de trabajo y en la visión de la arquitectura del sistema informático.
• Las decisiones sobre una solución total se sustentan en un alcance íntegro de
los entregables y en un nivel de detalle global, es decir, ni un alto grado de
desglose, ni un alto grado de especialización.
• Las decisiones sobre una solución parcial se sustentan en un alcance parcial de
los entregables y en un alto nivel de detalle detallado, es decir, un alto grado
de desglose y un alto grado de especialización.
Figura 4.27: Heurísticas acerca de la definición los puntos de decisión

en función del enfoque de la descripción.

Capítulo 4
Enfoque de control del Influencia en la planificación de los puntos de decisión

proyecto
Control frecuente del ê Control del proyecto en cada punto de decisión: definir la finalidad,
proyecto funciones y entregables.
ê Quizá añadir puntos de decisión con la única finalidad de control del
proyecto: los entregables dependerán de la frecuencia de los temas de
interés, por ejemplo, costes, planes, aseguramiento de la calidad y
gestión de la configuración.
Control formal del ê Incluir el control del proyecto en puntos de decisión periódicos con
proyecto requisitos formalmente definidos acerca de planes e informes.
ê Definir una métrica de la progresión y la calidad del proyecto, y
solicitar una métrica para los planes e informes de los puntos de
decisión.
ê Definir procedimientos formales de control de calidad, por ejemplo,
técnicas de inspección específicas, y solicitar estados de calidad de
elementos descriptivos de acuerdo con estos procedimientos.
ê Definir procedimientos formales de control de la configuración, y
solicitar planes e informes de configuración en determinados puntos de
decisión.
Responsabilidad del ê Descripción de los requisitos:
cliente Planificar lo antes posible las decisiones sobre los requisitos, con
entregables del cliente al proveedor.
ê Control de la configuración de los requisitos:
Planificar los planes e informes de control de la configuración del
cliente en determinados puntos de decisión.
ê Gestión de los conflictos del dominio objetivo:
Planificar las decisiones sobre los requisitos relativos a los conflictos.
ê Involucrar a los agentes del sistema de información apropiados:
Planificar con cuidado la asignación de funciones del cliente en los
ê Coordinación de las interfaces con otras adaptaciones del sistema de
información:
Planificar las decisiones sobre la coordinación de las interfaces con
otras adaptaciones del sistema de información con planes e informes
del cliente.
ê Adquisición de conocimientos y toma de decisiones:
Planificar con las decisiones de inversión y de diseño necesarias.
Figura 4.28: Ejemplos de la influencia de los enfoques de control del proyecto en la

planificación de los puntos de decisión.

Enfoque de desarrollo Adaptación ‘en cascada’
1. Decidir sobre: • marco lógico del negocio en términos generales

Descripción
• progresión del proyecto y plan de descripción
analítica y 2. Decidir sobre: • diseño general de las prácticas de trabajo
conducida por expertos
3. Decidir sobre: • diseño general del sistema informático
• revisión del plan de adaptación
4. Decidir sobre: • diseño detallado de las prácticas de trabajo
5. Decidir sobre: • diseño detallado del sistema informático

• progresión del proyecto y plan de construcción
Construcción de una vez 6. Decidir sobre: • aceptación del SI construido y probado

• progresión del proyecto y plan de instalación
7. Decidir sobre: • aceptación del sistema de información instalado

Instalación de una vez
8. Decidir sobre: • finalización del contrato
Figura 4.29: Ejemplo de una secuencia de puntos de decisión

desde una descripción del problema a un sistema de información instalado.
Control frecuente y formal del proyecto: cada punto de decisión contiene
decisiones acerca de la progresión y sentido de la adaptación del SI.

Capítulo 4
Enfoque de desarrollo Adaptación ‘modular’
1. Decidir sobre: • prototipo general de las prácticas de trabajo

Descripción
experimental y
2. Decidir sobre: • diseño general de las prácticas de trabajo
conducida por expertos • progresión del proyecto y plan de descripción
3. Decidir sobre: • prototipo general del sistema informático
4. Decidir sobre: • diseño detallado de las prácticas de trabajo
5. Decidir sobre: • diseño detallado del sistema informático

6.1 Decidir sobre: • aceptación de la parte 1 del sistema

Construcción
incremental (3 partes)
• progresión del proyecto y plan de ensayo del
sistema
7. Decidir sobre: • aceptación del SI construido y probado
• progresión del proyecto
8. Decidir sobre: • finalización del contrato

desde la descripción de un problema a un sistema de información probado.
decisiones acerca de la progresión y el sentido de la adaptación del SI.

Enfoque del Adaptación ‘de versión’

desarrollo
Descripción 1.1. Decidir sobre v.1: • diseño detallado del SI

(evolutiva) • prototipo y diseño detallados del CS
experimental y • progresión del proyecto y plan de construcción
participativa
(v.1)
Construcción 1.2. Decidir sobre: • aceptación del SI construido y probado, versión 1
(evolutiva) (v1) • progresión del proyecto y plan de instalación, v.1
Instalación 1.3. Decidir sobre: • aceptación del SI instalado, versión 1

(evolutiva) (v.1) • progresión del proyecto y plan de descripción, v.2
• revisión del plan de adaptación.
Descripción 2.1. Decidir sobre v.2: • diseño detallado del sistema de información
(evolutiva) • prototipo y diseño detallados del sistema
experimental y informático
participativa • progresión del proyecto y plan de construcción.
(v.2)
Construcción 2.2. Decidir sobre v.2: • aceptación del SI construido y probado
(evolutiva) (v.2) • progresión del proyecto y plan de instalación.
Instalación 2.3. Decidir sobre: • aceptación del SI instalado, versión 2

(evolutiva) (v.2) • progresión del proyecto y plan de descripción, v.3
• revisión del plan de adaptación.
Descripción 3.1. Decidir sobre la versión final (v.3):

experimental y • diseño detallado del SI
participativa • prototipo y diseño detallado del sistema informático
(v.3) • progresión del proyecto y plan de construcción.
Construcción 3.2. Decidir sobre: • aceptación de la versión final construida y probada

( v.3) • progresión del proyecto
• plan de instalación final.
Instalación 3.3. Decidir sobre: • aceptación de la versión final instalada

(v.3)
4. Decidir sobre: • finalización del contrato.

desde un diseño global hasta un sistema de información instalado.
decisiones acerca de la progresión y sentido de la adaptación del SI.

Capítulo 4
4.4.1.2 Escenario 2: Derivar una secuencia básica en base a un modelo

de proceso del método
Definición Un modelo de proceso del método es una descripción de una clase de

procesos para un proyecto de SI propuesto por un método. En la
mayoría de los casos, el modelo de proceso se utiliza con la finalidad
de proporcionar normas, es decir, describir ‘cómo
deben/deberían/podrían hacerse las cosas’, en contraste con el propio
proceso, que es lo que ocurre realmente. Muy a menudo el modelo
de proceso del método contiene recomendaciones sobre la secuencia
de puntos de decisión dentro del proyecto de SI [EM-DC].

1. Hallar correspondencias entre los productos del método y los productos de los
estados inicial y final definidos por los perfiles de los entregables.
2. Utilizar el modelo seleccionado de proceso del método para determinar los
productos intermedios que pueden precisar decisiones del cliente a nivel de
gestión contractual.
La secuencia en que deben darse las decisiones del cliente determina la secuencia
de los puntos de decisión.
Paso 1: Hallar correspondencias entre los productos del método y los estados
inicial y final
El primer paso consiste en definir los productos del método que pueden Hallar
corresponderse con los productos de los estados inicial y final definidos por los correspon-
perfiles del plan de adaptación. Si este paso se lleva a cabo antes del inicio de la dencias entre los
adaptación del SI, puede que sólo algunos de los productos del estado inicial estén productos del
disponibles para facilitar la definición; otros se describen únicamente mediante sus método y los
estados inicial y
perfiles, pero también se planifican para que estén disponibles en el estado inicial.
final
Los productos del estado inicial pueden producirse utilizando un método distinto al
que se haya utilizado en esta adaptación del SI.
Con este paso se consigue lo siguiente:
• se identifican todos los productos del método que han de entregarse dentro
de la adaptación del SI, tal y como constan en la descripción del estado final
• para todos los productos del estado inicial se identifica lo que representan en
términos del método aplicado.

Paso 2: Determinar los productos intermedios y los puntos de decisión

Determinar las Conociendo los productos del método que se obtienen en el estado inicial y los que
necesidades de han de producirse para el estado final, ya es posible determinar los productos
decisiones del intermedios que han de producirse de acuerdo con el método aplicado, en base al
cliente modelo de proceso del método aplicado21.
Para algunos de estos productos intermedios, el método aplicado puede precisar
decisiones del cliente. Estos productos se convierten en entregables, es decir, se
entregan al cliente. La secuencia en que deben darse las decisiones del cliente a
nivel de gestión contractual, determina la secuencia de puntos de decisión en el
plan de adaptación.
Al identificar las decisiones del cliente que se precisan, se garantiza lo siguiente:
• se identifican todos los puntos de decisión del plan de adaptación
• se identifican los entregables para cada punto de decisión.
Posteriormente, con ayuda de las técnicas de planificación de la adaptación, los
clientes y los proveedores pueden revisar y valorar la idoneidad del plan de
adaptación propuesto para la adaptación del SI.
4.4.2 Adaptar la secuencia básica a las contramedidas

Esta técnica proporciona las heurísticas y procedimientos que explican cómo
adaptar una secuencia básica de puntos de decisión a fin de tener en cuenta las
contramedidas. Estas contramedidas se han seleccionado utilizando la técnica
descrita en el apartado 4.3.1.
Procedimiento • revisar las contramedidas propuestas en la estrategia de adaptación: para
para modificar la cada contramedida deberá adaptarse la secuencia básica de puntos de
secuencia básica decisión, introduciendo uno o más cambios:
− definir y añadir nuevos puntos de decisión
− agrupar los puntos de decisión, por ejemplo, por motivos de calendario
− modificar la secuencia de puntos de decisión
− modificar el contenido de los puntos de decisión, es decir, la finalidad de
la decisión, las funciones que intervienen, el entregable a intercambiar o la
organización y el calendario.
La figura 4.32 refleja ejemplos de la influencia de las contramedidas en la
planificación de los puntos de decisión.
21 Algunos métodos no poseen un modelo de proceso; otros poseen un único modelo de

proceso; y también existen métodos que proponen varios modelos de proceso. En este caso,
la frase debería ser: “en base al modelo de proceso seleccionado ...”
Eurométodo no ofrece asesoramiento directo para la selección de un modelo de proceso en
concreto, si un método propone alternativas. No obstante, las técnicas de planificación de la
adptación pueden sustentar esta selección ayudando a definir la estrategia adecuada del
proyecto.

Capítulo 4
Contramedida Influencia en la planificación de los puntos de decisión
Involucrar a los agentes ê Al inicio de la adaptación del SI deberá decidirse un plan para
del SI involucrar a los agentes del SI.
ê Informar a los agentes del SI es una condición necesaria de algunos
Formar a los agentes del ê Al inicio de la adaptación del SI deberá decidirse un plan para un
SI programa de formación de los agentes del SI.
ê La formación deberá planificarse como condición necesaria de algunos
Utilizar la ingeniería ê Añadir puntos de decisión asociados al aumento del nivel de
inversa comprensión del SI actual mediante descripciones del mismo.
Realizar un análisis de ê Añadir puntos de decisión acerca de requisitos del futuro SI y
requisitos riguroso planificar con un control de la configuración de los requisitos.
Rehacer los elementos ê Añadir puntos de decisión acerca de la aprobación de nuevos
descriptivos elementos descriptivos.
Formar al equipo del ê Al inicio de la adaptación del SI deberá decidirse un plan para un
proyecto programa de formación del equipo del proyecto.
ê Deberán planificarse informes sobre la formación del equipo del
proyecto, que servirán de condiciones previas de algunos puntos de
decisión.
Subdividir la adaptación ê Plan que incluya decisiones iniciales de inversión o de diseño acerca
del SI de la definición de una secuencia de adaptaciones del SI, véanse las
heurísticas generales de las figuras 4.31, 4.32.
Utilizar a un experto del ê Plan que incluya decisiones del dominio del proyecto acerca de la
SI con un alto grado de asignación de agentes del proyecto. Se precisa un plan del proyecto
cualificación con perfiles de los agentes del proyecto.
Clarificar las interfaces ê Plan que incluya decisiones de diseño acerca de interfaces externas. Se
externas con otros SI precisan elementos descriptivos que abarquen las propiedades
adecuadas, y planes para la construcción, ensayo e instalación de las
interfaces.
Gestionar la complejidad ê Plan que incluya decisiones iniciales de diseño acerca del intercambio
de las propiedades de entre propiedades funcionales y propiedades de calidad. Aprobar las
calidad descripciones de las propiedades de calidad y las propiedades
funcionales que se precisen para sustentar esas decisiones.
Gestionar la migración ê Plan que incluya decisiones acerca del plan de migración. Se precisan
por pasos planes para la migración, incluyendo planes para la construcción y
ensayo de interfaces intermedias.
Utilizar una tecnología ê Plan que incluya decisiones iniciales de diseño acerca de la
objetiva segura, bien arquitectura y la tecnología del sistema informático. Se precisan
conocida y madura elementos descriptivos que abarquen la visión de la arquitectura del
sistema informático. Si es posible, deberán aportarse prototipos que
demuestren la madurez de la tecnología seleccionada.
Utilizar normas ê Plan que incluya decisiones iniciales de diseño acerca del uso de
normas, por ejemplo, las normas para sistemas informáticos abiertos.
Se precisan elementos descriptivos que abarquen la visión de la
arquitectura del sistema informático, centrándose en el uso de normas.

Figura 4.32: Ejemplos de la influencia de las contramedidas en los puntos de

decisión.

Capítulo 4
4.4.3 Describir los puntos de decisión

La figura 4.33 establece los elementos que debe tener una descripción de un punto
de decisión dentro de un plan de adaptación de Eurométodo. Esta estructura
deberá utilizarse para cada punto de decisión. El anexo D.21 contiene una plantilla
de una descripción de un punto de decisión. La figura 4.33 proporciona
orientaciones acerca de cada uno de los elementos de la descripción. Además se
recomienda lo siguiente:
• La secuencia y el calendario de los puntos de decisión deberán documentarse
en un mismo lugar del plan de adaptación para facilitar el mantenimiento, por
ejemplo, en forma de tablas o diagramas. Es decir, no deberá existir un
calendario absoluto en las descripciones de puntos de decisión.
• En las versiones tempranas de un plan de adaptación, el calendario puede
enunciarse con referencia al inicio de la adaptación del sistema de
información.
Elemento de la Orientaciones acerca de la descripción de puntos de decisión

descripción
1. Finalidad Describir la finalidad general del punto de decisión.
1.1. Finalidad del dominio Describir la finalidad de las decisiones relativas al dominio objetivo,
objetivo por ejemplo, la selección de soluciones y la aprobación de
descripciones del SI actual o de uno futuro.
1.2. Finalidad del dominio Describir la finalidad de las decisiones relativas al proyecto y al
del proyecto dominio contractual, por ejemplo, decisiones sobre entregables,
calendario, presupuesto y asignación de recursos.
1.3. Finalidad del dominio Describir la finalidad de las decisiones relativas al dominio
contractual contractual, por ejemplo, decisiones sobre el plan de adaptación y
otras cuestiones contractuales.
2. Funciones involucradas Describir las funciones involucradas en el proceso de toma de

decisiones.
Identificar a los agentes asignados a las funciones, para cada
organización (cliente y proveedor) y para cada función.
3. Entregables Proporcionar una descripción general de los entregables y señalar

cómo pueden sustentar la toma de decisiones.
3.1. Condiciones previas Describir los entregables que deben entregarse en el período que va
desde el punto de decisión previo hasta el punto de decisión
previsto, excepto la base para las decisiones – véase elemento 3.2.
Los entregables pueden ser: entregables del dominio objetivo
(elementos descriptivos, elementos operativos) y entregables de
gestión (planes e informes). Representan el hito de los entregables a
validar dentro de la ejecución del punto de decisión.
Tanto los entregables del proveedor al cliente como los entregables
del cliente al proveedor deberán describirse con referencia a los
perfiles de los entregables que figuran en el anexo.

Elemento de la Orientaciones acerca de la descripción de puntos de decisión

descripción
3.2. Bases para las Describir los entregables que se han planificado para ser entregados
decisiones como base de las decisiones. Los entregables pueden ser: propuesta
de punto de decisión, elementos descriptivos, planes, informes, plan
de adaptación. Los planes e informes deberán abarcar las
propiedades acerca de los recursos y el presupuesto relativos a la
información sobre el porcentaje de finalización.
Tanto los entregables del proveedor al cliente como los entregables
del cliente al proveedor deberán describirse con referencia a los
perfiles de los entregables que figuran en el anexo.
La propuesta de punto de decisión es obligatoria y deberá describir
los diferentes resultados de las decisiones, por ejemplo, los
entregables se aceptan por completo, se aceptan con reservas o se
rechazan; y las acciones alternativas con respecto a estas acciones,
por ejemplo, repetir el trabajo que sea preciso y volver a presentar el
entregable. Si procede, los resultados y acciones alternativas pueden
señalarse en las finalidades de la descripción del punto de decisión,
véase elemento 1.
4. Programa organizativo Describir el programa organizativo del proceso de toma de
y calendario decisiones y el calendario para los entregables. Esto incluye las
responsabilidades de elaborar una propuesta de punto de decisión y
un informe de punto de decisión.
Normalmente, el proceso de toma de decisiones contiene
validaciones de entregables, preparación de las decisiones y una o
más reuniones de punto de decisión. El programa organizativo y el
calendario deberán tener en cuenta la disponibilidad de las personas
involucradas, y prever el tiempo suficiente para la preparación de
las reuniones de punto de decisión.
5. Costes Efectuar una estimación de los costes del proyecto en el punto de
decisión, es decir, los costes que genera el proyecto desde el punto
de decisión previo (o inicio del proyecto) hasta el actual, más el
coste del propio proceso de toma de decisiones.
Anexo Proporcionar perfiles de varios entregables necesarios: elementos
descriptivos, planes e informes; véase las directrices del apartado
4.5.
Proporcionar referencias de los elementos descriptivos que
describirán los elementos operativos y servicios necesarios.
Figura 4.33: Orientación acerca de la descripción de puntos de decisión.

Capítulo 4
4.5 Descripción de los entregables

La regla básica para determinar qué entregables se precisan para una decisión es la
siguiente:
• Los entregables deberán contener la información idónea para adoptar la
decisión y ninguna más; el exceso de información resulta caro de producir y
genera una imagen más confusa, con lo que dificulta el trabajo de las
personas que toman las decisiones.
Los entregables necesarios deberán describirse utilizando los conceptos
independientes del método que se mencionan en el capítulo 3: Entregables. (þ 3:
Entregables)
Esta técnica proporciona orientaciones en torno a la planificación de elementos
descriptivos:
1. Describir perfiles de elementos descriptivos.
2. Establecer enlaces con productos del método.
4.5.1 Describir perfiles de elementos descriptivos

La figura 4.34 ofrece orientación sobre cómo elaborar el perfil de un elemento
descriptivo. Las figuras 4.35 – 4.37 reflejan heurísticas generales acerca de la
planificación de los tres tipos de decisión del dominio objetivo: inversión, diseño y
aceptación del sistema, además de orientación en torno a los requisitos de los
elementos descriptivos.
Elemento de la Orientaciones sobre el modo de elaborar el perfil de un

descripción elemento descriptivo
Visiones y Describir las visiones y propiedades funcionales que se precisan para
propiedades funcionales fundamentar las decisiones; véase la figura 4.32-34, que muestra
ejemplos de decisiones de inversión, diseño y aceptación del sistema,
y el anexo C , que contiene ejemplos de secuencias de puntos de
decisión.
Propiedades de calidad Describir las propiedades de calidad que se precisan para
fundamentar las decisiones; véase la figura 4.35–37, que muestra
ejemplos de decisiones de inversión, diseño y aceptación del sistema,
y el anexo C, que contiene ejemplos de secuencias de puntos de
decisión.
Propiedades de la Describir las propiedades de la inversión que se precisan para
inversión fundamentar las decisiones; véase la figura 4.35, que muestra
ejemplos de decisiones de inversión.
Alcance Definir los diferentes tipos de alcance que se utilizarán en el
proyecto, por ejemplo, en los términos de área de negocio, unidad
organizativa, conjunto de procesos o subsistemas del dominio
objetivo.
Asignar el tipo apropiado de alcance a este entregable de elemento
descriptivo.

Elemento de la Orientaciones sobre el modo de elaborar el perfil de un

descripción elemento descriptivo
Soluciones alternativas Indicar hasta qué punto este elemento descriptivo contiene
descripciones de soluciones alternativas.
Nivel de acuerdo Describir los diferentes tipos de niveles de acuerdo que se utilizarán
en el proyecto, indicando:
• qué agentes del dominio objetivo participan en el acuerdo en
torno al elemento descriptivo
• qué procedimientos de gestión del acuerdo se utilizan.
Asignar el tipo apropiado de nivel de acuerdo a este entregable.
Grado de formalidad Definir los diferentes tipos de formalidad que se utilizarán en el
proyecto, por ejemplo, en términos de técnicas de modelado.
Asignar el tipo apropiado de formalidad a este entregable.
Cuantificación Indicar si las propiedades deberían cuantificarse o no.
Simulación Indicar si este elemento descriptivo es un prototipo o no.
Identificación de la Indicar qué versión del SI debería describir este entregable, por
versión del SI ejemplo, el sistema actual, la primera versión instalada, o un futuro
sistema cuya instalación aún no se ha planificado.
Nivel de detalle Definir los diferentes niveles de detalle que se utilizarán en el
proyecto, por ejemplo, el nivel de desglose y especialización
utilizados en las técnicas de modelado.
Asignar el tipo apropiado de nivel de detalle a este entregable.
Estado de calidad Definir los diferentes estados de calidad que se utilizarán en el
proyecto, por ejemplo, en términos de los tipos de procedimientos de
calidad del sistema de garantía de calidad, por ejemplo, inspección,
evaluación de iguales y lecturas críticas.
Asignar el tipo apropiado de estado de calidad a este entregable.
Figura 4.34: Orientaciones sobre el modo de elaborar el perfil de un elemento

descriptivo.

Capítulo 4
Elemento de la Heurísticas generales acerca de las decisiones de

descripción inversión
1. Finalidad Decidir si se invierte o no en un sistema de información nuevo (o
modificado).
2. Funciones Incluye las funciones de la alta dirección.
involucradas
3. Entregables
Elementos
descriptivos
Visiones y Las propiedades funcionales, que fundamentan la valoración de los
propiedades beneficios, costes, riesgos y planes. Estas propiedades funcionales
funcionales deberán utilizar todas las visiones que influyen en esos elementos, es
decir, las visiones que mostrarán cualquier cambio que se produzca
entre el sistema de información actual y el futuro. Ejemplos:
• si los procesos del negocio van a cambiar, es probable que los
nuevos procesos del negocio repercutan en los beneficios,
costes, etc., por lo que deberá utilizarse la visión de los procesos
del negocio.
• si la decisión afecta a los cambios en la organización, a las
prácticas de trabajo, las funciones de los agentes, la
automatización de las tareas o la interfaz entre hombre y
ordenador, deberá utilizarse la visión de las prácticas de trabajo.
• si va a cambiar la arquitectura del sistema informático, ésta
probablemente repercuta en los beneficios, costes, etc. por lo
que deberá utilizarse la visión de la arquitectura del sistema
informático.
Propiedades de Requisitos de eficiencia, seguridad, mantenibilidad, etc.
calidad
Propiedades de la Beneficios
inversión ¿Qué beneficio supone un nuevo sistema de información?
Ello puede valorarse en términos de nuevas oportunidades de
mercado, ventaja competitiva, mejora de la calidad de un
servicio o producto, mejor gestión, operación más eficiente,
reducción de los costes organizativos, mejora de las condiciones
de trabajo para los agentes del sistema de información, etc.
Costes
¿Cuáles son los costes de la adaptación del sistema de
información, por ejemplo, costes del soporte físico y del soporte
lógico, costes de construcción, costes de instalación, etc.?
¿Qué costes operativos genera el nuevo sistema de información
y qué diferencias hay respecto al sistema actual?
Riesgo
¿Qué riesgos supone la adaptación del sistema de información
(véase apartado 4.2)?
Alcance Alcance íntegro, a menos que una parte representativa del sistema
pueda utilizarse para valorar los beneficios, costes, riesgos, etc.


Soluciones Deberán presentarse alternativas.
alternativas

Capítulo 4

Nivel de acuerdo El informe de punto de decisión deberá tener implicaciones legales.
Grado de formalidad Informal, en visiones generales, tablas y quizá diagramas para
visiones específicas.
Cuantificación Estimaciones de volúmenes, capacidad, etc. necesarias para la
valoración de costes, beneficios y riesgos.
Simulación Posibilidad de demostrar partes críticas o inciertas del sistema de
información mediante prototipos, por ejemplo maquetas.
Versión del SI Un futuro sistema de información.
No obstante, en ocasiones pueden introducirse entregables referidos al
sistema de información actual. Estos entregables pueden utilizarse con
la siguiente finalidad:
• Valorar si la comprensión del sistema de información actual es
correcta.
• Servir de base para expresar los cambios del sistema de
información.
• Justificar las propuestas de cambios mediante un diagnóstico del
sistema de información actual.
• Comparar el futuro sistema de información con el actual y
garantizar que hay una mejora.
Aparte de estas finalidades, no existe justificación para la
introducción de un entregable referido al sistema actual como insumo
para una decisión de inversión, ni siquiera si su producción se ha
planificado con un método de desarrollo.
Nivel de detalle Una visión global (bajo grado de desglose, bajo grado de
especialización) es suficiente para valorar los beneficios, costes,
riesgos, etc.
Sin embargo, en ciertos casos se precisa una apreciación más
profunda de aquellas partes del sistema que se consideran críticas,
complejas o inciertas. Para estas partes se precisa más detalle en las
descripciones; el nivel de detalle correcto es el que permite adoptar la
decisión de inversión.
Estado de calidad Debe adaptarse a la decisión a tomar: normalmente las decisiones de
inversión no precisan un nivel máximo de coherencia, precisión o
integridad.
Planes e informes
Plan de adaptación No se precisa necesariamente el plan de adaptación completo, sino
que deben conocerse varias fechas clave, como la fecha en que estarán
disponibles los principales subsistemas.
4. Programa organizativo Se precisa algún tiempo entre la entrega y la reunión de puntos de
y calendario decisión.
Figura 4.35: Heurísticas para la definición de decisiones de inversión.

Elemento de la Heurísticas generales acerca de las decisiones de diseño

descripción
1. Finalidad Decidir si un sistema de información nuevo (o modificado) es aceptable

tal y como está descrito.
2. Funciones
involucradas
3. Entregables
Elementos descriptivos Las características dependen del enfoque, como se explica en el apartado
4.4.1.
Visiones y Potencialmente todas las propiedades, en función de la finalidad. Por
propiedades ejemplo:
funcionales
• Si la decisión se refiere a cambios del negocio y de los recursos de
información que lo sustentan, el perfil del entregable utilizará la
visión de la información del negocio y la visión de los procesos del
negocio.
• Si la decisión se refiere a cambios de la organización, las prácticas
de trabajo, las funciones de los agentes, la automatización de las
tareas o la interfaz hombre-ordenador, el perfil del entregable
utilizará la visión de las prácticas de trabajo.
Propiedades de Potencialmente todas las propiedades de calidad.
calidad
Propiedades de la
inversión
Alcance Dependerá de la naturaleza de la decisión y de su ubicación en la
secuencia.
Soluciones
alternativas
Nivel de acuerdo
Grado de formalidad
Cuantificación
Simulación
Versión del SI Un futuro sistema de información.
No obstante, en ocasiones pueden introducirse entregables referidos al
sistema de información actual. Las heurísticas para las decisiones de
diseño son similares a las heurísticas para las decisiones de inversión,
véase figura 4.31.
Nivel de detalle Dependerá de la naturaleza de la decisión y de su ubicación en la
secuencia.
Estado de calidad Los procedimientos de calidad a aplicar suelen estar más elaborados que
los de las decisiones de inversión. Los procedimientos de control de
calidad pueden controlar la corrección, precisión, integridad, coherencia,
rastreabilidad de los requisitos, etc. de acuerdo con los planes.
Planes e informes Informes de aseguramiento de la calidad que muestran los resultados del
control de calidad aplicado a los elementos descriptivos.
4. Programa organizativo
y calendario
Figura 4.36: Heurísticas para la definición de decisiones de diseño.

Capítulo 4
Elemento de la Heurísticas generales acerca de la aceptación del sistema

descripción
1. Finalidad Existen dos tipos de decisiones de aceptación del sistema:

• Decisión de aceptación de un sistema de información
construido y probado.
• Decisión de aceptación de un sistema de información instalado
y operativo.
2. Funciones
involucradas
3. Entregables
Elementos Elementos operativos probados o instalados.
operativos
Elementos Una descripción actualizada y definitiva del sistema de información,
descriptivos si no se ha realizado y comprobado anteriormente.
Visiones y
propiedades
funcionales
Propiedades de
calidad
Alcance
Soluciones No existen alternativas
alternativas
Nivel de acuerdo
Grado de formalidad
Cuantificación
Simulación
Versión del SI Futuro sistema de información
Nivel de detalle Detallado (alto grado de desglose y de especialización).
Estado de calidad Actualizado y revisado de acuerdo con los procedimientos de
calidad.
Planes e informes • Informes de aseguramiento de la calidad que muestran los
resultados de los ensayos del sistema construido o validaciones
del sistema instalado.
• Informes de gestión de configuración (en su caso).
4. Programa Se precisa algún tiempo entre la entrega y la reunión de punto de
organizativo y decisión.
calendario
Figura 4.37: Heurísticas para la definición de decisiones de aceptación del sistema.

4.5.2 Establecer enlaces con los productos del método

El plan de adaptación contiene los perfiles de los entregables necesarios, que
definen las propiedades que deben reunir los productos del método que
intercambiarán el cliente y el proveedor durante la adaptación del sistema de
información.
Una vez se ha establecido el plan de adaptación, los perfiles de los entregables que
se precisen deben enlazarse con los productos definidos en los métodos utilizados
por el proveedor. El proveedor deberá describir los productos del método que se
entregarán en cada punto de decisión para satisfacer los requisitos descritos en los
perfiles de los entregables. Esta actividad podrá apoyarse en un diccionario de
enlace con los métodos, es decir, un conjunto de perfiles de productos del método
que describen los productos definidos en los manuales del método, utilizando la
terminología de Eurométodo.
Cómo utilizar un Un diccionario de enlace con los métodos puede utilizarse para adaptar y
diccionario de establecer correspondencias entre los perfiles de los productos del método y el
enlace con los perfil del entregable que se precise, hasta que se ha hallado el mayor número
métodos posible de correspondencias con las propiedades establecidas.
La identificación El procedimiento para hallar el conjunto de productos del método que concuerde
de los con el perfil del entregable que se precisa, presenta algunas de las características de
entregables del la solución de un rompecabezas. El perfil del entregable que se precisa representa
método es como un contorno imaginario en el que encajan unas piezas, que son los perfiles de los
un rompecabezas
productos del método que debemos hallar. En esta analogía, la ‘forma’ de las
piezas viene definida por las propiedades que posee cada uno de los productos del
método; y la ‘forma’ del contorno viene definida por las propiedades que especifica
el perfil del entregable que se precisa.
Esta analogía debe recordar al lector que el proceso de establecer enlaces con los
productos del método no tiene por qué ser secuencial en la realidad.
pero las piezas Pero también existen límites para esta analogía. Mientras que un rompecabezas
del posee una solución determinada, hallar los productos del método apropiados
rompecabezas se supone adaptar los productos del método a los perfiles de los entregables que se
pueden hacer a precisan. Esto implica que pueden existir diferentes combinaciones de productos
medida
del método adaptados que concuerden con el perfil del entregable que se precise.
Cómo gestionar Si el perfil del entregable que se precisa incluye alguna propiedad no contemplada
las propiedades por los productos del método, deberán identificarse ampliaciones de los métodos
para las que no que permitan cubrir esa laguna. Una vez se ha conseguido esto, se pueden elaborar
es posible hallar perfiles de los productos del método para las ampliaciones, al objeto de completar
correspondencias
el diccionario de enlace con los métodos.
4.6 Valoración de un plan de adaptación

Las técnicas de elaboración de un plan de adaptación, véase apartado 4.2-4,
también pueden utilizarse para la valoración del mismo. En general, la valoración y
la elaboración de un plan de adaptación se componen de las mismas actividades,

Capítulo 4
con la única diferencia de que en el primer caso existe una propuesta al inicio de la
actividad. Por ejemplo:
• Las técnicas de análisis de riesgos también son relevantes como orientación Simular la
para la valoración de un plan de adaptación. Es esencial comprender la elaboración de
situación del problema a fin de valorar la idoneidad de un plan de adaptación un plan de
adaptación
y la justificación de la estrategia del proyecto y los puntos de decisión.
• Las técnicas de selección de una estrategia de adaptación adecuada pueden
considerarse técnicas de valoración de la idoneidad de una estrategia de
adaptación seleccionada dentro de un plan de adaptación.
• Las técnicas de comprobación de la coherencia de la descripción de puntos
de decisión pueden utilizarse como técnicas de valoración de los puntos de
decisión dentro de un plan de adaptación.
Las técnicas no incluyen la valoración del contexto de un plan de adaptación en su Valorar el
estado inicial. Esta valoración podría incluir la siguiente evaluación de la contexto del plan
coherencia entre los elementos de un estado inicial: de adaptación
• El plan del proyecto relativo a la adaptación del sistema de información en

cuestión deberá ser coherente con el plan de adaptación.
• Las descripciones relativas a los elementos operativos disponibles para el
proyecto del sistema de información, deberán estar actualizadas. Los
elementos operativos se instalan en un sistema de información en su estado
inicial, en construcción o listo para ser instalado.
4.6.1 Valorar la descripción de la situación

Deberán utilizarse las técnicas descritas en el apartado 4.2. Además deberán
aplicarse los siguientes criterios de calidad relativos a la calidad de la descripción
de los estados inicial y final:
• Deberán valorarse las descripciones que deberían estar disponibles para la Criterios de
adaptación del sistema de información (parte del estado inicial) y las calidad para la
descripciones que el cliente desea utilizar una vez finalizada la adaptación del descripción de
los estados
sistema de información (parte del estado final).
inicial y final
• Los perfiles de las descripciones de estados iniciales deberán estar en
concordar con el contenido y situación de las descripciones actuales o con las
expectativas en cuanto al contenido y situación de las descripciones
disponibles al inicio de la adaptación del sistema de información.
• Los perfiles de las descripciones de estados finales deberán estar de acuerdo
con los requisitos y expectativas del cliente.
• Los productos que el proveedor facilitará en el estado final deberán estar
documentados y coincidir con los perfiles.

4.6.2 Valorar la idoneidad de la estrategia de adaptación

Es preciso describir la justificación de la estrategia de adaptación seleccionada, que
deberá adaptarse a la situación.
Si la estrategia se describe utilizando la terminología de Eurométodo, deberán
utilizarse las técnicas descritas en el apartado 4.3 al objeto de comprobar los
siguientes criterios de calidad:
Criterios de • Deberá existir una coherencia interna en la estrategia de adaptación. Por
calidad para la ejemplo, ausencia de contradicciones entre las modalidades de descripción,
estrategia de construcción e instalación.
adaptación
• La estrategia de adaptación deberá dar como resultado el estado final que se
precisa.
• Las modalidades de descripción, construcción, instalación y control del
proyecto deberán ser adecuadas. Esto puede valorarse utilizando las
heurísticas de selección de enfoques, véase apartado 4.3.2, y de análisis de
repercusiones, véase apartado 4.3.5.
• El resto de contramedidas deberá ser adecuado. Esto puede valorarse
utilizando las heurísticas de selección de contramedidas, véase apartado
4.3.3-4.
4.6.3 Valorar la idoneidad de los puntos de decisión

Deberán utilizarse las técnicas descritas en el apartado 4.2. Además deberán
aplicarse los siguientes criterios de calidad, relativos a la idoneidad de los puntos
de decisión planificados:
Criterios de • Los puntos de decisión deberán adaptarse a la situación y ser coherentes con
calidad para las la estrategia de adaptación descrita, para lo cual deberá proporcionarse una
descripciones de justificación. Esto puede valorarse utilizando las heurísticas de definición de
puntos de
una secuencia de puntos de decisión, véase apartado 4.4.1-2.
decisión
• Las finalidades de los puntos de decisión deberán ser comprensibles y
adecuadas.
• Las descripciones que sirven de condiciones necesarias o de bases para la
toma de decisiones deberán describirse utilizando perfiles de los elementos
descriptivos, es decir, términos independientes del método.
• Los entregables deberán definirse y ser suficientes de acuerdo con las
finalidades de las decisiones. Esto puede valorarse utilizando las heurísticas
de definición de los perfiles de los entregables relativos a las decisiones,
véase apartado 4.4.4.
• Deberá existir una coherencia entre las finalidades del entregable y las
decisiones.
• Las descripciones propuestas por el proveedor deberán estar documentadas y
coincidir con los perfiles de los elementos descriptivos.

Capítulo 4
• Las funciones propuestas que intervienen en la toma de decisiones deberán

ser apropiadas y asignarse a las personas adecuadas.

Capítulo 5
Descripción y planificación de servicios
5 Descripción y planificación de servicios

Este capítulo explica las actividades de descripción y planificación de servicios de
estado estable y sus resultados (véase figura 5.1.). Estos resultados se incluyen en
la petición de ofertas, en la oferta y en el contrato (consultar 2.3. y 3.2.) cuando la
compra se refiere a servicios. Este capítulo debe ser leído por los responsables de
proyecto de los clientes y de los proveedores. En el transcurso de una adquisición
se suele acceder a él desde el capítulo 2, a través de las referencias apropiadas.
Un servicio es un proceso relevante para el dominio objetivo que es ejecutado por
otra persona u organización. La subcontratación de un proceso se considera una
manera de obtener mayores beneficios de ese proceso.
La finalidad de un servicio de estado estable es contribuir al funcionamiento del
dominio objetivo (cf. capítulo 1). Los servicios de estado estable se caracterizan
por:
• el dominio objetivo en cuestión
• el tipo de procesos que se llevan a cabo
• los elementos operativos destinatarios de los servicios.
A menudo los servicios se describen y planifican en el contexto de proyectos de Puede utilizarse
reingeniería de procesos de negocio, que son un tipo de adaptación del dominio la reingeniería
objetivo. De hecho, la contratación de un proceso suele conllevar cambios de procesos de
organizativos importantes en el dominio objetivo, que deben estudiarse y negocio para
preparar la
prepararse con cuidado. Para llevar a cabo estos proyectos deberán utilizarse contratación de
métodos adecuados de análisis de requisitos y de reingeniería de procesos de procesos
negocio.
Normalmente este tipo de proyectos dan los siguientes resultados:
• descripción de los procesos/servicios existentes en el dominio objetivo
• descripción de los futuros procesos/servicios; proporcionan requisitos de los
futuros servicios
• planes (planes de prestación de servicios y planes de servicio) o requisitos de
planes.
Estos resultados constituyen los insumos para las actividades que se explican en los
siguientes apartados.
Si no se ha llevado a cabo un proyecto de este tipo, será preciso realizar un estudio Los requisitos
de reingeniería de procesos como parte de las actividades de descripción y del servicio
planificación del servicio. En cualquier caso, se dispondrá de un determinado forman parte de
conjunto de requisitos del servicio, como parte del objetivo de la adquisición. la definición del
objetivo de la
adquisición

5.1 Descripción de servicios
Actividad Insumo y resultado

1. Identificar el tipo de servicio (opcional) Entrada:
2. Describir las propiedades del servicio: • Requisitos del servicio
• las propiedades de la inversión • Descripciones disponibles de los
procesos/servicios existentes en el dominio
• las propiedades funcionales
objetivo (opcional)
• las propiedades de calidad
• Descripciones disponibles de
procesos/servicios similares (opcional)
• Descripciones de procesos incluidas en la
norma ISO-LCP (opcional)
• Descripciones de servicios incluidas en los
paquetes de servicios disponibles (opcional)
Resultado:
• Descripción del servicio
Figura 5.1.: Actividades y resultados de la descripción de servicios

Los servicios pueden describirse por extensión, es decir, por las propiedades que
Describir un caracterizan cada servicio, y por intención, es decir, por su tipología (por ejemplo,
servicio por las un tipo de servicio es el mantenimiento).
propiedades y
por la tipología 5.1.1 Identificar el tipo de servicio
Se proponen dos fuentes para identificar el tipo de servicio:
• los Procesos del Ciclo Vital de la norma ISO [ISO-LCP] y
• los paquetes de servicios del dominio público.
5.1.1.1 Identificar el tipo de servicio utilizando los Procesos del Ciclo

Vital de la norma ISO
Identificar el Un servicio puede ser declarado en términos de tipos de procesos y tipos de

tipo utilizando la elementos operativos que son objeto de dicho servicio. La norma ISO sobre
norma [ISO- Procesos del Ciclo Vital [ISO-LCP] proporciona una lista de tipos de procesos
LCP] (véase figura 5.2). A pesar de que esta norma se centra en productos de software,
se mencionan también otros tipos de elementos operativos de sus procesos, como
procedimientos, soporte físico o agentes formados.
Pueden aplicarse varios tipos de procesos a cada tipo de elemento operativo. En la
práctica, diferentes elementos operativos pueden requerir diferentes tipos de
servicios.
La figura 5.2 muestra las correspondencias existentes entre Procesos del Ciclo
Vital y los tipos de elementos operativos dentro de la norma [ISO-LCP]. Esta

Capítulo 5
matriz no es exhaustiva, de manera que también son válidos otros tipos de

correspondencias, aunque no estén recogidos en la norma, como por ejemplo el
mantenimiento de las instalaciones.
La norma [ISO-LCP] proporciona descripciones normalizadas de los Procesos del
Ciclo Vital, desglosándolos en actividades y tareas (véase ejemplo de la figura
5.3.).
Elementos operativos
Instalacio- Soporte Software de Software de Datos Manuales Descripción Programa Agentes
nes físico sistema aplicación físicos de usuario y del trabajo de formados
Procesos del Ciclo Vital de (edificios, de operador formación/
la norma ISO-LCP cableado migración
etc.)
Primarios
Adquisición √ √ √ √
Suministro √ √ √ √
Desarrollo √ √ √ √ √ √ √
Operaciones √ √ √
Mantenimiento √ √ √ √ √ √ √
De apoyo
Documentación √ √ √ √
Gestión de configuración √ √
Aseguramiento de la calidad √ √ √ √
Verificación √ √ √ √ √ √ √ √
Validación √ √ √ √ √
Revisión conjunta √
Auditoría √ √ √
Resolución de problemas √
Organizativos
Gestión
Infraestructura √ √ √ √
Mejora
Formación √
Figura 5.2: Correspondencias entre los procesos y los elementos operativos

incluidos en la norma [ISO-LCP]

Proceso de mantenimiento del software

Actividades Tareas
Implementación del proceso 1. El responsable de mantenimiento deberá
desarrollar, documentar y ejecutar planes y
procedimientos para llevar a cabo las actividades y
tareas del proceso de mantenimiento.
....
Análisis del problema y de la 1. El responsable de mantenimiento deberá analizar
modificación el informe del problema o la solicitud de
modificación, al objeto de detectar las
repercusiones en la organización, en el sistema
actual y en el sistema con el que existe interfaz
..etc.
2. El responsable de mantenimiento deberá replicar o
verificar el problema.
......
Implementación de la modificación ......
Revisión/aceptación del ......
mantenimiento
Migración ......
Retirada del software ......
Figura 5.3: Desglose del proceso de mantenimiento del software según la norma
[ISO-LCP]
5.1.1.2 Identificar el tipo de servicio utilizando paquetes de servicios
Los paquetes de servicios proporcionan una segunda manera de identificar un tipo

de servicio.
Identificar el Los proveedores de servicios normalmente especifican los servicios en términos de
tipo utilizando paquetes de servicios, como servicios de ayuda y gestión de problemas. A menudo
paquetes de utilizan su capacidad y su plantilla para atender a las solicitudes de servicios de
servicios varios clientes a la vez, de manera que los clientes comparten algunos de los
paquetes de servicios.
Estos paquetes de servicios suelen describirse con mayor detalle que las
descripciones de procesos de la norma [ISO-LCP]. La biblioteca de infraestructura
de tecnologías de la información de la CCTA [ITIL] proporciona una descripción
de los paquetes de servicio a la que puede acceder el público en general.
La figura 5.4 refleja una breve descripción de los principales tipos de paquetes de
servicios.

Capítulo 5
Paquetes de servicios típicos Breve descripción
Gestión de la configuración Identificar y documentar el software, soporte físico, redes,

etc. disponibles; controlar, registrar e informar de sus
cambios.
Gestión de problemas Reconocer y resolver problemas de infraestructura.
Gestión de cambios Llevar a cabo cambios controlados del sistema de
información, de manera que se evite cualquier
interrupción o problema en la prestación de servicios.
Servicios de ayuda Ayudar a los usuarios en el uso de los sistemas o servicios
e intentar gestionar las desviaciones o incidentes de que
informen los clientes.
Control y distribución de Validar todos los elementos de software y garantizar que
software se comercializan únicamente versiones probadas y válidas
de software autorizado.
Gestión de la red Gestionar todas las instalaciones de comunicación de
datos
Gestión de operaciones Cuidar de la operación diaria de los sistemas.
Gestión de procesadores y Gestionar los sistemas y estaciones de trabajo locales
terminales locales
Gestión de la seguridad Vigilar el uso no autorizado de sistemas, redes y software.
Gestión de la capacidad Garantizar la capacidad necesaria y un uso óptimo de la

capacidad disponible. Posibilitar el cumplimiento de los
requisitos de usuario en cuanto a horas de servicio,
recuperación, tiempos de respuesta, etc.
Gestión de la disponibilidad Optimizar la disponibilidad de las infraestructuras de TI y
apoyar a la organización que presta los servicios de TI, al
objeto de garantizar el cumplimiento de los requisitos del
negocio.
Gestión de contingencias Garantizar y restaurar la disponibilidad de sistemas y
aplicaciones (por ejemplo, mediante procedimientos de
copia de seguridad y recuperación) en caso de catástrofes
y eventos imprevistos.
Figura 5.4: Visión general de los principales tipos de paquetes de servicios

Los servicios arriba mencionados se relacionan entre sí de la siguiente manera.
• Los servicios al cliente (servicios de ayuda, etc.) captan incidentes y nuevos Servicios al
requisitos de los clientes, los cuales son causa de problemas que deben ser cliente
gestionados (gestión de problemas) y pueden activar una ‘cadena de
cambios’ compuesta de la gestión de cambios, gestión de la configuración,
distribución y control de software.
• Los servicios de gestión de operaciones que planifican, gestionan y operan Servicios de
los elementos operativos incluyen la gestión de operaciones automatizadas, gestión de
gestión de redes, gestión de procesadores y terminales locales. Los incidentes operaciones

que se produzcan en estas instalaciones centrales y redes pueden conducir a

la misma ‘cadena de cambios’.
Además, pueden existir relaciones entre los proyectos de adaptación y algunos de
estos servicios (por ejemplo, gestión de la configuración, gestión de cambios,
control y distribución de software).
5.1.2 Descripción de las propiedades de un servicio
Caracterizar una Las descripciones de los servicios son un tipo de elemento descriptivo. Una
descripción del descripción del servicio puede caracterizarse mediante un perfil del elemento
servicio descriptivo (véase 3.6.1) que indique las propiedades de interés:
mediante un
perfil del • propiedades funcionales
elemento
descriptivo • propiedades de calidad
• propiedades de la inversión.
El perfil del elemento descriptivo indicará también: alcance del servicio, nivel de
detalle, nivel de acuerdo, grado de formalidad, cuantificación, simulación,
identificación de la versión del servicio, soluciones alternativas y estado de calidad
del elemento descriptivo del servicio. En el apartado 3.6 figuran más orientaciones
acerca del modo de describir estas características.
Las descripciones normalizadas que especifica la norma [ISO-LCP] y las
descripciones de los paquetes de servicios simplifican la descripción del servicio, al
existir la posibilidad de reutilizar las descripciones existentes.
En la práctica, la descripción de las propiedades de la inversión, funcionales y de
calidad se lleva a cabo en paralelo, debido a las interdependencias entre estas
actividades.
5.1.2.1 Describir las propiedades de inversión de un servicio
Describir el Las bases lógicas o los objetivos de la contratación de un servicio pueden

objetivo describirse mediante las propiedades de la inversión, las cuales hacen referencia a
mediante las los costes y beneficios del servicio.
propiedades de
la inversión • Costes
Los costes de instalación, ejecución, mantenimiento y cancelación del
servicio
• Beneficios
Los beneficios que un servicio aporta al dominio objetivo. Entre los más
habituales cabe destacar:
− ahorro de costes
− reducción del personal
− reducción del número de actividades realizadas
− mejor gestión de los costes de TI
− acceso a tecnologías más avanzadas
− mejor prestación de servicios

Capítulo 5
− enfoque más profesional de las TI

− concentración en el núcleo del negocio
− ayuda en la introducción de nuevas aplicaciones de sistemas empresariales
− mejor acceso a conocimientos especializados
− flexibilidad con respecto a picos, influencias estacionales, etc.
• Riesgo
Los principales riesgos en este nivel incluyen la baja calidad del servicio,
pérdida del control (costes, calendario). En el apartado 5.2.1, Análisis de
riesgos, se hallará más información al respecto.
5.1.2.2 Describir las propiedades funcionales de un servicio
En términos de Eurométodo, la descripción funcional de un servicio consiste

principalmente en las propiedades de los procesos de negocio y de las prácticas
de trabajo (véase 3.6.2). Los Procesos del Ciclo Vital de la norma [ISO-LCP] se Describir las
describen en términos de propiedades de los procesos del negocio, mientras que funciones, por
ejemplo,
los paquetes de servicios suelen describirse en términos de propiedades de los
mediante las
procesos de negocio y propiedades de las prácticas de trabajo. propiedades de
Para algunos servicios, puede que esta descripción deba perfeccionarse las prácticas de
trabajo
utilizando otras visiones. En particular, se precisará la visión del sistema
informático cuando una parte del servicio esté automatizada.
Para otros servicios, cuando sea preciso representar algún aspecto de la
organización distinto del sistema de información, las descripciones de los
servicios deberán ampliarse documentando los flujos apropiados de material,
capital o energía.22
Las propiedades de la visión de los procesos del negocio pueden utilizarse para
describir el proceso de negocio que aborda el servicio.
Ejemplo Un servicio de mantenimiento del software puede describirse de la siguiente
manera:
PROCESO DE NEGOCIO: mantenimiento del software
EVENTO ACTIVADOR: se identifica un error
EVENTO GENERADO: aprobación de la modificación
CONDICIÓN ACTIVADORA: se presenta un informe de un problema
REGLAS DE NEGOCIO: problemas muy graves evaluados el mismo día
INFORMACIÓN UTILIZADA / GENERADA: documentación de modificación.
etc.
22 Por consiguiente, las propiedades de las prácticas de trabajo de Eurométodo deberán

perfeccionarse, a fin de representar estos flujos de material, capital y energía.

Las siguientes propiedades de la visión de las prácticas de trabajo se utilizan de la

siguiente manera:
• agentes:
− recursos humanos para cada tipo de cualificación
− toda cualificación que se precise, formación de personal nuevo (o
referencias a la documentación de formación) y toda deficiencia conocida
en las cualificaciones o cualificaciones difíciles de obtener
• tareas:
− obligaciones del proveedor en términos de tareas
− obligaciones del cliente en términos de tareas, inclusive las obligaciones
que son críticas para que la entrega del servicio obtenga un resultado
favorable, tales como la asistencia a las reuniones de servicios
• reglas de las tareas
− reglas que dirigen las tareas
− imperativos del cliente en cuanto a la práctica laboral, por ejemplo, horas
de trabajo, uso de las instalaciones locales
• la(s) ubicación(es) e imperativos con respecto al acceso o al uso
• los recursos necesarios para realizar la tarea, aportados por el proveedor y
por el cliente (por ejemplo, fotocopias, impresión de documentos, servicios
técnicos y otras facilidades):
− responsabilidades del proveedor en cuanto a estos recursos y cualquier
imperativo relativo a su uso
− referencias a los inventarios que se mantienen y responsabilidades de su
mantenimiento
• eventos organizativos activadores: por ejemplo, surge un problema en la red
• condición activadora: por ejemplo, el problema tiene lugar en horas de
trabajo y posee una prioridad de la categoría 1 ó 2
• uso y generación de información, por ejemplo documentación de redes
• responsable de la ejecución de la tarea: por ejemplo, técnico de redes
• responsable de la gestión de la tarea: por ejemplo, responsable de un servicio

Capítulo 5
Ejemplo Un servicio de ayuda puede describirse de la siguiente manera:

EVENTO ORGANIZATIVO ACTIVADOR: surge un problema
CONDICIÓN ACTIVADORA: el problema se produce durante el horario de
trabajo y posee una categoría de prioridad 2
TAREA: resolver este problema
REGLAS DE LA TAREA: el procedimiento normalizado para resolver este
problema
RESPONSABLE DE LA EJECUCIÓN: el encargado del servicio de ayuda que
esté disponible en ese momento
RESPONSABLE DE LA GESTIÓN: El gerente de servicios, etc.
5.1.2.3 Describir las propiedades de calidad de un servicio
Las propiedades de calidad de un servicio constituyen el nivel de servicio, es decir,

el nivel de servicio es el indicador de la calidad del servicio prestado.
Los requisitos de calidad se obtienen de los usuarios o se extraen de la estrategia Describir el nivel
de la organización. Por ejemplo, la rapidez con que los datos deben estar de servicio
disponibles para una tarea, o qué importancia tiene la portabilidad para la mediante las
propiedades de
organización. La lista de propiedades de calidad que se ofrece en el apartado 3.6.
calidad
(por ejemplo, seguridad, fiabilidad, facilidad de uso, eficiencia) puede utilizarse
como lista de comprobación para identificar estos requisitos de calidad.
Estos requisitos de calidad deben ordenarse por prioridades y acordarse entre los
distintos agentes que intervienen, con lo que se obtendrá una lista de requisitos de
calidad ordenada que expresará en términos mensurables (por ejemplo, acceso en
un segundo) la importancia del requisito, la motivación para el requisito y el nivel
de acuerdo entre los agentes.
Pueden proponerse distintos tipos de acción para ocuparse de los requisitos de Puntualizar las
calidad. Por ejemplo, personal de apoyo a la formación, procedimientos de descripciones de
desarrollo para la recuperación tras una catástrofe, seguros de riesgos, uso de un la propiedad de
paquete de aplicaciones, inclusión de funciones de diálogo adicionales en el la tarea
sistema, o inclusión de un modelo de datos normalizado. A menudo existirán varias
opciones que reflejarán diferentes niveles de calidad, por ejemplo, escoger entre
una interfaz de usuario estática o dinámica. Los costes de estas opciones deberán
ser diferentes y reflejarse en las propiedades de la inversión. Estas opciones
deberán reflejarse también en las propiedades funcionales del servicio.
A menudo, el nivel de servicio sólo puede garantizarse en determinadas Indicar los
condiciones relativas a la cuantificación. Deberán indicarse todos los supuestos supuestos
relativos a las condiciones en que se garantiza el nivel de servicio. relativos a la
cuantificación
Tomemos como ejemplo un supuesto acerca del número de llamadas que puede
gestionar un servicio de ayuda. Normalmente un analista del servicio de ayuda que
se encargue de la recepción de llamadas es capaz de atender 35 – 40 llamadas
telefónicas en una jornada de ocho horas. Esto supone que los picos no alcanzan
nunca el doble de la media calculada para un período de varias semanas.

5.2 Planificación de servicios

Actividad Insumo y resultado
1. Análisis de riesgos Insumo:
– descripción del servicio
2. Diseño de la estrategia de prestación del
– plan de adquisición
servicio
Resultado:
3. Planificación de puntos de decisión
– plan de prestación de servicios
Contenido de un Figura 5.5: Actividades y resultados de la planificación de servicios

plan de
prestación de Un plan de prestación de servicios define la descripción de la situación, la
servicios estrategia de prestación del servicio y los puntos de decisión durante una
prestación de servicios. Se ocupa de la instalación del servicio, la ejecución del
servicio y la retirada del servicio que lleva a cabo un proveedor, véase figura 5.6.
La estructura del plan de prestación de servicios se describe en el apartado 3.2.1., y
la plantilla se incluye en el anexo D.7.
Cada plan de entregas puede incluir uno o más planes de prestación de servicios.
Los insumos para las actividades de planificación son la descripción del servicio
(véase apartado 5.1) y el plan de adquisición, que puede incluir requisitos relativos
al plan de prestación de servicios.
Figura 5.6: Ejemplo del nivel de servicio que proporciona un proveedor en una
La instalación y la retirada del servicio son adaptaciones.
Los tres La instalación del servicio puede llevarse a cabo en diferentes contextos:
subprocesos de
una prestación • contratación de un proceso ya existente en el dominio objetivo
de servicios • contratación de un servicio ya existente (posiblemente a un proveedor
diferente)
• contratación de un nuevo proceso.
La retirada del servicio puede llevarse a cabo con diferentes intenciones:

Capítulo 5
• devolver el proceso a la organización del cliente

• contratar un servicio similar a otro proveedor
• suprimir el proceso.
Durante la ejecución del servicio, el nivel de servicio suele mantenerse constante,
aunque también puede producirse algún aumento o disminución del mismo. Las
mejoras del servicio pueden llevarse a cabo en forma de adaptaciones.
5.2.1 Análisis de riesgos

El resultado de un análisis de riesgos es una descripción de la situación del Resultado de un
problema que incluye: análisis de
riesgos
• el resumen del servicio
• los estados inicial y final de la instalación del servicio
• los estados inicial y final de la cancelación del servicio
• la apreciación de la situación (factores de situación y riesgos).
El resumen del servicio es una sinopsis de las propiedades clave del servicio tal y
como se describen en la descripción del servicio.
5.2.1.1 Documentar el estado inicial y el estado final de la instalación del

servicio
El estado inicial de la instalación del servicio puede incluir (según el contexto): Documentar los
estados inicial y
• el proceso/servicio existente final de la
• los elementos operativos sujetos a la ejecución del servicio instalación y la
cancelación
• los elementos descriptivos del servicio de las distintas versiones del servicio
(actual, futura)
• planes/informes del servicio disponibles (véase 3.3.2).
El estado final de la instalación del servicio puede incluir:
• el servicio instalado (obligatorio)
• los elementos operativos sujetos a la ejecución del servicio (obligatorio)
• las descripciones de las distintas versiones del servicio
• planes/informes del servicio (véase 3.3.2).

5.2.1.2 Documentar el estado inicial y el estado final de la cancelación

del servicio
El estado inicial de la cancelación del servicio puede incluir:

• el servicio que se va a cancelar (obligatorio)
• los elementos operativos que están sujetos a la ejecución del servicio
(obligatorio)
• las descripciones del servicio de las distintas versiones del servicio
• planes/informes del servicio (véase 3.3.2).
El estado final de la cancelación del servicio puede incluir (según la intención):
• el futuro proceso/servicio
• los elementos operativos que están sujetos a la ejecución del servicio
• las descripciones del servicio/proceso de las distintas versiones del
servicio/proceso
• los planes/informes del servicio/proceso (véase 3.3.2).
5.2.1.3 Documentar la apreciación de la situación (factores situacionales

y riesgos)
Para analizar las situaciones de los problemas se utilizan los factores situacionales
(tal como se describe en el apartado 4.2.2), del mismo modo que para las
adaptaciones. Así pues, deberán seguirse los siguientes pasos:
• identificar los factores situacionales que son apropiados para los servicios
que se prestan
• determinar los valores de los factores situacionales, y registrar su
justificación
• para cada factor situacional que tenga una alta complejidad e incertidumbre,
registrar los riesgos asociados. La lista de riesgos del apartado 4.2.4 ha sido
adaptada a los servicios, con lo que se obtienen los siguientes riesgos
(consultar también las figuras 4.8 y 4.9):
− requisitos inciertos o inviables
− incertidumbre de las interfaces con otros procesos
− requisitos variables
− costes impredecibles para la organización
− costes impredecibles para el servicio
− falta de participación de los agentes del dominio objetivo (desmotivación
del personal)
− deficiencias de las tareas realizadas externamente
− retrasos en la disponibilidad del servicio
− baja calidad del servicio
− incremento de los costes del servicio (aumento de costes)

Capítulo 5
− problemas de integración del servicio

− deficiencias de las propiedades de calidad (seguridad, fiabilidad, eficiencia,
mantenibilidad, etc.)
− servicio incorrecto
− servicio no aceptado por los agentes
− repercusiones en el negocio del fallo del servicio
− pérdida de control del servicio
− el servicio no funciona
− pérdida de las capacidades y competencias de la organización del cliente
(y vinculación a un único proveedor); este riesgo es propio de los
servicios y no se halla en la tabla original de la figura 4.10.
• Determinar si conviene añadir algún riesgo específico para el tipo de servicio
en cuestión.

5.2.2 Diseño de la estrategia de prestación del servicio

El insumo para el diseño de la estrategia de prestación del servicio es la situación
del problema del servicio.
Los productos son:
• enfoque de la instalación
• enfoque de la cancelación
• enfoque del control del servicio
• contramedidas para reducir riesgos.
5.2.2.1 Documentar el enfoque de la instalación
Opciones de la Para desarrollar un enfoque de la instalación se utilizan los enfoques descritos en el

estrategia de apartado 4.3.2. Las posibles opciones de instalación del servicio son: de una vez,
prestación del incremental y evolutiva. Las opciones de cobertura geográfica son: global y local.
servicio
5.2.2.2 Documentar el enfoque de la cancelación
Para desarrollar un enfoque de la cancelación se utilizan los enfoques descritos en

el apartado 4.3.2. Las posibles opciones de cancelación del servicio son: de una
vez, incremental y evolutiva. Las opciones de cobertura geográfica son: global y
local.
5.2.2.3 Documentar el enfoque del control del servicio
El apartado 4.3, que trata de distintos aspectos del enfoque del control del
proyecto (frecuencia, formalidad, responsabilidades del cliente), puede utilizarse
para caracterizar los enfoques del control del servicio.
Especificar un El control de calidad del servicio es una cuestión clave del control del servicio.
procedimiento Deberá especificarse un procedimiento de medida, al objeto de evitar discusiones
de medida del acerca de si se ha conseguido el nivel de servicio acordado. Para ello se procederá
control de de la manera siguiente:
calidad
• determinar o hacer referencia a métricas que permitan medir cada una de las
propiedades
• definir una escala de valores para cada métrica
• definir un procedimiento de medida objetivo, fiable y eficiente para cada
métrica
• especificar los valores actuales, los valores mínimos aceptables y los valores
deseados, a ser posible para varios momentos futuros.

Capítulo 5
5.2.2.4 Documentar las contramedidas utilizadas para reducir riesgos
En el apartado 4.3.1 se describe un conjunto de contramedidas, algunas de las Tener en cuenta

cuales pueden utilizarse para contrarrestar riesgos identificados en la apreciación contramedidas
de la situación del problema. No obstante, es preciso tener en cuenta también específicas para
contramedidas específicas de los distintos tipos de servicios. los riesgos
inherentes a
prestación del
5.2.3 Planificación de puntos de decisión servicio
El insumo para la planificación de puntos de decisión es la estrategia de prestación
del servicio.
Los productos son:
• secuencia de puntos de decisión
• descripciones de los puntos de decisión
5.2.3.1 Derivar una secuencia de puntos de decisión
En el apartado 4.4 se describe cómo derivar una secuencia de puntos de decisión.

Debe desarrollarse una secuencia separada de puntos de decisión para:
• Instalación del servicio: se trata de un tipo especial de adaptación para el que
pueden utilizarse las recomendaciones del apartado 4.4.
• Ejecución del servicio: la secuencia de puntos de decisión deberá reflejar las Planificar con
opciones seleccionadas del enfoque del control del servicio y las puntos de
contramedidas para reducir riesgos. Normalmente, durante la ejecución del decisión
periódicos para
servicio se repiten periódicamente puntos de decisión de naturaleza similar,
el control del
en los cuales se suelen tomar decisiones relativas al nivel de servicio, mejora servicio
y mantenimiento del servicio. En estos puntos de decisión podrán decidirse
adaptaciones para la mejora del nivel de servicio.
• Cancelación del servicio: se trata de un tipo especial de adaptación para el
que pueden utilizarse las recomendaciones del apartado 4.4.
Posteriormente, estas tres secuencias deberán fusionarse en el plan de prestación
de servicios.
5.2.3.2 Describir los puntos de decisión
Para describir los puntos de decisión deberá utilizarse el formato que se indica en
el apartado 4.4.3.
En cuanto a la instalación y cancelación del servicio, puede utilizarse la
orientación descrita en el apartado 4.4.3, suponiendo que se hayan realizado los
ajustes que precise la especificidad del tipo de servicio en cuestión.
En cuanto a la ejecución del servicio, la finalidad de los puntos de decisión Valorar si se
periódicos es revisar el rendimiento del proveedor, comparándolo con los niveles cumplen las
de servicio especificados, y revisar los requisitos del servicio a fin de valorar si necesidades del
aún cumplen las necesidades del negocio o si precisan modificaciones. Los negocio

entregables que se utilizan como base para estas decisiones son los planes y los
informes de servicio (véase apartado 3.3.2.).
Se recomienda documentar la secuencia y calendario de los puntos de decisión en
un lugar concreto dentro del plan de prestación de servicios, al objeto de facilitar
el mantenimiento, es decir, las descripciones de los puntos de decisión no deberán
incluir información sobre el calendario.

Lista de referencias e Índice de materias
Referencias
[87/95/CEE] Directiva de Normas de la CEE.
[92/50/CEE] Directiva de Servicios de la CEE.
[EM-DC] Euromethod Dictionary.
[EPHOS] European Procurement Handbook for Open Systems,
EPHOS Awareness Office, XCOMS International SA, 5
Rue d’Angoussaart, B-1301, Bierges, Belgique.
[IEEE-610.12] IEEE. Standard Glossary of Software Engineering
Technology. Spring 1990. ANSI/IEEE Std. 610.12 1990.
[ISO/IEC 2382-20] Information Technology – Vocabulary. Part 20: System
Development. First edition 1990-03-01.
[ISO 8402] Quality Management and Quality Assurance – Vocabulary.
Second edition 1994-04-01.
[ISO/IEC 9126] Information Technology – Software Product Evaluation –
Quality Characteristics and Guidelines for their use: First
edition 1991-12-15.
[ISO-LCP] Information Technology – Software Life Cycle Processes.
First edition 1995-08-01.
[ITIL] IT Infrastructure Library, HMSO Books (P9D), St
Crispin’s House, Duke Street, Norwich NR3 1PD
[KSP] Kwaliteit van softwareprodukten, Kluwer
Bedrijfsinformatie B.V., Deventer 1996, ISBN 90-267-
2430-6.


Índice de materias
contract completion process, 19

A
contract completion report, 94, 106
abnormal contract completion, 89 contract change control, 87
acquisition, 15, 30 contract domain, 98
acquisition goal, 16, 32, 33 contract domain deliverables, 96
acquisition goal definition, 32 contract domain properties, 98, 107
acquisition initiation, 18, 30 contract management, 21
acquisition management, 21 contract monitoring, 79
acquisition plan, 16, 35, 56 contract monitoring process, 19
acquisition process, 15, 30 contract status report, 87, 93, 106
acquisition strategy, 16, 38 cost, 138
actors, 127 cost estimation, 71
adaptation, 15 countermeasures, 170, 206
adaptation plan, 28 critical risks, 167
adaptation plan, 22, 28, 69, 99 customer, 16
adaptation planning, 27 customer responsibility, 180
adaptation planning techniques, 148 customer-supplier relationship, 16
adaptation processes, 13
D
adaptation strategy, 28, 53, 63, 191
alternative solutions, 144 data, 127
analytical approach, 175 decision point, 22, 63, 193
animation, 143 decision point deliverable, 98, 106
application software, 122, 128 decision point description, 194, 208
assess situational factors, 85 decision point proposal, 85, 106
assessment of an adaptation plan, 75, 216 decision point report, 89, 106
B decision points, 55, 218, 235
decision points planning, 70
benefit, 138 decisions, 19, 85
business expertise, 23 degree of decomposition, 139
business information view, 126 degree of formality, 142
business needs, 16 degree of specialisation, 139, 140
business process view, 127 deliverable, 24, 63
deliverable type, 97
C
deliverable types, 96
cognitive approach, 175 delivery plan, 22, 60, 63, 69, 80, 99
complexity, 27, 156, 157, 174 description, 175
computer system, 14 description approach, 185, 200
computer system architecture view, 128 description of deliverables, 70, 210
computer system data view, 127 description process, 26
computer system function view, 127 descriptive item, 97, 123
computer system views, 125 descriptive items profile, 210
configuration control, 181 design decision, 196
configuration management, 110 design decisions, 214
configuration management expertise, 23 design of adaptation strategy, 70
considered context, 115, 119 design of service provision strategy, 70
consistency rules between the views, 132 development, 25, 110
construction approach, 178 development approach, 175, 183
construction process, 26 development control, 181
contract, 17, 45, 77, 97, 99
E
contract authority, 22
contract completion, 69, 92 efficiency, 137

evaluation matrix, 74 method bridging dictionary, 216

event, 129 method process model, 205
evolutionary construction, 178
N
evolutionary construction approach, 121
evolutionary installation, 179 network management expertise, 23
evolutionary installation approach, 121
O
experimental approach, 175
expert-driven, 176 one shot construction, 178
one shot installation, 178
F
operational expertise, 23
facilities, 121 operational item, 97, 121
final state, 15, 149, 232 organisation characteristics, 66, 73
financial authority, 23, 64 organisational authority, 23
formal, 142 organisations, 13
formality, 180
P
function, 128
functional properties, 125, 227 participatory, 176
functionality, 137 physical data, 122
plans, 109
G
portability, 137
geographical coverage, 179 problem situation, 27
global installation, 179 problem situations, 232
processes, 13, 127
H
processing units, 128
hardware, 128 procurement, 16, 17
hardware device, 121 project, 20, 71
human-computer interface, 127 project actors, 156
project control, 179
I
project control approach, 179, 188, 201
incremental construction, 178 project control aspects, 179
incremental installation, 179 project domain, 156
informal, 142 project management deliverable profile,
information resource, 13, 126 116
information system, 14 project management deliverables, 109
information system expertise, 23 project plan, 64
information system views, 125 project plans, 110
initial state, 15, 46, 149, 231, 232 project production, 21
installation, 178 project properties, 113, 114, 118, 119
installation approach, 178, 234 project reports, 110
installation process, 26 project structure, 156
investment decision, 196 project task, 156
investment decisions, 212, 213 project technology, 156
investment properties, 226 prototype, 143
IS-adaptation, 14
IS-procurement requirements, 98 Q
quality assurance, 25, 110
L
quality assurance expertise, 23
legal authority, 23, 72 quality control, 181
legal clauses, 72 quality management authority, 23
level of agreement, 141 quality properties, 135, 229
level of detail, 139 quality state, 115, 119, 122
local installation, 179 quality state of a descriptive item, 144
M quantification, 142
maintainability, 137 R
management deliverables, 84, 96, 109 reliability, 137
management of risk, 145 reports, 109

request for proposal, 61, 98 situational factors, 27, 37

requirements analysis, 33, 41 social approach, 176
response, 98 strategy options, 28, 175, 190
retirement approach, 234 sub-system, 150
risk, 28, 138, 145 sub-systems, 154
risk analysis, 27, 37, 38, 63, 70, 147, 148 supplier, 16
risk management, 18, 37 supplier evaluation report, 98
risk management planning, 147 supplier selection, 74
risk management strategy, 38, 40 supplier selection criteria, 65
risk monitoring, 147 system acceptance decision, 196
risks, 232 system acceptance decisions, 215
roles, 22 system coverage, 178
system operation expertise, 23
S
system software, 121, 128
scenario, 143 system version, 122
scope, 138 system/service version, 143
security, 137 systems description, 62
semi-formal, 142
T
senior management, 23
sequence of decision points, 28, 193, 197 target domain, 15, 32, 62, 68, 124, 155
service, 15, 221 target domain deliverables, 82, 97, 120
service control approach, 234 task, 127
service description, 62 technical expertise, 23
service descriptions, 226 tendering, 59
service execution, 29, 117, 231 tendering deliverable, 98
service installation, 29, 230 tendering process, 18, 45
service management deliverable profile, trained actors, 122
119 training and/or migration programmes, 122
service management deliverables, 116 type of a service, 222
service or project authority, 22 typical final state, 47, 49
service or project management, 21 typical initial state, 47, 50
service organisation, 20
U
service packages, 224
service plan, 64, 71, 116 uncertainty, 156, 158, 164, 173
service plans, 116 usability, 137
service provision, 21, 54, 116 user and operator manuals, 122
service provision plan, 22, 29, 69, 99, 230 user expertise, 23
service provision strategy, 29, 63, 234 W
service retirement, 29, 230
simulation, 142 work descriptions, 122
situation description, 217 work practice view, 125, 127
situational approach, 27

Eurometodo v1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Eurometodo v1

Încărcat de

Drepturi de autor:

Formate disponibile

CONSEJO SUPERIOR

Consejo Superior de Informática

MINISTERIO DE ADMINISTRACIONES PÚBLICAS

La presente obra es la traducción al español del documento "Euromethod version

En particular, por lo que se refiere al ámbito de las AA.PP., algunas

Cómo utilizar este libro

Estructura del libro

Capítulo 1 – Presentación de conceptos

Capítulo 2 – El proceso de adquisición

© Proyecto Eurométodo 1996 i

Capítulo – Técnicas de planificación de la adaptación

Capítulo 5 – Descripción y planificación de servicios

ii © Proyecto Eurométodo 1996

• responsable contractual del cliente

En general, las funciones se indican al inicio de cada apartado y se vuelven a

Icono de compra pública

© Proyecto Eurométodo 1996 iii

Texto específico sobre adaptaciones/servicios

Definición Definición del término o concepto

Esta convención no se emplea en el capítulo 1, que contiene un gran número de

iv © Proyecto Eurométodo 1996

La incertidumbre dependerá del tipo de aplicación, aspectos organizativos, la

© Proyecto Eurométodo 1996 v

Las tecnologías evolucionan con rapidez y con ellas aumenta la variedad de

Clarificar el Una adquisición efectiva de un sistema de información y los servicios asociados

Control de las expectativas y de los costes

vi © Proyecto Eurométodo 1996

A través de la consecución de estos objetivos, la Comisión Europea pretende

Ventajas de utilizar Eurométodo

© Proyecto Eurométodo 1996 vii

Al tomar en consideración todo el sistema de información, y no sólo el software,

Formulación más clara de los Mejor comprensión de las necesidades del

Mejor información para controlar los

Ventajas de utilizar Eurométodo

Eurométodo como marco

Eurométodo Uno de los principales obstáculos para conseguir un entendimiento mutuo es la

viii © Proyecto Eurométodo 1996

Eurométodo proporciona un marco en el que describir, utilizar, perfeccionar y

Eurométodo como método

© Proyecto Eurométodo 1996 ix

Eurométodo no se ocupa de aspectos legales ni es un método para el desarrollo

x © Proyecto Eurométodo 1996

© Proyecto Eurométodo 1996 11

3.6.5 Alcance ............................................................................................................ 138

12 © Proyecto Eurométodo 1996

1.1 Organizaciones y sus sistemas de información

1.1.1 Organizaciones y sus procesos

© Proyecto Eurométodo 1996 13

Figura 1.1: Organización y dominio objetivo

1.1.2 Sistemas de información

Sistema de El sistema de información (SI) se define como el aspecto de la organización que

1.1.3 Adaptaciones de sistemas de información

• diversas clases de estudios

1.2.1 Dominio objetivo

1.2.2 Objetivo de la adquisición

Objetivo de la El objetivo de la adquisición viene definido por un conjunto coherente de requisitos

1.2.3 Estrategia y plan de adquisición

Estrategia de La estrategia de adquisición determinará el número y tipos de adaptaciones,

1.2.4 Relación cliente-proveedor

Cliente El proceso de adquisición se gestiona dentro de las relaciones cliente-proveedor. El

16 © Proyecto Eurométodo 1996

Contrato 1 Contrato 2 Contrato 3

Suministrador 1 Suministrador 2 Suministrador 3