Suscríbete a DeepL Pro para poder traducir archivos de mayor tamaño.

Más información disponible en www.DeepL.com/pro.

Información y Gestión 24(1993) 257-266

North-Holland

Investigación

Adquisición de sistemas informáticos

Gestión del riesgo
Universidad de Pensilvania y máster
en Ciencias de la Industria por la
Susan A. Sherer Universidad de Lehigh.
Lehigh tlnieersity, Bethlehem, PA, EE.UU. de la Universidad Estatal de Nueva
York en Búfalo y Licenciado en
Ciencias por la Universidad Estatal
de Nueva York en Albany. Antes de
Las empresas ya no desarrollan sistemas personalizados dedicarse a la aca- demia, la Dra.
para cada aplicación. De hecho, el crecimiento de las Sherer dirigió proyectos de
empresas especializadas en software, junto con la desarrollo de software. Su actual re
diversidad de requisitos de cualificación, la rápida Sus intereses de investigación incluyen la medición y
evolución de la tecnología y el aumento de la demanda de gestión del riesgo del software y el desarrollo de
aplicaciones automatizadas, impulsan la compra de software y la gestión de pruebas. Es miembro de TIMS,
productos de software. Éstos deben adaptarse a las DSI y SIM. Correspondencia a: Susan S. Sherer, Lehigh
necesidades específicas del horno e integrarse en las University, Col-
instalaciones existentes. lege of Business and Economics, Ranch Business Center 37,
La compra de software puede reducir algunos componentes Bethlehem. PA 18015, U.S.A. sas6 olehigh.edu.
de riesgo, como intentar producir un sistema con
tecnología o personal inadecuados. Sin embargo, puede aumentar
otros; por ejemplo, que el sistema no proporcione la
funcionalidad necesaria o que el comprador pase a depender
del proveedor para recibir asistencia en el futuro.
Analizamos los distintos componentes del riesgo en la
compra de software y, a continuación, nos centramos en el riesgo
de que el software no funcione correctamente en el entorno
del usuario. Un estudio de caso demuestra cómo la
metodología formal para evaluar el riesgo de fallo puede
integrarse en las decisiones relativas a la compra e
instalación de software.

Palabras clave: Adquisición de software; Riesgo de fallo;

Riesgo de funcionalidad; Implantación; Gestión de riesgos;
Selección de software; Pack- aged software

Susnn A. Sherer es profesora

adjunta de Gestión en la
Universidad de Lehigh. Es doctora
en Ciencias de la Decisión por la
Wharton School de la Universidad
de Pensilvania, máster en
Investigación Operativa por la

1. Introducción
La compra de Softwarc se ha convertido en
una alternativa atractiva al desarrollo interno.
Proporciona economías de escala al tiempo
que altera el perfil de riesgo del proyecto de
implantación 14].
Las empresas de software especializado
responden a la demanda de competencias
difíciles de encontrar y mantener en los
departamentos de SI. Ante la creciente
demanda, los responsables de SI pueden
reducir los retrasos internos con la compra de
software. La adaptación de este software suele
ser más rentable que el costoso desarrollo
interno, que puede retrasar el funcionamiento
útil de un sistema.
Aunque la compra puede reducir algunos
componentes de riesgo, como intentar un
proyecto con tecnología o personal
inadecuados, también aumenta otros
elementos de riesgo. Quizá el mayor sea el
incumplimiento de los requisitos del usuario, que
puede producirse cuando los clientes no
037S-7206/93/$06.00 O 1993 - Elsevier Science Publishers B.V. Todos los derechos reservados
conocen todos los cambios de sistema y
procedimiento necesarios para utilizar el sistema
de forma eficaz. Los compradores suelen
basarse en ejercicios en papel, testimonios de
clientes y documentación proporcionada por el
proveedor para tomar decisiones de compra [5].
No participan en las revisiones internas del
diseño, donde se pueden identificar posibles
problemas operativos. Adquirir un sistema
genérico en lugar de desarrollar uno a medida
puede suponer la pérdida de algunas funciones
que limiten la utilidad del sistema. Pero adaptar
el sistema genérico para proporcionar estas
funciones puede introducir nuevos riesgos. A
menudo, el comprador depende del proveedor
para obtener asistencia.
Los componentes controlables del riesgo
deben identificarse y medirse [1] para poder
gestionarlos eficazmente durante la
implantación [2]. En particular, el riesgo de
fallo, es decir, que el software no funcione
correctamente en el entorno del cliente.
- puede gestionarse cuando las decisiones de
selección e instalación se guían por la medición de
este
 Desarrollo Operación
Riesgo del proyecto Riesgo de fracaso
Riesgo técnico Riesgo funcional
riesgo. Aunque la evaluación del riesgo de fallo
Riesgo político Riesgo de rendimiento
también puede guiar el desarrollo y las pruebas Riesgo de cambio Riesgo
de mantenimiento Riesgo
de software interno [15], las decisiones de de adaptabilidad Riesgo
compra son únicas, porque implican adaptar los de portabilidad
Riesgo financiero
sistemas o adaptar los procedimientos para que se Riesgo
ajusten a estos sistemas. Además, la organización sistémico
Riesgo político
usuaria suele tener poca información sobre el
código y su desarrollo.

2. Riesgo de compra de software

La compra de software modifica la
importancia de los distintos elementos de
riesgo en el desarrollo y uso del software,
como se resume en la Tabla 1. La compra suele
reducir los elementos de riesgo que impiden el
desarrollo, pero puede aumentar los riesgos que
surgen durante el funcionamiento del sistema. La
compra suele reducir los elementos de riesgo que
impiden el desarrollo, pero puede aumentar los
riesgos que surgen durante el funcionamiento
del sistema.
Los riesgos de desarrollo que suelen
reducirse con la compra de software son:
riesgo del proyecto - el or- ganizador no puede
completar el proyecto a tiempo o dentro del
presupuesto, y riesgo técnico - el proyecto va
más allá de lo posible. Aunque puede haber
incertidumbre sobre el tiempo y el coste de
modificación del paquete [6], es más difícil
planificar y cumplir un calendario para un
esfuerzo de desarrollo completo que
simplemente instalar un sistema desarrollado.
El riesgo técnico se reduce porque los
desarrolladores suelen tener más experiencia
con tecnología especializada.
El riesgo político -el desarrollo o uso
obstaculizado por la política de la organización-
puede aumentar con el software adquirido si el
grupo interno de desarrollo de sistemas percibe
la adquisición como una amenaza para su
subsistencia. Este riesgo puede gestionarse
implicando al personal en la toma de decisiones
y demostrando las ventajas del software
adquirido.
Riesgo de fallo: que el sistema no funcione
correctamente en el entorno del usuario; puede
deberse a un riesgo de funcionalidad: que no se
cumplan los requisitos.
Cuadro 1
Componentes de riesgo en el desarrollo y uso de software.
 ïn/ormoiioii y Gestión posible que ya no sea capaz de mantener,
adaptar o transferir internamente el sistema.
los requisitos del usuario o el riesgo de el sys.em.
El riesgo financiero (que el sistema no genere
rendimiento - inadecuan la calidad del software.
el rendimiento de la inversión previsto) sólo
Dado que el software adquirido puede tener una
puede reducirse con la compra de software si
base de clientes, es probable que tenga menos
el cliente comprende realmente los requisitos
errores, lo que reduce el riesgo de rendimiento.
Pero el riesgo de fallo sólo se reduce si los de personalización e integración y puede
usuarios comprenden realmente cómo calcular con precisión el esfuerzo necesario para
funcionará el sistema propuesto. El prototipado instalar el sistema en el nuevo entorno.
interno ha disminuido la ventaja tradicional del
software comprado: la previsualización del
funcionamiento del sistema permite una
identificación y validación más concrète de
los requisitos del usuario (11). a menudo es
más difícil relacionarse con el funcionamiento
previsualizado de un sistema comprado,
especialmente si el entorno es muy diferente.
Además, revisar un paquete de software
terminado es más caro que un proto-tipo [101. El
riesgo de funcionalidad aumenta si el software
no satisface todos los requisitos del usuario.
Dado que los paquetes de software genéricos
pueden no hacerlo, es posible que los usuarios
tengan que enfrentarse a un sistema que no
satisface todas sus necesidades, lo que
aumenta el riesgo de funcionalidad. La
adaptación de la aplicación para satisfacer
necesidades específicas puede hacer que la
empresa sea más vulnerable a un
funcionamiento incorrecto que si el software
se hubiera desarrollado internamente, lo que
aumenta el riesgo de rendimiento. La compra de
software afecta a todos los riesgos asociados a
la necesidad de cambiar el software a medida
que se utiliza: riesgo de mantenimiento: el
sistema no se puede mantener
adecuadamente; riesgo de adaptabilidad: el
sistema no se puede mejorar o cambiar; y
riesgo de portabilidad: el sistema no se puede
transferir a diferentes configuraciones. La
compra establece nuevas relaciones de
cooperación, lo que introduce riesgos de
rentas apropiables y de pérdida de control de
los recursos [3]. Si el vendedor mantiene el
software, el riesgo de rentas apropiables [7]
se produce si el vendedor intenta renegociar
el contrato de forma oportunista, aumentando
el coste de mantenimiento o negándose a
prestarlo. Dado que la conversión a otro
sistema suele conllevar un elevado coste de
cambio, la relación puede dar lugar a un riesgo
de transacción sustancial y a la dependencia
del proveedor. Además, si el comprador deja
que se atrofien los conocimientos técnicos
necesarios, pierde el control de la fuente y es

El riesgo sistémico se produce cuando el
entorno cambia, causando una pérdida de valor
del sistema por una respuesta competitiva,
reglamentaria o interna. La guerra blanda
puede alterar la naturaleza competitiva de la
industria si el vendedor de software obtiene
información privada que se utiliza para alterar
la base de la competencia.
debe considerar explícitamente qué puede salir
mal al utilizar el software para medir su riesgo o
fracaso en el entorno propuesto. Para evitar los
elevados costes y retrasos asociados al
cambio de paquetes de software, los clientes
suelen modificar los proce-

3. Decisiones de compra de software

Aunque todos los componentes del riesgo

deben gestionarse activamente a la hora de
adquirir software, nosotros nos centramos en la
consideración del riesgo de fallo, a menudo
un componente implícito de las decisiones de
compra e implantación de software. A la hora
de seleccionar sistemas, deben analizarse
tanto los costes como los beneficios (17). El
sistema seleccionado no sólo debe satisfacer las
necesidades del usuario, sino que debe ofrecer
un riesgo mínimo de fallo en la nueva
instalación. Los procedimientos de
implantación adecuados gestionan este riesgo.
Las capacidades funcionales deben analizarse
en el contexto del entorno empresarial en el que
operará el sistema. Si el software no cumple gran
parte de los requisitos, la cus- tomización e
integración podría requerir casi
El mismo nivel de esfuerzo necesario para
desarrollar el sistema internamente. La revisión
del sistema en funcionamiento en otras
instalaciones puede indicar la compatibilidad con
el nuevo entorno. Los requisitos deben
revisarse, asegurándose de que se ajustan a
la tecnología existente o verificando que la
tecnología puede ampliarse para dar cabida al
software.
Los métodos formales, como los modelos
de puntuación o las valoraciones ponderadas,
pueden utilizarse para elegir entre sistemas de
software competidores. Por lo general, estos
métodos se centran en lo que puede hacer el
sistema propuesto, si cumple los requisitos del
usuario y cómo puede mejorar las capacidades
de la organización. Los componentes de riesgo
pueden ponderarse o las preferencias de riesgo
pueden incorporarse a las funciones de
utilidad [18]. Pero aunque estos métodos
incorporan actitudes de riesgo, no miden
explícitamente la pérdida esperada asociada a
un componente de riesgo.
La evaluación de los sistemas propuestos
 módulos de un sistema de software, para
para reducir las discrepancias entre el paquete y orientar las decisiones de implantación del
las necesidades del usuario [9]. El riesgo de sistema.
fallo asociado a estas modificaciones puede
servir de base para elegir entre sistemas
competidores. 4.I. Evaluador de la exposición externa
La planificación de la instalación sigue a la
adquisición del software. Si el software va a Esto requiere la identificación de todos los
sustituir a un sistema existente, la empresa peligros, o condiciones que conducen a la
tiene varias opciones: puede instalarse en
paralelo con el sistema existente o puede pérdida, que pueden ocurrir cuando un
simplemente sustituir al antiguo: una
instalación "en frío" o "big bang" del nuevo
sistema. En algunos casos, puede ser factible
una pequeña aplicación piloto del nuevo
sistema, lo que puede resultar especialmente
atractivo en el caso de un sistema que ofrezca
funciones completamente nuevas.
Las decisiones de instalación deben tener en
cuenta tanto el coste como el riesgo de fallo.
El sistema paralelo es costoso y difícil de
mantener; a menudo es difícil discernir si los
nuevos resultados son más precisos. Sin
embargo, una instalación "en frío" puede
colocar a la empresa en una posición de riesgo
inaceptable si el sistema no funciona
correctamente. Las pruebas son
especialmente importantes en este tipo de
implantación. Una pequeña aplicación piloto
puede no provocar los cambios ambientales
necesarios para probar el riesgo de fallo del
sistema completo.
Dado que el software puede tener errores
latentes, una consideración clave es el
tiempo necesario para poner en marcha un
sistema piloto o paralelo o realizar pruebas
en la nueva instalación. Esta decisión debe
tener en cuenta el coste de las pruebas
continuadas y los retrasos, así como el riesgo.
La continuación de las pruebas estaría
justificada si el riesgo de fallo fuera superior
al coste. Sin embargo, un software con un
riesgo mínimo puede no justificar el coste de
pruebas adicionales o de un funcionamiento
paralelo.

4. Evaluación del riesgo de fracaso

Esto comienza con la estimación de la

exposición externa, la magnitud de la pérdida
que podría producirse cuando se utiliza un
sistema. Estas evaluaciones pueden orientar la
selección del sistema y proporcionar la base
para medir el riesgo de fallo de los módulos [16],
la pérdida esperada debida a un fallo en los
 el número esperado de fallos resultantes de
esos fallos:
se instala el sistema. Cada instalación tiene un R T) -- E"( T) NM ( T) ,
entorno único, con su propio personal y
procedimientos. Además, los sistemas alternati
Funciones diferentes
métodos. Éstos pueden dar lugar a escenarios
de accidente y modos de fallo únicos que
provoquen peligros. Por ejemplo, algunos
sistemas tienen controles más amplios o
funciones de auditoría que pueden alterar la
posibilidad de pérdida por entrada no válida.
La selección del sistema de software debe
incluir un análisis externo del uso previsto del
sistema en el entorno propuesto; un análisis que
se centre en lo que puede salir mal. Este
análisis debe incorporar tanto el "análisis de
varianza" [12], que se centra en los puntos
débiles del sistema que se producen al integrar
las partes técnicas y sociales del sistema, como
el "análisis de futuro" {8], que predice los
cambios que se producirán y su impacto en el
sistema. El análisis debe identificar todas las
acciones que pueden pre cipar peligros y
evaluar su probabilidad de ocurrencia. El
evaluador de riesgos debe analizar a fondo el
entorno y el sistema. La incapacidad para
identificar todos los peligros o modos de fallo
puede, por supuesto, dar lugar a una evaluación
subestimada de la exposición.
La magnitud de las pérdidas que pueden
derivarse de acciones inadecuadas depende
del entorno y del contexto en el que funciona
el sistema. Dado que prácticamente existe un
número ilimitado de factores medioambientales
que pueden afectar a la pérdida, la información
se consolida utilizando valores esperados para
cada condición que define el entorno del
comprador y la aplicación concreta.
La evaluación de la exposición externa
proporciona estimaciones de la pérdida
potencial asociada a cada peligro j durante el
tiempo operativo T, L ¡[T'. Éstas diferirán para
cada instalación y sistema y pueden servir de
base para su selección.

4.2. Riesgo de fallo del módulo

Se trata de una estimación de las pérdidas

potenciales que podrían derivarse de fallos en
los componentes de un sistema. Se calcula como
el producto de la exposición del módulo, la
pérdida potencial debida a fallos que podrían
resultar de fallos en un módulo de software y
 Información '£ Gestión
donde It"(r)= riesgo de fallo durante el tiempo
natural T del módulo M, £"(T) = exposición
debida al mod- ule 3f durante el tiempo
T, N't T) - número esperado de fallos debidos a
fallos en el módulo Af durante el tiempo T.
4.2.1. Exposición del módulo
dicha salida. Mediante la ingeniería inversa de
las funciones específicas, se revelan elementos
de datos críticos relacionados con esta salida,
lo que permite al equipo de sistemas determinar
qué módulos podrían estar implicados en la
producción de la salida. La distribución de
probabilidad condicional de estos riesgos
puede asignarse uniformemente o en función
de la gravedad relativa de los distintos
riesgos.

Una vez adquirido un nuevo sistema, el equipo

interno de sistemas de información suele
revisar las especificaciones antes de su
implantación. Esta revisión debe estructurarse con
el objetivo de comprender el riesgo de fallo de
los módulos individuales. Tanto la función del
módulo como su uso previsto están relacionados
con el análisis de la exposición externa. La
exposición puede expresarse como:

donde p(t/,^) = probabilidad de que el módulo M

tenga un uso i, p(Nj/t/,'f)- probabilidad de que
el peligro y ocurra cuando el módulo tiene un
uso i.
La función del módulo en cualquier
momento, y el
nivel de exposición asociado, podría variar en
función de la forma en que se utilice el sistema;
esto, a su vez, está relacionado con la forma
en que se utiliza el propio sistema. Las
estimaciones del uso previsto de las distintas
funciones del sistema por parte del cliente
proporcionan la base para la distribución de
uso del sistema. La distribución del uso del
módulo, p(U^), se obtiene relacionando la
función de un módulo con el uso del sistema.
Dado que cada cliente puede utilizar un sistema
adquirido de forma diferente, el uso del módulo y,
por tanto, la exposición diferirán en cada
instalación.
Para calcular la distribución de probabilidad
de peligro condicional, p(H j/ U;*), es necesario
determinar primero qué escenarios de peligro
pueden derivarse de fallos en cada módulo. Se
identifican los fallos de software que pueden
dar lugar a acciones que provoquen los peligros.
Dado que los fallos de software dan lugar a
una salida no válida del sistema o a la falta de
la salida prevista, los fallos en un módulo
podrían causar o efectuar un peligro si el
módulo está implicado en la producción de
Gestión de la información 8

4.2.2. Nuziiber previsto de fallos 5. Estudio de caso

El número esperado de fallos derivados de fallos
en un módulo puede calcularse con un modelo de
fiabilidad de software [13]:
dondep = número medio de fallos en tlie
módulo, t9 = tasa de fallos por fallo, la
probabilidad de que un fallo cause un fallo
por unidad de tiempo de CPU, i i T) -- tiempo
de CPU durante los periodos operativos T.
Este modelo requiere estimaciones del
número de fallos y de la probabilidad de que un
fallo provoque una avería: parámetros que
dependen de las características del módulo y
de su desarrollo. Esta información puede no
estar disponible para el software adquirido. Los
clientes pueden obtener los registros de
informes de problemas de software de los
remitentes para obtener estimaciones iniciales,
pero los vendedores pueden no estar
dispuestos a proporcionar esta información o
pueden no estar dispuestos a hacerlo.
proporcionan parámetros demasiado optimistas. Otros en" organización de ahorro y
préstamo
Se pueden utilizar los registros de informes de
problemas de las instalaciones para generar las
primeras estimaciones o información sobre productos
similares. A medida que se obtiene información sobre
las pruebas, estos parámetros se actualizan
con análisis bayesianos.
La evaluación del riesgo de fallo operativo
puede orientar la asignación de esfuerzos de prueba
y formación durante la instalación, garantizando que
los componentes del sistema de alto riesgo del
cliente se prueben a fondo y que los usuarios
reciban formación sobre los procedimientos
relacionados con estos componentes. Aunque las
pruebas y la formación pueden ser costosas, en
general reducen el riesgo de fallos. La cantidad
óptima de pruebas, la cantidad de tiempo de
prueba que maximiza la reducción del riesgo de fallo
menos el coste de las pruebas (suponiendo que no se
obtiene ningún beneficio del uso temprano de un
software mal probado), es: '
El uso de la evaluación del riesgo de fracaso
para determinar la compra de software se
ilustra ahora con un estudio de caso sobre la
adquisición y archivado de un sistema de
préstamos comerciales, una asociación de
ahorro y préstamo. Tras describir los
procedimientos de selección tradicionales, se
analiza la forma de complementar las
decisiones con estimaciones de exposición. A
continuación se explica cómo se instaló el
sistema y se concluye con ejemplos que
ilustran cómo las estimaciones de riesgo
pueden guiar las pruebas y la implantación.
5.I. Adquisición del sistema de préstamos
comerciales
Antes de principios de los 80, las cajas de
ahorros se limitaban a conceder hipotecas a
tipo fijo y a largo plazo, financiadas con
depósitos a corto plazo. En
1983, la desregulación propició un entorno
para ajustar su kadi-
casos de prueba, x2 =Coste de encontrar y
eliminar el fallo que provoca la avería.
Esta información puede orientar los planes de
pruebas e implantación.
Se obtiene diferenciando el beneficio neto del reposo, la
reducción del riesgo menos el coste de las pruebas:
(h"(T)p[1 - exp[- Or T)j + ezp\-O-[r + its)) - exp( - Or))} -
(K;i + R,p{l - esps - T)\1. Se supone que los costes son
una función del tiempo de prueba y del número
esperado de fallos.

donde A, = coste de ejecución y análisis de los

tional ampliando su producto, es decir, a
incluyen préstamos con vencimientos más cortos.
First Savings and Loan2 creó su departamento
de préstamos a empresas comerciales en 19:*,
adquiriendo un sistema de información básico
para controlar sus préstamos de estructura
sencilla. En los años siguientes, se expandió
rápidamente mediante una agresiva política de
adquisiciones y la entrada en nuevos mercados.
Los índices de producción de préstamos
crecieron de
3 a casi 20; el negocio de préstamos
comerciales creció hasta incluir más del 10%
de todos los préstamos en 4
años. Este rápido crecimiento empezó a poner a
prueba las capacidades del sistema de
información de préstamos. Además, los cambios
en el entorno externo obligaron a modificar los
sistemas de información. Por ejemplo, se
produjo un cambio significativo en el método
de contabilización y presentación de informes
tanto de los ingresos f-e de la originación de
préstamos como de los costes de originación
relacionados '.
First Sat'ings and Loan reconoció la necesidad
de
implantar un sistema mejorado que permita
prestar con mayor eficiencia y eficacia los
servicios comerciales a los clientes, así como
un control e información más exhaustivos de la
gestión. El sistema tendría que mantener toda
la información

Se han facilitado nombres ficticios para proteger la

confidencialidad de los participantes en este estudio.
' Este cambio se inició con la adopción de la Norma de
Contabilidad Financiera nº 91.
 coste de desarrollo interno.
En primer lugar, Sat'ings y Loom llevaron a cabo
una investigación muy cuidadosa y exhaustiva
a('uut nuevas cuentas. prestatarios, líneas,
sobre cómo el sistema propuesto z'odería
compromisos, préstamos. retiradas, renovaciones,
cumplir los requisitos identificados. El análisis
participaciones, sindicaciones. calendarios de
formalizado se centró en cómo cumpliría el
amortización, pasivos indirectos. calendarios de
sistema los requisitos específicos. Aunque se
intereses y comisiones, garantías y
consideraron de manera informal, ni el análisis
operaciones de pago. Para ofrecer un mejor
de riesgos explícito
servicio, la información sobre prestatarios,
préstamos y garantías debería mantenerse
en línea para que los gestores de préstamos
pudieran acceder a ella inmediatamente.
La tarea inicial de determinar los requisitos
del nuevo sistema se asignó a un grupo de
aproximadamente 10 personas, formado por
personal de la oficina central y de campo y
desarrolladores de sistemas. El grupo de trabajo
elaboró una lista de requisitos en las seis áreas
siguientes: contabilidad y operaciones de
préstamos, estructuras de préstamos,
mantenimiento de registros de garantías,
controles de auditoría y seguridad, informes de
gestión y capacidades de consulta remota. Por
ejemplo, los requisitos de contabilidad y
operaciones de préstamos incluían la facilidad
de establecimiento de nuevos préstamos, un
número reducido de pantallas, la posibilidad de
traspasar información de cuentas comunes, la
verificación completa de la edición de todos
los elementos introducidos, calendarios de
facturación flexibles y múltiples opciones de
transacción.
El grupo de trabajo elaboró un cuestionario
para responder a estas preguntas. En primer
lugar, Sai iitgs und Loan identificó cinco
productos de software disponibles en el
mercado. Todos ellos pertenecían a empresas
con más de un año de actividad y más de 50
empleados de asistencia técnica; cuatro tenían
al menos 25 instalaciones. La antigüedad de
los sistemas oscilaba entre "nuevo" (menos de
1 mes) y 17 años. El número de módulos de
programa de estos sistemas oscilaba entre 200 y
800. Utilizando sus cuestionarios como base
para las entrevistas telefónicas, la empresa
obtuvo información sobre cada uno de los
puntos de su lista de requisitos. Cada
sistema se calificó en función de estos
requisitos. Además, se elaboró un resumen de
los principales puntos fuertes y débiles de cada
uno de ellos.
Basándose en los resultados de las
calificaciones, el
recomendó el sistema de Fi- nancial Software Inc.
(FSI). El coste de adquirir este sistema y
adaptarlo a las necesidades era inferior al
 Itt(orinaiioii 8- Gestión de cada uno de los sistemas en liza. Aunque
son subjetivas, incorporan hipótesis razonables
Cuadro 2 sobre el funcionamiento y el comportamiento
previstos. En primer lugar, el interés medio
Riesgos del sistema de préstamos comerciales.

No presentar mensual se estimó en 2,4 millones de dólares. Se

facturas ln-'alid supuso que existía una probabilidad del 109% de
intereses
que los clientes no alertaran a la entidad de
Comisiones no
válidas ahorro y préstamo si los cargos por intereses
Seguimiento incorrecto de los pagos eran incorrectos. Se partió de la base de que los
Acceso inválido a la información financiera cobros excesivos darían lugar a problemas de
Exceso de dólares comprometidos atención al cliente;
Garantía insuficiente
Contabilización errónea de iransacliones en
el Libro Mayor Problemas de servicio al
cliente
Ni gestionar la documentación colateral
Trabajo administrativo adicional
Informes gubernamentales no válidos

ni se tuvo en cuenta lo que podía salir mal al

utilizar cada sistema.

5.2. mejorar las decisiones de adquisición de

software mediante la evaluación de la exposición

La evaluación de la exposición externa

obliga a considerar explícitamente el uso
externo del sistema propuesto y sus peligros
asociados, información que puede
complementar el análisis de la capacidad de
un sistema para cumplir los requisitos
funcionales.
En el First Savings and Loan se identificaron
los principales riesgos en el sistema de
préstamos comerciales. Éstos se resumen en
el cuadro 2. Las diferentes características
ofrecidas por los sistemas alternativos
propuestos cambiarían el procesamiento
externo y los procedimientos utilizados por el
personal de préstamos. Por lo tanto, la
exposición externa a cada uno de estos riesgos
potenciales sería diferente. Las variaciones
en los informes de auditoría y las pantallas de
consulta que ofrecen los sistemas contribuyen
a las diferencias en la exposición externa. Las
diferencias en los procedimientos de
formación necesarios afectan a la exposición.
La evaluación de la exposición externa de cada
sistema a cada riesgo puede ayudar al cliente a
seleccionar un sistema que minimice dicha
exposición.
Para ilustrarlo, consideremos el peligro
"interés no válido". Se han hecho varias
suposiciones para elaborar las estimaciones
Informaiiun S Maiia$''inetii Evaluaciones comparativas de la exposición al peligro:
"inter-est inválido".
La pérdida de intereses se debe a una Exposición
facturación insuficiente. En el s i s t e m a FSI, un $/mes
gestor de préstamos introducía los intereses, los
tipos efectivos y los códigos de devengo de
intereses, mientras que un empleado de control
de entrada de préstamos introducía y mantenía
los calendarios de tipos de interés. Si no se
introducían estos datos, el sistema aceptaba un
préstamo pero no facturaba los intereses. El
personal era responsable de reconocer que los
intereses devengados eran erróneos a partir de
la información incluida en los informes de
auditoría masiva. Esto llevó a suponer que la
falta de calendarios de devengo provocaría que
los intereses no se facturaran el 10% de las
veces (pérdida prevista de 24.000 $). Los costes
para cubrir los problemas de atención al cliente
derivados de los intereses cobrados de más se
estimaron en 3.000 dólares (0,01% de las
facturas mensuales medias más el esfuerzo
administrativo adicional). La pérdida por
intereses de demora se estimó en 2.000 $ (50%
de las cuentas a 29r/año). La estimación de la
exposición resultante de este riesgo para el
sistema FSI en First Savings and Loan fue de
29.000 $/mes.
La exposición de los sistemas alternativos
difiere porque los requisitos de procesamiento y
las funciones del sistema para los devengos de
préstamos difieren, lo que cambia la
probabilidad de que se cometan errores
externos. La tabla 3 compara las estimaciones
de exposición de los sistemas alternativos
para este riesgo. Los gestores de préstamos
que utilizaran la alternativa 1 tendrían que
introducir una cantidad considerable de
información adicional sobre las estructuras de
los préstamos. Esta información se obtendría
de manuales de préstamo independientes en
lugar de incorporarse a la lógica del sistema.
Había muchas más probabilidades de que los
gestores de préstamos o el control de entrada
de datos introdujeran información no válida o
se olvidaran de introducir los esquemas de los
préstamos. La estimación del riesgo era de 48.000
dólares, suponiendo una probabilidad del 15%
de que faltaran calendarios de devengo (36.000
dólares); 7.000 dólares para cubrir los problemas
de servicio derivados de las correcciones; y 5.000
dólares de pérdidas potenciales de intereses
por cobros insuficientes.

Cuadro 3

... El riesgo principal, que tuvo una
exposición muy diferente en los cinco sistemas,
fue el de "exceso de anticipos en dólares
concedidos". Esto significa que los clientes
reciben anticipos que superan su límite de
crédito. Dado que los compromisos de
préstamo se realizan en distintos niveles de
una organización (por ejemplo, corporativo,
departamento), se necesitaban vínculos para
poder supervisar los compromisos totales. Un
sistema exigía un gran esfuerzo manual por
parte de los gestores de préstamos para
identificar estos vínculos. El resultado era una
exposición externa muy elevada. Un sistema que
utilizaba participaciones, afiliaciones y pasivos
indi- rectos para establecer los vínculos
requería una formación adicional de los
agentes. La exposición externa era alta, porque
se necesitaba una formación más amplia y los
procedimientos de formación continua estaban
tradicionalmente mal instituidos y ejecutados en
esta organización. Un tercer sistema contaba
con punteros a través de los niveles
organizativos para establecer vínculos de
préstamos, lo que reducía la exposición debido al
mínimo procesamiento manual. Cada sistema
evaluaba de forma diferente el riesgo de "no
Sistema $29,000
FSI 48.000
Alternativa 1 33,800
Alternativa 2 29.500
Alternativa 3 24,200
A1ternatix'e 4
presentar facturas". Varios sistemas exigían
que los impagos se establecieran manualmente,
lo que aumentaba la exposición; otros incluían
diferentes impagos automáticos, cada uno con
diferentes exposiciones. Mientras que algunos
sistemas tenían frecuencias de pago fijas, otros
tenían calendarios superpuestos que afectarían
al ciclo de facturación y al tratamiento externo.
Algunos sistemas calculaban el importe facturado
al cliente; otro facturaba sólo el importe de
pago en un registro de pagaré; mientras que
otro facturaba un porcentaje fijo del saldo
pendiente. La evaluación de la exposición externa
obligó a considerar cómo afectarían estas
diferencias a la facturación.
fecto tratamiento externo.
La evaluación de la exposición externa requiere
considerar cómo cambiará el entorno. First
Savings and Loan tenía previsto iniciar en el
futuro la contabilización directa en su libro
mayor. Se analizaron los distintos
procedimientos requeridos por cada sistema
para llevar a cabo esta tarea con el fin de
determinar cuál minimizaría la exposición
externa debida al peligro identificado,
"contabilización errónea de transacciones en
el libro mayor". Una de las alternativas estaba
mucho más expuesta a este riesgo que las
demás, ya que la interfaz era la siguiente
no suministrado con el sistema.
Las comparaciones de la exposición total del
sistema pueden complementar las
clasificaciones de requisitos para seleccionar
un sistema. Si la elección no es evidente, el
análisis de sensibilidad puede determinar qué
cambio en las estimaciones de exposición
264 Reseercii
pueden alterar las decisiones y, a continuación,
concentrarse en obtener información adicional
que respalde estas estimaciones. En este
caso, el sistema FSI tenía una de las
exposiciones totales más bajas; su capacidad
funcional lo hacía más deseable que otro
sistema con una exposición ligeramente
inferior.
5.3. Implantación del sistema de préstamos
comerciales
El sistema se implantó en First Savings and
Loan en 1987. Durante la planificación de la
implantación se elaboraron procedimientos
de prueba y planes de formación. El sistema
se probó durante un periodo de implantación
de tres meses, seguido de un mes de
funcionamiento en paralelo con el sistema
existente. Debido a los problemas que surgieron
durante el primer mes de funcionamiento
paralelo, la dirección aprobó un segundo mes
de pruebas paralelas, tras el cual el sistema
pasó a ser totalmente operativo. Durante los
ocho primeros meses de funcionamiento, se
detectaron 34 problemas que requirieron
correcciones en 21 módulos.
Se elaboraron programas de formación
para el personal de la oficina principal y de
préstamos. El personal de la oficina de
préstamos recibió formación para introducir
tipos específicos de préstamos y responder a
las consultas de los clientes. El sistema FSI
ofrecía muchas posibilidades (por ejemplo,
estructuras de préstamo alternativas) que no
estaban previstas para su uso inmediato; la
información relativa a estas funciones se facilitó
en manuales. El personal de la oficina principal
recibió formación sobre la introducción y
verificación de datos.
Cuadro 4
Riesgo del módulo y tiempo de
prueba óptimo. Nº previsto
Módulo Exposición de fallos en 1
3f ($/mes) mes
E'(TI N"(T)
10 1800 0.015
21 1438 * 0.009
111 21 0.000
164 621 0.001
1040 1287 0.008
Gestión de la información
El tratamiento de las excepciones se describía en
los manuales de introducción de datos.
5.4. Mejorar las decisiones de implantación de
sistemas con la evaluación de riesgos
¿Cómo debe instalarse el nuevo
sistema? ¿Dónde debe centrarse el
esfuerzo de las pruebas? ¿Cuántas pruebas
son necesarias? ¿Qué tipo de formación se
necesita? Estas preguntas son especialmente
difíciles de responder cuando se adquiere
un sistema, porque la organización tiene poca
experiencia con el software.
El tipo de implantación (paralela, piloto, "en
frío" o "a lo grande") depende del tipo de
sistema, el coste de la instalación y el riesgo de
fallo. En todos los casos es necesario realizar
pruebas, ya que el sistema funciona en un
nuevo entorno. Normalmente, se trata de
pruebas funcionales más que estructurales.
Las pruebas funcionales utilizan las entradas
del sistema para desarrollar casos de prueba,
mientras que las pruebas estructurales utilizan
la estructura interna del programa. La
decisión de detener las pruebas se toma
cuando el gestor considera que las funciones
se han probado adecuadamente o cuando
llega la fecha límite para el cambio al nuevo
sistema. La evaluación de riesgos del módulo
debe utilizarse para probar la estructura del
sistema, de modo que las partes del sistema
con mayor riesgo de fallo puedan identificarse
y someterse a las pruebas adecuadas.
Calculamos el riesgo de fallo operativo para
mod-
Riesgo Tiempo de
($/mes) R prueba
^LTI óptimo
(CPU min)
i*
27 767
13 497
0 0
1 0
10 0
1070 1*04 0.016 29 1115
1150 1804 0.004 7 0
2300 1g79 0.616 1157 3892
2400 2575 0.921 2370 4268
2450 2573 0.021 54 1714
3500 1go4 0.433 781 3721
4600 50 0.208 10 0
* Véase el Apéndice ior detalle.
Información y ñfnnogemeni módulos o las funciones del sistema podrían
clasificarse por exposición, aunque faltara
ulas en el sistema FSI antes de la prueba información sobre la probabilidad de fallo.
[14]. La Tabla 4 contiene algunos ejemplos. La Por último, pueden desarrollarse
procedimientos de formación
información histórica sobre fallos se elaboró a
de las evaluaciones de riesgo. Los módulos
partir de los registros de informes de problemas
con mayor riesgo de fracaso deben ser objeto de
de ISi para sistemas similares. El número de
un seguimiento más estrecho. Por ejemplo, la
fallos y las tasas de fallo por fallo encontradas
formación debe centrarse en
en estos módulos se utilizaron para estimar el
número esperado de fallos en el sistema de
préstamos comerciales. El análisis de
estimación de la exposición se ilustra en el
apéndice.
Estas evaluaciones de riesgos podrían haber
orientado los planes de implantación, ensayo
y formación. El análisis respaldó la elección
de una instalación paralela. El riesgo de fallo
era considerable en varios módulos, por lo
que no era razonable una instalación "en frío".
Un pequeño lote de operaciones no podría
probar un volumen adecuado de transacciones
a través de los módulos de alto riesgo, todos los
módulos de grandes lotes que procesan una
variedad de tipos de transacciones financieras.
Lo más deseable era una implantación en
paralelo, pero ¿cuánto tiempo debía durar?
Se determinó la cantidad óptima de tiempo
de prueba para cada uno de los módulos.
Sólo tres de los aproximadamente 135
módulos requirieron extensas pruebas
adicionales, aproximadamente 4000 minutos de
CPU. Algunos módulos no necesitaron
pruebas adicionales porque su riesgo de fallo no
justificaba el coste de las pruebas. Sin embargo,
dado que esta información se basaba en
parámetros de fallo de- rivados de módulos
de sistemas similares, se validó mediante
pruebas preliminares de todos sus módulos en Ff
"YSt Savings and Loan. El análisis de sensibilidad
puede incorporarse evaluando el grado de
cambio en cada uno de los parámetros que
alteraría la decisión de poner fin a las pruebas.
La capacidad de utilizar estos métodos en
una fase temprana del
El esfuerzo de implantación depende de la
disponibilidad de datos. Si no se dispone de
datos de fallos de la sede, se utilizarían
inicialmente datos de probabilidad más
genéricos, pero los resultados tendrían que
validarse con datos de pruebas de la nueva
sede antes de poder utilizar la información para
centrar los esfuerzos de pruebas posteriores.
En los casos en los que el software adquirido
se suministra sin documentación técnica de los
sistemas, puede resultar difícil obtener
estimaciones de riesgo específicas. Los
 Referencias

B. Boehm. Software Risk Management, IEEE Computer

Procedimientos para revisar los informes de
auditoría que incorporan los resultados de los
módulos de alto riesgo de fallo.
Society Press, 1989.
[2] E.K. Clemons. "Evaluation of Strategic Investments in
Information Technology", Communications of the
ACM (34,1), enero de 1991, pp. 22-36.
[3]E.K. Clemons y M.C. Row. "Information Technology

and Industrial Cooperation", Documento de trabajo,

El creciente uso de software adquirido conlleva Departamento de Ciencias de la Decisión, Wharton
riesgos únicos derivados de la necesidad de School, Universidad de Pensilvania, 1990.
perfeccionar e integrar el software existente en [4] E.K. Clemons, B.W. Weber, D. Brennen. "Componentes
un nuevo entorno. El conocimiento del riesgo de
fallo del software puede orientar la adquisición
e implantación del sistema.
Hemos utilizado un estudio de caso para
demostrar cómo
Las decisiones de compra de software
importantes pueden guiarse por la evaluación
del riesgo de fallo. Mientras que los enfoques
tradicionales para la selección de software evalúan
las capacidades y limitaciones de un sistema
propuesto, la evaluación de riesgos hace
hincapié en cómo los sistemas propuestos
contribuyen a los peligros en el entorno del cliente.
Aunque esta información puede complementar los
procedimientos de selección tradicionales, también
puede revelar futuras dificultades operativas y
fuentes de riesgo en un sistema seleccionado. El
análisis explícito del uso operativo y los peligros es
la contribución más significativa de los
procedimientos de evaluación de riesgos a la
compra de software.
La evaluación de riesgos de los módulos
puede orientar los esfuerzos de implantación al
centrar la atención en aquellas partes de un sistema
que plantean el mayor riesgo en una nueva
instalación. Puede ayudar a determinar la
cantidad de pruebas necesarias, así como los
planes de instalación y formación.

Agradecimientos

El autor agradece los comentarios del

profesor Eric K. Clemons.

of Risk in Strategic IT i'rograms: Implications and Risk
Management", Proceedings of the Conference on
Strate- gic Information Architectures, Wharton School,
Univer- sity of Pennsylvania, 1990.
[5]I. Gershkoff. "El juego de hacer o comprar",
Datamotion,
ifi de febrero de 1990, pp. 73-77.
{6] P. Gross y M.J. Ginzberg. "Barriers to the Adoption of
Applimtion Software Packages", Systems, Objectives,
Sofiitiozts (4, 4), 1984, pp. 211-226.
(7] B. Klein, R.G. Crawford, A.A. Alchian. "Vertical Inte-
gration, Appropriable Rents, and the Competitive Con-
tracting Process", Journal of Law and Bwiness (21, 2),
pp. 297-326.
[8] F. Land. "Adaptación a las necesidades cambiantes de
los usuarios",
Infomiotion and Management (5, 2), 1982, pp. 59-75.
(9] H.C. Lucas, E.J. Walton, M.J. Ginzherg.
"Implernentine Packaged Software", MIS Oman.-rly
(12, 4), diciembre l98ß, pp. 537-549.
(10] R. Lynch. "Implantación de paquetes de aplicaciones
Soft-
ware: Costes ocultos y nuevos retos, Sistemas, Objec-
tii'es, Soluciones (4, 4). Noviembre de 1984, pp. 227-234.
[I I] M.A. Mahmood. "System Development Methods - A
Comparative Investigation", MIS Ouanerlv.
Septiembre de 1987. pp. 293-311.
[12) E. Mumford y D. Henshall. Designing Participatieely,
Manchester Business School, 1983.
[13] J.D. Musa. A. lannino, K. Okumoto. Software Reliab
"dity: Measurement, Prediction, Apylicatton, McGraw Hill,
1987.
S.A. Sherer. "Measuring the Risk of Software Failure: A
Financial Application", Proceedings of the 10th Intema-
tional ConJerence on Information Systems, diciembre
de 1989, pp. 237-245.
(15) S.A. Sherer. "A Cost-Effektive Approach to Testing"
(Enfoque rentable de las pruebas),
IEEE Software, marzo de 1991, pp. 34-40.
Probabilidad
condicional de
Módulo Uso Peligro peligro
Distribución Consecuencia
M R{Qi\ Hg -AffjUiL-
Seguimiento incorrecto de los pagos
xi spostlnq t:o general ledqer
21-Pagos Servicio al
cliente
p=.7238
Esfuerzo administrativo
adicional
Informes gubernamentales no
válidos
Exposición .7238[(.167)(5300)+(.167)(1000)+(.167)(3000)
+ ( . 333) (8 00) + ( . 167) (1000) ]
= $ S438
Información y gestión
(16) S.A. Sherer y E.K. Clemons. "Methodology for Assess-
ing the Risk of Software Failure", Lehigh University
Martindale Center working paper 1989 Series #2.
[17] P. Shoval e Y. Lugasi. "Selección de sistemas
informáticos: The Graphical Cost-Benefit Approach",
Infomiatian and Management (15, 3), 1988, pp. 163-172.
[18] P. Shoval e Y. Lugasi. "Models for Computer System
Evaluation and Selection", Informahon and Management
(12, 3), 1987, pp. 117-129.
Anexo
La figura 1 ilustra la exposición estimada
para el módulo 21, un módulo de
introducción de datos en línea. Este módulo
sólo se utiliza para pagos; la probabilidad de
este uso se derivó de los números propuestos de
diferentes tipos de transacciones en First
Savings and Loan. Mediante ingeniería inversa
de las especifica-
los peligros relacionados con este módulo y el
uso
-z.ere determinada. El riesgo condicional proba-
Las distribuciones de la bilidad se basaron en la
gravedad
de estos riesgos identificados: los riesgos con
una exposición inferior a 1000 $/mes se
consideraron el doble de probables que los
riesgos de mayor exposición, ya que se
suponía que los desarrolladores prestaban
implícitamente más atención al desarrollo de
códigos de mayor exposición. Las
estimaciones de pérdidas se basaron en las
evaluaciones de exposición externa para el uso
del sistema FSI en First Savings and Loan.
Lig
.167 $5300
. 167 k000
. 167 3000
. 333 800
.167 1000
Fig. 1. Evaluación de la exposición para el módulo 21.