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-189130), 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 osolicitar permiso para reproducir materiales, llame al 1-800-545-7685, escriba a Harvard Business Publishing, Boston, MA 02163 o diríjase ahttp://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 larevisió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 mejoracomienzan 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 deelaboració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 elAnexo 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 (consulteManaging Information Technology: [Gestión de la tecnología de la información: sistemas componentes Computer Systems andtécnica Components informáticos], Nota de HBS n.º N9189-130). Los usuarios pueden utilizar estosylenguajes 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. la calidad de los de bien software y reducir el tiempo de desarrollo, muchos Además entornosde demejorar CASE proporcionan un productos subproducto 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 cambiasu trabajo. Los manuales deusuario, de operadores y de programadores son ayudas de aprendizaje y referencia importantes, y los cursos ylas sesiones prácticas de capacitación son necesarios para familiarizar a los usuarios conlos 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 sedividir puedede 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 fracaso 1. 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 3,4. Recomiendan que el métodos estructurados para abordar la disyuntiva del mantenimiento del software 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 desoftware. 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
Anexo 1
189-132
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
Anexo 3
Gestión de la tecnología de la información: Desarrollo de sistemas
Gastos relativos de la iniciativa en las fases de desarrollo de software
Fase
% dees f u e r z o
Encuesta inicial
10
Requisitosdelusuario
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
Manten er
Reempl azar
Alto
Experienciadelprogramadorconelprogramaexistente
Bajo
Alto
Confiabilidaddelprogramaexistente
Bajo
Alto
Adaptabilidaddelprogramaexistente
Bajo
Bajo
Probabilidadde pasar aunanuevabase de hardware
Alto
Alto
Capacidad de transportación delprogramaexistente
Bajo
Disponibilidaddeunsustitutoestándar
Anexo 5
Bajo Alto
Compra frente a desarrollo: criterios para la toma de decisiones
C om p ra r
Desarroll ar
Alto
Disponibilidaddesoftwareadecuado
Alto
Urgenciadenecesidaddelaaplicación
Alto
Acumulacióndetrabajodedesarrollodelsistema
Bajo
Bajo
Exclusividaddelaaplicación
Alto
Bajo
Habilidadesdelpersonalinterno
Bajo
Compromisodelagestióndeusuarios
8
Bajo Bajo
Alto Alto
