Capítulo 3. Los procedimientos de desarrollo y de mantenimiento
3.1 La metodología de desarrollo de las aplicaciones
• P. ¿Se realiza siempre un estudio de oportunidad previo
al lanzamiento del diseño de una nueva aplicación?
La oportunidad o no de desarrollar una nueva aplicación no es siempre evidente. De este modo, el auditor se encuentra algunas veces frente a costo- sos estudios detallados de sistemas de información, incluso con desarrollos de software, abandonados brutalmente sin verdadero motivo. Uno se ha dado cuenta durante el estudio que el software antiguo era del todo satisfac-
torio y que era completamente inútil sustituirlo. O aún, el diseño de la nueva aplicación adquiría proporciones considerables y ha parecido más razonable interrumpirla antes que alcanzara proporciones desorbitadas.
Estas situaciones muy costosas son generalmente el síntoma del mismo error: la ausencia, al principio del estudio, de una reflexión previa en cuanto a la oportunidad del proyecto. Esta reflexión tiene como objetivo, después de un análisis sumario de las necesidades de la arquitectura técnica futura de la aplicación, estimar el coste global del proyecto, para después pronun- ciarse sobre la prosecución de su aplicación.
Con el fin de facilitar la decisión, el estudio de oportunidad presentará, además, las ventajas y los límites del sistema propuesto, las principales obligaciones inherentes de su aplicación, y un primer calendario de reali- zación.
La instancia de decisión en cuanto al abandono o la prosecución del pro- yecto será generalmente el Comité informático o, más directamente, la Di- rección general. Una decisión llevada a cabo por el servicio informático, o por el único servicio operativo al que concierne, debe ser evitada, en la me- dida en que ésta se puede transformar posteriormente en fuente de tensiones, si se sospecha de parcialidad en su elección por parte de los susodichos ser- vicios.
Si se da el caso, más allá de la decisión de abandono o de prosecución del proyecto, se arbitrará un cierto número de decisiones técnicas fundamentales al final del estudio de oportunidad, tales como: informática centralizada o descentralizada, prioridades de arranque, desarrollo de software específico o adquisición de programas, etc.
Por último, hacemos mención a que, si se puede admitir una cierta flexi- bilidad en el nivel de formalización del estudio de oportunidad (no es, por ejemplo, deseable exigir de una PYME documentos voluminosos para el estudio de proyectos «pequeños»), la existencia misma de una reflexión previa al lanzamiento de cada proyecto es, en cuanto a ella, del todo indis- pensable.
El estudio de oportunidad incluirá principalmente: — La presentación sucinta de las funciones a desarrollar. — Las principales obligaciones de aplicación.
— Si fuere necesario, una presentación de las diferentes soluciones técnicas entre las cuales será conveniente arbitrar.
— Una estimación de los volúmenes a procesar.
— Una estimación de los costes previstos y, si fuere el caso, de los benefi- cios financieros esperados.
— Un calendario preventivo de la aplicación.
• P. Ante todo desarrollo de software o toda adquisición
de programas, ¿se analizan las ventajas y los inconvenientes respectivos de la adquisición de un programa
y de la realización de un sistema específico?
Conviene insistir muy particularmente sobre la utilidad de este análisis. Muy a menudo, los servicios informáticos desarrollan sistemas de contabili- dad general o de nómina muy complejos, por el solo hecho de incluir algu- nas necesidades complementarias de menor importancia en relación a las prestaciones de los programas disponibles en el mercado.
• P. ¿Se redacta un pliego de condiciones previo al lanzamiento
de la realización de nuevo software?
Evitaremos aquí un debate semántico sobre las diferentes fases de la vida de un proyecto. Modelos conceptuales y organizativos de los procesamien- tos y de los datos (vocabulario ligado a la metodología MERISE), análisis funcional (que define las funciones del software a desarrollar por oposición al análisis orgánico que definió las especificaciones técnicas), pliego de con- diciones, etc., son muchos términos cuyo contenido exacto puede variar am- pliamente de una interpretación a otra.
De todas formas, si el número y el contenido exacto de las diferentes fa- ses de un proyecto puede variar en función del tamaño de la empresa y de la importancia de los proyectos, existe un punto de paso obligado en todo pro- yecto: el acuerdo entre los informáticos y los usuarios sobre el contenido de la aplicación a desarrollar. Este acuerdo se formalizará imperativamente por medio de un documento escrito, que llamaremos aquí pliego de condiciones y que incluirá, en efecto, el conjunto de las especificaciones funcionales del futuro sistema de información.
De alguna forma, se puede comparar el pliego de condiciones con la re- cuperación de los puntos de apoyo antes de la ejecución de una volea en un partido de tenis. Si el atacante no se toma su tiempo para la recuperación de sus puntos de apoyo, la volea, jugada en desequilibrio, terminará en la red o fuera de los límites de la pista.
Ocurre lo mismo con el pliego de condiciones. En su ausencia, es casi se- guro que los programas desarrollados no corresponderán a las necesidades de los usuarios. El ahorro de algunos días empleados en la redacción, sin duda alguna trabajosa, de un documento de síntesis, parecerá irrisorio en comparación con los costes extraordinarios y los retrasos en los plazos que tendrán origen en esta falta de comprensión.
Y además, esta ausencia de formalización será fuente de conflictos. ¿La inadecuación del software es consecuencia de una mala expresión de las ne-
cesidades por parte de los usuarios, o bien de un mal análisis por parte de los informáticos?
Por tanto, la formalización de los análisis preliminares al desarrollo de un software es el origen de duros debates entre auditores y auditados. Cuántas veces he oído a los responsables de pequeñas estructuras informáticas afir- mar terminantemente que, si bien, de una forma general, los pliegos de con- diciones eran útiles sin ninguna duda, no se justificaban en sus casos particu- lares. La variedad de los argumentos es además infinita:
— «¡para tal máquina, el análisis funcional es inútil!»;
— «en nuestra empresa, los nuevos desarrollos son escasos y siempre de poca monta (pero mi predecesor, que había desarrollado varias aplicacio- nes muy gravosas, no nos ha dejado ningún análisis, lo que nos plantea grandes problemas»);
— «tenemos los informáticos más importantes y los usuarios más inteligen- tes y, no obstante, los dossieres son inútiles»;
— «mi Director general tiene toda mi confianza».
El único problema de este cuadro idílico es finalmente que, al salir del contexto de una auditoría, estos mismos responsables informáticos confesa- rán sus dificultades imputables, por supuesto, a la incompetencia notoria de sus interlocutores, cuando ésta no es otra que la de sus propios colaboradores.
En definitiva, la famosa frase de los automovilistas «esto sólo ocurre a los demás» encuentra del todo su aplicación en los fracasos de proyectos in- formáticos.
Sin que la lista sea exhaustiva, podemos nombrar como principales docu- mentos contenidos en el pliego de condiciones:
— La descripción de las funciones a desarrollar.
— La descripción de las pantallas de tomas de datos y de consulta. — Los procesos a realizar.
— La lista y el contenido de los principales listados editados.
— La lista y el contenido de los ficheros constitutivos de la aplicación (a ex- cepción de los ficheros de trabajo).
— La previsión de los volúmenes a procesar.
Según el caso, encontraremos igualmente las modalidades y el calenda- rio de ejecución y de arranque de la aplicación.
Para concluir este importante y espinoso tema, citaremos una evolución interesante para el análisis de las aplicaciones. El desarrollo de programas de «maquetación» que, principalmente para las aplicaciones transaccionales, permite visualizar en la pantalla las propuestas de clave de registro y de con-
sulta que formarán la aplicación. Si bien estos «modelos» no sustituyen en ningún caso a un pliego de condiciones, ya que sólo definen los soportes de entradas y salidas interactivas pero no los procesos en sí, se debería, sin em- bargo, generalizar de forma progresiva y substituir los diseños demasiado complejos de la pantalla por soporte en papel.
Las herramientas de preparación de prototipos son, en sí mismas, mucho más completas, puesto que permiten presentar el conjunto de una aplicación futura antes de una programación en firme. Su único inconveniente, pero en justa medida, reside por último en el tiempo necesario para la elaboración del prototipo.
• P. ¿Existen normas en materia de desarrollo de aplicaciones?
Evidentemente, es totalmente indispensable que se adopte un método en materia de desarrollo de aplicación. En cambio, la cuestión de saber si un método reconocido en el mercado es preferible a las normas «de la casa» es más delicada.
En un entorno de grandes empresas o de administraciones públicas, la elección de un método ampliamente difundido se impone indiscutiblemente. Los métodos como el MERISE, el estándar por antonomasia, o el AXIAL (propuesto por IBM) presentan la ventaja, debido a su amplia difusión, de ser conocidos por gran número de informáticos y, por lo tanto, de poder ser impuestos con facilidad en el seno de la empresa. Presentan, además, la ven- taja de un gran rigor, necesario para el desarrollo de proyectos muy impor- tantes (más concretamente, consideraremos como importantes los proyectos cuyo coste global alcanza varias decenas de millones de pesetas).
En las empresas pequeñas o medianas, o bien para proyectos de menor envergadura, los métodos citados anteriormente representan, por lo general, el inconveniente de una carga demasiado elevada. Por ello, no es extraño en- contrar en las empresas métodos «caseros». Se imponen entonces en el desa- rrollo de un proyecto el respeto de ciertas etapas y la formalización de docu- mentos cuyo contenido tipo será predefinido.
Se impondrán, por ejemplo — El estudio previo.
— El pliego de condiciones. — El análisis técnico.
— Las normas de programación.
• P. ¿Existen normas en materia de programación?
finalidad mejorar la calidad de los programas producidos, en la medida que éstos constituyen una verdadera guía de especial utilidad para los programa- dores debutantes. Además, conducen a una mejor homogeneidad del con- junto del software de la empresa.
Distinguiremos con más exactitud:
• Las normas concernientes a la estructura general de los programas
Los métodos como la programación estructurada, o también WARNIER, proponen una estructura común para el conjunto del software desarrollado. Además, nos daremos cuenta que ciertos lenguajes de desarrollo (lenguajes de cuarta generación, generadores de programas) imponen, de hecho, una estructura de programación.
• Las normas relativas al contenido detallado de los programas
Citamos, por ejemplo: — los nombres de ficheros;
— los nombres de zonas en los ficheros; — los nombres de etiquetas en los programas; — etcétera.
Para poder ser respetadas, las normas de programación serán inscritas en un documento escrito y difundidas al conjunto del personal de estudios.
• P. ¿Se utilizan herramientas del tipo «taller de ingeniería de software»?
El término «taller de ingeniería de software» (TIS) se utiliza, hoy día, para designar funciones muy diversas en el desarrollo de aplicaciones. El producto MAESTRO, de PHILIPS, fue, en los años setenta, el precursor de los TIS de hoy día. Sus funciones en aquella época cubrían principalmente la gestión de las bibliotecas de software de estudios y de explotación y la auto- matización de procesos de puesta en explotación.
Las posibilidades de los TIS son hoy día mucho más amplias puesto que incluyen a menudo, además de las funciones mencionadas anteriormente, la asistencia en el diseño del software, la gestión automatizada de las especifi- caciones y de la documentación, la generación del software a partir de las es- pecificaciones, etc.
Los TIS se relacionan a menudo con un método de desarrollo, principal- mente el MERISE. Sin embargo, nos daremos cuenta que, si bien el TIS del
mañana será con certeza una herramienta totalmente integrada que dará una asistencia al conjunto de las etapas del proceso de desarrollo de la aplica- ción, esto todavía está muy lejos de ser el caso de la mayoría de los TIS dis- ponibles en el mercado, de los cuales las diferentes funciones no están siem- pre del todo integradas las unas con las otras.
De todas formas, el auditor no podrá, en ningún caso, contentarse con considerar la presencia de un TIS como un punto fuerte y su ausencia como un punto débil. En efecto, un TIS mal utilizado puede ser totalmente inefi- caz, cuando algunas herramientas de desarrollo escogidas con acierto pue- den ser suficientes para una excelente productividad del servicio.
Después de enumerar los métodos y herramientas de producción de apli- cación, el auditor deberá entonces pronunciarse sobre sus efectos en término de seguridad y de eficacia del proceso.
• P. ¿Se prevén en el proceso de desarrollo de nuevas aplicaciones
las principales fases de puesta en práctica de un proyecto?
Salvo excepciones, ciertas fases deben imperativamente estar previstas en el proceso de introducción de nuevas aplicaciones. Las principales entre ellas son citadas a continuación.
• La formación de los usuarios
Una mala formación de los usuarios tendrá como consecuencia una utili- zación anárquica del sistema, con todos los riesgos que esto comporta, o bien un desinterés, incluso un rechazo, frente a éste. En ambos casos, la apli- cación está condenada a una fase de arranque, en el mejor de los casos, cier- tamente agitada.
• La documentación de la aplicación
El contenido y la calidad de la documentación serán nombrados poste- riormente (apartado 3.3).
• La recuperación de los ficheros
El arranque de una aplicación necesita casi siempre la constitución y la entrada exnihilo de los ficheros necesarios para ésta, o bien la recuperación en el nuevo sistema de los ficheros procedentes del viejo, siendo este caso, notablemente, el más frecuente en la actualidad (los nuevos programas susti- tuyen muy a menudo a una vieja aplicación que tiene un proceso manual).
Estas recuperaciones son con frecuencia delicadas y necesitan una parti- cipación de los usuarios, aunque sólo sea con el fin de confirmar el conte- nido de los ficheros recuperados.
Una mala previsión de los gastos de recuperación es, así pues, suscepti- ble de comprometer el arranque de la aplicación.
• El impacto del nuevo sistema en la organización
y en los procedimientos administrativos
Un nuevo sistema informático va seguido, en la mayoría de los casos, de una reflexión sobre la organización del trabajo, y sobre la aplicación de nue- vos procedimientos.
En ausencia de una reflexión de este tipo, es previsible que los procedi- mientos administrativos sean mal adaptados al sistema de información y no permitan sacar el mejor partido del mismo.
• La implantación física de los equipos
La reflexión sobre el tema permite prever, entre otras cosas:
— La implantación de la o de las unidades centrales (en un sistema bastante descentralizado, encontraremos una unidad central por emplazamiento). — El número y la localización geográfica de los terminales, pantallas e im-
presoras.
• La validación del software
Dos métodos complementarios conducen a la validación del software (se habla, a menudo, de «receta») antes de su puesta en explotación.
— Los juegos de prueba, que permiten simular casos reales. Después de los juegos de prueba, diseñados y realizados por los informáticos, que permitirán asegurarse de que los programas están de acuerdo con los pliegos de condiciones, es indispensable prever los juegos de prueba para usuarios, los cuales darán validez a la adecuación de la aplicación a las necesidades y serán, en definitiva, el último control antes del arran- que.
— La explotación doble, que consiste en hacer funcionar simultáneamente el software nuevo y el viejo con el fin de comparar los resultados.
Esta última técnica es muy eficaz puesto que la aplicación sustituye los programas que tienen funciones similares. No obstante, es engorrosa ya que
impone a los usuarios una importante sobrecarga de trabajo, como: doble re- gistro, doble control. Así pues, está limitada en el tiempo (por lo general, de uno a tres meses).
Cualquiera que sea el método de validación del software escogido, el auditor comprobará que los usuarios hayan sido partícipes y que hayan te- nido la posibilidad de probar las aplicaciones puestas en explotación.
• La seguridad
Si bien la seguridad del sistema de información es primordial en la fase de explotación, un primer acercamiento en ciertos ámbitos es deseable a par- tir del diseño. Nombremos, por ejemplo, las reflexiones sobre:
— la lista de personas autorizadas a acceder al sistema y las funciones ase- quibles a cada una de ellas;
— el medio de control de la validez de los procesos: controles de explota- ción, controles de bases de datos, etc;
— el respeto por la aplicación de ciertos principios de control interno: con- trol jerárquico, separación de funciones, continuidad de la vía de revi- sión, etc.;
— los procedimientos de explotación: recuperación en caso de incidente, copias de seguridad, emplazamiento de emergencia, etc.
Volveremos más detalladamente sobre el conjunto de estos puntos a lo largo de la obra.
• P. ¿Se ha llevado a cabo regularmente un seguimiento del avance
y de los costes de los proyectos?
Este seguimiento tiene como objeto el control del avance de cada una de las tareas elementales que componen los proyectos, con el fin de detectar lo más rápidamente posible los riesgos de desaciertos en términos de planifica- ción y de costes.
Varios programas de seguimiento de proyecto se encuentran actualmente disponibles para grandes sistemas o, con más frecuencia, para microordena- dor. De todos modos, un simple tablero puede ser suficiente para un segui- miento eficaz.
Cualquiera que sea la herramienta utilizada, el auditor se preocupará de comprobar que el responsable del proyecto disponga de los medios adecua- dos para anticipar a tiempo todo tipo de error, a fin de tomar las medidas ne- cesarias.
• P. ¿Son los proyectos objeto de una coordinación suficiente?
Por lo general, el carisma del o de los responsables del proyecto es un factor primordial del éxito del mismo. Para los proyectos más importantes, la coordinación del mismo debe estar formalizada a través de reuniones pe- riódicas (por ejemplo: semanales) de los principales responsables.
En realidad, distinguiremos, para cada proyecto cuya envergadura lo jus- tifique:
• La coordinación entre los equipos de diseño, y posteriormente entre
los equipos de realización
Si la amplitud del proyecto justifica una distribución de tareas entre va- rios equipos, es deseable una coordinación periódica, por ejemplo, a través de una reunión semanal de los grupos de trabajo, a falta de la cual los dife- rentes subproyectos estarían poco integrados entre sí, además que algunas funciones habrían sido omitidas o tratadas doblemente.
Además, se deben prevenir las fases regulares de validación de los docu- mentos producidos.
• La coordinación entre los equipos de puesta en marcha
Hemos citado antes algunas de las tareas a tener en cuenta en la puesta en marcha de un proyecto informático, tales como: recuperación, organización, formación, etc. Una coordinación general entre estas tareas es indispensable, aunque sea sólo por evitar que algunas de ellas se tornen «críticas» en térmi- nos de plazo.
• La coordinación entre los informáticos y los usuarios
Ya hemos subrayado la importancia de la formación de los usuarios. Ge-