AGILA2: Acceso Generalizado a Internet desde LinEx Avanzado 2. Subproyecto 5

Transcripción

1 AGILA2: Acceso Generalizado a Internet desde LinEx Avanzado 2 Subproyecto 5 Estudio de nuevas metodologías aplicables al software libre y la adaptación sobre las métricas actuales. Javier Corral García y José Luis González Sánchez GÍTACA Grupo de Investigación de Ingeniería Telemática Aplicada y Comunicaciones Avanzadas UNIVERSIDAD DE EXTREMADURA

2 Índice de contenido I. Introducción...4 II. Análisis de las métricas más usadas en estos momentos en los desarrollos software La metodología catedral sobre el software libre La metodología bazar sobre el software libre Desarrollo de un proyecto Bazar, ventajas e inconvenientes Éxito frente al modelo catedral: Metodologías actuales aplicables a un proyecto Estructura general de Merise Estructura general de SSADM Estructura general de Métrica versión Métrica versión Metodologías ágiles Metodologías ágiles versus metodologías tradicionales Metodologías ágiles respecto a la metodología bazar XP (Programación extrema)...19 La programación extrema y el software libre Metodología Crystal Desarrollo de software adaptable Scrum Desarrollo manejado por rasgos Método de desarrollo de sistema dinámico...24 III. Diseño y propuesta de soluciones para los problemas planteados Propuesta de metodología y métrica a aplicar en un desarrollo software Por qué una metodología bazar? Por qué una metodología catedral? Entre la catedral y el bazar Seguridad por oscuridad Acercando el bazar a la catedral...28 Buscando la calidad del software...28 Community source...28 Hacia un modelo híbrido...29 Herramientas para la fase libre...31 IV. Conclusiones

3 3

4 I. Introducción E n el movimiento del software libre cada vez se va haciendo más necesario aplicar métodos e ideas tradicionales de ingeniería software, con el fin de alcanzar una calidad óptima del mismo, y al mismo tiempo mejorar la planificación y el tiempo de desarrollo. Partiendo del hecho de que actualmente muchas empresas se plantean la necesidad de aplicar algún tipo de metodología de desarrollo software, el presente documento pretende cubrir uno de los objetivos del proyecto Agila 2: impulsar el uso de métodos de ingeniería software, sin perder de vista los requerimientos especiales que tiene el software libre. De este modo, a través de un extenso y elaborado estado del arte, pretendemos orientar el desarrollo de una metodología que aporte calidad a cualquier proyecto software, sirviendo como medio para que toda empresa pueda seguir una estructura de buen método de desarrollo. La metodología de un proyecto de desarrollo software define siempre quién debe hacer qué, cuándo y cómo debe hacerlo. En concreto, la metodología es el conjunto de procedimientos, técnicas y herramientas además de una documentación adicional, que permite a los desarrolladores crear software. Puede seguir uno o varios modelos de ciclos de vida, los cuales indican qué es lo que hay que obtener a lo largo del desarrollo del proyecto, pero no cómo hacerlo. El movimiento del software libre, unido a la explosión mediática de Internet, supuso la aparición de nuevos métodos de desarrollo. Las nuevas metodologías rompían con lo establecido por las metodologías tradicionales, gestionadas por responsables que distribuyen y supervisan todo el trabajo de forma cerrada. En 1997, Eric S. Raymond escribió un ensayo a favor del software libre titulado The Cathedral & the Bazaar (La catedral y el bazar) [1]. En él, Raymond analizaba el surgimiento de GNU/Linux y un proyecto de software libre creado para comprobar las diferencias existentes entre los modelos de desarrollo tradicionales y los emergentes: el modelo de construcción cuidadoso y planificado de una catedral (del software propietario) y el bazar (del código abierto), en permanente crecimiento pero aparentemente caótico. Así, detallaba el enfoque cerrado desarrollado bajo una gestión centralizada propia de las empresas comerciales de software, con la comunidad global de código abierto responsable del desarrollo y éxito creciente de Linux. Por otro lado, las metodologías ágiles también se centran en una organización menos formal y jerárquica, intentando enfocar las metodologías tradicionales hacia los resultados y el factor humano, dando más valor al individuo y a la colaboración con el cliente, y eliminando actividades sobre la elaboración y mantenimiento de documentos formales de especificación que no tengan relación directa con el producto final. Mientras que la metodología bazar y las ágiles, tienen cada vez mayor éxito, las tradicionales no se han distinguido precisamente por ser exitosas, y menos aún por su popularidad, debido a su naturaleza burocrática que acaba retardando el ritmo del desarrollo en sí, siendo inadecuadas para proyectos donde el entorno sea volátil o los requisitos no se conozcan con exactitud. Sin embargo, las nuevas metodologías también se enfrentan a una serie de inconvenientes, como la falta de 4

5 intereses de los desarrolladores voluntarios, o la escasa confianza de los clientes en sistemas desarrollados de forma abierta, donde el código es accesible para cualquiera. Partiendo de que, ni la metodología bazar, ni la catedral son del todo correctas, y apoyándonos en el éxito de las metodologías ágiles así como de diversos estudios realizados con anterioridad por diversos autores, este documento justifica el aplicar al desarrollo tradicional los conceptos del software libre, de forma que, tanto desarrolladores como clientes acaben valorando los beneficios que podrían obtener creando comunidades al estilo bazar alrededor de los proyectos de desarrollo, liberando versiones constantemente de forma que pudieran ser testeadas frecuentemente, y evitando en la mayor medida posible, el problema de la seguridad por oscuridad que presenta la metodología catedral, sin subestimar la importancia de un diseño modular con un código de calidad óptima. 5

6 II. Análisis de las métricas más usadas en estos momentos en los desarrollos software 1. La metodología catedral sobre el software libre S e trata del método tradicional que, hoy en día, emplean la mayoría de los fabricantes de software. En el estilo catedral, el desarrollo de software está dirigido de manera centralizada, y el proceso de desarrollo está restringido a un grupo de programadores, quienes trabajan fuertemente en la depuración del código con la finalidad de que los usuarios puedan ver menos errores en cada versión producida [2]. Describimos a continuación sus características principales dentro del enfoque tradicional del software propietario: Software de gran tamaño construido (a semejanza de una catedral) de manera cuidadosa y planificada por expertos. Personal seleccionado previamente y en un número adecuado para desarrollar el proyecto, teniendo siempre en cuenta que a partir de un punto determinado, los costes aumentan al incrementarse excesivamente el número de personas involucradas, además de ralentizar el desarrollo en lugar de acelerarlo. Las versiones beta no son publicadas hasta prácticamente llegar al final del proyecto, debido principalmente a que de no ser así, contendrían innumerables errores. Dichos errores son muy difíciles de encontrar, y es por ello que se requiere una fase de pruebas al finalizar el desarrollo. El código fuente es propietario y nadie más puede tener acceso a él. La figura del jefe de proyecto es muy influyente en todo el desarrollo, debiendo ser especialmente clave en la fase de diseño. La Figura 1 muestra las principales fases del modelo de desarrollo tradicional: requisitos, diseño, implementación, pruebas y mantenimiento. 6

7 Figura 1: Modelo de desarrollo tradicional Los proyectos de software libre tienen cabida en esta metodología pese a que, a priori, podemos pensar que, este modelo de creación de catedrales, solo representa a procesos como el modelo de cascada clásico o las diferentes vertientes del Rational Unified Process. En este sentido, algunos proyectos abiertos también necesitan entregas espaciadas en el tiempo que siguen una planificación muy estricta, con pocas entregas de software y ciclos largos con varias etapas entre cada una de las entregas. Además, para Raymond [1], estos proyectos libres se encuentran fuertemente centralizados, ya que unas pocas personas son las que realizan el diseño e implementación del software. Las tareas que desempeñan estas personas, así como sus roles, están perfectamente definidos y alguien que quisiera entrar a formar parte del equipo de desarrollo necesitaría que se le asignara una tarea y un rol según las necesidades del proyecto [3]. Por último, en entornos tradicionales, un grupo de individuos conduce el desarrollo, mientras que los usuarios ni contribuyen ni tienen acceso al código. En el software libre, potencialmente cualquiera tiene el derecho a acceder y modificar el código fuente de una aplicación, sin embargo, y en este sentido, un sistema libre típico presenta una fase de catedral en la primera parte de su historia evolutiva [4]. 2. La metodología bazar sobre el software libre E n la metodología bazar, el desarrollo de software no es dirigido de manera centralizada, la construcción de la aplicación se realiza con la participación de una comunidad de interesados que libera frecuentemente cada versión desarrollada, con la finalidad de que otros puedan depurar el código [2]. Los principales beneficios de este modelo son una rápida evolución y depuración, independencia y disponibilidad permanente y la producción de un software estable de alta calidad y bien documentado. Detallamos a continuación sus características más destacables: A diferencia de la metodología bazar, al comenzar el desarrollo únicamente existe una idea, pero ésta no es del todo clara, y se va perfilando a medida que avanza el proyecto. 7

8 El código fuente es abierto y está disponible públicamente (cualquiera puede leerlo y modificarlo), y son frecuentes las liberaciones de versiones, aunque en la mayor parte de los casos, éstas estén incompletas o sean inestables. El proceso de depuración de un proyecto de software libre es sinónimo de la fase de mantenimiento del ciclo de vida tradicional de un proyecto software [4]. Un red de usuarios y desarrolladores revisa y modifica el código producido, de modo que el viejo dicho el trabajo compartido es más llevadero describe las razones por las que la mayoría de los proyectos de software libre tienen éxito [5]. El número de colaboradores que trabajan simultáneamente en el proyecto es ilimitado. Esto unido a la característica anterior, y al hecho de que la mayoría de ellos son además usuarios del propio software, hace que los errores estén siendo encontrados continuamente, con facilidad y de manera paralela al desarrollo. La estructura organizativa no está clara, de hecho, no suele existir jerarquía alguna en estos proyectos. Sí existen una serie de normas para poder participar en el proyecto, pero el compromiso es libre, pudiendo cada colaborador dedicarle el tiempo que estime oportuno. Los usuarios sin perfil técnico pueden sugerir nuevos requisitos, escribir documentación y tutoriales, o poner de manifiesto problemas de usabilidad [4]. A continuación veamos una tabla que enfrenta las principales características vistas en el desarrollo tradicional y en el de software libre: Desarrollo tradicional Construcción de catedrales: objetivos requerimientos planteados detalladamente antemano. Desarrollo de software libre y Colaboración en bazares: cada desarrollador de aporta las funcionalidades que estima recomendables. Jerarquía de liderazgo descendente. Liderazgo emergente, no impuesto. Asignación de tareas. Cada desarrollador es libre de elegir en qué trabajar. Equipos estables de tamaño controlado. Innumerables colaboradores, con alta rotación. Control estricto y seguimiento continuo de Disponibilidad total de los desarrolladores para actividades. invertir el tiempo que consideren oportuno. Desarrolladores ubicados generalmente en la Desarrolladores rara vez comparten localización misma localización. física. Motivación extrínseca. Motivación intrínseca. Tabla 1: Características de los desarrollos tradicionales y de software libre 2.1. Desarrollo de un proyecto Bazar, ventajas e inconvenientes Los proyectos bazar a menudo surgen por las necesidades de un usuario-desarrollador, y 8

9 suelen comenzarse a partir de trabajos ya realizados, siendo la reusabilidad de código básica en este tipo de modelo de desarrollo. A partir de ahí empieza a ser esencial la colaboración de los usuarios que se involucren en el proyecto, siendo importante la figura de los líderes, que deben cumplir una serie de características como son la humildad ante el resto de desarrolladores, la capacidad para motivarles, y la virtud de reconocer en ellos ideas mejores o innovaciones adecuadas para continuar el proyecto por otros caminos. La comunidad de voluntarios trabaja sobre el código fuente, modificando dicho código, las funcionalidades de la aplicación, reportando y corrigiendo errores y, solicitando nuevas características. Siendo enviado continuamente este trabajo a los líderes del proyecto, con el fin de añadirse al núcleo estable de la aplicación (Figura 2) [6]. Figura 2: Modelo de desarrollo bazar [6] Algunas críticas recibidas por el trabajo de Raymond [1] se basan en el hecho de que su obra es únicamente un ensayo, sin rigor científico y asistemático. Algunos críticos ven en Linux más un modelo de catedral que no un bazar, quejándose además del intento de Raymond de generalizar el caso de Linux a todo el software libre, donde creen que realmente existe una estructura piramidal de mando, con responsabilidades distribuidas aunque no de manera explícita. A primera vista resulta obvio pensar que una metodología como la que describimos se enfrenta siempre a una serie de desafíos, como puede ser el hecho de que los desarrolladores no participen en los proyectos bajo contratos laborales, sino que lo hagan libremente sin que ninguna autoridad centralizada defina sus funcionalidades. El desarrollo es distribuido por toda la red, con la dificultad que entraña coordinar a un innumerable grupo de colaboradores con alta rotación. Según Bruce Perens, líder del proyecto Debian en 1997, intentar liderar esta comunidad es como arrear gatos. A todo esto habría que añadir además el desafío que supone bazar frente a distintos paradigmas tradicionales. Por ejemplo la conocida como ley de Brooks : añadir más personal a un proyecto retrasado, lo retrasa más [7], que explica cómo la necesidad de intercomunicación se ve 9

10 minimizada por la elegancia del código y la modularidad del diseño, se contrapone directamente a la ley de Linus (bautizada por Eric S. Raymond [1]): dados muchos ojos, todos los errores serán obvios, que reduce de manera indiscutible la necesidad de un equipo dedicado a pruebas. Por contra, algunos estudios establecen que la aplicación de la ley de Linus puede llevar a problemas en el mantenimiento y la seguridad del software [8] [9], aludiendo al bajo número de contribuciones realizadas por gente realmente externa al desarrollo, es decir, colaboradores que no pertenecen al núcleo central que trabaja en los sistemas, debido a que ciertos proyectos a la larga desconfían de contribuciones externas, precisamente por miedo a la introducción de códigos con errores difíciles de encontrar. Raymond mantiene que si la citada ley no fuese cierta, un proyecto tan complejo como el kernel de Linux, habría fracasado por causa de interacciones imprevistas y errores muy profundos pasados inadvertidos durante el desarrollo del proyecto. Sin embargo, bastaría fijarse en la relativa ausencia de errores en el código de Linux para demostrar su certeza, y por añadidura, la superioridad del modelo de desarrollo del software libre frente al del software propietario. Así, mientras que en el modelo catedral usado en software propietario los errores suelen necesitar meses de revisión exhaustiva para comenzar a confiar en que todos han sido eliminados, en el bazar se asume a priori que los errores son evidentes o empiezan a serlo a raíz de que son publicados ante el innumerable grupo de colaboradores que participa en cada proyecto, liberándose versiones constantemente y bordeando así las desmoralizaciones que se sufren en el software propietario cuando las versiones largamente esperadas no resultan perfectas [1]. Otros paradigmas tradicionales a los que se enfrenta la metodología bazar son, por ejemplo, la ineficiencia de las líneas de código paralelas: que el software libre soluciona usando mecanismos de resolución de conflictos y una selección de la mejor opción; la criticidad de la ubicación física, frente a la minimización de la necesidad de comunicación entre desarrolladores como consecuencia de la modularidad y la autoexplicación del código; o, finalmente, el impacto causado por la alta rotación de desarrolladores: mitigado gracias a diseños sencillos y de calidad, en cuyos códigos es innecesaria la documentación adicional debido a su alta calidad Éxito frente al modelo catedral: Sin embargo, es evidente el éxito de la metodología bazar en proyectos como Linux, a la altura de los sistemas operativos comerciales más elaborados y con una notable presencia de sus servidores en la red. Como muestra de dicho éxito, basta con mencionar que entre las entidades que usan Linux se encuentra la Bolsa de Nueva York. Por otro lado, un estudio sobre la distribución Red Hat en su versión 7.1 reveló que ésta en particular posee más de 30 millones de líneas de código real. Utilizando el modelo de cálculo de costos COCOMO, puede estimarse que esta distribución requeriría programadores por año para su desarrollo. De haber sido desarrollado por medios convencionales de código cerrado, hubiera costado más de mil millones de dólares en los Estados Unidos [10]. Desde principios del año 2001 ha ido creciendo el apoyo y respaldo por parte de importantes fabricantes de hardware (como IBM, Sun Microsystems, Hewlett-Packard y Novell: preinstalando Linux en algunos modelos de portátiles y ordenadores de sobremesa), y el respaldo de compañías de software que permiten que aplicaciones como Nero, Java, Google Earth y Desktop, Adobe 10

11 Reader y Flash, RealPlayer y Yahoo! Messenger estén disponibles para Linux. De este modo, actualmente son bastantes las empresas de ámbito internacional que comercializan soluciones basadas en Linux, como IBM o Novell, así como miles de PYMES que ofrecen productos o servicios basados en esta tecnología. Otros proyectos ejemplos del buen funcionamiento de la tecnología bazar en el software libre son Samba y Apache. Samba implementa todos los protocolos de conectividad de Windows y su éxito hizo que compañías como Silicon Graphics, Sun e IBM lo usen como parte de sus estaciones de trabajo. Apache es desde 1996 el servidor HTTP más usado en la red, alcanzando en 2005 una cuota de mercado del 70%, posicionándose a fecha de Noviembre de 2008 en un 50.34%. En la Figura 3 podemos ver el número de sitios web para cada servidor a nivel mundial, donde Apache, en primer lugar, presenta sitios, Microsoft (con su producto IIS: Internet Information Server) en segundo lugar, alcanza el número de sitios y, Google en tercer puesto (producto GFE: Google Front End) con sitios. Figura 3: Número de sitios web por servidor (Ago00 Nov08) Fuente: 3. Metodologías actuales aplicables a un proyecto L a metodología de un proyecto de desarrollo software define siempre quién debe hacer qué, cuándo y cómo debe hacerlo. En concreto, la metodología es el conjunto de procedimientos, técnicas y herramientas además de una documentación adicional, que permite a los desarrolladores crear software. Puede seguir uno o varios modelos de ciclos de vida, los cuales indican qué es lo que hay que obtener a lo largo del desarrollo del proyecto, pero no cómo hacerlo. Por norma general consta de un conjunto de fases y subfases: módulos, etapas, pasos, etc., de forma que los desarrolladores son guiados a la hora de seleccionar las técnicas a usar en cada estado del proyecto, facilitándoles la planificación, gestión, control y evaluación de los proyectos. De esta 11

12 forma, especifica: cómo se debe dividir un proyecto en etapas, qué tareas hay que realizar en cada etapa, qué salidas se producen y cuándo, qué restricciones se aplican, qué herramientas se utilizan, cómo se gestiona y controla un proyecto. Por tanto, la metodología representa el camino para desarrollar la aplicación software de manera sistemática, sirviendo de manual o guía puesta en práctica al abordar la construcción de un sistema. Las metodologías usan un ciclo de vida determinado y siguen las fases de especificación, diseño, etc. de un modo concreto, algunas incluso apoyadas por herramientas hechas a medidas. Lamentablemente no existe una metodología de software universal, dadas las características particulares de cada proyecto: equipo de desarrollo, recursos, etc.. Además, en el desarrollo convencional (sin metodología) los resultados finales son impredecibles, ya que no hay forma de controlar lo que está sucediendo en el proyecto, afectando los cambios organizativos de forma negativa en el proceso de desarrollo. Las características deseables y destacables de cualquier metodología son las siguientes: Existencia de reglas predefinidas. Cobertura total del ciclo de desarrollo. Verificaciones intermedias. Planificación y control. Comunicación efectiva. Utilización sobre un abanico amplio de proyectos. Fácil formación. Herramientas CASE. Actividades que mejoren el proceso de desarrollo. Soporte para el mantenimiento. Soporte para la reutilización de software. Las metodologías (tanto comerciales como en el ámbito académico y de investigación) pueden ser agrupadas en estructuradas y orientadas a objetos. En el enfoque estructurado podemos destacar Métrica versiónes 2 y 3, Merise, SSADM, etc. y en el enfoque orientado a objetos: Métrica versión 3 (en parte), RUP, XP, etc. Veamos a continuación las principales metodologías de desarrollo estructuradas gubernamentalmente: Merise en Francia, SSADM en Reino Unido, y finalmente Métrica 3 en España Estructura general de Merise MERISE empezó a sentar sus bases en 1972 gracias a un equipo universitario de ingenieros de Aix-en-Provence, viendo la luz la primera versión a finales de En Septiembre de 1977, el proyecto fue iniciado por el Centre Technique Informatique del Ministerio de Industria Francés para cubrir las necesidades de las empresas, así como de la propia administración, finalizando en Mayo de 1978 y estableciendo MERISE como metodología de análisis y diseño de sistemas de 12

13 información. Esta metodología aportó un ciclo de vida más largo que los existentes hasta la fecha, materializándose en un conjunto definido de etapas, e incluyendo dos ciclos complementarios, uno de abstracción y otro de decisión. El primero recoge el proyecto en base a tres niveles de abstracción: conceptual, organizativo y físico. Distinguiéndose además dos subniveles en cada nivel: un modelo de datos y otro de tratamientos. Las fases de la metodología MERISE son: Estudio preliminar. Estudio detallado. Implementación. Realización y puesta en marcha Estructura general de SSADM El gobierno británico planteó la necesidad de crear una metodología que desarrolló posteriormente entre la Central Computing Telecommunications Agency (CCTA) y Learmonth and Burchett Management Systems (LBMS), dando como resultado la metodología SSADM (Structures Systems Analysis and Design Method). Los aspectos más destacables de SSADM son: Énfasis en los usuarios: sus requisitos y participación. Definición del proceso de producción: qué hacer, cuándo y cómo. Tres puntos de vista: datos, eventos y procesos. Máxima flexibilidad en herramientas y técnicas de implementación. SSADM proporciona un conjunto de procedimientos para llevar a cabo el análisis y diseño, pero tiene grandes carencias. En concreto, no cubre aspectos como la planificación estratégica ni entra en la construcción del código Estructura general de Métrica versión 2 Se trata de una metodología propuesta por el Ministerio de Administraciones Públicas del Gobierno de España, para que todas las organizaciones sigan el mismo modelo, y unificar de esa forma los criterios para lograr una mayor homogeneidad y eficiencia en las aplicaciones informáticas. Métrica versión 2 surgió a raíz de una revisión realizada sobre el proyecto inicial de Métrica, con el objetivo básico de obtener una nueva versión, debido a varios motivos: principalmente por 13

14 mejorar la versión anterior fechada en 1989, responder a la demanda por parte de los centros informáticos de una referencia para el desarrollo de sistemas de información, contar con una metodología compatible con EuroMétodo, y finalmente aprovechar un mercado de herramientas CASE que había crecido ampliamente desde que se realizó la primera versión de Métrica. Fue diseñada por un grupo de trabajo constituido por personal procedente de distintos ministerios y organismos de la administración española, con la asistencia externa de la empresa Coopers & Lybrand. Se trata de una guía formal, aunque flexible en su utilización, para la planificación, análisis, diseño y construcción e implantación de sistemas software, empleando conceptos y técnicas de ingeniería de sistemas y tecnología de la información [11]. Para construir en base a Métrica versión 2, es necesario pasar por unas etapas intermedias que aseguran la calidad en la aplicación que está siendo construida, mediante la elaboración de un marco homogéneo de referencia (para verificar que los productos creados tengan niveles aceptables de calidad), y el cumplimiento de las previsiones iniciales de plazo y costes Métrica versión 3 [12]: Métrica 3 es actualmente la metodología oficial de desarrollo de aplicaciones informáticas de la administración española. Comenzando su elaboración en 1996, su punto de partida es la versión 2.1 mencionada anteriormente. Se trata de una metodología mixta, pues cubre tanto el desarrollo estructurado como el orientado a objetos, e incluye procesos como los interfaces (que no forman parte de lo que se entiende como ciclo de vida). Además, tiene en cuenta la tecnología cliente/servidor y el desarrollo de interfaces gráficas de usuario (IGU). Está basada en el modelo de procesos del ciclo de vida de desarrollo ISO/IEC (Information Technology Software Life Cycle Processes) así como en la norma ISO/IEC SPICE (Software Process Improvement And Assurance Standars Capability Determination), y otros estándares que se muestran en la Figura 4. Figura 4: Composición de Métrica Versión 3 Los objetivos que persigue son, principalmente: proporcionar un marco estratégico para el desarrollo de los sistemas de información dentro de las organizaciones; enfatizar el análisis de requisitos para que, de esta forma, los productos satisfagan las necesidades de los usuarios; mejorar 14

15 la productividad de los departamentos de sistemas de información, permitiendo una mayor adaptabilidad a los cambios y reutilización; desarrollar procesos que permitan una comunicación más fluida entre todos los miembros involucrados en la producción de software; y facilitar la operación y mantenimiento de los productos obtenidos. Métrica 3 por una parte consta de procesos principales: relativos a la planificación, desarrollo y mantenimiento de los sistemas de información, y por otra, de interfaces que definen actividades orientadas a la mejora y perfeccionamiento de los procesos principales, con el fin de garantizar la consecución del objetivo del desarrollo. De esta forma, cada proceso se divide en actividades, teniendo cada actividad una descripción y una tabla de tareas propias. Cada tarea a su vez tiene la correspondiente descripción, definiendo los productos de entrada que necesita, los que genera de salida, así como las prácticas necesarias para llevar a cabo la tarea y los participantes. Una de las principales características de Métrica 3 es que es flexible en su estructura, al no ser obligatorio seguir todos los procesos o actividades, es decir, se adapta en función de las necesidades de cada proyecto. Tampoco es necesario realizar dichas actividades secuencialmente, ya que en ocasiones será deseable realizar su ejecución en paralelo. Del mismo modo que ISO/IEC 12207, Métrica está orientada al proceso, siendo en su versión 3 los siguientes: Planificación de Sistemas de Información (PSI). Desarrollo de Sistemas de Información (DSI). Dividido a su vez en cinco subprocesos: Estudio de Viabilidad del Sistema (EVS). Análisis del Sistema de Información (ASI). Diseño del Sistema de Información (DSI). Construcción del Sistema de Información (CSI). Implantación y Aceptación del Sistema (IAS). Mantenimiento de Sistemas de Información (MSI). Además, como hemos mencionado anteriormente, proporciona también cuatro interfaces que definen actividades orientadas a mejorar y perfeccionar los principales procesos, cara a garantizar la consecución del objetivo del desarrollo. En concreto se trata de la Gestión de Proyectos (GP), Seguridad (SEG), Aseguramiento de la Calidad (CAL) y Gestión de la Configuración (GC). Por otro lado, distingue entre las técnicas de desarrollo, en las que engloba los casos de uso, diagramas de clases y de flujo de datos, etc.; las técnicas de gestión de proyectos, donde entrarían las técnicas de estimación, staffing size, planificación, etc.; y las prácticas: análisis de impacto, presentaciones, prototipado, etc Metodologías ágiles El desarrollo ágil de software es un paradigma basado en procesos ágiles, que intenta evitar los inconvenientes de las metodologías tradicionales, promoviendo iteraciones en el desarrollo a lo 15

16 largo de todo el ciclo de vida del proyecto, y enfocándose hacia los resultados y el factor humano. Esta es la filosofía de las metodologías ágiles, las cuales dan mayor valor al individuo, a la colaboración con el cliente, y al desarrollo incremental del software con iteraciones muy cortas. Es decir, al igual que el software libre, se centran en una organización menos formal y jerárquica y más centrada en la persona, de forma que se produzca un sistema de gestión con la cantidad correcta de funcionalidades, incluyendo el sistema final el número mínimo de características necesarias para satisfacer al cliente. Además, eliminan actividades sobre la elaboración y mantenimiento de documentos formales de especificación que no tengan relación con el producto final. Pese a ser enfoques muy diferentes, las metodologías de desarrollo ágiles y el software libre presentan muchas concordancias como, por ejemplo, los principios y valores básicos [13]. Así, se asemejan en varios puntos: las bases de ambas aproximaciones se establecieron hace bastantes años, sin embargo han cobrado interés de un tiempo a esta parte, tanto la metodología del software libre [14], como las ágiles. Ambas rompen con lo establecido en las metodologías tradicionales, y lo que es más importante, han tenido éxito (basta referenciar los proyectos MozillaFirefox [15] y C3). Este enfoque está mostrando su efectividad en proyectos con requisitos muy cambiantes, y cuando se exige reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. Las metodologías ágiles están revolucionando la manera de producir software y, a la vez, generando un amplio debate entre sus seguidores y quienes, por escepticismo o convencimiento, no las ven como alternativa para las metodologías tradicionales. La Figura 5 [16], muestra una gráfica que expresa como crece el coste de introducir cambios, conforme avanza la vida del proyecto, en proyectos de enfoque tradicional, y en aquellos desarrollados mediante metodologías ágiles. Figura 5: Coste de introducir cambios en proyectos de enfoque tradicional y de metodologías ágiles [16] En este apartado se presenta resumidamente el contexto en el que surgen las metodologías ágiles, sus valores, principios y comparación con las metodologías tradicionales. Además, se 16

17 describen brevemente las principales propuestas, especialmente Programación Extrema (extreme Programming, XP) la metodología ágil más popular en la actualidad [17]. Estas metodologías están especialmente orientadas para proyectos que necesitan de una solución a medida, con una elevada simplificación, y sin dejar de lado el aseguramiento en la calidad del producto. Las metodologías ágiles se centran en el factor humano y el producto software, es decir, dan más valor al individuo, a la colaboración del cliente y al desarrollo incremental del software con iteraciones muy cortas [18]. Partiendo de ahí, la base de cualquier metodología ágil es siempre minimizar los riesgos, desarrollando software en periodos cortos de tiempo. De este modo, el software desarrollado en una unidad de tiempo es denominado iteración (del ciclo de vida), debiendo durar ésta del orden de una a cuatro semanas. Asimismo, cada iteración incluye planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. Un punto importante es que cada iteración no debe añadir demasiada funcionalidad, pero sí ser en sí mismo una versión incompleta pero sin errores, volviendo a evaluar las prioridades del proyecto al finalizar dicha iteración. El manifiesto ágil está fundamentado en una serie de valores: se orienta al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas, siendo las personas el principal factor de éxito de un proyecto software, de forma que es más importante construir previamente un buen equipo de trabajo y dejar que sea éste quien construya el entorno de desarrollo en base a sus necesidades; es más esencial la idea de desarrollar software que funciona, que conseguir una buena documentación (la regla es no producir documentos, a menos que sean necesarios de forma inmediata para tomar una decisión importante); hay que dar más importancia a la colaboración con el cliente que a la negociación de un contrato, de forma que exista una interacción constante entre el cliente y el equipo de desarrollo, lo que marcará la marcha del proyecto, asegurando su éxito; por último, responder a los cambios más que seguir estrictamente un plan, pues la habilidad de responder a los cambios que puedan surgir a lo largo del proyecto (en los requisitos, en la tecnología, en el equipo) es otro factor que determina el éxito o fracaso del mismo, por lo tanto la planificación no debe ser estricta sino flexible y abierta [18] y [19]. Por otro lado, los métodos ágiles suelen ser criticados debido a su documentación técnica: escasa y poco disciplinada, debido a que dan prioridad a las comunicaciones cara a cara en lugar de a la documentación formal. Los equipos desarrolladores suelen estar localizados en una oficina abierta, denominadas habitualmente plataformas de lanzamiento (bullpen), donde tienen cabida revisores, diseñadores de iteración, escritores de documentación y ayuda, así como directores de proyecto Metodologías ágiles versus metodologías tradicionales A continuación se muestra una tabla comparativa con las principales diferencias entre las metodologías tradicionales y las recientes metodologías ágiles: 17

18 Metodologías tradicionales Metodologías ágiles Normas de estándares seguidos por el entorno Heurísticas de prácticas de producción de de desarrollo. código. Resistencia a los cambios. Preparadas para cambios durante el desarrollo del proyecto. Reglas de trabajo impuestas externamente. Reglas de trabajo impuestas por el propio equipo. Proceso controlado, con numerosas políticas y Proceso menos normas. principios. Contrato previo. controlado, con pocos Flexibilidad en los contratos debido a la preparación para responder a los cambios. Distintas reuniones del cliente con el equipo de El cliente es parte del equipo de desarrollo. desarrollo, durante determinadas etapas del proyecto. Grupos grandes y distribuidos en diferentes Grupos pequeños trabajando en el mismo sitio. tareas. Más artefactos y roles. La arquitectura software es expresándose mediante modelos. Pocos artefactos y roles. esencial, Menos énfasis en la arquitectura del software. Tabla 2: Metodologías tradicionales versus metodologías ágiles Metodologías ágiles respecto a la metodología bazar Software libre (bazar) Metodologías ágiles El desarrollo se basa en la colaboración entre desarrolladores de todo el mundo. Las interacciones suelen realizarse a través del correo electrónico, pero las individualidades de cada programador son obvias. Más importancia de los recursos humanos y las relaciones entre ellos, frente a procesos y herramientas. Sin embargo, al contrario que en el software libre, se incentiva la conciencia de equipo. La principal documentación del proyecto reside en el propio código fuente, de donde se extraerá la documentación técnica necesaria para cada momento. El código fuente en sí, es la base principal de toda la documentación. El software operativo es más importante que toda la documentación burocrática, no relacionada con el producto final, propia de las metodologías tradicionales. El personal involucrado en el proyecto suele Es más importante la colaboración con el compaginar roles de desarrollador y cliente, de cliente que el propio contrato o su negociación forma que es como si el propio cliente en sí en sí. fuera quien desarrollase el sistema. El desarrollo y evolución del proyecto es Se trata de una metodología preparada para guiado por el cliente. Inicialmente no tienen un responder ante cualquier cambio en contra del diseño fijo definido, si no que suele ser un seguimiento de la planificación inicial. diseño básico que va creciendo a medida que se va desarrollando el proyecto. Tabla 3: Metodologías ágiles respecto a la metodología bazar 18

19 Como hemos mencionado con anterioridad, es obvio que ambos enfoques presentan numerosos planteamientos en común. La tabla anterior muestra otra comparativa, en este caso con las concordancias entre las metodologías ágiles y el software libre. A continuación, veremos métodos derivados del ágil entre los que se encuentra Scrum, Crystal Clear (cristal transparente), Programación extrema, desarrollo de software adaptativo, feature driven development, y el método de desarrollo de sistemas dinámicos XP (Programación extrema) Se trata de una metodología ágil centrada en potenciar las relaciones interpersonales como clave para el éxito en desarrollo de software, promoviendo el trabajo en equipo, preocupándose por el aprendizaje de los programadores, y propiciando un buen clima de trabajo. La programación extrema se basa en cuatro principios básicos: realimentación continua entre el cliente y el equipo de desarrollo, comunicación fluida entre todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar los cambios. Se define especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes [20]. Sin duda, la metodología de programación extrema está siendo la más utilizada de todas las metodologías ágiles. Se basa en esos cuatro valores principales que hemos mencionado: comunicación, retroalimentación, simplicidad y coraje, estableciendo la comprobación como fundamento del desarrollo, de forma que cada programador escribe pruebas durante la producción de su código, que van siendo integradas en el proceso de forma constante. XP construye así un proceso de diseño evolutivo, que se basa en volver a refactorizar un sistema simple en cada iteración. Todo el diseño se centra en la iteración actual y no se hace nada anticipadamente para necesidades futuras. El resultado es un proceso de diseño disciplinado, lo que es más, combina la disciplina con adaptabilidad de una manera que, indiscutiblemente, la hace la más desarrollada entre todas las metodologías adaptables [21]. La técnica usada por XP para especificar los requisitos del software se denomina historias de usuario. En ella se utilizan formatos, a través de los cuales, el cliente describe las características que desea que tenga el sistema, refiriéndose tanto a requisitos funcionales como no funcionales, de una forma breve y explícita, de forma que cada historia pueda ser implementada por los programadores en unas semanas. Por otro lado, esta metodología hace uso de los siguientes roles: programador, que además de desarrollar el código escribe las pruebas unitarias; cliente, que escribe las historias de usuario mencionadas, y además describe las pruebas funcionales de las mismas; encargado de pruebas: ayuda al cliente a escribir las pruebas funcionales; encargado de seguimiento, que va verificando el acierto producido en las estimaciones para ver si coincide el tiempo real con el estimado y, realiza el seguimiento del proceso en cada iteración; entrenador, responsable del proceso global, que vigila que se siga el proceso correctamente; consultor: miembro externo del equipo con conocimientos externos específicos; y, por último, el gestor: vínculo entre cliente y programadores. Con todo lo anterior, veremos a continuación el proceso que sigue la metodología XP. En todas las iteraciones de este ciclo tanto el cliente como el programador aprenden. No se debe 19

20 presionar al programador a realizar más trabajo que el estimado, ya que se perderá calidad en el software o no se cumplirán los plazos. De la misma forma el cliente tiene la obligación de manejar el ámbito de entrega del producto, para asegurarse que el sistema tenga el mayor valor de negocio posible con cada iteración [18]: 1. El cliente define el valor de negocio a implementar. 2. El programador estima el esfuerzo necesario para su implementación. 3. El cliente selecciona qué construir, de acuerdo con sus prioridades y las restricciones de tiempo. 4. El programador construye ese valor de negocio. 5. Vuelve al paso 1. Figura 6: Proceso de la metodología XP [18] La programación extrema y el software libre Existe un nivel considerablemente alto de solapamiento entre los valores adoptados por las metodologías ágiles y la programación extrema en particular, y los enumerados por Raymond [1], sobre el desarrollo de código abierto [13]. Los pilares básicos en los que se sostiene la programación extrema y que mencionábamos anteriormente guardan gran relación con el software libre: Retroalimentación continua entre el cliente y el equipo de desarrollo: la metodología bazar describe la retroalimentación entre los desarrolladores, y entre estos y los clientes (Raymond expresa en sus reglas: Lo más grande después de tener buenas ideas es reconocer las buenas ideas de sus usuarios. Esto último es a veces lo mejor, y publique rápido y a menudo y escuche a sus clientes [1]). Comunicación fluida entre todos los participantes: precisamente el ideal del software libre está basado en compartir ideas mediante el código fuente, principal elemento de la comunicación entre los desarrolladores. Raymond [1] destaca la necesidad de la comunicación y las habilidades sociales para llevar a cabo un proyecto de manera exitosa. Simplicidad en las soluciones implementadas: en una de las reglas de Raymond expone: La perfección (en diseño) se alcanza no cuando ya no hay nada que añadir, si no cuando ya no hay algo que quitar [1]. 20