Mitos del Software

Mito: El gerente del Proyecto piensa: Tenemos un libro lleno de estándares y procedimientos para elaborar software. ¿No le dará a mi personal todo lo que necesita saber?

Realidad: Tal vez exista el libro de estándares, pero ¿se utiliza? ¿Saben de su existencia los trabajadores del software? ¿Refleja la práctica moderna de la ingeniería de software? ¿Es completo? ¿Es adaptable? ¿Está dirigido a mejorar la entrega a tiempo y también se centra en la calidad? En muchos casos, la respuesta a todas estas preguntas es “no”. No he conocido un solo Jefe que me haya entregado un libro teórico para que lo lea. Y cuando sea Jefe de un proyecto, no me veo recomendando libros a mis colaboradores.

Mito: Si nos atrasamos, podemos agregar más programadores y ponernos al día.

Realidad: El desarrollo del software no es un proceso mecánico similar a la manufactura. Agregar personal a un proyecto de software atrasado lo atrasará más. A medida que se agregan personas, las que ya se encontraban trabajando deben dedicar tiempo para enseñar a los recién llegados, lo que disminuye la cantidad de tiempo dedicada al esfuerzo de desarrollo productivo. Pueden agregarse individuos, pero sólo en forma planeada y bien coordinada. Y puede ocurrir que se agreguen personas, que nadie les enseñe, y pasen 2 o 3 meses sin aportar.

Mito: Si decido subcontratar el proyecto de software a un tercero, puedo descansar y dejar que esa compañía lo elabore.

Realidad: Si una organización no comprende cómo administrar y controlar proyectos de software internamente, tendrá dificultades cuando subcontrate proyectos de software. Y lo más probable es que pague demasiado por los servicios de una organización tercera, que pueden ser realizados por personal de la propia empresa.

Mito: Para comenzar a escribir programas, es suficiente el enunciado general de los objetivos. Podremos entrar en detalles más adelante.

Realidad: Aunque no siempre es posible tener el enunciado exhaustivo y estable de los requerimientos, un “planteamiento de objetivos” ambiguo es una receta para el desastre. Los requerimientos que no son ambiguos (que por lo general se obtienen en forma iterativa) se desarrollan sólo por medio de una comunicación eficaz y continua entre el cliente y el desarrollador. Es probable que en algunos casos no se realice correctamente la toma de requerimientos. El desarrollador debe estar preparado para estos casos.

Mito: Los requerimientos del software cambian continuamente, pero el cambio se asimila con facilidad debido a que el software es flexible.

Realidad: Es verdad que los requerimientos del software cambian, pero el efecto que los cambios tienen varía según la época en la que se introducen. Cuando se solicitan al principio cambios en los requerimientos (antes de que haya comenzado el diseño o la elaboración de código), el efecto sobre el costo es relativamente pequeño. Sin embargo, conforme pasa el tiempo, el costo aumenta con rapidez: los recursos ya se han comprometido, se ha establecido la estructura del diseño y el cambio ocasiona perturbaciones que exigen recursos adicionales y modificaciones importantes del diseño.

Mito: Una vez que escribimos el programa y hacemos que funcione, nuestro trabajo ha terminado.

Realidad: Alguien dijo alguna vez que “entre más pronto se comience a ‘escribir el código’, más tiempo tomará hacer que funcione”. Los datos de la industria indican que entre 60 y 80% de todo el esfuerzo dedicado al software ocurrirá después de entregarlo al cliente por primera vez.

Mito: Hasta que no se haga “correr” el programa, no hay manera de evaluar su calidad.

Realidad: Uno de los mecanismos más eficaces de asegurar la calidad del software puede aplicarse desde la concepción del proyecto: la revisión técnica. Las revisiones del software son un “filtro de la calidad” que se ha revelado más eficaz que las pruebas para encontrar ciertas clases de defectos de software.

Mito: El único producto del trabajo que se entrega en un proyecto exitoso es el programa que funciona.

Realidad: Un programa que funciona sólo es una parte de una configuración de software que incluye muchos elementos. Son varios los productos terminados (modelos, documentos, planes) que proporcionan la base de la ingeniería exitosa y, lo más importante, que guían el apoyo para el software.

Mito: La ingeniería de software hará que generemos documentación voluminosa e innecesaria, e invariablemente nos retrasará.

Realidad: La ingeniería de software no consiste en producir documentos. Se trata de crear un producto de calidad. La mejor calidad conduce a menos repeticiones, lo que da como resultado tiempos de entrega más cortos.