Advertencias:
Es muy frecuente que se exagere la importancia de un nuevo enfoque de negocio - e n este caso, la RPN como si fuese la panacea, para después criticarla con tanta severidad que pase a ser un desecho. A lo largo de los Últimos años, se ha debatido de forma exagerada acerca de la eficacia de la RPN. En un resumen excelente del caso a favor y en contra de la RPN, Weisz expone su argumento de la manera siguiente:
Resulta tentador atacar a la RPN como si se tratase de otra reencarnación de la famosa bala de plata. Desde varios puntos de vista -pensamiento de sistemas, tratamiento de personal, simple historia- habría que predecir unos índices de fallos elevados para el concepto, índices que parecen ser confirmados por la evidencia empírica. Para muchas compañías parece que la bala de plata no da en el blanco. Para otras, sin embargo, el nuevo esfuerzo de la reingeniería ha tenido evidentemente su fruto .
La RPN puede funcionar, si es aplicada por personas motivadas y formadas, que reconozcan que el proceso de reingeniería es una actividad continua. Si la RPN se lleva a cabo de forma efectiva, los sistemas de información se integran mejor con los procesos de negocios..
Dentro del contexto de una estrategia más amplia de negocios se puede examinar la reingeniería de aplicaciones más antiguas, y también se pueden establecer de forma inteligente las prioridades de reingeniería del software Aunque la reingeniería de negocio sea una estrategia rechazada por una compañía, la reingeniería del software es algo que debe hacerse. Existen decenas de millares de sistemas heredados -aplicaciones cruciales para el éxito de negocios grandes y pequeños- que se ven afectados por una enorme necesidad de ser reconstruidos o rehechos en su totalidad.
Reingeniería del Software:
Este escenario resulta sumamente conocido: Una aplicación ha dado servicio y ha cubierto las necesidades del negocio de una compañía durante diez o quince años. A lo largo de este tiempo, ha sido corregida, adaptada y mejorada muchas veces. Las personas se dedicaban a esta tarea con la mejor de sus intenciones, pero las prácticas de ingeniería del software buenas siempre se echaban a un lado (por la urgencia de otros problemas). Ahora la aplicación se ha vuelto inestable. Sigue funcionando, pero cada vez que intenta efectuar un cambio se producen efectos colaterales graves e inesperados.
El mantenimiento del software existente puede dar cuenta de más del 60 por 100 de las inversiones efectuadas por una organización de desarrollo, y ese porcentaje sigue ascendiendo a medida que se produce más software. Los lectores que tengan menos conocimientos en estos temas podrían preguntarse por qué se necesita tanto mantenimiento, y por qué se invierte tanto esfuerzo.
Gran parte del software del que dependemos en la actualidad tiene por término medio entre diez y quince años de antigüedad. Aun cuando estos programas se crearon empleando las mejores técnicas de diseño y codificación conocidas en su época (y la mayoría no lo fueron), se crearon cuando el tamaño de los programas y el espacio de almacenamiento eran las preocupaciones principales. A continuación, se trasladaron a las nuevas plataformas, se ajustaron para adecuarlos a cambios de máquina y de sistemas operativos y se mejoraron para satisfacer nuevas necesidades del usuario; y todo esto se hizo sin tener en cuenta la arquitectura global.
El resultado son unas estructuras muy mal diseñadas, una mala codificación, una lógica inadecuada, y una escasa documentación de los sistemas de software que ahora nos piden que mantengamos en marcha ...
La naturaleza ubicua del cambio subyace en todos los tipos de trabajo del software. El cambio es algo inevitable cuando se construyen sistemas basados en computadoras; por tanto debemos desarrollar mecanismos para evaluar, controlar y realizar modificaciones.
Un modelo de procesos de reingeniería del software:
La reingeniería requiere tiempo; conlleva un coste de dinero enorme y absorbe recursos que de otro modo podrían emplearse en preocupaciones más inmediatas. Por todas estas razones, la reingeniería no se lleva a cabo en unos pocos meses, ni siquiera en unos pocos años. La reingeniería de sistemas de información es una actividad que absorberá recursos de las tecnologías de la información durante muchos años. Esta es la razón por la cual toda organización necesita una estrategia pragmática para la reingeniería del software.
Una estrategia de trabajo también acompaña al modelo de procesos de reingeniería. Más adelante, en esta misma sección, se describirá este modelo, pero veamos en primer lugar algunos de los principios básicos. La reingeniería es una tarea de reconstrucción, y se podrá comprender mejor la reingeniería de sistemas de información si tomamos en consideración una actividad análoga: la reconstrucción de una casa. Consideremos la situación siguiente:
Suponga que ha adquirido una casa en otro lugar. Nunca ha llegado a ver la finca realmente, pero la consiguió por un precio sorprendentemente reducido, advirtiéndosele que quizá fuera preciso reconstruirla en su totalidad. ¿Cómo se las arreglaría?
Antes de empezar a construir, sería razonable inspeccionar la casa. Para determinar si necesita una reconstrucción, usted (o un inspector profesional) creará una lista de criterios para que la inspección sea sistemática.
Antes de derribar y de construir toda la casa, asegúrese de que la estructura está en mal estado. Si la casa tiene una buena estructura, quizá sea posible remodelarla sin reconstruirla (con un coste muy inferior y en mucho menos tiempo).
Antes de empezar a reconstruir, asegúrese de que entiende la forma en que se construyó el original. Eche una ojeada por detrás de las paredes. Comprenda el cableado, la fontanería y los detalles internos de la estructura. Aunque vaya a eliminarlos todos, la idea que haya adquirido de ellos le servirán de mucho cuando empiece a construirla.
Si empieza a reconstruir, utilice tan solo los materiales más modernos y de mayor duración. Quizá ahora le cuesten un poquito más, pero le ayudarán a evitar un mantenimiento costoso y lento en fecha posterior.Si ha decidido reconstruir, tenga una actitud disciplinada. Utilice prácticas que den como resultado una gran calidad -tanto hoy como en el futuro.
Aunque los principios anteriores se centran en la reconstrucción de una casa, son aplicables igualmente a la reingeniería de sistemas y aplicaciones basados en computadoras.
Para implementar estos principios, se aplica un modelo de proceso de reingeniería del software que define las seis actividades mostradas en la Figura 30.2. En algunas ocasiones,
estas actividades se producen de forma secuencial y lineal, pero esto no siempre es así. Por ejemplo, puede ser que la ingeniería inversa (la comprensión del funcionamiento interno de un programa) tenga que producirse antes de que pueda comenzar la reestructuración de documentos.
El paradigma de la reingeniería mostrado en la figura es un modelo cíclico. Esto significa que cada una de las actividades presentadas como parte del paradigma pueden repetirse en otras ocasiones. Para un ciclo en particular, el proceso puede terminar después de cualquiera de estas actividades.
Análisis de inventario. Todas las organizaciones de software deberán disponer de un inventario de todas sus aplicaciones. El inventario puede que no sea más que una hoja de cálculo con la información que proporciona una descripción detallada (por ejemplo: tamaño, edad, importancia para el negocio) de todas las aplicaciones activas.
Los candidatos a la reingeniería aparecen cuando se ordena esta información en función de su importancia para el negocio, longevidad, mantenibilidad actual y otros criterios localmente importantes. Es entonces cuando es posible asignar recursos a las aplicaciones candidatas para el trabajo de reingeniería.
Es importante destacar que el inventario deberá revisarse con regularidad. El estado de las aplicaciones (por ejemplo, la importancia con respecto al negocio) puede cambiar en función del tiempo y, como resultado, cambiarán también las prioridades para la reingeniería.
No hay comentarios:
Publicar un comentario