MITOS DEL SOFTWARE

Mitos de gestin.
Los gestores con responsabilidad sobre el software, como los gestores en la mayora de
las disciplinas, estn normalmente bajo la presin de cumplir los presupuestos, hacer
que no se retrase el proyecto y mejorar la calidad.

Mito.
Tenemos ya un libro que est lleno de estndares y procedimientos para construir
software. No le proporciona ya a mi gente todo lo que necesita saber?

Realidad.
Est muy bien que el libro exista, pero se usa?, conocen los trabajadores su
existencia?, refleja las prcticas modernas de desarrollo de software?, es completo?
En muchos casos, la respuesta a todas estas preguntas es "no".

Mito.
Mi gente dispone de las herramientas de desarrollo de software ms avanzadas, despus
de todo, les compramos las computadoras ms modernas.

Realidad.
Se necesita mucho ms que el ltimo modelo de computadora grande (o de PC) para
hacer desarrollo de software de gran calidad. Las herramientas de ingeniera del
software asistida por computadora (CASE), aunque la mayora todava no se usen, son
ms importantes que el hardware para conseguir buena calidad y productividad.

Mito.
Si fallamos en la planificacin, podemos aadir ms programadores y adelantar el
tiempo perdido (el llamado algunas veces "concepto de la horda mongoliana").

Realidad.
El desarrollo de software no es un proceso mecnico como la fabricacin. En palabras
de Brooks [BRO75]: << ... aadir gente a un proyecto de software retrasado lo retrasa
an ms>>. Al principio, esta declaracin puede parecer un contra sentido. Sin embargo,
cuando se aaden nuevas personas, le necesidad de aprender y comunicarse con el
equipo puede y hace que se reduzca la cantidad de tiempo gastado en el desarrollo
productivo. Puede aadirse gente, pero slo de una manera planificada y bien
coordinada.

Mitos del cliente.

Un cliente que solicita una aplicacin de software puede ser una persona del despacho
de al lado, un grupo tcnico de la sala de abajo, el departamento de ventas o una
compaa exterior que solicita un software bajo contrato. Los mitos conducen a que el
cliente se cree una falsa expectativa y finalmente, quede insatisfecho con el que
desarrolla el software.

Mito.
Una declaracin general de los objetivos es suficiente para comenzar a escribir los
programes; podemos dar los detalles ms adelante.

Realidad.
Una mala definicin inicial es la principal causa del trabajo baldo en software. Es
esencial una descripcin formal y detallada del mbito de la informacin, funciones,
rendimiento, interfaces, ligaduras del diseo y criterios de validacin. Estas
caractersticas pueden determinarse slo despus de una exhaustiva comunicacin entre
el cliente y el analista.

Mito.
Los requisitos del proyecto cambian continuamente, pero os cambios pueden
acomodarse fcilmente, ya que el software es flexible.

Realidad.
Es verdad que los requisitos del software cambian, pero el impacto del cambio vara
segn el momento en que se introduzca. La Figura 1.5 ilustra el impacto de los cambios.
Si se pone cuidado al dar la definicin inicial, los cambios solicitados al principio
pueden acomodarse fcilmente. El cliente puede revisar los requisitos y recomendar las
modificaciones con relativamente poco impacto en el costo. Cuando los cambios se
solicitan durante el diseo del software, el impacto en el costo crece rpidamente. Ya se
han acordado los recursos a utilizar y se ha establecido un esqueleto del diseo. Los
cambios pueden producir trastornos que requieran recursos adicionales e importantes
modificaciones del diseo; es decir, costo adicional. Los cambios en la funcin,
rendimiento, interfaces u otras caractersticas, impacto importante sobre el costo.
Cuando se solicitan al final de un proyecto, los cambios pueden producir un orden de
magnitud ms caro que el mismo cambio pedido al principio.

Mitos de los desarrolladores.

Los mitos en los que an creen muchos desarrolladores se han ido fomentando durante
cuatro dcadas de cultura informtica. Durante los primeros das del desarrollo del
software, la programacin se vea como un arte. Las viejas formas y actitudes tardan en
morir.

Mito.
Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha
terminado. Realidad. Alguien dijo una vez: << cuanto ms pronto se comience a escribir
cdigo, tardara en terminarlo >>. Los datos industriales indican que entre el cincuenta y
el sesenta por ciento de todo el esfuerzo dedicado a un programa se realizar despus de
que se le haya entregado al cliente por primera vez.

Mito.
Hasta que no tengo el programa << ejecutndose >> realmente no tengo forma de
comprobar su calidad.

Realidad.
Desde el principio del proyecto se puede aplicar uno de los mecanismos ms efectivos
para garantizar la calidad del software: la revisin tcnica formal. La revisin del
software es un << filtro de calidad >> que se ha comprobado que es ms efectivo que la
prueba, para encontrar ciertas clases de defectos en el software.

Mito.
Lo nico que se entrega al terminar el proyecto es el programa funcionando.

Realidad.
Un programa funcionando es slo parte de una configuracin del software que incluye
programas, documentos, y datos. La documentacin es la base de un buen desarrollo y,
lo que es ms importante, proporciona guas para la tarea de mantenimiento del
software.
Muchos profesionales del software reconocen la falacia de los mitos descritos
anteriormente. Lamentablemente, las actitudes y mtodos habituales, fomentan una
pobre gestin y malas prcticas tcnicas, incluso cuando la realidad dicta un mtodo
mejor. El reconocimiento de las realidades del software es el primer paso hacia la
formulacin de soluciones prcticas para su desarrollo.