Cargando...
 
Imprimir

Metodologías de desarrollo del software

Image
El concepto de metodología, dentro de la Ingeniería del Software es, sin duda, uno de los más oscuros y que más confusión 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 aplicación de una metodología brilla por su ausencia, siendo éste un concepto casi desconocido.

Además, la constante innovación tecnológica hace que cada vez sea necesaría la aplicación de nuevas metodologías adaptadas a los nuevos tiempos y, sin embargo, siguen figurando en los libros de texto viejas metodologías pensadas para viejos problemas... cosa que no sería necesariamente mala si las nuevas metodologías tuviesen también su lugar... pero a menudo no es así.

Y no es que haya una metodología claramente superior a las demás. Como ya hemos dicho en más de una ocasión, todas las metodologías son, en esencia, bienintencionadas. Obviamente, las más modernas responden a problemas y necesidades más actuales.

Afortunadamente, los tiempos van cambiando (aunque no de la misma manera para todo el mundo). La informática va madurando y tanto algunos profesionales de las tecnologías de la información 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 metódico: seguir una metodología.

En todo este tema sólo tengo una cosa clara: la ausencia de metodología en el desarrollo de un proyecto de software garantiza con seguridad también la ausencia de calidad.

¿Qué es una metodología de desarrollo del software?

Bueno... ya decíamos que la definición no es sencilla. Si autores de supuesto renombre llevan un montón de años en el tema y todavía no han logrado ponerse de acuerdo, no vamos a ser nosotros los que sentemos cátedra... pero una idea general quizá sí podamos aportar.

Ya comentamos que en el ciclo de vida del software se debían 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. (Véase, si procede, Las actividades del ciclo de vida del software )

Pues bien... cada una de esas tareas puede ser abordada y resuelta de múltiples maneras... con distintas herramientas y utilizando distintas técnicas. Es necesario saber cuándo podemos dar por concluida una tarea... quién debe realizarla... qué tareas preceden o anteceden a una dada... qué documentación utilizaremos para llevar a cabo esa tarea...

Estamos hablando de detalles organizativos... de un "estilo" de hacer las cosas... Pero yendo un poco más allá que un simple estilo, formalizando ese "estilo" añadiendo algo de rigurosidad y normas obtenemos una metodología.

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 descripción 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... ¿Cómo se hace?... ¿Con quién hay que entrevistarse? ¿Qué debo preguntar? ¿Cómo es el informe que debo escribir? ¿Quién lo va a leer? ¿Qué va a hacer con él? ¿Cuánto debo tardar? ¿Cuándo sé que he terminado?...

Si soy una persona medianamente desenvuelta podré responderme a esas preguntas yo mismo... pero entonces, estaría haciendo las cosas a mi manera... Eso quizá podría valer para un proyecto pequeño, en el que el equipo de desarrollo estuviera formado por dos o tres personas... pero en un proyecto de un tamaño razonablemente mediano o grande es absurdo... ¡Todo el mundo haría las cosas a su manera!
Lamentablemente, eso ocurre en proyectos reales todos los días.... generando proyectos fracasados, recursos perdidos y profesionales frustrados...

Volvamos a las metodologías: todos los integrantes de un equipo de desarrollo deben seguir un criterio común a la hora de realizar las tareas del ciclo de vida. Ese criterio, esa manera común es una metodología de desarrollo.

A lo largo de los años se han propuesto numerosas metodologías. Algunas han sido escritas por autores del ámbito académico... otras por autores del ámbito empresarial de desarrollo del software... otras por administraciones públicas...

Algunas metodologías están escritas en infumables tochos de heróica lectura. Otras, se describen en apenas unas pocas páginas.
Algunas metodologías intentan describirlo todo al detalle. Otras son más genéricas.

Algunas hacen hincapié en los datos... otras en los usuarios... otras en las tareas... otras en la documentación... o cualquier aspecto o combinación de aspectos que puedan darse en el desarrollo del software.

¿Qué metodología debo utilizar?

También es una pregunta de difícil respuesta.

Solo tengo una cosa clara, que voy a exponer con rapidez.

Hay una serie de metodologías que solemos llamar tradicionales propuestas casi todas ellas con anterioridad a los años 90 que pretendían 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 informático es casi una extensión de un proyecto burocrático tradicional. Así pues, los pasos que sugieren para llevar a cabo cada tarea, aunque bienintencionados, están cargados de burocracia, reiteraciones, ambigüedades... No suelen tener en cuenta cosas como la calidad, la satisfacción, la competitividad, los beneficios. Fueron metodologías creadas en los años 70-80 pensando en los negocios de los años 50.

El mundo va ahora mucho más rápido: sólo los negocios inteligentes sobreviven... sólo los proyectos de software inteligentemente construidos lo hacen también. Ahora las comunicaciones son instantaneas... mundiales. La información 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 más allá de los datos y los algoritmos.

La mayor parte de las metodologías tradicionales ya no funcionan. Están obsoletas desde casi todos los puntos de vista. Sólo algunas metodologías tradicionales han sido revisadas y adaptadas... y su funcionalidad suele estar limitada a proyectos no muy innovadores.

Las metodologías 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 metodología debe ser lo suficientemente precisa como para que todo el mundo la pueda seguir y sea de utilidad como pauta común, pero también debe ser lo suficientemente adaptable como para poder aplicarse en distintos proyectos, y lo suficientemente sencilla como para que no resulte muy gravosa su utilización, pero lo suficientemente completa y compleja como para que la utilización por parte del equipo sea provechosa... En una palabra: agilidad.

Aunque el término de agilidad es muy discutible, es indudable que las metodologías "modernas" responden a otra mentalidad completamente distinta.

Así a la pregunta de "¿Qué metodología utilizar?"... pues depende:
  • Si formas parte de un equipo de desarrollo en un proyecto grande y te toca decidir qué metodología hay que utilizar significa que tienes un puesto de responsabilidad. Escoge una metodología 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 deberías decidir qué metodología utilizar: alguien lo decidirá por tí. Si nadie toma esa decisión... ¡Mucho ánimo!... el proyecto en el que estás involucrado está destinado al fracaso.
  • Si formas parte de un equipo pequeño en un proyecto pequeño, lo mejor es consensuar la metodología a utilizar. Incluso, combinar buenas ideas de más de una.

¿Y qué metodologías hay?

Entre las metodologías tradicionales podemos citar:

  • Desarrollo de sistemas de Jackson (JSD). De los años 80. (artículo en wikipedia en inglés(external link))
  • Ingeniería de la información. De los 80 también (artículo en wikipedia en inglés(external link))
  • Structured System Analysis and Design Method (SSADM). También de los 80. Muy popular en Europa, ya que tiene su origen el Reino Unido. (artículo en wikipedia en inglés(external link))
  • Nuestra querida metodología METRICA, promovida por el Ministerio de las Administraciones Públicas. (Artículo en Wikipedia(external link)) (Página de la metodología(external link))
Algunas, como las dos primeras (Jackson, Ingeniería de la información), tienen un interés principalmente histórico. Otras, como SSADM o MÉTRICA, tienen cierta vigencia, en especial en lo que concierne a proyectos públicos.

Entre las metodologías modernas -unas más, otras menos- se puede destacar:

Hay muchas más, pero quizá éstas sean las más populares en el momento de escribir estas líneas. Personalmente recomendaría un cierto conocimiento general de al menos las cuatro últimas (Scrum, XP, RUP y AUP)

Por último: Cosas que NO son metodologías de desarrollo del software.

  • La "Programación estructurada" o la "Programación Orientada a Objetos" son paradigmas o modelos de programación. Indican pautas de comportamiento en los sistemas de programación... 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 METODOLOGÍAS.
  • Los términos "Ciclo de vida en espiral", "Incremental", en "Cascada", con "prototipo", etc... Indican esquemas generales de organización 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 antaño 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 METODOLOGÍAS.
  • El lenguaje UML (Unified Modeling Languaje) es un gran logro de la ingeniería. Aún con sus carencias, es algo muy importante: un lenguaje común 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 METODOLOGÍA. Sin embargo, algunas metodologías de las que hemos comentado, como RUP o METRICA hacen referencia a UML como herramienta para expresar ideas.

Ultima edición por vic .
Página última modificacion en Lunes 03 de Septiembre, 2012 17:09:42 CEST.



¿Dónde estoy?

Estás en La tecla de ESCAPE, un sitio web personal en el que nos gusta hablar de algoritmos, metodología de la programación, personajes de informática, tecnología, ingeniería del software, internet, y cualquier otra tontería que se nos ocurra.
Leer más / Términos de uso (ToS)

Este sitio web usa cookies para su funcionamiento. Navegar por éste sitio supone la aceptación de la política de cookies -
Política de cookies +