CICLO VITAL DEL SOFTWARE.






Introducción
Recomendamos encarecidamente al lector que consulte un texto dedicado a estos temas. Una obra muy agradable es la de Pressman .
En resumen, la complejidad de los programas ha ido creciendo de forma muy considerable con el paso del tiempo; de hecho, se puede decir que se ha producido una progresión aritmética en el aumento de complejidad del software. Esto es un hecho lamentable, si se tiene en cuenta que la complejidad del hardware ha crecido de forma exponencial. El resultado son unos programas mediocres que corren en un hardware cuyas prestaciones rayan en lo increíble. La razón de este deficiente crecimiento del software es fundamentalmente la dificultad que implica resolver mediante programas unas tareas cada vez más complejas. El ser humano se desborda, y no avanza más allá de ciertos límites que le vienen impuestos muy especialmente por las herramientas que maneja. El ingeniero de hardware, por otra parte, tiene en su haber una herramienta asombrosa: los circuitos integrados estandarizados. Existen circuitos integrados para casi cualquier tarea, y el ingeniero puede utilizarlos en sus diseños directamente, sin preocuparse por desarrollarlos. El resultado es, como ya se ha dicho, un crecimiento casi exponencial del rendimiento del hardware. El ingeniero de software, por su parte, no cuenta con tales herramientas, y su productividad se ve mermada en consecuencia. Al margen de esta Crisis del Software, existen ciertamente métodos que permiten llevar a buen puerto el desarrollo de programas (dentro de ciertos límites claro está). Estos métodos facilitan las diferentes fases del desarrollo de un programa; su estudio va más allá de los límites de este libro (véase el excelente libro de Meyer ), pero estas fases pueden y deben mencionarse aquí.

Análisis
En esta fase hay que englobar dos aspectos importanes: Lo dicho anteriormente sobre los nefastos efectos de los cambios imprevistos en los requisitos tiene un significado quizá poco evidente. Las dificultades que implican los cambios imprevistos no deben impulsarnos a poner trabas al cliente para realizar cambios: antes bien, deben impulsarnos a prever que el cliente podría muy bien necesitar cambios en las especificaciones . El cambio es un factor habitual en el desarrollo de produtos informáticos: no se trata de algo que haya que impedir, sino de una circunstancia perfectamente conocida de antemano, y frente a la cual debemos estar apercibidos. Véase, por ejemplo, la obra de Meyer ya mencionada.

Diseño
Una vez sabido qué hay que hacer, se pasa a investigar como hay que hacerlo, desde el punto de vista computacional. Es el momento de estudiar bloques funcionales, descripciones pormenorizadas de procesos y pasos a seguir: se pretende estudiar los algoritmos empleados para la realización de las distintas tareas, y las relaciones precisas que existen entre las diferentes entidades implicadas. Una vez tenida esta información, se estudiará el equipo físico (hardware) y el soporte lógico (programas) que se emplearán para construir el sistema. Entre otras cosas, la fase de diseño decide el lenguaje de programación que se empleará. Es preciso mencionar una peculiaridad: la fase de análisis y la fase de diseño son independientes por completo de todo lenguaje de programación. Esta decisión se toma únicamente al final de la fase de diseño, una vez que ya se dispone de toda la documentación anterior.
Los resultados de las fases de análisis y diseño son aspectos realmente valiosos del desarrollo de un proyecto, al menos tanto como el código fuente producido finalmente. Si el usuario decide realizar otro proyecto basado en este, será de más utilidad el análisis y el diseño previso que el código fuente elaborado. Bien podría ser que se optase por un cambio de lenguaje, y entonces el código fuente quedaría descartado o sufriría grandes modificaciones, a diferencia del análisis y diseño del sistema. Es frecuente hallar fallos de análisis en la fase de diseño. En tal caso es preciso volver atrás, rehacer el análisis y abordar de nuevo el diseño teniendo en cuenta los cambios efectuados. Consiguientemente, el ciclo vital del software es un proceso iterativo .

Implementación
La implementación no es otra cosa que el proceso de codificación, empleando el lenguaje seleccionado en la fase de diseño. Esta fase debería resultar muy sencilla, puesto que lo que hay que hacer y la forma de hacerlo son resultados perfectamente definidos en las fases anteriores. Nuestros objetivos serán múltiples: El orden de prioridades de las indicaciones anteriores es casi abierto, porque la corrección y robustez priman sobre las demás características, pero eso es todo lo que se puede decir. Cada proyecto impondrá sus propias reglas, y deberemos respetarlas para satisfacer las necesidades del cliente. Es frecuente hallar fallos de análisis y/o diseño en la fase de implementación. En tal caso es preciso volver atrás, rehacer el análisis y/o el diseño, y comenzar de nuevo la implementación teniendo en cuenta los cambios efectuados. El ciclo vital del software es un proceso iterativo .

Depuración
Ha llegado el momento de construir conjuntos de valores de pruebas; estos valores de pruebas contendrán valores correctos (extremos o intermedios) de resultados conocidos, y también valores incorrectos (para comprobar la robustez del programa). La fase de depuración suele exigir la contratación de personal no relacionado con la empresa, que utilizará el producto en una situación análoga a la de su implantación final, con objeto de detectar y corregir errores. Los datos de prueba empleados, y los resultados obtenidos, pasarán al Registro de Pruebas. Esta es una parte fundamental de la documentación del programa, que permitirá seguir el desarrollo del mismo en sus diferentes versiones. De esta manera se pasa por las fases alfa, beta y golden master (la última beta): hemos llegado a una verión x.0, que se comercializa. Es frecuente hallar fallos de análisis, diseño y/o implementación en la fase de depuración. En tal caso es preciso volver atrás, rehacer el análisis, el diseño y/o la implementación, y comenzar de nuevo la depuración teniendo en cuenta los cambios efectuados. El ciclo vital del software es un proceso iterativo . Por otra parte, la mejor técnica de depuración consiste en emplear métodos que dificulten la comisión de errores.

Mantenimiento
Cabría pensar que el delicado tratamiento que se ha dado a nuestro proyecto debería garantizar la virtual inexistencia de problemas su la llegada al mercado: a fin de cuentas, nuestros usuarios beta han probado exhaustivamente el producto y todo debería ir bien. Sin embargo, al cabo de unos seis meses de su entrada en el mercado, empiezan a llegar informes de nuestros clientes: Los costes asociados al mantenimiento de una aplicación suelen importar más del 50% de su coste total. Por tanto, todos los esfuerzos que realicemos por facilitar la labor de mantenimiento redundarán directamente en beneficio del proyecto global. Por si no ha quedado claro, El ciclo vital del software es un proceso iterativo .

Documentación
Se menciona en último lugar la documentación del proceso, que realmente se habrá ido construyendo a lo largo de todo el proceso. La documentación de un programa consta como mínimo de

Ah, si, además hay un pequeño detalle... se llama Manual del Usuario, y debe capacitar a una persona en su sano juicio (no sólo al programador) para hacer uso de todas las características y posibilidades del programa. Un buen manual del usuario es la clave de un programa que se vende bien, y por ende es fundamental para el éxito de la empresa. Esta rapidísima introducción querría iluminar fugazmente algunos aspectos de la programación que suelen resultar casi desconocidos para los programadores noveles. Ciertamente, las empresas de software intentan emplear cada vez más los métodos presentados aquí, con objeto de intentar que el rendimiento de la industria del software deje de ser catastrófico en comparación con la industria del hardware.