Metodologías de Desarrollo de Software Contenido 4.1 Metodologías 4.2 Metodologías conducidas por los planes 4.3 Metodologías ágiles 4.4 Diferencias de enfoque 4.5 Diferencias de aplicabilidad a plicabilidad 4.6 Conclusión 4.7 Referencias
Objetivos Aprend nder er el conc concep eptto de proc proces eso o de desa desarr rrol ollo lo y meto metodo dolo logí gía. a. • Apre
• Aprender las diferentes alternativas de organización de un proyecto de acuerdo al tipo de sistema que se va a construir y al tipo de organización que que enca encarrga el sis sistema tema en desa desarr rrol ollo lo.. • Aprender las diferentes alternativas de organización de un proyecto de acuerdo a las capacidades de los profesionales participantes y al tipo de org organiz anizac ació ión n en la cual cual se lle lleve adel adelan antte el proy proyec ectto.
4.1 Metodologías Una metodología es un marco de trabajo que puede ser utilizado como guía de las actividades que se van a llevar a cabo. Por lo tanto, una metodología de desarrollo de software no es más que una forma de trabajo para desarrollar software, donde se especifican las tareas que se van a llevar a cabo, los artefactos por generar y las relaciones entre ambos. Este marco o forma de trabajo permite organizar el proceso de desarrollo de software a través de la definición de pautas que se deben seguir y restricciones por cumplir. Las reglas y limitaciones especificadas son propias de cada metodología. En consecuencia, existe una amplia variedad de metodologías definidas, cada una con ventajas y limitaciones inherentes al contexto de aplicación. Es decir que no existe una metodología que pueda ser aplicada perfectamente en todos los contextos de trabajo.
4.1 Metodologías 4.1.1 Historia En la década del 50 el software se desarrolló a medida para cada aplicación y fue utilizado por la misma persona u organización que lo había desarrollado. No se reali ealizzaba aba ning ningún ún tipo tipo de plan planif ific icac ació ión n ni docu docume ment ntac ació ión. n. La dist distri ribu buci ción ón del del soft softw ware are era ínfima. No existía una metodología de desarrollo definida: se codificaban y se corr corregí egían an los erro errore ress encon encontr trado ados. s. Desd Desde e med mediad iados de los los 60 el avanc ance de la tecnol cnolo ogía, gía, jun junto con la multi ultip program gramac ació ión ny los los sist sistem emas as mult multiu iusu suar ario io,, aume aument ntar aron on el desa desarr rrol ollo lo de soft softw ware are y traj trajer eron on apar aparej ejad ada a su dist distri ribu buci ción ón.. De est esta forma orma el soft softw ware are se est estable ableci ció ó como omo prod produc ucto to.. La dist distri ribu buci ción ón del sof software requería del mantenimiento y desarrollo propios ios para ara cada cliente. En consec secuencia se buscaba el establecimiento de procedimientos para llevar a cabo el desarrollo de software. Así surgió la progra gramación ión estructur turada en 1969 y en 1975 la progr programa amació ción n estruc estructur turada ada de Jacks Jackson. on.
4.1 Metodologías 4.1.2 Clasificación
Hasta aquí hemos realizado la clasificación de las metodologías en aquellas conducidas por los planes y ágiles. Veamos ahora las diferencias más significativas entre ellas.
4.2 Metodologías conducidas por los planes
Previamente hemos mencionado un listado cronológico de las metodologías conducidas por los planes. A continuación describiremos los modelos genéricos en los cuales éstas se basan. • Cascada. • Prototipado. • DRA (Desarrollo Rápido de Aplicaciones). • Incremental. • Espiral.
4.2 Metodologías conducidas por los planes 4.2.1 Cascada Es un modelo de desarrollo lineal secuencial. El proyecto de software es dividido en fases que deben procederse en forma secuencial. Estas fases han servido de base para la definición de otras metodologías, como por ejemplo el modelo incremental descrito posteriormente en este capítulo. El proceso incluye una serie de etapas en el siguiente orden [Roger Pressman]: 1. Definición del software: Corresponde a la visión del producto, a sus aspectos desde el punto de vista comercial. 2. Análisis de requerimientos: Implica el entendimiento del dominio del producto que será desarrollado; esto es, funciones, comportamiento y relación con sistemas externos. El principal ob jetivo de esta fase es achicar los riesgos de negocio. 3. Diseño de la arquitectura: Es la forma en que la so lución se implementará. 4. Codificación: Corresponde a la implementación de la so lución de acuerdo a cómo se ha estipulado durante el diseño de la arquitectura. 5. Pruebas: Deben asegurar que el producto satisfaga los requerimientos, es decir, que cumplan con el comportamiento esperado. Los principales objetivos de esta fase son asegurar la calidad del producto y reducir los riesgos de falla de la aplicación en el entorno final de implantación.
4.2 Metodologías conducidas por los planes 4.2.1 Cascada La arquitectura de la aplicación se plasma en un documento que po dríamos nombrar “Documento de Arquitectura”. Este elemento será la puerta de entrada a la codificación. Finalmente, la codificación genera el producto de software en sí y es la entrada para la fase de pruebas.
Figura 4.1. Metodología en cascada
4.2 Metodologías conducidas por los planes 4.2.1 Cascada 4.2.1.1 Roles El modelo de cascada, así como cualquier proceso de desarrollo, se apoya sobre los recursos para llevar a cabo cada una de las etapas. Podríamos decir más específicamente que los modelos se valen de roles para ejecutar las distintas fases que los componen. Para cada etapa del modelo cascada se puede asociar un rol y, dado que las fases se siguen en forma ordenada, cada uno de los roles formará parte del proyecto en la fase correspondiente. Los roles asociados a cada una de las fases podrían ser: 1. Definición del software Responsable de la parte comercial del proyecto 2. Análisis de requerimientos Analista 3. Diseño de la arquitectura Arquitecto 4. Codificación Desarrollador 5. Pruebas Responsable de las pruebas del sistema
4.2 Metodologías conducidas por los planes 4.2.1 Cascada 4.2.1.2 Ventajas La ventaja de emplear el modelo en cascada es que los riesgos son detectados en forma temprana dado que los requerimientos se congelan inicialmente. Esto permite tener una estimación considerablemente buena sobre los tiempos y costos requeridos. 4.2.1.3 Desventajas A su vez, el hecho de contar con los requerimientos congelados impide o dificulta cualquier tipo de cambio que deba ser incorporado al producto. Por ejemplo, supongamos que en la etapa de pruebas el cliente detecta que se ha olvidado de solicitar un requerimiento. Esto impacta directamente sobre cada una de las fases. La magnitud del impacto estará directamente relacionada con el nuevo requisito, siendo incluso, en algunos casos, imposible satisfacer la nueva necesidad. Además, dada la naturaleza de dependencia entre las distintas fases, el impacto en una de ellas provocará muy probablemente el impacto sobre el resto de las fases.
4.2 Metodologías conducidas por los planes 4.2.2 Prototipado El prototipado es un modelo de desarrollo iterativo en el cual se desarrolla una maqueta del producto. Esta maqueta o prototipo desarrollada por el equipo de proyecto y refinada junto al cliente permite idealmente especificar los requerimientos del producto. Inicialmente se comienza con la definición de alto nivel de los requisitos junto al cliente. Con base en el entendimiento de los requerimientos se desarrolla un prototipo que será presentado al cliente, quien probará la maqueta y emitirá su opinión, de acuerdo a la cual se iterará sobre el proceso descrito o se procederá a la implementación definitiva del producto. Así el prototipo evolucionará refinando los requerimientos en cada iteración hasta lograr la aprobación del cliente.
4.2 Metodologías conducidas por los planes 4.2.2 Prototipado El objetivo principal del proceso descrito es disminuir los riesgos que podría traer aparejada la falta de claridad de los requerimientos. Con esto se busca orientar al cliente/usuario con la definición de los requisitos.
Figura 4.2. Metodología de Prototipo
4.2 Metodologías conducidas por los planes 4.2.2 Prototipado 4.2.2.1 Roles Los roles involucrados durante la etapa de definición del prototipo variarán de acuerdo al contexto, pero podríamos mencionar al analista y/o desarrollador. Una vez que el prototipo se encuentre acordado con el cliente, aparecerán los roles de arquitecto, desarrollador y responsables de pruebas. Al igual que para el modelo en cascada, el líder de proyecto participará durante todo el ciclo de vida del proyecto. 4.2.2.2 Ventajas Este modelo permite obtener una respuesta rápida por parte del cliente sobre el producto que desarrollaremos. Consecuentemente podremos corregir y/o modificar el requisito que no se adecue con las necesidades del cliente. 4.2.2.3 Desventajas Dado que se presenta la aplicación “funcionando” al cliente, éste puede pensar que sólo restan algunos ajustes y cuando se le informa que debe construirse el producto puede ser que no logre comprenderlo y surjan conflictos. Para mitigar este riesgo es importante aclarar la forma de trabajo desde el comienzo. Puede suceder que con el fin de definir rápidamente el prototipo se lleven a cabo flujos o elementos que no pueden ser implementados posteriormente cuando se construya el producto final.
4.2 Metodologías conducidas por los planes 4.2.3 DRA (Desarrollo Rápido de Aplicaciones)
Este modelo, también conocido como RAD (en inglés Rapid Application Development), implica un proceso de desarrollo lineal secuencial llevado a cabo en paralelo por distintos equipos de trabajo. Cada uno de estos equipos de trabajo será responsable por una parte de las funcionalidades del proyecto. El objetivo es crear en un período corto de tiempo un producto final. Asimismo, el modelo se basa fuertemente en la reutilización de componentes y, en caso de que esto no sea posible, en desarrollar componentes reutilizables.
4.2 Metodologías conducidas por los planes 4.2.3 DRA (Desarrollo Rápido de Aplicaciones)
Figura 4.3. Metodología de desarrollo rápido de aplicaciones
4.2 Metodologías conducidas por los planes 4.2.3 DRA (Desarrollo Rápido de Aplicaciones) Por lo tanto, el modelo requiere la división de los requerimientos en los equipos de trabajo. Cada equipo trabajará sobre los requerimientos asignados empleando las siguientes etapas [Roger Pressman]: • Modelado de gestión El proceso de gestión se modela teniendo en cuenta los siguientes asuntos: la información que conduce la gestión, la información generada y el responsable de haberla generado, el destino de la información y el responsable de su procesamiento. • Modelado de datos El modelado de los datos se resuelve teniendo en consideración: los objetos de datos básicos que el sistema procesará, los atributos y componentes de ese objeto y la relación entre los objetos de datos y los procesos que los impactan. Básicamente, se busca obtener una abstracción del dominio relevante al producto en cuestión.
4.2 Metodologías conducidas por los planes 4.2.3 DRA (Desarrollo Rápido de Aplicaciones) Por lo tanto, el modelo requiere la división de los requerimientos en los equipos de trabajo. Cada equipo trabajará sobre los requerimientos asignados empleando las siguientes etapas [Roger Pressman]: • Modelado de proceso Lo que se busca modelar es el proceso de agregar, eliminar, modificar o recuperar los objetos de datos obtenidos en la etapa de modelado de datos. • Generación de aplicaciones La generación de aplicaciones corresponde al desarrollo del código necesario en un lenguaje de programación predefinido de los requerimientos estipulados. Como se ha comentado previamente, se buscará reutilizar componentes ya existentes, siempre que sea posible. En caso contrario se intentará crear componentes que puedan ser reutilizados posteriormente.
4.2 Metodologías conducidas por los planes 4.2.3 DRA (Desarrollo Rápido de Aplicaciones) Por lo tanto, el modelo requiere la división de los requerimientos en los equipos de trabajo. Cada equipo trabajará sobre los requerimientos asignados empleando las siguientes etapas [Roger Pressman]:
• Prueba y entrega Las pruebas que se van a realizar dependerán del tipo de componente utilizado. En el caso de que se reutilicen componentes, muchas veces puede suponerse que estos ya han sido probados y restaría solamente llevar a cabo una prueba integral entre los componentes. Cuando los componentes usados sean nuevos se requerirá llevar a cabo un conjunto de pruebas que logren asegurar el correcto funcionamiento del componente en cuestión. Las etapas mencionadas previamente pueden variar según el autor.
4.2 Metodologías conducidas por los planes 4.2.3 DRA (Desarrollo Rápido de Aplicaciones) 4.2.3.1 Roles Los roles involucrados coinciden con el modelo en cascada, haciendo la distinción de que se requerirá el desempeño de roles simultáneamente. Por ejemplo, inicialmente el equipo 1 comenzará a trabajar sobre los requerimientos correspondientes. Podría suceder que, antes de finalizar con la etapa de modelado de gestión, el equipo 2 emprenda su fase de modelado de gestión con base en los requisitos asignados. Es decir que paralelamente se estarán ejecutando dos fases de modelado de gestión disjuntas. El mismo caso podría suceder para las etapas posteriores y/o con más etapas simultáneas. Esto implica contar con una cierta cantidad de recursos disponibles.
4.2 Metodologías conducidas por los planes 4.2.3 DRA (Desarrollo Rápido de Aplicaciones) 4.2.3.2 Ventajas Cuando los requerimientos se encuentran especificados claramente desde el inicio es posible la construcción de un producto en un lapso considerablemente pequeño. 4.2.3.3 Desventajas El modelo DRA precisa de la cooperación del cliente para resolver temas que puedan presentarse en relación a él. Esta cooperación permitirá la rápida resolución de los eventuales inconvenientes, facilitando una veloz evolución del proceso. Asimismo, requiere contar con un gran número de recursos simultáneamente. Este número de recursos será proporcional a la magnitud del producto que se va a desarrollar y al tiempo comprometido con el cliente. El modelo exige que el producto por desarrollar pueda ser modularizado con el fin de llevar a cabo el proceso en paralelo. Por lo tanto, la metodología no puede ser aplicada a cualquier tipo de sistema.
4.2 Metodologías conducidas por los planes 4.2.4 Incremental Las metodologías mencionadas hasta aquí no consideran la evolución del producto debido al tiempo. En contraposición, el modelo incremental permite el aumento iterativo de la funcionalidad del producto. La base de esta metodología es el modelo lineal secuencial que se repetirá iterativamente. Cada iteración incrementará funcionalidad al producto hasta haber implementado todos los requerimientos. Por lo general cada una de las iteraciones se construye sobre el producto que se tiene hasta el momento, es decir, sobre el resultado obtenido de las iteraciones precedentes. Queremos recalcar que como resultado de cada iteración se obtendrá un producto operacional y no un prototipo, como en el caso del modelo prototipo. Será conveniente utilizar este modelo cuando el producto que se va a construir no esté definido completamente, cuando haya un gran número de requerimientos.
4.2 Metodologías conducidas por los planes 4.2.4 Incremental 4.2.4.1 Roles Dada la base en el modelo lineal secuencial, los roles participantes coincidirán, con la gran diferencia de que los roles participarán en forma simultánea unos con otros. Veamos un ejemplo para comprenderlo mejor: supongamos el rol que desempeña el analista. Inicialmente comenzará el análisis de una cierta cantidad de requerimientos correspondientes a la primera iteración. Una vez finalizada esta tarea, el arquitecto podrá comenzar con el diseño de la aplicación. Simultáneamente, el analista continuará con el análisis de los requerimientos para la próxima iteración. Cuando el analista haya terminado con su tarea, el arquitecto podrá iniciar su diseño para la segunda iteración y así sucesivamente para cada una de las iteraciones hasta finalizar el producto. De esta manera, el analista finalizará en primera instancia el trabajo en el proyecto y le seguirán el arquitecto, los desarrolladores y los responsables de las pruebas.
4.2 Metodologías conducidas por los planes 4.2.4 Incremental Recordemos nuevamente que el rol del líder de proyecto se llevará a cabo a lo largo de todo el ciclo de vida del proyecto.
Figura 4.4. Metodología Incremental
4.2 Metodologías conducidas por los planes 4.2.4 Incremental 4.2.4.2 Ventajas El modelo iterativo permite adaptarse a la evolución que puede sufrir el producto con el pasar del tiempo. Al igual que para el modelo de prototipado, da la posibilidad de obtener una pronta respuesta por parte del cliente sobre el producto que se está desarrollando. 4.2.4.3 Desventajas Previamente dijimos que cada una de las iteraciones da como resultado un producto operativo. Armar este entregable requiere de un trabajo extra por cada iteración. Este tiempo extra representa tiempo y costo al proyecto. Por lo tanto, debe ponderarse la importancia de estos entregables con el fin de reducir los tiempos y costos que siempre son tiranos en los proyectos.
4.2 Metodologías conducidas por los planes 4.2.5 Espiral Este modelo combina los modelos de cascada y la esencia iterativa del prototipado descritos previamente. Por lo tanto, es una metodología iterativa incremental. El proyecto de software es dividido en “miniproyectos”, cada uno de los cuales evoluciona el producto y busca minimizar los riesgos. Como se puede desprender a partir del gráfico del modelo, el proyecto comienza desde el origen del espiral con una planificación de los requerimientos, continúa con el análisis de los riesgos del proyecto y así sigue. Es importante observar que las primeras iteraciones son más pequeñas en costo y en tiempo. Por ejemplo, podría pensarse en un primer prototipo en papel, el cual en las próximas iteraciones podría convertirse en código.
4.2 Metodologías conducidas por los planes 4.2.5 Espiral Los “miniproyectos” están compuestos de las siguientes fases [Steve Mc Connell]: 1. Determinar los objetivos: Define los objetivos que deben ser alcanzados por el miniproyecto correspondiente. 2. Identificar y resolver los riesgos: Identifica y resuelve los riesgos técnicos y de gestión del proyecto. 3. Evaluar alternativas: Involucra el análisis y prototipado de distintas alternativas posibles para los requerimientos correspondientes al miniproyecto en cuestión. 4. Codificación y pruebas: Tareas necesarias para la implementación y las pruebas de los requerimientos pactados para el “miniproyecto” correspondiente. La funcionalidad será implementada de acuerdo al resultado obtenido del análisis de las distintas alternativas planteadas previamente. 5. Planificar la próxima iteración: Involucra las acciones pertinentes para planificar los recursos, tiempos y costos necesarios para llevar a cabo la próxima iteración.
4.2 Metodologías conducidas por los planes 4.2.5 Espiral 4.2.5.1 Roles Los roles involucrados son los mencionados en los modelos descritos previamente. Cada uno de ellos participará en forma simultánea en el proyecto dada la naturaleza iterativa de la metodología. 4.2.5.2 Ventajas La mayor ventaja del método es el control de los riesgos que lleva a cabo. A medida que se avanza en las iteraciones los riesgos del proyecto decrecen. 4.2.5.3 Desventajas El modelo en espiral es difícil de implementar dado que requiere de una administración minuciosa. En relación a esto, es importante remarcar que si el principal riesgo del proyecto no es descubierto y mitigado, puede ser complicada su administración. Asimismo, puede resultar complicada la definición de objetivos y su evaluación para decidir el momento de avanzar en las iteraciones [Steve Mc Connell].
4.3 Metodologías ágiles
Las metodologías ágiles surgen en el nuevo milenio como resultado de algo que se venía gestando hacia fines de la década del 90 y que se concretó en el año 2001. En este año se reunieron algunos representantes de los modelos ágiles y dieron origen a lo que se denomina el manifiesto ágil. Este acontecimiento y el manifiesto ágil se encuentran detallados en el capítulo 6 de “Metodologías ágiles”. De todas maneras es necesario aquí introducir un pequeño fragmento del manifiesto ágil que presentaremos en el capítulo mencionado con el fin de comprender el espíritu de estas metodologías. En el mismo capítulo podrá encontrar además un detalle de cada uno de los puntos principales.
4.3 Metodologías ágiles El manifiesto ágil “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas. Software que funciona sobre documentación extensiva. Colaboración con el cliente sobre negociación contractual. Respuesta ante el cambio sobre seguir un plan. Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”.
4.3 Metodologías ágiles En las metodologías conducidas a los planes, los procesos definidos son estrictos y burocráticos. En contraste, las metodologías ágiles, como su nombre lo indica, buscan brindar flexibilidad al proceso de desarrollo de software. De esta forma, intentan lograr un punto que sea útil entre las restricciones de los modelos orientados a los planes y la libertad absoluta. Hay una gran variedad de modelos de metodologías ágiles que mencionaremos en el capítulo 6 dedicado exclusivamente a ellas. Dada esta variedad, nos es difícil practicar una definición específica. Sin embargo, podemos decir, en línea general, que el modelo de desarrollo de las metodologías ágiles es evolutivo, iterativo y trabaja con timeboxed. Cuando decimos que el modelo de desarrollo trabaja con timeboxed nos referimos a que las iteraciones poseen tiempos fijos. La planificación es adaptativa y los entregables, evolutivos.
4.3 Metodologías ágiles Entre las metodologías ágiles más conocidas podemos mencionar Extreme Programming (XP), Scrum, Lean Software Development, Crystal y Feature Driven Development.
Figura 4.5. Esquema mostrando la esencia de las metodologías ágiles.
4.4 Diferencias de enfoque Una perspectiva interesante para hacer una comparación entre las metodologías conducidas por los planes y las ágiles es desde la teoría de las restricciones [10]. Para ello es necesario establecer un paralelo entre un proyecto de desarrollo de software y una organización. La gestión de las organizaciones tradicionalmente se administró según la reducción de costos. Sin embargo, no todas las áreas de una organización necesitan seguramente reducirlos para lograr un buen funcionamiento. Otras quizás sí lo necesitan. Esta visión local es reemplazada por una visión sistémica en la teoría de las restricciones, en la que en lugar de enfocarse en los costos se propone centrarse en la producción. Se trata entonces de maximizar el valor producido al negocio.
4.4 Diferencias de enfoque Como en toda organización, en un proyecto hay una inversión (I), un gasto operacional (GO) y una producción (P), como se muestra en la figura 4.6. La gestión del proyecto según esta estrategia es aumentar la producción (P), manteniendo la inversión (I) controlada y reduciendo el gasto operacional (GO) y el inventario (V).
Figura 4.6. Diagrama esquemático que muestra la inversión (I), el gasto operacional (GO), el inventario (V) y l a producción (P) en una organización.
4.4 Diferencias de enfoque La diferencia de enfoque trata de priorizar una de las magnitudes frente a las otras. En la figura 4.7 se observa un esquema que muestra esta diferencia entre el enfoque que prioriza los costos y el que lo hace con la producción.
Figura 4.7. Esquema que muestra la diferencia de prioridades entre los enfoques basados en los costos y los que están basadon en la producción.
4.4 Diferencias de enfoque
El paralelo entre una organización y un proyecto nos lleva a la siguiente analogía:
• Inversión (I): Está representada por las ideas relevadas del cliente acerca del negocio y por implementar en el sistema. El alcance del proyecto está dado por este conjunto de ideas. • Costo operacional (CO): Es el costo de transformar estas ideas en código productivo. • Inventario (V): Está dado por las ideas elaboradas sin cerrar en el proyecto. • Producción (P): Valor agregado al negocio a partir del código generado que funciona.
4.4 Diferencias de enfoque
El comportamiento de estos enfoques aplicados a los proyectos de desarrollo y a la metodología utilizada es el siguiente: Metodologías Conducidas por los Planes (Centradas en los Costos), que planifican los proyectos a partir de estimaciones de alcance y esfuerzo. A partir de éstas se estima el tiempo de duración del proyecto y el presupuesto. La falencia de esto radica en que el alcance es el componente de mayor incertidumbre y todo este proceso se basa en él. La gestión del proyecto se desarrolla tratando de cumplir con los hitos planificados y reducir así la incertidumbre. Por lo tanto, es equivalente a cumplir con la premisa de implementar los requerimientos, que refinados exceden los originalmente estimados a un precio prefijado, o sea que se trata de minimizar costos.
4.4 Diferencias de enfoque
Este incremento del inventario es visto como un activo y no como un compromiso.
Figura 4.8. Esquema de la diferencia entre los procesos de gestión de los proyectos con enfoques conducidos por los planes y los de enfoques ágiles.
4.5 Diferencias de aplicabilidad Es necesario examinar la aplicabilidad de los métodos ágiles y considerar el espectro de dominios de problemas en los que podrían ser aplicables y aquellos en los que otros métodos serían mejores. La evidencia de los datos relevados estadísticamente indica que deben tenerse en cuenta las siguientes variables y ayuda a sacar algunas conclusiones, las cuales fueron condensadas en la tabla 4.2 que sigue:
4.5 Diferencias de aplicabilidad En la figura 4.9 se muestra en forma esquemática una guía con el mismo sesgo que el presentado en la tabla anterior.
Figura 4.9. Indicadores de aplicabilidad de diferentes metodologías, adaptada de David J. Anderson, Eli Schragenheim [10].
4.6 Conclusión Hasta aquí hemos descrito a grandes rasgos las metodologías conducidas por los planes y las ágiles. Es importante remarcar que el éxito de un proyecto no depende exclusivamente de la metodología utilizada, sino de otro conjunto de factores que oportunamente mencionaremos. A continuación listamos los contextos en los que sería más apropiado utilizar metodologías conducidas a los planes: • Un equipo de trabajo de gran magnitud. • Un alcance o contrato fijo.
La previsibilidad es una característica deseada, pero no siempre puede darse en los proyectos de desarrollo de software. Creer que tenemos previsibilidad y que luego esto no se cumpla puede provocar importantes desvíos sobre el proyecto.
4.6 Conclusión En contraposición a un contexto de previsibilidad, mencionamos una serie de situaciones en las cuales sería más conveniente aplicar metodologías ágiles: • Requerimientos inciertos o volátiles. • Desarrolladores responsables y motivados. • Cliente comprometido, es decir, que entienda y se involucre.
• Con esto no queremos decir que si estamos en un proyecto en el cual el alcance está cerrado, tenemos que aplicar indefectiblemente metodologías conducidas a los planes. Sino que si se cumple esta condición y estamos ante un cierto contexto en particular sería conveniente la aplicación de alguna metodología orientada a los planes. De acuerdo a nuestro criterio, el hecho de forzar una forma de trabajo hace que no se defina ninguna metodología o se defina una metodología inapropiada. Por lo tanto, creemos que es conveniente adaptar los modelos en función de la realidad de la empresa o equipo de trabajo que aplicar una metodología al pie de la letra o, peor aún, la ausencia de una forma de trabajo.
