1.

Definicin de metodologa
Una metodologa es un conjunto integrado de tcnicas y mtodos que permite abordar de forma homognea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un proceso de software detallado y completo.

Las metodologas se basan en una combinacin de los modelos de proceso genricos (cascada, incremental). Definen artefactos, roles y actividades, junto con prcticas y tcnicas recomendadas.

2. Metodologas para el proceso de desarrollo

Segn Piattini (1996), se puede definir la metodologa de desarrollo como un conjunto de procedimientos, tcnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a realizar nuevo software. Normalmente consistir en fases o etapas

descompuestas en subfases, mdulos, etapas, pasos, etc. Esta descomposicin ayuda a los desarrolladores en la eleccin de las tcnicas a utilizar en cada estado del proyecto, facilitando la planificacin, gestin, control y evaluacin de los proyectos.

Tambin se tiene un consenso de otros autores sobre la definicin de metodologas para el desarrollo de software, los cuales dicen que, Una metodologa de desarrollo de software es un marco de trabajo que se usa para estructurar, planificar y controlar el proceso de desarrollo de sistemas de informacin. Una gran variedad de estos marcos de trabajo han evolucionado durante los aos, cada uno con sus propias fortalezas y debilidades. Una metodologa de desarrollo de sistemas no tiene que ser necesariamente adecuada para usarla en todos los proyectos. Cada una de las metodologas disponibles es ms adecuada para tipos especficos de proyectos, basados en consideraciones tcnicas, organizacionales, de proyecto y de equipo.

3. Necesidades y objetivos de las metodologa de desarrollo de software

Las metodologas de desarrollo de software persiguen tres necesidades principales:

Mejores aplicaciones, tendientes a una mejor calidad, aunque a veces no es suficiente. Un proceso de desarrollo controlado, que asegure uso de recursos apropiados y costo adecuado. Un proceso estndar en la organizacin, que no sienta los cambios del personal.

Las metodologas a veces tienen diferentes objetivos, pero los ms representativos pueden ser:

Brindar un mtodo sistemtico, de modo de controlar el progreso del desarrollo. Especificar los requerimientos de un software en forma apropiada. Construir productos bien documentados y de fcil mantenimiento. Ayudar a identificar las necesidades de cambio lo ms pronto posible. Proporcionar un sistema gil que satisfaga a todas las personas involucradas.

4. Ventajas del uso de una metodologa de desarrollo

Son muchas las ventajas que puede aportar el uso de una metodologa. A continuacin se van a exponer algunas de ellas, clasificadas desde distintos puntos de vista.

Desde el punto de vista de gestin:

Facilitar la tarea de planificacin

Facilitar la tarea del control y seguimiento de un proyecto

Mejorar la relacin coste/beneficio

Optimizar el uso de recursos disponibles

Facilitar la evaluacin de resultados y cumplimiento de los objetivos

Facilitar la comunicacin efectiva entre usuarios y desarrolladores

Desde el punto de vista de los ingenieros del software:

Ayudar a la comprensin del problema

Optimizar el conjunto y cada una de las fases del proceso de desarrollo

Facilitar el mantenimiento del producto final

Permitir la reutilizacin de partes del producto

Desde el punto de vista del cliente o usuario:

Garanta de un determinado nivel de calidad en el producto final

Confianza en los plazos de tiempo fijados en la definicin del proyecto

Definir el ciclo de vida que ms se adecue a las condiciones y caractersticas del desarrollo

5. Clasificacin de las metodologas

Segn la filosofa de desarrollo se pueden clasificar las metodologas en dos grupos. Las metodologas tradicionales, que se basan en una fuerte planificacin durante todo el desarrollo, y las metodologas giles, en las que el desarrollo de software es incremental, cooperativo, sencillo y adaptado.

Metodologas tradicionales

Las metodologas tradicionales son denominadas, a veces, de forma peyorativa, como metodologas pesadas.

Centran su atencin en llevar una documentacin exhaustiva de todo el proyecto y en cumplir con un plan de proyecto, definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las caractersticas importantes dentro de este enfoque, son los altos costes al implementar un cambio y la falta de flexibilidad en proyectos donde el entorno es voltil.

Las metodologas tradicionales (formales) se focalizan en la documentacin, planificacin y procesos (plantillas, tcnicas de administracin, revisiones, etc.)

Metodologas giles

Este enfoque nace como respuesta a los problemas que puedan ocasionar las metodologas tradicionales y se basa en dos aspectos fundamentales, retrasar las decisiones y la planificacin adaptativa. Basan su fundamento en la adaptabilidad de los procesos de desarrollo.

Estas metodologas ponen de relevancia que la capacidad de respuesta a un cambio es ms importante que el seguimiento estricto de un plan.

6. Diferencias entre metodologa agiles y tradicionales

En las metodologas tradicionales el principal problema es que nunca se logra planificar bien el esfuerzo requerido para seguir la metodologa. Pero entonces, si logramos definir mtricas que apoyen la estimacin de las actividades de desarrollo, muchas prcticas de metodologas tradicionales podran ser apropiadas. Es importante tener en cuenta que el uso de un mtodo gil no vale para cualquier proyecto. Sin embargo, una de las principales ventajas de los mtodos giles es su peso inicialmente ligero y por eso las personas que no estn acostumbradas a seguir procesos encuentran estas metodologas bastante agradables. En la tabla que se muestra a continuacin aparece una comparativa entre estos dos grupos de metodologas.

Metodologas giles Basadas en heursticas provenientes de prcticas de produccin de cdigo

Metodologas tradicionales Basadas en normas provenientes de

estndares seguidos por el entorno de desarrollo

Especialmente preparados para cambios durante el proyecto Impuestas internamente (por el equipo) Proceso menos controlado, con pocos principios No existe contrato tradicional o

Cierta resistencia a los cambios

Impuestas externamente Proceso mucho ms controlado, con

numerosas polticas/normas al Existe un contrato prefijado

menos es bastante flexible El cliente es parte del equipo de desarrollo El cliente interacta con el equipo de desarrollo mediante reuniones Grupos pequeos (<10 integrantes) y Grupos grandes y posiblemente distribuidos

trabajando en el mismo sitio

Pocos artefactos Pocos roles Menos nfasis en la arquitectura del software

Ms artefactos Ms roles La arquitectura del software es esencial y se expresa mediante modelos

7. Proceso de desarrollo pesado

WATCH, el cual es un marco metodolgico que describe los procesos tcnicos, gerenciales y de soporte que deben emplear los equipos de trabajo que tendrn a su cargo el desarrollo de aplicaciones de software empresarial (Montilva y cols., 2008). El mtodo WATCH est compuesto por tres modelos que describen los tres elementos claves de todo mtodo: el producto que se quiere elaborar, los actores que lo elaboraran y el proceso que los actores deben seguir para elaborar el producto, tal como se aprecia en la figura 2.

Figura. N 2. Componentes del Mtodo WATCH Modelo de productos Este modelo identifica y describe los tipos de productos que se deben generar durante el desarrollo de una aplicacin empresarial. Estos tipos de productos se elaboran durante la ejecucin de los procesos tcnicos, de gestin o de soporte, que estn descritos en el Modelo de Procesos del mtodo.

Modelo de actores El modelo de actores tiene como objetivos: identificar los actores o interesados (stakeholders) que estn involucrados en el desarrollo de aplicaciones empresariales; describir las modalidades de organizacin del equipo de trabajo que desarrollarn los diferentes componentes arquitectnicos de una aplicacin empresarial; y definir los roles y responsabilidades de aquellos actores que integrarn el equipo de trabajo, tal como se muestra en la figura 3.

Figura. N 3. Clasificacin de los actores Modelo de procesos El objetivo de este modelo es describir los procesos tcnicos, de gestin y de soporte que los equipos de trabajo deben emplear para desarrollar una aplicacin empresarial. Estos procesos se organizan en la forma de una cadena de valor. (Ver figura 4).

Figura. N 4. Procesos del mtodo WATCH

El orden en que los procesos del mtodo se ejecutan est inspirado en la metfora del reloj; metfora en la cual el proceso de desarrollo de software es visto como un reloj, cuyo motor son los procesos de gestin y soporte y cuyos diales constituyen los procesos tcnicos ya descritos. Esta metfora determina la estructura del modelo de procesos. Ver figura 5

Figura. N 5. Estructura del modelo de procesos

8. Proceso de desarrollo gil

La Programacin Extrema (XP, por eXtreme Pro- gramming) creada por Kent Beck (Wells, 2006), est basada en los valores de simplicidad, comunicacin, retroalimentacin y valor (coraje), que propone a los equipos de trabajo, la implantacin de prcticas simples que les permite recibir retroalimentacin de la situacin actual del proyecto y ajustar las prcticas a dicha situacin especfica (Jeffries, 2001). XP tiene como meta reducir el costo del cambio mientras que las metodologas tradicionales buscan que los requisitos sean determinados y establecidos al comienzo del proyecto de desarrollo procurando que as permanezcan de ah en adelante (Beck, 2000).

En el Proceso de Implementacin, englobado como un episodio de desarrollo protagonizado por equipos de dos programadores, se observa la auto-organizacin, la asigna- cin de las tareas a realizar, la comunicacin descentraliza- da con el cliente, la especificacin funcional en forma de casos de prueba, el diseo evolutivo en forma de refactori- zacin, el diseo detallado en forma de pruebas unitarias y el proceso de integracin de los componentes como activi- dad del da a da. XP propone prcticas para la construccin del software, entre ellas: Programacin guiada por pruebas (TDD);

Mejoras evolutivas del diseo (Refactorizacin); Integracin Continua; Pertenencia colectiva del cdigo; Diseo simple y Adhesin a estndares de codificacin.

El proceso de Verificacin relacionado con la revisin constante del producto, mediante la Programacin en Pares y la ejecucin contina de pruebas unitarias. El proceso de Integracin manifestado en la prctica de Integracin Con- tinua, que promueve la disponibilidad de una ltima versin del cdigo a la cual se le integran componentes ya probados de manera unitaria.

9. Similitudes y diferencias entre el proceso de desarrollo pesado watch y el

proceso de desarrollo agil XP

Similitudes Acuerdo en establecer como requisito previo, la existencia de algn tipo de diseo detallado (formal o informal) antes de iniciar la actividad de codificacin del producto de software. Se considera elemento crucial, la inclusin de pruebas unitarias sobre el producto y la definicin del modelo de procesos de desarrollo de software basado en pruebas, ya sea de manera explcita (giles) o de manera implcita (diseo de los casos de prueba antes de codificar en los tradicionales). Se promueve la existencia de estndares de codificacin y es vital la adhesin a dichos estndares por parte de los desarrolladores. El Cdigo fuente es objeto de revisiones regulares para asegurar su calidad, que es correcto y el grado de adhesin a los estndares de codificacin predefinidos.

Diferencias En representantes disciplinados, el documento de diseo detallado es necesario e incluye documentos y modelos. En la perspectiva gil, el diseo detallado se logra con la creacin de la prueba unitaria y con el cdigo fuente, legi- ble y documentado, sin que

se requiera algn documento o artefacto adicional. En representantes disciplinados, el proceso de integracin se realiza a posteriori a la codificacin de los componentes de la aplicacin, en tanto que en los giles este proceso es sustituido por la prctica de integracin continua. Como consecuencia de lo anterior, en los representantes tradicionales existen, de manera explcita, las pruebas de integracin, en tanto que en los giles, stas son pruebas no tan unitarias, que solo se distinguen de las reales por probar ms de un componente o por su integracin con algn componente externo. La Revisin Tcnica del cdigo es una prctica propuesta en el modelo CMMI para realizarla entre pares. En el mtodo WATCH la realiza un grupo de expertos organizados por el grupo de V&V. En el caso de los representantes giles, la revisin de pares, se plantea de manera continua y regular para asegurar la calidad del cdigo, sin que por ello se requiera una revisin adicional externa. Los representantes disciplinados presentan una diversidad de productos de trabajo, entre ellos, documentos y modelos de diseo resguardados y que deben ser actualizados ante cualquier cambio. En los giles, existe la temporalidad de los productos de trabajo, en algunos casos son descartables, y en otros no se prescriben como necesarios, reduciendo as la carga adicional de resguardo y actualizacin ante cambios. Todos los modelos disciplinados mencionan el proceso de documentacin como parte de la implementacin. Esta documentacin es operativa e incluye manuales de sistema, de usuario, ayuda en lnea y de diseo. El mtodo XP no propone documentacin alguna. Los mtodos giles incluyen la refactorizacin del cdigo, es decir, el cambio a discrecin del desarrollador para hacer que un cdigo complejo realice la misma funcionalidad, de manera ms sencilla. Esta actividad discrecional del desarrollador no aparece mencionada o propuesta por ninguno de los representantes disciplinado.