Inicio arrow Artículos - apuntes arrow La lista definitiva de modelos y buenas prácticas para proyectos de software Make Text BiggerMake Text SmallerReset Text Size

Navegápolis publica actualmente en navegápolis.com.

Ir a navegapolis.com

La lista definitiva de modelos y buenas prácticas para proyectos de software
Valoración del artículo: / 28
MaloBueno 
29.10.2008

numerosEscribir "lista definitiva", de "buenas prácticas...", y más, en un blog, puede sonar como los "requisitos definitivos" de un proyecto ágil: ¿Estos son? ¿No van a cambiar?

Este artículo es un backlog, o pila, si empleamos en nuestro idioma: una lista en continuo cambio, para ir completando y mejorando entre todos, vuelta tras vuelta.

CRITERIO DE CLASIFICACIÓN

Prácticas

Dicen "CÓMO" hacer las cosas: cómo describir y gestionar los requisitos (historias de usuario, elementos de backlog...), cómo estimarlos, cómo realizar las reuniones para validar con el cliente, cómo realizar el mantenimiento del código, las pruebas, la integración...

 

Prácticas listadas:

  • Ágiles: eXtreme Programming, Scrum, FDD, CDT, EVO, TDD
  • Predictivas: ITIL

Modelos

No definen "CÓMO" hacer las cosas, sino  "QUÉ" cosas se deben hacer para conseguir los mejores resultados: se debe hacer gestión de la configuración, gestión de proyecto, medición y análisis, desarrollo de requisitos, validación, etc.  

Unos se centran en un área de conocimiento (generalmente gestión de proyecto).

Modelos centrados en un área (gestión de proyecto)

  • Ágiles: Crystal, DSDM, Lean, Unified Process (RUP, Open UP, OUM, AUP, EssUP), MSF
  • Predictivos: PMBOK, PRINCE2

Y otros abarcan todas las áreas de la organización implicadas en el desarrollo de software

Los modelos más conocidos son CMMI ISO 15504.

Tienen dos finalidades:
1.- Para mejorar: Como guión en los procesos de mejora, que indica cuáles son las áreas que se deben ir abordando.
2.- Para evaluar: Como criterio para medir a una organización cómo de bien lo hace, según cuántas de las cosas que dice el modelo, está cubriendo adecuadamente.

Relación de modelos con carácter glogal:

  • Basados en procesos: CMMI, ISO 15504
  • Ágiles: Scrum Manager (aparte de ser el único, es el que mejor conozco :-)  y, of course... en fase inicial de desarrollo

Vista de modelos basados en procesos Vista de modelos ágiles

Para situar en un escenario las prácticas y modelos, empleo el mismo criterio que en el proyecto ScrmManager: Hay prácticas orientadas a la gestión del proyecto, otras al desarrollo de la solución técnica y aunque muy pocas (o ninguna), también las debería haber preocupadas por la gestión de la empresa, porque las tres son necesarias para obtener el mejor resultado de un modelo, tanto sea de perfil ágil, o de procesos.


Visión Scrum Manager de modelos

MODELOS Y PRÁCTICAS

 

Agile Unified Process (AUP)

Es otra versión simplificada y ágil de RUP, desarrollada por Scott W. Ambler: aplica las siete disciplinas de RUP (modelado, implementación, prueba, desarrollo, gestión de la configuración, gestión de proyecto y entorno), pero dentro de ejecuciones iterativas, y sobre una base de cultura de desarrollo ágil.

Enlaces:

 

CDT

Context Driven Testing define un contexto de desarrollo y depuración de programas basado en las pruebas, que el equipo determina analizando el entorno del cliente, y determinando cuáles son las funcionalidades que éste necesita para su negocio, basándose en el principio de que un programa puede ser una solución válida en un entorno cliente, pero no en otro.

Enlaces:

 

CMMI

El Departamento de Defensa Amerícano, a través de su fundación SEI (Software Engineering Institute), ha desarrollado una línea de trabajo para mejorar y medir el grado de fiabilidad de una organización que desarrolla software, basada en el concepto de "madurez".
Por madurez se entiende la capacidad que tiene la organización para asegurar la calidad de sus proyectos de forma continua y homogénea; así como la capacidad de aprendizaje de su propia experiencia y aplicación en un proceso de mejora continua.

En 1990 SEI publicó el modelo de madurez de la capacidad para el desarrollo de software (CMM-SW), que tras casi dos décadas de existencia ha demostrado su eficacia en algunas organizaciones.
Este modelo crea una escala de cinco niveles para determinar la madurez de una organización.

En 2000 el modelo SW-CMM se actualizó en otro que facilitaba su implantación de forma conjunta y simultánea con otros modelos: fue el modelo CMMI (Capability Maturity Model Integration)

En la actualidad hay varios modelos CMMI, en función de las áreas que integran: CMMI-SE/SW/IPPD/SS (Systems Engineering, Software, Engineering, Integrated Product and Process Development, Supplier Sourcing). CMMI-SE/SW/IPPD (Systems Engineering Software Engineering, Integrated Product and Process Development). CMMI-SE/SE (Systems Engineering, Software Engineering).

Enlaces:

 

Crystal

La familia de metodologías Crystal ofrece diferentes métodos para seleccionar las prácticas más apropiadas para cada proyecto, en función de su tamaño y criticidad; de forma que los de mayor tamaño, o aquellos en los que la presencia de errores implique consecuencias de mayor gravedad, deben adoptar mayor "peso" de procesos en su gestión.

Enlaces:

 

DSDM

Es la más veterana de las metodologías ágiles, y la más próxima a los métodos formales; de hecho, la implantación de un modelo DSDM en una organización, la lleva a alcanzar lo que en CMM (modelo no ágil) sería un nivel 2 de madurez.
Surgió en 1994 de los trabajos de Jennifer Stapleton, la actual directora del DSDM Consortium.

Su desarrollo se inspira en los principios RAD (Rapid Application Development), y le reprocha a CMM:
- Aunque es cierto que CMM ayuda al éxito a algunas organizaciones, lo que funciona bien en un entorno, no tiene por que servir para todos.
- CMM no le da al diseño la importancia que debería tener.
- CMM plantea un foco excesivo en los procesos, olvidando la importancia que en nuestra industria tienen las personas.
- Tener procesos claramente definidos no es sinónimo de tener buenos procesos.

En común con los métodos ágiles, DSDM considera imprescindible la implicación y relación estrecha con el cliente durante el desarrollo, así como la necesidad de trabajar con métodos de desarrollo incrementar y entregas evolutivas.

Enlaces:

 

Enterprise Unified Process

Es una extensión de RUP diseñada por Scott W. Ambler, que incluye dos fases adicionales: producción y retirada del sistema, y nueve disciplinas: operaciones, soporte, modelado de negocio, gestión de portfolio, arquitectura de empresa, reutilización, gestión de personas, administración de la empresa, y mejora del proceso de software.

 

EssUP

Essential Unified Process es un modelo diseñado por Ivar Hjalmar Jacobson, co-autor de lenguaje de modelado UML y de RUP (Rational Unified Process).
Vió la luz en Noviembre de 2005, y según su autor se trata de una orientación super ligera y ágil de RUP.

Evo


Evolutionary Project Management es un modelo de gestión de proyectos ágil diseñado por Tom Gilb y Kai Gilb, que divide los proyectos en ciclos independientes y evolutivos; y sin llegar a la rigidez de la gestión predictiva, acuerda los requisitos con el ciente con mayor rigidez que otros modelos ágiles, para conseguir de esta forma cuantificar el valor que representan para el cliente y decidir la mejor estrategia de solución sobre tablas de estimación de impacto.

Enlaces:


Extreme Programming

Es el conjunto de prácticas ágiles para el desarrollo de la solución técnica  que más popularidad ha alcanzado entre las metodologías ágiles. Su creador Ken Beck fue el alma mater del Manifiesto Ágil.
Extreme Programming (XP) se irgue sobre la suposición de que es posible desarrollar software de gran calidad, a pesar, o incluso como consecuencia del cambio continuo.
Su principal asunción es que con un poco de planificación, un poco de codificación y unas pocas pruebas se puede decidir si se está siguiendo un camino acertado o equivocado, evitando así tener que echar marcha atrás demasiado tarde, o construir partes que nunca se utilizarán.

Cuatro son los valores que lo inspiran: simplicidad, feedback, coraje y comunicación.
XP es un conjunto de 12 prácticas que se complementan unas a otras:
De codificación: Simplicidad de código - Reingeniería continua - Estándares de codificación - Vocabulario común.
De desarrollo: Desrrollo basado en pruebas - Programación por parejas - Propiedad colectiva del código - Integración continua
De negocio: Implicación del cliente - Juego de planificación - Entregas regulares - Ritmo de trabajo sostenible.

 

Enlaces:

 

FDD

Desarrollo basado en funcionalidades (Feature Driven Development) es nombre de otro conjunto de prácticas ágiles para desarrollo iterativo e incremental que no hace tanto hincapié en la fase de requisitos, como en las de diseño y construcción.
Diseñado inicialmente en 1997 por Jeff De Luca, partiendo de las prácticas que él mismo empleaba en su trabajo en un proyecto para un banco de Singapur.

Enlaces:

 

ISO15504

En enero de 1993 la comisión ISO/IEC JTC1 aprobó un programa de trabajo para el desarrollo de un modelo que fuera la base de un futuro estándar internacional para la evaluación de los procesos del ciclo de vida del software. Este trabajo recibió el nombre de proyecto SPICE (Software Process Improvement and Capability dEtermination) y en junio de 1995 publicó su primer borrador.
En 1998, pasada la fase de proyecto, pasó a la fase de informe técnico con la denominación ISO/IEC TR 15504, y en la actualidad es ya un estándar ISO.
Aunque ISO comenzó, con el proyecto SPICE algo más tarde que SEI con CMM, durante su evolución han ido convergiendo, y ambas instituciones vienen trabajando de forma continua desde 1998 para lograr la compatibilidad que en la actualidad ya está acordada, entre ambos modelos (CMMI e ISO 15504)

ISO/IEC 15504, al igual que CMMI, es un modelo para evaluar los procesos de una organización y determinar si resultan efectivos para conseguir los objetivos. También es un modelo para guiar las acciones de mejora de dichos procesos.

 

ITIL

La Biblioteca de Infraestructura de Tecnologías de Informción (Information Technology Infraestructure Library - ITIL) comprende documentación con las mejores prácticas para administrar y entregar servicios de tecnologías de la información. La primera versión fué desarrollada y publicada en 1980 por la Central Computer and Telecommunications Agency (CCTA), como un conjunto de manuales, especializado cada uno en un área de la gestión de tecnologías de la información. En la actualidad es marca registrada de la OGC británica (Office of Government Commerce)

Lean Software Development

Metodología ágil centrada en la gestión y seguimiento ágil de proyectos que adapta al desarrollo de software los principios "fabricación lean" (lean manufacturing), basada en el sistema japonés del fabricante de automóviles Toyota.

Para saber más:

Sitio de Mary y Tom Poppendieck , principales desarrolladores y difusores del modelo. 

Libros:

 

MSF

MSF es la metodología empleada por Microsoft para el desarrollo de software.
Hasta su versión 3 (principios de 2005), se definía como un marco flexible para adaptarse a las necesidades de cada proyecto, en oposición a lo que sería una metodología prescriptiva, porque parte de la base de que no hay una estructura óptima para las necesidades de todos los entornos de desarrollo posibles.
Los principios fundamentales del marco MSF son:
Comunicación abierta - Trabajo en torno a la visión compartida del sistema - Autonomía del equipo - Responsabilidades claras y compartidas - El objetivo es la entrega de valor para el negocio - Esperar el cambio - Invertir en calidad - Aprender de la experiencia.

MSF aplica estos principios en los procesos y en las personas, desarrollando un modelo de equipo y un modelo de procesos, que cubren tres disciplinas: gestión de proyecto, gestión de riesgos y gestión de la mejora del talento.

El marco incluye: conceptos clave, prácticas contrastadas y recomendaciones.

En 2005, el desarrollo del nuevo producto de Microsoft "Visual Studio Team System" generó la evolución de MSF hacia la versión 4.0, con dos líneas paralelas: MSF for Agile Software Development y MSF for CMMI.

Para sabe más:


OpenUP

El proceso de gestión OpenUP (Open Unified Process) es una parte del marco de desarrollo Eclipse (open source, y desarrollado por la fundación Eclipse).
Mantiene las característcas esenciales de RUP (Rational Unified Process), y las características de la gestión ágil: desarrollo iterativo e incremental.

Enlaces:

 

Oracle Unified Method (OUM)

Es un marco para desarrollo de software, iterativo e incremental, desarrollado por Oracle y orientado a su suite de productos: aplicaciones, "middleware" y base de datos.

Es otra variante ágil de UP (Unified Process).

 

PMBOK

Project Management Body of Knowledge es un modelo de gestión de proyectos, desarrollado por el Project Management Institute (PMI) en 1987 para documentar información y prácticas para la gestión de proyectos.
PMBOK identifica 5 áreas de procesos y 9 áreas de conocimiento comunes a todos los proyectos.
Desarrolla un modelo de gestión de proyectos predictivo, y ha tomado el rango de estándar: IEEE Std 1490-2003

Enlaces:

PMI

PRINCE y PRINCE2

PRojects IN Controlled Environments (PRINCE) es un modelo de gestión de proyectos desarrollado en 1989 por la Central Computer and Telecommunications Agency (CCTA) como estándar para la gestión de proyectos de tecnologías de la información.
PRINCE2 fue el resultado de la revisión realizada en 1996 sobre PRINCE, que pasa a ser un desarrollo de la Office Government Commerce (OGC), dependiente de la administración británica, y amplía su ámbito para proyectos de cualquier tipo, más allá de las tecnologías de la información
Desarrolla un modelo de gestión de proyectos predictivo, adaptable a las características del proyecto en cuanto al conjunto de prácticas que deben contemplarse.

 

Scrum

Metodología ágil centrada en la gestión y seguimiento ágil de proyectos, a través de ciclos cortos de desarrollo. Es uma implementación realizada por Ken Schwaber, Mike Beedle y Jeff Shuterland de los principios empleados por los equipos de trabajo "Scrum" definidos por Nonaka y Takeuchi en 199

Los principios de Scrum son: equipos auto-gestionados - Un avez dimensionadas las tareas no es posible agregar trabajo extra - reuniones de seguimiento diarias - ciclos de desarrollo de frecuencia inferior a un mes (propuesta original dos meses), que entregan una parte del producto completamente terminada.

Enlaces:

 

Scrum Manager

Es unodelo de evaluación y mejora desarrollado de forma abierta y libre por la comunidad profesional de gestores e ingenieros de software.


Enlaces:


 TDD

Desarrollo guiado por pruebas (Test-driven developmetn - TDD) es una técnica de programación definica por Kent Beck cuyas prácticas comienzan por elaborar primero el código que probará una funcionalidad, antes de programar la funcionalildad, y a continuación desarrollar y refactorizar el código hasta que se pasan satisfactoriamente. Estas prácticas eliminan los aspectos negativos que implican las pruebas en los procesos secuenciales de programación.

 

Unified Process

Marco de desarrollo ágil, iterativo e incremental, que solapa las tres fases de desarrollo (elaboración, construcción y transición) en iteraciones breves de tiempo cerrado. En determinados proyectos también puede solaparse la fase previa de inicio.

Unified Software Development Process, comprende la definición general de este tipo de ciclo ágil: iterativo e incremental, pero no la concreción en procedimientos o prácticas determinadas, y son varios los autores y organizaciones que han desarrollado variaciones y concreciones sobre este patrón UP genérico:

- RUP - Rational Unified Process, por IBM / Rational.
- OpenUP Open Unified Process, por Eclipse como evolución del previo Basic Unified Process (BUP)
- OUM Oracle Unified Method
- AUP Agile Unified Process, por Scott W. Ambler
- EssUP Essential Unified Process, por Ivar Jacobson

 A excepción de RUP, el resto se pueden considerar ágiles, con más o menos reparos; o al menos sus autores o promotores lo consideran, aunque también es habitual encontrar foros en los que se pueda cuestionar o criticar determinado aspecto de determinada metodología como ágil o no ágil.

 

Trackback(0)
Comentarios (5)Add Comment
+1 !!
escrito por a, October 29, 2008
ffua! adoro este artículo. muchas gracias!

sólo tengo una queja menor. le echo en falta una pequeña tabla de contenidos. como si fuera una página de wiki... o espera, mejor sugiero, si es posible, ponerlo directamente en una página de wiki. así no hay que actualizar la tabla de contenidos manualmente conforme el contenido cambie.

gracias otra vez.

saludos
En un buen momento
escrito por Julio Trujillo Leon, November 03, 2008
En un buen momento llega este artículo para despehjar dudas, ahora que en españa están pegando fuerte las adopciones de metodologías de desarrollo, gracias autor.
Me parece bueno
escrito por Daniel Lévano Rodriguez, December 16, 2008
Una sugerencia. Seria bueno hacer una tabla comparativa de los modelos propuestos.
Sigo sin estar de acuerdo con la clasificacion.......
escrito por Jonathan, December 07, 2009
Sigo creyendo que se clasifica muy mal al PMI................ ah, y no son 5 procesos sino 42 procesos agrupados en 5 grupos de procesos y 9 areas de conocimiento........

Porque se insiste en decir que es predictiva ? lo es tanto como Scrum....... PMI recomienda el desarrollo evolutivo o rolling wave, que es justamente lo que hace Scrum........... acaso si cogieramos cada Sprint de Scrum como un proyecto, no seria predictivo tambien ? y mucho mas rigido puesto que no acepta ningun tipo de cambio durante el desarrollo del Sprint........
Scrum vs PMP
escrito por Vanessa, January 14, 2013
En referencia al comentario de Daniel Lévano, quisiera decir que ,en mi humilde opinión, las metodologías predictivas, a parte de su rigidez, no tienen en cuenta al equipo. Para hacer una estimación sólo se contemplan los procesos, la arquitectura en la que se implementarán, riesgos, etc, pero todo es a priori y sin contar con el equipo de personas que trabajarán en el proyecto. Cuando he trabajado como programadora o analista, siempre me ha venido todo dado. Y pocas veces se me ha preguntado antes de presentar una estimación al cliente y menos aún son las que se ha tomado en cuenta mi criterio. En SCRUM, el alcance depende del equipo, el ritmo de trabajo será sostenible y continuado en función del equipo y con el conocimiento absoluto de cuáles son los objetivos del cliente, la meta hacia la que se camina. Y creo que la aplicación de esta perspectiva tiene más probabilidades de éxito.

Escribir comentario

busy
 
< Anterior   Siguiente >
Advertisement





Artículos relacionados

Registrado en Safe Creative