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.
