Tiempo atrás hablábamos del ciclo de vida del software. El ciclo de vida del software es, básicamente, el proceso que sigue un software, desde que es un simple proyecto hasta que deja de utilizarse, pasando por estudiar su origen, sus funcionalidades, sus restricciones, realizar su diseño, "fabricarlo", probarlo, instalarlo, utilizarlo, mantenerlo... y casi cualquier cosa que podamos hacer con un producto manufacturado como un paquete de software.

No obstante, 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... los criterios que nos sugieren esa organización son las metodologías de desarrollo de software. Buenas o malas, son mejor que nada. En este artículo discutimos sobre la organización del ciclo de vida y las actividades que pueden formar parte del desarrollo de un producto de software y asímismo, presentamos el concepto de "metodología" y de "técnica".

Empecemos por el principio. Las fuentes de las que nace la idea de realizar un desarrollo de software (o un "proyecto", o un "sistema", como lo quieras llamar) son variadas, pero podríamos, a grandes rasgos concluir que terminan cayendo en grupos bien definidos.

LOS ORÍGENES DE UN PROYECTO

Por un lado están los proyectos de software que nacen para cubrir una necesidad concreta de una empresa u organización concreta de producción de bienes o servicios. Por ejemplo, un fabricante de galletas, una agencia de viajes, un club de golf o cualquier otra organización similar. Estas organizaciones, como cualquier otra, tienen necesidades de gestión de su información. Una gestión automatizada de algunos de sus procesos puede reportarles una mayor eficiencia, eficacia o competitividad. Así pues, los responsables barruntan un poco y deciden poner en marcha el desarrollo de un proyecto de software que cubra esa necesidad. Una vez decidido, caben dos alternativas: 1) dicho proyecto se encarga al departamento de IT de la propia empresa, si es que lo tiene o 2) no hay departamento de IT o no se les quiere encargar, con lo cual se recurre a una empresa externa que lo organice. También existen otras alternativas, que en según que casos no suelen dar buen resultado, como por ejemplo, combinar los esfuerzos del propio departamento de IT y de una empresa externa, o contratar a varias empresas externas.

Por otro lado, hay proyectos que no nacen en una empresa de bienes o servicios, sino que la idea la tienen empresas especializadas del sector de la informática. Por supuesto, también se intenta cubrir una necesidad, bien sea de empresas u organización de producción de bienes o servicios como de usuarios particulares, pero su intención es más generalista. Esa necesidad no es concreta. La empresa lanza la idea de un producto que pueda ser vendido con pocas modificaciones a más de un cliente, sea empresa o particular. En esta categoría caen todos los programas de los cuales se puede adquirir una unidad... desde los programas de ofimática a los juegos, pasando por todo tipo de utilidades, contabilidades, facturaciones... Probablemente, también podríamos incluir en este gran bloque las aplicaciones web, ya que aunque no se venden unidades, el usuario final es variado. Desde el punto de vista que estamos manteniendo, en todos esos casos, es la propia empresa de desarrollo la que fija el objetivo y funcionamiento del software, a diferencia de la categoría anterior, en la que la empresa que tiene la necesidad es la que fija el objetivo y funcionamiento del software.

¿Discutible? Pues claro que sí. La realidad siempre supera a cualquier clasificación, pero tenemos que mantener un cierto nivel de abstracción si queremos generalizar y obtener pautas.

LAS ACTIVIDADES DEL CICLO DE VIDA.

Una vez que se ha decidido que se va a construir un software, tanto si la idea ha nacido de una empresa u organización de producción con una necesidad como de una empresa de desarrollo de software con ánimo de obtener un producto generalista, es necesario realizar una serie de tareas que concluyan con un producto de software funcionando.

Tradicionalmente se ha hablado de que esas tareas (o actividades... vamos a considerar ambos términos como sinónimos) caen en una serie de grandes bloques: el ANÁLISIS, el DISEÑO, la PRODUCCIÓN y el MANTENIMIENTO del software. A grandes rasgos, puede ser verdad. En casos particulares, puede no serlo, pero en general es bueno tener una idea común de lo que significa un desarrollo del software. De hecho, tanto si estamos fabricando sofware como zapatos o galletas de limón, antes de lanzar un producto debemos saber QUÉ es exactamente lo que queremos hacer. Cuando lo tengamos decidido tendremos que decidir CÓMO se hará. Después, hay que CONSTRUIRLO, propiamente... y finalmente, hay que dar algún tipo de soporte al producto para que pueda MEJORAR y ACTUALIZARSE.

Pues dicho de otro modo, cada actividad involucrada en la producción del software cae en uno de estos bloques:

• Análisis: tener claro qué hay que hacer
• Diseño: decidir cómo se hace
• Producción: hacerlo
• Mantenimiento: mejorar y actualizarse

Bueno, vale... pero ¿Cuáles son las actividades que hay que hacer para obtener un producto de software, sea grande o pequeño?

Pues pueden ser muchas... pero empezaremos por un símil. ¿Cuales son las actividades necesarias para obtener un edificio? Pensemos, por un lado en una pequeña vivienda unifamiliar, un chalet pequeño o una casita de pueblo y por otro lado en un gran edificio de una urbanización, con muchos pisos, ascensores... ¿Qué cosas hay que hacer en cada uno? Bueno... seguro que hay muchas más cosas que hacer en el gran edificio que en la pequeña vivienda, pero podemos encontrar similitudes... actividades que hay que realizar en los dos, aunque a distinto nivel. Por ejemplo: diseñar los planos, obtener los permisos de construcción, hacer los cimientos, paredes, techos, estucar, alicatar, fontanería, electricidad... Por supuesto que los cimientos del gran edificio no son iguales que los de la pequeña vivienda, pero son actividades que hay que hacer en ambos casos.

Vale... pues volvamos al software. Al igual que en los edificios, no vamos a poder encontrar una lista exhaustiva de cosas que hay que hacer siempre... pero sí una lista de actividades más o menos comunes a todos los proyectos. Vamos con ella.

ACTIVIDADES DEL CICLO DE VIDA DEL SOFTWARE, ES DECIR, ACTIVIDADES COMUNES EN EL DESARROLLO DE UN PROYECTO DE 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. Por ejemplo, una zapatería, cuando vende un par de zapatos a un cliente lo hace siguiendo un proceso... que si cobro los zapatos, doy una factura de tal manera, lo anoto en el total de caja, lo descuento del almancen... 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. Aunque puede haber muchos tipos de pruebas, se suele hablar al menos de estos grandes tipos importantes:
  • Las pruebas unitarias, en las que un componente del software se prueba de manera individual. Es una tarea de producción.
  • Las pruebas de integración, en las que se prueba el funcionamiento conjunto de dos o más componentes del software. Es una tarea de producción.
  • Las pruebas de aceptación, en las que se verifica que el software está cumpliendo los requisitos iniciales. Es una tarea de análisis (o diseño, según se mire)
  • Las pruebas de carga, en las que se verifica que el sistema será capaz de soportar ampliamente la carga de trabajo que se exigirá. Es una tarea de producción (o diseño, según se mire).
  • Y, en mi humilde opinión, y aunque no se mencionan a menudo, las pruebas de robustez del diseño, en las que se verifica que el diseño es eficaz, eficiente, hace lo que se le pide y permite responder con solidez a situaciones imprevistas. Es una tarea de diseño.
• 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. Es una tarea de mantenimiento. Aunque en general, la palabra "error" cubre cualquier mal funcionamiento del software, se puede afinar un poco más, y localizar al menos tres orígenes de mal funcionamiento, y así hablar de:
  • Defecto: cuando alguna parte del producto del software no se ajusta a su diseño. En ese caso es apropiada la palabra "defecto", porque el software fué bien diseñado, pero al codificarlo, algo no se programó tal como fue diseñado. Por ejemplo, si compro una cafetera eléctrica y mi unidad falla porque una soldadura está incorrecta, digo que mi unidad está "defectuosa", aunque probablemente la cafetera fue bien diseñada.
  • Fallo: cuando alguna parte del producto de software no funciona convenientemente, debido a alguna circunstancia no prevista en el diseño. Por ejemplo, si en mi oficina en verano hay 50ºC y eso hace que el disco duro no funcione bien digo "el disco duro está fallando". Probablemente, el disco duro funcione bien en gran cantidad de ocasiones, pero el diseñador no previó que tuviera que funcionar a altas temperaturas.
  • Error: propiamente dicho, lo podemos dejar para aquellos malos funcionamientos de origen, en principio desconocido.

Estas y algunas otras son las que mencionan con caracter general los libros de ingeniería del software. ¿Discutibles? ¡Seguro! ¿Pueden haber más? ¡Seguro! ¿Y menos? ¡Seguro también! Pero tener un punto de partida en común para desarrollar software es mejor que no tener nada.

Bueno, vale... pero con esto todavía no sabríamos cómo abordar un proyecto de software.... por dónde se empieza, cómo se diseña, cuánta gente se necesita y cómo tienen que organizarse, cómo se escogen las herramientas, como se sabe cuándo se termina o cuánto nos va a costar.

Bien... para eso todavía nos hacen falta conocer un par de cosas más. En primer lugar, en la ingeniería del software existen una serie de técnicas para ayudar realizar cada una de las actividades descritas y otras muchas más que no hemos mencionado. Al igual que un fontanero conoce varias técnicas de soldadura o varias técnicas para empalmar desagües, nosotros tenemos varias técnicas para cada una de esas actividades. No es necesario dominarlas todas, y algunas son mejores que otras en unos contextos u otros. Estamos hablando de técnicas para representar la estructura de los datos, como por ejemplo los diagramas de Entidad/Relación o los diagramas de clases de UML, las técnicas para planificar el tiempo como PERT/CPM, las técnicas para estimar costes y esfuerzo productivo, las técnicas para realizar pruebas unitarias... en fin... un montón.

Pero con eso no es suficiente. Necesitamos un guión general que guíe el desarrollo de las actividades implicadas en la producción del software: qué debe hacerse antes o después, cómo debe hacerse, cómo debe organizarse el personal... es decir, un estilo, si me apuras, de organizar todo lo que hay que hacer en el ciclo de vida de desarrollo de un software concreto. Eso son las metodologías. A lo largo del tiempo numerosos autores y grupos de desarrollo nos han contado cómo creen que debe organizarse el desarrollo de un software en concreto. A cada una de esas historias les llamamos metodologías. Algunas metodologías han partido de profesores de universidad, autores de libros de renombre.... otras, de instituciones administrativas o gubernamentales... otras, de empresas de desarrollo de sofware... otras, de grupos independientes. Cada una tiene su propio nombre y su propio estilo. Algunas van bien para proyectos grandes, pesados y lentos, otras para proyectos pequeños, otras para proyectos que tienen un mantenimiento complicado, otras para proyectos que tienen que ayudar a sus usuarios a competir en un determinado mercado...  Algunas están exhaustivamente descritas, otras son una vaga descripción. Todas están marcadas por la ideología tecnológica de sus creadores y las tendencias del momento en el que fueron planteandas. En fin... hay una buena variedad.... en cualquier caso, y al margen de cualquier comparativa capciosa entre ellas, todas son, sin duda, bienintencionadas.... y a donde queremos llegar es que en general, la utilización de una metodología o la combinación de varias va a tener cosas buenas y malas... pero seguro que mucho mejores en conjunto que el no utilizar ninguna metodología en absoluto.

Pero eso lo dejamos para otro día... hablaremos de las principales metodologías, y dedicaremos una serie de artículos a algunas técnicas comunes.