El término ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propósito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo.
No existe un proceso "industrial" estándar de fabricación de software. Cada caso es un mundo y puede resolverse de mil maneras, pero sin embargo, sí hay unas pautas generales para organizar el proceso, unas actividades que se repiten una y otra vez en la construcción de cualquier software. Esas actividades necesitan de una cierta organización en su realización.
Actividades del ciclo de vida del software.
- Identificación del sistema. Puede parecer una tontería, pero es más importante de lo que parece. Hay que saber qué es lo que se quiere hacer y qué es lo que no se quiere hacer. A la hora de desarrollar un producto de software siempre hay algo más que se puede hacer. En la realidad unas cosas están enlazadas con otras, y si se quiere contemplar todo en el software se puede convertir en una bestia difícil de manejar e inútil. Es necesario establecer LÍMITES. Fijar lo que debe hacer el sofware y lo que no. Qué datos debe manejar y cuáles no. Con quién o qué se debe comunicar y con quién o qué no. Esta es una tarea de análisis.
- Toma de requisitos. Tradicionalmente se ha llamado así a la actividad de plasmar por escrito o gráficamente, pero de manera lo más formal posible todas aquellas cosas que el software debe poder hacer. Entendemos por "formal" una forma de expresarse lo más completa posible y sin ambigüedades, es decir, con poco o ningún margen a la interpretación. Esta también es una tarea de análisis, que suele dar como resultado uno o más documentos conocidos como Especificación de Requisitos del Software (SRS). Existe un intento de estandarización del SRS por parte del IEEE, el conocido como IEEE-STD-830-1998, aunque sus recomendaciones son útiles como punto de partida, su aplicacion total es bastante discutible.
- Estudio de procesos. Todas las organizaciones basan su trabajo en procesos. Digamos que son rutinas más o menos establecidas para tratar un determinado asunto. El estudio de procesos se basa en identificar cuáles son esos procesos, para qué sirven, quién los realiza. Es una actividad de análisis. Suelen utilizarse diagramas gráficos para esta labor, como por ejemplo, los antiguos DFD, o los actuales diagramas de UML.
- Reingeniería de procesos. La gran olvidada en la producción del sofware. A menudo, los procesos empresariales están viciados por la tradición, la costumbre y la burocracia. Es bueno pararse a pensar si un proceso puede reorganizarse e incluso obtener otro equivalente de tal manera que el resultado siga siendo el mismo pero de manera más eficiente e incluso más eficaz. En muchos casos puede hacerse. Eso es la reingeniería. Si un proceso es ineficiente o ineficaz y se automatiza directamente, lo único que conseguiremos es que se muestre más rápidamente su ineficiencia o ineficacia.
- Diseño: Las actividades de diseño cubren todo tipo de decisiones, pero especialmente las relacionadas con "cómo va a ser el software"... de qué grandes partes constará, qué tecnología utilizará, cómo se interrelacionan los datos que va a utilizar. Por hacer un simil con la arquitectura, el diseño es al proyecto de sofware como los planos son a un edificio. También forma parte del diseño el decidir qué pequeñas piezas forman el todo: cuál es la función de cada una de ellas y cómo se comunica con las demás. El punto de partida para el diseño es la especificación de requisitos (SRS).
- Planificacion: Cuando se conoce el diseño, es necesario decidir cómo se organizará el trabajo hasta la conclusión del proyecto, desde el punto de vista de la administración de recursos, tanto humanos como materiales, y del tiempo, el espacio y el dinero. Es una tarea de diseño.
- Codificación/Implementación/Programación. Tres nombres para la misma cosa. Nos referimos a la programación propiamente dicha de cada uno de los pequeños componentes que formarán el software, siguiendo el diseño. Cada componente debe realizar la función que se le exige, y debe comunicarse con otros componentes de la manera que haya sido fijada en el diseño. Es una tarea de producción.
- Integración. Integrar es unir dos o más componentes del proyecto de sofware y verificar que todo funciona según lo diseñado, prestando especial atención al funcionamiento conjunto de los componentes. Integrando, integrando... se obtiene el proyecto entero. Es una tarea de producción.
- Pruebas: Las pruebas son muy importantes en el desarrollo del sofware. Consisten en verificar que lo que se está haciendo va bien.
- Implantación. Implantar un software es ponerlo en marcha en su ubicación definitiva. Es una tarea de producción.
- Explotación. No es una actividad o tarea en sí. Se denomina así al hecho de utilizar el sistema y sacarle partido.
- Mejora. Cuando el sistema está en explotación, es decir, en marcha, a veces es necesario introducir mejoras. Es una tarea de mantenimiento.
- Ampliación. Al igual que con las mejoras, a veces es necesario introducir nuevas funcionalidades (requisitos) en el producto de software cuando ya está en marcha. Es una tarea de mantenimiento.
- Corrección de errores. Los errores suelen aparecer con frecuencia en el software cuando está ya en marcha, aun cuando se dedique gran cantidad de esfuerzo a las pruebas.
Estas y algunas otras son las que mencionan con caracter general los libros de ingeniería del software.
No hay comentarios:
Publicar un comentario