- Metodologías de Software a la medida -- Metodologías de Software a la medida -

Dime qué desarrollas y te diré que metodología usar

Autores:Kiberley Santos C.I. 16.725.946Carmen Salazar C.I. 15.621.262

Agenda

Introducción Metodologías Pesadas

• Proceso Unificado de Rational (RUP) Metodologías Livianas

• Metodologías Ágiles• eXtreme Programing (XP)• SCRUM

Caso Software Libre Tendencias en la Industria Venezolana Conclusiones Referencias Bibliográficas

Introducción

- El cliente demanda sistemas de software eficientes, con un alto desempeño funcional y alta calidad.

- Nace la necesidad de contar con una metodología para gestionar los proyectos bajo un enfoque disciplinado y sistemático.

- Existen variedad de metodologías de desarrollo y no siempre se escoge la mas adecuada, o se termina proponiendo una nueva.

- A continuación se presenta esquema de desarrollo, ventajas y desventajas, destacando para que tipo de proyecto su utilización es apropiada .

Proceso Unificado Rational (RUP)

- Precursores: Barry Boehm, Ken Hartman, Ivar Jacobson. La primera versión fue puesta en marcha en 1998 siendo el arquitecto en jefe Philippe Kruchten.

- Proceso de ingeniería de software que junto al Lenguaje Unificado de Modelado (UML), constituye una metodología estándar altamente utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.

- Su propósito es asegurar la producción de software de alta calidad que se ajuste a las necesidades de sus usuarios finales con unos costos y calendario predecibles.

Proceso Unificado Rational (RUP)

Figura 1: Fases, iteraciones y flujos de trabajo en RUP. Tomado de IBM Corporation (2006).

Proceso Unificado Rational (RUP)

Ventajas

- Reconoce que los requisitos del cliente no se pueden definir completamente al principio y se deben tomar acciones adaptativas.

- Permite evaluar tempranamente los riesgos presentes en lugar de descubrir problemas en la integración final del producto de software.

- Reduce el costo del riesgo a los costos de un solo incremento.

- Acelera el ritmo del esfuerzo de desarrollo debido a que se trabaja para obtener resultados claros a corto plazo.

- Distribuye la caga de trabajo a lo largo del tiempo del proyecto ya que todas la disciplinas colaboran en una iteración.

- Facilita la reutilización de componentes teniendo en cuenta que se realizan en al primeras iteraciones.

Proceso Unificado Rational (RUP)

Desventajas

- La metodología puede ser vista como muy pesada debido a su contenido amplio y complejo.

- Si se desconoce que es un marco de trabajo configurable, puede parecer tedioso ya que da la impresión de que se debe hacer uso de todos los elementos (actividades, artefactos y roles).

- También se puede caer en el error de pensar que RUP no admite adaptabilidad ni extensiones dependiendo de las particularidades del proyecto. El detalle esta en conocer suficiente mente la metodología para estar en la capacidad de configurar el marco de trabajo.

Proceso Unificado Rational (RUP)

Usos

Esta metodología por su amplitud es más apropiada para proyectos grandes, de largo plazo y sobre todo cuando se trabaja con equipos de desarrollo con numerosas personas y dispersos en cuanto a ubicación geográfica.

Metodologías Ágiles

- PrecursoresKent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas.

Manifiesto Ágil

- A los individuos y su interacción, por encima de los procesos y las herramientas.

- El software que funciona, por encima de la documentación exhaustiva.

- La colaboración con el cliente, por encima de la negociación contractual.

- La respuesta al cambio, por encima del seguimiento de un plan (Cockburn).

Metodologías Ágiles

Principales Exponentes

- XP (eXtreme Programming): Kent Beck y Ward Cunningham a finales de los 1980s.

- La familia de Cristal de Cockburn: Alistair Cockburn.- Código Abierto.

- El desarrollo de software adaptable de Highsmith: Jim Highsmith.

- Scrum: Ken Schwaber y Mike Beedle.

- Desarrollo manejado por rasgos: Jeff De Luca y el viejo gurú de la OO Peter Coad.

- DSDM (método de desarrollo de sistemas dinámicos): El DSDM empezó en Gran Bretaña en 1994.

eXtreme Programming (XP)

- La XP empieza con cuatro valores: Comunicación, Retroalimentación, Simplicidad y Coraje.

- Construye sobre ellos una docena de prácticas que los proyectos XP deben seguir:

Planificación incrementalTestingProgramación en parejasRefactorizaciónDiseño simplePropiedad colectiva del códigoIntegración continúaCliente en el equipoReleases pequeñasSemanas de 40 horasEstándares de codificaciónUso de Metáforas

eXtreme Programming (XP)

Figura 3. Fases de un proyecto en eXtreme Programming. Tomado de XP (2006).

eXtreme Programming (XP)

Ventajas

- Funciona muy bien cuando loe requisitos son inciertos y volátiles.

- Garantiza la satisfacción del cliente ya que se encuentra involucrado en las constantes validaciones que se hacen con los release.

- Los desarrollos serán de calidad ya que son probados constantemente en todo el proceso.

- Los equipos de trabajo pueden ser numerosos.

eXtreme Programming (XP)

Desventajas

- El equipo de trabajo es menor a 6 personas.

- Si no se confía en las capacidades del equipo de trabajo.

- Si los requisitos están bien definidos, no es necesario implementar ninguna metodología ágil.

- En caso de contrataciones con costos fijos, ya que no existe la interacción que se necesita con el cliente.

SCRUM

- Es un modelo de referencia que define un conjunto de prácticas y roles.

- Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders (clientes externos o internos), y el Team que incluye a los desarrolladores.

- El desarrollo de software se realiza mediante iteraciones, denominadas sprints, con una duración de 30 días. El resultado de cada sprint es un incremento ejecutable que se muestra al cliente.

- Existen reuniones a lo largo del proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para coordinación e integración.

SCRUM

Figura 2: Proceso de Trabajo con Scrum. Tomado de Taringa! (2007).

SCRUM

Ventajas

- Permite la entrega de un producto funcional al finalizar cada Sprint (iteración).

- Posibilidad de ajustar la funcionalidad en base a la necesidad de negocio del cliente.

- Se puede visualizar el proyecto día a día.

- Alcance acotado y viable.

- Potencia la formación de equipos de trabajos autosuficientes y multidisciplinarios.

SCRUM

Desventajas

- Scrum no genera toda la evidencia o documentación de otras metodologías.

- No es apto para todos los proyectos.

- Tal vez sea necesario complementarlo con otras metodologías, como por ejemplo XP.

SCRUM

Usos

- Indicada para pequeños equipos de desarrollo.- Entornos complejos.- Donde se necesita obtener resultados pronto.- Donde los requisitos son cambiantes o poco definidos.- Donde la innovación, la competitividad y la productividad son

fundamentales.- Para resolver situaciones en que no se está entregando al

cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable.

- Cuando se necesita capacidad de reacción ante la competencia.- Cuando la moral de los equipos es baja y la rotación alta.- Cuando es necesario identificar y solucionar ineficiencias

sistemáticamente.- Cuando se quiere trabajar utilizando un proceso especializado

en el desarrollo de producto.

Caso Software Libre

El Software Libre (SL) ha ganado seguidores a nivel mundial debido a las ventajas, tanto filosóficas como prácticas, que ofrece a sus usuarios y desarrolladores.

Hoy en día está abierta un supuesta investigación denominada ingeniería de SL, de los cuales existen artículos publicados, que es algo cuestionado académicamente.

Se puede tomar, del SL, como aspecto relevante la constante interacción con el usuario final a través de sus procesos de retroalimentación y la publicación de versiones en etapas tempranas.

Desarrolladores de SL tienden a utilizar más metodologías ágiles, como XP y Scrum, que metodologías de desarrollo basados en un análisis exhaustivo previo, esto se debe a que las metodologías ágiles propician principios y valores que se pueden adaptar fácilmente al desarrollo de SL.

Caso Software Libre

MeRinde, metodología desarrollada dentro del Centro Nacional de Tecnologías de Información (CNTI), que está basada en diversas metodologías para el desarrollo de software, como UP especialmente, la cual permite gestionar proyectos de desarrollo de SL para el estado venezolano, garantizando el cumplimiento con calidad del decreto N° 3.390.

Existen propuestas metodológicas venezolanas para desarrollar SL, como son:

Metodología para el desarrollo colaborativo de SL, promovida por el Centro Nacional de Desarrollo e Investigación en Tecnologías Libres (CENDITEL), la cual está inspirada fuertemente en XP. En la metodología se combinan características de los estilos de desarrollo Catedral y Bazar, en base a las cuales es posible definir procesos centralizados que permitan el desarrollo colaborativo y la liberación frecuente del código.

Tendencias en la Industria Venezolana

Un estudio realizado por la facultad de Ingeniería de la Universidad de los Andes en conjunto con el GIDyC, CEISoft y CEIDIS; con el título: “La Industria Nacional del Software en Venezuela”, arrojo entre sus conclusiones la siguiente:

- El 93% de las empresas utilizan algún modelo de procesos o método de desarrollo en particular. El 51% dice emplear un modelo propio, es decir, han desarrollado su propio modelo de procesos o utilizan una mezcla de varios de los modelos conocidos.

- Sin embargo, se pudo detectar que muchas de las empresas que usan un modelo propio, por lo general, no tienen un modelo documentado a un nivel de detalle que facilite su uso corporativo. El 68% de la muestra señalo que no es obligatorio el uso de modelos de procesos en los proyectos.

Tendencias en la Industria Venezolana

Conclusiones

Siempre existirá una metodología adecuada y adáptale a las necesidades del proyecto, lo importante es saber como identificarla.Para esto proponemos tener en cuenta lo siguiente:

- Para desarrollos con requisitos poco definidos, tiempos cortos y equipos de trabajo mayores de 2 personas, capacitado y con experiencia, se recomiendan metodologías ágiles.

- Para desarrollos con requisitos poco definidos, tiempos largos y equipos de trabajo multidisciplinarios, se recomiendan metodologías pesadas como RUP o sus variaciones.

Conclusiones

- Si el desarrollo es contratado y no existe suficiente interacción con el cliente, las metodologías ágiles no aplican.

- Las metodologías pesadas generan más documentación y por ende más material que sirven de antecedente para futuros desarrollos que las metodologías livianas.

- Para el caso de desarrollos libres, existen propuestas de metodologías que permiten canalizar el desarrollo de software hacia un desarrollo de calidad, sin dejar de lado el paradigma del bazar y la reutilización del conocimiento.

Conclusiones

Emplear metodologías auto configuradas (por así decirlo), tiene sus riesgos, ya que puede afectar seriamente la calidad del producto final.

Resumiendo los factores que se consideran determinantes a la hora de escoger una metodología, entre otros, son:- Capacidades y pericias del equipo de trabajo.

- Madurez de los requisitos.

- Tiempo con el que se cuenta para el desarrollo.

- Interacción con el cliente.

- Requerimiento de documentación por parte de la empresa desarrolladora de software y/o empresa contratante.

Conclusiones

En relación a las tendencias de las empresas desarrolladoras de software a nivel nacional, hay que tomar en cuenta que este es un mercado relativamente nuevo en el país. Sin embargo, poco a poco, conforme los equipos de trabajo van madurando y adquiriendo experiencia, haciendo uso de diferentes metodologías; se va depurando el conocimiento y fomentando las buenas prácticas. Dando píe el uso de metodologías de desarrollo adecuadas, según las características de la empresa desarrolladora de software.

Referencias Bibliográficas

Alvarez, I. (2007) Desarrollo Ágil con Scrum. Tomado el 25-01-2009 de http://www.sg.com.mx/sg07/presentaciones/Mejora%20de%20procesos/SG07.P02.Scrum.pdf

Alvares J., Terán O., Aguilar J. (2008). Experiencias desde CENDITEL: Metodología para el Desarrollo Colaborativo de Software Llibre. Vol. 1.

Canós José, Letelier Patricio, Mª Carmen Penadés (2003). Métodologías Ágiles en el Desarrollo de Software. Tomado el 25-01-2009 de http://www.willydev.net/descargas/prev/TodoAgil.Pdf

Cockburn and Highsmith, Agile Software Development Ecosystems.

Cousso Ricardo, Desarrollo ágil de software. Tomado el 25-01-2009 de http://knol.google.com/k/ricardo-colusso/desarrollo-gil-de-software/3satfj6065tbv/2#

Ferrer Jorge (2003). Metodologías Ágiles. Tomado el 25-01-2009 de http://libresoft.dat.escet.urjc.es/html/downloads/ferrer-20030312.pdf

Fowler Martin (2003), La nueva metodología. Tomado el 25-01-2009 de http://www.martinfowler.com/articles/newMethodology.html

IBM Corporation (2006). Rational Unified Process [Material disponible en disco Compacto (CD)]. Disponible: Rational Unified Process Version 7.0.1.

Referencias Bibliográficas

Jeffries Ron (2001). What is Extreme Programming?. Tomado el 25-01-2009 de http://www.xprogramming.com/xpmag/whatisxp.htm

Kruchten, P. (2003). The Rational Unified Process: An Introduction (3ra Ed.), Addison Wesley.

Letelier, P. (2003). Proyecto Docente e Investigador, DSIC.

MeRinde (2007). Descripción de MeRinde. Tomado el 25-01-2009 de http://merinde.rinde.gob.ve/

Netcraft (2006). December 2006 Web Server Survey. Tomado el 24-01-2009 de http://news.netcraft.com/

Rivero Dulce, Montilva Jonás, Granados Gladis, Barrios Judith, Besembel Isabel y Sandia Beatriz (2007), La Industria Nacional de Software en Venezuela, Tomado el 31-01-2009 de http://www.saber.ula.ve/bitstream/123456789/15822/1/09_INS_EVETIS2007.pdf

Schwaber K (2004). Agile Project Management with Scrum.Microsoft Press, 163pp, ISBN 0-7356-1993-X

Schwaber K., Beedle M., Martin R.C. (2001) Agile Software Development with SCRUM. Prentice Hall.

Referencias Bibliográficas

Sourcepyme (2006). Los institutos tecnológicos AIMME, AIMPLAS e ITI reúnen a más de 200 expertos en la Jornada Sourcepyme. Tomado el 24-01-2009 de http://www.sourcepyme.org/?q=node/97

Taringa! (2007). SCRUM: Desarrollo Ágil de software. Tomado el 25-01-2009 de http://www.taringa.net/posts/info/867068/SCRUM:-Desarrollo-%C3%81gil-de-Software.html

Wheeler, D. (2005). Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers!. Tomado el 25-01-2009 de http://www.dwheeler.com/oss_fs_why.html

Wikipedia, Agile software development, Tomado el 25-01-2009 de http://en.wikipedia.org/wiki/Agile_software_development

Wikipedia, Manifiesto Ágil, Tomado el 25-01-2009 de http://es.wikipedia.org/wiki/Manifiesto_%C3%81gil

XP (2006), Extreme Programming: A gentle introduction, Tomado el 25-01-2009 de http://www.extremeprogramming.org/