Plantilla de especificación de requisitos de software (ERS) al estilo de DAC (I)

Plantilla ERS Especificación de Requisitos de Software

Uno de los principios de DAC es generar solo la documentación necesaria para garantizar la calidad del proceso y los productos. Es por esto que DAC propone en su expediente de proyecto de referencia 3 diferentes plantillas para especificar requisitos de software detallados y una plantilla para la Especificación de Requisitos del Software Entregable:

• Especificación General de Requisitos de Software ERS 
• Descripción técnica de requisitos detallada para nuevos desarrollos guiados por requisitos (Publicada en este blog) 
• Especificación funcional de requisitos mediante ingeniería inversa (Próximamente aquí) 
• Especificación de requisitos para desarrollo rápido (Próximamente aquí)

Es válido aclarar que las plantillas de especificación de requisitos que propone DAC se basan en el estándar IEEE 830.

En la etapa de Análisis y Diseño de Alto Nivel (Ver el Ciclo de vida de DAC) el analista a partir del levantamiento de requisitos confecciona un catálogo tratando de desglosar los requisitos hasta el más bajo nivel a partir de los requisitos de alto nivel obtenidos en la elicitación de los requisitos.

Luego hace un análisis de estos requisitos de manera general para tener una idea de cómo engranarlos e integrarlos en el software. Durante este análisis puede que se agreguen, eliminen o modifiquen requisitos. La salida fundamental de esta etapa es la Especificación de Requisitos de Software que va a servir de guía para la posterior especificación detallada ya enfocada a la implementación de los requisitos y además va a permitir mostrarle al cliente descripciones de los requisitos que ellos puedan entender.

Esta es la plantilla que explicaremos hoy: "Plantilla ERS Especificación de Requisitos de Software". Descargarla aquí.

Secciones del documento ERS para especificación de requisitos funcionales y no funcionales

El documento ERS puede tener tantas secciones como se consideren necesarias según lo que espera y pide el cliente y las necesidades de validación que tiene el equipo de proyecto. Al ser un documento entregable debe estar escrito correctamente y evitar el uso de términos técnicos. Estas son las secciones básicas que propone DAC en su plantilla aunque cada organización es libre de definir su plantilla de ERS a partir de sus necesidades y tipos de proyecto:

1. Vista del producto: en esta sección debería ir la descripción general del software, un resumen de requisitos clasificados pro complejidad y prioridad, también clasificados por sprint y entregas o versiones. Una parte muy importante de esta sección es el Modelo conceptual y el diccionario de datos del modelo conceptual. En futuros artículos hablaremos específicamente de los diccionarios de datos. 
2. Catálogo de requisitos funcionales: en un formato bien definido y agrupados por requisitos de alto nivel y agrupaciones lógicas de funcionalidades se especifican a grandes rasgos los requisitos funcionales. 
3. Componentes del sistema: en esta sección se explican los módulos o componentes del sistema haciendo una breve descripción de cada uno. 
4. Catálogo de requisitos no funcionales: en un formato bien definido se especifican los requisitos no funcionales.

Ejemplo de escenario de especificación de requisitos al estilo DAC

Aquí puedes encontrar un ejemplo de tabla para especificar requisitos funcionales en la ERS general. Esta tabla está basada en la idea de la Historia de Usuario, en este caso. Entre los stakeholders designados por el cliente para la definición y validación de los requisitos y el analista o miembro designado del equipo de proyecto deben enriquecer cada requisito:

Luego de que esta ERS sea validada con el cliente y una vez se tenga clara y establecida la arquitectura que soportará los requisitos planificados para la siguiente versión/entrega, se puede pasar a la siguiente etapa, donde el analista desarrollará los requisitos junto a los especialistas de calidad en plantillas más detalladas para que los requisitos puedan ser correctamente implementados y probados.

Una de estas especificaciones o descripciones detalladas las explico en mi siguiente artículo: Plantilla de especificación de requisitos de software. Descripción detallada

Pautas para la especificación de requisitos de software dirigidas al cliente

El analista o miembro designado del equipo debe tener en cuenta un conjunto de buenas prácticas para especificar requisitos enfocados al cliente:

1. Utilizar lenguaje natural, evitar detalles técnicos y de implementación. 
2. Utilizar una correcta ortografía. 
3. Pensar que lo que estás describiendo debe ser posible de programar y probar. 
4. Analizar la prioridad y complejidad para poder determinar el alcance de cada Entrega o Versión. 
5. Tratar de que en u solo documento quede recogida toda la información que el cliente debe validar, especialmente campos, validaciones fundamentales, requisitos funcionales y requisitos no funcionales. 
6. Llevar un correcto control del documento describiendo cada cambio y en que versión del producto se incorpora. 
7. Pensar durante la especificación a quien está dirigido el documento para que les sea útil. En este caso es para clientes y stakeholders externos al proyecto peor vinculados directamente ocn el objeto de informatización. 

Plantilla de especificación de requisitos de software al estilo de DAC (II). Descripción detallada.

Repasando el artículo anterior

En la primera parte de este artículo hablamos sobre la plantilla general de especificación de requisitos (descárgala aquí) que se hace en lenguaje natural y está enfocada a tener una comprensión general de cómo debe funcionar el sistema pero sin entrar en detalles de implementación.

En el artículo de hoy explicaremos una de las más utilizadas: 

La plantilla de especificación de requisitos detallada para implementación de un requisito de nuevo desarrollo.

En este link pueden descargar la plantilla completa.

¿Cuándo usar esta plantilla?  

1. Esta plantilla es muy detallada y se recomienda para proyectos que cuenten con al menos una analista dedicada a realizar este trabajo. 
2. Además si el proyecto es altamente complejo en cuanto a negocio o implementación también se recomienda utilizar esta plantilla. 
3. Cuando deseas tener los requisitos bien documentados. 
4. Cuando los casos de prueba o las pruebas se hacen a partir de los requisitos especificados.

La plantilla para especificación detallada de requisitos y sus partes

La mejor forma de describir estos requisitos es mediante la técnica de escenarios mezclada con la técnica del prototipado. En una tabla de varias secciones se van especificando cada uno de los pasos lógicos que debe seguir el programador para implementar el requisito. Como una imagen vale más que mil palabras explicaremos cada sección o grupo de secciones mediante imágenes.

Parte 1: Datos generales y de trazabilidad

Parte 2: Lo que se debe analizar antes de entrar en el flujo

Parte 3: Describir los flujos del requisito y las condiciones finales

• Flujo básico: Es el curso normal y satisfactorio del requisito 
• Flujos alternos: Cualquier desviación o alternativa en un paso del flujo básico o de otro flujo alterno

Parte 4: Mensajes y observaciones

Pautas para la especificación detallada de requisitos de software

El analista debe tener en cuenta un conjunto de buenas prácticas para especificar requisitos que están dirigidos al equipo de desarrollo, dígase programadores y probadores:

1. Llegar hasta el más bajo nivel en la descripción de los flujos, precondiciones y pos-condiciones. 
2. Utilizar una correcta ortografía. 
3. Pensar cómo se haría lo que estás describiendo a nivel de programación y como puede ser probado. 
4. Utilizar referencias a otros documentos donde se encuentren las reglas de negocio, diccionarios de datos, modelos de datos, mapa de navegación y otros requisitos, por lo general estamos hablando del modelo de diseño y de la ERS. 
5. Codificar todo lo que sea posible y me refiero por ejemplo a mensajes del sistema, nomencladores, objetos y enumeradores predefinidos del negocio. Tratar de que todo esto se encuentre centralizado para evitar errores y repeticiones innecesarias. 
6. No repetir el texto de reglas de negocio, requisitos y clases o entidades referenciados sino poner solo su código. Estos deben estar en un lugar centralizado para evitar problemas de trazabilidad ante una modificación. 
7. Llevar un correcto control del documento describiendo cada cambio y en que versión del producto se incorpora. 
8. Hacer un documento de descripción detallada de requisitos (DR) por cada requisito hace más fácil su localización, control de cambios y trazabilidad. 
9. Pensar durante la especificación a quien está dirigido el documento para que les sea útil. En este caso es para desarrolladores y probadores por lo que debe ser una guía lo suficientemente detallada para poder programar y probar el requisito.

Definiendo las prácticas de DAC

El Manifiesto Ágil

La aplicación de los valores y principios del manifiesto ágil (Beck et al., 2001) así como prácticas ágiles para la gestión de proyectos mejoran considerablemente los resultados de calidad del proyecto medidos en: indicadores de ejecución del proyecto, número de no conformidades encontradas en evaluaciones de calidad del proceso y productos de trabajo, satisfacción del cliente.

Basada en los principios y valores del manifiesto ágil (Beck et al., 2001) DAC defiende lo siguiente:

• Es prioridad para el proyecto satisfacer los acuerdos tomados con el cliente a través de la entrega temprana y continua de software de valor que cumpla con los atributos de calidad definidos. 
• El cambio es bienvenido pero controlado, dejando siempre constancia de las solicitudes realizadas y las decisiones a tomar al respecto. Los cambios no pueden comprometer el éxito y la calidad del proyecto. 
• Los involucrados relevantes, tanto externos como internos, deben estar en constante comunicación y realizar reuniones de chequeo del avance del proyecto de forma frecuente. 
• Es vital para la gestión de la comunicación en el proyecto explotar las bondades de las nuevas tecnologías y la red. No obstante se declara como la forma más efectiva de comunicación la conversación cara a cara. 
• Construir el proyecto con individuos capacitados en todo momento garantiza la mitad del éxito. 
• La atención continua a la excelencia técnica enaltece la agilidad y determina la calidad. 
• La reunión diaria es una técnica eficaz para mejorar la comunicación y la resolución de problemas; mientras que la reunión de chequeo y análisis de resultados, en intervalos regulares, se aprovecha para que el equipo reflexione sobre la forma de ser más efectivo y ajustar su conducta en consecuencia. 
• La planeación colaborativa, iterativa y detallada no quita agilidad, brinda control. 
• Evitar a toda costa tener documentación repetida.

Metodologías Ágiles

Las metodologías ágiles de desarrollo de software como XP, Scrum, proceso guiado por funcionalidades (FD, Feature Driven Development) y otras, prevalecen cada vez más en la industria del Software. DAC toma elementos de estas metodologías.

De XP (Beck y Andres, 2004; Jeffries, Anderson, y Hendrickson, 2001) se retoma la idea de realizar un plan de entregas, en este caso versiones del producto, realizando durante el mantenimiento de la primera versión nuevas iteraciones para desarrollar las siguientes versiones del software. Se propone además retomar la idea de las siguientes prácticas XP adaptadas al concepto de DAC: 

• El uso de la metáfora mediante diagramas de paquetes lógicos a partir del estudio del negocio o los requisitos de alto nivel. 
• Diseño simple, abarcando únicamente el modelado del sistema mediante diagramas de paquetes o componentes solo hasta el nivel de funcionalidad. Se incluye como parte del diseño el mapa de navegación y el modelo de datos. No se realizan en DAC diagramas de clases o tarjetas clase-responsabilidad-colaboración (CRC). No son necesarios si en la implementación se aplican correctamente los patrones arquitectónicos y de diseño definidos. 
• La producción del código está dirigida por pruebas de unidad desde el nivel de funcionalidad hasta el nivel de módulos para evitar no conformidades futuras en revisiones de calidad del producto. 
• La refactorización del código antes de las pruebas finales contribuyen a la calidad del software disminuyendo la ocurrencia de no conformidades. 
• Integración continua de cada componente del software una vez sea liberado por el grupo de aseguramiento y control de la calidad. 
• Estándares de programación para fomentar la reutilización del código y la comunicación entre programadores. 

DAC también asume todos los valores de Scrum (Palacio; Schwaber & Beedle, 2002). Esta metodología tiene buenas prácticas que se pueden aplicar en DAC:

• Revisión de las iteraciones con el equipo de proyecto. Las iteraciones en DAC pueden ser tan largas como se determine en la planificación con el cliente. En DAC hay dos tipos de iteraciones: iteraciones por versiones del producto e iteraciones por versiones de componentes. 
• Desarrollo incremental obteniendo en cada iteración al menos un componente del software pudiendo ser este una entrega pactada o parte de ella. 
• Desarrollo evolutivo, aunque en las fases iniciales de cada versión del producto se define una arquitectura y diseño de alto nivel, esta se va actualizando y mejorando durante las iteraciones. 
• Colaboración entre los miembros del equipo de desarrollo. DAC pone especial énfasis a compartir y socializar el conocimiento partiendo del hecho de que un equipo de proyecto es una comunidad de desarrollo. También se propone el uso de repositorios de activos de productos y componentes. 
• DAC define varios tipos de reuniones: reunión de inicio de una iteración, reunión diaria, reunión de análisis de resultados (máximo cada 30 días), reunión de chequeo de acuerdos con involucrados, reunión de cierre de iteración. 

Por otra parte, de la metodología FDD (Palmer & Felsing, 2001) se retoma en DAC la idea del desarrollo de un modelo inicial de alto nivel, que se corresponde con la metáfora de XP. DAC indica que debe establecerse una arquitectura base para poder iniciar el desarrollo a partir de la priorización y agrupamiento de los requisitos del cliente o de alto nivel. Estos requisitos se traducen en objetivos del proyecto, que guiarán el proceso de desarrollo mediante su desglose, refinamiento, análisis, especificación y validación en las distintas fases.


También se incluyen actividades como el estudio de los documentos, el desarrollo de un modelo en áreas y un modelo global. De estos modelos salen las propuestas de componentes en distintos niveles de empaquetamiento y de cada componente las iteraciones necesarias para desarrollarlos.

Prácticas ágiles

En Letelier (2013) se presenta una lista creada por este autor de 42 prácticas ágiles “a modo de carta de restaurante para que cada equipo configure su propio menú”. Además, explica que “Este enfoque conlleva la promoción de una estrategia de implantación que apuesta por combinar prácticas cogidas desde diferentes métodos ágiles”. La mayoría de estas prácticas se aplican en DAC de forma íntegra; sin embargo otras deben aplicarse haciendo algunas adaptaciones. Entre estas:

• Formar equipos pequeños (si el trabajo está organizado se puede dividir un equipo grande en pequeños grupos de desarrollo). 
• El equipo se autoorganiza y toma las decisiones técnicas (a veces un equipo que se autoorganiza tiende a acomodarse y no planificar de la manera más eficiente). 
• Colocalización de miembros del equipo, todo el equipo trabajando en el mismo espacio físico (con el uso de las tecnologías de la información y comunicaciones esto no es necesario, al menos no siempre). 
• Que los integrantes del equipo no tengan solo algunas actividades fijas asignadas (es ideal un equipo así pero en DAC se le da mucha importancia a la especialización de cada miembro en su rol). 
• Documentar, pero solo lo estrictamente necesario, que sea rentable el aprovechamiento de la documentación respecto del esfuerzo asociado a elaborarla (en DAC es utilizar cada uno de los productos de trabajo definidos en la metodología de la manera más eficiente y en el momento que corresponda). 
• Establecer pautas para gestionar convenientemente el retrabajo (mientras sea posible evitar el retrabajo y si ocurre debe analizarse, priorizarse e incorporarse a la planificación). 

Definiendo las prácticas de DAC

Uniendo todo lo anteriormente expuesto junto a un conjunto de buenas prácticas generales en el desarrollo de software a continuación se resumen las prácticas de DAC. 

Calidad en la gestión de los recursos humanos:

• Realizar las reuniones necesarias planificadas. 
• Comunicación mediante las redes e internet y cara a cara siempre que sea posible. 
• Capacitación constante del equipo. 
• Socialización del conocimiento. 
• Colaboración constante. 
• 40 horas semanales. 

Calidad de los productos de trabajo:

• Definir la arquitectura de alto nivel al inicio de cada versión. 
• Planificación conjunta entre cliente y equipo de proyecto. 
• Arquitectura y diseño basados en componentes y patrones. 
• Refactorización de código. 
• Integración continua. 
• Estándar de código. 
• Pruebas en cada iteración y versión (pruebas funcionales, de integración, no funcionales, aceptación alfa y beta). 
• Desarrollo evolutivo-incremental. 
• Evaluar la calidad de cada entregable. 
• Gestionar líneas base. 
• Revisar y gestionar inconsistencias entre los productos de trabajo. 

Calidad en los procesos:

• Documentar, firmar y satisfacer los acuerdos con involucrados y compromisos con el plan. 
• Controlar y firmar las solicitudes de cambio. 
• Planificar y ejecutar el aseguramiento de la calidad del proceso y del producto. 
• Planificar guiado por entregas y requisitos. 
• Adaptar los procesos definidos. Ÿ Seguir los procesos definidos. 
• Analizar los resultados. 
• Documentar los procesos y sus guías. 
• Debe existir un administrador de la calidad y la configuración. 
• Firmar actas de aceptación de los entregables. 
• Monitorear los procesos. 
• Elaborar productos de trabajo simples que cumplan con su propósito de uso.

Nota importante: Estos fragmentos han sido tomados de: http://revistas.proeditio.com/iush/quid/article/download/82/82. En dicho artículo podrán encontrar las referencias bibliográficas.

Integrando Ágil, CMMI, ISO/IEC 12207 y PMBOK en DAC

Estudios realizados sobre integración de ágil y modelos de calidad

En (2012) se trata de establecer algunas ideas que demuestran que “CMMI no tiene ningún requisito que impida a una organización conseguir una clasificación de CMMI mientras usa un proceso ágil”, además se ejemplifican casos reales en los que ha sido posible recibir una clasificación de CMMI aplicando métodos ágiles para el desarrollo.

En la actualidad se encuentran además varios estudios de casos exitosos en la mejora de procesos usando CMMI dentro de un contexto ágil tales como Pikkarainen y Mäntyniemi (2006), Boehm y Turner (2003) y Anderson (2005); Glazer et al. (2008). Además se puede decir que Bernal Cam y Calderón Valverde (2011), Fernández Díaz (2009), Navarro y Garzás (2010) y Sutherland y Ruseng (2008) estudian probables y palpables beneficios de esta integración. En el caso de Paulk (2001) se estudia específicamente la metodología de Programación Extrema (XP, eXtreme Programming) desde la perspectiva de CMMI. De la misma forma existen otros que dan argumentos en contra del uso de ambos de manera conjunta de acuerdo con la investigación de Matalonga (2012).

Ejemplos de investigaciones que explican cómo adaptar los procesos de PMBOK en proyectos que desarrollan ágil son Cottmeyer (2010), Sliger (2006a, 2006b). También existen estudios comparativos entre ambas tendencias como Fitsilis (2008) y Udo y Koppensteiner (2003); y otros como D. G. O'Sheedy, Xu, y Sankaran, (2010), Grey (2012) y D. O'Sheedy y Sankaran (2013) que muestra resultados concretos de la integración entre ágil y PMBOK.

Necesidades actuales de mejora de procesos en el desarrollo ágil

En la actualidad por lo general las empresas parten de aplicar una metodología junto a un modelo específico. De forma independiente metodologías y modelos tienen ventajas y desventajas a raíz de las características propias de cada proyecto y terminan por aplicarse junto a un conjunto de prácticas empíricas y no documentadas de cada equipo de proyecto. Esto les permite a los equipos solventar los problemas y deficiencias que puedan tener al aplicar una metodología de las ya existentes junto a un modelo de calidad. Esta práctica tan común trae consigo el hecho de que el conocimiento y la descripción del proceso real recaen en las personas y la transmisión de este conocimiento depende de estas.

De ahí la necesidad de establecer una metodología que recopile esas buenas prácticas tanto empíricas como definidas y las concentre en un modelo. 

La metodología DAC, PMBOK, CMMI e ISO

La metodología que se propone, Desarrollo Ágil con Calidad (DAC), trata de parecerse a la forma en que empíricamente trabajan los proyectos ágiles estableciendo al mismo tiempo pautas de calidad, procesos definidos y prácticas ágiles.

En las primeras versiones de CMMI y PMBOK no se tuvo en cuenta su aplicación junto a métodos ágiles de desarrollo de software. Sin embargo en las últimas versiones de ambos se introducen elementos, notas, procesos específicos para su aplicación en estos entornos.

En el PMBOK se definen 47 procesos de dirección de proyectos, 5 grupos de procesos de dirección de proyectos y 10 Áreas de Conocimiento de la Dirección de Proyectos (Meléndez De La Cruz, 2013).

CMMI-DEV contiene 22 áreas de proceso. De esas áreas de proceso, 16 son áreas de proceso base, 1 es un área de proceso compartida y 5 son áreas de proceso específicas de desarrollo.

Las áreas de procesos se organizan en cuatro categorías: Gestión de Procesos, Gestión de Proyectos, Ingeniería y Soporte (CMMIProductTeam, 2010).

En la Norma ISO/IEC 12207 (IEEE, ISO, & IEC, 2008) los procesos del ciclo de vida del software se agrupan en procesos de acuerdos, procesos de proyecto-activación organizacional, procesos de proyecto, procesos técnicos, procesos de implementación de software, procesos de soporte al software y procesos de reutilización del software.

La metodología DAC tiene ocho etapas del ciclo de vida llamadas fases o procesos: inicio del proyecto, análisis y diseño de alto nivel, desarrollo de requisitos, construcción del producto, cierre de iteración, liberación del producto, transición del producto y cierre del proyecto.

También cuenta con dos áreas de procesos de protección: gestión de proyectos y soporte; y las disciplinas de ingeniería: modelado del negocio, arquitectura y diseño, especificación de requisitos, implementación, pruebas, despliegue y mantenimiento.

En la Tabla 1 se muestra cómo integrar DAC con el PMBOK en cuanto a los grupos de procesos.

Tabla 1 Correlación entre DAC y PMBOK.

DAC	PMBOK
Inicio del proyecto	Grupo de procesos de iniciación
Análisis y diseño de alto nivel	Grupo de procesos de planificación
Desarrollo de requisitos	Grupo de procesos de ejecución Grupo de procesos de seguimiento y control
Construcción del producto
Cierre de iteración
Liberación del producto
Transición del producto
Cierre del proyecto	Grupo de procesos de cierre

Para incorporar a DAC las áreas de proceso de CMMI se definieron como complemento a los ocho procesos básicos de DAC un proceso para área de proceso CMMI de las siguientes:

Gestión de Proyectos: REQM, PP, PMC, SAM, IPM, OPD, OPF, RSKM, QPM.

Soporte: CM, MA, PPQA, DAR, OT, OPP, CAR, OPM.1

Estos procesos de gestión de proyectos y soporte son de apoyo y solo son de obligatorio cumplimiento los procesos de gestión de la configuración, gestión de requisitos, aseguramiento de la calidad de procesos y productos, medición y análisis, monitoreo y control, planificación del proyecto y gestión de acuerdos con proveedores. El resto son opcionales a decisión de cada entidad desarrolladora.

Las áreas de proceso de la categoría ingeniería de CMMI se definen dentro de los ocho procesos básicos vinculadas a las disciplinas de ingeniería. Las áreas del conocimiento de PMBOK están incorporadas en la definición de los procesos de gestión de proyecto.

De igual forma los procesos de la ISO/IEC 12207 se definieron dentro de los procesos de gestión de proyecto, soporte y las disciplinas de ingeniería como se muestra en la tabla 2.

Tabla 2 Integración de ISO/IEC 12207 y CMMI

CMMI1	ISO/IEC 12207
TS	Instalación del software Implementación del software Diseño arquitectónico del software Diseño detallado del software Construcción del software Ingeniería de dominio Gestión de reutilización de software Gestión de reutilización de activos
RD	Análisis de requisitos del software
PI	Instalación del software Integración del software
VER	Pruebas de calificación del software Verificación del software
VAL	Pruebas de calificación del software Soporte de aceptación del software Mantenimiento del software Validación del software
REQM	Definición de requisitos de los involucrados
PP	Planificación del proyecto
PMC	Evaluación y control del proyecto
SAM	Adquisición Proceso de oferta
IPM	Gestión de la Información Gestión del Modelo del Ciclo de Vida Gestión de la Infraestructura Gestión de los Recursos Humanos Gestión de la Calidad
CM	Gestión de la Configuración Gestión de la Configuración del Software
MA	Medición
RSKM	Gestión de Riesgos
PPQA	Aseguramiento de la Calidad del Software Revisión del Software Auditoría del Software
DAR	Resolución de Problemas del Software Gestión de Decisiones
CAR	Resolución de Problemas del Software Gestión de Decisiones

1

Por cuestión de espacio se referencian las áreas de procesos por sus siglas según CMMIProductTeam, (2010).

Nota importante: Estos fragmentos han sido tomados de: http://revistas.proeditio.com/iush/quid/article/download/82/82. En dicho artículo podrán encontrar las referencias bibliográficas.

Introduciendo las bases de DAC

El desarrollo ágil en la actualidad

En el año 2001 diecisiete especialistas, convocados por Kent Beck, definieron el término “Métodos Ágiles” para referirse a las metodologías que estaban surgiendo como alternativa a las tradicionales. Los integrantes de la reunión resumieron en el Manifiesto Ágil cuatro valores y doce principios sobre los que se basan los métodos alternativos (Beck et al., 2001).

Al consultar el Chaos Manifiesto (The Standish Group International, 2013) se puede constatar que uno de los factores de éxito de los proyectos en el 2012 fue acatar un proceso ágil. En el caso específico de los proyectos pequeños se identificaron en este reporte un total de 10 puntos de éxito para la implementación de un proceso ágil.

En los últimos años la adopción de los métodos ágiles para el desarrollo se ha incrementado. Según el World Quality Report (Reporte de Calidad Mundial) del 2013-2014 (HP, Ayer Sogeti, & Capgemini, 2013) el 83% de las empresas usan metodologías ágiles para el desarrollo de sus aplicaciones, ya que éstas les permiten adaptarse mejor a los cambios del mercado. El 46% de estas empresas no disponen, sin embargo, de técnicas de prueba consistentes para estas metodologías. El World Quality Report se basa en entrevistas a 1500 directores de TI de 25 países.

CMMI DEV 1.3, PMBOK y ÁGIL

Por otro lado el Modelo de Integración de Capacidad y Madurez (CMMI, por sus siglas en inglés) en su revisión 1.3 (CMMIProductTeam, 2010) es el patrón de la mejora de proceso en el dominio del desarrollo de software pues provee un enfoque sistémico y sistemático para la mejora de procesos. Según estadísticas de CMMI Institute, (2014) ha habido más de 9500 evaluaciones de 84 países hasta marzo del 2014. Entre estos países se encuentra Cuba con una certificación de CMMI para Desarrollo (CMMIDEV), de la Universidad de las Ciencias Informáticas. A nivel mundial los países con mayor

cantidad de evaluaciones CMMI son China, Estados Unidos, India, España, Japón, Corea del Sur, México, Brasil, Francia y Taiwán (CMMI Institute, 2014).

En cuanto a la gestión de proyectos el estándar por excelencia es el Cuerpo del Conocimiento para la Gestión de Proyectos ( PMBOK, Project Management Body of Knowledge), Desarrollado por el Project Management Institute (PMI, 2013). El PMI actualiza la versión del PMBOK cada 4 años (Meléndez De La Cruz, 2013).

En él se explican una serie de puntos o factores de éxito para los proyectos; entre estos destaca la correcta elección de los procesos de gestión de proyectos, así como el enfoque de desarrollo del software y por ende la metodología (PMI, 2013).

Con el fin de hacerse de un nombre y prestigio en la industria del software las empresas optan por modelos y estándares como CMMI y PMBOK para certificar la calidad de su proceso de desarrollo y gestión del software. Para esto necesitan mostrar un conjunto de evidencias, por lo general documentales.

En este punto la empresa en ocasiones se ve ante la disyuntiva de escoger entre aplicar el modelo o estándar y aplicar métodos ágiles cuando en realidad todo es una cuestión de interpretación.

Equivocadamente se ven a los métodos ágiles como anti-documentos sin comprender realmente que las prácticas ágiles se hicieron para ser flexibles y adaptables a los cambios y las necesidades propias de cada proyecto. Por lo general los estándares y modelos te dicen qué tienes que hacer y posibles evidencias para demostrar que lo haces, pero no te dicen el cómo, ni te sujetan a utilizar formatos de documentos específicos para llevar registros de evidencias.

El crecimiento de la tecnología hace que los proyectos más modernos sean poco exitosos ya que los cambios tecnológicos se realizan con tanta rapidez que es muy difícil poder planificar a largo plazo. El cliente promedio de productos y soluciones de software de gestión exige entregas con frecuencias cortas debido a la necesidad de informatización de sus áreas de procesos. Al ser estos procesos cada vez más grandes y complejos el uso de un método tradicional para el desarrollo de software de gestión conllevaría un largo desarrollo y por ende una entrega tardía del software, a riesgo de que en el momento que este sea terminado los procesos hayan cambiado tanto que sea necesario modificarlo todo.

Apostar por los métodos ágiles favorece el éxito de los proyectos y la satisfacción de los clientes.

Enriquecer estos métodos con modelos, estándares y normas de calidad constituye el broche de oro para la gestión de proyectos en el entorno actual. El agilismo y la calidad no tienen por qué utilizarse como términos opuestos. Una integración de ambos permitirá enaltecer la calidad manteniendo la agilidad en el desarrollo.

Este artículo tiene como objetivo presentar una metodología para el desarrollo de software de gestión, integrando las prácticas ágiles, estándares internacionales de gestión de proyectos y calidad de software y el modelo CMMI, para la mejora de las evaluaciones en los indicadores que miden la ejecución del proyecto, la satisfacción del cliente así como la calidad del proceso y del producto en proyectos de software.
Nota importante: Estos fragmentos han sido tomados de: http://revistas.proeditio.com/iush/quid/article/download/82/82. En dicho artículo podrán encontrar las referencias bibliográficas.