Metodologías pesadas de desarrollo software

Este recurso de aprendizaje es una lección creada originalmente como material didáctico del proyecto de aprendizaje Dirección y gestión de proyectos y sistemas informáticos.

En esta lección se abordan las metodologías pesadas más tradicionales para el desarrollo de software, procesos rigurosos con abundante documentación y formalismo pensada para garantizar la calidad a la hora de fabricar aplicaciones y sistemas muy sofisticados.

Introducción

En los inicios de la Informática, el desarrollo de software era prácticamente "artesanal" en su totalidad. Debido a la fuerte necesidad de mejorar el proceso y de hacer cumplir los objetivos deseados para los proyectos, tuvieron que importarse la concepción y fundamentos de metodologías existentes en otras disciplinas y adaptarlas al desarrollo de software. Algo muy habitual era dividir el desarrollo en fases secuenciales, donde una tras otra se realizaban las actividades propias del desarrollador (análisis, diseño, codificación y prueba).

Estas metodologías pesadas o tradicionales que se crearon, consistían en procesos rigurosos con abundante documentación. Procesos que permiten que el desarrollo de software sea más predecible y eficiente, como en el caso de una de metodologías más populares: el Proceso Unificado.

Metodologías pesadas populares

Entre las metodologías tradicionales más populares se encuentran el mencionado Rational Unified Process (RUP) o también Microsoft Solutions Framework (MSF), que centran su atención en mantener una documentación exhaustiva del proyecto y cumplir con el plan previsto y definido con precisión en la fase inicial del desarrollo del proyecto. Digamos que las metodologías tradicionales suelen enfatizar la documentación, la planificación y seguimiento riguroso de múltiples actividades (mediante plantillas, técnicas de administración, revisiones formales, etc.).

Aunque los modelos generalmente son realistas y están pensados para avanzar en la construcción del software de una manera iterativa e incremental, algunas de las características negativas dentro de estos enfoques son los altos costos de implementar cualquier cambio y el no ofrecer una buena solución para proyectos que operan en un entorno extremadamente incierto.

Arquitectura orientada a servicios

Ciclo de vida SOA

Varios de los modelos de proceso importantes se centran en la idea de "arquitectura", muy a menudo en arquitecturas de componentes o en las llamadas arquitecturas orientadas a servicios (Service-Oriented Architecture o SOA). Por eso en esta sección se explica brevemente lo que son las arquitecturas orientadas a servicios.

Un servicio es un componente que provee un conjunto de funciones de negocios. Conceptualmente son autónomos, opacos y bajamente acoplados.

Arquitectura de referencia

Arquitectura de referencia SOA

SOA permite que los servicios de información satisfagan más ágilmente las necesidades del negocio, cerrando cada vez más la brecha entre la estrategia del negocio y la tecnología subyacente al mismo. La idea es crear servicios basados en estándares, interoperables e independientes de un proveedor específico, para fomentar la reutilización de servicios que permitan crear eficazmente nuevas aplicaciones o funcionalidades en nuestro negocio.

Implementación

Para implementar SOA es necesario evaluar el grado de madurez de la organización y definir los grados que aspira alcanzar con el tiempo. Se comenzaría implementado un proyecto piloto, usando SOA para servicios simples que impacten únicamente un área del negocio. En el caso de sistemas heredados se podrían habilitar como servicios aquellas funciones de negocio que requiere el proyecto piloto, y esta sería una manera de ir introduciéndose en el uso de esta arquitectura.

Niveles de madurez

Nivel	Herramienta	Utilización
Nivel 6	SOA optimizadoa	Explotación
Nivel 5	Adopción empresarial de SOA	Explotación
Nivel 4	SOA repetible	Expansión
Nivel 3	Enfoque SOA definido	Expansión
Nivel 2	Adopción Ad Hoc de SOA	Exploración
Nivel 1	Ninguna adopción de SOA	Exploración

Lucasian: Un ejemplo de plataforma de servicios SOA

Servicios Web

Los Servicios Web (Web Services) juegan un papel importante en SOA, ya que brindan mecanismos independientes de la plataforma con los que exponer, descubrir e invocar servicios.

SOA requiere que un servicio:

Sea descubrible e invocable dinámicamente (como ocurre con UDDI, WSDL, SOAP...)
Tenga una definición del contrato independiente de plataforma (típicamente XML)
Pueda interoperar con otros servicios (por ejemplo mediante HTTP)

Comparativa con las metodologías ágiles

Si la estrategia de las metodologías tradicionales consiste en aplicar una combinación de procesos formales bien definidos para lograr obtener productos y resultados predecibles, en las ágiles, por el contrario, consisten en el desarrollo de software de manera más enfocada a resultados y a interacción entre los participantes del proyecto (desarrolladores, responsable de producto, cliente, usuarios...). Definen una estrategia flexible y holística del desarrollo del producto en la que el equipo trabaja como una unidad auto-organizada para alcanzar un objetivo común.

Ambas metodologías atacan el problema de mantener el conocimiento dentro de la organización, pero la más pesada pone el énfasis en la documentación y en los procesos, y la más ágil, en el software funcionando y en las personas.

La diferencia es hasta cierto punto "académica", algo muy tratado en libros de texto y debates teóricos, porque en la vida real todo gestor de proyecto tiene que llegar a un compromiso, a menudo quedándose en un punto intermedio. La documentación (diagramas, descripciones, explicaciones, comentarios en el código) es siempre de gran ayuda, a veces imprescindibles para conseguir implicar a una comunidad grande en el desarrollo de un software complejo. Pero indudablemente escribir documentación conlleva esfuerzo que reduce la productividad de los desarrolladores, que cuando son veteranos y experimentados, no requieren mucha gestión externa para ofrecer resultados de calidad rápidamente.

Conclusiones

El uso de metodologías "pesadas" o tradicionales ha sido fundamental durante muchos años en la historia del desarrollo de software. Todavía hoy siguen teniendo sentido para sistemas grandes y complejos, especialmente en organizaciones con un alto número de personas involucradas en estos proyectos. Sin embargo hay que tener muy presentes que en contextos como el actual, donde hay mucha variabilidad de plataformas, modelos de negocio e incertidumbre en general, es importante ser flexibles y ágiles para llegar adecuadamente con nuestros productos al cada vez más complejo mercado del software.

Lecciones relacionadas

Referencias

Proceso unificado de Rational
¿Metodologías pesadas o ágiles? (en español) (26 de noviembre de 2014) Consultado el 18 de marzo de 2014.