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 version1" desarrollado por la Comisión Europea, y no una adaptación de dichodocumento a la situación española y en particular a la legislación nacional sobrecontratos. Su punto de vista es general, esto es, aplicable a cualquier situación decontratación de sistemas y servicios informáticos tanto por empresas del sectorprivado como por organizaciones del sector público, en cualquier lugar de la UniónEuropea.

En particular, por lo que se refiere al ámbito de las AA.PP., algunasconsideraciones y ejemplos del método pudieran no ser conformes con lo previstoen la Ley de Contratos de las Administraciones Públicas o sus normas dedesarrollo. Naturalmente. En estos y en todos los demás casos, los compradorespúblicos deberán atenerse a lo dispuesto en la Ley.

Cómo utilizar este libro

© Proyecto Eurométodo 1996 i


Con este libro se pretende satisfacer las necesidades de un gran número depersonas, tanto las de aquellos lectores que deseen saber más de Eurométodocomo las de quienes precisen una orientación detallada en aspectos concretos deEurométodo.

Teniendo en cuenta esta doble funcionalidad, el contenido del libro sigue un ordenlógico: se describe el marco de Eurométodo, se presentan los conceptos clave y seofrece 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 funcionesasociadas 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 deEurométodo; su concepto, alcance y objetivos en el contexto de la adquisición desistemas de información y servicios asociados.

Índice

El diseño del índice permite que el lector que ya esté familiarizado conEurométodo encuentre de inmediato el tema que desea consultar, al tiempo quepresenta la estructura de Eurométodo a aquellos lectores que desean conocerlamás a fondo.

Capítulo 1 – Presentación de conceptos

Este capítulo presenta los conceptos clave y las funciones que se utilizan enEurométodo, en el contexto de una organización y su sistema de información, demanera 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 estecapítulo se describen a grandes rasgos los principales procesos en que intervienenlos clientes y los proveedores, y se hace referencia a otros apartados del libro queofrecen más información de cada tema.

El capítulo 2 es el punto de partida aconsejado para aquellos lectores quepretendan utilizar Eurométodo de guía en un determinado proceso de adquisiciónde sistemas de información y servicios asociados. Este capítulo permitirá al lectorbuscar en todo el libro, gracias a las referencias a otros capítulos y anexos deinterés.

Eurométodo versión 1

© Proyecto Eurométodo 1996ii

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óndel proceso de adaptación de un sistema de información) y describe con tododetalle 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 secentra en la planificación de la prestación de servicios (es decir, la planificación deun proceso que un proveedor ofrece como servicio).

Anexos

Los anexos contienen información detallada y plantillas que se utilizan al aplicarEurométodo.

Diccionario

El diccionario contiene las definiciones de todos los términos y conceptosutilizados en Eurométodo.

Funciones

Eurométodo identifica dos funciones clave comunes a la organización del cliente ya la del proveedor. La importancia de estas funciones se pone de manifiestosiempre que un cliente y un proveedor se relacionan. Se trata del responsablecontractual y del responsable de proyecto o servicio:

• Un responsable contractual es:la persona o personas con la facultad de resolver o concluir una cuestiónabierta con respecto a un contrato específico. Un responsable contractualrepresenta a la organización del cliente y el otro representa a la organizacióndel proveedor. No es necesario, ni siquiera deseable, que una misma personadesempeñe la función de responsable contractual durante todo el proceso deadquisición.

• Un responsable de proyecto o servicio es:la persona o personas con la facultad de resolver o concluir una cuestiónabierta con respecto a un servicio o proyecto específicos. De nuevo, unresponsable de servicio representa a la organización del cliente y el otrorepresenta a la organización del proveedor. No es necesario, ni siquieradeseable, que una misma persona desempeñe la función de responsable deproyecto o de servicio durante todo el proceso de adquisición.

Dado que estas funciones existen tanto en la organización del cliente como en ladel proveedor, se identifican las cuatro funciones clave siguientes:


© Proyecto Eurométodo 1996 iii

• 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 enlos márgenes, como el del ejemplo que se ofrece a continuación. En este caso lafunción que se indica es la de responsable contractual del proveedor, ya que sedestaca la sección situada en la fila superior (responsable contractual) y la columnade la derecha (organización del proveedor).

SCCC

SuministradorCP SP

CS SS

Cliente

Contrato

Proyecto o provisión deservicios

En general, las funciones se indican al inicio de cada apartado y se vuelven adestacar posteriormente cuando el tema principal del texto cambia. Mediante elsímbolo (þ apartado: título) se hace referencia a otras partes del libro que puedenorientar 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éspara quienes intervienen en compras del sector público, se llama la atención dellector 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 sobreciertos 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 1996iv

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


© Proyecto Eurométodo 1996 v


La necesidad de Eurométodo

La piedra angular de toda organización moderna es la disponibilidad deinformación oportuna, relevante y fácilmente accesible. El aspecto de laorganización que proporciona, utiliza y distribuye esta información, junto con losrecursos organizativos asociados, tanto técnicos como humanos, se denominasistema de información (SI). Todas las organizaciones, sean del sector privado odel sector público, poseen sistemas de información que les ayudan a gestionar susactividades. Un sistema de información puede basarse en documentos impresos, obien estar total o parcialmente automatizado, es decir, informatizado. Estossistemas de información son la clave del éxito y, a menudo, de la supervivencia, demuchas organizaciones.

La dinámica de la vida moderna provoca continuos cambios en las actividadescomerciales de todos los tipos de organizaciones (incluyendo lasadministraciones públicas). Para hacer frente a estos cambios se precisansistemas de información cada vez más potentes y flexibles.

La adquisición de un sistema de información que cubra nuevas necesidades delnegocio no es una tarea trivial. Incluye definir el objetivo de la adquisición,desarrollar una estrategia para su implementación, contratar por partes el objetivode la adquisición, e integrar estas partes en un sistema de información completo yen los procesos de negocio de la organización que realiza la adquisición.

Orientar adecuadamente estos aspectos durante la adquisición aumentasignificativamente la probabilidad de éxito.

Gestión de riesgos

La evolución de la tecnología contribuye a un aumento de las oportunidades, perotambién a un incremento de los riesgos que hay que gestionar.

La ‘complejidad’ y la ‘incertidumbre’ son factores importantes que contribuyena la aparición de riesgos en una adquisición. La nueva tecnología crea nuevasoportunidades, pero también genera nuevos riesgos. No obstante, el principalriesgo potencial reside en los factores humanos.

Un sistema informático puede variar en complejidad, desde un único PC con unaaplicación sencilla e independiente hasta un sistema heterogéneo distribuido quecontenga numerosas aplicaciones complejas que interactúen entre sí.

La incertidumbre dependerá del tipo de aplicación, aspectos organizativos, latecnología utilizada, etc. Las aplicaciones de uso común en numerosasorganizaciones y de fácil comprensión prácticamente no encierran riesgos. Lasaplicaciones nuevas y/o específicas proporcionan una ventaja competitiva, peropueden presentar mayores riesgos.

Los sistemas deinformación sonla clave del éxito

La adquisiciónde un sistema deinformación noes una tareatrivial

Gestionar lacomplejidad y laincertidumbre


© Proyecto Eurométodo 1996vi

Las tecnologías evolucionan con rapidez y con ellas aumenta la variedad desoluciones posibles. Hoy en día los diseñadores de sistemas de información seenfrentan a sistemas distribuidos, interfaces gráficas de usuario, nuevos sistemas dealmacenamiento 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 larealidad virtual y otras nuevas tecnologías que, si bien crean nuevas oportunidades,también generan sus propios riesgos que hay que gestionar.

Cada vez más un sistema de información se percibe como un sistema complejo queincluye aspectos humanos y sociales, donde la tecnología no es más que una partedel conjunto. El principal riesgo potencial reside en estos aspectos humanos; porejemplo, la migración de sistemas heredados tiene complejas implicacionesorganizativas que deben tomarse en consideración.

Entendimiento mutuo

Una adquisición efectiva de un sistema de información y los servicios asociadosrequiere descripciones claras del estado final deseado y de la situación actual. Esimportante que el cliente y el proveedor entiendan del mismo modo la situaciónactual y el sistema de información y los servicios asociados a adquirir.

La apertura del mercado único europeo y el mercado mundial emergente son elresultado de una predisposición política a incrementar el volumen de negociosentre 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 sepodrá alcanzar completamente si se eliminan los obstáculos al entendimientomutuo entre los clientes y proveedores de distintos países. Estos obstáculos sedeben, en parte, a la existencia de gran número de métodos, cada uno con unosconceptos y un vocabulario propios.

La comunicación entre cliente y proveedor se ve dificultada cuando la terminologíautilizada se interpreta de manera distinta por cada uno de ellos.

Para asegurar la introducción de los sistemas modernos y los servicios asociados espreciso que participen muchas personas con diferentes funciones,responsabilidades, experiencias y conocimientos básicos. Una comunicaciónefectiva es esencial para un entendimiento mutuo.

Control de las expectativas y de los costes

A menudo se subestiman los costes de adquisición o mejora de un sistema deinformación y los gastos de mantenimiento. Una razón importante de ello es quelas expectativas tienden a aumentar durante el proceso de producción, a veces deforma inconsciente. El control de tales expectativas precisa una gestión cuidadosade las decisiones que afectan al desarrollo, diseño, construcción e instalación yoperación del sistema de información nuevo o mejorado. El proceso de decisióndebe planificarse y realizarse con cuidado, contando con la intervención del clientey del proveedor.

Gestionar losaspectoshumanos

Clarificar elestado finaldeseado

Unificar laterminología enlascomunicacionesentre cliente yproveedor

Cuidado con lasexpectativas queaumentan deformainconsciente


© Proyecto Eurométodo 1996 vii

Objetivos de Eurométodo

Eurométodo se ha diseñado para ayudar a las organizaciones en la adquisición desistemas de información efectivos y de los servicios asociados en distintassituaciones. Anima a los clientes y proveedores a controlar los costes y los plazosprevistos, gestionar los riesgos y mejorar el entendimiento mutuo.

A través de la consecución de estos objetivos, la Comisión Europea pretendefomentar la apertura del mercado de sistemas de información, mejorar la movilidadde las personas entre los distintos países, facilitar la organización de proyectosinternacionales 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 yservicios de sistemas de información dentro de un mercado internacionalabierto, proporcionando asesoramiento apoyado por un conjunto deconceptos y terminología que utilizarán en las transacciones

• mejorar la adquisición de sistemas de información y servicios, teniendopresente la situación del problema y los riesgos asociados

• proporcionar un marco para la unificación de la terminología de losmétodos.

Destinatarios

Para sacar el máximo partido de Eurométodo, lo mejor es que tanto el clientecomo el proveedor lo utilicen a nivel contractual. Sin embargo, aunque sólo una delas partes comience a utilizarlo, ello ya supone una mejora en la planificación y enla supervisión.

Así pues, quienquiera que esté a cargo de la adquisición u obtención de un sistemade 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 personaldirectivo, con lo que se garantizaría que obtienen la información necesaria paraadoptar decisiones estratégicas y que utilizan el mejor sistema disponible parallevar a cabo la adquisición de manera eficiente.

Los directores de proyectos y servicios deberían utilizar las técnicas deEurométodo cuando proceda, y deberían estar familiarizados con Eurométodo a finde valorar y reconocer las necesidades a nivel contractual.

Los agentes de proyectos y servicios deberían comprender la terminología deEurométodo para evitar malentendidos entre ellos y sus directores.

Ventajas de utilizar Eurométodo

Tanto los clientes como sus proveedores pueden beneficiarse potencialmente deluso de Eurométodo.

Eurométodoayuda agestionar losriesgos

Eurométododebe utilizarse anivel contractual


© Proyecto Eurométodo 1996viii

Al tomar en consideración todo el sistema de información, y no sólo el software,Eurométodo ayuda a proporcionar soluciones adecuadas a las necesidades delnegocio y a los imperativos técnicos y organizativos.

Eurométodo se ha desarrollado para ser utilizado tanto en el sector público comoen el privado.

Ventajas de utilizar Eurométodo

Eurométodo como marco

Uno de los principales obstáculos para conseguir un entendimiento mutuo es lagran diversidad de métodos que utilizan distintos conceptos y terminología. Estosmétodos suelen utilizar un vocabulario que procede de la ingeniería de software yque puede resultar de difícil comprensión para los usuarios del sistema deinformación, los responsables de la adquisición y los responsables contractuales.Para solventar este problema, Eurométodo toma en consideración las adaptacionesy prestaciones de servicios desde el punto de vista de la adquisición, en lugar delpunto de vista de la ingeniería.

Lasadquisiciones desistemas deinformacióndeberánadecuarse a lasnecesidades delnegocio Ventajas para los clientes Ventajas para los proveedores

Formulación más clara de losrequisitos

Mejor comprensión de las necesidades delcliente

Mejora de la gestión de riesgos Visión más clara del sistema deinformación del cliente

Orientación al seleccionar lamodalidad de adquisición másadecuada para una situación concretadel problema

Mayor facilidad para que los clientesaprueben las decisiones claves de diseño

Mejor comprensión de las ofertas delos proveedores

Determinación del enfoque más adecuadopara la realización de un proyecto o laprestación de un servicio

Evaluación más sencilla de las ofertasde los proveedores

Selección de los métodos, técnicas yherramientas adecuadas

Aceptación más sencilla de servicios ysistemas, gracias a una mejorplanificación y definición de losrequisitos

Aceptación más sencilla de servicios ysistemas, gracias a una mejorplanificación y definición de losrequisitos

Mejora del proceso de decisión enrelación con los entregables y servicios

Mejora de la gestión de riesgos asociadosa un proyecto y/o prestación de servicios

Evitar limitarse a un único proveedor Mejor información para controlar lasexpectativas y los costes

Evitar limitarse a un método específico

Mejor información para controlar loscostes

Control más sencillo de lasexpectativas

Eurométodoaplica el puntode vista de laadquisición


© Proyecto Eurométodo 1996 ix

Eurométodo proporciona un marco en el que describir, utilizar, perfeccionar yunificar los distintos métodos, como por ejemplo los métodos de reingeniería deprocesos de negocio, métodos de desarrollo de sistemas de información y métodosde gestión de proyectos y servicios.

Potencialmente cualquier método se puede utilizar junto con Eurométodo en unaadquisición, siempre que se ajuste a la situación. Eurométodo está abierto atécnicas estructuradas, técnicas orientadas a objetos, técnicas de ingeniería deprocesos 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. Undiccionario de enlace permite comprender los tipos de entregables que propone unmétodo, sin haber recibido formación específica acerca de ese método. Ya existendiccionarios de enlace entre varios métodos y Eurométodo. Traducen laterminología específica del método a la terminología de Eurométodo, al tiempoque especifican en qué situaciones son adecuadas las técnicas que propone elmétodo.

Eurométodo proporciona un marco, es decir, un conjunto de conceptos y unaterminologí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 agentesutilizan una gran variedad de métodos y herramientas para tareas como eldesarrollo del sistema de información, aseguramiento de la calidad, gestiónde la configuración y manejo del ordenador

• en el nivel de gestión del servicio o proyecto, los agentes cuentan con elapoyo de métodos y herramientas de gestión de proyectos

• Eurométodo se ha diseñado para ser utilizado a nivel contractual por lagestión de adquisiciones, en especial dentro de la gestión de contratos.

Eurométodo proporciona un método para definir, planificar y ejecutar laadquisición de un sistema de información y los servicios asociados.

Se utiliza para valorar y determinar:

• 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 yla prestación de servicios

• el plan de entregas que describa las relaciones cliente-proveedor a nivelcontractual, incluyendo el intercambio de entregables.

Un marcoabierto parautilizar yunificar métodos

Eurométodo esun método paraser utilizado anivel contractual


© Proyecto Eurométodo 1996x

Eurométodo no se ocupa de aspectos legales ni es un método para el desarrollode un sistema de información ni para la prestación de un servicio.

Capítulo 1Presentación de conceptos

© Proyecto Eurométodo 1996 11

Índice

1 PRESENTACIÓN DE CONCEPTOS............................................................................13

1.1 ORGANIZACIONES Y SUS SISTEMAS DE INFORMACIÓN.......................................................131.1.1 Organizaciones y sus procesos............................................................................131.1.2 Sistemas de información .....................................................................................141.1.3 Adaptaciones de sistemas de información ...........................................................141.1.4 Servicios .............................................................................................................15

1.2 ADQUISICIONES.............................................................................................................151.2.1 Dominio objetivo ................................................................................................151.2.2 Objetivo de la adquisición ..................................................................................161.2.3 Estrategia y plan de adquisición .........................................................................161.2.4 Relación cliente-proveedor .................................................................................161.2.5 Contrato .............................................................................................................171.2.6 Compra...............................................................................................................171.2.7 Modelo del proceso de adquisición .....................................................................181.2.8 Organización de la adquisición...........................................................................201.2.9 El plan de entregas .............................................................................................22

1.3 FUNCIONES EN LAS ADQUISICIONES ................................................................................221.4 ENTREGABLES ..............................................................................................................241.5 PLANES Y PROCESOS DE ADAPTACIÓN .............................................................................25

1.5.1 Procesos dentro de las adaptaciones...................................................................251.5.2 Planificación de la adaptación............................................................................27

1.6 PLANES Y PROCESOS DE LA PRESTACIÓN DE SERVICIOS.....................................................281.6.1 Procesos dentro de la prestación de servicios .....................................................291.6.2 Plan de prestación de servicios...........................................................................29

2 EL PROCESO DE ADQUISICIÓN...............................................................................30

2.1 INICIO DEL PROCESO DE ADQUISICIÓN .............................................................................302.1.1 Definición del objetivo de la adquisición ............................................................312.1.2 Planificación de la adquisición...........................................................................35

2.2 CONDUCCIÓN DE UN PROCESO DE COMPRA......................................................................572.2.1 Licitación............................................................................................................592.2.2 Seguimiento del contrato ....................................................................................792.2.3 Cumplimentación del contrato ............................................................................92

3 ENTREGABLES ............................................................................................................96

3.1 TIPOS DE ENTREGABLES.................................................................................................963.1.1 Entregables del dominio contractual...................................................................963.1.2 Entregables de gestión........................................................................................963.1.3 Entregables del dominio objetivo........................................................................97

3.2 ENTREGABLES DEL DOMINIO CONTRACTUAL...................................................................973.2.1 Entregables de licitación ....................................................................................983.2.2 Entregables de punto de decisión......................................................................106

3.3 ENTREGABLES DE GESTIÓN ..........................................................................................1093.3.1 Entregables de gestión del proyecto..................................................................1093.3.2 Entregables de gestión del servicio ...................................................................116

3.4 ENTREGABLES DEL DOMINIO OBJETIVO.........................................................................1203.5 ELEMENTOS OPERATIVOS.............................................................................................1213.6 ELEMENTOS DESCRIPTIVOS ..........................................................................................123

3.6.1 Perfiles de los elementos descriptivos ...............................................................1233.6.2 Visiones y propiedades funcionales...................................................................1243.6.3 Propiedades de calidad.....................................................................................1353.6.4 Propiedades de la inversión ..............................................................................138


© Proyecto Eurométodo 199612

3.6.5 Alcance ............................................................................................................ 1383.6.6 Nivel de detalle................................................................................................. 1393.6.7 Nivel de acuerdo............................................................................................... 1413.6.8 Grado de formalismo ........................................................................................ 1423.6.9 Cuantificación .................................................................................................. 1423.6.10 Simulación........................................................................................................ 1423.6.11 Identificación de la versión del sistema/servicio ............................................... 1433.6.12 Soluciones alternativas..................................................................................... 1433.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 .................................................................................................. 1454.2 ANÁLISIS DE RIESGOS .................................................................................................. 148

4.2.1 Documentar el estado inicial y el estado final .................................................. 1494.2.2 Valorar los factores situacionales..................................................................... 1544.2.3 Evaluar la incertidumbre y complejidad generales ........................................... 1614.2.4 Analizar la probabilidad de riesgos .................................................................. 1624.2.5 Identificar los riesgos críticos........................................................................... 167

4.3 DISEÑO DE UNA ESTRATEGIA DE ADAPTACIÓN............................................................... 1694.3.1 Selección de contramedidas.............................................................................. 1704.3.2 Análisis de las opciones estratégicas ................................................................ 1754.3.3 Seleccionar las opciones estratégicas ............................................................... 1824.3.4 Analizar las repercusiones de la estrategia....................................................... 191

4.4 PLANIFICACIÓN DE LOS PUNTOS DE DECISIÓN................................................................ 1934.4.1 Derivar la secuencia básica de puntos de decisión ........................................... 1974.4.2 Adaptar la secuencia básica a las contramedidas ............................................. 2064.4.3 Describir los puntos de decisión ....................................................................... 208

4.5 DESCRIPCIÓN DE LOS ENTREGABLES............................................................................. 2104.5.1 Describir perfiles de elementos descriptivos ..................................................... 2104.5.2 Establecer enlaces con los productos del método.............................................. 216

4.6 VALORACIÓN DE UN PLAN DE ADAPTACIÓN................................................................... 2164.6.1 Valorar la descripción de la situación .............................................................. 2174.6.2 Valorar la idoneidad de la estrategia de adaptación......................................... 2184.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 ......................................................................................... 2225.1.1 Identificar el tipo de servicio ............................................................................ 2225.1.2 Descripción de las propiedades de un servicio.................................................. 226

5.2 PLANIFICACIÓN DE SERVICIOS ...................................................................................... 2305.2.1 Análisis de riesgos............................................................................................ 2315.2.2 Diseño de la estrategia de prestación del servicio ............................................ 2345.2.3 Planificación de puntos de decisión.................................................................. 235



1 Presentación de conceptos

Este capítulo presenta al lector los conceptos de Eurométodo, describe el contextoen el que opera Eurométodo y los conceptos clave que determinan el vocabulario yla 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, sinimportar 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 depersonas que posiblemente utilizan máquinas (inclusive ordenadores) y coordinansus esfuerzos de cara a la consecución de ciertos objetivos. Las personas precisaninformación para llevar a cabo sus procesos cognitivos, y las organizacionesprecisan 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 ejecutanunos procesos utilizando (y actualizando) recursos de información (véase figura1.1). Por recursos de información se entiende la totalidad de la información queestá disponible dentro de la organización. Esta información es relevante para laestructura, 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,entregar cierto producto a un cliente sin sobrepasar un plazo y un costedeterminados, 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 entregaconsistirá 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 laorganización, es decir, la consecución de sus objetivos con respecto a su entorno.Suelen ser continuos e incluyen actividades que se repiten periódicamente durantela vida de la organización. Permanecen en el mismo estado estable durante largosperíodos de tiempo, o sólo experimentan ligeros cambios.

Los procesos de adaptación ajustan la organización a los cambios del entorno. Elobjetivo de una adaptación es cambiar la organización y/o estudiar y preparar estecambio. Cada adaptación es un proceso específico con un principio y un final, yrepresenta un estado de transición en la organización, es decir, traslada laorganización de un estado inicial a un estado final en un tiempo determinado. Unaadaptación se define por sus estados inicial y final y por el camino que lleva del unoal otro.

Organización

Recursos deinformación

Proceso

Proceso deestado estable

Proceso deadaptación



Organización

Dominio objetivo

Recursos de información

Procesos

Agentesejecutan

utilizanutilizan

Figura 1.1: Organización y dominio objetivo

1.1.2 Sistemas de información

El sistema de información (SI) se define como el aspecto de la organización queproporciona, utiliza y distribuye información. Por tanto, se trata de un aspecto deun sistema humano, que posiblemente incluye sistemas informáticas y automatizaciertos elementos.

El sistema informático (CS) es la parte automatizada del sistema de información.Puede incluir uno o más ordenadores o periféricos, y software que ejecuta elproceso de datos.

1.1.3 Adaptaciones de sistemas de información

Una adaptación del sistema de información puede ser cualquier tipo demodificación (corrección, perfeccionamiento, mejora, automatización, introduccióno incorporación de un nuevo sistema informático, etc.) de un SI para satisfacer lasnecesidades 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

Sistema deinformación

Sistemainformático



• diversas clases de estudios

El estado inicial de una adaptación del SI es la situación del SI al inicio de laadaptación, más los conocimientos disponibles en ese momento acerca de este SI ylas versiones futuras del mismo.

El estado final de una adaptación del SI es la situación del SI al final de laadaptación, más los conocimientos acerca de este SI y las versiones futuras delmismo que se consiguen al final de la adaptación.

La vida de un SI suele incluir varias adaptaciones, por ejemplo, uno o más estudiosde análisis de cambios1, y uno o más proyectos de descripción, construcción einstalación del sistema.

Eurométodo proporciona los medios para definir, con flexibilidad, los estadosinicial y final de una adaptación, e incluye ejemplos de estados iniciales y finalestípicos.

1.1.4 Servicios

Un servicio es un proceso que una persona o una organización ejecuta para otra.

Más concretamente, en el sector público, el término servicio se utiliza parareferirse a aquellos procesos que representan un valor económico no relacionadocon la producción de bienes materiales. La Directiva de Servicios de la CEproporciona una clasificación de los servicios [92/50/CEE].

Dentro de Eurométodo se abordan dos tipos de servicios, que corresponden a lostipos de procesos que se han mencionado anteriormente: los servicios deadaptación y los servicios de estado estable.

En esta guía, todo ‘servicio de estado estable’ se designará normalmente con lapalabra ‘servicio’, y todo ‘servicio de adaptación’ se llamará ‘adaptación’, comoocurre en la práctica habitual.

1.2 Adquisiciones

El proceso de adquisición (o simplemente adquisición) es el proceso de obtenciónde 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 variosde sus procesos, la parte que se ve afectada se denomina dominio objetivo (véasefigura 1.1). El dominio objetivo es la parte de la organización que se ve afectadapor una adaptación o un servicio. El dominio objetivo puede ser una empresa, unaadministració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 delos conocimientos y de la documentación acerca del sistema existente o del diseño de unfuturo sistema.

Estado inicial

Estado final

Servicio

Servicio deestado estable

Servicio deadaptación

Dominioobjetivo



Las necesidades del negocio pueden formar parte de una estrategia de negocio (porejemplo, el desarrollo de una aplicación estratégica), o pueden derivarse de lasnecesidades de personas interesadas del dominio objetivo (por ejemplo, mejorar losaspectos ergonómicos, funcionalidad o mantenimiento de un sistema informático),o ser el resultado de imperativos externos (por ejemplo, cambios de la normativalegal).

Con la integración de los sistemas informáticos y los procesos de negocio, laadquisición de servicios asociados a sistemas de información se ha convertido enuna tarea compleja. Para definir estas necesidades, la adquisición tiene quecomenzar en el nivel de estrategia del negocio.

1.2.2 Objetivo de la adquisición

El objetivo de la adquisición viene definido por un conjunto coherente de requisitosdel sistema y del servicio que satisfacen las necesidades del negocio seleccionadasen el dominio objetivo. Ejemplos de objetivos de la adquisición: un procesoempresarial perfeccionado, una nueva estructura organizativa, una nueva aplicacióninformatizada, 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, quecomienza con la formulación de una estrategia de adquisición.

1.2.3 Estrategia y plan de adquisición

La estrategia de adquisición determinará el número y tipos de adaptaciones,prestaciones de servicios y contratos que se precisan para lograr el objetivo de laadquisició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.

El plan de adquisición documenta la estrategia de adquisición y define laorganización y la coordinación de las distintas compras.

1.2.4 Relación cliente-proveedor

El proceso de adquisición se gestiona dentro de las relaciones cliente-proveedor. Elcliente es la persona u organización responsable del objetivo de la adquisición, queha decidido contratar prestaciones de servicios o adaptaciones. El cliente puede sero 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.

El proveedor es la persona u organización que suministra un sistema o servicio alcliente.

En las adquisiciones complejas pueden intervenir más de un proveedor, siendocada uno de ellos responsable de un subconjunto de sistemas y servicios. Losproveedores, a su vez, pueden tener subcontratistas que les proporcionen variosservicios y sistemas – véase figura 1.2. En estas circunstancias, el proveedor actúacomo cliente para estos subcontratistas.

Necesidades delnegocio

Objetivo de laadquisición

Estrategia deadquisición

Plan deadquisición

Cliente

Proveedor



1.2.5 Contrato

Un contrato es un acuerdo vinculante con valor legal entre dos partes, o unacuerdo similar dentro de una organización, para el suministro de servicios osistemas. Una organización puede precisar varios contratos para la adquisición delos sistemas y servicios que necesite.

Cliente

Suministrador 2 Suministrador 3

Contrato 1

Subcontratista 1

Suministrador 1

Contrato 2 Contrato 3

Subcontrato 1.1 Subcontrato 1.2

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 sistemasy servicios que se definen en dicho contrato.

En la figura 1.3 se puede observar que un contrato puede regular la compra devarios servicios de adaptación y de estado estable.

Contrato



Compra 1

Adquisición

Contrato 1

Adaptación 1

Servicio 1Adaptación 1.2

Servicio 1.2

Contrato 2Licitación

Adaptación 2.1

Servicio 2.1

Licitación

Compra 2

Figura 1.3: La relación entre adquisición, compra, adaptación y servicio de estadoestable

1.2.7 Modelo del proceso de adquisición

La adquisición comienza como un proceso del cliente y posteriormente incluyeprocesos cliente-proveedor en los que posiblemente intervienen varios proveedoresy contratos. La primera actividad del cliente es el inicio de la adquisición, quepermite definir con mayor precisión el objetivo de la adquisición en base a lasnecesidades del negocio, formular los requisitos de los servicios y sistemasnecesarios, elaborar la estrategia de adquisición y planificar la adquisición en base aun análisis de la situación y al objetivo de la adquisición.

La estrategia de adquisición se elabora en un marco de gestión de riesgos. Unriesgo es la posibilidad de exposición a las consecuencias adversas de eventosfuturos.

La gestión de riesgos es un enfoque sistemático para reducir la probabilidad deriesgos 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óncompleta en un conjunto de compras, cada una de las cuales se ocupa de unsubconjunto de los sistemas y servicios.

Para cada contrato, el proceso de compra es una secuencia de tres procesos:

• El proceso de licitación:está encaminado a seleccionar un proveedor y una oferta para los servicios ysistemas en cuestión, y a acordar con el proveedor seleccionado un contratoque defina las entregas y las responsabilidades de ambas partes. El procesode licitación se compone de los siguientes subprocesos: preparación de la

Inicio de laadquisición

Riesgo

Gestión deriesgos

Proceso delicitación



petición de ofertas, preparación de las ofertas, selección del proveedor,preparación del contrato. Estos subprocesos no tienen por qué ser ejecutadosen el orden de la figura 1.4: pueden coincidir en el tiempo, y puedenproducirse iteraciones de grupos de dichos subprocesos.

• El proceso de seguimiento del contrato:está encaminado a supervisar las prestaciones de servicios y el desarrollo delos sistemas definidos en el contrato, es decir, asegurar que los servicios ysistemas entregados son conformes con los requisitos especificados en elcontrato. Este proceso puede considerarse un proceso de decisión: en ciertosmomentos, el cliente y el proveedor toman decisiones relativas a los serviciosy sistemas entregados, costes, calendario y otras cuestiones contractuales.Un tipo de decisión importante es la aceptación por parte del cliente de unsistema entregado por el proveedor. Es preciso coordinar los diferentescontratos.

• El proceso de cumplimentación del contrato:está encaminado a poner término al contrato. Comprueba que se hanrealizado efectivamente todas las entregas, y que se han cumplido lasobligaciones de ambas partes, y cumplimenta todas las cuestiones pendientes(por ejemplo, el pago, transmisión de la propiedad, garantía) antes decancelar el contrato.

Proceso deseguimiento delcontrato

Proceso decumplimentacióndel contrato



Licitación

LicitaciónLicitación

Seguimiento del contratoSeguimiento del contrato

Seguimiento del contrato

Cumplimentación del contrato

Cumplimentación del contratoCumplimentación del contrato

Compra 1

Compra 2

Compra n

Inicio de laAdquisición

Preparación de lapetición de ofertas Preparación de la

petición de ofertas Preparación de lapetición de ofertasPreparación de

las ofertas Preparación delas ofertas Preparación de

las ofertasSelección delsuministrador Selección del

suministrador Selección delsuministradorPreparación del

contrato Preparación delcontrato

Preparación delcontrato

Ejecución del puntode decisión Ejecución del punto

de decisión Ejecución del puntode decisión

Cumplimentaciónadministrativa Cumplimentación

administrativa Cumplimentaciónadministrativa

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 personaldel cliente y del proveedor desempeñará diferentes funciones en esa organización.

Un equipo organizado de personas, denominado organización de servicios, es elque se hace cargo del servicio contratado. La organización de serviciosproporciona resultados que deberán satisfacer los requisitos formulados por elcliente (véase figura 1.5). Una organización temporal denominada ‘proyecto’ es laencargada de llevar a cabo una adaptación que realiza un proveedor para uncliente.

Proyecto deorganización deservicios



Se suelen definir tres niveles (en las adquisiciones de pequeña envergadura, unamisma persona puede estar a cargo de más de un nivel).

• La función de prestación de servicios o producción del proyecto proporcionaal cliente el servicio o sistemas que precisa, por ejemplo: ingeniería deprocesos de negocio, manejo de un sistema informático, mantenimiento deredes, desarrollo de software. Para ello utiliza recursos (pericia,conocimientos, productos, etc.) del proveedor y a veces del cliente.

• La función de gestión del servicio o del proyecto planifica y supervisa elservicio o la producción. Organiza el equipo, asigna recursos a las tareas ygarantiza que se satisface la calidad requerida dentro del plazo y delpresupuesto pactados.

• La función de gestión de la adquisición controla la adquisición y susdiferentes contratos. Es responsable de los requisitos del servicio y delsistema que se reflejan en la petición de ofertas, las ofertas y los contratos.Controla si los servicios y el sistema satisfacen los requisitos y adopta lasmedidas oportunas en caso contrario. En una adquisición compleja, este nivelpuede desglosarse en gestión de la adquisición y gestión del contrato, ypueden participar distintas personas en la gestión de los diversos contratos.

º

Cliente

Eurométodo

Requisitos

Información

Organización

Servicio/Proyecto

NormativaPlanes

Productos

Servicios

ProductosPericia

Conocimiento

Proveedor 1

Proveedor 2

Adquisición de S.I.

Información

Gestión de laAdquisición(incluida lagestión delcontrato)

Satisfacción derequisitos

ObjetivosRequisitos

Planes

Gestión delServicio/proyecto

Realizacióndel servicioo proyecto

ProductosPericia

Conocimiento

Proveedor 1

Servicio/ProyectoOrganización 2

Figura 1.5: Estructura de una organización de la adquisición

Prestación deservicios

Producción delproyecto

Gestión delservicioGestión delproyecto

Gestión de laadquisición

Gestión delcontrato



1.2.9 El plan de entregas

Un proceso específico de supervisión del contrato se representa como unasecuencia de puntos de decisión. Un punto de decisión es un momento en que elcliente, posiblemente junto con el proveedor, toma decisiones sobre lasadaptaciones y la prestación de servicios. Un punto de decisión se caracteriza porlas decisiones que se toman, las funciones involucradas en estas decisiones y losentregables que se intercambian. Existen entregables de insumo, que sirven decondición necesaria o de base para las decisiones, y entregables de producto, esdecir, informes de puntos de decisión.

El plan de entregas define la relación contractual cliente-proveedor durante elseguimiento del contrato. Consolida los planes de adaptación y planes deprestación de servicios de un contrato, haciendo especial hincapié en lasinterdependencias entre los planes.

El plan de entregas define la secuencia de puntos de decisión del proceso deseguimiento del contrato. Durante el proceso de licitación se producen variasversiones del plan de entregas. En la petición de ofertas se da un plan de entregas alos 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 funcionesclave que adquieren relevancia siempre que un cliente y un proveedor serelacionan. Estas funciones son las de responsable contractual y responsable deproyecto o de servicio:

• un responsable contractual es:la persona o personas con la facultad de resolver o concluir una cuestiónabierta con respecto a un contrato específico. Un responsable contractualrepresenta a la organización del cliente y otro a la organización delproveedor. No es necesario, ni siquiera deseable, que la misma persona actúecomo responsable contractual durante todo el proceso de adquisición.

• un responsable de proyecto o de servicio es:la persona o personas con la facultad de resolver o concluir una cuestiónabierta con respecto a un servicio o proyecto específicos. De nuevo, unresponsable de servicio representa a la organización del cliente y otro a laorganización del proveedor. No es necesario, ni siquiera deseable, que lamisma persona actúe como responsable de proyecto o de servicio durantetodo el proceso de adquisición.

El comportamiento de estos tipos de función clave se ve afectado por la imposiciónde 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 insumosrelativos a la dirección organizativa, o aportar la pericia concreta que se precisa enel proceso de adquisición. Estos otros tipos de funciones son los correspondientesa los responsables organizativos y la pericia operativa, que se encuentran en lasorganizaciones de los clientes y de los proveedores:

Punto dedecisión

Plan de entregas



• Un responsable organizativo es:la persona o grupo de personas con la facultad para resolver o concluir unacuestión abierta en relación con los requisitos estratégicos de laorganización. Así pues, en un nivel determinado, cualquier decisión queadopte un responsable contractual puede verse afectada por variosresponsables organizativos de su organización. En consecuencia, uno de losresponsables organizativos puede imponer una decisión al responsablecontractual. Son ejemplos de responsable organizativo: alta dirección,responsable financiero, responsable jurídico, responsable de gestión decalidad.

• Una pericia operativa es:la persona o grupo de personas que desempeñan una tarea o actúan comocreadores de opinión en base a su pericia, cualificación o conocimientosrelativos a un tema en concreto. Cuando realizan su trabajo, los responsablesde un proyecto/servicio utilizan varios recursos especializados existentes ensus organizaciones, es decir, utilizan pericia operativa. Son ejemplos depericia 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, periciaen 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 periciaque precisan proveedor y cliente, los requisitos pueden ser distintos para lasorganizaciones de uno y otro.

Las funciones que identifica Eurométodo sirven para representar a los responsablesy a sus responsabilidades en una adquisición, además de las cualificaciones y losconocimientos que proporcionan. En una adquisición concreta puede ser una únicapersona o un grupo de personas (en especial, la pericia operativa suele veniraportada por un grupo de personas, por ejemplo el equipo del proyecto) quiendesempeñe cada una de las funciones. En ocasiones, una única persona desempeñadiversas funciones; por ejemplo, una persona que gestiona el trabajo del proveedorpuede, por tanto, desempeñar funciones de responsable de servicio y participar almismo tiempo en el trabajo aportando pericia operativa.



Pericia operativa

Responsables de la

Organización

- Alta dirección

- Responsable financiero

- Responsable jurídico

- Responsable de gestión de calidad

Responsabledel contrato

del cliente

Responsabledel contrato

del proveedor

Responsable delservicio/proyecto

del cliente

Responsable delservicio/proyecto

del proveedor

Apoya

- Alta direccion

- Responsable financiero

- Responsable jur¡dico

- Responsable de gestión de calidad

Responsables de la

Organización

- Pericia operativa en: . Sistema de información . Calidad . Gestión de configuración . Operación del sistema . Etc.

Pericia operativa

- Pericia operativa en: . Sistema de información . Calidad . Gestión de configuración . Operación del sistema . Etc.

Apoya

Figura 1.6: Funciones de una adquisición

1.4 Entregables

Un entregable es un producto que se intercambia entre el proveedor y el clientepara satisfacer una determinada finalidad en una adquisición.

Los entregables tienen que definirse perfectamente y evitar ambigüedades.

Eurométodo clasifica los entregables en distintos tipos y define un conjunto depropiedades para cada uno de estos tipos (véase capítulo 3). Estas propiedades seutilizan para caracterizar los entregables que se precisan, con independencia de unmé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 elproceso contractual de la compra de un sistema de información

• entregables de gestión, que se utilizan para planificar y controlar proyectos yprestaciones de servicios

• entregables del dominio objetivo, que consisten en sistemas o documentosrelativos al dominio objetivo.

Entregable



Entregable

Entregabledel dominiodel contrato

Entregablepara la

licitación

Entregablede punto de decisión

Entregabledel dominio

objetivo

Elementooperativo

Elementodescriptivo

Entregablede gestión

Plan Informe

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 elcontrol jerárquico (véase figura 1.5), que considera la organización como unconjunto de procesos que cooperan para lograr los objetivos de la adaptación.

Esta visión se utiliza para elaborar modelos organizativos y corresponde a losprocesos que se describen en [ISO/LCP]. Algunos de estos procesos sonespecialmente relevantes para la relación cliente-proveedor, ya que afectandirectamente a los entregables y se utilizan para definir las opciones de la estrategiade 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:encaminado a desarrollar los entregables que precisa una adaptación.

• aseguramiento de la calidad:consiste en todas las actividades sistemáticas y planificadas que se precisanpara 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 controldel desarrollo y el control de calidad.

Desarrollo

Aseguramientode la calidad



Otro proceso que afecta directamente a los entregables es la gestión de laconfiguración, una disciplina que utiliza la dirección y supervisión técnica yadministrativa para identificar y documentar las características funcionales y físicasde 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 yverificar el cumplimiento de los requisitos especificados [IEEE-610.12]

Para una relación completa de los procesos, el lector puede consultar la norma ISOsobre Procesos del Ciclo Vital [ISO-LCP].

Desarrollo

El desarrollo de un SI según los requisitos del cliente abarca tres procesos: unproceso 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, elsistema informático).

• Proceso de descripción:encaminado a diseñar un sistema que satisfaga los requisitos utilizandodescripciones, las cuales pueden basarse en un lenguaje natural, modelos oprototipos.

• Proceso de construcción:encaminado a realizar y probar el sistema, cuando éste aún se considera unartículo artificial que todavía no es operativo.

• Proceso de instalación:encaminado a poner en funcionamiento el sistema, es decir, a hacer que laorganización del dominio objetivo migre al uso del sistema.

Para realizar un sistema o subsistema pueden ser necesarias varias versiones: eldesarrollo de cada versión se produce tras un ciclo vital típico, que aparecerepresentado esquemáticamente en la figura 1.8. Esta figura muestra los diferentesestados 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 sobreProcesos del Ciclo Vital del Software [ISO-LCP].

Algunos métodos de desarrollo de SI proponen un modelo de proceso (porejemplo, modelo en cascada) basado en una secuencia de fases que corresponden aldiseño, construcción e instalación. Estas fases forman la base para la planificaciónde las adaptaciones de SI. Desafortunadamente, estos modelos de fases handemostrado ser impracticables en situaciones complejas e inciertas. En la mayoría

Gestión de laconfiguración

Proceso dedescripción

Proceso deconstrucción

Proceso deinstalación



de las adaptaciones, los tres procesos se ejecutan en paralelo, con picos deactividad 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 aldefinir 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 lacreación del plan de adaptación (véase capítulo 4) y se utilizan dentro del procesogeneral de adquisición.

El enfoque situacional

En Eurométodo, para seleccionar la estrategia se utiliza un enfoque flexible para laresolución de problemas denominado enfoque situacional. Este enfoque estáencaminado a mejorar la efectividad del proceso de adquisición, adaptándolo acada situación del problema. Un proceso de adquisición adaptado es aquél quemaximiza las posibilidades de lograr el éxito en la adaptación, al tiempo queminimiza los riesgos y los costes.

Situación del problema(necesidad de adaptación

de un sistema deinformación)

Estrategia de gestión de riesgos

determina

se adapta a

Figura 1.9: La estrategia de gestión de riesgos depende de la situación delproblema

En el enfoque situacional, la estrategia de gestión de riesgos y los planes deadaptación se adaptan a la situación, a su complejidad e incertidumbre, ycontribuyen a la reducción de los riesgos en dicha situación.

En un enfoque situacional es preciso valorar las propiedades de una situación delproblema, calcular sus consecuencias posibles y proponer estrategias adecuadas(véase figura 1.9). Estas estrategias ayudan a reducir los riesgos inherentes a lasituación.

Análisis de riesgos

Las propiedades relevantes de la situación del problema a la hora de determinar laestrategia más adecuada para la resolución del problema se denominan factoressituacionales.

Los valores de los factores situacionales dependen de la complejidad y lasincertidumbres 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ónpuede alcanzar tres niveles: complejidad o incertidumbre alta, baja o media.

Enfoquesituacional

Factores desituación

Complejidad

Incertidumbre



Los valores atribuidos a cada uno de los factores de situación se utilizan paraidentificar los riesgos. A partir de la identificación de los riesgos es posibledeterminar las estrategias más adecuadas.

La estrategia de adaptación

Las adaptaciones tienden a ser complejas, por lo que se requiere una planificacióncuidadosa para garantizar un resultado favorable. Los planes son necesarios paragestionar los proyectos y predecir los costes, pero para diseñar un plan adecuadoes preciso determinar una estrategia apropiada.

La estrategia de adaptación es el enfoque que pretende conseguir los objetivos deuna adaptación, al tiempo que gestiona de manera eficaz los riesgos inherentes acierta situación del problema.

La estrategia para una adaptación en concreto sirve de orientación para eldiseño de los planes y la selección de los métodos que se van a utilizar para esaadaptación.

Opciones estratégicas

Eurométodo proporciona recomendaciones (heurísticas) para la selección de lasopciones 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 puedenutilizar para determinar una estrategia de adaptación o para valorar si unaestrategia se adapta a la situación del problema.

Secuencia de puntos de decisión

La secuencia de puntos de decisión para un proyecto en particular depende de laestrategia de adaptación que se haya elegido. Eurométodo propone varias plantillasde secuencias de puntos de decisión para diferentes opciones estratégicas. Estasplantillas pueden servir de ejemplos que pueden volver a utilizarse al diseñar el plande adaptación para un proyecto en concreto.

Eurométodo se centra en las decisiones y los entregables, pero no establecedirectamente las actividades a ejecutar ni las técnicas a utilizar. De este modo sepreserva la ventaja competitiva de un método concreto que ofrezca unproveedor para el desarrollo del SI.

Plan de adaptación

Un plan de adaptación es un plan para una adaptación singular que se lleva a cabodentro de la compra de un SI. Define la situación del problema, incluyendo elestado inicial y el estado final de la adaptación, la estrategia de adaptación, lasecuencia 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 planificarsedentro del plan de prestación de servicios.

Riesgos

Estrategia deadaptación

Opcionesestratégicas

Heurísticas parala estrategia

Secuencia depuntos dedecisión

Plan deadaptación



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 elproveedor al cliente, a diferencia de los procesos de instalación del servicio yretirada del servicio, que se emprenden a modo de adaptaciones en una únicaocasión, sin que exista continuidad.

La naturaleza de la instalación del servicio puede variar considerablemente entre unservicio y otro. Las cuestiones importantes son la situación de conocimiento acercade los sistemas y servicios actuales y su anterior estado, y la fase en que tienenlugar 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 unaadaptación separada, denominada retirada del servicio. El objetivo de la retiradadel servicio es anular la responsabilidad del proveedor sobre la prestación delservicio. Si el proveedor tiene que devolver a los clientes (o a otro proveedor quese 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ínimamenteafectados. No obstante, a veces el servicio simplemente se suprimirá, si deja de sernecesario.

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 únicoservicio o de un grupo de servicios asociados dentro de la compra de un sistema deinformación. Define el estado inicial y el estado final de la instalación del servicio yde la retirada del servicio, la estrategia de prestación del servicio, la secuencia depuntos de decisión y los entregables durante el seguimiento del contrato.

S

Ejecución delservicio

Instalación delservicio

Retirada delservicio

Plan deprestación deservicios



2 El proceso de adquisición

Este capítulo contiene orientaciones en torno al proceso de adquisición. Deberánleerlo los responsables contractuales y los responsables de proyecto del cliente ydel proveedor. Los lectores que ya estén familiarizados con Eurométodo puedenabordar 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 deobtención de un sistema o servicio, o cualquier combinación de ambos.

La adquisición comienza como un proceso del cliente al que posteriormente siguenvarios procesos cliente-proveedor que posiblemente incluyen varios proveedores yvarios contratos. La primera actividad del cliente es el inicio de la adquisición, queconsiste en definir con más precisión el objetivo de la adquisición en base a lasnecesidades del negocio, establecer los requisitos de los servicios y sistemas que seprecisan, elaborar la estrategia de adquisición y planificar la adquisición en base aun 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 totalidadde la adquisición en un conjunto de compras, cada una de las cuales se ocupa de unsubconjunto 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 figura1.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 procesoque el responsable contractual del cliente ejecuta en unaadquisición. Consiste en la definición del objetivo de laadquisición y la planificación de la adquisición, véase figura2.1. El resultado final es un plan de adquisición que refleja una estrategia deadquisición y un claro entendimiento de las necesidades de sistemas y servicios quedefinen el objetivo de la adquisición.

En la práctica, la planificación de la adquisición revela siempre un cierto grado deimprecisión en el objetivo de la adquisición, que precisa un análisis más detalladode la adaptación y de los requisitos del servicio. Por tanto, se produce unainteracción continua entre la definición del objetivo de la adquisición (análisis delos requisitos) y la planificación de la adquisición.

La viabilidad, programa y costes de la adquisición afectarán al propósito delobjetivo de la adquisición: ésta es otra característica de la interacción entre la

CC SC

CPCS

SPSS

Interaccionesentre el análisisde los requisitosy laplanificación dela adquisición

Capítulo 2El proceso de adquisición


definición del objetivo de la adquisición y la planificación de la adquisición. Lafigura 2.1 ilustra estas interacciones.

Definición del objetivode la adquisición

Planificación de laadquisición

Inicio de la adquisición

Necesidades del negocioDefinición aproximada delobjetivo de la adquisición

Objetivo de la adquisición(requisitos de sistemas y

servicios)

Plan de adquisición

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ásprobable es que una adquisición mal planificada fracase. Sin embargo, es posibleque incluso un buen plan experimente cambios durante el proceso de adquisición.Hasta el propio objetivo puede modificarse durante este proceso. Por tanto, elcliente tendrá que garantizar una gestión rigurosa de la versión del objetivo y delplan de adquisición durante todo el proceso de adquisición.

En situaciones complejas e inciertas, el inicio de la adquisición es una tareacomplicada que no puede llevarse a cabo como una secuencia estricta deactividades. La secuencia de actividades descrita a continuación es un ejemplo.

2.1.1 Definición del objetivo de la adquisición

Objetivo: Entender de forma suficientemente clara los requisitos de los sistemas yservicios que conforman el objetivo de la adquisición.Insumos: Necesidades del negocio, definición aproximada del objetivo de laadquisiciónActividades: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

Las actividadesno se realizan enuna secuenciaestricta



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 conjuntocoherente de requisitos de sistemas y servicios derivado de las necesidadespatentes del negocio y del objetivo preliminar de la adquisición, previo al inicio dela adquisición. Los atributos importantes del objetivo de la adquisición que sevalorarán son: intereses, interesados, costes y beneficios.

La definición aproximada del objetivo de la adquisición puede derivarse, porejemplo, 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 delcliente al definir el objetivo de una adquisición.

2.1.1.1 Definir el dominio objetivo (posiblementeidentificar subdominios)

El dominio objetivo de la adquisición (véase apartado 1.2) tieneque definirse con precisión. Una definición incorrecta del mismopuede 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 dominioobjetivo formalmente definido.

A En el caso de una adaptación (por ejemplo, una adaptación del sistema deinformación), puede que resulte difícil trazar los límites de la zona de repercusiónde 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 debencontratarse. 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 eiteraciones de las mismas.

Definir eldominio objetivocon precisión



Si el dominio objetivo es complejo, vale la pena desglosarlo en subdominios, queposteriormente pueden utilizarse para desglosar la adquisición en partes máspequeñas y sencillas de gestionar.

Si la definición del dominio objetivo no es suficientemente precisa, se recomiendallevar a cabo un análisis de las necesidades, véase la siguiente actividad.

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 suficienteantes del inicio de la adquisición. La definición del objetivo de la adquisición debeidentificar los entregables y servicios necesarios y definir sus requisitos:

• 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 sersuficiente. Muchas veces el cliente se da cuenta de que los requisitos de lossistemas y servicios son insuficientes para determinar los costes, beneficios yriesgos de la adquisición. También pueden ser insuficientes para la planificación dela 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 presentensus ofertas.

Cuando es preciso definir con mayor claridad el objetivo de la adquisición, serecomienda realizar un análisis de requisitos utilizando un método apropiado paraello, por ejemplo un método de reingeniería de procesos de negocio o un métodode 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 quepueda contemplar el responsable contractual. Así pues, cualquier modificación delalcance deberá ser gestionada al nivel de alta dirección de la organización. Enprimer lugar habrá que reducir los riesgos, véase planificación de la adquisición. Sifalla algún medio de reducción de riesgos, probablemente será necesario revisar laestrategia del SI y que en el nivel de alta dirección se tome decisión de revisar elobjetivo 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. Espreciso hacer hincapié en que la incertidumbre de los requisitos de sistemas yservicios siempre da lugar a unas estimaciones poco fiables. Puede que ladefinición aproximada del objetivo de la adquisición ya incluya una aproximación alos costes y beneficios, aunque si es preciso éstos deberán analizarse ydocumentarse con mayor profundidad mediante este proceso.

Pueden utilizarsesubdominiospara desglosar laadquisición enpartes mássencillas degestionar

Definir lasnecesidades conprecisiónsuficiente

Experimentarcon el nivel dedetalle de losrequisitos

La modificacióndel alcance segestiona en elnivel de altadirección

Evaluar loscostes ybeneficios



Los beneficios dependen principalmente de los requisitos de los sistemas yservicios y de su fecha de entrega. Es preciso identificar todos los beneficios,incluyendo los que no se pueden cuantificar. En la medida de lo posible, habrá queevaluar los beneficios en términos financieros o en términos cuantificablesutilizando unidades. La evaluación de los beneficios debe considerarse unainversión de la organización del cliente y basarse en los métodos y prácticasdisponibles. La identificación de los beneficios también puede basarse en analogíascon adquisiciones similares en organizaciones similares.

Los costes dependerán, además de otros factores, de los requisitos de sistemas yservicios y de la estrategia de adquisición, véase Planificación de la adquisición.

Es importante identificar todos los costes relacionados con la adquisición y no sólolos relativos a la compra de soportes físicos y al desarrollo de soportes lógicos.Otros ejemplos de costes son: gestión de la adquisición, gestión del proyecto y delservicio, 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 lanorma ISO sobre Procesos del Ciclo Vital [ISO-LCP] puede utilizarse como listade comprobación de las actividades que pueden plantearse en una adquisición.

2.1.1.4 Analizar los intereses y a los interesados

Los interesados son aquellos agentes a quienes afecta la adquisición y quedeterminarán el éxito o el fracaso de la misma. Estos agentes deben seridentificados y sus intereses satisfechos. Es preciso clarificar y anunciar losbeneficios de la adquisición. Si un agente no percibe ningún beneficio es probableque mantenga una actitud negativa frente a la adquisición.

Puede realizarse un análisis para identificar los lados fuertes, los puntos débiles, lasoportunidades y las amenazas de la adquisición para cada agente (lo que en inglésse denomina un análisis SWOT). Éste es un importante insumo del análisis deriesgos.

Considerar unaadquisicióncomo unainversión

Identificar loscostes de todoslos procesosnecesarios

Identificar yanunciar losbeneficios atodos losinteresados



2.1.2 Planificación de la adquisición

Objetivo: Definir una estrategia de adquisición adaptada a la situación, planificarlos principales puntos de decisión de la adquisición y establecer la organización de laadquisición.

Insumos: Definición del objetivo de la adquisición (requisitos del sistema y delservicio).

Actividades:

1. Determinar los escenarios generales de las adaptaciones y prestaciones deservicios.

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 laadquisició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 eiteraciones de las mismas.



La planificación de la adquisición comenzará por determinar los escenariosgenerales de las adaptaciones y del plan de prestación de servicios, para analizarposteriormente los riesgos y diseñar una estrategia de adquisición en el marco de lagestión de riesgos y, finalmente, planificar los principales puntos de decisión de laadquisición y establecer la organización de la adquisición.

Las actividades descritas en la figura 2.3 las lleva a cabo el responsable contractualdel cliente al elaborar un plan de adquisición.

2.1.2.1 Determinar los escenarios generales de las adaptaciones y lasprestaciones de servicios

Una vez se ha definido el objetivo de la adquisición (requisitos de los sistemas yservicios, costes, beneficios, etc.), el responsable contractual del cliente tiene queplanificar las entregas de las adaptaciones y prestaciones de servicios a nivel global.Los escenarios globales de las adaptaciones y del plan de prestación de serviciosdependen de las prioridades y las dependencias entre las entregas.

Estas dependencias pueden ser:

• técnicas (por ejemplo, puede que sea preciso adquirir soportes físicos antesde la instalación del software)

• funcionales (por ejemplo, es necesario desarrollar un SI de gestión del clienteantes que una base de datos que proporcione estadísticas acerca de clientes)

• relativas a la reutilización (por ejemplo, el desarrollo de objetos reutilizablesdeberá preceder al desarrollo de sistemas que los van a utilizar).

Las prioridades pueden ser:

• estratégicas (por ejemplo, cierta aplicación proporcionará una ventajacompetitiva)

• económicas (por ejemplo, una adaptación del sistema de informaciónreducirá los costes operativos de una función)

• políticas (por ejemplo, cierto departamento se encuentra en una posición másfuerte 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ánal diseñar la estrategia de adquisición, para garantizar que el plan de adquisicióntenga 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 laadquisición.

Definición Un riesgo es la posibilidad de exposición a las consecuenciasadversas de sucesos futuros.

Los factores situacionales son aquellas particularidades de la situación que generanriesgos y que deben tenerse en cuenta al diseñar la estrategia de adquisición.

Elaborar losescenarios deacuerdo con lasprioridades y lasdependenciasentre las entregas

Analizar lasituació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 (þ 5.2.1.3: Documentar la apreciación de la situación) S

Puede que algunos de estos factores situacionales no sean relevantes durante elinicio de la adquisición, cuando sólo se toman en consideración las cuestiones másestratégicas: probablemente adquieran relevancia cuando se planifiquen con mayordetalle adaptaciones específicas y prestaciones de servicios durante los procesos delicitación. En ocasiones, los factores situacionales sólo se pueden valorar bajociertos supuestos, como por ejemplo la disponibilidad de tecnología de desarrollo ola capacidad del equipo de proyecto. La situación cambiará con el tiempo y puedeque también haya que cambiar los supuestos, por ejemplo habrá que volver avalorar la capacidad del equipo de proyecto cuando se seleccione la tecnologíautilizada y las modalidades de adaptación. Así pues, será necesario repetir elanálisis de riesgos periódicamente en el transcurso de la adquisición.

Eurométodo proporciona orientaciones para evaluar la probabilidad de riesgos,pero no para valorar la magnitud de su impacto negativo (consecuencias adversas),que está fuertemente relacionada con la naturaleza y especificidad de laorganización del dominio objetivo. La magnitud del impacto negativo debevalorarse desde una perspectiva de negocio: supervivencia, funcionamientoefectivo y evolución de la organización del dominio objetivo. En algunos casos, larepercusión se puede valorar en términos económicos (costes, oportunidadesperdidas, etc.).

A (þ4.2.4-5: Analizar la probabilidad de riesgos, Identificar los riesgos críticos)A

S (þ 5.2.1.3: Documentar la apreciación de la situación) S

El análisis de riesgos es una parte de la gestión de riesgos, como muestra la figura2.4.

El análisis deriesgos deberáadaptarse a lasituación yreiterarsedurante laadquisición

Identificar laprobabilidad y elimpacto de losriesgos



Análisis de lasituación

Factoressituacionales

Probabilidad deriesgos

Análisis de Riesgos

Situación

Análisis de impacto

Otras opciones dela adquisición

Seleccionar otrasopciones de la

adquisición

Estrategia deprovisión de

servicios

Seleccionar laestrategia deprovisión de

servicios

Estrategia deadaptación

Seleccionar laestrategia de la

adaptación

Contramedidaspara los factores

situacionales

Seleccionarcontramedidas para

los factoressituacionales

Seleccionaropciones

Diseñar la estrategia de gestión de riesgos

Identificación deriesgos

Probabilidad eimpacto de los

riesgos

Figura 2.4: Análisis de riesgos y diseño de la estrategia de gestión de riesgosdentro 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 lagestión de riesgos y el seguimiento de riesgos. El tema del análisis de riesgos ya seha tratado anteriormente. Un plan de gestión de riesgos deberá reflejar unaestrategia de gestión de riesgos que represente la selección entre diferentesopciones 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 degestió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 opcionesdisponibles para la gestión del riesgo. No todas las opciones están abiertas para elresponsable contractual del cliente, sino que algunas pueden estar sometidas aimperativos y políticas a nivel organizativo. Por ejemplo, las administracionespúblicas tienen que aplicar los reglamentos nacionales e internacionales en materiade compras públicas.



La figura 2.5 presenta los distintos tipos de opciones de la estrategia deadquisición. El texto subsiguiente proporciona orientación acerca de las diferentesopciones. La figura 2.5 indica los niveles facultados para seleccionar las distintasopciones: niveles de organización, adquisición, contrato, proyecto/servicio.

Nivel de gestión

Opción de gestión de riesgos

Organización Adquisición Contrato Proyecto/Servicio

1 Cambiar los factores de situación x x o o

Cambiar o puntualizar losrequisitos

x x x x

Estrategia con respecto a lasnormas

x x

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

4 A Comprar o desarrollar x x o

Enfoque de la instalación delsistema

x x

Enfoque de la construcción delsistema

x x

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 delservicio

x x x

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 aquellaspueden estar abiertas a una decisión4.

Por regla general, el nivel de gestión podrá tomar decisiones relativas a una opciónsi 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 enmuchas organizaciones. Una ‘o’ indica que en algunas organizaciones esa opción puedeseleccionarse 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 nivelapropiado.



Por ejemplo, un proyecto sólo podrá tomar decisiones relativas a una opción si lasconsecuencias de estas decisiones no afectan a otros proyectos. Si sucede que espreciso tomar decisiones relativas a una opción, y no se está en el nivel apropiadopara ello, probablemente será el síntoma de que la adquisición se encuentra ante ungrave problema.

Tomando como insumos los escenarios de planificación y el análisis de riesgos, sepueden elaborar varios escenarios estratégicos, cada uno de los cuales dará comoresultado un conjunto de opciones seleccionadas. El responsable contractual delcliente 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 opcionesseleccionadas son suficientes para reducir los distintos riesgos, y si son coherentesentre sí. Normalmente, una opción contempla varios riesgos (por ejemplo, unenfoque de instalación evolutivo contempla la mayoría de riesgos relativos a laincertidumbre de la situación). Para cada estrategia se recomienda confeccionaruna matriz que relacione los riesgos identificados con las opciones seleccionadasque los abordan (véase figura 2.6) y comprobar que se han abordado todos losriesgos. Las opciones pueden conllevar sus propios riesgos, los cuales deberán seranalizados (probabilidad y repercusión) e incluidos en la matriz.

Opción

Riesgo

Opción 1 Opción 2 Opción 3 Opción 4 …

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

Esta matriz resume la estrategia de gestión de riesgos.

Los escenarios estratégicos deberán considerarse a la luz de su eficiencia, suscostes y el retraso en obtener resultados. Seguidamente se selecciona la estrategiamás adecuada de gestión de riesgos como base de la planificación y organizaciónde la adquisición.

A continuación se explican las diferentes opciones y se formulan algunasorientaciones de cara a su selección.

Seleccionar lasopciones

Comprobar si lasopciones reducenlos riesgos y sucoherenciaglobal



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

El análisis de la situación puede revelar factores situacionales cuyos valoresindiquen un alto grado de incertidumbre o complejidad. Puede que algunos deestos factores sean difíciles de cambiar por ser inherentes al problema. Noobstante, puede que exista alguna posibilidad de mejorar otros factores antes deiniciar una compra. En el capítulo 4 figura una lista de las posibles medidas paracambiar valores específicos de factores situacionales. Las explicaciones quefundamentan los valores otorgados a los factores situacionales pueden reflejar talesposibilidades de mejora.(þ 4.3.1: Seleccionar contramedidas)

Ejemplo • Formación de las personas que participarán en laadaptación del SI como agentes del mismo, si se consideraque su capacidad o motivación son bajas.

• Uso de asesoría externa si se considera que la capacidad delos agentes del SI es baja y no hay posibilidad demejorarla.

Opción: Decidir el cambio o puntualización de los requisitos antes de lalicitación

Los requisitos se pueden puntualizar o modificar en distintos niveles de gestión, enfunción de los siguientes criterios: el nivel de detalle del requisito en cuestión, elalcance de la repercusión de la modificación de los requisitos y el nivel estratégicodel requisito en cuestión (por ejemplo, se puede decidir acerca de los requisitosergonómicos en el nivel de proyecto, o adoptar una decisión al respecto en el nivelorganizativo, si ello se considera apropiado desde un punto de vista estratégico).

En el nivel de adquisición, si se considera que los requisitos del sistema y delservicio no son suficientes para realizar la adquisición porque introducen en elproceso una incertidumbre ingestionable, podrá llevarse a cabo un análisis másestricto de los requisitos antes de la licitación. Además de eliminar laincertidumbre, este análisis mejorará las descripciones de los servicios o los estadosiniciales de cualquier adaptación posterior.

S Puede iniciarse una adaptación con la finalidad de producir descripciones de losservicios antes de solicitar ofertas de prestación de servicios. El propósito deproducir descripciones de los servicios es:

• comprender el proceso/servicio actual

• entender perfectamente el tipo de servicio que se solicita, los motivos paracontratar 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, debidoa la falta de recursos o de capacidad), la puede encargar a un proveedor.

En el capítulo 4figuran ejemplosdecontramedidas afactoressituacionales

Seleccionar elnivel de detalleapropiado de losrequisitos



Resumen • Procede encargar un análisis de requisitos cuando ladisponibilidad o claridad de los requisitos es baja y lacapacidad 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 lasadministraciones públicas es preciso aplicar la Decisión sobre Normas de la CE siel ‘responsable contractual’ (el cliente) adquiere la propiedad de unos productosque entran dentro del ámbito de aplicación de dicha Decisión. Tal Decisión sobreNormas no afecta a aquellos productos que permanecen en propiedad delproveedor [87/95/CEE].

Los motivos para utilizar las normas son: garantizar que las soluciones seanabiertas, evitar limitarse a un único proveedor y solución, maximizar lainteroperabilidad de los sistemas y utilizar un lenguaje común universal paraexpresar 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. Convienefacilitar 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. Enalgunos casos, la selección viene limitada por los imperativos de una políticaorganizativa.

Procede utilizar proveedores externos si:

• la capacidad del equipo de proyecto del cliente es baja (por ejemplo, elequipo del cliente no posee experiencia, hay pocos expertos en SI, el equipose dedica al mantenimiento de sistemas ya existentes, se requierenconocimientos técnicos especiales, se precisa una elevada flexibilidad en laasignación de recursos)

• existe el riesgo de que aumente el coste del proyecto y se produzcan retrasosen la entrega: puede ser útil obtener algún compromiso por parte de losproveedores externos (en especial mediante contratos a precio fijo)

• la novedad del objetivo o de la tecnología de desarrollo precisan una periciaque sólo se puede hallar en el exterior

• la pronunciada heterogeneidad de los agentes o su actitud negativa exige laintervención de un tercero, que se considera neutral, en el juego político de laorganizació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

¿Por qué utilizarnormas?

¿Cuándo utilizarproveedoresexternos?



Opción: Determinar los tipos de licitación

La Directiva de Servicios de la CE (92/50/CEE) define cuatro procedimientos deadjudicación:

• procedimiento abierto: en el que todos los proveedores interesados puedenpresentar una oferta

• procedimiento restringido: en el que sólo pueden presentar una ofertaaquellos proveedores que hayan sido invitados por el responsable contractualdel cliente; este conjunto de proveedores candidatos puede determinarse apartir de los conocimientos sobre el mercado que posea el cliente, a partir deun estudio de mercado o mediante una preselección a través de unaconvocatoria

• procedimiento negociado: en el que el responsable contractual del clienteconsulta a los proveedores que él seleccione y negocia los términos delcontrato con uno o más de ellos

• concurso de diseños: en el que el responsable contractual del cliente adquiereun plan o diseño seleccionado por un jurado en un concurso que puede o nootorgar premios.

La Directiva de Servicios estipula reglas para la elección de un proceso deadjudicación. En las compras dirigidas por ‘responsables contractuales’ públicos yotras organizaciones a quienes afecte la Directiva (los clientes), sólo podráutilizarse el procedimiento negociado antes que el procedimiento abierto o elrestringido si se cumplen las circunstancias que establece la Directiva y quepermiten su uso, por ejemplo, cuando debido a la existencia de derechos exclusivossólo un proveedor puede ejecutar las adaptaciones o prestar los servicios.

Incluso para aquellas organizaciones que no estén sujetas a la Directiva deServicios y a sus transposiciones a nivel nacional, la situación normal debería ser elprocedimiento abierto o restringido, que permiten al cliente extraer el máximobeneficio de un mercado competitivo. El procedimiento negociado sólo deberáutilizarse cuando la incertidumbre de la situación dificulte la determinación de losrequisitos de los sistemas y servicios (por ejemplo, estimar los costes), cuando laselección de los posibles proveedores se vea restringida por la propia naturalezadel problema o cuando la urgencia dificulte el uso de un proceso de licitación másformal.

Opción: Determinar el tipo de relación con los proveedores

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

Losprocedimientosabiertos orestringidossuponen elmáximobeneficio para elmercadocompetitivo



denominado proceso de licitación multifásico. Los ejemplos siguientes ilustranestos escenarios.

Ejemplos: • Se puede elaborar una lista reducida de proveedores en base ala evaluación de miniofertas incluidas dentro de las ofertasque se reciben en una petición de ofertas.Las miniofertas están menos elaboradas que las ofertascompletas y permiten a los proveedores a quienes no se va aadjudicar el contrato reducir los costes de su participación enel proceso de licitación. A continuación se solicita una ofertacompleta a los proveedores que forman parte de esta listareducida.

En este ejemplo, el proceso de licitación se compone de unaprimera fase que incluye la preparación de la petición deofertas, preparación de las ofertas y selección del proveedor;y posteriormente una segunda fase que incluye la preparaciónde la petición de ofertas, preparación de las ofertas, seleccióndel proveedor y preparación del contrato.

• Se puede elaborar una lista reducida de proveedores en base auna evaluación de las ofertas que se reciben tras una peticiónde ofertas. A continuación el cliente contrata y financia a losproveedores seleccionados para que realicen un estudio de lacompra del sistema, investigando y desarrollando distintosaspectos de la solución que propongan. Posteriormente, estasofertas, mejor definidas, son valoradas por el cliente, queselecciona la mejor y adjudica el contrato al proveedorcorrespondiente.

En este ejemplo, el proceso de licitación se compone de unaprimera minifase de compra que incluye la preparación de lapetición de ofertas, preparación de las ofertas, selección delproveedor, preparación del contrato, seguimiento del contratoy cumplimentación del contrato; y posteriormente unasegunda 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 procesode licitación en tres fases.

Los procesos de licitación en varias fases proporcionan al cliente informaciónadicional acerca de la adaptación o prestación de servicios previstas. Enconsecuencia, disminuirá la incertidumbre y mejorarán las descripciones de losservicios o el estado inicial de la adaptación, posiblemente en grado suficiente parapermitir su gestión. Un inconveniente es que este tipo de procesos es mucho máslento que los procesos de licitación monofásicos, por lo que no resulta adecuadocuando el calendario es muy apretado.



Por regla general, las condiciones en que puede utilizarse la licitación en variasfases se regulan a nivel organizativo (por ejemplo, los reglamentos de comprapública). Durante la licitación, el cliente deberá garantizar que todos losproveedores reciben el mismo trato y que ninguno de ellos obtiene una ventajacompetitiva injusta al tener acceso a más información que el resto. También serecomienda que el cliente financie a los proveedores, ya que la finalidad de sutrabajo dentro del proceso de licitación en varias fases es contribuir a un mejorentendimiento del problema por parte del cliente.

Resumen: • Un proceso de licitación multifásico es apropiado cuandola incertidumbre y/o complejidad son elevadas y no existeun calendario apretado.

Opción: Determinar la flexibilidad de los contratos

La flexibilidad de un contrato es la capacidad para modificar o puntualizar ciertoselementos contractuales, tales como los requisitos de sistemas y servicios, loscostes y el calendario, durante el proceso de seguimiento del contrato. Puede queestos elementos no se hayan definido con total claridad al firmar el contrato y sedeban puntualizar o revisar en el transcurso del contrato.

En el plan de entregas que planifica el proceso de supervisión del contrato, lamodificación o puntualización de los elementos contractuales se lleva a cabomediante puntos de decisión de inversión. Básicamente, una decisión de inversióndetermina si se debe o no invertir en modificar una organización o un sistema deinformación (consultar apartado 4.4).

Estos puntos de decisión de inversión deberán determinarse y planificarse antes oal inicio del proceso de licitación. De otro modo, existe el riesgo de que seproduzcan cambios contractuales no controlados durante la supervisión delcontrato. En otras palabras, cualquier procedimiento y condición para cambiar opuntualizar los elementos contractuales, por ejemplo los requisitos y el calendario ysu repercusión en los costes, deberán definirse perfectamente en el contrato.

Los contratos flexibles no suelen fijar un precio de manera estricta: deberá serposible volver a determinar el precio. El precio deberá poder aumentarse odisminuirse en los puntos de decisión de inversión, para ajustarlo mediante unosprocedimientos y parámetros (por ejemplo, costes de puntos de función, costes demano de obra, carga de trabajo, capacidad, costes de los recursos) que se hanfijado en el contrato. En general, se acuerdan los límites inferior y superior delprecio al objeto de proteger al cliente y al proveedor del riesgo de costesimpredecibles derivados de la ejecución del proyecto/prestación del servicio.

Planificar elcontrol de loscambioscontractuales



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 anivel organizativo (por ejemplo, mediante reglamentos nacionales paraadministraciones públicas).

Cuando el responsable contractual del cliente puede utilizarlos, los contratosflexibles suponen una manera de gestionar la incertidumbre sin tener que cambiarde proveedores en el transcurso de la adquisición o programar secuencias decontratos, lo que prolonga el proceso e incrementa los costes.

Resumen: • Los contratos flexibles son apropiados cuando laincertidumbre 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 laadquisición mediante uno o varios contratos ejecutados en paralelo osucesivamente.

Esta decisión puede verse influenciada por dos factores.

• Los imperativos del reglamento interno de la organización pueden motivar laelección de una cierta serie de contratos (por ejemplo, limitacionespresupuestarias de contratos o años fiscales, necesidad de utilizar contratoscon un precio fijo).

• Depende de la incertidumbre de la situación; el uso de una serie de contratosen lugar de un único contrato puede:− proporcionar la flexibilidad necesaria para la clarificación y evolución de

los requisitos de sistemas y servicios de acuerdo con las necesidades delnegocio en el transcurso de la adquisición: esto resulta especialmente útilcuando la claridad, disponibilidad y estabilidad de los requisitos es baja, yen general en todas las situaciones inciertas en las que existe el riesgo deevolució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: elloresulta útil en todas las situaciones inciertas en las que existe el riesgo deque surjan costes impredecibles para la organización, el proyecto o laprestación del servicio.

Si el responsable contractual del cliente decide utilizar una serie de contratos, o losimperativos le obligan a ello, podrá llevar a cabo la licitación de cada uno de ellosdescribiendo cada compra en términos de su plan de entregas.

A A continuación se aborda con mayor detalle la cuestión de las relaciones entrelas adaptaciones de SI y la secuencia de contratos.

¿Cuándo utilizaruna serie decontratos?

CC SC

CPCS

SPSS



La experiencia demuestra que ciertas combinaciones de estado inicial y estado finaltienden a dar como resultado proyectos difíciles de controlar. Ello se debeprincipalmente a que el estado inicial no se elabora lo suficiente al objeto de reducirlas incertidumbres, que deben ir resolviéndose a medida que se avanza hacia elestado final. Se pueden utilizar distintas estrategias para gestionar estasincertidumbres:

• Los enfoques de instalación o construcción evolutivos (véase Opción:Determinar los requisitos de la estrategia de adaptación) permiten laclarificación progresiva de los requisitos en base a la utilización o ensayo delas sucesivas versiones del SI; un único contrato puede contemplar variasversiones del SI si las cláusulas contractuales son suficientemente flexiblescomo para puntualizar los requisitos y costes durante la vida del contrato; deno ser así, podrá utilizarse una serie de contratos, cada uno de los cuales sereferirá a una versión del SI.

• Si se utilizan las modalidades de instalación o construcción de una vez oincremental, podrá dividirse la adquisición en una secuencia de contratos,cada uno de los cuales ayudará a reducir las incertidumbres: su estado finalse utilizará como estado inicial del siguiente contrato; en otras palabras, cadacontrato proporciona un mayor conocimiento de los requisitos del SI, loscostes y los planes futuros para sucesivas adaptaciones y contratos.

En el caso de una serie de contratos de adaptación, normalmente el estado inicialde cada adaptación se puede derivar directamente del estado final de la adaptaciónanterior. Este escenario queda representado en la figura 2.7.

Sistema deInformación

Actual

Objetivo de la

adquisición

Un solo contrato

Licitación/

Seguimiento/

Finalización//

Licitación/

Seguimiento/

Finalización/

Múltiples contratos

Sistema deInformación

Deseado/ / /Licitación

/Seguimiento Finalización

Figura 2.7: Consecución del objetivo de la adquisición mediante un único contratoo mediante varios contratos de adaptación.

¿Cómo gestionarun estado inicialinsuficiente?

Utilizarcontratosflexibles

División envarios contratos



A pesar de que cada adaptación del sistema de información se encarga de resolverun problema concreto, se observa un conjunto de estados iniciales y finales típicosque apoyan la secuencia de los contratos de adaptación.

La noción de estados finales típicos indica que existen ciertas combinaciones deentregables que suelen aparecer como estados finales de una adaptación del SI.Ello se debe a que globalmente proporcionan un resultado útil a un cliente.

La noción de estados iniciales típicos indica que existen ciertas combinaciones deun SI de un cliente y de sus elementos descriptivos asociados que normalmente seencuentran al inicio de una adaptación del SI.

Las figuras 2.8 y 2.9 contienen descripciones abreviadas de los estados iniciales yfinales típicos. En el anexo A figuran descripciones más detalladas, además de losperfiles de los entregables de los estados iniciales y finales típicos. En el apartado3.6 aparecen descripciones de los entregables del dominio objetivo.

Algunos de los estados iniciales y finales típicos consisten en combinacionessimilares de entregables. En este caso se da el mismo nombre al estado inicial típicoy al estado final típico.

N.B. Los estados iniciales y finales típicos simplemente proporcionan ejemplos de puntosiniciales y finales de adaptaciones de SI. No recomiendan una secuencia de puntos dedecisión dentro de una única adaptación del SI. Por este motivo se utiliza siempre laexpresión ‘estados iniciales y finales típicos’ y se evita cualquier forma abreviada de lamisma, ya que podría transmitir una impresión incorrecta.

Los estadosiniciales yfinales típicospueden apoyar lasecuencia de loscontratos



Figura 2.8: Estados finales típicos de adaptaciones del SI.Los estados finales típicos pueden incluir planes para posteriores adaptaciones del

SI.

Estado final típico Finalidad Entregables del dominio objetivo

Documentación del sistemade información

Que la documentación llegue a unasituación en que pueda servir de insumoútil para posteriores adaptaciones del SI; oResolver incertidumbres debidas a unescaso conocimiento del sistemainformático (CS) o del SI existente.

Elementos descriptivos detallados que serefieren a las prácticas de trabajo y laarquitectura del CS del SI actualmenteoperativo.

Análisis de cambios del SI Proporcionar documentación de apoyo alas decisiones, por ejemplo para cambiosde las prácticas de trabajo.El SI actual no experimenta ningúncambio.

Elementos descriptivos globales que serefieren a las visiones de los procesos delnegocio, de la información del negocio y delas prácticas de trabajo.

Análisis de cambios del CS Proporcionar documentación de apoyo alas decisiones, por ejemplo parainversiones en soportes físicos del CS o ensoftware de aplicación.El SI actual no experimenta ningúncambio.

Elementos descriptivos globales que serefieren a las visiones de los procesos denegocio, de la información del negocio, delas prácticas de trabajo y de la arquitecturadel CS.

Diseño detallado del negocio

Proporcionar documentación de apoyo alas decisiones y documentos de entradapara posibles adaptaciones posteriores delSI. Con ello representa al mismo tiempoun estado inicial típico de una adaptacióndel SI; y un posible punto de división deuna adaptación del SI en varias otras.

Elementos descriptivos detallados quecontemplan las visiones de la informacióndel negocio, de los procesos del negocio yde las prácticas de trabajo de una nuevaversión del SI.

Elementos descriptivos globales que serefieren a los datos, las funciones y laarquitectura del CS, e ilustran la viabilidaddel diseño de negocio detallado.

Diseño técnico detallado El SI actual no experimenta ningúncambio.

Elementos descriptivos detallados que serefieren a las prácticas de trabajo y a losdatos, funciones y arquitectura del CS deuna nueva versión del SI.

SI probado Se construye y se prueba una nuevaversión del SI, que sólo tiene queinstalarse en el dominio objetivo. Sueleaparecer, por ejemplo, cuando lainstalación del CS es tan compleja quedebe gestionarse como una adaptaciónaparte del SI, o cuando la naturaleza delos cambios organizativos del dominioobjetivo aconseje al cliente llevarlos acabo internamente.El SI actual no experimenta ningúncambio.

Elementos operativos de una nueva versióndel SI, que pueden sustituir a varios o atodos los elementos operativos del SIactualmente operativo.

Elementos descriptivos detallados de lasprácticas de trabajo y de la arquitectura delCS de la nueva versión del SI.

SI instalado Cambiar el SI para satisfacer lasnecesidades del negocio seleccionadas.Asimismo, se produce la documentaciónde diseño de la nueva versión del SI paraapoyar su mantenimiento y desarrolloadicional.

Una nueva versión operativa del SI, en laque varios o todos los elementos operativosson sustituidos por otros nuevos.Elementos descriptivos detallados de lasprácticas de trabajo y de la arquitectura delCS 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 incluirtambién planes de proyecto relativos a la adaptación prevista del SI.

Estado inicial típico Estado final precursor típico Entregables del dominio objetivo

SI no documentado Ninguno - puede ocurrir si, durante unperíodo de tiempo, se ha modificado elsistema operativo sin que se hayaregistrado ninguno de los cambiosrealizados.

No existe documentación de apoyo; obien

Documentación rudimentaria o de bajacalidad; o bien

Documentación que ya no es coherentecon la versión actual operativa del SI.

SI documentado Un estado final similar al de SIinstalado o al de la documentación delSI.

Descripción detallada de las prácticasde trabajo y de la arquitectura delsistema informático del SI actualmenteoperativo.

Descripción delproblema

Un estado final similar al de análisis decambios del SI o al de análisis decambios del sistema informático.

Elementos descriptivos de carácterglobal e informal relativos a losprocesos e información del negocio y alas prácticas de trabajo y la arquitecturadel sistema informático del SIactualmente operativo y otros futuros.

Diseño global Un estado final similar al de análisis decambios del SI o al de análisis decambios del sistema informático.

Elementos descriptivos de carácterglobal y semiformal relativos a losprocesos del negocio, la informacióndel negocio, las prácticas de trabajo y laarquitectura del sistema informático delfuturo SI; pueden ser simulaciones.

Diseño detallado delnegocio

Un estado final similar al de diseñodetallado del negocio.

Elementos descriptivos detallados de lainformación del negocio y de lasprácticas de negocio y de trabajo de unanueva versión del SI.

Elementos descriptivos globalesrelativos a los datos, funciones yarquitectura del sistema informático,que ilustran la viabilidad del diseñodetallado del negocio.

Diseño técnicodetallado

Un estado final similar al de diseñotécnico detallado.

Elementos descriptivos detallados delas prácticas de trabajo y de los datos,funciones y arquitectura del sistemainformático de una nueva versión delSI.

SI probado Un estado de SI probado en que se haconstruido, pero no instalado, unanueva versión del SI, por ejemplodebido a que la instalación en sí mismaes compleja y difícil de realizar.

Los elementos operativos queconstituyen la nueva versión del SI.

Elementos descriptivos detallados delas prácticas de trabajo y de laarquitectura del sistema informático dela nueva versión del SI.



El siguiente procedimiento puede utilizarse para dividir una adaptación del SI envarios contratos cuando se utiliza la modalidad de una vez o la modalidadincremental:

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 laadaptación del SI con los estados inicial y final típicos apropiados, véase figuras2.8 y 2.9.

3. Comprobar si esta combinación de estados inicial y final típicos constituyealguna 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 unaposible división de dicha adaptación.La tabla de la figura 2.10 indica a partir de qué estados iniciales típicos sueletener lugar la progresión hacia los distintos estados finales típicos en una únicaadaptación del SI, y para cuáles deberá tomarse en consideración una divisiónde la adaptación del SI. Estos estados iniciales y finales típicos determinanpuntos en los que una adaptación del SI podría dividirse en otras dosadaptaciones del SI; la primera de ellas finalizaría con el estado final típico y lasegunda continuaría con el estado inicial típico.

Procedimientopara definir unasecuencia decontratos



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 estadosinicial y final con los estados inicial y final típicos, se obtiene una primera impresiónde los riesgos asociados a las adaptaciones del SI. No se trata de un juicioabsoluto, sino simplemente de una señal inicial. Siempre pueden existir factoressituacionales concretos que pueden alterar ese juicio. Por ejemplo:

• es posible que una adaptación del SI que se inicie con la descripción delproblema 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 eldominio objetivo es muy pequeño o los requisitos del SI se conocenperfectamente.

• es posible que una adaptación del SI que se inicie con un diseño detallado delnegocio y finalice con un diseño técnico detallado, combinación que entérminos generales se caracteriza por ser gestionable, sea muy difícil degestionar, simplemente porque la situación del proyecto sea muy complicada;por ejemplo, debido a un elevado número de subcontratos, resistencia a laaceptación de la adaptación del SI, interfaces externas, etc.

Estado

final

Estadoinicial

Documentación del

sistema de

información

Análisis de

cambios del

sistema de

información

Análisis de

cambios del

sistema

informático

Diseño

detallado del

negocio

Diseño

técnico

detallado

Sistema de

información

probado

Sistema de

información

instalado

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 oun control explícito de los cambios contractuales.

Combinación no válida.

Comprobar laviabilidad de lasecuencia decontratos



Resumen: • Dividir la adquisición en varios contratos resulta apropiadocuando la incertidumbre es elevada y no existe uncalendario apretado.

A

A Opción: Decidir si comprar o desarrollar

En ocasiones se puede elegir entre comprar (por ejemplo, un paquete de softwaredisponible en el mercado) o desarrollar específicamente un producto (por ejemplo,software) que satisfaga los requisitos. Puede existir una política general a nivelorganizativo acerca de esta opción (por ejemplo, únicamente se deciden desarrollosespecíficos si no hay ningún producto adecuado disponible).

La compra es aconsejable cuando:

• existen productos con suficientes referencias y proveedores fiables (unejemplo típico es el dominio contable)

• la especificidad del SI no es muy elevada y los productos cubren la mayoríade funcionalidades que se requieren

• la capacidad de los agentes es baja, es decir, el cliente posee un conocimientoinsuficiente 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.

El desarrollo de productos resulta adecuado cuando:

• 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 explicanestas modalidades y se ofrecen orientaciones para seleccionar entre las opcionesdisponibles. En concreto, se indica cómo reducir los riesgos derivados de lacomplejidad y la incertidumbre seleccionando las modalidades apropiadas. (þ4.3.2-3: Analizar y seleccionar las opciones estratégicas)

Al inicio de la adquisición, el responsable contractual del cliente suele establecerlos requisitos del enfoque de la instalación: de una vez, incremental o evolutiva. Elenfoque de la instalación se refiere al momento en que las distintas partes yversiones de los sistemas pasan a estar disponibles en la organización.

CC SC

CPCS

SPSS

¿Cuándocomprar?

¿Cuándodesarrollar?

Establecer losrequisitos delenfoque de lainstalación delsistema



El responsable contractual del cliente también podrá establecer requisitos relativosal enfoque de la construcción y, más raramente, al enfoque de la descripción si seprecisa un enfoque uniforme en el nivel de adquisición. Muchas veces estascuestiones se dejan a elección de los proveedores en sus ofertas, es decir, al nivelde gestión del contrato.

Las decisiones relativas al enfoque de control del proyecto se pueden adoptar adistintos niveles, en función del nivel de normalización de los procedimientos decontrol 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

En cuanto a los servicios, existen las siguientes opciones:

• ubicación: en la sede del cliente o en la del proveedor

• compartir (o no) el servicio entre varios clientes

• 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 muchoselementos físicos, desde mobiliario de oficina hasta un gran sistema informáticocentral, ya no son necesarios o deben trasladarse. Entre otras cosas, habrá quedefinir qué bienes internos y externos ya no serán necesarios, cuáles debendevolverse 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 lainstalación del servicio, la cancelación del servicio y el control del servicio. En elapartado 5.2 se explican estos enfoques y se ofrecen orientaciones para seleccionarentre las opciones disponibles.

El personal que interviene directamente en el servicio también suele participar en lainstalación y la retirada del mismo. Pueden surgir conflictos y problemas de moraly de motivación, que pueden evitarse mediante una planificación detallada y unagestión activa. Por supuesto, el propio personal deberá ser informado de todas lasactividades y planes relativos a la instalación y cancelación del servicio. (þ 5.2:Servicios de planificación)

Clarificar lasresponsabilidadesdel cliente y delproveedor, y labase para lospagos



Al inicio de la adquisición, el responsable contractual del cliente suele establecerlos requisitos de los enfoques de la instalación del servicio: de una vez, incrementalo evolutiva, con cobertura geográfica global o regional. Pueden establecersediferentes requisitos para diferentes servicios o grupos de servicios.

Normalmente, los enfoques de cancelación del servicio se decidirán durante elproceso de compra.

Las decisiones relativas al enfoque del control del servicio pueden adoptarse endistintos niveles, en función del nivel de normalización de los procedimientos decontrol del servicio que utiliza la organización, la especificidad de la adquisición, elcontrato 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 dela adquisición

El responsable contractual del cliente deberá planificar yorganizar los principales puntos de decisión de la adquisición enbase 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 deentregas)

• factores de situación y riesgos (apreciación de la situación)

• estrategia de adquisición (opciones seleccionadas de gestión de riesgos).

El plan de adquisición deberá incluir las compras previstas y otras actividades delcliente, por ejemplo el cambio de los factores situacionales, cambio opuntualización de los requisitos o adquisición de ayuda externa. El plan podráevolucionar durante el proceso de adquisición, es decir, el nivel de detalle variará yserá mayor para las actividades y compras a corto plazo.

Las decisiones relativas a una compra documentada en un plan de adquisición serelacionan en la figura 2.11.

Establecer losrequisitos delenfoque de lainstalación delservicio

El plan deadquisicióndeberá reflejar laestrategia

Planificar lascomprasnecesarias y lasactividades delcliente



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áa cabo la adquisición. Para ello deberá identificar las distintas funciones que seprecisen (los responsables de proyecto y de servicio del cliente y los diferentesexpertos, véase capítulo 1) y asignarlas a personas. Es preciso comprobar que estaspersonas estarán disponibles cuando sean necesarias en el transcurso de laadquisición.

También habrá que identificar y programar la intervención de los agentes de laorganizació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 responsablecontractual del cliente para la gestión de la adquisición. Esta ayuda externa a lagestión de la adquisición es apropiada cuando:

• la capacidad del equipo del cliente es baja (por ejemplo, escasa o nulaexperiencia en la adquisición de un SI, falta de tiempo disponible, falta derecursos)

• la elevada heterogeneidad de los agentes o su actitud negativa precisa unpunto de vista externo, no influenciado por el conocimiento de la trayectoriay los conflictos internos del cliente

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

Asignarfunciones a laspersonas

¿Cuándo utilizarayuda externa?



• el SI es complejo (por ejemplo, un dominio objetivo de gran tamaño, unagran 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 deacceso a fuentes externas.

2.2 Conducción de un proceso de compra

Una compra es el proceso de obtención de las adaptaciones y prestaciones deservicios 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óndel servicio y cancelación del servicio)

• varias prestaciones de servicios (incluyendo la instalación y cancelación delos servicios)

• varias adaptaciones y prestaciones de servicios.

Los requisitos de una compra se definen al inicio de la adquisición y se documentanen un plan de adquisición, véase figura 2.11 en el apartado 2.1: Inicio de laadquisición. Durante el proceso de compra es posible que los requisitos de lacompra evolucionen. El plan de adquisición deberá mantenerse actualizadomediante el control de la gestión de las versiones. Incluso la definición del objetivode la adquisición deberá revisarse para adecuarla a las puntualizaciones ymodificaciones que se produzcan durante el proceso de compra. Ello exigirá lacoordinación entre los responsables de gestión a nivel de adquisición y a nivelcontractual.

Tal y como se explica en el capítulo 1, véase figura 1.4: Modelo del proceso deadquisición, un proceso de compra es una secuencia de tres procesos:

• Licitación.Proceso encaminado a seleccionar un proveedor y una oferta para lasadaptaciones y prestaciones de servicios en cuestión, y a acordar con elproveedor seleccionado un contrato que defina las entregas y lasresponsabilidades de ambas partes.

• Seguimiento del contrato.Proceso encaminado a supervisar las adaptaciones y prestaciones de serviciosdefinidas en el contrato, es decir, asegurar que los entregables y servicios sonconformes a los requisitos especificados en el contrato.

CC SC

CPCS

SPSS

Manteneractualizados elobjetivo y elplan deadquisición

Una secuenciade tres procesosde compra



• Cumplimentación del contrato.Proceso encaminado a finalizar el contrato.

A continuación se formulan orientaciones sobre la utilización de Eurométodo enestos tres procesos.



2.2.1 Licitación

Actividades del cliente

Preparación de lapetición de ofertas

Petición de ofertas

Respuesta

Informe de evaluaciónde proveedores

Contrato

Actividades del proveedor

Selección delproveedor


Preparación delas ofertas


• Preparación de la petición de ofertas.La finalidad de esta actividad es obtener la primera versión de los requisitos decompra del sistema de información, para incorporarlos al entregable de peticiónde 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ónpropuesta que satisface sus requisitos de compra del sistema de información. Estaoferta incluirá versiones más elaboradas de los planes que contiene la petición deofertas.

• Selección del proveedor.En base a una evaluación, se comunica al proveedor que haya presentado laoferta más apropiada, que ha sido seleccionado. En caso de que no se prefiera aningún proveedor en concreto, se considerarán posibles alternativas, como unanueva petición de ofertas.

• Preparación del contrato.El proveedor seleccionado y el cliente podrán negociar posibles modificaciones yampliaciones de la oferta antes de pactar el contenido final del contrato. A

CC SC

CPCS

SPSS



continuación, ambas partes firmarán el contrato.

Figura 2.12: Actividades e intercambio de entregables dentro de un proceso delicitación

(ejecutadas por los responsables contractuales y del proyecto/servicio)

El proceso de licitación está encaminado a seleccionar un proveedor y una ofertapara 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 proveedorseleccionado un contrato que defina las entregas y responsabilidades de ambaspartes.

El proceso de licitación encierra las siguientes actividades: preparación de lapetición de ofertas, preparación de las ofertas, selección del proveedor ypreparación del contrato, véase figura 2.12. Estas actividades las realiza el cliente oel proveedor o ambos; y en ellas se elabora una descripción de los procesosprevistos de seguimiento y cumplimentación del contrato. El proceso previsto deseguimiento del contrato se documenta dentro de un plan de entregas contractual.

Todas estas actividades incluyen la elaboración de documentos que se intercambiancomo 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 figura2.12: pueden coincidir en el tiempo y pueden producirse iteraciones de grupos deellas, véase figura 2.13. En el apartado 2.1.2.3: Opción: Determinar las relacionescon los proveedores, figuran ejemplos de iteraciones

Proceso de l ic i tac ión Proceso desuperv is ióndel cont ra to

Plan de en t regas de l p roceso de superv is ión de l cont ra to

Preparac iónde la pe t ic ión

de ofer tas del cont ra toPreparac ión

descr ibe descr ibevaloradescr ibe

Puntos de dec i s ión de l p roceso de superv i s ión de l con t ra to

Preparac iónde la ofer ta

Se lecc ión de lp roveedor

Plan de en t regasrea l izado en

I terac ión de ac t iv idades

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 firmadel 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 firmadel contrato o como resultado de que el cliente presente al proveedor una carta deintenciones; en función de la práctica de negocio a nivel nacional.

En ciertas situaciones, como dentro del dominio público, el cliente y el proveedortendrán que cumplir los reglamentos nacionales y europeos. Eurométodo ayuda alcliente a realizar estas actividades de acuerdo con estos reglamentos, en su caso.

2.2.1.1 Preparación de la 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ánelaborar 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 eltrabajo. Las actividades a realizar para elaborar una petición de ofertas serelacionan en la figura 2.14. Estas actividades corresponden a las propiedades que

Diferentesprácticas denegocio a nivelnacional

CC SCCPCS

SPSS

Objetivo: Producir una petición de ofertas que documente los requisitos delcliente respecto al objetivo y el plan de adquisición, y que constituya una basesuficiente 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 yservicios

– Determinar los imperativos y procedimientos organizativos (normasaplicables, arquitectura, etc.)

– Determinar el plan de entregas necesario

– Determinar los imperativos que previsiblemente afectarán al plan delproyecto y al plan de servicio (calendario, disponibilidad de los recursos delcliente, 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 delproveedor

– Presentar la petición de ofertas

Productos: Petición de ofertas



se definen en el apartado 3.2.1. A continuación figuran orientaciones sobre lamanera de llevar a cabo estas actividades.

En la práctica, la preparación de la primera petición de ofertas dentro de unaadquisición puede integrarse en el inicio de la adquisición, es decir, se integran lasactividades similares dentro del inicio de la adquisición y la preparación de lapetició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 unsubconjunto de éste. En caso de que existan varios contratos dentro de laadquisición, el dominio objetivo de esta compra podrá ser un subconjunto deldominio objetivo de toda la adquisición, es decir, habrá que definir estesubconjunto.

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 seestablecen al inicio de la adquisición) incluidos dentro del alcance de este contrato.Esta actividad puede llevarla a cabo el cliente con o sin ayuda de proveedores, enfunción de las relaciones con los proveedores dentro del proceso de licitación,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:

• A descripciones de los sistemas, que definen los elementos operativos.Elementos descriptivos que deben incorporarse a las adaptaciones; puedenincluir elementos descriptivos del estado inicial y de futuros SI. El nivel dedetalle 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. Puedenincluir las actividades a realizar, las comunidades de usuarios a las que se vana prestar los servicios, etc. Para cada servicio, el nivel de detalle de ladescripción del servicio puede variar, desde una simple descripción hasta lapropia 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 puedeevolucionar 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 deentregas, el cliente deberá identificar cualquier imperativo técnico u organizativoque afecte a las adaptaciones y prestaciones de servicios propuestas. Ejemplos deestos imperativos: arquitectura técnica y de datos de la empresa, además de normasde ingeniería de sistemas adoptadas y guías de estilo de la documentación. Véasetambién el apartado 2.1.2.1: Determinar los escenarios generales de adaptaciones

Definir conmayor precisiónel dominioobjetivo

Definir conmayor precisiónlos requisitos desistemas yservicios

Requisitos desistemas yservicios

Determinar losimperativosorganizativos



y prestaciones de servicios, donde figuran ejemplos de prioridades y dependenciasentre entregas.

Determinar el plan de entregas necesario

El plan de entregas que incluye una petición de ofertas puede presentar diferentesniveles de detalle, en función del nivel disponible de conocimientos acerca de lasadaptaciones y prestaciones de servicios necesarias, obtenidos al inicio de laadquisición.

A Para cada adaptación necesaria, el nivel de detalle del plan de adaptaciónincluido en el plan de entregas puede variar, desde un simple análisis de riesgoshasta la propia definición de la estrategia de adaptación y la elaboración de cadadecisión y de cada entregable identificados. Las técnicas de planificación de laadaptación descritas en el capítulo 4 deberán utilizarse para elaborar un plan deadaptación:

1. Análisis de riesgos (preceptivo).El resultado es una apreciación y descripción de la situación del problema: elestado final y el estado inicial de la adaptación, los valores de los factores desituación y los riesgos críticos. El cliente deberá solicitar que el plan deadaptació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 modalidadde control del proyecto y las contramedidas para reducir los riesgos. Deberíacentrarse en los riesgos más críticos. (þ 4.3: Diseño de una estrategia deadaptació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 dedecisión, incluyendo los entregables que servirán de condiciones previas o debase para las decisiones.(þ 4.4-5: Planificación de los puntos de decisión, descripción de los

entregables) A

S Para cada servicio o grupo de servicios asociados, el nivel de detalle del plan deprestación de servicios necesario puede variar, desde una descripción de lasituación del problema hasta la propia elaboración del plan de instalación delservicio, ejecución del servicio y cancelación del servicio. Para ello podránutilizarse 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óndel servicio, los factores situacionales y los riesgos críticos. (þ 5.2.1: Análisisde 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 unaestrategia de prestación del servicio)

Diferentesniveles dedetalle

Establecer losrequisitos de losplanes deadaptación

Establecer losrequisitos de losplanes deprestación deservicios



3. Planificar los puntos de decisión (opcional)Da como resultado descripciones de la secuencia y del contenido de los puntosde 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 riesgosespecíficos que conlleva la preparación de la petición de ofertas. Ejemplos de estetipo de riesgos:

• ningún proveedor responde a la petición de ofertas, debido a que lasorganizaciones de los proveedores consideran que una compra de un sistemade información es, por ejemplo, inviable o demasiado arriesgadaeconómicamente

• los importes y los costes que indican las ofertas son muy elevados, debido aque los proveedores han tenido que adoptar importantes medidas deprevenció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. Unaposible contramedida para reducir los riesgos es revisar el plan de adquisición, esdecir, cambiar los requisitos de esta compra.

Finalmente, los requisitos de los puntos de decisión incluidos en los planes deadaptación y de prestación de servicios deberán reunirse en un conjunto derequisitos de los puntos de decisión dentro de la supervisión del contrato. Ellodeberá complementarse con los requisitos del punto de decisión decumplimentación del contrato, por ejemplo, los requisitos de organización,procedimientos y funciones que intervienen.

Determinar los imperativos que previsiblemente afectarán al plan del proyecto yal plan de servicio

Ninguna compra de un SI se produce totalmente desligada de los procesos denegocio que tienen lugar en la organización del cliente. Así pues, al preparar lapetición de ofertas deberá consultarse a los responsables organizativos al objeto deidentificar cualquier imperativo organizativo o de planificación, como por ejemplola interrupción de los pagos, la presentación del producto y fechas deimplementación de la reorganización. La relación de propiedades del plan delproyecto y del plan de servicio que se ofrece en el apartado 3.3 puede utilizarsepara 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 alpresupuesto de la adquisición. Este presupuesto debería especificarse de algunamanera en la petición de ofertas. Así pues, al preparar la petición de ofertas esconveniente consultar al responsable financiero, al objeto de identificar cualquierimperativo financiero u organizativo relativo al plan de negocio de la organización,véase apartado 2.1.1.3: Analizar los costes y beneficios.

Considerar losriesgosespecíficos de lapetición deofertas

Posible cambiodel plan deadquisición

Establecer losrequisitos delpunto dedecisión decumplimenta-ción del contrato

Clarificar lasinterfaces de losprocesos denegocio

Estimación delpresupuesto



Definir las cláusulas jurídicas del contrato

Ejemplos de cláusulas jurídicas:

• criterios de aceptación de la adaptación y la prestación del servicio

• 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

Los criterios que se aplicarán para evaluar y seleccionar un proveedor deberándocumentarse en la petición de ofertas. Deberán tenerse en cuenta los siguientesaspectos para la selección de los criterios relevantes:

• 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 contractualespor ejemplo: precio, métodos propuestos, cualificaciones de los agentes queintervienen en la producción de los proyectos y las prestaciones de servicios.

Es preciso determinar el enfoque de la evaluación de las ofertas para cada criterioseleccionado. En la medida de lo posible deberán utilizarse medicionescuantitativas. Como no es posible expresar todos los beneficios con una únicamedida, 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 esosbeneficios de acuerdo con la estrategia del negocio y la gestión. Esta tabla deevaluación y su justificación deberán estar documentadas para garantizar que laselección del proveedor sea imparcial. En el apartado 2.2.1.3: Selección delproveedor figura más información a este respecto (comparación de ofertas).

Definir lascláusulasjurídicasnecesarias

Determinar loscriteriosrelevantes deselección delproveedor

Graduar loscriterios



Asimismo, el cliente deberá indicar qué requisitos son obligatorios, incluyendo estainformación en las descripciones de los sistemas, en las descripciones de losservicios y en el plan de entregas necesario.

Determinar las instrucciones para los proveedores que presentan ofertas

Al preparar la petición de ofertas, es preciso tener en cuenta qué instruccioneshabrá que dar a los proveedores. Ejemplos de instrucciones:

• 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ánutilizar la terminología de Eurométodo

• Procedimientos de intercambio durante la preparación de las ofertas, porejemplo, reuniones con todos los proveedores interesados.Cuando una organización esté sujeta a los reglamentos de las Directivas deServicios [92/50/CEE], deberá asegurarse de que cumple sus requisitos, porejemplo, enviando a todos los proveedores potenciales conocidos todas lasrespuestas a una cuestión en concreto

• Indicación de los métodos propuestos por el proveedor y existencia dediccionarios 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ónhaciendo una indicación al respecto en la petición de ofertas: ‘Se invita aproveedores cuyas organizaciones reúnan las siguientes características: registrosegún la norma EN 29000, capitalización de 1 MECU, etc.’. Otra posibilidad esque los criterios para valorar la capacidad de los procesos organizativos seextraigan de las especificaciones actualmente disponibles sobre capacidad deproceso 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 yperiódicos de ámbito profesional, y remite sendos ejemplares de los requisitos decompra del SI a todos los proveedores interesados o sólo a los proveedoresseleccionados, 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 deservicios, y

• el valor de la adquisición, o de la agregación de adquisiciones, supere losumbrales CE/OMC.

Indicar losrequisitospreceptivos

Planificar lasrelaciones conlos proveedores

Extraer loscriterios de lasnormas o de lacapacidad deproceso ymétodos deevaluación



En esta situación, las organizaciones de proveedores interesadas en el contrato quese propone podrán solicitar más información al respecto. El cliente deberá remitirentonces 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 decriterios predefinidos (por ejemplo, certificación ISO 9001).

Si se desea una licitación restringida o negociada [92/50/CEE], el proceso será mássencillo, ya que los requisitos de compra del sistema de información sólo seproporcionan a los proveedores que han sido seleccionados para participar en elproceso de licitación.

El responsable contractual del cliente y el responsable de un proyecto/serviciodeberán confeccionar una oferta con el contenido que se describe en el apartado3.2.1: Entregables de licitación. Para facilitar el trabajo, puede utilizarse la plantilladel anexo D.2. Las actividades para confeccionar una oferta se relacionan en lafigura 2.15. Estas actividades corresponden a las propiedades que se definen en elapartado 3.2.1. A continuación figuran indicaciones sobre la manera de realizarestas actividades.



2.2.1.2 Preparación de las ofertas

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/serviciodeberán:

1. decidir si la organización del proveedor debe participar en el proceso delicitación y presentar una oferta a la organización del cliente.

1. elaborar una oferta completa, incluyendo el plan de entregas propuesto, lascláusulas jurídicas o comentarios a las cláusulas jurídicas que exige el cliente.

La preparación de la oferta consiste en una valoración y cumplimentación delos requisitos de compra del SI descrito por el cliente en la petición deofertas.

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 lapetición de ofertas del cliente. No obstante, al presentar su oferta, un proveedorpuede interpretar el dominio objetivo de manera diferente (por ejemplo, debido auna apreciación del dominio objetivo a raíz de contactos previos con otros clientesde la misma área de negocio), o puede verse limitado por las tecnologíasdisponibles.

Objetivo: Presentar una oferta competitiva que satisfaga los requisitos del clientetal y como se especifican en la petición de ofertas.

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

CC SC

CPCS

SPSS

Decidir si sepresenta la oferta

En casoafirmativo:elaborar unaoferta

Clarificar laapreciación deldominio objetivo



Determinar los objetivos, requisitos y soluciones

El proveedor deberá clarificar la apreciación de los objetivos y requisitos yproporcionar descripciones de la solución propuesta para los sistemas y serviciosque se solicitan en la petición de ofertas.

Las descripciones de las soluciones consisten en elementos descriptivos quedescriben los entregables de los elementos operativos (sistemas) y los servicios.Las propiedades de un elemento descriptivo que se mencionan en el apartado 3.6,Elementos descriptivos, pueden utilizarse como lista de comprobación para realizarlas descripciones. En el apartado 5.1 se ofrece asesoramiento acerca de ladescripción de los servicios.

S Si lo solicita el cliente, las descripciones de los servicios deberán indicar losmé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 elproveedor revisará el plan de entregas que precisa el cliente y definirá todos losdetalles 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.

Para ello, el proveedor tomará como base la valoración que él mismo hayarealizado de la situación del problema. El proveedor deberá generar una estrategiacompleta de gestión de riesgos para las adaptaciones y prestaciones de servicios.

El siguiente procedimiento puede utilizarse para confeccionar un plan de entregas.

1. A Elaborar un plan de adaptación para cada adaptación. A

2. S 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 deprestación de servicios.

4. Agregar las secuencias de puntos de decisión incluidos en los planes deadaptación y de prestación de servicios, para formar una única secuencia de losprincipales 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.

Clarificar laapreciación delos objetivos yrequisitosDescribir lassoluciones desistemas yservicios

Confeccionar unplan basado enuna estrategia dereducción deriesgos



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 elplan de entregas deberá contener una estrategia de adaptación completa quecontemple todos los riesgos, y una descripción detallada de cada punto de decisióny de cada entregable. Para ello, el proveedor podrá basarse en uno de los dosescenarios posibles para utilizar las técnicas de planificación de la adaptación quese 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:Aplicar el apartado 4.1-5 con el escenario 1 del apartado 4.1: extraer unasecuencia básica de puntos de decisión basada en las opciones estratégicas deEurométodo.

• Utilizar todas las técnicas excepto las opciones estratégicas de Eurométodo(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 escenario2 del apartado 4.4.1: extraer una secuencia básica de puntos de decisiónbasada en un modelo de proceso del método.

Asimismo, si lo solicita el cliente, el proveedor deberá indicar qué métodospropone utilizar y si existe un diccionario de enlace. De este modo, el cliente sabecó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 Para cada servicio o grupo de servicios asociados deberá elaborarse un plan deprestación de servicios utilizando las orientaciones del apartado 5.2: Planificaciónde la prestación de servicios. El plan de prestación de servicios deberá incluir lainstalación del servicio, la ejecución del servicio y la cancelación del servicio quepropone el proveedor. Habrá que prestar especial atención a la realización de unanálisis específico de todos los puntos que presenten dificultades en lasinstalaciones 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óndebidas a los requisitos impuestos sobre la secuencia de decisiones a adoptar, o lossistemas y servicios a entregar. Este análisis de las dependencias es la base de laagregación de las secuencias de puntos de decisión.

Paso 4: Agregar las secuencias de puntos de decisión

Las secuencias de puntos de decisión deberán agregarse de acuerdo con lasdependencias que existan entre ellas. Deberá minimizarse el número de puntos de

Cómo utilizar lastécnicas deplanificación dela adaptacióndescritas en elcapítulo 4

Utilizar lasorientaciones delcapítulo 5 enmateria deplanificación deservicios

Analizar losrequisitos decalendario de lasdecisiones yentregas

Minimizar elnúmero depuntos dedecisión



decisión a fin de elaborar un plan viable para que los responsables contractualesintervengan 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

El punto de cumplimentación del contrato deberá describirse siguiendo lasorientaciones del apartado 4.4.3: Descripción de los puntos de decisión. Estoincluye la descripción de los objetivos, funciones que intervienen, condicionesprevias, bases para las decisiones, organización y calendario. Se puede utilizar laplantilla del anexo D para facilitar esta tarea.(þ 4.4.3: Descripción de los puntos de decisión, anexo D.21: Descripción de lospuntos 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 deservicios, deberá documentarse utilizando el asesoramiento que ofrece el apartado3.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

Ninguna compra de un sistema de información se produce totalmente desligada delos procesos de negocio que están teniendo lugar en la organización. Al preparar laoferta deberá consultarse a los responsables organizativos apropiados, al objeto deidentificar cualquier imperativo organizativo, por ejemplo en los niveles deobtención de recursos para el proyecto y el servicio, o en las fechas deimplementación de la reorganización.

Estos imperativos, junto con los imperativos de la organización del cliente(descritos en la petición de ofertas), se toman en consideración al elaborar laorganización y el plan del proyecto y del servicio. Pueden utilizarse como lista decomprobación las propiedades del plan del proyecto y del plan de servicio que sedescriben en el apartado 3.3: Entregables de gestión.(þ 3.3: Entregables de gestión)

Determinar los importes y los precios

Deberá consultarse a los responsables financieros y de marketing a fin de identificarcualquier programa organizativo de fijación de precios e imperativos financierosrelativos a los importes y los costes. La fijación de precios y el cálculo de costespueden verse afectados por distintas políticas: políticas de ventas y políticas deestimación de costes. Cuando sea posible deberán utilizarse herramientasautomatizadas de estimación, referencias anteriores y técnicas de analogía, a fin deelaborar un buen programa de cálculo de costes.

Existen cuatro métodos básicos para estimar los costes de las adaptaciones:

• Por analogía con experiencias previas:Las estimaciones se basan en los costes de adquisiciones similares. Estemétodo precisa una capitalización de experiencias de adquisición y unaclasificación de estas experiencias según los parámetros que influyen en loscostes.

Clarificar losrequisitos decumplimentacióndel contrato

Clarificar losimperativosrelativos a lasubcontratación

Proponerorganizaciones yplanes delproyecto y delservicio

Puede haberdiferencias entrela fijación deprecios y elcálculo de costes

CC SC

CPCS

SPSS

Métodos deestimación decostes a utilizar



• Modelos matemáticos:Las estimaciones se basan en un modelo matemático que calcula los costes apartir 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. Elanálisis de puntos de función es un ejemplo popular de este método. Estosmodelos matemáticos tienen que ser calibrados para reflejar la especificidadde la situación. También tienen que actualizarse para reflejar la evolución delos últimos avances en tecnologías de la información, métodos, herramientas,etc. Hay que tener cuidado al seleccionar un método cuyos parámetrospuedan ser evaluados durante el inicio de la adquisición: por ejemplo, el usodel análisis de puntos de función precisa un conocimiento suficiente delnúmero de funciones que intervienen en la adquisición y de su nivel decomplejidad.

• Por desglose de tareas:Las estimaciones se basan en un desglose detallado de las tareas que tienenlugar en la adaptación o servicio, y se obtienen sumando los costes de cadauna de las tareas. Los costes de cada tarea se estiman por analogía con tareassimilares o mediante un modelo matemático.

• Por opinión experta:Las estimaciones se obtienen consultando a expertos y alcanzando unconsenso.

Algunos métodos permiten evaluar otros datos además de los costes, como son elesfuerzo y la duración.

Si se utiliza más de un método de estimación de costes las estimaciones serán másfiables.

Es preciso documentar los supuestos y los parámetros aplicados (por ejemplo,tecnologías utilizadas, número de funciones, complejidad de las funciones, plazosprevistos, tasa de mano de obra, tasa de inflación, cambio de moneda) a fin decomprobar, negociar y posiblemente revisar las estimaciones en el transcurso de laadquisición.

Puntualizar las cláusulas jurídicas propuestas

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

CC SC

CPCS

SPSS

Valorar lascláusulasjurídicasnecesarias



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

Deberá incluirse una indicación de la idoneidad de la organización, que demuestreque reúne las características definidas en la petición de ofertas, tales como:

• registro ISO 9000/EN 29000

• fiscalización corporativa

• 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

El proveedor deberá presentar un resumen de aquellas características de la ofertaque considere más ventajosas de las soluciones propuestas.

2.2.1.3 Selección del proveedor

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 lasorganizaciones de proveedores ya hayan sido evaluadas, en cuyo caso ahora simplemente sepuntualizará esa evaluación. En un proceso de licitación abierto, ésta será la primeraocasión en que se evaluará a un proveedor.

El proveedorpuede hacerreferencia acertificadosreconocidosinternacional-mente

Hacer hincapiéen los ladosfuertes

CC SCCPCS

SPSS

Objetivo: Seleccionar la oferta mejor y más rentable entre todas las recibidas.

Insumos: Ofertas

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 losproveedores



La selección del proveedor consiste en decidir qué proveedor se selecciona en basea las evaluaciones de las ofertas. La modalidad de evaluación, por ejemplo loscriterios de evaluación y sus grados de importancia, se han determinado en lapreparación de la petición de ofertas. Hay dos decisiones principales que debenadoptarse:

• En primer lugar, qué ofertas cumplen los requisitos efectivamente (y enparticular, todos los que sean obligatorios). Esta decisión incluye unaevaluació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 hanpresentado ofertas válidas ofrece la solución económicamente más ventajosapara los requisitos de compra del SI.

Las ofertas deberán ser completas y correctas desde el punto de vista formal. No sepermite a los proveedores influir o participar en la selección. El resultado de laselección deberá documentarse en un informe de evaluación del proveedor, talcomo se describe en el apartado 3.2.1, Entregables de licitación y en la plantilladel anexo D.3. En base al informe de evaluación del proveedor, deberá notificarsea cada uno de los proveedores que presentan una oferta el resultado del proceso deselección.

A continuación se ofrece asesoramiento sobre las actividades mencionadas en lafigura 2.16.

Valorar la organización del proveedor

La idoneidad de una organización se suele controlar, en términos generales,haciendo una indicación al respecto en la petición de ofertas (‘Se invita aproveedores cuyas organizaciones reúnan las siguientes características: registrosegún la norma EN 29000, capitalización de 1 MECU, etc.’), o bien quedaacreditada por la presencia del proveedor en la lista de proveedores cualificadosdel cliente, si ésta se permite. La capacidad de los procesos organizativos puedevalorarse utilizando los criterios extraídos de las especificaciones actualmentedisponibles 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 hayandeterminado en la preparación de la petición de ofertas. Para cada criterio elequipo de evaluación del cliente deberá acordar una puntuación, teniendo encuenta el grado de importancia. El resultado deberá ser una matriz de evaluacióncomo la del ejemplo de la figura 2.17.

Es razonable conceder a los proveedores la oportunidad de entrevistarse con elcliente durante la evaluación de proveedores y presentar sus ofertas oralmente.Para que todos tengan las mismas oportunidades, el cliente deberá establecer unlímite de tiempo para las entrevistas. Estas reuniones no deberán convertirse en‘discusiones’; se trata de presentaciones de las ofertas, no negociaciones. Muchasveces también podrá ser una buena idea visitar otras organizaciones que utilicen las

Valorar entérminosgenerales lacapacidad ymadurez de losproveedores

Acordar unapuntuación paracada criterio

Recibirpresentacionesorales y realizarvisitas dereferencia



soluciones propuestas después de la entrevista con los proveedores que presentanla oferta.

El ejercicio de evaluación de la idoneidad del plan de adaptación y del plan deprestación de servicios es muy similar al ejercicio de definición de dichos planes.Supone un correcto entendimiento de la situación del problema, aunque puede quese hayan identificado riesgos distintos debido a diferencias a la hora de calificar losfactores situacionales. Dado que la calificación es subjetiva, tiene la máximaimportancia entender su justificación. De este modo se suelen resolver muchosmalentendidos 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 laadaptació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-tancia

Oferta 1 Oferta 2

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 lafigura 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 laorganización del proveedor, para obtener el resultado final de la comparación deofertas.

Se recomienda el uso sistemático de los criterios de evaluación en la petición deofertas. Diferentes personas y grupos de trabajo pueden encargarse de aspectosconcretos y elaborar una recomendación escrita. Una vez se han evaluado todoslos aspectos, podrá llevarse a cabo la comparación general. De este modo seexplicitan la evaluación de los aspectos individuales y la valoración final general, altiempo que se facilita la gestión de los conflictos de interés que surgen a menudo.

Evaluar el plande adaptación yel plan deprestación deservicios

Realizar unacomparacióngeneralsistemática detodos losaspectos



Seleccionar la mejor oferta e informar a los proveedores que han presentadooferta

Deberá seleccionarse la mejor oferta en base al proceso de comparación. Esimportante que la conclusión se base en una evaluación unificada de todo el equipode evaluación. Puede surgir el problema de que varias de las personas queintervienen en la evaluación, que informan de distintos aspectos, tengan unaopinión muy definida respecto a que una oferta en concreto es claramente la mejorpara el aspecto concreto que les concierne. Sin embargo, no tendrán en cuentaotros aspectos que escapan a su apreciación. Un proceso de comparaciónsistemático como el que se ha descrito anteriormente facilitará una evaluaciónunificada.

Todos los resultados y conclusiones de la evaluación deberán constar en uninforme de evaluación del proveedor, cuya finalidad será:

• documentar con quién se debe celebrar el contrato

• 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 compradel SI.

El informe de evaluación del proveedor constituye la base para las notificacionesque informan a los proveedores de si han sido seleccionados o rechazados.

2.2.1.4 Preparación del contrato

Objetivo: Acordar un contrato coherente con los requisitos actuales y que permitagarantizar 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 formafinal del contrato. Este proceso finaliza con la firma formal del contrato o bien conla retirada de una de las partes del proceso contractual. Las negociaciones secaracterizan por la consideración de las cuestiones conocidas relativas a aspectos

Utilizar unaevaluaciónunificada

Elaborar uninforme deevaluación delproveedor

CC SC

CPCS

SPSS

Firma formal oretirada delproceso delicitación



técnicos, financieros, de gestión y de calidad, y se lleva a cabo dentro del marcojurídico de los contratos.

En ciertas situaciones, existirán contratos preliminares que se habrán preparado ydiscutido con cada uno de los proveedores que formen parte de la lista en una faseanterior del proceso de licitación, por ejemplo antes de adoptar la decisión deadjudicar un contrato al proveedor cuya oferta resulte ganadora (la selección delproveedor). No obstante, la preparación del contrato corresponde al momento enque ha finalizado la oferta técnica completa, incluyendo el plan de entregascontractual.



En caso de que la adjudicación de contratos públicos esté sujeta a los reglamentosde 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 deaspectos fundamentales de los contratos, en particular los precios, cuya variaciónpodría desvirtuar la competitividad. Se permiten discusiones con los proveedorescon la finalidad de clarificar la oferta y los requisitos del cliente, siempre que ellono conlleve una discriminación de algún proveedor o limite la competitividad. Enesta situación, en función de los resultados de cualquier discusión y clarificaciónpermitidas, el plan de entregas y las descripciones de los sistemas y serviciosincluidas en la oferta deberán incorporarse al contrato sin sufrir modificacionessubstanciales (aparte de las aclaraciones y añadidos permitidos que se hayanacordado como resultado de la evaluación de la oferta por parte del cliente). Noexisten restricciones a las negociaciones posteriores a la licitación cuando loscontratos se adjudican según el procedimiento negociado.

Tal y como refleja la figura 2.18, las actividades realizadas durante la preparacióndel contrato consisten en alcanzar un acuerdo entre el cliente y el proveedor yfirmar el contrato. A continuación se dan orientaciones acerca de las respectivasfunciones 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 unaclarificación, o una solicitud de modificación, de la oferta. Las solicitudes demodificación pueden proceder del cliente o del proveedor.

Cuando convenga, la propuesta de contrato del proveedor seleccionado podrápuntualizarse en los siguientes aspectos, por ejemplo: objetivos, requisitos ysoluciones, plan de entregas, organización y planes del proyecto, importes yprecios, 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 manerassiguientes:

• incorporando los resultados de las negociaciones contractuales en torno a lassoluciones de los sistemas y servicios, por ejemplo puntualizando cada unade las descripciones de los servicios contractuales, incluyendo las tareas yresponsabilidades de la organización del servicio y del responsable delservicio

6 En aquellas situaciones contractuales en que no se permita ningún tipo de negociación y nose pueda tomar la oferta como base del contrato, la única opción disponible es repetir todoel proceso de licitación.

Clarificar omodificar laoferta delproveedor



• A llevando a cabo actividades de planificación detalladas acerca de lasadaptaciones, 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 losservicios, 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

El objetivo del cliente es adjudicar un contrato que sea coherente con los requisitosactuales y que permita garantizar el máximo provecho de los fondospresupuestados. 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 solicitaruna modificación de la oferta

• revisar la versión final del contrato

• decidir si el proveedor seleccionado y el contrato propuesto aún satisfacenlos intereses de la organización del cliente.

El objetivo del proveedor es obtener un contrato que esté de acuerdo con losrequisitos de compra del sistema de información negociados con el cliente, altiempo que se mantienen los beneficios comerciales identificados en la ofertaoriginal. El responsable contractual del proveedor deberá:

• llevar a cabo un análisis de las repercusiones de un cambio propuesto yelaborar el plan de entregas, el plan de servicio y el plan del proyecto segúnlas modificaciones introducidas

• decidir si el contrato propuesto aún satisface los intereses de la organizacióndel proveedor.

Firmar el contrato

CC SC

CPCS

SPSS

CC SC

CPCS

SPSS

CC SC

CPCS

SPSS



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 lasadaptaciones y prestaciones de servicios definidas en el contrato, es decir,asegurarse de que los entregables y los servicios son conformes a los requisitosespecificados.

Al pasar del proceso de licitación al proceso de seguimiento del contrato, laresponsabilidad del cliente sobre la compra del SI pasa de dirigir el proceso acontrolar un proceso que dirige el proveedor.

A partir de ese, momento la cooperación entre el cliente y el proveedor tiene lugaren dos niveles separados:

• En el nivel contractual, el proveedor colabora formalmente con el cliente entodos los puntos de decisión del plan de entregas. En este caso, el clientesupervisa y controla las actividades del proveedor.

• En el nivel de proyecto/servicio, el cliente proporciona los recursos quepermiten la retroalimentación de los procesos de realización del proyecto yprestación del servicio. Es decir, el cliente colabora con el proveedoraportando pericia operativa a la organización del proyecto/servicio a fin desatisfacer los requisitos del plan de entregas. En este caso, el clientegarantiza que cumple con sus propias responsabilidades oportunamente.

Este tipo de cooperación es un proceso impulsado por decisiones. En determinadosmomentos, el cliente y el proveedor toman decisiones relativas a las entregas(entregables y servicios), costes, calendario y otros asuntos contractuales. Larelación cliente-proveedor en esta situación se define en el plan de entregas, véasefigura 2.19.

Proceso de licitación Proceso de seguimiemnto del contrato

Plan de entregaspara el proceso de seguimiento del contrato

define

Puntos de decisión del proceso de seguimiento del contrato

El plan de entregasse realiza en

Ejecución de unpunto de decisión

Figura 2.19.: Función del plan de entregas en el seguimiento del contrato

CC SC

CPCS

SPSS

Un procesodirigido por elproveedor

Un procesoimpulsado pordecisiones



En el proceso de seguimiento del contrato, el plan de entregas sirve de guía para lavalidación de las entregas y la ejecución de los puntos de decisión. Este proceso sesubdivide en un conjunto de decisiones relativas al dominio contractual, al dominioobjetivo y al dominio del proyecto/servicio, es decir, relativas al sistema deinformación que se adapta, al nivel de servicio que se alcanza.

A En las adaptaciones, estas decisiones son cruciales para el cliente, ya quedeterminarán las propiedades del estado final del SI, y son igualmente importantespara 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 decisionesacerca 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 deentregas debidas a cambios de los valores de los factores situacionales, por ejemploque el trabajo progresa más deprisa o más despacio de lo esperado.

La ejecución del punto de decisión es el proceso por el que la organización delcliente emite juicios y adopta decisiones en base a la situación de la compra del SIen cualquier momento dado. La descripción de los puntos de decisión dentro delplan de entregas es la que determina la finalidad del punto de decisión, lasactividades 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 entregablesprocedentes del proveedor o del cliente, y con uno o más servicios prestados por elproveedor. Estos entregables se especifican en la descripción de los puntos dedecisión, bien como condiciones necesarias, bien como las bases para lasdecisiones.

Los entregables especificados como condiciones necesarias deberán entregarseantes del inicio de la ejecución del punto de decisión. Puede tratarse de entregablesdel dominio objetivo o de entregables de gestión del proyecto y del servicio, y seutilizan para señalar un momento claramente definido en el contrato. En lapreparación de la toma de decisiones, es preciso comprobar que todos losentregables sean conformes al plan de entregas. Eurométodo proporcionaorientaciones de cara a este proceso.

La base de una decisión puede consistir en una propuesta de punto de decisión(preceptiva) y un informe de situación del contrato. El resultado del punto dedecisión deberá documentarse siempre en un informe de punto de decisión.

Cuando se entrega un conjunto de entregables, el plan de entregas ya ha definidoclaramente cuáles son las finalidades del punto de decisión asociado y cuáles sonlas funciones necesarias. De este modo se consigue una visibilidad mucho mayor dela progresión del contrato y de las decisiones que deben adoptarse en materia deinversió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 puntode decisión, y seguidamente se formulan orientaciones para dichas actividades.

Decisionesrelativas aldominiocontractual, aldominio objetivoy al dominio delproyecto/servicio

Ejecución delpunto dedecisión

Condiciónnecesaria: unhito de losentregables

Una propuestade punto dedecisión espreceptivaDescripción delos puntos dedecisión



Objetivo: Evaluar la progresión de la compra del SI y adoptar las decisionesapropiadas 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óndentro del seguimiento del contrato

(ejecutadas por los responsables de un proyecto/servicio).

2.2.2.1 Validar los entregables del dominio objetivo

A Los entregables del dominio objetivo se componen de elementos operativos(sistemas) y elementos descriptivos (descripciones del sistema y descripciones delos servicios), véase apartado 3.4: Entregables del dominio objetivo. Losprocedimientos para garantizar la calidad de los entregables del dominio objetivoantes de su entrega deberán especificarse en las descripciones de los sistemas(propiedades de calidad) o en los perfiles de los elementos descriptivos (estado decalidad), véase apartado 3.6: Elementos descriptivos, y apartado 4.5: Descripciónde los entregables. La organización, procedimientos y calendario de validacióndeberán especificarse en la descripción de los puntos de decisión, véase apartado4.4.3: Describir los puntos de decisión.

La mayoría de los entregables del dominio objetivo los entrega el proveedor alcliente. En ocasiones es posible que el cliente tenga que realizar una entrega alproveedor. Son ejemplos de ello la entrega de soportes físicos del dominioobjetivo, los productos del estado inicial o los paquetes en que se basará laadaptación. En estas circunstancias, el cliente deberá garantizar la calidad antes dela entrega y el proveedor deberá validar la entrega. La situación generada cuandola entrega no se realiza a entera satisfacción del proveedor encierra potencialmenteel mismo tipo de repercusiones que la situación en que el cliente rechaza lasentregas que ha realizado el proveedor. A continuación se dan orientaciones acercade la situación que se produce cuando el proveedor efectúa una entrega al cliente.

CC SC

CPCS

SPSS

Repercusionesde la falta decalidad de losentregables delcliente



Cuando concluye la fase de producción de varios entregables, el proveedor deberávalorar si su estado es suficientemente bueno para entregarlos. La función delproveedor es entregar los entregables que satisfacen las expectativas del cliente,recibir la aprobación de dichos entregables y, por tanto, el permiso para continuarcon la adaptación. El responsable contractual del proveedor deberá valorar si losentregables cumplen los requisitos del contrato antes de entregarlos a laorganización del cliente. De ser así, el responsable contractual decide efectuar laentrega formal.

Al recibir los entregables, el responsable de proyecto del cliente tiene la función decontrolarlos, a fin de garantizar que son coherentes con el objetivo de laadaptación, que consiste en que los entregables finales sean los que precisa laorganización; y de este modo cumplir los requisitos definidos en el contrato. Lasdescripciones de los sistemas y los perfiles de los elementos descriptivos tambiénsirven de base para validar los sistemas y los elementos descriptivos,respectivamente, después de su entrega. Los siguientes elementos se utilizan comobase para validar entregables:

• La descripción asociada de los puntos de decisión

• Las descripciones asociadas de los sistemas o los perfiles de los elementosdescriptivos

• El estado de calidad de cada entregable para comprobar si cumplen losrequisitos de compra del sistema de información determinados para estadecisión.

La siguiente lista de comprobación puede utilizarse para validar los entregables deldominio objetivo:(þ 3.5: Elementos operativos; 3.6: Elementos descriptivos)

• ¿Se ha conseguido que el entregable cumpla por completo los requisitos delpunto de decisión?

• ¿Se ha demostrado que el entregable es idóneo para esta situación, tal ycomo afirma el proveedor?

• ¿ Cubren los elementos descriptivos todas las visiones y propiedadesfuncionales necesarias para satisfacer los requisitos de la descripción delpunto de decisión?

• ¿Abordan los elementos descriptivos todas las propiedades de calidad y deinversión necesarias para satisfacer los requisitos de la descripción del puntode decisión?

• El alcance, nivel de detalle, nivel de acuerdo y grado de formalismo de loselementos descriptivos, ¿son coherentes con los que se especifican en ladescripción del punto de decisión?

• ¿Se simulan los elementos descriptivos (por ejemplo, con un prototipo) si lorequiere la descripción del punto de decisión?

CC SC

CPCS

SPSS

CC SC

CPCS

SPSS

Lista decomprobaciónpara lavalidación de losentregables deldominio objetivo



• La versión del sistema (ya sea actual o futura) que contemplan los elementosdescriptivos, ¿es coherente con la que se especifica en la descripción delpunto de decisión? ¿Existen soluciones alternativas si se solicitan?

• ¿Se han observado todas las normas de coherencia interna y externa de loselementos descriptivos?

Ejemplo: Una de las reglas de coherencia es que cada uno de loselementos de datos de un modelo de datos debe aparecer almenos en una función automatizada. Una de lascomprobaciones de coherencia de la revisión de calidad delmodelo de datos del futuro sistema antes mencionado podríaconsistir en verificar que cada elemento de datos se contemplaal menos en una función automatizada.

• ¿Poseen los elementos operativos la funcionalidad y las características decalidad necesarias? Para validar este aspecto deberán utilizarse métodos decomprobación, técnicas y herramientas adecuados.

El resultado de la validación deberá documentarse en un informe del proyecto. Elresultado 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 losentregables de gestión del proyecto y del servicio (informes y planes) que exige ladescripción del punto de decisión y entregarlos a los responsables contractuales delcliente y del proveedor.

S Los informes de servicio deberán basarse en mediciones sistemáticas de lacalidad de los servicios prestados (los niveles de servicio realizados), por ejemplouna medición de referencia realizada por el propio personal del cliente en intervalosregulares, 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 ellopodrá utilizarse la siguiente lista de comprobación.

• ¿Se ha conseguido que los entregables cumplan por completo los requisitosdel punto de decisión?

• ¿Se ha demostrado que los entregables son idóneos para esta situación, tal ycomo afirman el proveedor y los responsables del proyecto/servicio?

7 En ciertos casos, esta tarea la desempeñan los responsables del proyecto/servicio delproveedor por sí solos, y en otros, los responsables del cliente y del proveedorconjuntamente. Ello deberá clarificarse en el plan de entregas.

CC SC

CPCS

SPSS

CC SC

CPCS

SPSS



• ¿Incluyen los entregables todas las propiedades y alcanzan el estado decalidad necesario para satisfacer los requisitos de la descripción de los puntosde decisión?

La supervisión de una adaptación consiste en supervisar un proceso de cambiodurante el cual van apareciendo entregables del dominio objetivo, mientras que lasupervisión de una prestación de servicios consiste, sobre todo, en garantizar queun cierto estado, el nivel de servicio pactado, no varía, a menos que ello se solicitede forma específica.

Generalmente esto significa que la validación de los entregables del dominioobjetivo es una parte fundamental de la supervisión de las adaptaciones(proyectos), mientras que la supervisión de las prestaciones de servicios tiene lugarprincipalmente tomando como base los informes de servicio.

2.2.2.3 Proponer decisiones (alternativas) (propuesta de punto dedecisión)

Los responsables del proyecto/servicio del proveedor8 deberán elaborar propuestasde decisiones, por ejemplo proponer y recomendar varias soluciones para el SI ylos servicios o varios escenarios para las adaptaciones y prestaciones de servicios.Estas recomendaciones son parte de una propuesta de punto de decisión, pero sebasan en entregables del dominio objetivo y entregables de gestión delproyecto/servicio (planes e informes).(þ 3.2.2: Entregables del punto de decisión; anexo D.8: Plantilla de propuesta depunto de decisión)

Se abordan temas de planificación como la estimación, organización,programación, empleo de personal, coordinación y cálculo de costes, además detemas de control como la supervisión, medición, análisis de la desviación, análisisde progresión y evaluación, al objeto de desarrollar una conjunto adecuado depropuestas dentro de la propuesta de punto de decisión.

Decisiones sobre las adaptaciones

A En cuanto a las adaptaciones, las técnicas de planificación de la adaptaciónpueden utilizarse para evaluar las repercusiones de problemas concretos; es decir,el punto de partida para el desarrollo de las propuestas de decisión pasa por unavaloración de la situación del problema. Ello puede dar lugar a que los valores delos factores de situación difieran de los valores establecidos antes de que seprodujeran los problemas. (þ 4.2.2: Evaluar los factores de situación)

Dentro de una propuesta de punto de decisión, el cliente o el proveedor puedenproponer varios tipos de opciones:

• 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 delproveedor por sí solos, y en otros, los responsables del cliente y del proveedorconjuntamente. Ello deberá clarificarse en el plan de entregas.

CC SC

CPCS

SPSS

Temas deplanificación ycontrol quedeben abordarse

Valorar lasituación delproblema

Tipos deopciones dedecisiones



• modificar ligeramente el plan del proyecto

• repasar varios o todos los entregables

• modificar o clarificar los requisitos de compra del SI, registrando los avancesrealizados en la comprensión de los objetivos y requisitos contractuales; ellopuede requerir la modificación del contrato

• realizar modificaciones técnicas importantes que precisen cambios radicalesde los requisitos de compra del SI, de los planes y del propio contrato; lo quemotivará 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 enun informe de situación del contrato, véase la siguiente actividad. A continuaciónse 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 certezaabsoluta de que el cliente los aprobará. Sin embargo, es posible que esto no sucedasiempre en el caso de proyectos vivos, por lo que en determinadas circunstanciasserá inevitable repasar los entregables.

Las técnicas de planificación de la adaptación explican cómo minimizar el riesgo deun repaso no planificado, desarrollando planes de adaptación que se ajusten a unadeterminada situación del proyecto y que por tanto se adapten a las situaciones quese produzcan. Por ejemplo, una situación del problema en la que los requisitosevolucionan con rapidez puede gestionarse utilizando un plan de adaptacióndesarrollado en base a un enfoque experimental de la descripción y un enfoqueevolutivo de la construcción.(þ 4.3.3: Seleccionar las opciones estratégicas)

No obstante, existen muchas razones por las que un entregable puede entregarsesin cumplir todos los requisitos previstos. Ello puede deberse a carencias de laorganización del cliente o de la del proveedor. Los siguientes ejemplos provocaríanun repaso de los entregables:

• Los entregables no eran conformes a los requisitos.

• Los rápidos cambios que experimentaron las circunstancias de laorganización del cliente no se tuvieron en cuenta en su totalidad, de maneraque los entregables reflejaban una situación del problema obsoleta.

El repaso de los entregables precisará que los responsables de proyecto del clientey 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 derecursos en la adaptación.

• propongan cambios en el plan del proyecto. A

Opción: repasarlos entregables



Decisiones sobre las prestaciones de servicios

S Durante la prestación del servicio, el cliente o el proveedor pueden solicitar uncambio en el servicio.

La implementación de estos cambios puede o no formar parte de la prestación delservicio, en función del plan de prestación de servicios y de la importancia delcambio. Si el cambio no es importante, puede gestionarse dentro de un servicio degestión de cambios.

Si el cambio es demasiado importante, habrá que llevar a cabo una instalación delservicio. Esto se gestiona mediante un cambio formal del contrato, si éste posee laflexibilidad 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 delcontrato)

Los responsables de un proyecto/servicio del proveedor9 deberán elaborar uninforme de situación del contrato cuando así lo requiera la descripción del punto dedecisió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 delcontrato)

Habrá que informar de la situación general de todas las adaptaciones y prestacionesde servicios que se están llevando a cabo actualmente. Cualquier desviación delplan de entregas deberá reflejarse en el informe, junto con las propuestas deacciones correctivas y cambios del plan de proyecto y del plan de servicio. Todaslas propuestas de modificación del contrato deberán estar argumentadas. Puedenproducirse cambios del plan de entregas, de las descripciones de los sistemas, delas descripciones de los servicios o de otros elementos del contrato.

Deberá presentarse y explicarse todo desacuerdo entre el responsable de proyectodel cliente y el del proveedor para que lo resuelvan los responsables contractuales.

En los siguientes capítulos figura más información sobre la necesidad de un controlde los cambios contractuales, incluyendo los casos de renegociación del contrato ycumplimentación anormal del contrato.

Control de cambios contractuales

El control de cambios contractuales puede planificarse en el plan de entregas: éstees el caso de los contratos flexibles, véase apartado 2.1.2.3: Opción: determinar laflexibilidad de los contratos, donde el plan de entregas incluye puntos de decisiónde inversión específicos para puntualizar los requisitos de compra del SI. El controlde cambios deberá realizarse de acuerdo con los procedimientos de control de loscambios especificados en el contrato.

9 En ciertos casos esta tarea la desempeñan los responsables del proyecto/servicio delproveedor por sí solos, y en otros, los responsables del cliente y del proveedorconjuntamente. Ello deberá clarificarse en el plan de entregas.

Necesidad deadaptación de losservicios

CC SC

CPCS

SPSS

Planificado bajocontratosflexibles



Importante: • El proceso de control de los cambios contractualesdebe estar descrito en el contrato.

El control de los cambios contractuales también puede ser activado durante elproceso 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 gestionarclaramente con la solución técnica del contrato existente. A menudo, el control delos cambios contractuales tiene lugar tras la evaluación de varios entregables o dela propia realización del proyecto/prestación del servicio, en la que se identificancambios contractuales a fin de reducir una amenaza.

El control de los cambios contractuales consiste en que ambas partes contratantesacuerdan cambios de los requisitos del SI o de otros elementos del contrato.Normalmente estos cambios suponen una pequeña modificación o clarificación deun requisito ya existente. En la inmensa mayoría de los casos, los cambiosefectuados no repercuten substancialmente en el contenido y la intención delcontrato. Simplemente se registran los avances que se producen en la comprensiónde los objetivos y los requisitos contractuales.

La siguiente lista de comprobación permite identificar situaciones en las que puedeser 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 lanecesidad de llevar a cabo alguna mejora o actualización de los requisitos decompra del SI?

• ¿Alguna de las especificaciones del contrato ya no es aplicable a la compradel SI y conviene eliminarla para evitar posibles confusiones?

En base a la experiencia podrán identificarse otras situaciones. Ejemplos de loscambios que pueden efectuarse:

• llevar a cabo un nuevo análisis de la situación del problema y comprobar silas conclusiones iniciales acerca de las estrategias de adaptación y deprestació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 elplan de prestación de servicios

• redefinir las responsabilidades dentro del plan de adaptación o del plan deprestación de servicios

• introducir puntos de decisión adicionales.

En ciertas circunstancias puede que se precisen cambios técnicos importantes querequieran modificaciones radicales de los planes y del propio contrato. Noobstante, cualquier renegociación de asuntos contractuales, por ejemplo elcalendario jurídico y financiero, deberá gestionarse en base a las prácticasempresariales habituales (que se encuentran fuera del alcance de Eurométodo).Normalmente, las modificaciones del contrato tienen que ser firmadas por personasequiparables a las que firmaron los contratos originales.

Pequeñoscambios delcontrato

Renegociacióndel contrato



La Directiva de Servicios (92/50/CEE) establece que si un cliente introduce algúncambio 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 seidentifica uno o más requisitos adicionales distintos de los que incluía la petición deofertas original, dichos requisitos sólo podrán adjudicarse al proveedor original sinnecesidad de volver a presentar una petición de ofertas en le caso de que porrazones imprevistas se hayan hecho absolutamente necesarios para la ejecución delcontrato, o por motivos técnicos o económicos imperiosos causarían grandesperjuicios al cliente si se adjudicara el contrato a otro proveedor dentro de unlímite del 50% del valor original del contrato.

Posibles escenarios en los que puede hacerse necesaria la renegociación delcontrato:

• el cliente detecta que los requisitos de los entregables y serviciosmencionados en el contrato ya no concuerdan con los objetivos del negocioy, por tanto, desea cambiarlos al objeto de garantizar que reciba losentregables y servicios necesarios

• el cliente detecta que el proveedor no cumple los requisitos de losentregables y servicios

• el proveedor detecta que las expectativas reales del cliente no son coherentescon los requisitos establecidos y, por tanto, desea introducir cambiossignificativos en el contrato a fin de evitar riesgos al aceptar el trabajo

• el proveedor determina que el desarrollo del sistema o la prestación deservicios no es viable.

En los entornos jurídicos en que los contratos estén sujetos a las reglas de laUE 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 contratosi no se vuelve a presentar una petición de ofertas. En tal situación, losrequisitos de compra del SI serán invariables para toda la duración delcontrato.

En las siguientes situaciones se considera que las prestaciones de una de las partescontratantes perjudica a la progresión del contrato.

• Se considera que las prestaciones del proveedor son parcial o totalmenteinsatisfactorias de cara a la consecución de los objetivos del contrato. Porconsiguiente, el cliente podrá solicitar que se suspenda el acuerdocontractual 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 contractualesjunto 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 lacancelación de la compra del SI, véase apartado 2.2.3: Cumplimentación delcontrato.

Cumplimentaciónanormal delcontrato



2.2.2.5 Adoptar decisiones y comunicarlas (informe de punto dedecisión)

El propio proceso de toma de decisiones es un proceso cooperativo en el queparticipan activamente el responsable contractual del cliente y el del proveedor.

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

• El responsable contractual del cliente es quien toma las decisiones, mientras queel responsable contractual del proveedor actúa como asesor y controla si lasdecisiones del cliente son conformes a los acuerdos contractuales.

• El responsable contractual del cliente y el del proveedor comparten laresponsabilidad de la toma de decisiones.

Se aplicarán la organización y procedimientos previstos en la descripción del puntode decisión. Podrán utilizarse todas las técnicas de toma de decisiones: decisionesen grupo, simulaciones, previsiones, análisis de riesgos, análisis de costes ybeneficios, 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 registrarconjuntamente todas las decisiones que contenga un informe de punto de decisióny distribuirlo convenientemente.(þ 3.2.2: Entregables del punto de decisión; anexo D.10: Informe de punto dedecisión)

Es preciso documentar con todo rigor cualquier cambio que se produzca en losrequisitos de compra del sistema de información, ya se haya decidido a raíz de uncontrol planificado de cambios contractuales (en un punto de decisión deinversión), ya se haya acordado al amparo de un control de los cambioscontractuales activado por las circunstancias. Para asegurar una cumplimentaciónefectiva 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 serviciodeberán revisarse de acuerdo con las decisiones. Asimismo, en el informe de puntode decisión podrán identificarse varias acciones correctivas. Estas acciones podrárealizarlas, por ejemplo, la organización del proveedor a fin de mejorar susprocesos.

De este modo, las decisiones pueden motivar la instigación de un programa demejora de procesos que se desarrolle paralelamente a las adaptaciones y lasprestaciones de servicios. Las cuestiones relativas a la mejora de procesos podrántratarse con las técnicas definidas en las especificaciones actualmente disponiblessobre evaluación de la capacidad y la madurez del proceso.

CC SC

CPCS

SPSS

CC SC

CPCS

SPSS

Registrar loscambios de losrequisitos

CC SC

CPCS

SPSS

Puede iniciarseun programa demejora deprocesos



Como Eurométodo ofrece los medios para clarificar el proceso de entrega y laadopción de decisiones que comporta, proporciona un marco ideal en el que reunirlas experiencias de adaptaciones y prestaciones de servicios. En particular, facilitael registro de todo lo necesario en un entregable que contenga un productoparticular del método para soportar una decisión particular, y, a la inversa, lo queno es necesario. Así pues, el cliente y el proveedor tienen los medios para utilizarsus observaciones como ayuda para adaptar el proceso de toma de decisiones a lamedida de las exigencias de futuros contratos. Por consiguiente, podrá mejorarse ladescripción de los entregables necesarios en futuras compras.

Para cada punto de decisión deberán tenerse en cuenta los siguientes aspectos.

• ¿Qué partes del entregable (y por tanto los productos del método que loconstituyen) se ha observado que facilitan el proceso de toma de decisiones?

• ¿Se ha observado en el entregable algún concepto que no facilite el procesode toma de decisiones?

• ¿Cumple el entregable con igual efectividad todos los requisitos de ladescripción del punto de decisión?

• Para aquellos aspectos de la descripción del punto de decisión que elentregable no cumplió con efectividad, ¿qué habrá que hacer en el futuropara obtener un entregable de mejor calidad?

Registrar lasexperienciaspara utilizarlasen comprasfuturas

Cómo mejorar ladescripción delos puntos dedecisión



2.2.3 Cumplimentación del contrato

Objetivo: Garantizar que se han resuelto satisfactoriamente todas las cuestionestécnicas y comerciales pendientes relativas a este contrato de compra del SI

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 losentregables y los asuntos pendientes del contrato, de manera que se pueda cancelarde forma efectiva el acuerdo contractual entre un cliente y un proveedor.

Representa el final de todas las adaptaciones y servicios contemplados en elcontrato y, por tanto, el final de la relación temporal cliente-proveedor que seinició con motivo de la compra del SI.

Los responsables contractuales deberán comprobar que se han realizadoefectivamente todas las entregas y que ambas partes han cumplido todas susobligaciones. Todas las cuestiones pendientes (por ejemplo, pagos, transmisión dela propiedad, garantía, etc.) deberán resolverse antes de cancelar el contrato. Lacumplimentación del contrato es un proceso administrativo que controla si se hancumplido de forma satisfactoria todos los requisitos de compra del SI.

Las actividades encaminadas a la cumplimentación del contrato se relacionan en lafigura 2.21.

Normalmente, la cumplimentación del contrato precisa la cumplimentación del plande entregas, que se produce cuando concluyen todos los entregables y decisionescontractuales, véase figura 2.22.

CC SC

CPCS

SPSS

Lacumplimentacióndel contrato esun procesoadministrativo



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 delcontrato)

En base al informe de proyecto y al informe de gestión del servicio, losresponsables del proyecto/servicio del proveedor10 deberán elaborar un informefinal de situación del contrato que sustente las decisiones de cumplimentación delcontrato. Los siguientes elementos de la lista de comprobación deberán tenerse encuenta al desarrollar la base para estas decisiones:(þ 3.2.2: Entregables del punto de decisión; anexo D.9: Informe de situación delcontrato)

• Aspectos 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 sistemaoperativo funciona perfectamente?

− ¿Se ha proporcionado a ambas partes toda la información de planificaciónpreviamente pendiente acerca de futuras adaptaciones y prestaciones deservicios en estudio?

10 En ciertos casos esta tarea la desempeñan los responsables del proyecto/servicio delproveedor por sí solos, y en otros, los responsables del cliente y del proveedorconjuntamente. Ello deberá clarificarse en el plan de entregas.

Proceso de cumplimentación

Cumplimentacióndel contrato

Ejecución delpunto de decisión n

dentro del plan de entregas

Plan de entregasconcluido en

Proceso de seguimiento

Punto de decisión de cumplimentación del contrato

CC SC

CPCS

SPSS

Aspectostécnicos



− ¿Se ha cumplimentado y entregado toda la documentación de revisión decalidad?

− ¿Se ha ultimado y entregado toda la documentación de usuario?

• Aspectos comerciales y jurídicos:− ¿Se han abonado todos los subcontratos?− ¿Se han emitido todas las facturas a las organizaciones pertinentes?− ¿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 unao más actividades. Por ejemplo, se pueden iniciar nuevas negociacionescontractuales (o quizá presentar una nueva petición de ofertas) para abordar eltema de las relaciones poscontractuales, es decir, iniciar una nueva compra de unsistema de información o finalizar el servicio de mantenimiento o de garantía. Otroejemplo es el caso de una cancelación anormal de la compra del SI. En este caso, laejecución de este proceso puede tener lugar al mismo tiempo que la renegociacióndel contrato.

Estas relaciones deberán tenerse en cuenta al desarrollar la propuesta de punto dedecisión, a fin de garantizar que la relación con el proveedor sea coherente ygestionable.

2.2.3.2 Adoptar decisiones de cumplimentación del contrato

Las decisiones de cumplimentación basadas en el informe de situación del contratodeberán adoptarse teniendo en cuenta los aspectos técnicos y comerciales en elcontexto de una cumplimentación programada o no programada, tal y como semenciona 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 deir cancelando todos los aspectos técnicos, de gestión y financieros de la adaptaciónde una manera progresiva y controlada, tal y como recomienda el informe desituación del contrato.

El responsable contractual del cliente cancela la relación contractual con elproveedor sin olvidar las repercusiones en el negocio de las tareas residuales detipo técnico y comercial, y registra todas las experiencias importantes relativas a lacompra del SI.

El responsable contractual del proveedor asegura que el contrato expira en elmomento debido, dejando una puerta abierta a posibles oportunidades de negocioen 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 proveedordeberán colaborar en la realización de un informe de cumplimentación del contrato,

Aspectoscomerciales yjurídicos

Dependenciasrespecto a otrasactividades

CC SC

CPCS

SPSS

CC SC

CPCS

SPSS



véase una descripción del mismo en el apartado 3.2.3: Entregables del punto dedecisión. La finalidad del informe es registrar todas las decisiones adoptadasdurante la cumplimentación del contrato y reflejar hasta qué punto el contrato haconseguido sus objetivos de negocio, incluyendo los beneficios previstos; ademásde 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 delcontrato)

El informe de cumplimentación del contrato no se presenta hasta el final delperíodo del contrato. Antes de que expire el contrato es posible que hayanfinalizado una o más adaptaciones y servicios.

¿Qué lecciones deben extraerse de esta compra del SI para ser utilizadas enfuturas compras de SI?

Eurométodo proporciona un marco que permite extraer experiencias para su usoposterior en un contrato, dominio objetivo o dominio del proyecto/servicio, yregistrar posteriormente lo que se precisa para sustentar el proceso de toma dedecisiones que requieren las relaciones cliente-proveedor. Este marco puedeaplicarse en la cumplimentación del contrato para considerar en su totalidad lacompra del SI.

El cliente dispone de los medios para utilizar sus propias observaciones a fin deestablecer los requisitos de futuras adaptaciones y prestaciones de servicios, y deese modo formular mejor las exigencias del proceso de toma de decisiones defuturas compras de un SI.

El proveedor dispone de los medios para utilizar sus propias observaciones a fin dedesarrollar futuros procesos de producción, y de ese modo cumplir mejor lasexigencias del proceso de toma de decisiones de futuras compras de un SI.

Asimismo, el cliente y el proveedor tienen la oportunidad adicional, dentro delproceso de cumplimentación del contrato, de realizar una síntesis de toda larelación cliente-proveedor, y de esta manera contar con una referencia de lo quesería la buena práctica en esta área tan compleja.

El objetivo es aprender de la experiencia: para sustentar el proceso de decisiónen futuras compras de SI, y para evitar el riesgo de que la calidad de los SI oservicios adaptados que se compren sea mala o insuficiente.

Registrar lasexperienciaspara utilizarlasen futurascompras de SI



Esta revisión de cumplimentación del contrato puede utilizar de nuevo las listas decomprobación relativas a las lecciones extraídas de cada punto de decisión delproceso 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 y5 a través de las referencias apropiadas.

Los conceptos de entregables de Eurométodo permiten caracterizar los entregablesque intercambian clientes y proveedores en toda compra de SI. Todos losentregables, tanto los entregables de adaptación como los entregables deprestació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 elproceso 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 lasprestaciones de servicios. Los entregables de gestión se dividen en dos tipos:

• los entregables de gestión del proyecto se utilizan para planificar y controlarlos proyectos de adaptación

• los entregables de gestión del servicio se utilizan para planificar y controlarlas prestaciones de servicios.

Existen dos tipos de entregables de gestión:

• un plan, o

• un informe.

Capítulo 3Entregables


3.1.3 Entregables del dominio objetivo

Los entregables del dominio objetivo son sistemas o documentos relacionados conel 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á instaladocomo parte del dominio objetivo.

• elemento descriptivo:un documento entregado que recoge conocimientos relativos al dominioobjetivo.Los elementos descriptivos pueden utilizarse para describir sistemas yservicios. Un elemento descriptivo facilita el proceso de toma de decisionesrelativas a una adaptación o prestación de servicios, es decir, especifica loque debería hacer y cómo debería ser el diseño de la organización deldominio objetivo y/o su sistema de información.

La figura 3.1 muestra los principales tipos de entregables arriba mencionados.

del dominio

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 unacuerdo similar dentro de una organización), para el suministro de un servicio opara 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óndel cliente y del proveedor que se encuentran vinculadas temporalmente por losrequisitos 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 SIpuede contener una o más adaptaciones o prestaciones de servicios.

Dentro de una compra de SI, los entregables del dominio contractual sustentan larelación entre:

• un cliente y su proveedor a nivel contractual, es decir, la función de gestióndel 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 puedecaracterizar mediante un subconjunto de propiedades del dominio contractual. Esdecir, estas propiedades representan el contenido lógico de todo entregable deldominio contractual.

3.2.1 Entregables de licitación

Un entregable de licitación se produce como parte del proceso de licitación dentrode una compra de SI. Los entregables de licitación establecen requisitos para todaslas adaptaciones y prestaciones de servicios de una compra de SI.

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 quese facilitan a los proveedores potenciales. Los requisitos de compra de SIcontienen descripciones del sistema, descripciones de los servicios, el plan deentregas y los planes de proyecto/servicio (opcional).

Oferta (þAnexo D.2)

Es el producto que contiene la propuesta técnica de un proveedor potencial parasatisfacer 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. Contienela puntuación otorgada a cada proveedor potencial según los criterios deevaluación del proveedor. Registra qué oferta es la mejor y la más rentable en lapráctica. En él se basan las notificaciones que se envían a cada proveedor paracomunicarle si ha sido aceptado o rechazado.

Plantillas



Contrato (þAnexo D.4)

Un acuerdo vinculante con valor legal entre dos partes (o un acuerdo similardentro 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 delicitación arriba descritos. Cada plan experimenta una transformación: de laversión solicitada se pasa a la versión propuesta, y de ella a la versióncontractual, a medida que se adquieren más conocimientos y la compra del SIavanza 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 versionescambiantes: versión solicitada, versión propuesta, versión contractual.

Se trata del entregable que define la relación contractual cliente-proveedor duranteuna compra de un SI. Cada contrato, oferta y petición de ofertas contienen un soloplan de entregas.

El contenido de un plan de entregas se describe en la figura 3.2 y las relacionesentre 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 cabodentro de una compra de SI. Define la situación del problema incluyendo el estadoinicial y el estado final de la adaptación, la estrategia de adaptación, la secuencia depuntos de decisión y los entregables durante el seguimiento del contrato. Cada plande entregas contiene uno o más planes de adaptación.

Como parte de una adaptación también se pueden producir planes de adaptaciónpara futuras adaptaciones del SI. Por ejemplo, un plan para una adaptación quelleve a cabo el diseño detallado de un SI, o que ejecute la construcción oinstalación del SI, mientras se realiza un estudio de viabilidad del mismo en laadaptació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érminoespecífico: plan de adaptación de una futura adaptación, o plan de adaptaciónfutura.

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 únicoservicio o de un grupo de servicios asociados dentro de una compra de SI. Defineel estado inicial y el estado final de la instalación del servicio y de la cancelacióndel servicio, la estrategia de prestación del servicio, la secuencia de puntos dedecisión y los entregables durante el seguimiento del contrato.



Los planes de entregas, los planes de adaptación y los planes de prestación deservicios contienen descripciones de puntos de decisión. La plantilla de estasdescripciones figura en el anexo D.21.



Plan Contenido

Para cada plan de entregas • Suma de puntos de decisión relativos a cadaadaptación y cada prestación de servicios que tienelugar en una compra de SI.

• Punto de decisión relativo al proceso decumplimentación del contrato.

• Planes de adaptación de una compra de SI.

• Planes de prestación de servicios de una compra deSI.

• Dependencias entre todos los planes de adaptación ylos planes de prestación de servicios de una comprade SI.

Para cada plan de adaptación • Situación del problemaUna descripción del estado inicial y del estado final, yuna descripción de los factores de situación y losriesgos

• 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ónLa secuencia de los puntos de decisión necesarios.

• Descripción de los puntos de decisiónDescripciones de los puntos de decisión necesarios yde los entregables asociados

Para cada plan de prestaciónde servicios

• Situación del problema− 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ónLa secuencia de los puntos de decisión necesarios.

• Descripciones de los puntos de decisiónDescripciones de los puntos de decisión necesarios yde 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 deprestación de servicios

3.2.1.2 Propiedades de los entregables de licitación

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



Propiedad contractual

Entregable de licitación

Descripción

Petición deofertas

Oferta Informe deevaluación

delproveedor

Contrato

Representación deldominio objetivo de lacompra de SI

Suma de las descripciones deldominio objetivo para cadaadaptación y cada prestación deservicios dentro de la compra deSI.

√ √(Visión delproveedor)

__ √

Objetivos de negocio,necesidades y objetivosde la adquisición

Proporciona el contexto esencialen el que tiene lugar una comprade SI

√ √(+ solución)

√ √

Imperativos yprocedimientos(estratégicos)organizativos

Por ejemplo, normas,arquitectura, etc.

√ __ __ √

Requisitos de compra deSI:

El conjunto formado por el plande entregas, las descripciones delos sistemas, las descripciones delos servicios, el plan de proyectoy el plan de servicio, quedescriben los requisitos de unacompra en particular dentro deuna adquisición

Plan de

entregas

Entregable del dominiocontractual que define lasadaptaciones contractuales y lasprestaciones de servicios duranteuna compra

√(Solicitado)

√(Propuesto)

__ √(Contrato)

Descripciones

de los sistemas

Descripciones de los entregablesde los elementos operativos(elementos descriptivos) de quedispone el proyecto; esto puedeincluir los elementosdescriptivos del SI en su estadoinicial y de futuros SI

√(Global/

detallada)

√(Detallada)

__ √(Detallada)

Descripciones

de los servicios

Descripciones de los servicios oprocesos (elementosdescriptivos) de que dispone laprestación de servicios; estopuede incluir los elementosdescriptivos deservicios/procesos en su estadoinicial y de futurosservicios/procesos

√(Global/

detallada)

√(Detallada)

__ √(Detallada)

Plan de

proyecto y plan

del servicio

Para adaptaciones: planes dedesarrollo, planes deaseguramiento de la calidad,planes de gestión deconfiguración.Para servicios: planes de nivel deservicio , planes de recursos deservicio, planes de funciones deservicio

√(Opcional)

√(Opcional)

__ √(Opcional)

Imperativosorganizativos quepueden afectar al plandel proyecto

Por ejemplo, interrupción delpago, lanzamiento de producto yfechas de implementación de lareorganización.

√ ___ __ √(Opcional)

Imperativos financieros /presupuesto

Imperativos sobre costes, fechasde pago, etc.

√ __ __ __

•





Descripción

Petición deofertas


delproveedor

Contrato

Cargos y costes • Los cargos y costes quepercibe o acumula unproveedor al cumplir losrequisitos de una compra deSI.

• Procedimiento de variaciónde cargos durante el períododel contrato

__ √ √

Cláusulas jurídicas • Criterios de adaptación yprestación de servicios

• Condiciones de pago

• Garantías de cumplimientode las obligaciones

• Limitación de laresponsabilidad

• Derechos de propiedadintelectual

• Propiedad del hardware,software y licencias

• Seguridad yconfidencialidad

• Condiciones de rescisión delcontrato

• Normativa aplicable

• En caso de conflicto, quiénactuará como árbitroindependiente

• Control de lasubcontratación

etc.

√ √ __ √

Instrucciones a loslicitantes

Orientación y referencias acercadel formato, modo de envío yfechas límite

√ __ __ __

Característicasorganizativas delproveedor

Por ejemplo, situaciónfinanciera, experiencia denegocio, experiencia con eldominio, certificado ISO9000

√(Requisitos)

√(Conformida

d)

√(Conformida

d)

__

Enfoque de evaluacióndel proveedor

• Tabla de evaluación(criterios, atributos yjustificaciones)

• Procedimiento para realizarla evaluación de las ofertas

√ __ √(Completo)

__

Organización delproveedor

Descripciones del proyecto y delas organizaciones de servicios

__ √ __ √(Opcional)

Funciones yresponsabilidades delequipo de evaluación

Establecer las funciones yresponsabilidades de la periciaoperativa y del responsableorganizativo en la selección delproveedor

__ __ √ __

Recomendacionesacerca del proveedorpreferido

Declaración de qué proveedor seprefiere; y recomendaciones paramejorar la oferta

__ __ √ __





Descripción

Petición deofertas


delproveedor

Contrato

Procedimientos decontrol de cambioscontractuales

Procedimientos para proponer,aprobar y llevar a cabo cualquiercambio del contrato, incluyendocambios de los requisitos de losentregables y servicios,calendario, importes y otrascondiciones contractuales

√(Opcional)

√(Opcional)

__ √

Firmas del contratoAutorización del contrato por losresponsables contractuales o laalta 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 elproceso de toma de decisiones como parte del seguimiento del contrato durante lasadaptaciones 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 lasopciones técnicas y financieras a considerar en un punto de decisión. Unapropuesta de punto de decisión puede proponer opciones relativas a unaadaptación, una prestación de servicios o ambas.

Como base de una decisión, describe el posible resultado de un punto de decisiónen los términos de las decisiones (y recomendaciones) hechas en ese punto dedecisió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 requisitoscontractuales definidos en el plan de entregas, para su consideración en un puntode decisión. Es decir, el informe de situación del contrato informa de todas lasadaptaciones y prestaciones de servicios definidas en el plan de entregas.

Este informe facilita la valoración de los riesgos asociados a la compra y ladefinició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 delas decisiones (y recomendaciones) hechas en ese punto de decisión. Un informe depunto de decisión puede incluir decisiones relativas a una adaptación, unaprestación de servicios o ambas.

Informe de cumplimentación del contrato (un subtipo de informe de punto dedecisión) (þAnexo D.11)

Un entregable que registra si el contrato ha satisfecho efectivamente sus objetivosde negocio, incluyendo los beneficios previstos, e identifica lecciones a extraer envista de futuras compras de SI y gestiones contractuales.

El informe de cumplimentación del contrato no se presenta hasta el final delperíodo contractual. Antes de ese momento es posible que hayan finalizado una omás adaptaciones y prestaciones de servicios, es decir, la cumplimentación de unaadaptación no implica necesariamente la cumplimentación del contrato.



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 dominiocontractual que deben aparecer en cada uno de los entregables de punto dedecisión.




Entregables de punto de decisión

Descripción

Propuestade punto de

decisión

Informe desituación

del contrato

Informe depunto dedecisión

Informe decumplimentación

del contrato

Objetivos del contrato Resumen de los objetivos delnegocio, necesidades y objetivosde la adquisición y requisitos decompra de SI definidos en elcontrato.

__ __ __ √

Descripción del puntode decisión

Según se describe en el plan deentregas.

√ √ √ √

Grupo destinatario delinforme

Público a quien va dirigido esteinforme.

__ __ √ √

Opciones de decisión Las opciones de decisión puedenser de negocio, financieras,técnicas, de gestión yorganizativas.

Para cada opción puedenabordarse los siguientes asuntos:

• Objetivos de alto nivel quese han logrado

• Objetivos y requisitos depunto de decisión que se hancumplido

• Importancia relativa de cadarequisito cumplido

• Análisis de costes/beneficios

• Análisis de lasrepercusiones

• Beneficio actualizado /costes de oportunidad

√ __ √(Seleccionadas)

__

Decisiones adoptadas Selección y/o modificación delas opciones de decisión que setienen en cuenta en el punto dedecisión. Las decisiones puedenser de inversión, de diseño y deaceptación de un sistema

__ __ √ __

Desviaciones respectoal plan de entregas

Las desviaciones con respecto a:

• Calidad

• Calendario

• Presupuesto

• Disponibilidad de recursos

__ √ __ __

Asuntos nuevos de lacompra de SI

• Problemas detectadosdurante la prestación deservicios, el desarrollo delSI o el proceso deaseguramiento de la calidad.

• Riesgos detectados durantela prestación de servicios, eldesarrollo del SI o elproceso de aseguramientode la calidad.

__ √ __ __

Propuestas de accionescorrectivas

Opciones de decisión acerca deacciones correctivas a nivelcontractual.

__ √(si se

precisan)

__ __

Propuestas paracambiar el plan deentregas

Opciones de decisión acerca decuestiones relativas al plan deentregas.

__ √(si se

precisan)

__ __




Entregables de punto de decisión

Descripción

Propuestade punto de

decisión

Informe desituación

del contrato

Informe depunto dedecisión

Informe decumplimentación

del contrato

Propuestas para elcontrol de los cambioscontractuales

Opciones de decisión acerca detemas contractuales de caráctergeneral.

__ √(si se

precisan)

__ __

Descripción de lacumplimentación

Deberán tenerse en cuenta lossiguientes aspectos:

• plazos y recursos de compra

• identificar los problemasque puedan surgir durante elproceso de licitación y elproceso de seguimiento delcontrato

• revisar el proceso degestión de riesgos

• identificar las lecciones degestión contractual aextraer durante elseguimiento del contrato

__ __ __ √

Figura 3.5: Propiedades del dominio contractual de los entregables de punto dedecisión

3.3 Entregables de gestión

Los entregables de gestión del servicio y de gestión del proyecto describen eldominio 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 yconfí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 losrequisitos 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 cadaprestación de servicios y cada proyecto habrá planes e informes específicos; porejemplo, 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 losproyectos.

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 losentregables del dominio objetivo

• facilitar al cliente-proveedor la toma de decisiones relativas a la progresióndel proyecto

• supervisar el proyecto.



Al desarrollar los entregables de gestión para una adaptación, deberán tenerse encuenta 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ónson 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 sedebe realizar el trabajo: estimación, organización, programación, obtenciónde 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 degestión:

• plan del proyectoUn plan es el compromiso de cumplir unos objetivos identificados entérminos de entregables, calendario, recursos, esfuerzos y costes.Proporciona orientación acerca de cómo conseguir los objetivos y establecelas bases para gestionar el proyecto de acuerdo con sus imperativos, recursosy capacidades.

• informe del proyectoUn informe es una valoración de la situación del proyecto y de la idoneidadde los entregables del dominio objetivo. En otras palabras, refleja laproductividad del proyecto, todo análisis de defectos y el análisis de lasituación; además propone acciones correctivas midiendo los esfuerzos,costes, progresión y calidad. Como resultado de todo ello, emite señales deaviso de problemas potenciales del proyecto. Es decir, proporciona unavisión real de la progresión, mediante la supervisión y revisión de losresultados, y una base para emprender acciones (para corregir desviacionesimportantes respecto del plan).

Para cada entregable se abordan tres procesos (desarrollo, aseguramiento de lacalidad y gestión de la configuración, que puede considerarse ortogonal conrespecto a los anteriores).

Se puede definir un conjunto de propiedades que caracterizan los conocimientosadquiridos relativos a los entregables de gestión del proyecto (véase figuras 3.6 y3.7). En primer lugar se identifican y definen globalmente las propiedades de losplanes e informes. En segundo lugar, se identifican propiedades adicionales de losplanes e informes de garantía de calidad y de gestión de la configuración (véasefiguras 3.8 y 3.9).



Plan del proyecto

Propiedades Subpropiedades Descripción

Objetivos de laadaptación

Debe manifestar con claridad el objetivo de laadaptación y establecer el enlace con el plan deadaptación.

Imperativos ysuposiciones

Debe establecer los supuestos en que se basa elproyecto, los acontecimientos externos de quedepende el proyecto y los imperativos que rigen laevolución del proyecto.

Organización Estructura de subdivisiónorganizativa

Grupos afectados

Dependencias

Organizaciones externas,límites e interfaces

Gestión desubcontratistas

Debe describir la estructura interna y externa delproyecto mediante dispositivos gráficos comoorganigramas o tablas, al objeto de representar laslíneas de mando, responsabilidades ycomunicaciones del proyecto.

Debe identificar los límites organizativos y lasinterfaces entre el proyecto y otras entidades, comola organización del cliente, organizacionessubcontratadas o cualquier otra organización con laque el proyecto mantenga algún tipo deinteracción.

Funciones y suresponsabilidad

Tipos de pericia en SI Debe identificar, definir y manifestar las funcionesy responsabilidades.

Entregables Estructura de subdivisióndel producto

Diagrama de flujo delproducto

Requisitos de entrega

Debe relacionar todos los elementos a entregar alcliente.

Los productos del trabajo se subdividen de maneraque se puedan supervisar y controlar fácilmente, yse desglosan en función de la granularidadnecesaria para lograr los objetivos.

Actividades Estructura de subdivisióndel trabajo

Red de actividades

Multiestructura delproyecto

Prioridades

Debe especificar los paquetes de trabajo para lasactividades a realizar.

Puede utilizarse un diagrama que represente ladivisión de las actividades en subactividades, pararepresentar las relaciones jerárquicas entre lospaquetes de trabajo.

Las actividades se dividen de manera que sepuedan supervisar y controlar con facilidad.

Las relaciones entre las actividades se especificanpara explicar las interdependencias entre ellas.Existen varias técnicas, como listas dedependencias, redes de actividades y el método devía crítica, que pueden utilizarse para representarlas dependencias.



Plan del proyecto


Tamaño Tamaño del sistema

Tamaño del proyecto

Reparto del esfuerzo

Se realizan estimaciones del tamaño del SI y delsistema informático de acuerdo con losconocimientos disponibles acerca de la situación delproblema.

Se realizan estimaciones del esfuerzo, coste ycalendario relativos al proyecto.

Se documentan las fuentes, bases y supuestos en quese fundamentan las estimaciones.

Se preparan repartos del esfuerzo, coste y personalentre las tareas.

Calendario Diagrama Gantt, plazos

Fechas, hitos

Se prepara el calendario de las distintas actividades,teniendo en cuenta las relaciones de precedencia, ylas fechas de puntos de decisión del plan deadaptación. Puede expresarse en tiempo absoluto decalendario o en incrementos basados en un hitoclave.

Recursos Estructura de subdivisiónde los recursos humanos

Perfil

Dotación de personal

Disponibilidad

Se facilitan estimaciones de los recursos humanosnecesarios para finalizar el proyecto. Especifica elnúmero y el tipo de personal que se precisa, ademásde los niveles de cualificación necesarios, fechas deinicio, duración, métodos de obtención, formación,conservación y reducción de personal.

Presupuesto Estructura de subdivisiónde la contabilidad decostes

Se especifica la asignación de los fondospresupuestados a las actividades, es decir, el perfilde costes.

Infraestructura Normas de ingeniería

Herramientas, métodos ytécnicas

Instalaciones

Procedimientos

Dispositivos físicos ysoftware

Se facilitan estimaciones de los recursos nohumanos que se precisan para finalizar el proyecto,como horas de ordenador, software de apoyo,ordenadores y material informático, oficinas,infraestructura de viajes y comunicaciones.

Se especifica el lenguaje de programación,notaciones, herramientas, técnicas y métodos autilizar para elaborar los entregables, además de lasnormas, políticas y procedimientos que determinanel desarrollo de los mismos.

Gestión deriesgos

Se identifican y valoran los factores de riesgoasociados al proyecto. Se definen mecanismos paracontrolar los distintos factores de riesgo.

Medidas deemergencia

Se implementan planes de emergencia.

Mecanismosde control

Mecanismo deinformación

Formatos de informe

Se define el mecanismo de información, formatos deinforme, flujo de información, mecanismos derevisión y auditoría y otras técnicas para controlarque se cumple el plan.



Figura 3.6: Propiedades de un plan del proyecto

Informe del proyecto


Entregables Esfuerzo utilizado

Coste utilizado

Calendario utilizado

Las unidades reales de los resultados entregados secomparan periódicamente con la entrega estimada enel plan en términos de esfuerzo, coste y calendarioutilizados.

Actividades Esfuerzo utilizado

Coste utilizado

Calendario utilizado

Procedimientosaplicados

Los gastos reales en que se ha incurrido parafinalizar el trabajo, junto con el esfuerzo, coste ycalendario utilizados, se comparan con lasestimaciones del plan, a fin de identificardesviaciones potenciales.

Recursos Uso de los recursos delcliente

Uso de los recursos delproveedor

Pericia, capacidad ycompetencia de laspersonas

El esfuerzo, la capacidad y el personal utilizados secomparan con las estimaciones del plan, a fin deidentificar desviaciones, conflictos y problemas. Seidentifican además las dependencias entre grupos.

Presupuesto Presupuesto utilizado Se estiman los fondos presupuestados utilizadoshasta el momento.

Infraestructura Utilización

Problemas y necesidades

Se mide la utilización de los recursos que formanparte de la infraestructura. Se identifican losproblemas y necesidades relativos a lainfraestructura.

Gestión de labaja calidad

Esfuerzo de repaso

Tiempo de repaso

Se estima el esfuerzo y el tiempo empleado para eltrabajo de repaso.

Desviaciones Exceso de coste

Exceso de esfuerzo

Incumplimiento delcalendario

Se miden y comunican las desviaciones de losvalores reales respecto de los valores de base.

Se determinan y analizan las causas.

Seguimientode riesgos

Se analizan los riesgos, se detectan nuevos riesgos yse valoran contramedidas.

Propuestas deaccionescorrectivas

(si se precisan)

Acciones para ajustar elrendimiento

Acciones para ajustar elplan

Acciones para ajustar elcontrato

Acciones para ajustar lainfraestructura

Si se producen desviaciones respecto del plan seemprenden acciones correctivas, que pueden incluirla revisión del plan o del contrato para reflejar lasituación actual o la replanificación del trabajorestante, o acciones para mejorar el rendimiento.

Figura 3.7: Propiedades de un informe del proyecto



Planes del proyecto

Propiedades Subpropiedades específicas delaseguramiento de la calidad

Subpropiedades específicas dela gestión de la configuración

Entregables Requisitos de calidad Elementos de configuración

Requisitos de configuración

Actividades Tipos específicos de actividades delplan:

Revisiones

Auditorías

Inspección del código

Ensayos

Mantenimiento y conservación delos registros de calidad

Tipos específicos de actividadesdel plan:

Control de las interfaces

Identificación de la configuración

Control de la configuración

Contabilidad del estado de laconfiguración

Auditorías y revisiones

Recopilación y conservación deregistros

Infraestructura Procedimientos y normas de calidad

Métodos y herramientas de calidad

Procedimientos y normas degestión de configuración

Métodos y herramientas degestión de configuración

Figura 3.8: Propiedades adicionales de los planes de aseguramiento de la calidad ylos planes de gestión de la configuración

Informes del proyecto

Propiedades Subpropiedades específicas delaseguramiento de la calidad

Subpropiedades específicas dela gestión de la configuración

Entregables Estado de calidad

Fallos y defectos de conformidaddetectados

Situación de la configuración

Solicitudes de cambio y su estado(aceptadas, ..)

Figura 3.9: Propiedades adicionales de los informes de aseguramiento de la calidady los informes de gestión de la configuración

Contexto considerado

Los planes tienen dos finalidades posibles: pueden definir el dominio del proyectode 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ónposterior.

Estado de calidad

Los mecanismos de aseguramiento de la calidad pueden aplicarse para demostrarque un entregable de gestión del proyecto es conforme con los criterios de calidaddefinidos.



Para cada entregable específico de gestión del proyecto deberá definirse elmecanismo de aseguramiento de la calidad a aplicar. La figura 3.10 muestra unejemplo 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 harealizado 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óndel 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 laspropiedades y subpropiedades del entregable de gestión del proyecto. No espreciso mencionar todas las propiedades, sino únicamente las que sean relevantes.

El contexto considerado y el estado de calidad se especifican para todo elentregable de gestión del proyecto.

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 laprestació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 enté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 delservicio y la cancelación del servicio (véase 5.2.). La instalación y la cancelacióndel servicio son tipos especiales de adaptaciones que pueden planificarse utilizandoun plan del proyecto (véase apartado sobre entregables 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 .....



De forma similar, toda adaptación que tuviera lugar durante el proceso deejecución del servicio para mejorar el nivel de servicio podrá planificarse utilizandoun plan del proyecto.

La ejecución del servicio precisa diferentes tipos de planes con diferentespropiedades, en función de:

• el tipo de servicio (véase 5.1. y [ITIL]).

• la organización del servicio: por ejemplo, ¿comparten el servicio variosclientes o está destinado a uno solo?

Puede identificarse un conjunto de propiedades con la finalidad de caracterizar losconocimientos adquiridos para los entregables de gestión del servicio (véasefiguras 3.12 y 3.13). Eurométodo no propone subpropiedades, aunque éstaspodrá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 establecerel 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, losacontecimientos externos de que depende el servicio y losimperativos que rigen la evolución del servicio.

Organización Debe describir la estructura interna y externa de la organizaciónde 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 elservicio y otras entidades, como la organización del cliente,organizaciones subcontratadas o cualquier otra organización conla que la organización de servicios mantenga algún tipo deinteracción.

Funciones y suresponsabilidad

Deben identificar, definir y mencionar las funciones yresponsabilidades.

Elementos operativos Deben identificar los elementos operativos que constituyen elobjeto del servicio, su volumen (capacidad) y otrascaracterísticas, y su evolución.

Actividades Deben especificar las actividades que deben llevarse a cabo.

Pueden representarse las relaciones jerárquicas entre lasactividades.

Las actividades se dividen de manera que se puedan supervisar ycontrolar con facilidad.

Las relaciones entre las actividades se especifican para explicarlas interdependencias entre ellas.



Plan de servicio


Tamaño Se realizan estimaciones relevantes para el servicio acerca deltamaño del SI y del CS.

Se realizan estimaciones del esfuerzo, coste y calendariorelativos al servicio.

Se documentan las fuentes, bases y supuestos en que sefundamentan las estimaciones.

Se preparan repartos del esfuerzo, coste y personal entre lastareas.

Calendario Se prepara el programa de las distintas actividades, teniendo encuenta las relaciones en precedencia, y las fechas de puntos dedecisión que precisa el plan de prestación de servicios. Puedeexpresarse en tiempo absoluto de calendario o en incrementosbasados en hitos clave.

Recursos Se facilitan estimaciones de los recursos humanos necesariospara prestar el servicio con el nivel de servicio que se precisa.Especifica el número y el tipo de personal que se precisa y suorigen (cliente o proveedor), además de los niveles decualificación necesarios, fechas de inicio, duración, métodos deobtención, formación, conservación y reducción de personal.

Presupuesto Se especifica la asignación de los fondos presupuestados a lasactividades.

Infraestructura Se facilitan estimaciones de los recursos no humanos que seprecisan 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 estosrecursos y de su evolución.

Gestión de riesgos Se identifican y valoran los factores de riesgo asociados alservicio. Se definen mecanismos para controlar los distintosfactores 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 otrasté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 unosindicadores clave con el nivel de servicio que se precisa.

Elementos operativos Se comparan los volúmenes reales y otras características de loselementos 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 secomparan con las estimaciones del plan a fin de identificardesviaciones potenciales.

Recursos El esfuerzo, capacidad y personal utilizados se comparan con lasestimaciones del plan, a fin de identificar desviaciones,conflictos y problemas.

Presupuesto Se estiman los fondos presupuestados utilizados hasta elmomento.

Infraestructura Se mide la utilización de los recursos que forman parte de lainfraestructura. Se identifican los problemas y necesidadesrelativos 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 realesrespecto de los valores de base.

Se determinan y analizan las causas.

Seguimiento de riesgos Se analizan los riesgos, se detectan nuevos riesgos y se valorancontramedidas.

Propuestas de accionescorrectivas

(si se precisan)

Si se producen desviaciones respecto del plan se emprendenacciones correctivas, que pueden incluir la revisión del plan odel contrato para reflejar la situación actual o la replanificacióndel 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 unservicio futuro.

Estado de calidad

De forma similar a los entregables de gestión del proyecto, pueden aplicarsemecanismos de aseguramiento de la calidad para demostrar que un entregable degestió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óndel servicio, véase figura 3.14. (þAnexos D.14 y D.15)



El perfil del entregable de gestión del servicio proporciona una lista de laspropiedades (y subpropiedades, si son relevantes) que aborda el entregable degestió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 elentregable 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 eldominio objetivo de una adquisición, que entrega el proveedor al cliente oviceversa.

Existen dos tipos de entregables del dominio objetivo:

• elemento operativo:un sistema (o componente del sistema) que es o será instalado como partedel dominio objetivo.

• elemento descriptivo:un entregable que recoge conocimientos sobre el dominio objetivo.Los elementos descriptivos facilitan la toma de decisiones relativas a unaadaptación o una prestación de servicios, es decir, especifican qué deberíahacer y cómo debería ser el diseño de la organización del dominio objetivoy/o su sistema de información.

La figura 3.15 representa los tipos de entregables del dominio objetivo arribamencionados.



Figura 3.15: Tipos de entregables del dominio objetivo

Un elemento operativo es un sistema (sistema de información, sistema informáticoo parte de alguno de ellos) entregado que será instalado dentro del dominioobjetivo. Cuando un sistema entregado funciona en el dominio objetivo, puedeutilizarse para adquirir conocimientos a utilizar en la definición de futuras versionesdel mismo: en ese caso, se dice que se ha desarrollado con un enfoque deinstalación evolutiva (cf. capítulo 4). Cuando un sistema entregado se estáconstruyendo, antes de que entre en funcionamiento en el dominio objetivo, puedesometerse a ensayos con objeto de adquirir conocimientos para la definición deversiones posteriores del mismo: en ese caso, se dice que se ha desarrollado con unenfoque de construcción evolutiva (cf. capítulo 4).

Un sistema que únicamente se utiliza para adquirir conocimientos acerca deaspectos o requisitos del dominio objetivo se considera una simulación (porejemplo, un prototipo) y, por tanto, un elemento descriptivo. Si, por cualquiermotivo, se decide instalar una simulación como parte del dominio objetivo, seconsidera que se construirá un elemento operativo en base a la simulación: éste noes 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 operativosestán encaminados a contribuir al funcionamiento del dominio objetivo.

A continuación se relacionan los tipos de componentes del sistema que suelenaparecer en toda adaptación de un SI. Se pueden utilizar estos tipos paracaracterizar elementos operativos:

• instalaciones:local, cableado, suministro eléctrico

• soporte físico:ordenadores, dispositivos de red, unidades de almacenamiento, dispositivosde entrada-salida, etc.



• software de sistema:software independiente de la aplicación que soporta la ejecución del softwarede aplicación [ISO-2382-20]; por ejemplo, sistemas operativos, sistemas degestió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 deaplicación [ISO-2382-20], cuyas características vienen determinadas por laespecificación del sistema de información. Este concepto incluye paquetes deaplicación que se adaptan a la especificación del sistema de información yque, por tanto, pueden utilizarse.

• Datos físicos:los datos físicos del dominio objetivo. Será preciso migrar estos datos encaso 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áticopor los agentes humanos del sistema de información.

• descripciones de trabajos:instrucciones que los agentes humanos de un sistema de información tienenque 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 deinformación y la educación de los agentes humanos.

• agentes formados:los agentes humanos que han sido formados de cara a sus nuevascircunstancias (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 unafutura versión del sistema. Es preciso identificar la versión del sistema sinambigüedades. Deberá añadirse un texto explicativo si la simple mención delsistema 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 conformidadcon los criterios de calidad definidos en los procedimientos aplicables deaseguramiento de la calidad. Los procedimientos de aseguramiento de lacalidad 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 hansido planificadas. Estos elementos descriptivos pueden describirse utilizando losperfiles de elementos descriptivos presentados en el apartado 3.6. La versión delsistema que posee el perfil del elemento descriptivo se utilizará para establecer elenlace con el elemento operativo pertinente.



3.6 Elementos descriptivos

Un elemento descriptivo es un entregable del dominio objetivo que recogeconocimientos sobre el dominio objetivo. Los elementos descriptivos puedenutilizarse para describir sistemas de información dentro de adaptaciones o serviciosdel sistema de información.

Estos conocimientos se caracterizan por:

• el conjunto de propiedades del dominio objetivo (propiedades funcionales, decalidad y de inversión) que se describen.

• otras características: alcance, nivel de detalle, nivel de acuerdo, grado deformalismo, cuantificación, simulación, versión del sistema, solucionesalternativas 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 figura3.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 precisomencionar todas las propiedades que caracterizan una visión, sino únicamente lasque sean relevantes.

Las propiedades de calidad y de inversión pueden calificarse mediante unapropiedad funcional específica, por ejemplo, seguridad de los datos, facilidad deuso 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éaseapartados 3.6.5 a 3.6.13) pueden especificarse alternativamente para cadapropiedad, para cada visión o para la totalidad del elemento descriptivo. Si seespecifican a nivel de una visión, son válidos para todas las propiedades quecomprende esa visión. Si se especifican a nivel de un elemento descriptivo, sonválidos para todas las visiones y propiedades que comprende el elementodescriptivo.

Los valores definidos por los usuarios y que figuran en cada columna deberánremitir al texto explicativo que acompaña a la tabla (véase apartados 3.6.5. a3.6.13).



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 descriptivoviene 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

Nombre del elemento descriptivo

Características,visiones ypropiedades

alcan-ce

deta-lle

acuer-do

forma-lismo

cuantifi-cación

simula-ción

versióndel sis-tema

alter-nativas

estadodecalidad

Propiedadesfuncionales

Visión-1

Propiedadfuncional 1-1


…

Visión-2




…

Propiedades decalidad

Propiedad decalidad 1

Propiedad decalidad …

Propiedades de lainversión

Propiedad de lainversión 1

Propiedad de lainversión …



tener una finalidad concreta y un conjunto de propiedades funcionales. Unapropiedad funcional es un tipo de conocimiento de un dominio objetivo.

Las visiones definen los conceptos y la terminología que se utilizan paracaracterizar el conocimiento del dominio objetivo.

En la Versión 1 de Eurométodo, las seis visiones se clasifican en visiones delsistema de información y visiones del sistema informático11.

El SI es el aspecto de la organización que utiliza y produce información. Lasvisiones del SI definen la representación de los recursos de información, losagentes que los utilizan y producen, sus procesos y las relaciones entre ellos. Lasvisiones 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 porun sistema informático. Esto significa que algunas de sus tareas, o todas ellas, lasrealiza total o parcialmente un sistema informático. Todo esto se describe en lavisió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 deinformación pero no del resto de aspectos de la organización; por ejemplo, los procesosasociados a flujos de materiales, financieros o energéticos.



caracterizan los conocimientos acerca de la selección de tareas y el subconjunto derecursos de información que están informatizados.

Las visiones del sistema informático definen la representación de la estructura yfuncionalidad del sistema informático, y describen los conocimientos acerca delmodo en que se automatizan las tareas y se estructura el sistema informático (véasefigura 3.18).

del negocio

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 deinformación y de su sistema informático, que se precisan para facilitar la toma dedecisiones 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 recursosde información del dominio objetivo, independientemente de cómo éstos seimplementan y utilizan en las prácticas de trabajo reales. Abarca las propiedadesfuncionales que representan los conocimientos relativos a los elementos deinformació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 negocioestá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 deldominio objetivo, independientemente de cómo éstos se llevan a cabo por agentesen las prácticas de trabajo reales. Abarca las propiedades funcionales querepresentan los conocimientos sobre los procesos, las relaciones entre ellos, loseventos 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 negocioestán representadas en la figura 3.20.

La visión de la información del negocio junto con la visión de los procesos delnegocio abarcan las propiedades que definen una visión de un sistema deinformación independiente de los agentes (humanos o automatizados) que llevan acabo 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 elmodo en que ejecutan los procesos en el dominio objetivo y hacen uso de losrecursos de información.

La visión de las prácticas de trabajo utiliza el concepto de tarea: una tarea es (unaparte de) un proceso que realiza un agente.

La visión de las prácticas de trabajo abarca aquellas propiedades funcionales querepresentan conocimientos sobre los agentes, su estructura organizativa, suubicación física, las tareas mediante las cuales realizan los procesos del negocio yla posible automatización de estas tareas. Esto incluye la descripción estática ydinámica de la interfaz hombre-ordenador.

Las propiedades funcionales definidas en la visión de las prácticas de trabajo estánrepresentadas 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 parteautomatizada de los recursos de información. Abarca aquellas propiedadesfuncionales que caracterizan los conocimientos relativos a los datos querepresentan los recursos de información que contiene el sistema informático, y lasdependencias estáticas y dinámicas de esos datos.

Las propiedades funcionales definidas en la visión de los datos del sistemainformá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 laspartes automatizadas de las tareas de los agentes, con independencia de cualquierunidad de proceso.



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, esdecir, el cometido del sistema informático dentro del sistema de información.

Algunas funciones corresponden a una tarea automatizada específica (o partes deella), y otras soportan un determinado número de tareas automatizadas, o todasellas. Estas funciones de soporte son necesarias para el funcionamiento del sistemainformático.

La visión de las funciones del sistema informático abarca aquellas propiedadesfuncionales que representan conocimientos sobre las funciones que desempeña elsistema informático, el uso de los datos que contiene el sistema informático y lasinterfaces de datos.

Las propiedades funcionales definidas en la visión de las funciones del sistemainformático están representadas en la figura 3.23.

Visión de la arquitectura del sistema informático

La finalidad de la visión de la arquitectura del sistema informático es representarlas unidades de proceso del sistema informático, su estructura y sus característicasfísicas.

Una unidad de proceso es un procesador incluido en el sistema informático. Unaunidad de proceso del sistema informático es análoga a un agente.

La visión de la arquitectura del sistema informático abarca aquellas propiedadesfuncionales que representan los conocimientos relativos a las unidades de procesodel sistema informático, sus ubicaciones, sus conexiones y la distribución de losdatos y funciones que utilizan.

Comprende también aquellas propiedades funcionales que representan losconocimientos acerca del soporte físico, el software del sistema y el software deaplicación que constituyen el sistema informático.

Las propiedades funcionales definidas en la visión de la arquitectura del sistemainformático están representadas en la figura 3.24.

Propiedades funcionales de la visión de la información del negocio

Elementos deinformación

La identificación de la información que contienen los recursos deinformación del dominio objetivo

Gamas de valores Posibles valores que pueden adoptar los elementos de información alocurrir

Dependenciasestáticas

Las dependencias estáticas entre los elementos de información, porejemplo:

12 En la bibliografía, el término función se utiliza con distintos ignificados. En el contexto devisiones 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 loselementos

La evolución de los elementos de información, en términos de cambiosque pueden experimentar desde que ocurren hasta que se borran. Estoincluye los eventos que activan estos cambios, las dependenciasdiná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

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ónque lo componen.

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

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 delnegocio

Los eventos que pueden desencadenar el proceso del negocio, y suorigen

Condiciones deactivación

Las condiciones que deben cumplirse para desencadenar el procesodel negocio

Eventos generados porel negocio

Los eventos generados por el proceso del negocio, y su destino

Desglose del proceso delnegocio

El desglose del proceso del negocio en subprocesos. Lossubprocesos pueden considerarse como procesos y describirse delmismo modo, y también se pueden desglosar

Dependenciasdinámicas

Las dependencias dinámicas entre los subprocesos del proceso delnegocio, 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 deinformación

La información que utiliza y genera el proceso del negocio



Figura 3.21: Propiedades funcionales de la visión de las prácticas de trabajo

Propiedades funcionales de la visión de las prácticas de trabajo

Agentes Identificación de los agentes (humanos y sistemas informáticos) deldominio objetivo; y su cualificación o capacidad, necesidades deformación, etc.

Ubicaciones Las ubicaciones donde trabajan los agentes

Estructura organizativa Las relaciones organizativas entre los agentes, incluyendo la agregación deactores en unidades organizativas (las unidades organizativas también seconsideran agentes)

Comunicaciones La comunicación entre los agentes

Necesidades y derechos deacceso (de los agentes)

Las necesidades de acceso a la información y los derechos de accesonecesarios para cada agente, es decir, las visiones externas de los agentesrespecto 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 ointeractiva. Una tarea interactiva es ejecutada en parte por agenteshumanos y en parte por el sistema informático. Los detalles de laautomatización se definen en el desglose de la tarea

Desglose de la tarea El desglose de la tarea en subtareas. Las subtareas pueden considerarsecomo tareas y describirse de igual modo, y se pueden desglosar a su vez

Una tarea interactiva se puede desglosar en subtareas manuales yautomatizadas. Una tarea automatizada no se suele desglosar (se podríadesglosar en la visión de las funciones automatizadas)

Uso y generación de lainformación

La información (automatizada y no automatizada) que utiliza y genera latarea

Dependencias dinámicas Las dependencias dinámicas respecto a otras tareas y entre las subtareas dela tarea, por ejemplo secuencia, alternativa, iteración, paralelismo,sincronización, dependencias de información

Eventos organizativosactivadores

Los eventos que pueden activar la tarea y su origen

Eventos organizativosgenerados

Los eventos generados por la tarea y su destino

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-ordenador

La información que debe pasar por la interfaz hombre-ordenador(incluyendo la definición de diseños de pantalla, informes impresos, etc.) ylos eventos organizativos generados por una tarea manual y que activanuna tarea automatizada, o los generados por una tarea automatizada y queactivan una tarea realizada por un agente humano

Comportamiento de lainterfaz hombre-ordenador

Condiciones de activación de la interfaz hombre-ordenador.

El comportamiento de la interfaz hombre-ordenador también depende delas dependencias dinámicas entre las tareas automatizadas y las manuales



Figura 3.22: Propiedades funcionales de la visión de los datos de ordenador

Figura 3.23: Propiedades funcionales de la visión de las funciones automatizadas

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

Datos retenidos Los datos retenidos en el ordenador que representan los elementosde información automatizados, y otros datos necesarios para elfuncionamiento 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, dependenciasfuncionales

Evolución de los datos La evolución de los datos en términos de cambios que puedenexperimentar desde que ocurren hasta que se borran, incluyendo loseventos que activan estos cambios, las dependencias dinámicasentre estos cambios (por ejemplo, secuencia, alternativa, iteración)y los eventos generados por estos cambios

Propiedades funcionales de la visión de las funciones automatizadas

Funciones Identificación de las funciones del sistema informático y sufinalidad.

Y para cada función

Mensajes de entrada Los mensajes que pueden activar la función y su origen

Condiciones deactivación

Las condiciones que deben cumplirse para desencadenar la funció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 puedenconsiderarse como funciones y describirse del mismo modo, y sepueden desglosar a su vez

Dependenciasdinámicas

Las dependencias dinámicas entre las subfunciones de la función;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.24: Propiedades funcionales de la visión de la arquitectura del sistemainformático

Reglas de coherencia entre las visiones

Las distintas visiones no son independientes unas de otras, sino que están ligadaspor un conjunto de reglas de coherencia. Cualquier descripción coherente de unsistema de información deberá cumplir estas reglas.

En este apartado se definen las reglas de coherencia fundamentales entre laspropiedades funcionales antes mencionadas y, por tanto, entre la visión del sistemade información y la visión del sistema informático, que deben respetarse si se deseaelaborar una descripción coherente del sistema de información. Estas reglas seestablecen en términos generales, y deberán puntualizarse al utilizar las técnicas demodelado específicas.

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 ysus tipos

Ubicaciones Las ubicaciones donde se encuentran las unidades de proceso

Estructura La estructura del sistema informático que muestra las relacionesentre las unidades de proceso

Distribución de losdatos

La distribución del almacenamiento de datos en unidades deproceso

Distribución de lasfunciones

La distribución de las funciones en unidades de proceso. Laasignación de una función a las unidades de proceso puede requerirun mayor desglose de esta función que el que se ha efectuado en lavisión de las funciones del sistema informático

Comunicación externa Los enlaces de comunicación externa de las unidades de procesocon los sistemas informáticos de otros sistemas de información

Comunicación interna Los enlaces de comunicación interna entre las unidades de procesodel sistema informático

Y para cada unidad de proceso:

Descripción del soportefísico

Los datos técnicos del soporte físico en que se implementa launidad de proceso (por ejemplo, tipo de procesador, volumen de lamemoria, velocidad de transmisión, capacidad de almacenamiento)

Descripción delsoftware del sistema

Los datos técnicos del software del sistema en que se implementa launidad de proceso (sistemas operativos, sistemas de bases de datos,supervisores de transacciones, sistemas de gestión de red,compiladores, etc.)

Descripción de laaplicación

• Datos físicos: la descripción de la implementación de losdatos almacenados con el soporte físico y el soporte lógicoespecíficos del sistema.

• Programas: la descripción de la implementación de lasfunciones con el soporte físico y el soporte lógico específicosdel sistema. Los programas se pueden desglosar en funciónde las unidades de proceso, por ejemplo, interfaces hombre-ordenador en unidades de proceso locales y gestión deaccesos de datos en unidades de proceso centrales



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 oactualizado (creado, modificado, borrado) por un proceso del negocio.

• Debe existir una relación entre el conjunto de eventos que activan loscambios de los elementos de información y el conjunto de eventos delnegocio.

• La evolución de los elementos de información deberá mantener la coherenciacon 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 eventoorganizativo.

• La dinámica de las tareas16 debe ser coherente con la dinámica de losprocesos del negocio.

• La información que utilice y genere una tarea debe ser coherente con lainformación que utilice y genere la parte del proceso del negocio que aquéllarealice.

• Las necesidades y derechos de acceso a la información que posea un agentedeberán ser coherentes con la información que utilicen y generen las tareasque aquél realiza y, por tanto, con la información que utilicen y generen losprocesos 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 delas tareas que desempeñan y, por tanto, con la dinámica de los procesos denegocio 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 ladescripció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 delnegocio que activan los cambios, los eventos del negocio que se generan y las dependenciasdinámicas.

16 La dinámica de las tareas se expresa através de los eventos y condiciones organizativas queactivan los cambios, los eventos organizativos que se generan y las dependenciasdinámicas.



• Es preciso describir cada elemento de información que pueda ser utilizado oactualizado (creado, modificado, borrado) por una tarea.

Visión de los datos del sistema informático y visión de la información delnegocio

• Los datos retenidos en el sistema informático deberán corresponder aelementos de información o bien serán necesarios para el funcionamiento delsistema informático.

• Las gamas de valores de los datos deberán ser coherentes con las gamas devalores de los elementos de información.

• Las dependencias estáticas entre los datos deberán ser coherentes con lasdependencias estáticas entre los elementos de información.

• La evolución de los datos deberá ser coherente con la evolución del elementode información.

Visión de las funciones del sistema informático y visión de las prácticas detrabajo

• Cada tarea automatizada deberá corresponder a una función.

• La dinámica de las funciones17 deberá ser coherente con la dinámica de lastareas.

• Los datos retenidos que utilice y actualice una función deberán sercoherentes con los elementos de información que utilicen y actualicen lascorrespondientes tareas automatizadas.

• Las reglas de las funciones deberán ser coherentes con las correspondientesreglas de las tareas automatizadas.

• Los eventos organizativos que forman parte de la interfaz hombre-ordenadordeberá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 delsistema 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 oactualizado (creado, modificado, borrado) por una función.

• La evolución de los datos deberá ser coherente con la dinámica de lasfunciones.

17 La dinámica de las funciones se expresa a través de los mensajes de entrada y salida, lascondiciones desencadenantes y las dependencias dinámicas.



Visión de la arquitectura del sistema informático y visión de las funciones delsistema informático

• 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 elintercambio de mensajes entre las funciones distribuidas.

• Cada función deberá ser realizada por el soporte físico, el software delsistema o el software de aplicación.

Visión de la arquitectura del sistema informático y visión de los datos delsistema informático

• Cada uno de los datos retenidos deberá ser asignado al menos a una unidadde proceso.

• Los enlaces de comunicación de las unidades de proceso deberán permitirque 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 datofísico.

Visión de la arquitectura del sistema informático y visión de las prácticas detrabajo

• Las ubicaciones de las funciones deberán ser coherentes con las ubicacionesde 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 delsistema. Pueden utilizarse para caracterizar procesos o servicios, además desistemas; aunque su definición exacta, unidad de medida y métrica asociada puedendepender 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 loscomponentes del sistema o al sistema en su totalidad.Por ejemplo: ‘El nuevo sistema de información deberá ser capaz de gestionarel 250% de la carga máxima del sistema actual.’

• la totalidad del sistema informático.En este caso, define un imperativo general que afecta a cada uno de loscomponentes del sistema informático o al sistema informático en su totalidad.Por ejemplo: ‘El nuevo sistema informático deberá proteger todos losaccesos a los datos con un nivel de seguridad 2.’

• un proceso o servicio.En este caso, define un imperativo general que afecta a cada uno de loscomponentes del proceso/servicio o al proceso/servicio en su totalidad.



Por ejemplo: ‘El servicio de ayuda contestará el 90% de las consultas en unminuto.’

• varias propiedades funcionales.En este caso, define un imperativo que afecta a todos los casos de esapropiedad funcional.Por ejemplo: ‘Todo el software de aplicación debe poder trasladarse a lossistemas operativos X, Y, Z.’

• un ejemplo de una propiedad funcional.En este caso, define un imperativo que afecta únicamente al ejemploespecificado de la propiedad funcional.Por ejemplo: ‘El agente ejecutante de la tarea Cambiar-Situación-Financieradebe tener el nivel de autorización 1.’

La siguiente relación de propiedades de calidad (véase figura 3.25) se ha extraídode la Norma ISO-9126 [ISO-9126] y sus subcaracterísticas tienen en cuenta elmodelo 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 oun proceso/servicio.



Eficiencia La relación entre el nivel de prestaciones del sistema (o de uncomponente) y el volumen de recursos utilizados en condicionesdeclaradas. La eficiencia puede referirse al comportamiento en el tiempo(tiempo de respuesta, tiempo de proceso, velocidad de proceso) y alcomportamiento de los recursos (cantidad de recursos utilizados yduración de esta utilización).

Ejemplos de indicadores del comportamiento en el tiempo: tiempo deproceso, capacidad de proceso, tiempo de inversión, tiempo de respuesta,tiempo transcurrido en la CPU, tiempo de ejecución en la CPU, tiempo deproceso entrada/salida, tiempo de proceso de la red, velocidad.

Ejemplos de indicadores del comportamiento de los recursos: nivel deocupación de la comunicación, nivel de ocupación de memoria, nivel deocupació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 dela red.

Funcionalidad La funcionalidad está relacionada con la existencia de un conjunto defunciones y sus propiedades específicas. Las funciones satisfacen lasnecesidades declaradas o implícitas.

Son subcaracterísticas de la funcionalidad: idoneidad, precisión,interoperabilidad, conformidad, rastreabilidad y seguridad. Este últimotérmino se define a continuación.

Seguridad Capacidad de un sistema (o de un componente) para impedir todo accesono 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 derendimiento en unas condiciones declaradas y durante un período detiempo declarado.

Para evaluar la fiabilidad se utiliza a menudo el tiempo medio sin fallo. Lafiabilidad se puede determinar definiendo el nivel de protección contra losfallos 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 realizarmodificaciones específicas en el sistema (o en un componente). Lamodificación puede incluir correcciones, mejoras o adaptaciones a cambiosdel 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 sertransferido 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 usodel 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.



Figura 3.25: Propiedades de calidad

Esta lista no pretende ser exhaustiva. En ciertas adaptaciones, para determinadosservicios y en organizaciones concretas pueden identificarse otras propiedades decalidad.

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 uncomponente de uno de los anteriores.

En las definiciones de la siguiente lista de propiedades de la inversión (véase figura3.26) se ha utilizado el término “sistema”, que puede entenderse como un sistemade información, un sistema informático o un proceso/servicio.

Coste Los costes de producción, mantenimiento y explotación del sistema o deun componente individual

Beneficio Los beneficios que aporta un componente a otro componente del nivelsuperior que lo contiene o al sistema; o los beneficios que el sistema aportaal negocio de la organización

Riesgo Los riesgos asociados a la producción, mantenimiento y explotación delsistema 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 elelemento descriptivo.

Para cada elemento descriptivo, visión o propiedad funcional en particular, el perfildel elemento descriptivo deberá contener un conjunto de valores y un textoexplicativo que describa el alcance.

Los tipos de alcance posibles son:

• alcance íntegro:un elemento descriptivo que describe el dominio objetivo en su totalidad; porejemplo, la descripción de todos los procesos del dominio objetivo.

• alcance parcial:un elemento descriptivo que describe únicamente un subconjunto deldominio objetivo; por ejemplo, la descripción de un proceso del dominioobjetivo. En este caso se precisará un conjunto de elementos descriptivossimilares para conseguir un alcance íntegro. Si el alcance es parcial, espreciso definir con más detalle la cobertura del dominio objetivo en términoscuantitativos (por ejemplo, los procedimientos más importantes querepresentan el 80% del dominio objetivo) o en términos cualitativos (porejemplo, área de negocio, unidad organizativa, o grupo de procesos deldominio objetivo).



Para una adaptación particular podrán definirse, si es preciso, varios alcancesparciales al objeto de facilitar una secuencia de decisiones asociadas en esaadaptación.

3.6.6 Nivel de detalle

El nivel de detalle caracteriza el volumen de conocimientos que contiene elelemento descriptivo. Este volumen, es decir, el detalle que se incluye o se excluye,puede variar entre un producto totalmente desarrollado y un producto parcialmentedesarrollado.

Para cada elemento descriptivo, visión o propiedad funcional en particular, el perfildel elemento descriptivo deberá contener un conjunto de valores y un textoexplicativo que describa el nivel de detalle.

El nivel de detalle se caracteriza por el nivel de abstracción con respecto a los dosmecanismos 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 otrosmedios para caracterizar el nivel de detalle necesario en función de los métodosutilizados, 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 elementosdescriptivos 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, sistemade información o sistema informático) o un proceso/servicio está desglosado en elelemento descriptivo.

Los grados de desglose se definen del modo siguiente:

• un elemento descriptivo posee un alto grado de desglose si todas las partesdel sistema (o proceso/servicio) que recoge están completamentedesglosadas y descritas. Una descripción se suele considerar completa si yano se precisa un mayor desglose para la construcción del sistema y no esnecesario añadir más elementos a la descripción.

• un elemento descriptivo posee un bajo grado de desglose si no se hanidentificado y descrito todos los niveles jerárquicos.

Varias propiedades funcionales se describen utilizando el desglose jerárquico, paralo cual el grado de desglose se refiere al número de niveles de desglose. Porejemplo:

• procesos del negocio incluidos en la visión correspondiente



• tareas, agentes o estructuras organizativas incluidos en la visión de lasprá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 sistemainformático.

Ejemplo: Puede considerarse que un entregable que describe el primer nivel dedesglose de una función posee un bajo grado de desglose. Si se describe latotalidad del desglose de la función y se proporcionan descripciones de todas lasfunciones que no están a su vez desglosadas, se puede considerar que existe un altogrado 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 quedeben 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 dedesglose, al objeto de facilitar una secuencia de decisiones asociadas en esaadaptació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 todossus comportamientos especiales.

Los grados de especialización se definen del modo siguiente:

• un elemento descriptivo posee un alto grado de especialización si seidentifican 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 seidentifican y describen todos los subtipos de las propiedades que recoge(procesos, eventos, agentes, etc.) o los casos especiales. Únicamente sedescriben los casos normales o generales.

Ejemplo: Puede considerarse que un elemento descriptivo que describe un procesode venta en el que se definen todos los casos especiales (clientes nacionales einternacionales, diferentes condiciones de crédito, pedidos urgentes y normales,etc.), posee un alto grado de especialización. Si únicamente se describen los casosmás habituales (cliente nacional, pedido normal, etc.), puede considerarse queexiste un bajo grado de especialización.



Para una adaptación en particular pueden definirse, si es preciso, varios grados deespecialización, al objeto de facilitar una secuencia de decisiones asociadas endicha adaptación.

El nivel de detalle y el alcance de un entregable pueden combinarse de diferentesmaneras 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 tareadeterminada precisará un alcance parcial y un alto grado de desglose y deespecialización.

3.6.7 Nivel de acuerdo

El nivel de acuerdo se ocupa del aspecto social de la descripción del sistema (oproceso/servicio). Indica hasta qué punto los agentes del dominio objetivo están deacuerdo con las descripciones.

Normalmente, estos agentes poseen diferentes puntos de vista acerca del dominioobjetivo, su sistema de información y sus necesidades, debido a diferenciaspsicológicas, políticas, funcionales, geográficas y culturales. Estos puntos de vistarevelan contradicciones, coincidencias parciales y lagunas. Cuando se intentaintegrar estos puntos de vista surgen conflictos, aunque éstos no son siemprenegativos, ya que pueden ayudar a identificar problemas y estimular la creatividad.Es preciso gestionar los conflictos e incoherencias al objeto de integrar los puntosde vista en un conjunto coherente de descripciones que expresen los requisitos deldominio objetivo y su sistema de información.

El nivel de acuerdo deberá indicar:

• qué agentes del dominio objetivo participan en el acuerdo en torno alelemento descriptivo.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 losagentes encargados del mantenimiento y operación de ese sistemainformático les interesará sobre todo la visión de la arquitectura del sistemainformático.

• qué procedimientos de gestión del acuerdo se utilizan.Deberán indicar cómo organizar la participación de los agentes, y lacooperación y negociaciones entre los agentes, cómo resolver lasincoherencias y gestionar los conflictos, y qué tipo de acuerdo se esperarespecto a la descripción.

Para cada elemento descriptivo, visión o propiedad funcional en particular, elperfil del elemento descriptivo incluirá un conjunto de valores y un textoexplicativo que describa los dos puntos anteriores.



3.6.8 Grado de formalismo

El grado de formalismo describe el tipo de lenguaje de representación que debeutilizarse para el elemento descriptivo.

Para cada elemento descriptivo, visión o propiedad funcional en particular, el perfildel elemento descriptivo deberá contener un conjunto de valores y un textoexplicativo que describa el grado de formalismo.

Los grados de formalismo se dividen en:

• formalsi el lenguaje de representación se basa en sistemas matemáticos o de cálculológico.

• semiformalsi el lenguaje de representación se basa en notaciones gráficas cuyossímbolos poseen un significado definido, o en una notación textual queconsiste en un conjunto limitado de construcciones con un significado y unasintaxis definidos.

• informalsi el lenguaje de representación se basa en un lenguaje natural, ilustracionesgráficas, animación, etc.

Los lenguajes formales y semiformales pueden parafrasearse en un lenguaje naturalpara que las descripciones sean más sencillas de utilizar. La necesidad deparafrasear también puede indicarse en el texto que describe el grado deformalismo.

3.6.9 Cuantificación

Es posible cuantificar los sistemas, procesos, servicios y sus propiedades (porejemplo, 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.

Para cada elemento descriptivo, visión o propiedad funcional en particular, el perfildel elemento descriptivo deberá contener un valor que indique si el sistema oproceso/servicio descrito está o debería estar cuantificado, y que haga referencia aun texto que explique el tipo de cuantificación. Deberán indicarse las unidades demedida y la métrica.

3.6.10 Simulación

Una simulación es una representación artificial de un sistema real. La simulación esuna manera importante de aprender acerca del comportamiento y el rendimiento deun sistema. Asimismo, para la mayoría de los agentes del dominio objetivo es mássencillo entender un sistema que utilice simulaciones que otro que utiliceespecificaciones 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 repasode una especificación.

Un prototipo es un modelo o implementación preliminar adecuado para laevaluación del diseño, rendimiento y potencial de producción de un sistema; o parauna mejor comprensión o determinación de los requisitos [ISO-2382-20]. Elsistema a que se hace referencia suele formar parte del sistema informático. Unprototipo, mientras se encuentra en funcionamiento, no es una parte del sistemainformático del dominio objetivo, sino un medio especial para recogerconocimientos acerca de este sistema informático.

Una maqueta de interfaz hombre-ordenador simula el comportamiento externo deuna 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 personainteractúe con el proceso mediante el envío de mensajes y visualice el estado delproceso (normalmente utilizando una interfaz hombre-ordenador).

El término escenario suele referirse a la simulación del funcionamiento de unaorganización. Un escenario puede considerarse como una historia en la que actúanpersonas que representan a los agentes del dominio objetivo. Los escenariospueden utilizarse para simular procesos/servicios.

Para cada elemento descriptivo, visión o propiedad funcional en particular, el perfildel elemento descriptivo deberá contener un valor que indique si el sistema oproceso/servicio descrito está o debería estar simulado, y que haga referencia a untexto que explique el tipo de simulación. Es posible simular las propiedadesfuncionales y las propiedades de calidad al objeto de definir sus requisitos o paracomprobar que cumplen los requisitos definidos.

La solicitud de una simulación no significa que el entregable deba utilizar unlenguaje de descripción formal, ni siquiera si la simulación se realiza utilizando unlenguaje de descripción formal. Más aún, el lenguaje que utilicen los agentes delproyecto para desempeñar sus tareas no tiene por qué ser el mismo que el que seutiliza 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: puedetratarse 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 perfildel 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 precisoidentificar sin ambigüedades la versión del sistema/servicio que se describe. Seprecisará un texto explicativo cuando la simple mención del sistema/servicio actualo 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 delsistema/servicio, puede que sea preciso describir más de una solución posible. Por



tanto, para cada elemento descriptivo, visión o propiedad en particular, el perfil delelemento descriptivo deberá contener un valor que indique si se precisansoluciones alternativas y, de ser así, un texto explicativo que describa lascaracterí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 criteriosde calidad que definen los procedimientos aplicables de garantía de calidad.

Las revisiones e inspecciones son ejemplos de procedimientos de calidad. Para lasimulación, el procedimiento de calidad deberá especificar qué requisitos ypropiedades de calidad se utilizarán para medir la simulación.

Para cada elemento descriptivo en particular, el perfil del elemento descriptivodeberá contener un valor que indique el procedimiento de garantía de calidad y loscriterios de calidad que se han aplicado o deberían aplicarse.

El estado de calidad que se precisa en un determinado punto de decisión dependedel tipo de decisión. Ciertos tipos de decisiones no requieren la comprobación dedeterminados requisitos de calidad o la aplicación de los últimos procedimientos decalidad.

Capítulo 4Té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, demanera que se ciñe estrictamente a ellas. Debe ser leído por los responsables deproyecto de los clientes y de los proveedores. En el transcurso de una adquisiciónse suele acceder a él desde el capítulo 2 a través de las referenciascorrespondientes.

Definición Una técnica es un conjunto de heurísticas y procedimientos queexplican cómo crear un grupo de uno o más productos en unanotación especificada. Una técnica es un medio para conseguirobjetivos 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 deadaptación para una adaptación singular del SI. El contenido de un plan deadaptación se describe en el apartado 3.2. Un plan de adaptación puedeevolucionar, pasando por distintas versiones. En una situación típica, el cliente creauna versión inicial al preparar la petición de ofertas; los proveedores creanversiones elaboradas como parte de las ofertas; y el cliente, junto con el proveedorseleccionado, crean una versión final como parte del contrato. Es importante que elcontrato incorpore un plan de adaptación, ya que determina el estado inicial y elestado final y define los requisitos contractuales de cada una de las entregas en laadaptación del SI. Durante la adaptación del SI, lo normal es que el plan deadaptación permanezca invariable, aunque las decisiones acerca de cambios en elcontrato pueden motivar su modificación.

Las técnicas de planificación de la adaptación mencionadas en este capítulo puedenaplicarse cuando ya se tiene una idea general de cómo va a ser una adaptaciónsingular del SI, es decir, se ha perfilado el punto de partida (estado inicial) y elobjetivo (estado final), y podrán aplicarse de nuevo en cualquier momento duranteuna adquisición. El capítulo 2 contiene orientaciones acerca de cuándo y cómoutilizar las técnicas.(þ 2: El proceso de adquisición)

4.1 Gestión del riesgo

Definición Un riesgo es la posibilidad de exposición a las consecuenciasadversas de eventos futuros [EM-DC].

Las técnicas de planificación de la adaptación mencionadas en este capítulo secentran en la gestión del riesgo mediante puntos de decisión a nivel contractual. Espreciso planificar la secuencia de puntos de decisión para reducir la probabilidad deriesgo y las consecuencias adversas de los eventos.

Técnicas paraplanificar unaadaptaciónsingular del SI



En toda situación existen cuatro aspectos que contribuyen al riesgo: complejidad,incertidumbre, opciones y consecuencias.

Se puede hablar de una situación arriesgada cuando ésta es compleja o incierta yencierra varias opciones alternativas, y cuando algunas opciones pueden ofrecermás beneficios que otras. La incertidumbre puede referirse a la probabilidad de quetenga lugar un evento o a la severidad de las repercusiones de este evento. Cuandono existen opciones, un gestor no se enfrenta a una situación arriesgada, sino a unaatada, o al menos que escapa a su control. Es preciso comprender tanto laprobabilidad de un evento como sus repercusiones, al objeto de tener unaapreciació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 laadaptación contiene varias opciones alternativas a seleccionar. Eurométodoproporciona listas de factores situacionales que pueden implicar complejidad eincertidumbre. Estas listas pueden utilizarse para identificar los riesgos críticos ypara comprender mejor los motivos subyacentes a estos riesgos.

Cada nivel de gestión posee un alcance diferente y distintas opciones que afectan alos distintos tipos de riesgos. Las decisiones a nivel de alta dirección, relativas a laplanificación de la adquisición, afectan a los objetivos generales de negocio y a laasignación de los recursos necesarios para conseguir estos objetivos. Ello puededar 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 laadaptación, se ocupan de dar cumplimiento a los requisitos existentes con losrecursos disponibles. Ello puede dar lugar a unos niveles de productividadinadecuados (riesgos de infraprestación).

Las técnicas de planificación de la adaptación mencionadas en este capítulo serefieren principalmente a las decisiones a nivel de gestión del contrato; es decir, lareducción de los ‘riesgos de infraprestación’.

Los gestores que obtienen resultados favorables en la gestión de los riesgosmantienen un alto nivel de disciplina a la hora de adoptar decisiones; ello nosignifica 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 ypara 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 tomade decisiones en el nivel contractual de una adaptación del sistema de información.

Situaciónarriesgada ysituación atada

Gestión deriesgos en cadanivel de gestión

Disciplina en latoma dedecisiones



La gestión de riesgos se compone de tres subprocesos:

• Análisis de riesgos.Los riesgos de un plan o una política propuestos se identifican y valoran deforma sistemática. Durante la identificación se explicitan los supuestosrelativos a la situación. Eurométodo proporciona técnicas que sustentan elaná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 planificauna línea de acción apropiada. Eurométodo proporciona técnicas quesoportan la elección de una estrategia de adaptación y la planificación depuntos de decisión.

• Supervisión de riesgos.Define un medio para medir si las contramedidas tienen éxito o no. Ademásde otras actividades de seguimiento, la línea de acción determinada secomprueba continuamente, al tiempo que se definen y planifican medidascorrectivas. Eurométodo proporciona orientación acerca de la planificaciónde los puntos de decisión de la supervisión de riesgos, y técnicas para laevaluació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 estaseparación es garantizar que las decisiones de planificación se basan en toda lainformación relevante que se ha recopilado durante el análisis de riesgos. Lassoluciones para la reducción de riesgos no deberán llegar demasiado pronto. Esmuy fácil proponer soluciones simples para situaciones complejas y actuar antes deque se hayan podido recopilar y analizar todos los datos. Recuerde: Para obtenerbuenas respuestas es preciso hacer buenas preguntas.

Eurométodo se centra en las causas primordiales de los riesgos, los factores desituación, en lugar de en sus efectos, ya que es vital comprender estas causasprimordiales si se desea que la línea de acción seleccionada obtenga un resultadofavorable. El mejor enfoque es eliminar las fuentes de riesgo siempre que seaposible, por ejemplo, modificando los factores situacionales.

La gestión de riesgos es compleja, ya que existen interacciones entre los riesgos.No es frecuente hallar un riesgo único; lo más habitual es un grupo de riesgos. Losefectos de un riesgo pueden ser la causa de otro, o una causa puede dar lugar avarios riesgos. La reducción de un riesgo hace a menudo que aumente otro. Porejemplo, las medidas para minimizar el riesgo de baja calidad de los productossuelen implicar un aumento de los costes del proyecto. Las técnicas deEuromé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 proporcionaEurométodo. Las dependencias de datos entre estas técnicas son similares a lasdependencias que se ilustran y explican en el apartado 2.2.

Procesos dentrode la gestión deriesgos

No extraerconclusionesprecipitadas

Comprender losfactores desituación

Interaccionesentre los riesgos



Técnicas (pasos) Insumo y resultados

Análisis de riesgos:

1. Documentar el estado inicial y el estadofinal.

2. Valorar los factores de situación.

3. Evaluar la incertidumbre y complejidadgenerales.

4. Analizar la probabilidad de riesgos.

5. Identificar los riesgos críticos.

Insumo: Información acerca de la situación delproblema, incluyendo las líneas generales deun plan de adaptación: objetivo, estado inicial,requisitos de puntos de decisión.

Resultados:

Apreciación y descripción de una situación delproblema: estados inicial y final, factoressituacionales y riesgos (probabilidades yrepercusiones).

Diseño de una estrategia de adaptación:

1. Seleccionar las contramedidas.

2. Analizar las opciones estratégicas.

3. Seleccionar las opciones estratégicas.

4. Analizar las repercusiones de la estrategia.

Insumo: Información acerca de la situación delproblema, incluyendo los factores situacionalesy los riesgos (probabilidades y repercusiones).

Resultados:

Descripción de una estrategia de adaptación:opciones estratégicas, contramedidasnecesarias.

Planificación de los puntos de decisión:

1. Extraer la secuencia básica de puntos dedecisión.

2. Adaptar la secuencia básica a lascontramedidas.

3. Describir los puntos de decisión.

Insumo: Información acerca de la situación delproblema y la estrategia de adaptación(opciones de estrategia y contramedidas).

Resultados:

Descripción de la secuencia y contenido de lospuntos de decisión.

Descripción de los entregables:

1. Definir los perfiles de los elementosdescriptivos.

2. Establecer un enlace con los productos delmétodo.

Insumo: Descripciones de los puntos dedecisión con los requisitos de los entregables.

Resultados:

Descripciones de los puntos de decisión con losperfiles de los entregables y referencias a losproductos del método.

Valoración del plan de adaptación:

1. Valorar la descripción de la situación.

2. Valorar la idoneidad de la estrategia.

3. Valorar la idoneidad de los puntos dedecisión.

Insumo: Un plan de adaptación e informaciónacerca de la situación actual.

Resultados:

Valoración de la idoneidad de un plan deadaptación en la situación actual.

Figura 4.1: Técnicas de planificación de la adaptación en una adaptación singulardel sistema de información.

4.2 Análisis de riesgos

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



El cliente puede utilizar estas técnicas para valorar de una forma clara y sistemáticalas 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écnicaspara comprender y valorar mejor la situación del problema.

Tanto el cliente como el proveedor pueden utilizar las técnicas en el curso de unaadaptación del SI cuando sea preciso cambiar los planes o planificar futurasadaptaciones del SI.

La finalidad de las técnicas de análisis de riesgos es comprender los aspectosrelevantes de la situación de una adaptación presente o futura del SI, para estaren condiciones de emprender las acciones adecuadas.

El análisis de riesgos se sustenta en los factores situacionales definidos enEurométodo. Para valorar los factores situacionales, es importante comprenderbien las expectativas actuales con respecto a los resultados y el punto de partida dela adaptación del SI. Para ello deberá documentarse el punto de partida (estadoinicial) y el objetivo (estado final). La valoración de los factores situacionales es labase para la evaluación de la incertidumbre y la complejidad de la situación. Losriesgos pueden extraerse de los factores situacionales y de la incertidumbre ycomplejidad generales. Posteriormente, se identificará la importancia de los riesgosanalizando las probabilidades y repercusiones de los mismos.

Los resultados obtenidos con este análisis de la situación del problema representanun insumo para la definición de la estrategia de adaptación y la planificación de lospuntos de decisión.

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 deuna adaptación del SI en un plan de adaptación. En apartado 2.2 se indica cómodefinir una adaptación viable del SI en términos de un estado inicial y un estadofinal. En el apartado 2.2 se definen los estados iniciales y finales típicos y se explicaqué 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 deinformación y los conocimientos disponibles sobre el mismo alcomienzo de la adaptación del SI.

El estado final de una adaptación del SI es el estado del sistema deinformación y los conocimientos sobre el mismo al final de laadaptación del SI [EM-DC].

En la práctica, las descripciones de los estados inicial y final suelen producirse enparalelo, aunque aquí se relacionan en su orden natural:

1. Documentar el estado inicial.Comprender y describir el contenido y calidad de los elementos descriptivos yde los elementos operativos que estarán disponibles para los agentes delproyecto que realicen la adaptación del SI.

Eurométodoproporcionadefiniciones delos factoressituacionales

Estados inicialesy finales típicos



2. Documentar el estado final.Analizar qué elementos descriptivos y qué elementos operativos precisará yutilizará el cliente cuando haya finalizado esta adaptación del SI. Bosquejar loselementos operativos y describir los elementos descriptivos en forma deperfiles, como se explica en el capítulo 3.

Documentar el estado inicial

Es posible que algunos productos del estado inicial ya existan, y otros vayan aproducirse antes del inicio de la adaptación del SI; por ejemplo, a raíz de otraadaptación del SI o de un proceso de licitación. Estas expectativas deberándocumentarse en base a los planes actuales y demás información relevante.

Los elementos descriptivos del estado inicial pueden describir elementos operativosque ya se utilizan en el estado inicial o elementos operativos futuros, por ejemplolos elementos operativos que deberían construirse e instalarse en esta adaptacióndel SI. Las descripciones de futuros elementos operativos pueden utilizarse paracomprender los cambios que precisa el SI operativo, y para comprender el SI en suestado final. Por consiguiente, pueden utilizarse para documentar el estado final.

Para documentar el estado inicial, normalmente es preciso desglosar en subsistemasel SI en su estado inicial o futuro y, en aquellas situaciones en que sea posible yprocedente, describir el estado inicial de cada uno de los subsistemas. Lossubsistemas pueden definirse mediante un mayor desglose del dominio objetivo endominios objetivos de menor tamaño.

Para cada subsistema podrá utilizarse el siguiente procedimiento:

1. Valorar qué descripciones de elementos operativos utilizados o construidos enel estado inicial, son relevantes para esta adaptación del SI.

− Describir los elementos operativos mediante una visión general basada enla información disponible en la situación actual.

− Describir los elementos descriptivos mediante sus perfiles, véase apartado4.5.1.

2. Valorar qué descripciones de futuros elementos operativos son relevantes paraser utilizadas en esta adaptación del SI.

− Describir los elementos descriptivos mediante sus perfiles, véase apartado4.5.1.

Documentar el estado final

Para documentar el estado final, normalmente es preciso desglosar en subsistemasel 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 diferentestipos de elementos descriptivos relativos a los subsistemas.

Para cada subsistema podrá utilizarse el siguiente procedimiento:

1. Describir los elementos operativos utilizados o construidos en el estado finalmediante un resumen de los elementos descriptivos existentes en la situaciónactual. El resumen deberá centrarse en:

¿Quédescripcionesutilizará elcliente despuésde la adaptacióndel SI?

Es posible quealgunosproductos delestado inicial noexistan aún

Desglosar ensubsistemas

Elementosoperativos yelementosdescriptivos delestado inicial

Elementosoperativos delestado final



− 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 garantizarque el nuevo SI funciona con eficiencia y sin problemas.

− los datos que se hallan en el sistema de información existente y que debenconvertirse en nuevos elementos operativos del nuevo sistema deinformació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 seutilizan actualmente

− la nueva organización y los nuevos agentes que se introducirán, como porejemplo 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 elestado final.

− Los elementos descriptivos que se precisan para mantener de forma eficazel sistema de información en su estado final. Deberá definirse la política demantenimiento de estos elementos descriptivos, por ejemplo: quién esresponsable de este mantenimiento.

− Los elementos descriptivos que van a utilizarse tras la finalización de estaadaptación del SI al objeto de continuar desarrollando de manera eficienteel sistema de información en su estado final. Siempre que sea posibledeberán utilizarse los planes disponibles acerca de desarrollos ulteriores.

3. Si esta adaptación del SI dará como resultado propuestas de futurasadaptaciones del SI, es preciso describir:

− los requisitos de los planes apropiados para estas futuras adaptaciones delSI, incluyendo los requisitos de los perfiles de los elementos descriptivospresentes en el estado final.

Listas de comprobación

Las figuras 4.2 y 4.3 muestran una visión general de los productos que puedenestar disponibles al inicio y al final de una adaptación del SI. Estas figuras puedenutilizarse como listas de comprobación al documentar los estados inicial y final.

Elementosdescriptivos delestado final

Planes del estadofinal



Productos al inicio de la adaptacióndel SI:

Productos del estado inicial

Productos al final de laadaptación del SI:

Productos del estado final

Versión delsistema

Producto

Sistema deinformación enestado inicial

Futuro sistema deinformación

Sistema deinformación en

estado final

Futurosistema de

información

Elementos operativos 1.

Elementosoperativos

utilizados en elestado inicial

2.

Elementosoperativos

construidos, peroque aún no se

utilizan

11.

Elementosoperativos

utilizados en elestado final

12.

Elementosoperativos

construidos,pero que aúnno se utilizan

Elementosdescriptivos

3.

Descripciones de1: elementosoperativos


4a.

Descripciones de2: elementosoperativos

construidos, peroque aún no se

utilizan.

4b.

Descripciones de11 y 12: futuros

elementosoperativos

13.

Descripcionesde 11:

elementosoperativos

utilizados en elestado final

14a.

Descripcionesde 12:

elementosoperativos

construidos,pero que aúnno se utilizan.

14b.

Descripcionesde futuroselementosoperativos.

Perfiles de elementosdescriptivos de planesde adaptación

5.

Perfiles de 3:descripciones de

elementosoperativos


6a.

Perfiles de 4a y4b:

descripciones defuturos elementos

operativos

6b.

Perfiles de 13,14a y 14b:elementos

descriptivos delestado final

15.

Perfiles de 13:descripcionesde elementos

operativosutilizados en el

estado final

16a.

Perfiles de 14ay 14b:

descripcionesde futuroselementosoperativos.

16b.

Perfiles defuturos

elementosdescriptivos

Figura 4.2: Productos de los estados inicial y final relacionados con las versionesdel sistema.



Productos al inicio de la adaptación delSI:

Productos del estado inicial

Productos al final de laadaptación del SI:

Productos del estado final

Adaptación del SI

Producto

Adaptación actual del sistema deinformación

que comienza en el estado inicial

Futura adaptación del sistemade información

que comienza en el estadofinal o más tarde

Planes de adaptación Un plan de adaptación que incluya:

• Descripciones del estado inicial- Resumen de 3 y 4a:

descripciones de elementosoperativos utilizados oconstruidos en el estadoinicial.

- 5, 6a: perfiles de loselementos descriptivosdisponibles en el estadoinicial.

• Descripciones del estado final- Resumen de 4b:

descripciones de elementosoperativos utilizados oconstruidos en el estadofinal.

- 6b: perfiles de los elementosdescriptivos del estado final.

- Requisitos de los planes deadaptación presentes en elestado final, por ejemplo,requisitos de 15, 16a, 16b:perfiles del estado final yfuturos elementosdescriptivos.

Posiblemente planes deadaptación para futuras

adaptaciones del SI

Planes del proyecto Posiblemente un plan del proyecto queincluya:• plan de desarrollo• plan de garantía de calidad• plan de gestión de la configuración

Posiblemente planes deproyecto para futurasadaptaciones del SI

Figura 4.3: Productos de los estados inicial y final relacionados con adaptacionesdel 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 lasituación del problema que pueden utilizarse para determinar laestrategia más adecuada para resolver el problema. Se incluyenaquellas propiedades que pueden influir en los distintos tipos deeventos inciertos que puedan ocurrir y sus consecuencias adversas[EM-DC].

El análisis de los factores situacionales según Eurométodo puede utilizarse parapredecir los riesgos de una situación y para determinar la estrategia de adaptaciónmás apropiada a fin de evitar o contener dichos riesgos.

El análisis de los factores de situación utiliza una lista de comprobación paraadquirir conocimientos acerca de una situación del problema. Los conocimientospueden adquirirse analizando documentos y/o entrevistando a los agentes clave delsistema de información. Es preciso planificar con cuidado las entrevistas y tener encuenta 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 acargo de más de una persona.

• ¿Cómo redactar las preguntas?El análisis de los factores situacionales deberá adaptarse siempre a lasituación y las preguntas deberán redactarse de manera que la personaentrevistada comprenda los factores y los motivos de las preguntas.

Estas entrevistas deberían proporcionar información que justifique los valores delos 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 justificarestos valores.

Las figuras 4.4 a 4.6 proporcionan una visión general de los factores situacionales,sus definiciones, influencia en los riesgos y valores. El anexo B contienedescripciones detalladas de los factores. La estructura de las descripciones semuestra en la figura 4.7. De estas descripciones se pueden extraer las preguntasque deben plantearse al objeto de adquirir los conocimientos necesarios paradeterminar los valores de los factores situacionales.

Cuando las respuestas relativas a un factor situacional son poco claras o demasiadogenerales, normalmente indican que el alcance del SI que se está investigando esdemasiado grande. En este caso el sistema de información deberá dividirse ensubsistemas, 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

Lista decomprobaciónpara adquirirconocimientos

Las preguntaspueden derivarsede lasdefiniciones delanexo B

Dividir ensubsistemas osubfactores



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 quepueden utilizarse para registrar los factores situacionales marcando con una señallos valores apropiados para la situación del problema en cuestión. De este modo seobtiene una visión general de la situación del problema, que puede utilizarse para ladefinición de una estrategia de adaptación adecuada. Las tablas de factoressituacionales deberán estar respaldadas por una explicación y justificación de losvalores seleccionados. La lista de factores situacionales no es definitiva niexhaustiva. Contiene ejemplos que pueden utilizarse y mejorarse en base a laexperiencia personal y organizativa.

Las tablas de factores situacionales resaltan el carácter abierto de Eurométodo, altener 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 factoressituacionales registren su propia experiencia señalando:

• qué factores situacionales adicionales (actualmente no definidos enEurométodo) es importante tener en cuenta, y cómo pueden influir en losriesgos y en la estrategia de adaptación

• cómo determinar los factores situacionales relevantes (por ejemplo, en formamétrica, como tamaño del proyecto), adaptados a sus situaciones típicas delproblema; y los métodos para adquirir los conocimientos necesarios en unaorganización

• qué factores situacionales son los más importantes; por ejemplo, en forma degrados 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 unamatriz bidimensional: el dominio y la caracterización de los conocimientos.

La dimensión del dominio determina qué parte de la organización debeinvestigarse. Se consideran dos dominios:

• Dominio objetivo.La parte de la organización para la cual debe adaptarse el SI. Los factoresdel 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 existirningún algoritmo o regla para deducir el valor en base a los valores de los distintossubfactores.

Documentar yjustificar losvalores de losfactoressituacionales

Sistematizar yutilizar la propiaexperiencia

Dominioobjetivo yfactores deldominio delproyecto



La organización que realiza la adaptación del sistema de información. Losfactores 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.

La otra dimensión, la caracterización de los conocimientos, divide losconocimientos adquiridos para gestionar la situación del problema en las categoríasde complejidad e incertidumbre. Todo factor situacional puede afectar a los riesgosy la idoneidad de una estrategia de adaptación, bien directamente, bien a través desu contribución a la incertidumbre y complejidad generales de la situación:

• la complejidad puede considerarse la dificultad hallada al gestionar losconocimientos disponibles. La escala de complejidad de una situación es:simple⇒moderada⇒compleja19.

• la incertidumbre puede considerarse la falta de conocimientos disponibles. Laescala 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 alasignar un valor al factor cuando se analiza la situación del problema y al asociar unaestrategia de adaptación a cada uno de los valores. La reducción dos niveles supone unaclasificación demasiado generalizada, en la medida en que proponen casos extremos y nopermiten expresar una situación normal o neutra.

Factores decomplejidad eincertidumbre



Figura 4.4: Factores de complejidad relativos al dominio objetivo.

Dominioobjetivo

Factor decomplejidad

Breve descripción e influencia en los riesgos simple moderada compleja


Heterogeneidadde los agentes

Los agentes pueden ser heterogéneos por motivosorganizativos, políticos o individuales. Ejemplos deagentes: usuarios, gestores, socios, operadores ymáquinas.êConflictos en los requisitos.êLa adaptación del SI no se acepta.

baja media alta

Tamaño deldominioobjetivo

Puede expresarse en número de áreas de negocio ynúmero de unidades organizativas.êPérdida de control del proyecto.

pequeño medio grande

Tamaño de ladistribución

Número de sedes geográficas.êEl sistema de información no funciona.êPérdida de control del proyecto.

pequeño medio grande

Complejidadde lainformación

Los recursos de información del dominio objetivo.Por ejemplo pueden expresarse en número deentidades, atributos y relaciones.êEl sistema de información no funciona.

baja media alta

Complejidadde los procesosde negocio

Subfactores: número de procesos de negocio einterfaces, y complejidad de las reglas y algoritmosdel negocio.êEl sistema de información no funciona.

baja media alta

Sistemainformático

Complejidadde los datos

Los datos que representan la información y sealmacenan en un ordenador. Por ejemplo, puedenexpresarse en número de entidades, atributos yrelaciones.êEl sistema de información no funciona.

baja media alta

Complejidadde lasfuncionesautomatizadas

Las partes de los procesos que son ejecutadas porun ordenador. Por ejemplo, pueden estimarseutilizando el Análisis de Punto de Función.êEl sistema de información no funciona.

baja media alta

Complejidadde laspropiedades decalidad

Ejemplos de subfactores: eficiencia, seguridad,fiabilidad, mantenibilidad, portabilidad y facilidadde uso.êEl sistema de información no funciona.

baja media alta

Número dereplicacionesdel sistemainformático

El número de copias del sistema informático quedebe instalarse.ê Pérdida del control del proyecto.

una pocas muchas

Complejidadde la tecnologíaobjetiva

La tecnología utilizada como plataforma de losdispositivos físicos y el software del sistemainformático.êEl sistema de información no funciona.

baja media alta



Figura 4.5: Factores de incertidumbre relativos al dominio objetivo.

Dominioobjetivo

Factor deincertidumbre

Breve descripción e influencia en losriesgos

cierta mode-rada

incierta


Actitud de los agentes Subfactores: percepción de la necesidad,compromiso, motivación.êFalta de participación de los agentes.êLa adaptación del sistema de información no esaceptada.

pos. neutral neg.

Habilidad de losagentes

Capacidad, experiencia, cualificaciones,disponibilidad.êSistema de información inadecuado.

alta mediana baja

Estabilidad delentorno

Subfactores: políticos, legales, de mercado, denegocios y de estabilidad financiera.êRequisitos variables (cambio del objetivo)

alta mediana baja

Formalidad de lainformación

La información puede estar formalizada y descritapor datos.êRequisitos irrealizables.

alta mediana baja

Formalidad de losprocesos del negocio

Los procesos pueden estar formalizados yparcialmente realizados por ordenador.êRequisitos irrealizables.

alta mediana baja

Estabilidad de lainformación y de losprocesos del negocio

Número y tipos de cambios previstos.êRequisitos variables (cambio del objetivo)

alta mediana baja

Especificidad delsistema deinformación

Tipo estándar frente a tipo específico.êRequisitos irrealizables.

alta mediana baja

Grado decomprensión delsistema actual

La comprensión del sistema de información porparte del agente.êSistema de información incorrecto.êCostes impredecibles.

alto mediano bajo

Importanciaestratégica

Oportunidades estratégicas que ofrece el sistema deinformación.êRepercusiones en el negocio de un fallo.

alta mediana baja

Importancia de loscambios organizativos

Repercusiones en la estructura de la organización ylas tareas de los agentes.êLa adaptación del SI no es aceptada.êCostes impredecibles para la organización.

alta mediana baja

Disponibilidad,claridad y estabilidadde los requisitos

Los requisitos son las condiciones esenciales quedebe satisfacer un SI.êRequisitos inciertos e irrealizables.êIncertidumbre en las interfaces con otrossistemas.

alta mediana baja

Calidad de lasespecificacionesexistentes

Las especificaciones son descripciones definitivas.êSistema de información inadecuado.êCostes impredecibles para el proyecto.

alta mediana baja

Sistema informático Importancia de loscambios tecnológicos

Importancia del cambio y repercusión en laadaptación del SI.êDeficiencias de calidad.êLa adaptación del SI no es aceptada.êCostes impredecibles para la organización.

alta mediana baja

Novedad de latecnología objetiva

Una medida del carácter innovador de la tecnologíaobjetiva con respecto al estado de la técnica.êDeficiencias de calidad.êLa adaptación del SI no es aceptada.êCostes impredecibles para el proyecto.

alta mediana baja



Figura 4.6: Factores de complejidad e incertidumbre relativos al dominio delproyecto.

Dominiodel proyecto


Breve descripción simple mode-rada

compleja

Tarea delproyecto

Tamaño del proyecto Por ejemplo, número de meses o años de trabajo.êPérdida de control del proyecto.

pequeño mediano grande

Complejidad de lamigración

Una medida de la dificultad de la migración en todas lassedes operativas del dominio objetivo.êPérdida de control del proyecto.

baja mediana alta

Estructura delproyecto

Número desubcontratistas

Se refiere al control del proyecto que se precisa paragestionar recursos externos del proyecto.êPérdida de control del proyecto.

ninguno pocos muchos

Número deinterfaces con otrasadaptaciones del SI

Se refiere al control del proyecto que se precisa paragestionar interfaces externas con otras adaptaciones del SI.êPérdida de control del proyecto.

ninguna pocas muchas

Agentes delproyecto

Número de agentesdel proyecto

Número de interesados que se relacionan con la adaptacióndel SI, como usuarios, expertos, personal de desarrollo,clientes, gestores, etc.êPérdida de control del proyecto.

pequeño mediano grande

Tecnología delproyecto

Complejidad de latecnología delproyecto

La complejidad de utilizar la tecnología del proyecto pararealizar la tarea de desarrollo.êPérdida de control del proyecto.

baja mediana alta

Dominio delproyecto


Breve descripción e influencia en los riesgos cierta mode-rada

incierta

Tarea delproyecto

Innovación de laadaptación delsistema deinformación

Una medida de la innovación que supone la adaptación delSI respecto del estado de la técnica.êSistema de información inviable.êCostes impredecibles del proyecto.

baja mediana alta

Idoneidad de losprogramas

Debido a estimaciones erróneas o a la urgencia delproyecto.êBaja calidad de los entregables; aumento de los costes.

- normal ajustada

Idoneidad delpresupuesto

êBaja calidad de los entregables.êRetrasos en la entrega.

- normal ajustada

Estructura delproyecto

Dependencia desubcontratistas

êDeficiencias en las tareas que se realizan externamente.êPérdida de control del proyecto.

nula baja alta

Dependencia deotras adaptacionesdel SI

Por ejemplo, interfaces comunes, integración común.êRequisitos variables; problemas de integración.

nula baja alta

Formalidad delcontexto cliente-proveedor

Conformidad con las reglas y procedimientos definidos.ê Requisitos variables.êLa adaptación del sistema de información no esaceptada.

alta mediana baja

Agentes delproyecto

Capacidad delequipo de proyecto

Subfactores: cualificaciones, conocimientos, capacidad,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.

alta mediana baja

Tecnología delproyecto

Innovación de latecnología delproyecto

Con respecto a los últimos avances tecnológicos.êBaja calidad, retrasos, costes impredecibles.

baja mediana alta

Disponibilidad de latecnología delproyecto apropiada

Subfactores: entrega, apoyo y accesibilidad.êBaja calidad, retrasos, costes impredecibles.

alta mediana baja



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.

Nombre del factor situacional

• Explicación: breve descripción del factor y definiciones deconceptos 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óndel problema que describe el factor situacional que posee esevalor. Por consiguiente, cada riesgo se describe en términos delos eventos inciertos que pueden ocurrir en la situación delproblema:– Para los factores de complejidad, los riesgos afectan a la

gestión (pérdida de control del proyecto) y al diseño (elsistema de información no funciona o es incapaz degestionar la complejidad).

– Para los factores de incertidumbre se mencionan losriesgos de cada uno de ellos.

• Acciones de inhibición, cuando existen medidas concretas queposiblemente inhiben los riesgos al cambiar el valor individualdel factor situacional. El valor del factor situacional se cambiaal abordar el problema subyacente. Las acciones de inhibiciónpropuestas son ejemplos, y no son posibles para todos losfactores situacionales, por ejemplo, la complejidad yformalidad de la información y los procesos del negocio.

• Observaciones que permiten a usuarios específicos registrarinformación adicional.



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 generalo a la incertidumbre general de la adaptación del SI. Normalmente estos factoresejercerán una gran influencia en la definición de la estrategia de adaptaciónapropiada, tal y como se explica en el apartado 4.3.

Ejemplo La adaptación del SI es incierta, en especial debido a los siguientesfactores asociados al dominio objetivo:

• Escasa estabilidad del entorno: por ejemplo, los requisitos legalescambian a menudo.

• Alta especificidad del sistema de información: no existen paquetesque 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 esinsuficiente para estimar con exactitud el volumen de trabajo y lossiguientes factores relativos al dominio del proyecto:

• El calendario y el presupuesto son ajustados.

Los siguientes factores disminuirán la incertidumbre de la adaptacióndel 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 delsistema actual.

• Los cambios organizativos no son importantes.

• La calidad de las especificaciones del sistema informático actual esalta.

• Se espera que la capacidad del equipo de proyecto sea alta.

Puede utilizarse el siguiente procedimiento:

1. Elaborar una lista con todos los factores que posean losvalores ‘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 todainfluencia 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 eincertidumbre generales. Esta lista también puede utilizarse para valorar si unaestrategia de adaptación es viable y apropiada.

Procedimiento



La lista de factores situacionales no es definitiva ni exhaustiva.Contiene ejemplos que pueden utilizarse y mejorarse en base a la experienciapersonal y organizativa.

4. Utilizar la pericia existente en el seno de la organización para complementar lalista de factores situacionales y evaluar su influencia en la complejidad y laincertidumbre.

5. Utilizando los resultados de los cuatro pasos anteriores, determinar lacomplejidad e incertidumbre generales de la adaptación del SI.

La complejidad de una adaptación del SI se denomina ‘complejidad general’ y laescala de factores de complejidad, dividida en los tres niveles simple, moderado ycomplejo, 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 puedeanalizarse valorando los riesgos que puede causar este factor; véanse los siguientesapartados. Las heurísticas acerca de la valoración de riesgos se basan en ocasionesen la complejidad e incertidumbre generales, es decir, existen interdependenciasentre las distintas técnicas de análisis de riesgos, que deberían utilizarse en paraleloy/o de forma iterativa.

4.2.4 Analizar la probabilidad de riesgos

Definición Un riesgo es la posibilidad de exposición a las consecuenciasadversas de eventos futuros [EM-DC].

Eurométodo proporciona una lista de riesgos que se describen a modo deconsecuencias adversas que pueden producirse. Los riesgos se refieren a lasprestaciones del proyecto, y pueden deberse a la complejidad y la incertidumbre dela situación. Eurométodo indica los orígenes de estos riesgos en forma de valoresde factores situacionales. Los riesgos y los ejemplos de relaciones entre riesgos yfactores situacionales están representados en las figuras 4.8 y 4.9. Los riesgosaparecen 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 nofunciona.

La gravedad de los riesgos viene determinada por:

• la probabilidad de que tengan lugar eventos con consecuencias adversas.

• las repercusiones de esas consecuencias, por ejemplo, repercusiones en loscostes, el calendario y la calidad de los entregables.

En este apartado describe una técnica para analizar la probabilidad del riesgo. En elsiguiente apartado se comentan las técnicas para valorar las repercusiones de losriesgos. 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.

Listas de riesgosde prestación ysus orígenes

Gravedad de losriesgos



El análisis de las probabilidades de riesgo deberá documentarse utilizando laplantilla del anexo D.19. La figura 4.10 ofrece un ejemplo de probabilidades deriesgo. Puede utilizarse el siguiente procedimiento:

1. Elaborar una lista de los factores situacionales que implican incertidumbre dela 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 quemuestran las figuras 4.8 y 4.9, y marcar también con una X los riesgosgenerales, 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, enbase a un análisis de los factores situacionales, como se ha explicado en losapartados 4.2.2 y 4.2.3. Si no se ha realizado este análisis, el procedimiento puedecomenzar en el punto 4.

4. Repasar la lista de riesgos y analizarlos uno por uno a la luz de la informaciónadicional 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 puedenutilizarse y mejorarse en base a la experiencia personal y organizativa.

5. Utilizar la pericia existente en el seno de la organización para complementarlas listas de riesgos y factores de situación, y repetir los puntos 1-4.

Una técnica paraanalizar lasprobabilidadesde riesgo

Complementarcon la propiaexperiencia



Figura 4.8: Riesgos causados por la incertidumbre del dominio objetivo.

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 sonimportantes

Requisitos inciertos

Baja calidad de las especificaciones

RiesgoCambios tecnológicos

importantes

(consecuencias adversas) Tecnología objetivanovedosa

Requisitos inciertos o inviables X X X X X

Incertidumbre en las interfaces con otrossistemas X

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 deldominio objetivo X

Deficiencias en las tareas realizadasexternamente

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 deinformáticaSistema de información incorrecto oinviable X X X X X X X X X X

Adaptación del sistema de información noaceptada por los agentes X X X

Repercusiones en el negocio del fallo delproyecto X X



Factores del dominio del La novedad de la adaptación del SI es alta

proyecto que implicanincertidumbre

La idoneidad del calendario es ajustada

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 esbaja

Riesgo

(consecuencias adversas)

Requisitos inciertos o inviables

Incertidumbre en las interfaces con otrossistemas

Requisitos variables X X

Costes impredecibles para laorganizaciónCostes impredecibles para el proyecto X X X X

Falta de participación de los agentes deldominio objetivoDeficiencias en las tareas realizadasexternamente X

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 conocimientosde informática X

Sistema de información incorrecto oinviable X X

Adaptación del sistema de informaciónno aceptada por los agentes X X

Repercusiones en el negocio del fallo delproyecto

Figura 4.9: Riesgos asociados a la incertidumbre del dominio del proyecto.



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

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

Riesgo Complejidad global

(consecuencias adversas) Probabilidad Repercusiones

Requisitos inciertos o inviables X X !+ ?

Incertidumbre en las interfaces con otrossistemas X + ?

Requisitos variables X X -

Costes impredecibles para la organización X X + ?

Costes impredecibles para el proyecto X -

Falta de participación de los agentes deldominio objetivo -

Deficiencias en las tareas realizadasexternamente -

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 deinformática X -

Sistema de información incorrecto oinviable X X X + ?

Adaptación del sistema de información noaceptada por los agentes X -

Repercusiones en el negocio del fallo delproyecto X + ?

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 -



4.2.5 Identificar los riesgos críticos

Deberá prestarse especial atención a los riesgos con muchas probabilidades deocurrir y graves repercusiones en la adaptación del SI. Estos riesgos se denominanriesgos críticos. Los riesgos críticos deberían influir en la definición de la estrategiade adaptación y de los puntos de decisión, y conviene que estén documentados enel plan de adaptación.

Las repercusiones de los riesgos dependen en gran medida del contexto de laadaptación del SI, y son específicas de ese contexto. Los riesgos incluidos en lalista 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 losentregables. Esta técnica describe un procedimiento general para la identificaciónde los riesgos críticos en base a una valoración de las repercusiones yprobabilidades.

Los riesgos críticos deberán identificarse por:

• El principal tipo de repercusiónPor 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 sedenominan 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 laadaptación del SI. El nivel de aceptación puede expresarse, por ejemplo,mediante un requisito mínimo relativo al riesgo, o mediante cifras relativas auna medida que constituyan un límite superior; por ejemplo, costes.

El siguiente procedimiento puede utilizarse para cualquier riesgo cuya valoraciónse 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 demedida 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 altarepercusió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.

Riesgos con altaprobabilidad ygravesrepercusiones

Descripción delos riesgoscríticos

Procedimiento



Ejemplo • Requisitos inciertos o inviables.Ejemplo de repercusión:Puede resultar difícil completar la adaptación del sistema deinformación. La aceptación de los entregables puede ser causa deconflictos.

Nivel de aceptación:Un requisito mínimo es que el nuevo sistema informático puedasustituir completamente al sistema actual y que los procedimientosdel 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úmeropuede disminuir y su actitud tornarse negativa. Algunasorganizaciones del dominio objetivo pueden iniciar sus propiasadaptaciones del sistema de información y los problemas deintegración aumentarán.

Nivel de aceptación:Se puede aceptar cierto retraso respecto a los plazos actuales, perola sustitución del sistema informático actual deberá haber finalizadoa 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 decomunicación, y el futuro profesional de las personas que ocupancargos de responsabilidad puede verse seriamente afectado.

Nivel de aceptación:No se puede aceptar ningún tipo de crítica adversa procedente deuna auditoría oficial.



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 unaestrategia de adaptación adecuada. Este apartado ofrece técnicas útiles en esteproceso20.

Definición Una estrategia de adaptación es el enfoque encaminado a conseguirlos objetivos de una adquisición o de una adaptación del SI, altiempo que gestiona de manera eficaz los riesgos inherentes a ciertasituación del problema [EM-DC].

Las siguientes técnicas permiten la selección de una estrategia de adaptaciónadecuada que consistirá en:

• determinación de contramedidas apropiadas

• un enfoque del desarrollo para la descripción, construcción e instalación

• un enfoque de control del proyecto.

Definición Una estrategia para un proceso es el enfoque encaminado a alcanzarlos objetivos del proceso, es decir, un enfoque apropiado paragestionar de manera eficaz la complejidad e incertidumbre inherentesal proceso [EM-DC].

El siguiente procedimiento puede utilizarse para seleccionar una estrategia deadaptación apropiada en base a un análisis de riesgos:

1. Seleccionar countramedidas para la complejidad y la incertidumbre utilizando:− las heurísticas que proporciona Eurométodo.− 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 losriesgos 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 lospróximos pasos.

• Véase apartado 4.2: Análisis de riesgos.

3. Analizar las opciones estratégicas que proporciona Eurométodo.

Véase apartado 4.3.2: Opciones estratégicas.

4. Seleccionar las opciones estratégicas utilizando las heurísticas de Eurométodoy la experiencia personal y organizativa.

20 Las técnicas se basan en los conceptos definidos en Eurométodo, los cuales sustentan lascuestiones de tipo técnico relativas a la planificación de la adaptación. Las demáscuestiones, por ejemplo de tipo financiero y legal, que pueden ser vistas de distinta manerapor el cliente y el proveedor, no se contemplan.

Contenido deuna estrategia deadaptación

Heurísticas paracontramedidas

Opciones yheurísticas parala estrategia



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

5. Analizar las repercusiones de las opciones estratégicas elegidas.

Véase apartado 4.3.4: Análisis de las repercusiones de las contramedidas.

La valoración de la situación que supone la base para la selección de lascontramedidas y las opciones estratégicas puede haber cambiado. Porconsiguiente, quizá sea preciso repetir los pasos 1-5 hasta que la estrategia deadaptación resultante sea adecuada para su finalidad.

La estrategia de adaptación seleccionada será la base para la posterior planificaciónde los puntos de decisión, véase apartado 4.4. La estrategia comporta lajustificación de la secuencia y contenido de los puntos de decisión. Así pues, laestrategia deberá documentarse como parte del plan de adaptación. Lasheurísticas de las técnicas no son definitivas ni exhaustivas. Se trata deejemplos que pueden utilizarse y mejorarse a la luz de la experiencia personal yorganizativa. Las heurísticas no contienen relaciones complejas, como porejemplo dependencias, entre los factores situacionales.

4.3.1 Selección de contramedidas

Esta técnica proporciona heurísticas para gestionar los riesgos motivados por lacomplejidad y la incertidumbre de una situación. Las heurísticas elaboranpropuestas de requisitos de los puntos de decisión y los recursos. Estos requisitosdeberá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 complejidadtiene que ver con un único factor situacional, mientras que la resolución de losriesgos causados por la incertidumbre tiene en cuenta una combinación de factoressituacionales. Por lo tanto, las heurísticas para gestionar la complejidad estánrelacionadas con factores de situación individuales, mientras que las heurísticaspara gestionar la incertidumbre están relacionadas con los riesgos causados por laincertidumbre.

Las opcionesestratégicaspueden crearriesgos



Riesgo Contramedidas para minimizar el riesgo

Requisitos inciertos oinviables

ê Crear o utilizar un buen nivel de comprensión del sistema deinformación existente.

ê Adoptar decisiones iniciales acerca de las descripciones delfuturo sistema de información; por ejemplo, realizar unanálisis de requisitos riguroso y añadir al plan de adaptaciónpuntos de decisión acerca de los requisitos del futuro sistemade información, e implementar un sistema de control de losrequisitos.

ê Llevar a cabo un programa de formación para las personasque son agentes en la adaptación del sistema de información.

ê Utilizar métodos formales para el análisis de requisitos.

Incertidumbre de lasinterfaces con otrossistemas

ê Utilizar normas publicadas.

ê Crear normas propias y utilizarlas.

ê Involucrar en el control del proyecto a la gerencia de un SIasociado.

Requisitos variables ê Prestar mucha atención al diseño y construcción de unsistema de información adaptable, es decir, el plan de calidaddeberá contener criterios de calidad acerca de laadaptabilidad.

ê Implementar, junto con el cliente, un sistema riguroso decontrol de cambios

ê Planificar los puntos de decisión de inversión, revisando losrequisitos.

Costes impredeciblespara la organización

ê Disminuir la incertidumbre relativa a los costes incluyendo enel plan de adaptación puntos de decisión acerca de estoscostes, y ello en una fase inicial de la adaptación del sistemade información.

ê Utilizar asesoramiento profesional.

Costes impredeciblespara el proyecto

ê Rehacer las especificaciones, es decir, añadir al plan deadaptación puntos de decisión relativos a la aprobación de lasespecificaciones del futuro sistema de información.

ê Revisar las especificaciones actuales con los agentes delsistema de información.

ê Planificar los puntos de decisión de inversión, clarificando losrequisitos y los costes.

Falta de participaciónde los agentes deldominio objetivo

ê Obtener el apoyo y la responsabilidad de participación de la.alta dirección

ê Investigar y analizar la motivación de los agentes deldominio.

ê Motivar a los agentes, por ejemplo, haciendo que losbeneficios sean comprensibles y visibles.

ê Involucrar a los agentes, por ejemplo, aumentando suinformación.



Riesgo Contramedidas para minimizar el riesgo

Deficiencias técnicasde las tareasrealizadasexternamente

ê Incluir al proveedor externo en la fase de diseño y no sólodescribir los entregables, sino también para qué se utilizan.

ê Controlar la producción externa.

Retrasos de laentrega

ê Planificar opciones alternativas.

ê Planificar puntos de decisión de inversión que permitan unarevisión de las expectativas.

ð Asignar más personal al equipo del proyecto.

ð Asignar personal más capacitado al equipo del proyecto.

Baja calidad de losentregables

ê Utilizar una definición clara y mensurable de la calidad quese precisa.

ê Formar el equipo del proyecto; por ejemplo, formar a losagentes del sistema de información que participen en laadaptación del SI.

ê Prolongar los plazos.

Incremento de loscostes del proyecto

ê Controlar frecuentemente el presupuesto.

ê Planificar puntos de decisión de inversión que permitan unarevisión de las expectativas.

Problemas deintegración

ê Utilizar métodos formales para especificar las partes del SI.

ê Involucrar al cliente en la coordinación de las distintasadaptaciones del SI.

Deficiencias decalidad

ê Controlar los requisitos de las propiedades de calidad.

ê Utilizar un experto en el sistema de información que poseaconocimientos técnicos de alto nivel.

ê Elaborar prototipos para la simulación de las propiedades decalidad.

Necesidad deprofundosconocimientos deinformática

ê Estudiar una posible división de la adaptación del SI,aplazando los elementos punteros.

ê Estudiar el uso de soluciones normalizadas.

Desarrollo de unsistema incorrecto

ê Verificar lo antes posible que la funcionalidad del futuro SIserá igual de buena que la funcionalidad del SI actual, esdecir, los requisitos de la secuencia, finalidades y entregablesde puntos de decisión.

ê Elaborar declaraciones de requisitos, prototipos yespecificaciones del futuro SI.

ê Recopilar experiencias procedentes de SI similares.

ê Elaborar prototipos para la simulación de las propiedades delSI.

ê Utilizar la ingeniería inversa, es decir, añadir al plan deadaptación puntos de decisión asociados al aumento del gradode comprensión del SI actual, mediante descripciones delmismo.

Adaptación del SI noaceptada por losagentes

ê Crear o mantener una actitud positiva de los agentes.

ê Elaborar prototipos para la simulación de las propiedades delas prácticas de trabajo.

Repercusiones en elnegocio del fallo delproyecto

ê Conceder prioridad a los riesgos críticos y atender porseparado los riesgos más urgentes.

ê Dividir el sistema en partes más pequeñas.



Figura 4.11: Contramedidas para reducir riesgos


Contramedidas para cambiar los factores individuales

La actitud de losagentes del SI esnegativa

ê Involucrar a los agentes, por ejemplo, aumentando suinformación, participación e influencia en la adaptación del SI.

ê Motivar a los agentes, por ejemplo, haciendo que los beneficiossean comprensibles y visibles.

La habilidad de losagentes del SI esbaja

ê Formar a los agentes, es decir, llevar a cabo un programa deformación de las personas que son agentes en la adaptación delSI.

La comprensión delSI actual es baja

ê Utilizar la ingeniería inversa, es decir, añadir al plan deadaptación puntos de decisión asociados al aumento del nivelde comprensión del sistema de información actual, mediantedescripciones del mismo.

La disponibilidad oclaridad de losrequisitos de laadaptación del SI esbaja

ê Realizar un análisis de requisitos riguroso, es decir, añadir alplan de adaptación puntos de decisión acerca de declaracionesde requisitos del futuro SI, e implementar un sistema de controlde requisitos.

La calidad de lasespecificacionesactuales es baja

ê Rehacer las especificaciones, es decir, añadir al plan deadaptación puntos de decisión acerca de la aprobación de lasespecificaciones del futuro SI.

ê Revisar las especificaciones actuales con los agentes del SI.

La capacidad delequipo del proyectoes baja

ê Formar al equipo del proyecto, por ejemplo, llevar a cabo unprograma de formación para las personas que son agentes en laadaptación del SI.

ê Asignar personas más capacitadas al equipo del proyecto.

Figura 4.12: Contramedidas para cambiar factores situacionales individuales.




Contramedidas para gestionar la complejidad

El tamaño deldominio objetivo esgrande

ê Dividir la adaptación del SI en varias adaptaciones condominios objetivos más pequeños.

La complejidad dela información delSI es alta

ê Utilizar la visión de la información del negocio en lasdescripciones del SI a fin de sustentar decisiones inicialesacerca de la información del negocio.

ê Utilizar expertos en el SI que posean una elevada cualificaciónen este dominio de aplicación.

La complejidad delos procesos denegocio del SI esalta

ê Utilizar la visión de los procesos del negocio en lasdescripciones del SI a fin de sustentar decisiones inicialesacerca de los procesos de negocio.

ê Utilizar expertos en el SI que posean una elevada cualificaciónen este dominio de aplicación.

Complejidad de losprocesos denegocios debido aque existendemasiadasinterfaces externascon otros SI

ê Clarificar las interfaces al principio del proceso de descripcióny describirlas en las descripciones del SI.

ê Comprobar a fondo las interfaces externas.ê Planificar los cambios necesarios en cada SI externo que

interviene en la adaptación del SI.ê Planificar la construcción, ensayo e instalación de las interfaces

en coordinación con los responsables de los SI externos queintervienen en la adaptación del SI.

La complejidad delas propiedades decalidad es alta

ê Aprobar descripciones de propiedades de calidad mediante lospuntos de decisión iniciales de la adaptación del SI.

ê Adoptar decisiones iniciales acerca del intercambio entre laspropiedades funcionales y las propiedades de calidad.

ê Producir prototipos como parte de las descripciones.

El tamaño delproyecto es grande

Es decir, el esfuerzo de desarrollo que se precisa es considerable paralas organizaciones que intervienen.ê Dividir la adaptación del SI en varias adaptaciones cubiertas

mediante subcontratos.

La complejidad dela migración es alta

Es decir, el esfuerzo y complejidad de la migración del SI en suestado 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 ungran número deinterfaces con otrasadaptaciones del SI

ê Planificar la adaptación del SI en coordinación con losresponsables de las demás adaptaciones del SI.

ê Clarificar las interfaces (interfaces de sistema externo,interfaces de migración, etc.) al inicio del proceso deadaptación del SI y describirlas en los planes y descripcionesdel SI.

ê Informar de estas interfaces al aprobarse las transacciones de lasituación y del plan.

La complejidad dela tecnología es alta

ê Utilizar una tecnología segura, bien conocida y madura.ê Utilizar expertos en el SI que posean un alto nivel de

cualificación técnica.

Figura 4.13: Contramedidas para gestionar la complejidad.



4.3.2 Análisis de las opciones estratégicas

Eurométodo proporciona un conjunto de opciones para los enfoques del desarrolloy de control del proyecto. Estas opciones pueden adaptarse al contexto de laorganización y mejorarse en base a la experiencia, para obtener opcionesestratégicas específicas para la organización. De momento, Eurométodo noproporciona orientación para realizar estas mejoras. En este apartado se explicanlas 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 ladescripción, un enfoque de la construcción y un enfoque de la instalación. La figura4.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 elresultado de ese proceso: el proceso de análisis y diseño del sistemade información. La descripción incluye la determinación de losrequisitos. El resultado de un proceso de descripción es unadescripción que puede definir la organización, las característicasesenciales 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 alproducir uno o más elementos descriptivos, y el enfoque social que se precisa entrelos agentes del proyecto y los agentes del SI.

El enfoque cognitivo que se utiliza para elaborar las descripciones del sistema esla manera en que se procesa la información para tomar las decisiones de diseño delproyecto. Existen dos opciones:

• Enfoque analítico.Cuando la información se procesa de forma analítica, la informacióndisponible se simplifica mediante la abstracción, al objeto de alcanzar unacomprensión más profunda e invariable. Se utiliza el enfoque analítico paragestionar la complejidad de la información. En el enfoque analítico, elsistema de información se describe principalmente utilizando cierto grado deformalismo.

• Enfoque experimental.Cuando se utiliza el enfoque experimental, los agentes del proyecto aprendende experimentos que generan nuevos conocimientos. La finalidad es reducirla incertidumbre generando más información. Los experimentos pueden estarbasados, por ejemplo, en prototipos, maquetas, pruebas de referencia de losservicios u otro tipo de técnicas de visualización de escenarios.

Puede que sea preciso combinar ambos tipos de enfoque cognitivo. Un enfoqueanalítico para reducir la complejidad puede introducir nuevas fuentes de

Definir opcionesestratégicasespecíficas parala organización

Opciones delenfoquecognitivo



incertidumbre que requieran contramedidas experimentales, y a la inversa, unenfoque experimental para reducir la incertidumbre puede introducir nuevasfuentes de complejidad que requieran contramedidas analíticas. Por tanto, sólo elenfoque cognitivo primario formará parte de la estrategia del proyecto.

El enfoque social es la manera en que los agentes del proyecto colaboran con losagentes del sistema de información en la tarea de descripción. Existen dosopciones:

• Conducido por experto.En una cooperación conducida por expertos, los agentes del proyecto (losexpertos) producen descripciones a la luz de su propia pericia, entrevistas yobservaciones de los agentes del sistema de información. Las descripcionespueden facilitarse seguidamente a los agentes del SI para que las comenten oaprueben.

• Participativo.En un enfoque participativo, los agentes del proyecto elaboran lasdescripciones en estrecha colaboración con algunos o con todos los agentesdel SI, por ejemplo en seminarios con presentaciones, discusiones ydecisiones de diseño. El Diseño de Aplicación Conjunto (DAC) es unejemplo de una técnica que puede utilizarse en un enfoque participativo. Estetipo de enfoque permite la adquisición de conocimientos, el refinamiento delos requisitos y la simplificación de los cambios organizativos.

La opción por un enfoque de la descripción fijará requisitos de los entregables queintercambian el cliente y el proveedor, y de los métodos y técnicas utilizados en laadaptación del sistema de información. El cliente y el proveedor deberánseleccionar una de las cuatro posibles combinaciones de opciones de enfoquecognitivo 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.

Opciones delenfoque social

Opciones delenfoque dedescripción



Modalidad de desarrollo Opciones estratégicas

Enfoque de la descripción– enfoque cognitivo

1. Analítico:• uso de abstracciones y especificaciones

2. Experimental:• uso de experimentos y prototipos.

Enfoque de la descripción– enfoque social

1. Conducido por expertos:• 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– cobertura del sistema

1. Instalación de una vez:• 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– cobertura geográfica

1. Instalación global• 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 laorganización) es el proceso que consiste en traducir un elementodescriptivo en elementos operativos. Incluye el ensayo de loselementos operativos [EM-DC].

Un enfoque de la construcción define la manera en que se va a construir y probar elsistema de información. La selección de un enfoque de la construcción consiste enadoptar decisiones acerca de los pasos a partir de los cuales se construye y seprueba el sistema de información, es decir, decisiones acerca de la secuencia y tipode 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 tresenfoques de la construcción siguientes:

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

2. Construcción incremental:El SI se construye (y se prueba) en partes sucesivas. Cada parte contiene unsubconjunto de funcionalidades del SI. Los requisitos del SI instalado sedefinen completamente antes de la primera construcción y no pueden sermodificados 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 laspruebas. Cada versión puede contener un subconjunto o la totalidad de lasfuncionalidades.

Enfoque de la instalación

Definición La instalación de un sistema de información es el proceso queconsiste en hacer que el sistema de información sea operativo en eldominio objetivo [EM-DC].

La determinación de un enfoque de la instalación consiste en tomar decisionesacerca de las versiones del sistema de información que deberían instalarse en eldominio objetivo, y la secuencia de estas instalaciones.

El cliente y el proveedor deberán seleccionar una de las siguientestres opciones de cobertura del sistema:

1. Instalación de una vez:

La totalidad del SI se instala (y se utiliza) en una sola versión.

Opciones delenfoque de laconstrucción

Opciones delenfoque de lainstalación parala cobertura delsistema



2. Instalación incremental:

El SI se instala (y se utiliza) en partes sucesivas. Cada parte contiene unsubconjunto de funcionalidades del SI. Los requisitos del SI instalado sedefinen completamente antes de la primera instalación y no pueden sermodificados posteriormente.

3. Instalación evolutiva:

El SI se instala (y se utiliza) en versiones sucesivas. Entre dos versiones, lasdescripciones del SI pueden cambiar en función de la experiencia adquiridacon el uso del SI. Cada versión puede contener un subconjunto o la totalidadde las funcionalidades.

Conviene señalar que normalmente los requisitos de una versión deben fijarsedurante un período de tiempo entre la construcción y la instalación, pero despuésde la instalación pueden modificarse e influyen en la descripción de la siguienteversión.

Paralelamente a estas tres modalidades de cobertura del sistema, existe la coberturageográfica de cada tipo de instalación. El cliente y el proveedor deberánseleccionar una de las siguientes dos opciones de cobertura geográfica:

1. Instalación global.Una nueva versión del sistema de información se instala de una sola vez entodas 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 coberturageográfica limitada, por ejemplo, tan sólo una sección, un departamento o unaoficina. Este paso puede utilizarse como instalación piloto con la finalidad deperfeccionar la versión del sistema de información y mejorar el proceso deinstalación antes de que los cambios influyan en la totalidad del dominioobjetivo. 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 lostres 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 alseguimiento de la progresión del proyecto, es decir, su orientación,calidad y utilización de recursos, en relación con los planes delproyecto [EM-DC].

Se tienen en cuenta tres aspectos del control del proyecto: frecuencia, formalidad yresponsabilidad del cliente:

• Frecuencia.

Opciones decoberturageográfica en lamodalidad de lainstalación

Aspectos delcontrol delproyecto



La frecuencia de los puntos de decisión cliente-proveedor que tienen lugar enel proceso de control.

• Formalidad.El grado de formalidad de la organización, procedimientos y disciplinas queutiliza el proceso de control.

Ejemplo Un alto grado de formalidad del control del proyecto puedeabarcar, por ejemplo:

• Aprobaciones periódicas de la situación y del plan.

• Requisitos formalmente definidos acerca del contenido delos 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óny la calidad del proyecto.

• Uso de una técnica de inspección definida para controlar lacalidad del código.

• Procedimientos de control de configuración formalmentedefinidos.

• Responsabilidad del cliente .La definición de la responsabilidad del cliente sobe los procesos relativos alcontrol del proyecto. Por regla general, se asume que el proveedor esresponsable de todos los procesos, a menos que la responsabilidad del clientese defina de forma explícita en el contrato.



Ejemplo La responsabilidad del cliente puede definirse, porejemplo, de las siguientes maneras:

• El cliente es responsable del control de laconfiguración de los requisitos.

• El cliente es responsable del control de calidad de lasdescripciones con respecto a los requisitos ynecesidades del negocio.

• El cliente es responsable de generar de casosexperimentales que contemplen situaciones críticasdesde la perspectiva de los procesos de negocio.

• El cliente es responsable de la preparación de laorganización para la instalación del nuevo sistema deinformación operativo.

• El cliente es responsable de la obtención de cualquieracuerdo que tenga lugar en la organización enrelación con los requisitos del sistema deinformación.

En este contexto, la modalidad de control del proyecto es el enfoque utilizado parael control de la frecuencia y formalidad de las medidas de control del proyecto, y laresponsabilidad de su realización.

El control del proyecto puede dividirse en tres procesos: desarrollo del sistema deinformación, garantía de calidad y gestión de la configuración, todos ellos definidospor Eurométodo. Por consiguiente, existen tres procesos distintos de control delproyecto:

1. Control del desarrollo.Proceso de gestión de proyectos necesario para controlar la realización de lastareas del proyecto en el proceso de desarrollo del SI.

2. Control de calidad.Técnicas y actividades utilizadas para satisfacer los requisitos de calidad. Elcontrol de calidad incluye técnicas y actividades encaminadas a la supervisiónde un proceso y a la eliminación de las causas de un rendimiento insatisfactorioen 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 laevaluación y coordinación, aprobación o rechazo e implementación decambios en los elementos de configuración después del establecimiento formalde su identificación.

Para cada uno de los procesos de control del proyecto arriba definidos, el cliente yel proveedor deberán seleccionar una de las opciones relativas a los tres aspectosque considera Eurométodo. La figura 4.12 ofrece una visión general al respecto.

Modalidad decontrol delproyecto

Opciones delenfoque delcontrol delproyecto



Procesos de control del proyecto Aspectos de control delproyecto

Opciones estratégicas

• Control del desarrollo

• Control de la calidad

• Control de la configuración

Frecuencia Intervalos o fechas con losextremos de frecuentemente yraramente

Formalidad Grados de formalidad con losextremos de formal e informal

Responsabilidad delcliente

Responsabilidades del clientesobre 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

El principal objetivo de la mayoría de adaptaciones del SI consiste en introducircambios en el SI operativo, mediante la instalación de elementos operativos nuevoso modificados que pueden incluir nuevo personal y nuevas estructurasorganizativas. La instalación de la nueva versión del sistema de información es loque permite a los agentes del SI utilizar los resultados de una adaptación del SI. Lainstalación es ‘el momento de la verdad’ de la adaptación del SI. Por lo tanto, ladefinición de un enfoque de la instalación adecuado tiene una importancia decisivapara conseguir un resultado favorable.

Al definir el enfoque de la instalación es preciso proceder con sumo cuidado yatención.

El enfoque de la instalación debe estar influido por los factores situacionales. Noobstante, los conocimientos relativos a la situación pueden resultar insuficientespara seleccionar un enfoque de la instalación. En este caso, la adaptación delsistema de información deberá incluir actividades encaminadas a obtener losconocimientos necesarios para adoptar decisiones acerca de un enfoque de lainstalación adecuado, es decir, los entregables de los puntos de decisión inicialesrelativos a la descripción del sistema de información deberán sustentar la definiciónde un enfoque de la instalación adecuado, o lo que es lo mismo, la selección delenfoque de la instalación puede establecer varios imperativos y requisitos sobreotros enfoques. De forma similar, el enfoque de la construcción puede establecerimperativos sobre el enfoque de la descripción. Así pues, se recomiendaseleccionar el enfoque del desarrollo en el orden siguiente: enfoque de lainstalación, enfoque de la construcción y, finalmente, enfoque de la descripción, ycomprobar que existe coherencia entre las opciones seleccionadas.

Puede utilizarse el siguiente procedimiento para seleccionar las opcionesestratégicas relativas al desarrollo y al control del proyecto:

1. Seleccionar un primer enfoque de desarrollo ‘en borrador’, basado en unavaloración general de los factores situacionales y los riesgos críticos, y en lasheurísticas que proporciona Eurométodo.

La instalación es‘el momento dela verdad’

Interdepen-dencias entreenfoques deldesarrollo

Procedimiento



2. Revisar y justificar el enfoque de desarrollo utilizando las heurísticas detalladasque proporciona Eurométodo y la experiencia en el seno de la organización.

3. Seleccionar un enfoque de control del proyecto utilizando las heurísticasdetalladas que proporciona Eurométodo y la experiencia en el seno de laorganización.

4. Comprobar que se mantiene la coherencia entre las opciones estratégicasseleccionadas y corregir la selección efectuada.

4.3.3.1 Paso 1: Seleccionar un primer enfoque de desarrollo ‘enborrador’

• 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 deacuerdo 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.



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 delos enfoques de la instalación y la construcció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 factoressituacionales contrarrestan las incertidumbres (es decir, elenfoque experimental está menos justificado), y resultan útiles alutilizar 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óncon:− la alta especificidad del sistema de información− la descripción del futuro sistema

− la baja estabilidad del entorno.



Figura 4.17: Heurísticas generales acerca de la idoneidad de los enfoques de ladescripció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 dela situación en forma de factores situacionales y la complejidad eincertidumbre generales.

• Resultado:Enfoques de la descripción, construcción e instalación apropiados para estaadaptación del SI, y su justificación.

Estos enfoques deberán seleccionarse, revisarse y justificarse utilizando lasheurísticas detalladas que proporciona Eurométodo y la experiencia acumulada enel seno de la organización.

Es posible que, para que sean realistas, las opciones estratégicas requieran laexistencia de ciertas condiciones en la situación. Por ejemplo, para obtener unresultado favorable, el enfoque experimental y el enfoque evolutivo exigenconocimientos de gestión de proyectos; y el enfoque participativo requiere que elequipo de proyecto tenga capacidad de comunicación. Estas condiciones tambiéndeberá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 lasinstalaciones.El enfoque que se selecciona por defecto es el de una vez, con el cual lagestión del proyecto es más sencilla, es decir, se reduce el riesgo general depérdida de control del proyecto. Los enfoques incremental o evolutivo deberánseleccionarse en función de los factores situacionales particulares, véase lasheurísticas de la figura 4.18.

2. Seleccionar la opción estratégica para la cobertura geográfica de lasinstalaciones.

Enfoque social

Enfoque cognitivo

Conducido por expertos Participativo

Analítico Cuando la situación escompleja, excepto cuando lacomplejidad de lainformación o de los procesosde negocio es alta.

Cuando la complejidad de lainformación o de los procesos denegocio es alta.

Experimental Cuando la situación esincierta y el enfoqueparticipativo no es adecuado.

Cuando la situación es incierta yla habilidad de los agentes delsistema de información essuficientemente alta y la idoneidaddel calendario es normal.

Para que unaopciónestratégica searealista, espreciso que sepueda ejecutar



El enfoque que se selecciona por defecto es la instalación global, es decir, seinstala una versión del sistema de información en todas las ubicaciones y deuna vez. Puede utilizarse el enfoque de la instalación local, es decir, lainstalación gradual cubriendo cada vez más ubicaciones, para gestionar unasituació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 lagestión del proyecto es más sencilla, es decir, se reduce el riesgo general depérdida de control del proyecto. Los enfoques incremental o evolutivo deberánseleccionarse en función de los factores situacionales particulares; véase lasheurísticas de la figura 4.18.

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 lasopciones de enfoque de la descripción. Por regla general, existen casos en losque el enfoque seleccionado se combina con alguno de los demás. Porconsiguiente, los enfoques primarios cognitivo y social deberán definirse comoparte de la estrategia de adaptación; véase las heurísticas de la figura 4.18.



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)

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 comoagentes 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



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

• Insumo:Una valoración de la situación en forma de factores situacionales y lacomplejidad e incertidumbre generales

• Resultado:Un enfoque de control del proyecto que sirve para esta adaptación delsistema de información, y su justificación

• Orientación:Confrontar los factores situacionales con las heurísticas de la figura 4.19 yseleccionar el enfoque más apropiado.

Generalmente se prefiere siempre un alto grado de formalidad en el control decalidad, aunque los procedimientos que se aplican pueden ser más o menoscomplicados en función del tamaño del proyecto.



Figura 4.19: Heurísticas acerca de la idoneidad de las opciones de control delproyecto.

(X: la opción aborda este factor)

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



4.3.3.4 Paso 4: Comprobar que se mantiene la coherencia entre lasopciones estratégicas elegidas y corregir la selección efectuada

1. Utilizando las heurísticas de la figura 4.20, comprobar que la combinaciónseleccionada de opciones estratégicas es viable.

2. Utilizando las mismas heurísticas, corregir la selección efectuada y, utilizandolas heurísticas del paso 2, controlar los cambios.

Figura 4.20: Dependencias entre las opciones estratégicas.(X: la combinación es posible; -: la combinación no es posible)

Enfoque de laconstrucción

Enfoque de lainstalación

De unavez

Incre-mental

Evolutivo

Observaciones

De una vez X X X Tras la construcción puede realizarse unaprueba final de recepción de la totalidad delsistema de información y posteriormente unainstalación de una vez

Incremental X Tras la construcción de una vez puederealizarse una prueba final de recepción de latotalidad del sistema de información yposteriormente una instalación sucesiva de laspartes, o bien:Tras la construcción de una vez de cada unade las partes puede realizarse una prueba derecepción y la instalación de esa parte

X Tras la construcción incremental de cada unade las partes puede realizarse una prueba derecepción y la instalación de esa parte

X Tras la construcción evolutiva de cada una delas partes puede realizarse una prueba derecepción y la instalación de esa parte

Evolutivo - - X Un enfoque de instalación evolutivo implicaun enfoque de construcción evolutivo, ya quelos requisitos de la construcción puedencambiar en función de la experienciaadquirida con el uso del SI

• Una cooperación conducida por expertos puede ser más sencilla de planificar y controlar queun enfoque participativo.

• Un enfoque participativo puede ser más sencillo de controlar cuando se utiliza un enfoquede instalación evolutivo.



4.3.4 Analizar las repercusiones de la estrategia

Tras seleccionar las contramedidas y las opciones estratégicas, convienecomprobar si se han contemplado todos los riesgos críticos. Se recomienda crearuna matriz que relacione los riesgos críticos identificados y las opciones ycontramedidas seleccionadas – véase el boceto de la figura 4.21 y la plantilla delanexo D.20. Las opciones estratégicas seleccionadas pueden incrementar algunosriesgos, los cuales deberán ser analizados (probabilidad y repercusiones) eincluidos en la matriz, si son críticos. La figura 4.22 contiene ejemplos de riesgosque 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 deriesgos.

Figura 4.21: Diseño general de una matriz que relaciona las opciones seleccionadascon 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 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.22: Riesgos que pueden verse aumentados por las opciones estratégicas.(+: la opción estratégica 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 otrossistemas

+ +

Requisitos variables + + + +

Costes impredecibles para la organización + + + +

Costes impredecibles para el proyecto + + + + + + +

Falta de participación de los agentes deldominio objetivo

+ + + + +

Deficiencias de las tareas realizadasexternamente

+ + +

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 deinformática

+ +

Sistema de información incorrecto oinviable

+ +

Adaptación del sistema de información noaceptada por los agentes

+ + + + +

Repercusiones en el negocio del fallo delproyecto

+

Riesgos generales:

Pérdida de control del proyecto + + + + + + +

El sistema de información no funciona + + + + + +



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ónes un momento en que el cliente, posiblemente junto con elproveedor, toma decisiones sobre la adaptación del SI. Un punto dedecisión se caracteriza por las decisiones que se toman, las funcionesinvolucradas en estas decisiones y los entregables que seintercambian. Estos entregables sirven de condiciones previas o debase 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 puntosde decisión apropiados a nivel de gestión contractual en una adaptación del sistemade 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.

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 deadaptación, es posible definir una secuencia de puntos de decisión ajustada a lasituació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 dedecisión ajustados.

Las técnicas deberán utilizarse en el orden siguiente:

1. Derivar la secuencia básica de puntos de decisión.Esto puede basarse en opciones estratégicas que utilicen la terminología deEurométodo, véase apartado 4.3.2-4, o en opciones estratégicas de otrosmétodos.

Mes a partir delinicio del proyecto

Punto de decisión

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<Punto de decisión 1> ∆

<Punto de decisión 2> ∆

etc.

Secuencia detécnicas paradefinir puntos dedecisiónajustados



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 losentregables que deban entregarse a partir del anterior punto de decisión. Sedistinguen 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.

En una adaptación del SI pueden adoptarse varios tipos de decisiones. En un puntode decisión pueden tomarse decisiones de distintos tipos. Los tres tipos de decisiónprincipales son:

• Decisiones sobre cuestiones inherentes al dominio objetivo de la adaptacióndel SIes decir, sobre el sistema de información que se pretende adaptar.

• Decisiones sobre cuestiones inherentes al dominio del proyectoes decir, sobre la organización y los planes para llevar a cabo el trabajo.

• Decisiones sobre cuestiones inherentes al dominio contractuales decir, sobre cuestiones contractuales.

La finalidad de un punto de decisión deberá estar relacionada con estos tres tiposde 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 yentregables de gestión de proyecto.

3.2. Bases de decisión: propuesta de punto de decisión, informe desituació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.

Decisionesacerca deldominioobjetivo,dominio delproyecto ydominiocontractual



Las decisiones sobre el dominio objetivo pueden clasificarse en tres subtipos:

• decisiones de inversión

• decisiones de diseño

• 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ónindicando su tipo, ya que así se obtiene cierta orientación acerca de qué entregablesse 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.

Heurísticasgenerales acercade los tipos dedecisión deldominio objetivo



Figura 4.25: Heurísticas generales acerca de las decisiones sobre el dominioobjetivo.

Tipo de decisión Finalidad Entregables

Decisión de inversión Decidir si se invierte o no en unsistema de información nuevo (omodificado).

La decisión de inversión inicial serevisa o pormenoriza en base a lainformación adicional que seobtiene durante la adaptación delSI. Otro caso es cuando laadaptación del SI está encaminadaa proporcionar la informaciónnecesaria para tomar una decisiónde inversión (planificaciónestratégica, análisis de cambios,etc.).

Elementos descriptivos quefundamentan la valoración de:beneficios, costes y riesgos.

Además de estas propiedades de lainversión, las descripcionesdeberán abarcar las propiedadesfuncionales y de calidad queinfluyan en estos elementos.

Decisión de diseño Decidir si un sistema deinformación nuevo (o modificado)es aceptable tal y como se hadescrito.

Elementos descriptivos cuyascaracterísticas dependen delenfoque, como se explica en elapartado 4.4.1. Potencialmentepueden precisarse todas laspropiedades funcionales y decalidad. Ello dependerá del área deinterés.

Informes de garantía de calidadque muestran los resultados delcontrol de calidad aplicados a loselementos descriptivos.

Decisión de aceptacióndel sistema

Existen dos tipos de decisiones deaceptación del sistema:

• Decidir la aceptación de unsistema de informaciónconstruido y probado.

• Decidir la aceptación de unsistema de informacióninstalado y operativo.

Elementos operativos que seprueban o se instalan.

Una descripción definitiva yactualizada del sistema deinformación, si no se ha elaboradoy comprobado anteriormente.

Informes de garantía de calidadque muestran los resultados de laspruebas del sistema construido, ovalidaciones del sistema instalado.

Informes de gestión de laconfiguración.



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 elenfoque 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 puntosde decisión en función de las opciones estratégicas seleccionadas. Se distinguendos escenarios:

1. Derivar una secuencia básica en base a las opciones estratégicas deEurométodo.Los puntos de decisión se definen utilizando las opciones estratégicas queproporciona Eurométodo para la descripción, construcción, instalación ycontrol 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 parael desarrollo del SI o por el método de gestión del proyecto aplicado en elproyecto.

Posteriormente, en ambos escenarios, deberán tenerse en cuenta las contramedidasdefinidas 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 opcionesestratégicas de Eurométodo

Para cada una de las opciones estratégicas de desarrollo definidas en el apartado4.3.2, Eurométodo proporciona un ejemplo de una secuencia de puntos dedecisión, como el de la figura 4.26. Estos ejemplos pueden utilizarse para definiruna secuencia básica de puntos de decisión. El anexo C contiene todos losejemplos. Los ejemplos relativos a modalidades de la descripción se basan en lasheurísticas de la figura 4.27.

Puede utilizarse el siguiente procedimiento, el cual supone que el sistema deinformación en cuestión se divide en subsistemas, y que pueden existir diferentesopciones estratégicas en relación con los diferentes subsistemas. En caso de que noexista 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 siguientemanera:

1.1. Combinar los ejemplos de secuencias asociados a los enfoques dedesarrollo en una única secuencia.

1.2. Mejorar los puntos de decisión con las finalidades del dominio delproyecto, de acuerdo con el enfoque de control del proyecto que se haseleccionado. Si es preciso, añadir puntos de decisión. La figura 4.28describe heurísticas para la influencia de los enfoques de control delproyecto en la planificación de los puntos de decisión.

2. Combinar las secuencias para los subsistemas en una única secuencia para todala adaptación del SI.

Dos escenarios

El anexo Cincluye ejemplosde secuencias depuntos dedecisión

Procedimiento



En las figuras 4.29–31 figuran sendos ejemplos de combinaciones de puntos dedecisión para adaptaciones del SI. Los puntos de decisión se definen utilizando losejemplos de secuencias de puntos de decisión relativos a las opciones estratégicasseleccionadas:

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



Figura 4.26: Ejemplo de secuencia de puntos de decisión.

Descripción analítica y conducida por expertos

Nº Finalidad Entregables

1.Decisiones de diseño sobre:

marco lógico global del

negocio

Perfil del elemento descriptivo:• información del negocio/propiedades del proceso• propiedades de calidad, por ejemplo, seguridad• 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


diseño global de las prácticas

de trabajo

Perfil del elemento descriptivo:• propiedades de las prácticas de trabajo• propiedades de calidad, por ejemplo, eficiencia, facilidad deuso• propiedades de la inversión, por ejemplo, costes, beneficios• alcance íntegro, abierto a soluciones técnicas alternativas• texto con ilustraciones gráficas• futuro sistema de información, sin simulación• bajo grado de desglose y especialización


diseño global del sistema

informático

Perfil del elemento descriptivo:• propiedades del sistema informático• propiedades de calidad, por ejemplo, fiabilidad, portabilidad• propiedades de la inversión, por ejemplo, costes, riesgos• alcance íntegro, abierto a soluciones técnicas alternativas• futuro SI, sin simulación• bajo grado de desglose y especialización


diseño detallado de las

prácticas de trabajo

Perfil del elemento descriptivo:• propiedades de las prácticas de trabajo• propiedades de calidad, por ejemplo, eficiencia, facilidad deuso• propiedades de la inversión, por ejemplo, costes, beneficios• alcance íntegro, soluciones técnicas alternativas• texto con ilustraciones gráficas• futuro SI, sin simulación• alto grado de desglose y especialización


diseño detallado del sistema

informático

Perfil del elemento descriptivo:• propiedades del sistema informático• propiedades de calidad, por ejemplo, eficiencia, facilidad deuso• propiedades de la inversión, por ejemplo, costes, beneficios• alcance íntegro, soluciones técnicas alternativas• futuro SI, sin simulación• alto grado de desglose y especialización



Figura 4.27: Heurísticas acerca de la definición los puntos de decisiónen función del enfoque de la descripción.

Enfoque de ladescripción

Heurísticas acerca de puntos de decisión

Enfoquecognitivo

Enfoquesocial

Marco delnegociofrente asistematécnico

Nivelabstractofrente anivelconcreto

Solucióntotalfrente asoluciónparcial

Número depuntos dedecisión

Analítico Conducidopor expertos

Del marcodel negocioal sistematécnico

De abstractoa concreto

De totala parcial

Conjuntomínimo

Participativo Del marcodel negocioal sistematécnico

Abstracto yconcreto enparalelo

Principal-mente detotal aparcial

Conjuntosuficiente

Experimental Conducidopor expertos

Marco delnegocio ysistematécnico enparalelo

De concretoa abstracto

De totala parcial

Conjuntomínimo

Participativo Marco delnegocio ysistematécnico enparalelo

De concretoa abstracto

Total yparcial enparalelo

Conjuntosuficiente

Heurísticas generales acerca de los entregables que sustentan las decisiones:• Las decisiones sobre el marco del negocio se sustentan en las visiones del

sistema de información.• 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 deinformación y visión de los procesos del negocio) y en las visiones del sistemainformático independientes de la unidad de proceso (visión de los datos delsistema 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 lasprá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 delos entregables y en un nivel de detalle global, es decir, ni un alto grado dedesglose, ni un alto grado de especialización.

• Las decisiones sobre una solución parcial se sustentan en un alcance parcial delos entregables y en un alto nivel de detalle detallado, es decir, un alto gradode desglose y un alto grado de especialización.



Figura 4.28: Ejemplos de la influencia de los enfoques de control del proyecto en laplanificación de los puntos de decisión.

Enfoque de control delproyecto

Influencia en la planificación de los puntos de decisión

Control frecuente delproyecto

ê Control del proyecto en cada punto de decisión: definir la finalidad,funciones y entregables.

ê Quizá añadir puntos de decisión con la única finalidad de control delproyecto: los entregables dependerán de la frecuencia de los temas deinterés, por ejemplo, costes, planes, aseguramiento de la calidad ygestión de la configuración.

Control formal delproyecto

ê Incluir el control del proyecto en puntos de decisión periódicos conrequisitos formalmente definidos acerca de planes e informes.

ê Definir una métrica de la progresión y la calidad del proyecto, ysolicitar una métrica para los planes e informes de los puntos dedecisión.

ê Definir procedimientos formales de control de calidad, por ejemplo,técnicas de inspección específicas, y solicitar estados de calidad deelementos descriptivos de acuerdo con estos procedimientos.

ê Definir procedimientos formales de control de la configuración, ysolicitar planes e informes de configuración en determinados puntos dedecisión.

Responsabilidad delcliente

ê Descripción de los requisitos:Planificar lo antes posible las decisiones sobre los requisitos, conentregables del cliente al proveedor.

ê Control de la configuración de los requisitos:Planificar los planes e informes de control de la configuración delcliente 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 lospuntos de decisión.

ê Coordinación de las interfaces con otras adaptaciones del sistema deinformación:Planificar las decisiones sobre la coordinación de las interfaces conotras adaptaciones del sistema de información con planes e informesdel cliente.

ê Adquisición de conocimientos y toma de decisiones:Planificar con las decisiones de inversión y de diseño necesarias.



Figura 4.29: Ejemplo de una secuencia de puntos de decisióndesde 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.

Enfoque de desarrollo Adaptación ‘en cascada’

Descripción

analítica y

conducida por expertos

1. Decidir sobre: • marco lógico del negocio en términos generales• progresión del proyecto y plan de descripción

2. Decidir sobre: • diseño general de las prácticas de trabajo• progresión del proyecto y plan de descripción

3. Decidir sobre: • diseño general del sistema informático• progresión del proyecto y plan de descripción• revisión del plan de adaptación

4. Decidir sobre: • diseño detallado de las prácticas de trabajo• progresión del proyecto y plan de descripción

5. Decidir sobre: • diseño detallado del sistema informático

• progresión del proyecto y plan de construcción

• revisión del plan de adaptació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

Instalación de una vez7. Decidir sobre: • aceptación del sistema de información instalado

8. Decidir sobre: • finalización del contrato



Figura 4.30: Ejemplo de una secuencia de puntos de decisióndesde la descripción de un problema a un sistema de información probado.Control frecuente y formal del proyecto: cada punto de decisión contiene

decisiones acerca de la progresión y el sentido de la adaptación del SI.

Enfoque de desarrollo Adaptación ‘modular’

Descripción

experimental y

conducida por expertos

1. Decidir sobre: • prototipo general de las prácticas de trabajo• progresión del proyecto y plan de descripción

2. Decidir sobre: • diseño general de las prácticas de trabajo• progresión del proyecto y plan de descripción

3. Decidir sobre: • prototipo general del sistema informático• progresión del proyecto y plan de descripción• revisión del plan de adaptación

4. Decidir sobre: • diseño detallado de las prácticas de trabajo• progresión del proyecto y plan de descripción

5. Decidir sobre: • diseño detallado del sistema informático

• progresión del proyecto y plan de construcción

• revisión del plan de adaptación

Construcción

incremental (3 partes)

6.1 Decidir sobre: • aceptación de la parte 1 del sistema• progresión del proyecto y plan de construcción

6.2 Decidir sobre: • aceptación de la parte 2 del sistema• progresión del proyecto y plan de construcción

6.3 Decidir sobre: • aceptación de la parte 3 del sistema• progresión del proyecto y plan de ensayo delsistema

7. Decidir sobre: • aceptación del SI construido y probado• progresión del proyecto

8. Decidir sobre: • finalización del contrato



Figura 4.31: Ejemplo de una secuencia de puntos de decisióndesde un diseño global hasta un sistema de información instalado.

Control frecuente y formal del proyecto: cada punto de decisión contienedecisiones acerca de la progresión y sentido de la adaptación del SI.

Enfoque deldesarrollo

Adaptación ‘de versión’

Descripción(evolutiva)experimental yparticipativa(v.1)

1.1. Decidir sobre v.1: • diseño detallado del SI• prototipo y diseño detallados del CS• progresión del proyecto y plan de construcción

Construcción(evolutiva) (v1)

1.2. Decidir sobre: • aceptación del SI construido y probado, versión 1• progresión del proyecto y plan de instalación, v.1

Instalación(evolutiva) (v.1)

1.3. Decidir sobre: • aceptación del SI instalado, versión 1• progresión del proyecto y plan de descripción, v.2• revisión del plan de adaptación.

Descripción(evolutiva)experimental yparticipativa(v.2)

2.1. Decidir sobre v.2: • diseño detallado del sistema de información• prototipo y diseño detallados del sistema

informático• progresión del proyecto y plan de construcción.

Construcción(evolutiva) (v.2)

2.2. Decidir sobre v.2: • aceptación del SI construido y probado• progresión del proyecto y plan de instalación.

Instalación(evolutiva) (v.2)

2.3. Decidir sobre: • aceptación del SI instalado, versión 2• progresión del proyecto y plan de descripción, v.3• revisión del plan de adaptación.

Descripciónexperimental yparticipativa(v.3)

3.1. Decidir sobre la versión final (v.3):• diseño detallado del SI• prototipo y diseño detallado del sistema informático• progresión del proyecto y plan de construcción.

Construcción( v.3)

3.2. Decidir sobre: • aceptación de la versión final construida y probada• progresión del proyecto• plan de instalación final.

Instalación(v.3)

3.3. Decidir sobre: • aceptación de la versión final instalada

4. Decidir sobre: • finalización del contrato.



4.4.1.2 Escenario 2: Derivar una secuencia básica en base a un modelode proceso del método

Definición Un modelo de proceso del método es una descripción de una clase deprocesos para un proyecto de SI propuesto por un método. En lamayoría de los casos, el modelo de proceso se utiliza con la finalidadde proporcionar normas, es decir, describir ‘cómodeben/deberían/podrían hacerse las cosas’, en contraste con el propioproceso, que es lo que ocurre realmente. Muy a menudo el modelode proceso del método contiene recomendaciones sobre la secuenciade puntos de decisión dentro del proyecto de SI [EM-DC].


1. Hallar correspondencias entre los productos del método y los productos de losestados inicial y final definidos por los perfiles de los entregables.

2. Utilizar el modelo seleccionado de proceso del método para determinar losproductos intermedios que pueden precisar decisiones del cliente a nivel degestión contractual.

La secuencia en que deben darse las decisiones del cliente determina la secuenciade los puntos de decisión.

Paso 1: Hallar correspondencias entre los productos del método y los estadosinicial y final

El primer paso consiste en definir los productos del método que puedencorresponderse con los productos de los estados inicial y final definidos por losperfiles del plan de adaptación. Si este paso se lleva a cabo antes del inicio de laadaptación del SI, puede que sólo algunos de los productos del estado inicial esténdisponibles para facilitar la definición; otros se describen únicamente mediante susperfiles, pero también se planifican para que estén disponibles en el estado inicial.Los productos del estado inicial pueden producirse utilizando un método distinto alque 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 dentrode 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 entérminos del método aplicado.

Hallarcorrespon-dencias entre losproductos delmétodo y losestados inicial yfinal



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

Conociendo los productos del método que se obtienen en el estado inicial y los quehan de producirse para el estado final, ya es posible determinar los productosintermedios que han de producirse de acuerdo con el método aplicado, en base almodelo de proceso del método aplicado21.

Para algunos de estos productos intermedios, el método aplicado puede precisardecisiones del cliente. Estos productos se convierten en entregables, es decir, seentregan al cliente. La secuencia en que deben darse las decisiones del cliente anivel de gestión contractual, determina la secuencia de puntos de decisión en elplan 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, losclientes y los proveedores pueden revisar y valorar la idoneidad del plan deadaptació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ómoadaptar una secuencia básica de puntos de decisión a fin de tener en cuenta lascontramedidas. Estas contramedidas se han seleccionado utilizando la técnicadescrita en el apartado 4.3.1.


• revisar las contramedidas propuestas en la estrategia de adaptación: paracada contramedida deberá adaptarse la secuencia básica de puntos dedecisió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 laorganización y el calendario.

La figura 4.32 refleja ejemplos de la influencia de las contramedidas en laplanificación de los puntos de decisión.

21 Algunos métodos no poseen un modelo de proceso; otros poseen un único modelo deproceso; 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 enconcreto, si un método propone alternativas. No obstante, las técnicas de planificación de laadptación pueden sustentar esta selección ayudando a definir la estrategia adecuada delproyecto.

Determinar lasnecesidades dedecisiones delcliente

Procedimientopara modificar lasecuencia básica



Contramedida Influencia en la planificación de los puntos de decisión

Involucrar a los agentesdel SI

ê Al inicio de la adaptación del SI deberá decidirse un plan parainvolucrar a los agentes del SI.

ê Informar a los agentes del SI es una condición necesaria de algunospuntos de decisión.

Formar a los agentes delSI

ê Al inicio de la adaptación del SI deberá decidirse un plan para unprograma de formación de los agentes del SI.

ê La formación deberá planificarse como condición necesaria de algunospuntos de decisión.

Utilizar la ingenieríainversa

ê Añadir puntos de decisión asociados al aumento del nivel decomprensión del SI actual mediante descripciones del mismo.

Realizar un análisis derequisitos riguroso

ê Añadir puntos de decisión acerca de requisitos del futuro SI yplanificar con un control de la configuración de los requisitos.

Rehacer los elementosdescriptivos

ê Añadir puntos de decisión acerca de la aprobación de nuevoselementos descriptivos.

Formar al equipo delproyecto

ê Al inicio de la adaptación del SI deberá decidirse un plan para unprograma de formación del equipo del proyecto.

ê Deberán planificarse informes sobre la formación del equipo delproyecto, que servirán de condiciones previas de algunos puntos dedecisión.

Subdividir la adaptacióndel SI

ê Plan que incluya decisiones iniciales de inversión o de diseño acercade la definición de una secuencia de adaptaciones del SI, véanse lasheurísticas generales de las figuras 4.31, 4.32.

Utilizar a un experto delSI con un alto grado decualificación

ê Plan que incluya decisiones del dominio del proyecto acerca de laasignación de agentes del proyecto. Se precisa un plan del proyectocon perfiles de los agentes del proyecto.

Clarificar las interfacesexternas con otros SI

ê Plan que incluya decisiones de diseño acerca de interfaces externas. Seprecisan elementos descriptivos que abarquen las propiedadesadecuadas, y planes para la construcción, ensayo e instalación de lasinterfaces.

Gestionar la complejidadde las propiedades decalidad

ê Plan que incluya decisiones iniciales de diseño acerca del intercambioentre propiedades funcionales y propiedades de calidad. Aprobar lasdescripciones de las propiedades de calidad y las propiedadesfuncionales que se precisen para sustentar esas decisiones.

Gestionar la migraciónpor pasos

ê Plan que incluya decisiones acerca del plan de migración. Se precisanplanes para la migración, incluyendo planes para la construcción yensayo de interfaces intermedias.

Utilizar una tecnologíaobjetiva segura, bienconocida y madura

ê Plan que incluya decisiones iniciales de diseño acerca de laarquitectura y la tecnología del sistema informático. Se precisanelementos descriptivos que abarquen la visión de la arquitectura delsistema informático. Si es posible, deberán aportarse prototipos quedemuestren la madurez de la tecnología seleccionada.

Utilizar normas ê Plan que incluya decisiones iniciales de diseño acerca del uso denormas, por ejemplo, las normas para sistemas informáticos abiertos.Se precisan elementos descriptivos que abarquen la visión de laarquitectura del sistema informático, centrándose en el uso de normas.



Figura 4.32: Ejemplos de la influencia de las contramedidas en los puntos dedecisión.



4.4.3 Describir los puntos de decisión

La figura 4.33 establece los elementos que debe tener una descripción de un puntode decisión dentro de un plan de adaptación de Eurométodo. Esta estructuradeberá utilizarse para cada punto de decisión. El anexo D.21 contiene una plantillade una descripción de un punto de decisión. La figura 4.33 proporcionaorientaciones acerca de cada uno de los elementos de la descripción. Además serecomienda lo siguiente:

• La secuencia y el calendario de los puntos de decisión deberán documentarseen un mismo lugar del plan de adaptación para facilitar el mantenimiento, porejemplo, en forma de tablas o diagramas. Es decir, no deberá existir uncalendario absoluto en las descripciones de puntos de decisión.

• En las versiones tempranas de un plan de adaptación, el calendario puedeenunciarse con referencia al inicio de la adaptación del sistema deinformación.

Elemento de ladescripción

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

1. Finalidad Describir la finalidad general del punto de decisión.

1.1. Finalidad del dominioobjetivo

Describir la finalidad de las decisiones relativas al dominio objetivo,por ejemplo, la selección de soluciones y la aprobación dedescripciones del SI actual o de uno futuro.

1.2. Finalidad del dominiodel proyecto

Describir la finalidad de las decisiones relativas al proyecto y aldominio contractual, por ejemplo, decisiones sobre entregables,calendario, presupuesto y asignación de recursos.

1.3. Finalidad del dominiocontractual

Describir la finalidad de las decisiones relativas al dominiocontractual, por ejemplo, decisiones sobre el plan de adaptación yotras cuestiones contractuales.

2. Funciones involucradas Describir las funciones involucradas en el proceso de toma dedecisiones.

Identificar a los agentes asignados a las funciones, para cadaorganización (cliente y proveedor) y para cada función.

3. Entregables Proporcionar una descripción general de los entregables y señalarcómo pueden sustentar la toma de decisiones.

3.1. Condiciones previas Describir los entregables que deben entregarse en el período que vadesde el punto de decisión previo hasta el punto de decisiónprevisto, 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 degestión (planes e informes). Representan el hito de los entregables avalidar dentro de la ejecución del punto de decisión.

Tanto los entregables del proveedor al cliente como los entregablesdel cliente al proveedor deberán describirse con referencia a losperfiles de los entregables que figuran en el anexo.




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

3.2. Bases para lasdecisiones

Describir los entregables que se han planificado para ser entregadoscomo base de las decisiones. Los entregables pueden ser: propuestade punto de decisión, elementos descriptivos, planes, informes, plande adaptación. Los planes e informes deberán abarcar laspropiedades acerca de los recursos y el presupuesto relativos a lainformación sobre el porcentaje de finalización.

Tanto los entregables del proveedor al cliente como los entregablesdel cliente al proveedor deberán describirse con referencia a losperfiles de los entregables que figuran en el anexo.

La propuesta de punto de decisión es obligatoria y deberá describirlos diferentes resultados de las decisiones, por ejemplo, losentregables se aceptan por completo, se aceptan con reservas o serechazan; y las acciones alternativas con respecto a estas acciones,por ejemplo, repetir el trabajo que sea preciso y volver a presentar elentregable. Si procede, los resultados y acciones alternativas puedenseñalarse en las finalidades de la descripción del punto de decisión,véase elemento 1.

4. Programa organizativoy calendario

Describir el programa organizativo del proceso de toma dedecisiones y el calendario para los entregables. Esto incluye lasresponsabilidades de elaborar una propuesta de punto de decisión yun informe de punto de decisión.

Normalmente, el proceso de toma de decisiones contienevalidaciones de entregables, preparación de las decisiones y una omás reuniones de punto de decisión. El programa organizativo y elcalendario deberán tener en cuenta la disponibilidad de las personasinvolucradas, y prever el tiempo suficiente para la preparación delas reuniones de punto de decisión.

5. Costes Efectuar una estimación de los costes del proyecto en el punto dedecisión, es decir, los costes que genera el proyecto desde el puntode decisión previo (o inicio del proyecto) hasta el actual, más elcoste del propio proceso de toma de decisiones.

Anexo Proporcionar perfiles de varios entregables necesarios: elementosdescriptivos, planes e informes; véase las directrices del apartado4.5.

Proporcionar referencias de los elementos descriptivos quedescribirán los elementos operativos y servicios necesarios.

Figura 4.33: Orientación acerca de la descripción de puntos de decisión.



4.5 Descripción de los entregables

La regla básica para determinar qué entregables se precisan para una decisión es lasiguiente:

• Los entregables deberán contener la información idónea para adoptar ladecisión y ninguna más; el exceso de información resulta caro de producir ygenera una imagen más confusa, con lo que dificulta el trabajo de laspersonas que toman las decisiones.

Los entregables necesarios deberán describirse utilizando los conceptosindependientes 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 elementosdescriptivos:

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 elementodescriptivo. Las figuras 4.35 – 4.37 reflejan heurísticas generales acerca de laplanificación de los tres tipos de decisión del dominio objetivo: inversión, diseño yaceptación del sistema, además de orientación en torno a los requisitos de loselementos descriptivos.


Orientaciones sobre el modo de elaborar el perfil de unelemento descriptivo

Visiones ypropiedades funcionales

Describir las visiones y propiedades funcionales que se precisan parafundamentar las decisiones; véase la figura 4.32-34, que muestraejemplos de decisiones de inversión, diseño y aceptación del sistema,y el anexo C , que contiene ejemplos de secuencias de puntos dedecisión.

Propiedades de calidad Describir las propiedades de calidad que se precisan parafundamentar las decisiones; véase la figura 4.35–37, que muestraejemplos de decisiones de inversión, diseño y aceptación del sistema,y el anexo C, que contiene ejemplos de secuencias de puntos dedecisión.


Describir las propiedades de la inversión que se precisan parafundamentar las decisiones; véase la figura 4.35, que muestraejemplos de decisiones de inversión.

Alcance Definir los diferentes tipos de alcance que se utilizarán en elproyecto, por ejemplo, en los términos de área de negocio, unidadorganizativa, conjunto de procesos o subsistemas del dominioobjetivo.

Asignar el tipo apropiado de alcance a este entregable de elementodescriptivo.




Orientaciones sobre el modo de elaborar el perfil de unelemento descriptivo

Soluciones alternativas Indicar hasta qué punto este elemento descriptivo contienedescripciones de soluciones alternativas.

Nivel de acuerdo Describir los diferentes tipos de niveles de acuerdo que se utilizaránen el proyecto, indicando:• qué agentes del dominio objetivo participan en el acuerdo entorno 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 elproyecto, 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 laversión del SI

Indicar qué versión del SI debería describir este entregable, porejemplo, el sistema actual, la primera versión instalada, o un futurosistema cuya instalación aún no se ha planificado.

Nivel de detalle Definir los diferentes niveles de detalle que se utilizarán en elproyecto, por ejemplo, el nivel de desglose y especializaciónutilizados 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 elproyecto, por ejemplo, en términos de los tipos de procedimientos decalidad 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 elementodescriptivo.




Heurísticas generales acerca de las decisiones deinversión

1. Finalidad Decidir si se invierte o no en un sistema de información nuevo (omodificado).

2. Funcionesinvolucradas

Incluye las funciones de la alta dirección.

3. Entregables


Visiones ypropiedadesfuncionales

Las propiedades funcionales, que fundamentan la valoración de losbeneficios, costes, riesgos y planes. Estas propiedades funcionalesdeberán utilizar todas las visiones que influyen en esos elementos, esdecir, las visiones que mostrarán cualquier cambio que se produzcaentre el sistema de información actual y el futuro. Ejemplos:

• si los procesos del negocio van a cambiar, es probable que losnuevos procesos del negocio repercutan en los beneficios,costes, etc., por lo que deberá utilizarse la visión de los procesosdel negocio.

• si la decisión afecta a los cambios en la organización, a lasprácticas de trabajo, las funciones de los agentes, laautomatización de las tareas o la interfaz entre hombre yordenador, deberá utilizarse la visión de las prácticas de trabajo.

• si va a cambiar la arquitectura del sistema informático, éstaprobablemente repercuta en los beneficios, costes, etc. por loque deberá utilizarse la visión de la arquitectura del sistemainformático.


Requisitos de eficiencia, seguridad, mantenibilidad, etc.


Beneficios¿Qué beneficio supone un nuevo sistema de información?Ello puede valorarse en términos de nuevas oportunidades demercado, ventaja competitiva, mejora de la calidad de unservicio o producto, mejor gestión, operación más eficiente,reducción de los costes organizativos, mejora de las condicionesde trabajo para los agentes del sistema de información, etc.

Costes¿Cuáles son los costes de la adaptación del sistema deinformación, por ejemplo, costes del soporte físico y del soportelógico, costes de construcción, costes de instalación, etc.?¿Qué costes operativos genera el nuevo sistema de informacióny 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 sistemapueda utilizarse para valorar los beneficios, costes, riesgos, etc.





Solucionesalternativas

Deberán presentarse alternativas.





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 paravisiones específicas.

Cuantificación Estimaciones de volúmenes, capacidad, etc. necesarias para lavaloración de costes, beneficios y riesgos.

Simulación Posibilidad de demostrar partes críticas o inciertas del sistema deinformación mediante prototipos, por ejemplo maquetas.

Versión del SI Un futuro sistema de información.No obstante, en ocasiones pueden introducirse entregables referidos alsistema de información actual. Estos entregables pueden utilizarse conla siguiente finalidad:

• Valorar si la comprensión del sistema de información actual escorrecta.

• Servir de base para expresar los cambios del sistema deinformación.

• Justificar las propuestas de cambios mediante un diagnóstico delsistema de información actual.

• Comparar el futuro sistema de información con el actual ygarantizar que hay una mejora.

Aparte de estas finalidades, no existe justificación para laintroducción de un entregable referido al sistema actual como insumopara una decisión de inversión, ni siquiera si su producción se haplanificado con un método de desarrollo.

Nivel de detalle Una visión global (bajo grado de desglose, bajo grado deespecialización) es suficiente para valorar los beneficios, costes,riesgos, etc.Sin embargo, en ciertos casos se precisa una apreciación másprofunda de aquellas partes del sistema que se consideran críticas,complejas o inciertas. Para estas partes se precisa más detalle en lasdescripciones; el nivel de detalle correcto es el que permite adoptar ladecisión de inversión.

Estado de calidad Debe adaptarse a la decisión a tomar: normalmente las decisiones deinversión no precisan un nivel máximo de coherencia, precisión ointegridad.

Planes e informes

Plan de adaptación No se precisa necesariamente el plan de adaptación completo, sinoque deben conocerse varias fechas clave, como la fecha en que estarándisponibles los principales subsistemas.


Se precisa algún tiempo entre la entrega y la reunión de puntos dedecisión.

Figura 4.35: Heurísticas para la definición de decisiones de inversión.




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

1. Finalidad Decidir si un sistema de información nuevo (o modificado) es aceptabletal y como está descrito.


3. Entregables

Elementos descriptivos Las características dependen del enfoque, como se explica en el apartado4.4.1.


Potencialmente todas las propiedades, en función de la finalidad. Porejemplo:

• Si la decisión se refiere a cambios del negocio y de los recursos deinformación que lo sustentan, el perfil del entregable utilizará lavisión de la información del negocio y la visión de los procesos delnegocio.

• Si la decisión se refiere a cambios de la organización, las prácticasde trabajo, las funciones de los agentes, la automatización de lastareas o la interfaz hombre-ordenador, el perfil del entregableutilizará la visión de las prácticas de trabajo.


Potencialmente todas las propiedades de calidad.


Alcance Dependerá de la naturaleza de la decisión y de su ubicación en lasecuencia.


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 alsistema de información actual. Las heurísticas para las decisiones dediseñ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 lasecuencia.

Estado de calidad Los procedimientos de calidad a aplicar suelen estar más elaborados quelos de las decisiones de inversión. Los procedimientos de control decalidad 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 delcontrol de calidad aplicado a los elementos descriptivos.


Figura 4.36: Heurísticas para la definición de decisiones de diseño.




Heurísticas generales acerca de la aceptación del sistema

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

• Decisión de aceptación de un sistema de informaciónconstruido y probado.

• Decisión de aceptación de un sistema de información instaladoy operativo.


3. Entregables

Elementosoperativos

Elementos operativos probados o instalados.


Una descripción actualizada y definitiva del sistema de información,si no se ha realizado y comprobado anteriormente.



Alcance


No existen 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 decalidad.

Planes e informes • Informes de aseguramiento de la calidad que muestran losresultados de los ensayos del sistema construido o validacionesdel sistema instalado.

• Informes de gestión de configuración (en su caso).

4. Programaorganizativo ycalendario

Se precisa algún tiempo entre la entrega y la reunión de punto dedecisión.

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, quedefinen las propiedades que deben reunir los productos del método queintercambiarán el cliente y el proveedor durante la adaptación del sistema deinformación.

Una vez se ha establecido el plan de adaptación, los perfiles de los entregables quese precisen deben enlazarse con los productos definidos en los métodos utilizadospor el proveedor. El proveedor deberá describir los productos del método que seentregarán en cada punto de decisión para satisfacer los requisitos descritos en losperfiles de los entregables. Esta actividad podrá apoyarse en un diccionario deenlace con los métodos, es decir, un conjunto de perfiles de productos del métodoque describen los productos definidos en los manuales del método, utilizando laterminología de Eurométodo.

Un diccionario de enlace con los métodos puede utilizarse para adaptar yestablecer correspondencias entre los perfiles de los productos del método y elperfil del entregable que se precise, hasta que se ha hallado el mayor númeroposible de correspondencias con las propiedades establecidas.

El procedimiento para hallar el conjunto de productos del método que concuerdecon el perfil del entregable que se precisa, presenta algunas de las características dela solución de un rompecabezas. El perfil del entregable que se precisa representaun contorno imaginario en el que encajan unas piezas, que son los perfiles de losproductos del método que debemos hallar. En esta analogía, la ‘forma’ de laspiezas viene definida por las propiedades que posee cada uno de los productos delmétodo; y la ‘forma’ del contorno viene definida por las propiedades que especificael perfil del entregable que se precisa.

Esta analogía debe recordar al lector que el proceso de establecer enlaces con losproductos del método no tiene por qué ser secuencial en la realidad.

Pero también existen límites para esta analogía. Mientras que un rompecabezasposee una solución determinada, hallar los productos del método apropiadossupone adaptar los productos del método a los perfiles de los entregables que seprecisan. Esto implica que pueden existir diferentes combinaciones de productosdel método adaptados que concuerden con el perfil del entregable que se precise.

Si el perfil del entregable que se precisa incluye alguna propiedad no contempladapor los productos del método, deberán identificarse ampliaciones de los métodosque permitan cubrir esa laguna. Una vez se ha conseguido esto, se pueden elaborarperfiles de los productos del método para las ampliaciones, al objeto de completarel 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 yla elaboración de un plan de adaptación se componen de las mismas actividades,

Cómo utilizar undiccionario deenlace con losmétodos

La identificaciónde losentregables delmétodo es comoun rompecabezas

pero las piezasdelrompecabezas sepueden hacer amedida

Cómo gestionarlas propiedadespara las que noes posible hallarcorrespondencias



con la única diferencia de que en el primer caso existe una propuesta al inicio de laactividad. Por ejemplo:

• Las técnicas de análisis de riesgos también son relevantes como orientaciónpara la valoración de un plan de adaptación. Es esencial comprender lasituación del problema a fin de valorar la idoneidad de un plan de adaptacióny 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 puedenconsiderarse técnicas de valoración de la idoneidad de una estrategia deadaptación seleccionada dentro de un plan de adaptación.

• Las técnicas de comprobación de la coherencia de la descripción de puntosde decisión pueden utilizarse como técnicas de valoración de los puntos dedecisió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 suestado inicial. Esta valoración podría incluir la siguiente evaluación de lacoherencia entre los elementos de un estado inicial:

• El plan del proyecto relativo a la adaptación del sistema de información encuestión deberá ser coherente con el plan de adaptación.

• Las descripciones relativas a los elementos operativos disponibles para elproyecto del sistema de información, deberán estar actualizadas. Loselementos operativos se instalan en un sistema de información en su estadoinicial, 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ánaplicarse los siguientes criterios de calidad relativos a la calidad de la descripciónde los estados inicial y final:

• Deberán valorarse las descripciones que deberían estar disponibles para laadaptación del sistema de información (parte del estado inicial) y lasdescripciones que el cliente desea utilizar una vez finalizada la adaptación delsistema de información (parte del estado final).

• Los perfiles de las descripciones de estados iniciales deberán estar enconcordar con el contenido y situación de las descripciones actuales o con lasexpectativas en cuanto al contenido y situación de las descripcionesdisponibles al inicio de la adaptación del sistema de información.

• Los perfiles de las descripciones de estados finales deberán estar de acuerdocon los requisitos y expectativas del cliente.

• Los productos que el proveedor facilitará en el estado final deberán estardocumentados y coincidir con los perfiles.

Simular laelaboración deun plan deadaptación

Valorar elcontexto del plande adaptación

Criterios decalidad para ladescripción delos estadosinicial y final



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, quedeberá adaptarse a la situación.

Si la estrategia se describe utilizando la terminología de Eurométodo, deberánutilizarse las técnicas descritas en el apartado 4.3 al objeto de comprobar lossiguientes criterios de calidad:

• Deberá existir una coherencia interna en la estrategia de adaptación. Porejemplo, ausencia de contradicciones entre las modalidades de descripción,construcción e instalación.

• La estrategia de adaptación deberá dar como resultado el estado final que seprecisa.

• Las modalidades de descripción, construcción, instalación y control delproyecto deberán ser adecuadas. Esto puede valorarse utilizando lasheurísticas de selección de enfoques, véase apartado 4.3.2, y de análisis derepercusiones, véase apartado 4.3.5.

• El resto de contramedidas deberá ser adecuado. Esto puede valorarseutilizando las heurísticas de selección de contramedidas, véase apartado4.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ánaplicarse los siguientes criterios de calidad, relativos a la idoneidad de los puntosde decisión planificados:

• Los puntos de decisión deberán adaptarse a la situación y ser coherentes conla estrategia de adaptación descrita, para lo cual deberá proporcionarse unajustificación. Esto puede valorarse utilizando las heurísticas de definición deuna secuencia de puntos de decisión, véase apartado 4.4.1-2.

• Las finalidades de los puntos de decisión deberán ser comprensibles yadecuadas.

• Las descripciones que sirven de condiciones necesarias o de bases para latoma de decisiones deberán describirse utilizando perfiles de los elementosdescriptivos, es decir, términos independientes del método.

• Los entregables deberán definirse y ser suficientes de acuerdo con lasfinalidades de las decisiones. Esto puede valorarse utilizando las heurísticasde 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 lasdecisiones.

• Las descripciones propuestas por el proveedor deberán estar documentadas ycoincidir con los perfiles de los elementos descriptivos.

Criterios decalidad para laestrategia deadaptación

Criterios decalidad para lasdescripciones depuntos dedecisión



• Las funciones propuestas que intervienen en la toma de decisiones deberánser apropiadas y asignarse a las personas adecuadas.

Capítulo 5Descripció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 deestado estable y sus resultados (véase figura 5.1.). Estos resultados se incluyen enla petición de ofertas, en la oferta y en el contrato (consultar 2.3. y 3.2.) cuando lacompra se refiere a servicios. Este capítulo debe ser leído por los responsables deproyecto de los clientes y de los proveedores. En el transcurso de una adquisiciónse 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 porotra persona u organización. La subcontratación de un proceso se considera unamanera de obtener mayores beneficios de ese proceso.

La finalidad de un servicio de estado estable es contribuir al funcionamiento deldominio objetivo (cf. capítulo 1). Los servicios de estado estable se caracterizanpor:

• 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 dereingeniería de procesos de negocio, que son un tipo de adaptación del dominioobjetivo. De hecho, la contratación de un proceso suele conllevar cambiosorganizativos importantes en el dominio objetivo, que deben estudiarse yprepararse con cuidado. Para llevar a cabo estos proyectos deberán utilizarsemétodos adecuados de análisis de requisitos y de reingeniería de procesos denegocio.

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 losfuturos servicios

• planes (planes de prestación de servicios y planes de servicio) o requisitos deplanes.

Estos resultados constituyen los insumos para las actividades que se explican en lossiguientes apartados.

Si no se ha llevado a cabo un proyecto de este tipo, será preciso realizar un estudiode reingeniería de procesos como parte de las actividades de descripción yplanificación del servicio. En cualquier caso, se dispondrá de un determinadoconjunto de requisitos del servicio, como parte del objetivo de la adquisición.

Puede utilizarsela reingenieríade procesos denegocio parapreparar lacontratación deprocesos

Los requisitosdel servicioforman parte dela definición delobjetivo de laadquisición



5.1 Descripción de servicios

Actividad Insumo y resultado

1. Identificar el tipo de servicio (opcional)

2. Describir las propiedades del servicio:

• las propiedades de la inversión

• las propiedades funcionales

• las propiedades de calidad

Entrada:

• Requisitos del servicio

• Descripciones disponibles de losprocesos/servicios existentes en el dominioobjetivo (opcional)

• Descripciones disponibles deprocesos/servicios similares (opcional)

• Descripciones de procesos incluidas en lanorma ISO-LCP (opcional)

• Descripciones de servicios incluidas en lospaquetes 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 quecaracterizan cada servicio, y por intención, es decir, por su tipología (por ejemplo,un tipo de servicio es el mantenimiento).

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 CicloVital de la norma ISO

Un servicio puede ser declarado en términos de tipos de procesos y tipos deelementos operativos que son objeto de dicho servicio. La norma ISO sobreProcesos del Ciclo Vital [ISO-LCP] proporciona una lista de tipos de procesos(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, comoprocedimientos, soporte físico o agentes formados.

Pueden aplicarse varios tipos de procesos a cada tipo de elemento operativo. En lapráctica, diferentes elementos operativos pueden requerir diferentes tipos deservicios.

La figura 5.2 muestra las correspondencias existentes entre Procesos del CicloVital y los tipos de elementos operativos dentro de la norma [ISO-LCP]. Esta

Describir unservicio por laspropiedades ypor la tipología

Identificar eltipo utilizando lanorma [ISO-LCP]



matriz no es exhaustiva, de manera que también son válidos otros tipos decorrespondencias, aunque no estén recogidos en la norma, como por ejemplo elmantenimiento de las instalaciones.

La norma [ISO-LCP] proporciona descripciones normalizadas de los Procesos delCiclo Vital, desglosándolos en actividades y tareas (véase ejemplo de la figura5.3.).

Figura 5.2: Correspondencias entre los procesos y los elementos operativosincluidos en la norma [ISO-LCP]

Elementos operativos

Procesos del Ciclo Vital dela norma ISO-LCP

Instalacio-nes

(edificios,cableado

etc.)

Soportefísico

Software desistema

Software deaplicación

Datosfísicos

Manualesde usuario yde operador

Descripcióndel trabajo

Programade

formación/migración

Agentesformados

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.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 tipode servicio.

Los proveedores de servicios normalmente especifican los servicios en términos depaquetes de servicios, como servicios de ayuda y gestión de problemas. A menudoutilizan su capacidad y su plantilla para atender a las solicitudes de servicios devarios clientes a la vez, de manera que los clientes comparten algunos de lospaquetes de servicios.

Estos paquetes de servicios suelen describirse con mayor detalle que lasdescripciones de procesos de la norma [ISO-LCP]. La biblioteca de infraestructurade tecnologías de la información de la CCTA [ITIL] proporciona una descripciónde 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 deservicios.

Proceso de mantenimiento del software

Actividades Tareas

Implementación del proceso 1. El responsable de mantenimiento deberádesarrollar, documentar y ejecutar planes yprocedimientos para llevar a cabo las actividades ytareas del proceso de mantenimiento.

....

Análisis del problema y de lamodificación

1. El responsable de mantenimiento deberá analizarel informe del problema o la solicitud demodificación, al objeto de detectar lasrepercusiones en la organización, en el sistemaactual y en el sistema con el que existe interfaz..etc.

2. El responsable de mantenimiento deberá replicar overificar el problema.

......

Implementación de la modificación ......

Revisión/aceptación delmantenimiento

......

Migración ......

Retirada del software ......

Identificar eltipo utilizandopaquetes deservicios



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

Gestión de problemas Reconocer y resolver problemas de infraestructura.

Gestión de cambios Llevar a cabo cambios controlados del sistema deinformación, de manera que se evite cualquierinterrupción o problema en la prestación de servicios.

Servicios de ayuda Ayudar a los usuarios en el uso de los sistemas o serviciose intentar gestionar las desviaciones o incidentes de queinformen los clientes.

Control y distribución desoftware

Validar todos los elementos de software y garantizar quese comercializan únicamente versiones probadas y válidasde software autorizado.

Gestión de la red Gestionar todas las instalaciones de comunicación dedatos

Gestión de operaciones Cuidar de la operación diaria de los sistemas.

Gestión de procesadores yterminales locales

Gestionar los sistemas y estaciones de trabajo 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 lacapacidad disponible. Posibilitar el cumplimiento de losrequisitos 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 yapoyar a la organización que presta los servicios de TI, alobjeto de garantizar el cumplimiento de los requisitos delnegocio.

Gestión de contingencias Garantizar y restaurar la disponibilidad de sistemas yaplicaciones (por ejemplo, mediante procedimientos decopia de seguridad y recuperación) en caso de catástrofesy 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 nuevosrequisitos de los clientes, los cuales son causa de problemas que deben sergestionados (gestión de problemas) y pueden activar una ‘cadena decambios’ 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 operanlos elementos operativos incluyen la gestión de operaciones automatizadas,gestión de redes, gestión de procesadores y terminales locales. Los incidentes

Servicios alcliente

Servicios degestión deoperaciones



que se produzcan en estas instalaciones centrales y redes pueden conducir ala misma ‘cadena de cambios’.

Además, pueden existir relaciones entre los proyectos de adaptación y algunos deestos 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

Las descripciones de los servicios son un tipo de elemento descriptivo. Unadescripción del servicio puede caracterizarse mediante un perfil del elementodescriptivo (véase 3.6.1) que indique las propiedades de interés:

• propiedades funcionales

• propiedades de calidad

• propiedades de la inversión.

El perfil del elemento descriptivo indicará también: alcance del servicio, nivel dedetalle, nivel de acuerdo, grado de formalidad, cuantificación, simulación,identificación de la versión del servicio, soluciones alternativas y estado de calidaddel elemento descriptivo del servicio. En el apartado 3.6 figuran más orientacionesacerca del modo de describir estas características.

Las descripciones normalizadas que especifica la norma [ISO-LCP] y lasdescripciones de los paquetes de servicios simplifican la descripción del servicio, alexistir la posibilidad de reutilizar las descripciones existentes.

En la práctica, la descripción de las propiedades de la inversión, funcionales y decalidad se lleva a cabo en paralelo, debido a las interdependencias entre estasactividades.

5.1.2.1 Describir las propiedades de inversión de un servicio

Las bases lógicas o los objetivos de la contratación de un servicio puedendescribirse mediante las propiedades de la inversión, las cuales hacen referencia alos costes y beneficios del servicio.

• CostesLos costes de instalación, ejecución, mantenimiento y cancelación delservicio

• BeneficiosLos beneficios que un servicio aporta al dominio objetivo. Entre los máshabituales 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

Caracterizar unadescripción delserviciomediante unperfil delelementodescriptivo

Describir elobjetivomediante laspropiedades dela inversión



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

• RiesgoLos 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 deriesgos, 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 consisteprincipalmente en las propiedades de los procesos de negocio y de las prácticasde trabajo (véase 3.6.2). Los Procesos del Ciclo Vital de la norma [ISO-LCP] sedescriben en términos de propiedades de los procesos del negocio, mientras quelos paquetes de servicios suelen describirse en términos de propiedades de losprocesos de negocio y propiedades de las prácticas de trabajo.

Para algunos servicios, puede que esta descripción deba perfeccionarseutilizando otras visiones. En particular, se precisará la visión del sistemainformático cuando una parte del servicio esté automatizada.

Para otros servicios, cuando sea preciso representar algún aspecto de laorganización distinto del sistema de información, las descripciones de losservicios 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 paradescribir el proceso de negocio que aborda el servicio.

Ejemplo Un servicio de mantenimiento del software puede describirse de la siguientemanera:

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ánperfeccionarse, a fin de representar estos flujos de material, capital y energía.

Describir lasfunciones, porejemplo,mediante laspropiedades delas prácticas detrabajo



Las siguientes propiedades de la visión de las prácticas de trabajo se utilizan de lasiguiente 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 conocidaen 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 resultadofavorable, 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 ypor el cliente (por ejemplo, fotocopias, impresión de documentos, serviciosté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 detrabajo 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



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 detrabajo y posee una categoría de prioridad 2

TAREA: resolver este problema

REGLAS DE LA TAREA: el procedimiento normalizado para resolver esteproblema

RESPONSABLE DE LA EJECUCIÓN: el encargado del servicio de ayuda queesté 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 estrategiade la organización. Por ejemplo, la rapidez con que los datos deben estardisponibles para una tarea, o qué importancia tiene la portabilidad para laorganización. La lista de propiedades de calidad que se ofrece en el apartado 3.6.(por ejemplo, seguridad, fiabilidad, facilidad de uso, eficiencia) puede utilizarsecomo lista de comprobación para identificar estos requisitos de calidad.

Estos requisitos de calidad deben ordenarse por prioridades y acordarse entre losdistintos agentes que intervienen, con lo que se obtendrá una lista de requisitos decalidad ordenada que expresará en términos mensurables (por ejemplo, acceso enun segundo) la importancia del requisito, la motivación para el requisito y el nivelde acuerdo entre los agentes.

Pueden proponerse distintos tipos de acción para ocuparse de los requisitos decalidad. Por ejemplo, personal de apoyo a la formación, procedimientos dedesarrollo para la recuperación tras una catástrofe, seguros de riesgos, uso de unpaquete de aplicaciones, inclusión de funciones de diálogo adicionales en elsistema, o inclusión de un modelo de datos normalizado. A menudo existirán variasopciones que reflejarán diferentes niveles de calidad, por ejemplo, escoger entreuna interfaz de usuario estática o dinámica. Los costes de estas opciones deberánser diferentes y reflejarse en las propiedades de la inversión. Estas opcionesdeberán reflejarse también en las propiedades funcionales del servicio.

A menudo, el nivel de servicio sólo puede garantizarse en determinadascondiciones relativas a la cuantificación. Deberán indicarse todos los supuestosrelativos a las condiciones en que se garantiza el nivel de servicio.

Tomemos como ejemplo un supuesto acerca del número de llamadas que puedegestionar un servicio de ayuda. Normalmente un analista del servicio de ayuda quese encargue de la recepción de llamadas es capaz de atender 35 – 40 llamadastelefónicas en una jornada de ocho horas. Esto supone que los picos no alcanzannunca el doble de la media calculada para un período de varias semanas.

Describir el nivelde serviciomediante laspropiedades decalidad

Puntualizar lasdescripciones dela propiedad dela tarea

Indicar lossupuestosrelativos a lacuantificación



5.2 Planificación de servicios

Actividad Insumo y resultado

1. Análisis de riesgos

2. Diseño de la estrategia de prestación delservicio

3. Planificación de puntos de decisión

Insumo:– descripción del servicio– plan de adquisición

Resultado:– plan de prestación de servicios

Figura 5.5: Actividades y resultados de la planificación de servicios

Un plan de prestación de servicios define la descripción de la situación, laestrategia de prestación del servicio y los puntos de decisión durante unaprestación de servicios. Se ocupa de la instalación del servicio, la ejecución delservicio 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., yla 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 relativosal plan de prestación de servicios.

Figura 5.6: Ejemplo del nivel de servicio que proporciona un proveedor en unaprestación de servicios

La instalación y la retirada del servicio son adaptaciones.

La instalación del servicio puede llevarse a cabo en diferentes contextos:

• contratación de un proceso ya existente en el dominio objetivo

• contratación de un servicio ya existente (posiblemente a un proveedordiferente)

• contratación de un nuevo proceso.

La retirada del servicio puede llevarse a cabo con diferentes intenciones:

Contenido de unplan deprestación deservicios

Los tressubprocesos deuna prestaciónde servicios



• 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. Lasmejoras 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 delproblema que incluye:

• 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 ycomo se describen en la descripción del servicio.

5.2.1.1 Documentar el estado inicial y el estado final de la instalación delservicio

El estado inicial de la instalación del servicio puede incluir (según el contexto):

• el proceso/servicio existente

• los elementos operativos sujetos a la ejecución del servicio

• 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).

Resultado de unanálisis deriesgos

Documentar losestados inicial yfinal de lainstalación y lacancelación



5.2.1.2 Documentar el estado inicial y el estado final de la cancelacióndel 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 delservicio/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 situacionalesy 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 lasadaptaciones. Así pues, deberán seguirse los siguientes pasos:

• identificar los factores situacionales que son apropiados para los serviciosque se prestan

• determinar los valores de los factores situacionales, y registrar sujustificació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 sidoadaptada 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)



− 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 losservicios 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 servicioen 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óndel 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

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

5.2.2.2 Documentar el enfoque de la cancelación

Para desarrollar un enfoque de la cancelación se utilizan los enfoques descritos enel apartado 4.3.2. Las posibles opciones de cancelación del servicio son: de unavez, incremental y evolutiva. Las opciones de cobertura geográfica son: global ylocal.

5.2.2.3 Documentar el enfoque del control del servicio

El apartado 4.3, que trata de distintos aspectos del enfoque del control delproyecto (frecuencia, formalidad, responsabilidades del cliente), puede utilizarsepara caracterizar los enfoques del control del servicio.

El control de calidad del servicio es una cuestión clave del control del servicio.Deberá especificarse un procedimiento de medida, al objeto de evitar discusionesacerca de si se ha conseguido el nivel de servicio acordado. Para ello se procederáde la manera siguiente:

• determinar o hacer referencia a métricas que permitan medir cada una de laspropiedades

• definir una escala de valores para cada métrica

• definir un procedimiento de medida objetivo, fiable y eficiente para cadamétrica

• especificar los valores actuales, los valores mínimos aceptables y los valoresdeseados, a ser posible para varios momentos futuros.

Opciones de laestrategia deprestación delservicio

Especificar unprocedimientode medida delcontrol decalidad



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 lascuales pueden utilizarse para contrarrestar riesgos identificados en la apreciaciónde la situación del problema. No obstante, es preciso tener en cuenta tambiéncontramedidas específicas de los distintos tipos de servicios.

5.2.3 Planificación de puntos de decisión

El insumo para la planificación de puntos de decisión es la estrategia de prestacióndel 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 quepueden utilizarse las recomendaciones del apartado 4.4.

• Ejecución del servicio: la secuencia de puntos de decisión deberá reflejar lasopciones seleccionadas del enfoque del control del servicio y lascontramedidas para reducir riesgos. Normalmente, durante la ejecución delservicio se repiten periódicamente puntos de decisión de naturaleza similar,en los cuales se suelen tomar decisiones relativas al nivel de servicio, mejoray mantenimiento del servicio. En estos puntos de decisión podrán decidirseadaptaciones para la mejora del nivel de servicio.

• Cancelación del servicio: se trata de un tipo especial de adaptación para elque pueden utilizarse las recomendaciones del apartado 4.4.

Posteriormente, estas tres secuencias deberán fusionarse en el plan de prestaciónde 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 enel apartado 4.4.3.

En cuanto a la instalación y cancelación del servicio, puede utilizarse laorientación descrita en el apartado 4.4.3, suponiendo que se hayan realizado losajustes 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ónperiódicos es revisar el rendimiento del proveedor, comparándolo con los nivelesde servicio especificados, y revisar los requisitos del servicio a fin de valorar siaún cumplen las necesidades del negocio o si precisan modificaciones. Los

Tener en cuentacontramedidasespecíficas paralos riesgosinherentes aprestación delservicio

Planificar conpuntos dedecisiónperiódicos parael control delservicio

Valorar si secumplen lasnecesidades delnegocio



entregables que se utilizan como base para estas decisiones son los planes y losinformes de servicio (véase apartado 3.3.2.).

Se recomienda documentar la secuencia y calendario de los puntos de decisión enun lugar concreto dentro del plan de prestación de servicios, al objeto de facilitarel mantenimiento, es decir, las descripciones de los puntos de decisión no deberánincluir 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, 5Rue d’Angoussaart, B-1301, Bierges, Belgique.

[IEEE-610.12] IEEE. Standard Glossary of Software EngineeringTechnology. Spring 1990. ANSI/IEEE Std. 610.12 1990.

[ISO/IEC 2382-20] Information Technology – Vocabulary. Part 20: SystemDevelopment. 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: Firstedition 1991-12-15.

[ISO-LCP] Information Technology – Software Life Cycle Processes.First edition 1995-08-01.

[ITIL] IT Infrastructure Library, HMSO Books (P9D), StCrispin’s House, Duke Street, Norwich NR3 1PD

[KSP] Kwaliteit van softwareprodukten, KluwerBedrijfsinformatie B.V., Deventer 1996, ISBN 90-267-2430-6.



Índice de materias

A

abnormal contract completion, 89acquisition, 15, 30acquisition goal, 16, 32, 33acquisition goal definition, 32acquisition initiation, 18, 30acquisition management, 21acquisition plan, 16, 35, 56acquisition process, 15, 30acquisition strategy, 16, 38actors, 127adaptation, 15adaptation plan, 28adaptation plan, 22, 28, 69, 99adaptation planning, 27adaptation planning techniques, 148adaptation processes, 13adaptation strategy, 28, 53, 63, 191alternative solutions, 144analytical approach, 175animation, 143application software, 122, 128assess situational factors, 85assessment of an adaptation plan, 75, 216

B

benefit, 138business expertise, 23business information view, 126business needs, 16business process view, 127

C

cognitive approach, 175complexity, 27, 156, 157, 174computer system, 14computer system architecture view, 128computer system data view, 127computer system function view, 127computer system views, 125configuration control, 181configuration management, 110configuration management expertise, 23considered context, 115, 119consistency rules between the views, 132construction approach, 178construction process, 26contract, 17, 45, 77, 97, 99contract authority, 22contract completion, 69, 92

contract completion process, 19contract completion report, 94, 106contract change control, 87contract domain, 98contract domain deliverables, 96contract domain properties, 98, 107contract management, 21contract monitoring, 79contract monitoring process, 19contract status report, 87, 93, 106cost, 138cost estimation, 71countermeasures, 170, 206critical risks, 167customer, 16customer responsibility, 180customer-supplier relationship, 16

D

data, 127decision point, 22, 63, 193decision point deliverable, 98, 106decision point description, 194, 208decision point proposal, 85, 106decision point report, 89, 106decision points, 55, 218, 235decision points planning, 70decisions, 19, 85degree of decomposition, 139degree of formality, 142degree of specialisation, 139, 140deliverable, 24, 63deliverable type, 97deliverable types, 96delivery plan, 22, 60, 63, 69, 80, 99description, 175description approach, 185, 200description of deliverables, 70, 210description process, 26descriptive item, 97, 123descriptive items profile, 210design decision, 196design decisions, 214design of adaptation strategy, 70design of service provision strategy, 70development, 25, 110development approach, 175, 183development control, 181

E

efficiency, 137



evaluation matrix, 74event, 129evolutionary construction, 178evolutionary construction approach, 121evolutionary installation, 179evolutionary installation approach, 121experimental approach, 175expert-driven, 176

F

facilities, 121final state, 15, 149, 232financial authority, 23, 64formal, 142formality, 180function, 128functional properties, 125, 227functionality, 137

G

geographical coverage, 179global installation, 179

H

hardware, 128hardware device, 121human-computer interface, 127

I

incremental construction, 178incremental installation, 179informal, 142information resource, 13, 126information system, 14information system expertise, 23information system views, 125initial state, 15, 46, 149, 231, 232installation, 178installation approach, 178, 234installation process, 26investment decision, 196investment decisions, 212, 213investment properties, 226IS-adaptation, 14IS-procurement requirements, 98

L

legal authority, 23, 72legal clauses, 72level of agreement, 141level of detail, 139local installation, 179

M

maintainability, 137management deliverables, 84, 96, 109management of risk, 145

method bridging dictionary, 216method process model, 205

N

network management expertise, 23

O

one shot construction, 178one shot installation, 178operational expertise, 23operational item, 97, 121organisation characteristics, 66, 73organisational authority, 23organisations, 13

P

participatory, 176physical data, 122plans, 109portability, 137problem situation, 27problem situations, 232processes, 13, 127processing units, 128procurement, 16, 17project, 20, 71project actors, 156project control, 179project control approach, 179, 188, 201project control aspects, 179project domain, 156project management deliverable profile,

116project management deliverables, 109project plan, 64project plans, 110project production, 21project properties, 113, 114, 118, 119project reports, 110project structure, 156project task, 156project technology, 156prototype, 143

Q

quality assurance, 25, 110quality assurance expertise, 23quality control, 181quality management authority, 23quality properties, 135, 229quality state, 115, 119, 122quality state of a descriptive item, 144quantification, 142

R

reliability, 137reports, 109



request for proposal, 61, 98requirements analysis, 33, 41response, 98retirement approach, 234risk, 28, 138, 145risk analysis, 27, 37, 38, 63, 70, 147, 148risk management, 18, 37risk management planning, 147risk management strategy, 38, 40risk monitoring, 147risks, 232roles, 22

S

scenario, 143scope, 138security, 137semi-formal, 142senior management, 23sequence of decision points, 28, 193, 197service, 15, 221service control approach, 234service description, 62service descriptions, 226service execution, 29, 117, 231service installation, 29, 230service management deliverable profile,

119service management deliverables, 116service or project authority, 22service or project management, 21service organisation, 20service packages, 224service plan, 64, 71, 116service plans, 116service provision, 21, 54, 116service provision plan, 22, 29, 69, 99, 230service provision strategy, 29, 63, 234service retirement, 29, 230simulation, 142situation description, 217situational approach, 27

situational factors, 27, 37social approach, 176strategy options, 28, 175, 190sub-system, 150sub-systems, 154supplier, 16supplier evaluation report, 98supplier selection, 74supplier selection criteria, 65system acceptance decision, 196system acceptance decisions, 215system coverage, 178system operation expertise, 23system software, 121, 128system version, 122system/service version, 143systems description, 62

T

target domain, 15, 32, 62, 68, 124, 155target domain deliverables, 82, 97, 120task, 127technical expertise, 23tendering, 59tendering deliverable, 98tendering process, 18, 45trained actors, 122training and/or migration programmes, 122type of a service, 222typical final state, 47, 49typical initial state, 47, 50

U

uncertainty, 156, 158, 164, 173usability, 137user and operator manuals, 122user expertise, 23

W

work descriptions, 122work practice view, 125, 127

eurometodo_v1

Documents