Metodologas de desarrollo del software

Detalles
El concepto de metodologa, dentro de la Ingeniera del Software es, sin duda, uno de los ms oscuros y que ms confusin produce tanto en estudiantes como en profesionales involucrados en procesos de desarrollo de software. Tanto es as, que en muchos proyectos de desarrollo (no todos, por supuesto), la aplicacin de una metodologa brilla por su ausencia, siendo ste un concepto casi desconocido. Adems, la constante innovacin tecnolgica hace que cada vez sea necesara la aplicacin de nuevas metodologas adaptadas a los nuevos tiempos y, sin embargo, siguen figurando en los libros de texto viejas metodologas pensadas para viejos problemas... cosa que no sera necesariamente mala si las nuevas metodologas tuviesen tambin su lugar... pero a menudo no es as. Y no es que haya una metodologa claramente superior a las dems. Como ya hemos dicho en ms de una ocasin, todas las metodologas son, en esencia, bienintencionadas. Obviamente, las ms modernas responden a problemas y necesidades ms actuales. Afortunadamente, los tiempos van cambiando (aunque no de la misma manera para todo el mundo). La informtica va madurando y tanto algunos profesionales de las tecnologas de la informacin como algunos de sus clientes se van dando cuenta de que se hace necesario seguir unas ciertas pautas predefinidas en el desarrollo del software de calidad: es decir, llevar un comportamiento metdico: seguir una metodologa. En todo este tema slo tengo una cosa clara: la ausencia de metodologa en el desarrollo de un proyecto de software garantiza con seguridad tambin la ausencia de calidad.

Qu es una metodologa de desarrollo del software?

Bueno... ya decamos que la definicin no es sencilla. Si autores de supuesto renombre llevan un montn de aos en el tema y todava no han logrado ponerse de acuerdo, no vamos a ser nosotros los que sentemos ctedra... pero una idea general quiz s podamos aportar. Ya comentamos que en el ciclo de vida del software se deban completar una serie de tareas para obtener un producto de software. A menudo, se dice que los distintos componentes de software deben pasar por distintas fases o etapas durante el ciclo de vida. (Vase, si procede, "Las actividades del ciclo de vida del software") Pues bien... cada una de esas tareas puede ser abordada y resuelta de mltiples maneras... con distintas herramientas y utilizando distintastcnicas. Es necesario saber cundo podemos dar por

concluida una tarea... quin debe realizarla... qu tareas preceden o anteceden a una dada... qu documentacin utilizaremos para llevar a cabo esa tarea... Estamos hablando de detalles organizativos... de un "estilo" de hacer las cosas... Pero yendo un poco ms all que un simple estilo, formalizando ese "estilo" aadiendo algo de rigurosidad y normas obtenemos una metodologa. Por ejemplo: en el desarrollo de cualquier software, es necesario pasar por la etapa de "Toma de requisitos" (es decir, enterarnos de lo que hay que hacer). Por supuesto, tenemos muchas cosas que hacer para lograrlo: entrevistarnos con clientes, usuarios... tomar notas, escribir informes... Claro que s! Pero esa descripcin de la tarea es muy vaga. Cuando nos ponemos manos a la obra y hay que enfrentarse a la toma de requisitos de un proyecto real surgen mil detalles... Cmo se hace?... Con quin hay que entrevistarse? Qu debo preguntar? Cmo es el informe que debo escribir? Quin lo va a leer? Qu va a hacer con l? Cunto debo tardar? Cundo s que he terminado?... Si soy una persona medianamente desenvuelta podr responderme a esas preguntas yo mismo... pero entonces, estara haciendo las cosas a mi manera... Eso quiz podra valer para un proyecto pequeo, en el que el equipo de desarrollo estuviera formado por dos o tres personas... pero en un proyecto de un tamao razonablemente mediano o grande es absurdo... Todo el mundo hara las cosas a su manera! Lamentablemente, eso ocurre en proyectos reales todos los das.... generando proyectos fracasados, recursos perdidos y profesionales frustrados... Volvamos a las metodologas: todos los integrantes de un equipo de desarrollo deben seguir un criterio comn a la hora de realizar las tareas del ciclo de vida. Ese criterio, esa manera comn es una metodologa de desarrollo. A lo largo de los aos se han propuesto numerosas metodologas. Algunas han sido escritas por autores del mbito acadmico... otras por autores del mbito empresarial de desarrollo del software... otras por administraciones pblicas... Algunas metodologas estn escritas en infumables tochos de herica lectura. Otras, se describen en apenas unas pocas pginas. Algunas metodologas intentan describirlo todo al detalle. Otras son ms genricas. Algunas hacen hincapi en los datos... otras en los usuarios... otras en las tareas... otras en la documentacin... o cualquier aspecto o combinacin de aspectos que puedan darse en el desarrollo del software.

Qu metodologa debo utilizar?

Tambin es una pregunta de difcil respuesta. Solo tengo una cosa clara, que voy a exponer con rapidez.

Hay una serie de metodologas que solemos llamar tradicionales propuestas casi todas ellas con anterioridad a los aos 90 que pretendan ayudar a los profesionales indicando pautas para realizar y documentar cada una de las tareas del desarrollo del software. Sin embargo, tienen casi todas ellas un gran problema: asumen que un proyecto informtico es casi una extensin de un proyecto burocrtico tradicional. As pues, los pasos que sugieren para llevar a cabo cada tarea, aunque bienintencionados, estn cargados de burocracia, reiteraciones, ambigedades... No suelen tener en cuenta cosas como la calidad, la satisfaccin, la competitividad, los beneficios. Fueron metodologas creadas en los aos 7080 pensando en los negocios de los aos 50. El mundo va ahora mucho ms rpido: slo los negocios inteligentes sobreviven... slo los proyectos de software inteligentemente construidos lo hacen tambin. Ahora las comunicaciones son instantaneas... mundiales. La informacin fluye en tiempo real. Las empresas compiten al segundo. El software ya tiene una cierta historia. Hemos aprendido mucho. Utilizamos conceptos abstractos para construir sistemas que van mucho ms all de los datos y los algoritmos. La mayor parte de las metodologas tradicionales ya no funcionan. Estn obsoletas desde casi todos los puntos de vista. Slo algunas metodologas tradicionales han sido revisadas y adaptadas... y su funcionalidad suele estar limitada a proyectos no muy innovadores. Las metodologas surgidas desde los 90 hasta aqu suelen tener otra mentalidad... una cierta agilidad. Siendo conscientes de lo cambiante y amplio que es el mundo del software, una metodologa debe ser lo suficientemente precisa como para que todo el mundo la pueda seguir y sea de utilidad como pauta comn, pero tambin debe ser lo suficientemente adaptable como para poder aplicarse en distintos proyectos, y lo suficientemente sencilla como para que no resulte muy gravosa su utilizacin, pero lo suficientemente completa y compleja como para que la utilizacin por parte del equipo sea provechosa... En una palabra: agilidad. Aunque el trmino de agilidad es muy discutible, es indudable que las metodologas "modernas" responden a otra mentalidad completamente distinta. As a la pregunta de "Qu metodologa utilizar?"... pues depende:

Si formas parte de un equipo de desarrollo en un proyecto grande y te toca decidir qu metodologa hay que utilizar significa que tienes un puesto de responsabilidad. Escoge una metodologa moderna, bien definida, que d respuesta a las necesidades del proyecto. Si formas parte de un equipo de desarrollo en un proyecto grande y no ocupas un puesto de responsabilidad, no deberas decidir qu metodologa utilizar: alguien lo decidir por t. Si nadie toma esa decisin... Mucho nimo!... el proyecto en el que ests involucrado est destinado al fracaso. Si formas parte de un equipo pequeo en un proyecto pequeo, lo mejor es consensuar la metodologa a utilizar. Incluso, combinar buenas ideas de ms de una.

Y qu metodologas hay?
Entre las metodologas tradicionales podemos citar:

Desarrollo de sistemas de Jackson (JSD). De los aos 80. (artculo en wikipedia en ingls) Ingeniera de la informacin. De los 80 tambin (artculo en wikipedia en ingls) Structured System Analysis and Design Method (SSADM). Tambin de los 80. Muy popular en Europa, ya que tiene su origen el Reino Unido. (artculo en wikipedia en ingls) Nuestra querida metodologa METRICA, promovida por el Ministerio de las Administraciones Pblicas. (Artculo en Wikipedia) (Pgina de la metodologa)

Algunas, como las dos primeras (Jackson, Ingeniera de la informacin), tienen un inters principalmente histrico. Otras, como SSADM o MTRICA, tienen cierta vigencia, en especial en lo que concierne a proyectos pblicos.

Entre las metodologas modernas -unas ms, otras menos- se puede destacar:

Rapid Application Development (Desarrollo rpido de aplicaciones - RAD). (artculo en wikipedia en ingls) Scrum (artculo en wikipedia en ingls) Extreme programming. (Programacin extrema - XP) (artculo en wikipedia en ingls) Rational Unified Process. (Proceso Racional Unificado - RUP) (artculo en wikipedia en ingls) Agile Unified Process. (Proceso gil Unificado - AUP) (artculo en wikipedia en ingls)

Hay muchas ms, pero quiz stas sean las ms populares en el momento de escribir estas lneas. Personalmente recomendara un cierto conocimiento general de al menos las cuatro ltimas (Scrum, XP, RUP y AUP)

Por ltimo: Cosas que NO son metodologas de desarrollo del software.

La "Programacin estructurada" o la "Programacin Orientada a Objetos" son paradigmas o modelos de programacin. Indican pautas de comportamiento en los sistemas de programacin... no tienen nada que ver con el ciclo de vida del software ni la manera en la que debe realizarse cada tarea para un proyecto concreto... as pues... NO SON METODOLOGAS. Los trminos "Ciclo de vida en espiral", "Incremental", en "Cascada", con "prototipo", etc... Indican esquemas generales de organizacin en las tareas del ciclo de vida, unas con respecto a otras y con respecto a otros aspectos como el tiempo, los requisitos o el riesgo. Actualmente se denominan "PATRONES" del ciclo de vida del software, aunque antao fueron denominados simplemente distintos "Ciclos de vida". Indican ideas estructurales sencillas en el proceso de desarrollo, y no la manera en la que debe realizarse cada tarea del ciclo para un proyecto concreto... as pues... NO SON METODOLOGAS. El lenguaje UML (Unified Modeling Languaje) es un gran logro de la ingeniera. An con sus carencias, es algo muy importante: un lenguaje comn para que todos los profesionales del desarrollo de sistemas -de software o no- expresen sus ideas... pero el UML no le indica a nadie la manera de realizar las cada tarea en un proyecto concreto: tan solo es una herramienta para expresar ideas... as pues... NO ES UNA METODOLOGA. Sin embargo,

algunas metodologas de las que hemos comentado, como RUP o METRICA hacen referencia a UML como herramienta para expresar ideas.