You are on page 1of 12

Quid N° 21, pp.

13-24, jul - dic, 2013, ISSN: 1692-343X, Medellín-Colombia

MODELO Y PRÁCTICAS ESENCIALES DE LA METODOLOGÍA DAC INTEGRANDO LOS
MÉTODOS ÁGILES, PMBOK Y CMMI-DEV

MODEL AND PRACTICES OF DAC METHODOLOGY INTEGRATING THE ÁGILE METHODS,
PMBOK AND CMMI-DEV

Ing. Alelí Sánchez Méndez
Universidad de las Ciencias Informáticas, Dirección de Informatización, Líder de proyectos en el
Departamento de Desarrollo. La Habana - Cuba
aleli@netcons.com.cu

(Recibido el 04-07-2014. Aprobado el 07-11-2014)

Resumen. El presente artículo tiene como objetivo elaborar una metodología para el desarrollo de software de
gestión basado en componentes, 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, la calidad del proceso y del producto en proyectos de software.
Esta metodología se llama DAC, siglas de Desarrollo Ágil con Calidad. Surge ante la necesidad de algunas
entidades desarrolladoras de software de adaptarse a los cambios, brindar software con calidad a sus clientes en
períodos cortos de tiempo y reducir siempre que sea posible los gastos. DAC es un compendio de prácticas de
PMBOK, CMMI-DEV, ISO/IEC 12207, XP, Scrum, FDD y el Manifiesto Ágil. Al aplicar DAC en una fábrica de
software la misma puede brindar a sus clientes la seguridad de tener como premisa la calidad en el proceso de
desarrollo. Esto garantiza por ende un nivel aceptable de calidad en los productos los cuales pueden entregarse en
períodos cortos de tiempo de forma incremental aportando valor de negocio para el cliente. La metodología DAC
está sustentada en una investigación de tipo explicativa donde se empleó, entre otros, el método experimental,
realizando un pre experimento con pre y post prueba con un solo grupo. Ha sido aplicada en una entidad
desarrolladora de software durante un año obteniendo resultados alentadores en cuanto a la ejecución del proyecto y
resultados de evaluaciones de calidad a procesos y productos.

Palabras clave: calidad de software, CMMI, DAC, enfoque ágil, metodologías ágiles, metodología de desarrollo
de software, proceso de desarrollo de software.

Abstract. This research aims to develop a methodology for the development of management software based on
components, integrating agile practices, international standards of project management and software quality and the
CMMI model for improving assessment indicators measuring project execution, customer satisfaction, quality of
process and product in software projects. This methodology is called DAC, which stands for Quality Agile
Development. This approach emerged as a response of some software development companies to adapt to changes,
providing quality software to customers in short periods of time and reduce costs whenever possible. DAC is a
compendium of practices from PMBOK, CMMI-DEV, ISO/IEC 12207, XP, Scrum, FDD and Agile Manifesto.
Applying DAC in a software factory that can provide its customers the security of having quality premised on the
development process. This therefore ensures an acceptable level of quality in products which can be delivered in
short time periods incrementally, adding business value to the customer. The DAC methodology is supported by an
investigation of explicative type where it was applied, among others, the experimental method by performing a pre
experiment with pre and post test with a single group. It has been implemented in a software developer organization
for one year with encouraging results in regard to compliance with production schedules, customer satisfaction and
results of evaluations of process and product quality.

Keywords: agile approach, agile methodologies, CMMI, DAC, software development methodology, software
development process, software quality.

Citar, estilo APA: Sánchez, A. (2013) Modelo y prácticas esenciales de la metodología DAC integrando los métodos ágiles PMBOK y CMMI-DEV. Revista
QUID, (21), 13-24.

implementación de un proceso ágil. 2013. por lo general documentales. Project términos opuestos. 2013). INTRODUCCIÓN En él se explican una serie de puntos o factores de éxito para los proyectos. Según informatización de sus áreas de procesos. cada proyecto.3 (CMMIProductTeam. India. Enriquecer estos métodos con modelos. A nivel mundial los países con mayor cambiado tanto que sea necesario modificarlo todo. 2010) es el patrón plazo. integrando las prácticas ágiles. Al ser estos estadísticas de CMMI Institute. Los integrantes de la reunión resumieron en el Manifiesto Con el fin de hacerse de un nombre y prestigio en la Ágil cuatro valores y doce principios sobre los que se industria del software las empresas optan por basan los métodos alternativos (Beck et al. de la Universidad de las Ciencias momento que este sea terminado los procesos hayan Informáticas. pp. Estados Unidos. sin documentos específicos para llevar registros de embargo. & Capgemini. Por lo general los estándares y 2013) el 83% de las empresas usan metodologías modelos te dicen qué tienes que hacer y posibles ágiles para el desarrollo de sus aplicaciones. España. convocados correcta elección de los procesos de gestión de por Kent Beck. Quid N° 21. En el caso específico disyuntiva de escoger entre aplicar el modelo o de los proyectos pequeños se identificaron en este estándar y aplicar métodos ágiles cuando en realidad reporte un total de 10 puntos de éxito para la todo es una cuestión de interpretación. Una integración de ambos Management Body of Knowledge). definieron el término “Métodos proyectos. Corea del Sur. por sus siglas en inglés) en su rapidez que es muy difícil poder planificar a largo revisión 1. Medellín-Colombia 1. 2014). (2014) ha habido procesos cada vez más grandes y complejos el uso de más de 9500 evaluaciones de 84 países hasta marzo un método tradicional para el desarrollo de software del 2014. Esta artículo tiene como objetivo presentar una metodología para el desarrollo de software de gestión. 2001). estándares 14 . así como el enfoque de desarrollo del Ágiles” para referirse a las metodologías que estaban software y por ende la metodología (PMI. El World Quality Report se basa en entrevistas a 1500 directores de TI de 25 países. jul . El agilidad en el desarrollo. ISSN: 1692-343X. a riesgo de que en el DEV). 2013). 2013). El cliente promedio de productos y soluciones de la mejora de proceso en el dominio del desarrollo de software de gestión exige entregas con de software pues provee un enfoque sistémico y frecuencias cortas debido a la necesidad de sistemático para la mejora de procesos. PMI actualiza la versión del PMBOK cada 4 años –(Meléndez De La Cruz. ni te sujetan a utilizar formatos de mercado. Brasil. pero no te éstas les permiten adaptarse mejor a los cambios del dicen el cómo. estándares y normas de calidad constituye el broche de oro para la En cuanto a la gestión de proyectos el estándar por gestión de proyectos en el entorno actual. Ayer Sogeti. Francia y Taiwán (CMMI Institute. El agilismo excelencia es el Cuerpo del Conocimiento para la y la calidad no tienen por qué utilizarse como Gestión de Proyectos (PMBOK. una entrega tardía del software. Entre estos países se encuentra Cuba con de gestión conllevaría un largo desarrollo y por ende una certificación de CMMI para Desarrollo (CMMI. Apostar por los métodos ágiles favorece el éxito de México. Equivocadamente se ven a los métodos ágiles como En los últimos años la adopción de los métodos ágiles anti-documentos sin comprender realmente que las para el desarrollo se ha incrementado. surgiendo como alternativa a las tradicionales. Para esto necesitan mostrar un Group International. de técnicas de prueba consistentes para evidencias. Según el prácticas ágiles se hicieron para ser flexibles y World Quality Report (Reporte de Calidad Mundial) adaptables a los cambios y las necesidades propias de del 2013-2014 (HP. los proyectos y la satisfacción de los clientes. estas metodologías. ya que evidencias para demostrar que lo haces. modelos y estándares como CMMI y PMBOK para certificar la calidad de su proceso de desarrollo y Al consultar el Chaos Manifiesto (The Standish gestión del software. 13-24.dic. Japón. Desarrollado por permitirá enaltecer la calidad manteniendo la el Project Management Institute (PMI. El crecimiento de la tecnología hace que los proyectos más modernos sean poco exitosos ya que Por otro lado el Modelo de Integración de Capacidad los cambios tecnológicos se realizan con tanta y Madurez (CMMI. entre estos destaca la En el año 2001 diecisiete especialistas. uno de los factores de éxito de los proyectos en el En este punto la empresa en ocasiones se ve ante la 2012 fue acatar un proceso ágil. 2013) se puede constatar que conjunto de evidencias. cantidad de evaluaciones CMMI son China.. El 46% de estas empresas no disponen.

Para esto se aplicaron entre aplicar una metodología junto a un modelo otros los métodos sistémico y experimental. sus metodologías más populares. modelos y estándares de ha sido posible recibir una clasificación de CMMI gestión de proyectos. el desarrollo basado en En la actualidad se encuentran además varios reutilización de componentes y la posible estudios de casos exitosos en la mejora de procesos integración de estos elementos. Paso 2: definir un modelo del proceso de desarrollo Además se puede decir que Bernal Cam y Calderón para software de gestión basado en componentes que Valverde (2011). para la mejora de las significativas entre los proyectos. específico. Quid N° 21. Pikkarainen y Mäntyniemi (2006). pp. 13-24. y otros como Informáticas (UCI) y el criterio de expertos. Ejemplos de investigaciones que explican cómo adaptar los procesos de PMBOK en proyectos que Paso 4: validar la metodología propuesta a través de desarrollan ágil son Cottmeyer (2010). METODOLOGÍA DE INVESTIGACIÓN 3. Navarro y integre métodos y prácticas ágiles de desarrollo. y Sankaran. En el caso de Paulk (2001) se estudia específicamente la metodología de Programación Paso 3: definir las actividades. ISO/IEC 12207 y PMBOK en DAC Para lograr el objetivo planteado fue necesario seguir un conjunto de pasos. herramientas a utilizar en beneficio de un mejor resultado en la aplicación de la misma. la satisfacción del cliente así experimento. O'Sheedy y Sankaran (2013) que muestra La investigación es de tipo explicativa ya que se resultados concretos de la integración entre ágil y analizará el estado actual del problema identificando PMBOK. comportamientos frecuentes y formas de resolver el problema mediante una En la actualidad por lo general las empresas parten de metodología o modelo. sus prácticas más usadas. Esto les permite a los equipos solventar los son pocos proyectos y todos proveen información problemas y deficiencias que puedan tener al aplicar necesaria para el experimento. ISSN: 1692-343X. eXtreme Programming) desde la productos de trabajo que conformarán una perspectiva de CMMI. Boehm y Turner (2003) y Anderson (2005). integración. así como usando CMMI dentro de un contexto ágil tales como herramientas de apoyo al proceso de desarrollo. prácticas y de Matalonga (2012). 2006b). Fernández Díaz (2009). También existen estudios proceso definido para los proyectos de comparativos entre ambas tendencias como Fitsilis informatización de la Universidad de las Ciencias (2008) y Udo y Koppensteiner (2003). Se empíricas y no documentadas de cada equipo de selecciona el universo como muestra debido a que proyecto. D. el enfoque ágil para el aplicando métodos ágiles para el desarrollo. desarrollo. modelos y ágil”. roles y Extrema (XP. (2010).1. Xu. Integrando Ágil. CMMI. Sliger los resultados obtenidos de su aplicación como un (2006a. una metodología de las ya existentes junto a un 15 . CONSTRUCCIÓN DE UN MODELO 2. La población total está constituida por aplicarse junto a un conjunto de prácticas por los 6 proyectos de informatización en la UCI. (2008). Glazer et al. logrando en cada uno un En (2012) se trata de establecer algunas ideas que objetivo parcial. como la calidad del proceso y del producto en proyectos de software. demuestran que “CMMI no tiene ningún requisito que impida a una organización conseguir una Paso 1: elaborar un marco teórico sobre los modelos clasificación de CMMI mientras usa un proceso de procesos para el desarrollo de software. O'Sheedy. además se ejemplifican casos reales en los que estándares de calidad. G. tareas. jul . De la misma forma existen metodología de desarrollo de software de gestión otros que dan argumentos en contra del uso de ambos basado en componentes que adopte el modelo de manera conjunta de acuerdo con la investigación definido así como proponer técnicas. 2013. posibles causas. Medellín-Colombia internacionales de gestión de proyectos y calidad de De la prueba se espera encontrar diferencias software y el modelo CMMI.dic. Garzás (2010) y Sutherland y Ruseng (2008) CMMI y los estándares de calidad y gestión de estudian probables y palpables beneficios de esta proyectos más adecuados. 3. Grey (2012) y D. demostrando que evaluaciones en los indicadores que miden la mejoró el grupo experimental luego de aplicado el ejecución del proyecto. De forma independiente metodologías y modelos tienen ventajas y desventajas a raíz de las Se realizará un preexperimento con pre y post prueba características propias de cada proyecto y terminan con un solo grupo.

construcción del producto. Medellín-Colombia modelo de calidad. procesos de requisitos. Sin embargo en las últimas Construcción del versiones de ambos se introducen elementos. despliegue y mantenimiento. PMBOK en cuanto a los grupos de procesos. Ingeniería y Soporte OPM. PP. 5 grupos de procesos de dirección de Transición del producto proyectos y 10 Áreas de Conocimiento de la Grupo de procesos de Cierre del proyecto Dirección de Proyectos (Meléndez De La Cruz. PMC. especificación de requisitos. Inicio del proyecto iniciación Análisis y diseño de Grupo de procesos de En las primeras versiones de CMMI y PMBOK no se alto nivel planificación tuvo en cuenta su aplicación junto a métodos ágiles Desarrollo de requisitos de desarrollo de software. medición y análisis.dic. Las áreas de procesos se organizan en cuatro IPM. procesos de soporte al proveedores. transición del incorporadas en la definición de los procesos de producto y cierre del proyecto. CMMI se definen dentro de los ocho procesos análisis y diseño de alto nivel. 13-24. liberación del producto. proyecto. la transmisión de este conocimiento depende de arquitectura y diseño. La metodología que se propone. OPF. Para incorporar a DAC las áreas de proceso de CMMI-DEV contiene 22 áreas de proceso. MA. DAR. SAM. OT. Gestión de Ÿ Soporte: CM. implementación. Desarrollo Ágil con Tabla 1 Correlación entre DAC y PMBOK. RSKM. (2010). 1 Por cuestión de espacio se referencian las áreas de procesos por sus siglas según CMMIProductTeam. categorías: Gestión de Procesos. El resto son opcionales a decisión de software y procesos de reutilización del software. desarrollo de básicos vinculadas a las disciplinas de ingeniería. notas. procesos de productos. pp. de apoyo y solo son de obligatorio cumplimiento los 2008) los procesos del ciclo de vida del software se procesos de gestión de la configuración. estas. 1 es procesos básicos de DAC un proceso para área de un área de proceso compartida y 5 son áreas de proceso CMMI de las siguientes: proceso específicas de desarrollo. 2010). Grupo de procesos de procesos definidos y prácticas ágiles. Estos procesos de gestión de proyectos y soporte son En la Norma ISO/IEC 12207 (IEEE. cada entidad desarrolladora. ISO. 16 son áreas de proceso base. requisitos. CAR. OPD. Proyectos. procesos técnicos. jul . Calidad (DAC). procesos de planificación del proyecto y gestión de acuerdos con implementación de software. trata de parecerse a la forma en que empíricamente trabajan los proyectos ágiles DAC PMBOK estableciendo al mismo tiempo pautas de calidad. & IEC. Esta práctica tan común trae También cuenta con dos áreas de procesos de consigo el hecho de que el conocimiento y la protección: gestión de proyectos y soporte. gestión de proyecto. Quid N° 21. 16 . La metodología DAC tiene ocho etapas del ciclo de Las áreas de proceso de la categoría ingeniería de vida llamadas fases o procesos: inicio del proyecto.1 (CMMIProductTeam. 2013. OPP. y las descripción del proceso real recaen en las personas y disciplinas de ingeniería: modelado del negocio. PPQA. Grupo de procesos de producto procesos específicos para su aplicación en estos ejecución Cierre de iteración entornos. QPM. monitoreo y control. Grupo de procesos de Liberación del seguimiento y control En el PMBOK se definen 47 procesos de dirección de producto proyectos. Ÿ Gestión de Proyectos: REQM. ISSN: 1692-343X. cierre de Las áreas del conocimiento de PMBOK están iteración. De esas CMMI se definieron como complemento a los ocho áreas de proceso. De ahí la necesidad de establecer una metodología que recopile esas buenas prácticas tanto empíricas En la Tabla 1 se muestra cómo integrar DAC con el como definidas y las concentre en un modelo. gestión de agrupan en procesos de acuerdos. aseguramiento de la calidad de procesos y proyecto-activación organizacional. pruebas. cierre 2013).

1 se puede ver el modelo del proceso DAC VER Pruebas de calificación del software y en la Fig. Entre las fases de Desarrollo de Validación del software Requisitos. realizar con estos la Fig. en la que habrá obligatoriamente un incremento del producto a partir Tabla 2 Integración de ISO/IEC 12207 y CMMI de la solución de un componente del mismo. DAC plantea que el problema una vez identificado y definido debe ser descompuesto en problemas más pequeños. 2 los componentes del modelo más Verificación del software VAL Pruebas de calificación del software detallados. recursivo-iterativo. Entre el Inicio y Cierre del proyecto se Soporte de aceptación del software realizan iteraciones por entregas de versiones del Mantenimiento del software producto. Quid N° 21. Su modelo del proceso es una adaptación del modelo en cascada a los modelos programación extrema y desarrollo concurrente. pp. Además.2. 2. soporte y las disciplinas de ingeniería el software o producto final. jul . El modelo DAC Fig. 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 3. Cada sub-problema será resuelto definieron dentro de los procesos de gestión de mediante un componente y el problema resuelto será proyecto. ISSN: 1692-343X. Está enfocado a proyectos pequeños o proyectos grandes divididos en sub-proyectos que desarrollan software de gestión basado en componentes. Construcción del Producto y Cierre de REQM Definición de requisitos de los involucrados Iteración ocurren iteraciones concurrentes a nivel de PP Planificación del proyecto PMC Evaluación y control del proyecto componentes. incremental y guiado por procesos y requisitos. incorporando elementos de los modelos incremental y evolutivo en cada iteración. 13-24. entre las fases de Desarrollo SAM Adquisición de Requisitos y Construcción del Producto puede Proceso de oferta ocurrir un ciclo pues a medida que los requisitos son IPM Gestión de la Información descritos estos pueden ir entrando a la fase de Gestión del Modelo del Ciclo de Vida Construcción del Producto.dic. 1. por lo que las entregas como se muestra en la tabla 2. Componentes del modelo DAC 17 . TS Instalación del software Implementación del software Diseño arquitectónico del software Al finalizar cada iteración se realiza la integración Diseño detallado del software del componente al producto obtenido hasta el Construcción del software momento realizando pruebas de integración. y si es necesario. PI Instalación del software Integración del software En la Fig. Medellín-Colombia De igual forma los procesos de la ISO/IEC 12207 se misma operación. en DAC son a nivel de iteración. Modelo del proceso DAC La metodología DAC es un proceso de desarrollo colaborativo. 2013. Además en cada iteración se define como mínimo un hito a CMMI 1 ISO/IEC 12207 cumplir por cada fase. Las Ingeniería de dominio Gestión de reutilización de software iteraciones no tienen que desarrollarse todas al Gestión de reutilización de activos mismo tiempo sino que depende del plan del RD Análisis de requisitos del software proyecto.

dic. DEFINIENDO LAS PRÁCTICAS realizando durante el mantenimiento de la primera versión nuevas iteraciones para desarrollar las La aplicación de los valores y principios del siguientes versiones del software. Quid N° 21. brinda control. jul . correctamente los patrones arquitectónicos y de Ÿ El cambio es bienvenido pero controlado. iteraciones por versiones de componentes. pp. 13-24. iteraciones por versiones del producto e Ÿ Evitar a toda costa tener documentación repetida. en este caso versiones del producto. diseño definidos. Anderson. programadores. Feature Driven ella. mientras que la reunión de chequeo y aplicar en DAC: análisis de resultados. 2001) se retoma la idea de realizar un desarrollo. DAC toma elementos de estas iniciales de cada versión del producto se define metodologías. No entrega temprana y continua de software de valor son necesarios si en la implementación se aplican que cumpla con los atributos de calidad definidos. aunque en las fases industria del Software. proyecto explotar las bondades de las nuevas Ÿ Integración continua de cada componente del tecnologías y la red. conformidades futuras en revisiones de calidad Ÿ Los involucrados relevantes. No obstante se declara como software una vez sea liberado por el grupo de la forma más efectiva de comunicación la aseguramiento y control de la calidad. Schwaber & Beedle. se aprovecha para que el equipo reflexione sobre la Ÿ Revisión de las iteraciones con el equipo de forma de ser más efectivo y ajustar su conducta en proyecto. Esta mejorar la comunicación y la resolución de metodología tiene buenas prácticas que se pueden problemas.. S c r u m . Ÿ Diseño simple. Se propone manifiesto ágil (Beck et al. Se incluye como parte del diseño el mapa de navegación y el modelo de datos. abarcando únicamente el modelado del sistema mediante diagramas de Basada en los principios y valores del manifiesto ágil paquetes o componentes solo hasta el nivel de (Beck et al. en intervalos regulares. largas como se determine en la planificación con Ÿ La planeación colaborativa. prevalecen cada vez más en la Ÿ Desarrollo evolutivo. Medellín-Colombia 4. deben estar en constante Ÿ La refactorización del código antes de las pruebas comunicación y realizar reuniones de chequeo finales contribuyen a la calidad del software del avance del proyecto de forma frecuente. conversación cara a cara. DAC también asume todos los valores de Scrum Ÿ La reunión diaria es una técnica eficaz para (Palacio. Ÿ Desarrollo incremental obteniendo en cada Las metodologías ágiles de desarrollo de software iteración al menos un componente del software c o m o X P. número de no conformidades encontradas paquetes lógicos a partir del estudio del negocio o en evaluaciones de calidad del proceso y productos los requisitos de alto nivel. En DAC hay dos tipos de iteraciones: no quita agilidad. pruebas de unidad desde el nivel de funcionalidad Los cambios no pueden comprometer el éxito y la hasta el nivel de módulos para evitar no calidad del proyecto. compartir y socializar el conocimiento partiendo 18 . dejando siempre constancia de las solicitudes Ÿ La producción del código está dirigida por realizadas y las decisiones a tomar al respecto. tanto externos del producto. ISSN: 1692-343X. iterativa y detallada el cliente. 2001) así como prácticas además retomar la idea de las siguientes prácticas XP ágiles para la gestión de proyectos mejoran adaptadas al concepto de DAC: considerablemente los resultados de calidad del proyecto medidos en: indicadores de ejecución del Ÿ El uso de la metáfora mediante diagramas de proyecto. 2002). Development) y otras. Jeffries. 2004. una arquitectura y diseño de alto nivel. esta se va actualizando y mejorando durante las iteraciones. DAC pone especial énfasis a plan de entregas. satisfacción del cliente. 2013. disminuyendo la ocurrencia de no Ÿ Es vital para la gestión de la comunicación en el conformidades. como internos. Ÿ Estándares de programación para fomentar la Ÿ Construir el proyecto con individuos capacitados reutilización del código y la comunicación entre en todo momento garantiza la mitad del éxito. p r o c e s o g u i a d o p o r pudiendo ser este una entrega pactada o parte de funcionalidades (FDD. y Ÿ Colaboración entre los miembros del equipo de Hendrickson.. No Ÿ Es prioridad para el proyecto satisfacer los se realizan en DAC diagramas de clases o tarjetas acuerdos tomados con el cliente a través de la clase-responsabilidad-colaboración (CRC). Ÿ La atención continua a la excelencia técnica enaltece la agilidad y determina la calidad. De XP (Beck y Andres. de trabajo. 2001) DAC defiende lo siguiente: funcionalidad. Las iteraciones en DAC pueden ser tan consecuencia.

Ÿ Colocalización de miembros del equipo. el desarrollo de un modelo en áreas Ÿ Socialización del conocimiento. Calidad de los productos de trabajo: En Letelier (2013) se presenta una lista creada por Ÿ Definir la arquitectura de alto nivel al inicio de este autor de 42 prácticas ágiles “a modo de carta de cada versión. reunión de metodología de la manera más eficiente y en el análisis de resultados (máximo cada 30 días). asociado a elaborarla (en DAC es utilizar cada Ÿ DAC define varios tipos de reuniones: reunión de uno de los productos de trabajo definidos en la inicio de una iteración. que se Uniendo todo lo anteriormente expuesto junto a un corresponde con la metáfora de XP. que sea rentable el aprovechamiento uso de repositorios de activos de productos y de la documentación respecto del esfuerzo componentes. ISSN: 1692-343X. todo el Calidad en los procesos: equipo trabajando en el mismo espacio físico (con el uso de las tecnologías de la información y Ÿ Documentar. sin Ÿ Integración continua. especificación y validación en las distintas fases. La mayoría de estas Ÿ Refactorización de código. Ÿ Comunicación mediante las redes e internet y cara a cara siempre que sea posible. De estos modelos salen las Ÿ Colaboración constante. refinamiento. propuestas de componentes en distintos niveles de Ÿ 40 horas semanales. prácticas se aplican en DAC de forma íntegra. 2013. firmar y satisfacer los acuerdos con comunicaciones esto no es necesario. la promoción de una estrategia de implantación que Ÿ Arquitectura y diseño basados en componentes y apuesta por combinar prácticas cogidas desde patrones. siempre). Ÿ Seguir los procesos definidos. momento que corresponda). el retrabajo (mientras sea posible evitar el retrabajo y si ocurre debe analizarse. Entre estas: Ÿ Pruebas en cada iteración y versión (pruebas funcionales. miembro en su rol). restaurante para que cada equipo configure su propio Ÿ Planificación conjunta entre cliente y equipo de menú”. Ÿ Realizar las reuniones necesarias planificadas. Además. técnicas (a veces un equipo que se autoorganiza Ÿ Revisar y gestionar inconsistencias entre los tiende a acomodarse y no planificar de la manera productos de trabajo. pero solo lo estrictamente comunidad de desarrollo. Ÿ Controlar y firmar las solicitudes de cambio. priorizarse e Por otra parte. adaptaciones. análisis. y un modelo global. agrupamiento de los requisitos del cliente o de alto nivel. de integración. explica que “Este enfoque conlleva proyecto. organizado se puede dividir un equipo grande en Ÿ Desarrollo evolutivo-incremental. los documentos. Medellín-Colombia del hecho de que un equipo de proyecto es una Ÿ Documentar. También se propone el necesario. empaquetamiento y de cada componente las iteraciones necesarias para desarrollarlos. pequeños grupos de desarrollo). Estos requisitos se traducen en objetivos del Calidad en la gestión de los recursos humanos: proyecto. Ÿ Evaluar la calidad de cada entregable. embargo otras deben aplicarse haciendo algunas Ÿ Estándar de código. Quid N° 21. jul . 19 . pp. más eficiente). importancia a la especialización de cada Ÿ Adaptar los procesos definidos. al menos no involucrados y compromisos con el plan. 13-24. También se incluyen actividades como el estudio de Ÿ Capacitación constante del equipo. no funcionales. reunión diaria. Ÿ El equipo se autoorganiza y toma las decisiones Ÿ Gestionar líneas base. que guiarán el proceso de desarrollo mediante su desglose. DAC indica que conjunto de buenas prácticas generales en el debe establecerse una arquitectura base para poder desarrollo de software a continuación se resumen las iniciar el desarrollo a partir de la priorización y prácticas de DAC. reunión de chequeo de acuerdos con Ÿ Establecer pautas para gestionar convenientemente involucrados. diferentes métodos ágiles”. de la metodología FDD (Palmer & incorporarse a la planificación).dic. Ÿ Formar equipos pequeños (si el trabajo está aceptación alfa y beta). Ÿ Que los integrantes del equipo no tengan solo Ÿ Planificar y ejecutar el aseguramiento de la algunas actividades fijas asignadas (es ideal un calidad del proceso y del producto. 2001) se retoma en DAC la idea del desarrollo de un modelo inicial de alto nivel. reunión de cierre de iteración. equipo así pero en DAC se le da mucha Ÿ Planificar guiado por entregas y requisitos. Felsing.

recopilar y analizar los resultados con frecuencia como parte de los procesos de apoyo de la A continuación se mostrarán los resultados del metodología. Medellín-Colombia Ÿ Analizar los resultados. 3. respecto a la revisión anterior. Como trabajo futuro se prevé validar la propuesta por En el caso de las no conformidades. pp. comenzando por el propio hecho de las áreas de procesos del nivel dos de CMMI. En el caso de los todos los indicadores previstos como parte del diseño indicadores de ejecución. Trabajos futuros de la metodología en la muestra seleccionada. Quid N° 21. productos por la empresa CALISOFT. líneas base. Ÿ Debe existir un administrador de la calidad y la configuración. ISSN: 1692-343X. Ÿ Elaborar productos de trabajo simples que cumplan con su propósito de uso. Ÿ Documentar los procesos y sus guías. jul . En la post-prueba el porcentaje de no conformidades de adherencia a Ÿ Índice de no conformidades de adherencia a procesos y productos disminuyó en un 83. VALIDACIÓN DE LA PROPUESTA La metodología fue aplicada durante un año en el Departamento de Desarrollo de la Dirección de Fig. experimento teniendo en cuenta las siguientes variables: El intercambio con los miembros del proyecto fue fundamental. Posterior a la implementación de la metodología tres de los Ÿ Índice de rendimiento de la eficacia (IREF). liberaciones de Ÿ Índice de rendimiento de la ejecución (IRE). auditorías a la configuración y pruebas de software en los distintos niveles.1. a mayor porcentaje mejor de la investigación (Tabla 3). proyectos lograron una liberación de la primera versión de los productos en desarrollo.34 % con procesos y productos (NC 1). En la Fig. Los proyectos seleccionados habían sido abortados Ÿ Índice de rendimiento de los recursos humanos con anterioridad en sus intenciones de liberación de (IRRH). Ÿ Índice de rendimiento de la planificación (IRP). Cada entrega de software estuvo precedida de revisiones de calidad. Además los indicadores relevantes mejoraron obteniendo buenas Ÿ Índice de no conformidades en pruebas de evaluaciones superiores al 85 % en todos los software (NC 2). resultado. Resultados del experimento Informatización de la Universidad de las Ciencias Informáticas en 6 proyectos de desarrollo. frecuencias cortas. Ÿ Monitorear los procesos. Se realizaron entrevistas en grupo a los Recopiladas en informes de resultados de calidad: miembros de cada proyecto. Ÿ Firmar actas de aceptación de los entregables. 13-24. 5.dic. 20 . a mayor el criterio de expertos así como medir y analizar porcentaje peor el resultado. Se aplicó Evidentemente hubo un cambio en los resultados de una configuración de la metodología incorporando los proyectos. indicadores. Recopiladas en informes de estado de ejecución del La adherencia a los procesos definidos en DAC proyecto: propició planificar por entregas los proyectos y proveer a los clientes versiones del software en Ÿ Índice de ejecución del proyecto (IE). 3 se muestran los resultados promedios de calidad y ejecución antes y después de la aplicación 5. 2013.

en revisiones y Grado de cobertura de procesos auditorías Grado de cobertura de productos Adherencia a procesos Al aplicar la metodología en seis proyectos de Adherencia a productos desarrollo reales se puede decir que propicia mayor Calidad del producto Cantidad de no conformidades por organización y control en los proyectos. 2013. Medellín-Colombia Tabla 3 Dimensiones e indicadores para analizar 6. El análisis Calidad de la versión Cantidad de errores en producción de resultados y la retrospectiva permite al equipo de del producto en Cantidad de usuarios afectados explotación proyecto mejorar de manera continua. por errores en producción Nivel de aceptación del Aceptación del Se debe aún validar la metodología mediante el producto producto por el cliente criterio de expertos y aplicándola en un entorno Nivel de cumplimiento de empresarial para probar su efectividad en este sector. Paper presented at the Agile Conference. Aplicabilidad en el propuestas de productos de trabajo.dic. Favorece la de acuerdo a pruebas criticidad documentación y tratamiento oportuno de los de software formales Cantidad de no conformidades por cambios solicitados y las acciones correctivas y tipo preventivas ante la ocurrencia de riesgos. 13-24. Calidad de la Capacidad de aplicación en el metodología desarrollo de software de gestión Cubrimiento de las características La metodología DAC constituye una alternativa al definidas (Características propias desarrollo de software siguiendo un enfoque de la metodología declaradas) tradicional para la aplicación de modelos y Adaptabilidad estándares internacionales como PMBOK. (2005). definición temprana Capacidad de aplicación en el y ejecución constante del plan de pruebas teniendo en desarrollo basado en componentes cuenta distintos niveles. como fuente principal de conocimiento. pp. Existencia de una guía de actividades y tareas Un proyecto que implemente DAC puede planificar Definición de roles que intervienen las entregas a nivel de versiones del producto Definición de productos de desarrollando de manera ágil y concurrente. Stretching agile to fit CMMI level 3 . El uso trabajos generados de los principios y prácticas de esta metodología Nivel de aceptación guían al proyecto en la obtención de un producto con Cantidad de no conformidades por calidad y la satisfacción del cliente en etapas Calidad del proceso impacto tempranas. 2005. 21 . ISO y Capacidad de generalización CMMI. en el proyecto La metodología DAC define actividades en su ciclo Cubrimiento del enfoque ágil de vida que contribuyen a un enfoque de calidad Cubrimiento del modelo CMMI obteniendo las evidencias necesarias a través de Cubrimiento de estándares de gestión de proyectos productos de trabajo sencillos como son las Cubrimiento de estándares de revisiones de calidad para la liberación de las líneas calidad bases en cada fase del proyecto.the story of creating MSF for CMMI reg. CONCLUSIONES Dimensión Indicador La metodología Desarrollo Ágil (DAC) con Calidad Estado del proyecto provee a la entidad desarrolladora un conjunto de Estado del proceso en el proyecto procesos documentados. process improvement at Microsoft corporation. acuerdos y cronogramas Aceptación del Nivel de aceptación del producto REFERENCIAS producto por el usuario Nivel de uso del producto Anderson. ISSN: 1692-343X. D. J. Quid N° 21. jul . Los procesos de apoyo de DAC pueden ser Existencia de elementos configurados y adaptados por la entidad desarrolladora para adaptarse a un modelo estándar conceptuales deseado. paquete de proyecto Estado del equipo de proyecto productos de trabajo reutilizables y guías de Estado del producto desarrollado adaptación. Proceedings. con sus guías de aplicación. auditorías a la configuración y líneas de producto y establecimiento de estándares.

the “vs. Lima. North-West University. B. IEEE. Software. The Development of a Hybrid Agile Project Management Methodology. 13(15). C. Nueva versión del PMBOK – Edición 2013. S.. M. J. Information-Software life cycle processes (Vol. Universidad Politécnica de Madrid. jul . Pennsylvania: Navarro. Paulk..agilemanifesto. Meléndez De La Cruz. Manifiesto Ágil.blogspot. (2010)... Comparing PMBOK and Agile M a n a g e m e n t Te c h n i q u e s f o r a n S M E Project Management software development Environment. Madrid. M. Disponible en: Netherlands. New York: The Institute J.net/files/s/NST-010_01. Fowler. IEEE. 2006. www. International Journal of Arts and processes. Agile vs CMMI: Reasons why Addison-Wesley/Pearson Education. ISSN: 1692-343X. Agile Project Management for IT Projects in SMEs: A Fernández Díaz. A. 13-24. (2001.org. Balancing agility and discipline: A guide for the perplexed: Matalonga. & Sankaran. y Turner. Maturity Profile Report (pp. recuperado de: of Electrical and Electronics Engineers. ( 2 0 1 0 ) . G. A. (2001). REICIS Revista Española de Innovación. Estudio sobre la Framework and Success Factors. . .. (2013). recuperado de: Calidad e Ingeniería del Software. & Garzás.com/pdf/V1_The_Agile _Project_Manager.. Palmer. 19-26. R e c u p e r a d o d e : http://agilismoatwork. Anderson. Dalton. 6-15. Sobh (Ed. prácticas ágiles y su aplicación en Pyme. (2012).. S. M.es Boehm. J. CMMI y métodos ágiles en Wesley.2 en una micropyme con metodologías ágiles y software Cottmeyer.. A. & Calderón Valverde. 378-383): Springer Palacio. & Capgemini. R. propio menú ágil.. C. C . C M M I P r o d u c t Te a m . (2010). Ayer Sogeti. J. (Tesis de Grado) Letelier..). S. The Agile Project Manager libre.edu/library/abstracts/report s/08tn003. & Hendrickson. ISO/IEC 12207: 2008). Pennsylvania: Carnegie Mellon University. M.pdf O'Sheedy.com. & IEC. de maestría). O'Sheedy. CMMI or Agile: Why Not guide to feature-driven development: Pearson Embrace Both? recuperado de: Education.3. & S. (2010). Computer and Information Sciences and Engineering (pp.versionone. (2001). R. Sutherland. D. ISO. (2008). S. (2013). P. P. y A n d r e s ..sei. (2011).. (2008). la implantación de CMMI-DEV v1. Addison Wesley. 3(7). 18(6).dic. D. . J. L.cmu. Anderson. (2001).cfm. Y. In T. & Sankaran. (pp. Konrad. J. http://navegapolis. Quid N° 21. (Tesis 3(3). Retrieved 2014. 13). Inc. K .. W. El modelo Scrum. The correspondencia entre prácticas CMMI y International Technology Management Review.. Potchefstroom Campus. Advances in Sciences. (2014). Beedle... World programming explained: embrace change Quality Report. Medellín-Colombia B e c k . CMMI Institute.” is sticking for the time being.. 13) Lima. & Felsing. . 2013. Experiencia en Carnegie Mellon University. H. C M M I ® f o r Development. Bernal Cam. M. Standard for Beck. (2003). marzo). Xu.. Cockburn. C. Agile Product and Project Management. K. R. Van Bennekum.). F. Extreme programming from a CMM perspective. pp. D. Cunningham. M. Extreme programming installed: Addison Aplicación de BPM. Preliminary Results of a Study of Agile Project Fitsilis. (Version 1. Agilismo at work. 187-195. el desarrollo de software para empresas de producción y exportación. 278-291. (2009). http://www. E x t re m e HP. Carta de Prácticas Ágiles: Arma tu Universidad Peruana de Ciencias Aplicadas. (2013). http://www. M. (2012). Jeffries.. (2008).pdf Glazer. A practical Shrum. J. J. Grey. ( 2 0 0 4 ) . 22 . 16(1). (2013).

. S. (2008). A Guide to the Project Management Body of Knowledge.. M. M. I. Sliger. Paper presented at the Proceedings of the 41st Hawaii International Conference on System Sciences. & Mäntyniemi.. & Beedle. ISSN: 1692-343X. & Ruseng.com web site. The Standish Group International.Kent.. Proc. Rally Software Development Corporation. (2006b). 23 . Quid N° 21.dic. (2013). K. The CHAOS Manifesto. Retrieved from StickyMinds. PMI Global Congr. J. (2003). 13-24. C. Scrum and CMMI Level 5: The Magic Potion for Code Warriors. Inst. 48). Relating PMBoK Practices to Agile Practices. Project Manage. M. jul . & Koppensteiner. Sliger. Will Agile Development Change The Way We Manage Software Projects? Agile From a PMBOK® Guide Perspective. A project manager's survival guide to going agile. (2013). Johnson. gilè Software Development with Scrum. Sutherland. (2002). (2006). Hawaii. Udo. 2013. M. Act Small (pp. 22-23.. Pennsylvania: Project Management Institute. Medellín-Colombia Pikkarainen. pp. Paper presented at the Proceeeding of the 2006 SPICE Conference. PMI.. Schwaber. N. An Approach for Using CMMI in Agile Software Development: Experiences from three case studie. Think Big. (2006a). A.