crisis de software

c o l u m n i s t a

i n v i t a d o

¿Aún en
crisis?
Algunos mitos y desafíos
de la Ingeniería de
Software

Rubby Casallas

H

ace ya casi 40 años que
se trató por primera vez
el tema de la “crisis del
software” y se acuñó la
expresión Ingeniería de Software.
En ese momento fue identificado un
gran número de problemas derivados
de la utilización de métodos Ad Hoc
(el cicloprogramar-corregir). Hablar
entonces de Ingeniería de Software,
era expresar el deseo de contar con
prácticas más disciplinadas que remplazaran la manera artesanal como se
construían las aplicaciones.
Desde entonces ha habido evolución
y progresos en varios aspectos de
las prácticas de la construcción de
software. Pero también ha habido
muchos cambios en las tecnologías
y un aumento enlas expectativas de
los clientes y de los usuarios. La apa8 Sistemas

rición de Internet complicó, para los
desarrolladores, la implementación
de requerimientos no funcionales
como la escalabilidad, la seguridad,
la tolerancia a fallas o el manejo
transaccional en esquemas NegocioNegocio. Las necesidades crecientes
de software, el cambio en la manera
de hacer negocios, el tamaño cada
vezmayor de las aplicaciones y la
complejidad de los requerimientos no
funcionales hacen de la construcción
de software una disciplina retadora.
Significa que la crisis, aunque distinta, sigue ahí.
Esta crisis se evidencia porque una
gran cantidad de los proyectos fallan,
sobrepasan los costos y los tiempos
estimados. Hay muchos clientes y
usuarios insatisfechos porque la aplicación que seentregó no satisface

los requerimientos o porque sencillamente no funciona bien. Es usual encontrarse con proyectos que nunca se
terminan, nunca se utilizan o el costo
de mantenerlos es muy alto, dada la
dificultad de modificarlos ya sea para
corregir, extender o adaptar.
El gran mito
Dentro del deseo de acercarse a la
ingeniería para poder contar con
prácticas más disciplinadas,estaba el
hecho de querer definir los proyectos
de construcción de software de manera similar a como se definen muchos
proyectos de otras ingenierías.
Consideremos la construcción de un
puente como un ejemplo, que aunque
descrito de manera muy simplificada,
permite ilustrar la idea. Cuando se decide construirlo hay claridad sobre la
necesidad y el propósito. Seguramente se conocen el tráficoesperado, las
condiciones del terreno, el peso de la
superestructura, las cargas a las cuales estará sometido y muchos detalles
más. Conocidas las restricciones y
el contexto, le sigue la actividad de
diseño, en la cual los ingenieros especializados realizan cálculos, analizan
alternativas técnicas y económicas,
hacen simulaciones y verificaciones,
además de elaborar los planos deconstrucción.

Cuando el diseño está terminado,
se planifican en detalle las tareas de
construcción en diagramas de Gantt,
se establece el orden de las mismas
(localización topográfica, adecuación
del sitio, excavación, cimentaciones,
estribos, vigas, pavimento, protección lateral, entre otras). Una vez definidas y conocidos los rendimientos
en la ejecución de cada una de las
actividades seestima la duración de
las tareas, el tiempo total de la construcción y se asignan los recursos de
acuerdo con los roles. Todo esto pasa
a ser parte contractual del proyecto,
de estricto cumplimiento por parte
del contratista que ejecuta la obra.
En ejemplos como este hay que resaltar al menos cuatro supuestos básicos: (1) los requerimientos son claros
desde el principio; (2) los diseños sepueden elaborar de manera completa
(y validar) antes de la construcción;
(3) el proceso de construcción es predecible; y, por último, (4) hay gente
bien entrenada y especializada para
la realización de las distintas labores.
El mito es falso
Infortunadamente, en los proyectos
de construcción de software los supuestos mencionados no son válidos
por distintas razones. (1) Los requerimientos no...