Harvard Business School

9-189-132
19 de enero de 1989

Gestión de la tecnología de la información:

desarrollo de sistemas
La dependencia que tienen las grandes organizaciones de la tecnología de los sistemas de
información (SI) para respaldar el procesamiento de la información y la toma de decisiones ha aumentado
constantemente desde la década de 1960. Para muchas empresas, la tecnología de la información
se ha convertido en un elemento fundamental de la conducción estratégica y la ventaja competitiva.
Los gerentes generales están descubriendo que tienen que adoptar un papel más activo en el desarrollo
y el mantenimiento de los sistemas de información con el fin de asegurar que estos sistemas brinden
la información que necesitan para gestionar sus negocios. La finalidad de este artículo es ofrecer a los
gerentes generales una idea básica sobre el proceso de desarrollo y mantenimiento de los sistemas, y así
mejorar su capacidad para gestionar este importante recurso corporativo.

Un sistema que se ejecuta en una computadora, así sea para administrar las cuentas por cobrar o
para reservar billetes de avión, es una entidad compleja. En muchos casos, los datos ingresan al sistema a
partir de una enorme variedad de fuentes y formatos. La información generada en un sistema informático
puede incluir miles de informes impresos y pantallas interactivas de la computadora, y los programas que
la generan con frecuencia contienen de miles a millones de líneas de código de lenguaje de programación,
a menudo organizadas en cientos de módulos de programas individuales. La implementación de un
sistema grande puede exigir un equipo de 50 personas que trabajen durante dos años o más. Durante
estos extensos procesos de desarrollo, las empresas siguen creciendo y cambiando y, en muchos de los
sistemas, la revisión comienza el día que comienza la codificación y continúa incluso después de poner
el sistema en línea.

Los problemas de los sistemas informáticos después de la implementación pueden ser diversos
y variados. Los cambios en una línea de código en un programa pueden tener efectos de gran alcance
y, en algunos casos, provocar errores que son difíciles de detectar e incluso más difíciles de corregir sin
introducir errores adicionales. Con los años, cientos de personas distintas pueden trabajar en un mismo
programa, lo que puede provocar que la familiaridad con el programa sea escasa. Si la computadora
donde se está desarrollando un programa queda obsoleta, esta puede sufrir averías frecuentes, lo que
afectaría la ejecución y el mantenimiento del programa. Lo que es peor, si el fabricante de la computadora
deja de operar, puede ser difícil, si no imposible, encontrar piezas o servicio.

Algo que complica aún más el panorama es la dependencia inevitable de la computadora. Una
vez que se instala un sistema informático, muchos grupos dentro de una empresa se vuelven cada vez más
dependientes de él para sus operaciones comerciales. Para algunos, la falla del sistema incluso durante
unas pocas horas puede llevar las operaciones a una detención alarmante. Un error desapercibido puede

El editor John Simon y el investigador asociado sénior Thomas Davenport prepararon este artículo para la discusión en clase.
Es una versión actualizada y revisada de un artículo de 1987 preparado por la profesora adjunta Lynda M. Applegate. Otros
artículos de la serie “Managing Information Technology” (Gestión de la tecnología de información) tratan sobre sistemas
y componentes informáticos (Servicios de casos de HBS n.º N9-189­130), redes de comunicación (n.º N9-189-131) y organización
y liderazgo (n.º N9-189-133).
Copyright © 1989 Presidente y asociados de Harvard College. Para realizar un pedido de copias o solicitar
permiso para reproducir materiales, llame al 1-800-545-7685, escriba a Harvard Business Publishing,
Boston, MA 02163 o diríjase a http://www.hbsp.harvard.edu. Ninguna parte de esta publicación puede
reproducirse, ni almacenarse en un sistema de recuperación, ni utilizarse en una hoja de cálculo, ni
transmitirse mediante ninguna forma o medio, ya sea electrónico, mecánico, en fotocopias, grabación ni
de ninguna otra forma, sin el permiso de Harvard Business School.

1
189-132 Gestión de la tecnología de la información: Desarrollo de sistemas

costarle millones de dólares de ingresos a una empresa. Muchas empresas se ven frente al dilema de
la dependencia estratégica de un sistema existente y cada vez menos confiable, y los enormes costos,
plazos y riesgos que implica el desarrollo de uno nuevo.

Metodologías del desarrollo de sistemas

Afortunadamente, se han ideado varias metodologías para ayudar a gestionar el diseño, la implementación
y el mantenimiento generales de sistemas de aplicaciones complejos.

El ciclo de vida del desarrollo del sistema. Inspirados por la experiencia en los grandes proyectos
de ingeniería, los profesionales de sistemas de información han desglosado el proceso en un “ciclo de
vida de desarrollo del sistema”, que divide la tarea global de desarrollar un sistema en una serie de fases
independientes, donde cada una toma entradas de las fases anteriores y crea salidas intermedias que se
utilizarán en las fases posteriores. (Consulte el Anexo 1).

Los analistas de sistemas establecen la viabilidad general de un sistema propuesto a través de

una encuesta inicial entre los usuarios a quienes está dirigido. La meta de esta fase es desarrollar un “caso
comercial” que describa la función del sistema y brinde cálculos aproximados de los costos y los posibles
beneficios. Los requisitos del usuario se identifican y documentan en una segunda fase. Las funciones
comerciales básicas que debe respaldar el sistema se identifican a través de entrevistas a usuarios, y de la
observación y el análisis de los sistemas y los procedimientos existentes.

Los analistas de sistemas establecen el diseño externo, o las características funcionales, de

un sistema por medio de los requisitos generales definidos en las fases anteriores para establecer las
entradas y las salidas que debe proporcionar. Un procedimiento común empleado para comunicar el
diseño externo a los usuarios es la revisión estructurada, en la cual los analistas del sistema de información
demuestran el sistema completo y les muestran a los usuarios cómo interactuar con él en una variedad de
situaciones, y les explican el tipo y el formato de la salida que producirá el sistema. En general, las fases
dos y tres son un proceso iterativo dirigido a definir mejor los requisitos del sistema antes de diseñar y
codificar los procedimientos internos.

El diseño externo se utiliza para desarrollar un diseño interno o técnico que se pueda implementar
en una computadora. Con el uso de técnicas de diseño estructurado, los analistas de sistemas desarrollan
el diseño lógico de los programas individuales que serán necesarios para procesar los datos de entrada,
generar los datos de salida, y crear las pantallas y los informes de entrada y salida. En la fase de programación
y prueba, los programadores transforman este diseño en un código de lenguaje de programación que se
ejecutará en una computadora específica con un sistema operativo en particular.

La conversión y prueba implica una estrecha colaboración entre los analistas, programadores y
usuarios. La conversión del sistema se puede gestionar de varias maneras. La conversión directa implica
abandonar el sistema antiguo y comenzar a utilizar el nuevo de inmediato. En la conversión en fases, el
nuevo sistema se introduce gradualmente, un paso a la vez; en general, se comienza con la parte que
menos interrupciones genera. Una conversión por proyecto piloto implica el uso de un nuevo sistema en
un entorno de prueba en un único departamento, planta o sucursal antes de implementarlo en el resto
de la organización. Durante una conversión paralela, ambos sistemas se ejecutan en simultáneo hasta que
los usuarios están satisfechos con el funcionamiento del nuevo sistema. La conversión paralela es el
enfoque más seguro, dado que el sistema antiguo permanece intacto y sirve de copia de seguridad del
nuevo, pero la seguridad tiene su precio, dado que se deben ejecutar ambos sistemas durante toda la
conversión. Los aspectos técnicos u operativos hacen que la conversión paralela sea imposible o inviable
en algunos sistemas y, dado que el sistema antiguo representa un modo más familiar y cómodo de dirigir
los negocios, los usuarios suelen ser reacios a cambiar al nuevo sistema.

El mantenimiento y la mejora comienzan cuando un nuevo sistema se convierte en una parte operativa
de una organización. Los analistas siguen trabajando con los usuarios para identificar los errores, investigarlos
y corregirlos, y para agregar nuevas funciones y características a medida que cambia el ámbito empresarial.

2
Gestión de la tecnología de la información: Desarrollo de sistemas 189-132

Elaboración de prototipos. El riesgo de introducir un nuevo sistema se puede reducir en alguna medida
mediante la técnica de elaboración de prototipos. Un prototipo es un modelo con algunas de las funciones
y casi la totalidad del aspecto de un sistema propuesto. El desarrollo evoluciona de la planificación y el
diseño a la implementación de un prototipo inicial. El uso del prototipo conlleva la realización de ajustes,
con lo que el ciclo se repite (consulte el Anexo 2). Este enfoque es alentado por aquellos que consideran el
desarrollo como un proceso evolutivo que nunca está acabado.

Al ver un modelo del sistema propuesto mucho antes de que en verdad se ponga en
funcionamiento, un usuario puede “percibir” cómo se verá el sistema y cómo funcionará mucho antes
de que esté realmente programado e implementado. Los malentendidos en los requisitos se pueden
señalar mucho antes en el proceso de desarrollo, lo que ahorra tiempo y gastos sustanciales. Además, en
general los usuarios tendrán una mayor sensación de “propiedad” del nuevo sistema, y se generará una
capacitación cruzada entre programadores y especialistas funcionales. Pero la elaboración de prototipos
no está libre de contratiempos, entre otros, las ambiciosas expectativas generadas por el prototipo y el
diseño deficiente del sistema provocado por el enfoque incremental.

Herramientas del desarrollo de sistemas

A nivel de detalle, la productividad del desarrollo del sistema se puede mejorar mediante las opciones
de software y herramientas e, incluso, al delegar algún subconjunto de las tareas de desarrollo a los usuarios
finales. Si bien medir la productividad del desarrollo es una tarea difícil y muy discutida, cada una de las
técnicas siguientes ha demostrado el potencial de facilitar alguna parte de la actividad de desarrollo.

Lenguajes de programación avanzada. Los llamados lenguajes de programación de cuarta generación

pueden reducir el desarrollo del programa a una fracción del tiempo empleado cuando se utilizan
lenguajes de programación de tercera generación, como COBOL (consulte Managing Information Technology:
Computer Systems and Components [Gestión de la tecnología de la información: sistemas y componentes
informáticos], Nota técnica de HBS n.º N9­189-130). Los usuarios pueden utilizar estos lenguajes más
“humanos” para escribir programas sencillos con el fin de generar informes personalizados o realizar
consultas específicas, por lo que se reduce parte de la demanda de más rutinas que se pide a los grupos
de desarrollo de sistemas. Pero debido a que la “facilidad de uso” de estos lenguajes se construye sobre
la base de una complejidad considerable, los programas de alto volumen y complicados escritos en un
lenguaje de programación de cuarta generación normalmente consumen más recursos informáticos que
los programas equivalentes escritos en un lenguaje de programación de tercera generación. Cuando
los recursos informáticos están restringidos, esto puede ser un punto a tener en cuenta. Sin embargo,
en general, las velocidades de procesamiento de las computadoras están aumentando; y los precios,
cayendo, con rapidez.

Ingeniería de software asistida por computadora. A menudo, la “ingeniería de software asistida

por computadora” (CASE) se describe en términos de CASE “superior” (ayuda al diseño del sistema)
e “inferior” (ayuda al desarrollo del sistema). La primera incluye integrar “bancos de trabajo” que ofrecen
un sistema uniforme de asistencia para todas las fases, desde la encuesta inicial hasta la conversión y
prueba. Además de mejorar la calidad de los productos de software y reducir el tiempo de desarrollo,
muchos entornos de CASE proporcionan un subproducto bien recibido, en forma de documentación
automática mejorada para el nuevo sistema.

Programación orientada a objetos. Mientras que el enfoque convencional para el desarrollo de

módulos de programas se concentra en los procesos que se deben realizar para resolver un problema, los
módulos de programación orientada a objetos reflejan los objetos, o entidades externas, que conforman
el problema. Por ejemplo, una casilla de correos, tal como se podría desarrollar para un sistema de correo
electrónico, se podría utilizar en una variedad de aplicaciones para recibir mensajes. A diferencia de los
módulos orientados a procesos, que tienden a ser bastante específicos, los módulos orientados a objetos
se pueden generalizar con mayor facilidad y utilizarlos para otros problemas que implican objetos
similares. Dado que estos módulos modelan problemas del mundo real, también suelen ser más fáciles
de comprender y mantener.

3
189-132 Gestión de la tecnología de la información: Desarrollo de sistemas

Gestión del proceso de desarrollo del sistema

Los procedimientos de gestión de proyectos que habitualmente acompañan al desarrollo de un

sistema guían a los gerentes de los sistemas de información en la asignación de recursos a los proyectos
de desarrollo individuales y en la gestión del avance de los proyectos a través de sus correspondientes
ciclos de vida. El conocimiento de estos procedimientos de gestión de proyectos y la cooperación con los
gerentes de los sistemas de información son responsabilidades fundamentales del gerente general para
el cual se está desarrollando un sistema. El gerente general conserva la responsabilidad de las funciones
comerciales que debe automatizar el sistema informático y debe tener un papel activo en la gestión de los
proyectos de desarrollo del sistema en su área de responsabilidad.

Dado que la introducción de un nuevo sistema siempre implica nuevas maneras de que una
organización haga su trabajo, es importante darse cuenta de que la gestión del proceso gira en torno a
controlar el cambio de cultura institucional. Se ha descubierto que son varios los factores importantes
para la correcta implementación de nuevos sistemas. El más importante es que los niveles superiores de
gerencia apoyen de manera activa el nuevo sistema. Debido a que el éxito precoz otorga a todos la confianza
para continuar con la implementación, es mejor comenzar con una parte de la organización, que esté muy
comprometida con el uso de un nuevo sistema.

La capacitación del personal, algo que a menudo se pasa por alto, es un factor clave para el éxito
del proyecto de cualquier sistema. Un sistema bien diseñado, aunque incluya todas las funciones necesarias
para cumplir los requisitos de los usuarios, aporta escaso valor a menos que la gente sepa cómo utilizarlo
y entienda en qué medida cambia su trabajo. Los manuales de usuario, de operadores y de programadores
son ayudas de aprendizaje y referencia importantes, y los cursos y las sesiones prácticas de capacitación son
necesarios para familiarizar a los usuarios con los procedimientos y las capacidades del sistema.

Cálculo y supervisión de los proyectos de desarrollo de sistemas. Los proyectos de desarrollo de

sistemas son conocidos por entregarse fuera de plazo y por pasarse del presupuesto. Un factor clave en
los excesos de los proyectos de software es la dificultad de calcular con exactitud el esfuerzo, el tiempo
y los costos. Como consecuencia, se han diseñado estrategias para mejorar los cálculos tanto antes de
comenzar un proyecto de software como durante su transcurso.

El ciclo de vida del desarrollo del sistema que se trató anteriormente es una herramienta
importante de gestión en algunos proyectos de desarrollo de sistemas. Las distintas etapas en la evolución
de un proyecto de software resultan útiles para calcular el proyecto, planificarlo y hacerle un seguimiento.
Las etapas pueden servir de puntos de referencia del proyecto y como guía para las revisiones formales.
El Anexo 3 muestra las distribuciones relativas del esfuerzo, medido en persona-mes, para las distintas
etapas de los proyectos de software a gran escala. Debe tenerse en cuenta que el gasto de tiempo relativo
en cada etapa puede no verse reflejado con precisión si solo se tienen en cuenta las personas-mes del
esfuerzo. Otros factores pueden influir en la distribución del esfuerzo entre las distintas etapas. Por
ejemplo, en general la reescritura o la conversión de un programa existente no exigirán tanto esfuerzo
en las etapas de propuesta, requisitos y especificaciones como lo harían en un nuevo proyecto; mientras
que un proyecto abordado para una gran cantidad de usuarios puede insumir una enorme cantidad de
tiempo en la fase de requisitos del sistema, dada la necesidad de buscar consenso entre los usuarios.

Uno de los errores más comunes que se cometen en la gestión de los proyectos de software es la
confusión del esfuerzo realizado con el avance. Si esfuerzo y avance fueran sinónimos, sería correcto suponer
que personas y meses fueran intercambiables y que sumar personas a un proyecto de software disminuiría el
tiempo necesario para realizarlo. Esta suposición es válida solo cuando una tarea se puede dividir de manera
uniforme entre muchos trabajadores sin comunicación entre ellos. Si bien esto puede ser así para algunas tareas de
producción/fabricación, no es ni parcialmente cierto para el desarrollo y la programación de sistemas. Dado
que la construcción de un software es intrínsecamente un esfuerzo de sistemas, un ejercicio de interrelaciones
complejas, la necesidad de comunicación es grande y las tareas no se pueden dividir de manera uniforme. Como
resultado, sumar personas a un proyecto de software a menudo retrasa la planificación en lugar de acelerarla.

4
Gestión de la tecnología de la información: Desarrollo de sistemas 189-132

Sumar personas a un proyecto retrasado no es la única causa para el fracaso1. Los estudios
muestran que varios otros factores contribuyen al desastre.2

• Los proyectos no se definen o calculan de manera adecuada. No existe nunca un verdadero

“acuerdo de voluntades” entre usuarios y desarrolladores.

• Los requisitos del personal no se tienen en cuenta en los cálculos o se producen cambios
frecuentes del personal durante el proyecto. Se hacen falsas suposiciones acerca de las
habilidades. Por ejemplo, se supone que los miembros del personal son “expertos universales”
y, por lo tanto, se pueden intercambiar.

• Las funciones (por ejemplo, de líder del proyecto) están mal definidas. ??La documentación
es insuficiente o no existe. ??Las definiciones del proyecto cambian, pero los cálculos no.
??Se omite la planificación del proyecto, y la fase de programación y pruebas se comienza de
manera precoz.

• No se definen los criterios de finalización. “¿Cómo sabremos cuando hayamos terminado?”

es una pregunta que no tiene respuesta.

• No se gestiona el estado del proyecto y las revisiones del proyecto son insignificantes. No se
definen hitos del proyecto, por lo que la generación de informes del proyecto es superficial.

• No se razona acerca del uso de proyectos, herramientas o métodos de simplificación

anteriores con el fin de abreviar el ciclo. (“Reinventar la rueda”).

• Nunca se define la “calidad”.

Mantenimiento de sistemas antiguos. Muchas organizaciones se sienten presas de su pasado. Si bien les
gustaría sustituir cientos o, incluso, miles de aplicaciones y archivos de datos antiguos que han quedado
obsoletos, con una acumulación de dos años o más de trabajo nuevo ya en cola y con la dependencia de sus
operaciones diarias de los sistemas existentes, no ven forma de romper el ciclo de mantenimiento y mejora.
En muchas organizaciones, el mantenimiento consume hasta el 70% del esfuerzo total de
programación. Los usuarios aprenden rápido que lleva mucho tiempo obtener aunque sea una leve
modificación. Como resultado, los programas quedan más y más rezagados. Aunque ya no cubren las
necesidades de la empresa, estos programas al poco tiempo consumen una gran porción del presupuesto
total de los sistemas de información.

Aun así, el costo de mantenimiento suele ser pequeño en comparación con el costo de sustituir un
sistema. Piénsese en el caso de una gran compañía informática que había acumulado 50 000 programas en
COBOL con un total de 37,5 millones de líneas de código. Si suponemos que solo el 20% de estos sistemas
debía sustituirse, y utilizando una cifra de costos moderada de 10 dólares por línea, el costo de reescribir
la quinta parte del inventario ascendería a 75  millones de dólares e insumiría 2  000 años de trabajo
aproximadamente. Como consecuencia de esto, las empresas se ven atrapadas por los enormes costos de
actualizar los sistemas antiguos y los costos incluso mayores de sustituirlos.

1
Frederick P. Brooks, The Mythical Man-Month (El mítico hombre-mes) (Lectura, Massachusetts:
Addison-Wesley, 1975).
2
Stephen P. Keider, “Why Projects Fail” (Por qué fracasan los proyectos), Datamation, diciembre de
1974, págs. 53-55.

5
189-132 Gestión de la tecnología de la información: Desarrollo de sistemas

Mantenimiento frente a nuevo desarrollo. Los consultores de sistemas de información han desarrollado
métodos estructurados para abordar la disyuntiva del mantenimiento del software3,4. Recomiendan que el
análisis comience con una determinación del valor del sistema para la empresa. Este análisis debe tener en
cuenta la condición técnica del sistema, el grado de apoyo funcional que aporta a la empresa y su importancia
estratégica. Una vez que se ha establecido el valor del sistema, se ponderan las opciones siguientes:

• La reestructuración trata principalmente de limpiar la estructura interna de una aplicación

para que sea más eficiente, y se pueda mantener y comprender mejor.

• La renovación agrega alguna facilidad o funcionalidad a una aplicación, como una mejor
entrada, salida, o capacidad de manejo de datos.

• El rejuvenecimiento le agrega funcionamiento suficiente a una aplicación para aportarle un

mayor valor a la empresa.

• La reescritura implica una reescritura completa con enfoques tradicionales o iterativos. La

empresa puede reescribir el sistema con recursos internos o puede contratar los servicios de
un proveedor de software.

• El reemplazo implica una sustitución completa por un paquete adquirido a un productor de

software o un proyecto de desarrollo de un mayorista.

Los Anexos 4 y 5 dan pautas para decidir si mantener un sistema antiguo o desarrollar uno
nuevo, o si es conveniente encargarse del desarrollo de manera interna o adquirir un paquete disponible
en el mercado.

A pesar de la disponibilidad de una variedad de herramientas y técnicas de desarrollo de

aplicaciones y de mejores programas de aplicación comerciales, el desarrollo de aplicaciones sigue siendo
una tarea costosa, consumidora de tiempo y, muy a menudo, ineficiente. Suele ser la actividad menos
sistemática de todas las relacionadas con la tecnología de la información dentro de una organización.
Calcular y supervisar los proyectos de desarrollo de software es especialmente difícil dada la naturaleza
interrelacionada del proceso de desarrollo de software. En consecuencia, la gestión eficiente del desarrollo
y el mantenimiento de los sistemas exige una cabal comprensión del ciclo de vida del desarrollo del sistema
y de los métodos generales de la gestión de proyectos, así como familiarizarse con las herramientas y las
técnicas que están disponibles para mejorar estos procesos complejos.

3
D. F. Robinson, “Renewing Obsolete Systems” (Renovación de sistemas obsoletos), Information Strategy:
The Executive’s Journal, otoño de 1984.
4
R. H. Sprague y B. C. McNurlin, “Improving Old Systems” (Mejora de los sistemas antiguos), Information Systems
Management in Practice (NuevaJersey: Prentice-Hall, 1986).

6
Gestión de la tecnología de la información: Desarrollo de sistemas 189-132

Anexo 1 Ciclo de vida del desarrollo de sistemas

Encuesta
inicial

Requisitos
del usuario

Diseño
externo

Diseño
técnico

Programación
y pruebas

Conversión
y pruebas

Mejora del
mantenimiento

Anexo 2 El proceso de elaboración de prototipos

Utilizar
prototipo

Implementar
prototipo

Diseñar
prototipo

Planificación de
la información

7
189-132 Gestión de la tecnología de la información: Desarrollo de sistemas

Anexo 3 Gastos relativos de la iniciativa en las fases de desarrollo de software

Fase % de esfuerzo
Encuesta inicial 10
Requisitos del usuario 15
Diseño externo 20
Diseño interno 15
Programación/pruebas 20
Conversión/pruebas 20

Anexo 4 Mantenimiento frente a reemplazo: criterios para la toma de decisiones

Mantener Reemplazar
Alto Experiencia del programador con el programa existente Bajo
Alto Confiabilidad del programa existente Bajo
Alto Adaptabilidad del programa existente Bajo
Bajo Probabilidad de pasar a una nueva base de hardware Alto
Alto Capacidad de transportación del programa existente Bajo
Bajo Disponibilidad de un sustituto estándar Alto

Anexo 5 Compra frente a desarrollo: criterios para la toma de decisiones

Comprar Desarrollar
Alto Disponibilidad de software adecuado Bajo
Alto Urgencia de necesidad de la aplicación Bajo
Alto Acumulación de trabajo de desarrollo del sistema Bajo
Bajo Exclusividad de la aplicación Alto
Bajo Habilidades del personal interno Alto
Bajo Compromiso de la gestión de usuarios Alto