Instalar Subversion en Dropbox

Dado que no es precisamente económico para un particular dispuesto a hacer sus pequeños proyectos personales de software desde diferentes localizaciones disponer de un servidor equipado con un sistema de control de versiones mediante el cual pueda mantener alineadas todas las versiones del mismo proyecto en todos los dispositivos desde los que trabaje, muestro aquí en unos simples pasos cómo montar un sistema de gestión de versiones online gratuito gracias a la combinación Subversion + Dropbox:

  1. Instalar Dropbox y abrir cuenta si no se dispone ya de una.
  2. Instalar TortoiseSVN.
  3. Crear carpeta ‘svn’ dentro de la carpeta ‘Dropbox’ instalada en nuestro PC.
  4. Hacer click derecho sobre la carpeta ‘svn’ y seleccionar TortoiseSVN > Create repository here.
  5. Elegir la opción de ‘Create folder structure’ y después dar ‘OK’. Con esto hemos creado el repositorio.
  6. Para sincronizar nuestros proyectos con el repositorio: sobre la carpeta en la que almacenemos nuestros proyectos hacemos click derecho y seleccionamos TortoiseSVN > Import.
  7. Ponemos como URL del repositorio la dirección de la carpeta ‘svn’ creada en el paso 3. (Ejemplo: file:///D:/Dropbox/svn)
  8. Aceptamos y comprobamos cómo se suben los ficheros del proyecto al repositorio.
  9. Sobre la carpeta de nuestros proyectos, hacemos click derecho y elegimos ‘SVN Checkout…’
  10. En ‘URL of repository’ ponemos la misma del paso 7 y en ‘Checkout directory’ la carpeta de nuestros proyectos, quitando el ‘/svn’ que añadirá por defecto al final de la URL y pulsamos ‘OK’.
  11. Ya tenemos lista la carpeta de nuestros proyectos para hacer Commits y Updates haciendo click derecho sobre ella. :)

Si trabajamos con un IDE de desarrollo que incorpora plugins para Subversion no es necesario sincronizar manualmente la carpeta de nuestros proyecto (pasos 6 a 11), sino que sería suficiente con indicar en la configuración del plugin la dirección del repositorio (carpeta ‘svn’ de ‘Dropbox’).

Por cada uno de los PCs en los que vayamos a trabajar, habrá que repetir los pasos 1, 2, 9 y 10. Los demás pasos son sólo para el primer ordenador.

Share

Qué debe saber un Ingeniero en Informática

La ingeniería en informática es una disciplina tremendamente extensa, con multitud de campos de aplicación. Es muy difícil ser experto en varios de estos campos a la vez. Resultaría complicado encontrar, por poner un ejemplo, un profesional que conociese los secretos de la Inteligencia Artificial y al mismo tiempo fuese un gurú del modelado de sistemas en UML dominando a la par los arcanos de los Autómatas Programables: se dice que quien mucho abarca poco aprieta y eso es perfectamente aplicable a nuestra profesión.

Sin embargo la especialización, siendo importante, no lo es todo. La tendencia actual en el desarrollo de software a la formación de equipos multidisciplinares para el soporte de las metodologías ágiles y la reducción de costes en las organizaciones obliga a que los Ingenieros en Informática, si quieren mantenerse competitivos, sean capaces de manejarse al menos de forma aceptable en los siguientes campos:

  • Programación de aplicaciones de escritorio: conocer al menos .NET bajo Visual Studio y Java en Eclipse, siendo bastante competente en al menos uno de ellos.
  • Programación web: HTML es obligatorio y por lo menos se deben tener unas nociones básicas de CSS y JavaScript. Además, tienes que ser capaz de hacer aplicaciones simples en ASP.NET, Java EE y PHP, siendo bastante competente en al menos una de ellas. Aquí cobra además especial importancia la seguridad.
  • Ingeniería de Requisitos: Recogida y gestión de los requisitos. Normas básicas de elaboración de una buena especificación.
  • Análisis y Diseño de sistemas de software: Hay varios lenguajes de modelado importantes, pero el dominio de UML es obligatorio, al menos en un grado avanzado. Hoy en día hay que tener nociones además de Desarrollo Dirigido por Modelos. Conocimientos de algoritmia y estructuras de datos son igualmente básicos tanto para el diseño como para la programación.
  • Pruebas: unitarias, de integración, funcionales y de aceptación.
  • Bases de Datos: el diseño de bases de datos es esencial, la normalización bastante deseable. El conocimiento de al menos un lenguaje de acceso a bases de datos (SQL principalmente) es obligatorio. No se pueden olvidar los servicios web para el encapsulamiento del acceso y modificación de los datos.
  • Gestión de Proyectos:
    • Definición, Descomposición y Planificación de Proyectos. Técnicas de estimación de tareas.
    • Seguimiento de proyectos.
    • Control de versiones.
    • Gestión de riesgos, cambios e incidencias.
    • Gestión de expectativas de los implicados y de la comunicación entre ellos.
    • Nociones al menos básicas sobre presupuestos y contratos.
    • Dominio de herramientas como Microsoft Project.
  • Estándares, metodologías y modelos de calidad: CMMI, ISO 9001, RUP, 6 Sigma, Scrum, XP, etc. Algunos son metodologías de desarrollo, otros modelos de mejora de procesos, pero en cualquier caso haber oído hablar de ellos nunca está de más.

No creo que éstos que he mencionado tengan que ser campos que un junior deba conocer a fondo desde un principio para ejercer su profesión, pero sí creo que todo ingeniero debería trazar su propio plan de formación a corto y medio plazo de manera que se garantizase a sí mismo conocimientos en éstas y otras áreas de las que probablemente me haya olvidado y que resulten igualmente importantes. La Universidad pone las bases, pero el desarrollo formativo posterior es responsabilidad exclusiva de cada uno.

PD: Una primera crítica que se me ocurre a mi propia lista es que está posiblemente muy enfocada al desarrollo de software y deja de lado campos en los que ejercen gran número de ingenieros como son las Redes, la Optimización y el Control industrial o la electrónica de circuitos, entre otras.

Share

Estudios de balística en el software

En los viejos cuentos y leyendas europeos se decía que una bala de plata es el único instrumento capaz de acabar exitosamente con un hombre lobo. Del mismo modo, en la ingeniería del software se habla de bala de plata cuando se consigue una metodología de desarrollo capaz de ser aplicada con éxito en todo tipo de proyectos. El problema en ambos casos es que la leyenda no se cumple. En el primero porque los hombres lobo son sólo eso: materia de cuentos. En el segundo porque las metodologías infalibles son aún más legendarias que los licántropos.

En realidad no es que no existan buenas metodologías en el desarrollo de software, sino que cada metodología es aplicable a un contexto determinado. De hecho incluso dentro de una misma organización la metodología tomada como referencia debe ser evaluada y en su caso adaptada para cada proyecto concreto, en función de características diversas como son el número y la experiencia de los participantes, la relación con el cliente, los plazos, etcétera.

En resumen, hay que evitar ser un talibán de la metodología. La definición de los procesos de desarrollo en una organización debe ser configurable para cada proyecto, de forma que no se pierda el foco de lo realmente necesario para el éxito del mismo. Eso sí, los procesos resultantes de la adaptación no deben desviarse de los mínimos criterios de calidad impuestos por la organización. Se trata de modificar el cómo cumplir con los objetivos, no los objetivos en sí.

Share

Institucionalizando el nivel 2 de CMMI en el Departamento de I+D de una PYME

Por su interés enlazo el vídeo de la ponencia que realizamos en la Universidad Carlos III dentro del ITGSM 2011 el pasado junio sobre nuestra propia experiencia implementando el nivel 2 de CMMI en el Departamento de I+D de Answare Technologies.

En él explicamos los principales desafíos que supuso la adaptación de las diversas áreas de proceso de CMMI al modelo de negocio del I+D+i, así como las pautas que a nosotros mejor nos funcionaron para implantar exitosamente las prácticas en la organización.

La ponencia surgió a raíz del interés de la organización del congreso en difundir el contenido del artículo -del mismo nombre que la ponencia- que se puede encontrar en este enlace.

Share

Gestión de imprevistos

Cuando nos encontramos a tope de trabajo, con varios proyectos encima de la mesa y multitud de tareas por ser completadas, suele ser el momento propicio para que aparezcan los imprevistos, popularmente conocidos como marrones. Los imprevistos pueden llegar desde varias direcciones, y sólo son verdaderos marrones si su resolución es urgente y obligatoria, más incluso que el resto de los proyectos: un cliente solicitando un favor al que no nos podemos negar, un jefe que desvía sus tareas aguas abajo, un compañero que cae enfermo… Los imprevistos en algunos casos son síntoma de una planificación poco cuidada, pero en otros, como su propio nombre indica, eran prácticamente imposibles de prever.

Ante un imprevisto, un equipo de desarrollo cuenta con cuatro alternativas, que enumeraré en orden desde la más deseable hasta la que debe ser tomada como último recurso.

  1. Elegir a una persona con la formación adecuada que pueda retrasar sus tareas sin impactar en la fecha de entrega. Esta opción es la más deseable porque las tareas que la persona está realizando se encuentran fuera del camino crítico, y por lo tanto su retraso, dentro de un límite -concretamente la holgura de sus tareas asignadas-, no impacta en el trabajo de los compañeros ni en las fechas de entrega.
  2. Retrasar la fecha de entrega. Si no se dispone de recursos para afrontar las tareas que son desviadas por el marrón, y estas tareas ya se encontraban ajustadas de fechas, lo primero que se nos pasa por la cabeza es retrasar el hito. En este caso, por razones obvias, más nos vale disponer de un buen negociador en el equipo para interceder ante el cliente.
  3. Disminuir el alcance del proyecto. Si bueno debe ser el negociador que retrase la fecha de entrega, mejor debe ser el negociador que recorte los objetivos del proyecto. Cuando las tareas asignadas no pueden resolverse en tiempo, es evidente que determinadas funcionalidades y características del producto han de verse recortadas. Una disminución del alcance reducirá con total probabilidad el valor percibido por el cliente y por lo tanto una rebaja en el precio final será prácticamente obligatoria.
  4. Hacer horas extra. En el caso de que las horas extra estén bien pagadas y el equipo esté motivado, es muy posible que ésta no sea ni mucho menos la opción menos deseada para afrontar el imprevisto, pero también es cierto que este caso ideal no siempre se da y que por lo tanto el exigir un esfuerzo adicional del equipo para cumplir con el imprevisto y con el resto de tareas a tiempo y dentro de los objetivos marcados, va a exigir grandes dosis de mano izquierda y motivación por parte de los responsables de la organización.

En realidad el afrontar imprevistos es muy común en el mundo del desarrollo de software, y rara vez no se resuelven recurriendo al uso de horas extra. Que esos esfuerzos extraordinarios sean ocasionales entra dentro de lo perfectamente normal. El problema viene cuando se convierten en una práctica habitual.

Share

Gestión básica de requisitos

A partir de las nociones que he adquirido a lo largo de la carrera y los primeros años de trabajo sobre Gestión de Requisitos de software, y empleando el marco que proporciona CMMI -concretamente el área de proceso REQM- para la realización a un nivel básico de este proceso vital en el ciclo de desarrollo, dejo aquí unas notas sobre cómo realizar la gestión de requisitos de modo que se cumplan unos criterios mínimos de calidad:

1º Entender los requisitos: Plántate delante de cada requisito como si fuera uno de aquellos problemas de física del colegio. Siéntate, ponte a estudiarlo, consulta otros documentos, pide ayuda, especialmente a la persona que lo detectó y/o lo propuso, y no lo des por cerrado hasta que no estés absolutamente seguro -y otra persona así lo haya verificado- de que el requisito está entendido y de que están claras las razones por las que lo aceptas o lo rechazas.

2º Obtener el compromiso con los requisitos: Sabiendo como sabemos que los requisitos son un entorno cambiante, siempre hay que tener bien claro cómo nos impacta la incorporación de un cambio o la agregación de un nuevo requisito. Documenta los cambios que van surgiendo: que quede bien claro quién propone los cambios, quién los acepta, quién los desarrolla, quién los prueba y cómo queda el proyecto antes y después del cambio. Un requisito no debe incorporarse hasta que no haya sido mínimamente negociado.

3º Gestionar los cambios en los requisitos: Mantente abierto a los cambios, porque los cambios no son un marrón, sino que son propuestas que añaden valor al producto desde el punto de vista del cliente. Esto no significa que debas aceptar cualquier cambio, especialmente sin evaluar antes su impacto en colaboración con la fuente del propio cambio y con el equipo de desarrollo. Simplemente se trata de enfocar los cambios en los requisitos como un proceso de mejora continua del producto. Asesórate a la hora de estimar su impacto, no solo con el juicio de expertos sino sobre todo echa mano de experiencias pasadas con incidencias similares. Ah, y algo muy importante: guarda la historia de los cambios, versionando los requisitos para que se pueda ver cómo ha evolucionado cada uno a lo largo del proyecto.

4º Mantener la trazabilidad bidireccional de los requisitos: Es conveniente saber en cada momento de dónde viene y adónde va cada requisito. Los requisitos técnicos, esos que metes en fichas y que lucen un aspecto más o menos estructurado, detallando su importancia, urgencia, etc., deben tener su correspondencia con alguna línea o punto del documento de especificaciones que envía el cliente. Además, conviene que la relación entre los propios requisitos técnicos esté a su vez documentada y que se sepa de dónde vienen los productos de trabajo. Una forma habitual de afrontar todo este lío es mediante la matriz de trazabilidad, pero a mí me parece un tanto confusa y difícil de mantener. Prefiero que este tipo de relaciones vengan detalladas dentro de la ficha de cada requisito, al estilo de lo que propone la herramienta REM. Si consigues tener bien definida y mantener actualizada la trazabilidad, resultará más sencillo saber qué elementos se ven impactados cuando ocurre algún cambio. La trazabilidad se puede llevar a varios niveles, en función de tus necesidades.

5º Asegurar que los productos de trabajo cumplan con los requisitos: Realiza auditorías periódicas que aseguren que lo que se está desarrollando esté de acuerdo con lo que se pedía. A partir de estas auditorías -que no debemos confundir con las pruebas- se deben lanzar acciones correctivas a las inconsistencias detectadas. Lógicamente estas auditorías deben ser realizadas por alguien independiente al desarrollo de los requisitos a evaluar. Vamos, que no vale auditarse a uno mismo.

Si se quiere avanzar más en la gestión de los requisitos existe un área de proceso en CMMI -concretamente la de Requirements Development, del nivel 3- que detalla una serie de prácticas adicionales que completan la gestión en varios aspectos, si bien estos cinco puntos son los que se consideran necesarios y suficientes para adquirir un nivel de madurez aceptable en el tratamiento de los requisitos.

Una guía que me ha parecido muy completa a pesar de su tamaño relativamente reducido es la que proporciona el INTECO, y que se puede ver en el siguiente enlace: [pdf].

Share

¿Por qué los jefes de proyecto ganan más que los programadores?

Estaba preparando un artículo sobre gestión básica de requisitos en los proyectos de software, pero he preferido dar un volantazo y exponer mi punto de vista sobre un asunto que se discute estos días en la red sobre por qué los jefes de proyecto cobran más que los programadores.

Según he podido ver en artículos como éste (bien es cierto que tan solo se trata de una traducción al español de la respuesta dada por un internauta en stackexchange), culpan de este supuestamente injusto hecho ni más ni menos que a nuestra sociedad [sic], aduciendo una visión de la remuneración orientada a la jerarquía y un modelo de gestión poco menos que represor. Como prueba de ello, completan su análisis exponiendo el vocabulario habitual entre los jefes de proyecto: recursos, procesos, eficiencia, control, etc. En contraposición expone el caso de las compañías de software que funcionan de forma análoga a como lo hacen los estudios cinematográficos, en los que cada miembro es remunerado en función del valor que aporta al producto final independientemente de su posición en la jerarquía.

En mi opinión en esta manera de explicar por qué los jefes de proyecto ganan más que los programadores radica un profundo desconocimiento de las leyes del mercado. El hecho de que el trabajo de los programadores sea más complicado o no que el de los jefes de proyecto es aquí completamente irrelevante. El problema radica en la escasez, o lo que es lo mismo, en la ley de la oferta y la demanda. Un jefe de proyecto debe tener una serie de habilidades que, independientemente del valor que aporten al producto final (muy difícil de medir ya que se trata en su mayoría de un trabajo de gestión) y de la complejidad que implica el desarrollo de dichas habilidades, lo cierto es que escasean más que las habilidades aportadas por los programadores.

Con esto no quiero decir que cualquiera pueda programar o que los buenos programadores abunden, nada más lejos de mi intención. Lo que quiero decir es que si cualquiera no puede programar, menos aún puede ser jefe de proyecto. Y si los buenos programadores escasean, más aún escasean los buenos gestores.

Share

El nivel 2 de CMMI

“Y al principio fue el caos…”

Una de las particularidades de CMMI como modelo de procesos para la fabricación de software es que considera perfectamente factible la entrega de productos de acuerdo a las especificaciones originales de los mismos aún a pesar de no cumplir ninguna de las prácticas de calidad que su propio modelo predica. Eso sí, sufriendo al menos dos inconvenientes nada despreciables: por un lado la necesidad de contar con el esfuerzo de los llamados héroes para superar el trámite y por otro, la pérdida de oportunidades por parte de la organización de acumular conocimiento para superar futuras situaciones de riesgo, reforzándose el círculo vicioso que lleva a una empresa de desarrollo de software a ser poco más que la suma de la experiencia de sus miembros en un momento dado, en vez de ostentar un conocimiento propio.

Este estado es el que CMMI reconoce como Nivel 1 de madurez: los productos se entregan y aparentemente funcionan bien, pero acostumbran a sobrepasar las previsiones, si es que había tal cosa, de coste y calendario.

Un primer paso en el camino hacia la madurez, según el modelo CMMI, es trepar hasta el Nivel 2: el nivel Gestionado. Aunque existen consultores y expertos que aseguran que el paso más complejo en la larga carrera de la certificación es el avance del nivel 2 al 3, a mí personalmente me resulta complicado pensar que puede haber algo más difícil para una organización que pasar del caos absoluto a la definición de procesos adecuados para al menos siete áreas del desarrollo: la Gestión de Requisitos, la Planificación, la Monitorización del Proyecto, el Aseguramiento de la Calidad, la Gestión de Configuraciones, la Medición y Análisis y la Gestión de Acuerdos con Proveedores. Ni qué decir tiene que según se va avanzando de nivel, nuevas áreas de proceso surgen con nuevas metas que alcanzar y nuevas prácticas que implementar.

Además, no conviene olvidar que existe una serie de prácticas generales aplicables a cada una de las siete áreas del nivel 2, que son si cabe más importantes que las metas particulares de cada área. A menudo estas prácticas genéricas son despreciadas por los responsables de los procesos en las organizaciones, que las ven como un agregado al modelo sin demasiado que aportar. Craso error. De hecho las prácticas genéricas son la argamasa que junta todas las áreas y da consistencia al proceso.

Share

CMMI para principiantes (y III)

Los niveles de madurez de CMMI

Como comenté en el post anterior, CMMI está representado escalonadamente en 5 niveles de madurez, que califican a las empresas según la calidad de su proceso de producción. Estos niveles, además de por su correspondiente ordinal (del 1 al 5), se conocen por el adjetivo que los describe: Inicial, Gestionado, Definido, Cuantitativamente gestionado y el más alto de todos, Optimizado. Veamos brevísimamente en qué consiste cada uno de ellos.

Nivel 1 (Inicial): La organización no sigue conscientemente las prácticas especificadas en el modelo CMMI, pero de una forma u otra consigue que sus productos salgan al mercado. Supone una gran dependencia de los llamados héroes, profesionales sobresalientes que con su esfuerzo y habilidad personal sacan a la empresa del atolladero. La organización no genera conocimiento y la pérdida de estos héroes supone generalmente la pérdida de la capacidad acumulada.

Nivel 2 (Gestionado): Supone el cumplimiento, por parte de cada proyecto, de varias áreas de proceso de CMMI relacionadas con la gestión de requisitos, la planificación, la monitorización, la gestión de la configuración, el aseguramiento de la calidad, el acuerdo con los proveedores y la medición y análisis de los procesos. Se trata de asegurar que las buenas prácticas se mantengan independientemente de los vaivenes coyunturales que afecten a la organización. El conocimiento reside en la organización.

Nivel 3 (Definido): En este nivel, los procesos ya no sólo se definen de manera independiente para cada proyecto sino que toda la organización goza de unas pautas comunes. Se instaura una serie de procesos que, llevando la explicación al paradigma de la orientación a objetos, suponen la clase sobre la cual se instancian los proyectos. En resumidas cuentas, la empresa goza de una plantilla bien caracterizada que al ser aplicada a cada caso particular, genera un proyecto.

Nivel 4 (Cuantitativamente gestionado): Llegados a este punto, la organización ya no sólo gestiona los proyectos mediante procesos bien definidos, sino que además, se fijan objetivos tangibles que los procesos deben cumplir en lo relativo a su calidad, de manera que se analizan estadísticamente los procesos, propiciando una exactitud y predictibilidad, si se me permite el palabro, de la que no goza el nivel anterior.

Nivel 5 (Optimizado): En el nivel más alto de CMMI, la organización entera experimenta una optimización continua de los procesos a través de la innovación en los mismos y de las mejoras tecnológicas. Se modifican y reconducen los procesos en función de los defectos revelados durante el análisis estadístico.

¿Y cómo se le reconoce oficialmente a una organización su nivel de madurez?

La evaluación, conocida como Appraisal, del grado de madurez de una empresa es llevada a cabo por un equipo que debe estar formado, según el método SCAMPI (Standard CMMI Appraisal Method for Process Improvement), por un evaluador oficial (Lead Appraiser) formado por el SEI y por un conjunto de personas que deben haber recibido el curso de introducción a CMMI y entre las que se puede encontrar, y de hecho es lo habitual, personal de la propia organización. Este enfoque de que gente de la propia organización evalúe el grado de madurez que su empresa merece puede parecer chocante, y con razón. Sin embargo de una forma u otra el complejo método SCAMPI se las apaña para asegurar la objetividad, o al menos eso garantiza el SEI.

Se trata de una prueba exigente, que puede llegar a durar varias semanas, durante las cuales, entre otras cosas, se recogen y analizan las evidencias de cumplimiento de las áreas de proceso a evaluar y se entrevista a los involucrados en la organización. Al finalizar la Appraisal, el evaluador emite un informe que debe ser confirmado en Estados Unidos por nuestros amigos del SEI.

Conclusiones

En resumen, CMMI, y más concretamente CMMI for Development, puede ser en mi opinión un estupendo modelo para la mejora de procesos en una empresa, si es que esta organización se adecúa al modelo, es decir: la organización persigue la mejora real antes que la certificación, está dispuesta a asumir el elevado coste que conlleva la implantación y evaluación y su tamaño y características evitan que CMMI suponga una elevada carga adicional a los proyectos.

<< Ver CMMI para principiantes (II)

Share

CMMI para principiantes (II)

¿Eso de las prácticas, cómo va?

Es sencillo, y a la vez complejo. CMMI-DEV (El CMMI for Development del que hablé el otro día), se divide en áreas de proceso, 22 en total, que a su vez se dividen en metas para cubrir satisfactoriamente el área. Para complicar un poco más el tema, cada meta se compone de varias prácticas específicas, que son las que realmente nos aportan la chicha de lo que hay que cumplir. Por si fuera poco, además de haber una serie de metas y prácticas específicas por cada área, existen metas genéricas, con sus respectivas prácticas genéricas, que deben de cumplirse para todas las áreas. Incomprensible, ¿no? Veámoslo entonces con un ejemplo:

Una de las 22 áreas de proceso es REQM, Requirements Management. La gestión de requisitos, según CMMI, debe cumplir una única meta específica: gestionar los requisitos. De cajón. ¿Y qué es gestionar los requisitos? Eso se explica mediante las cinco prácticas específicas que componen la meta de gestionar requisitos. A saber:

SP1.1 Entender los requisitos: desarrollar un entendimiento sobre el significado de los mismos con sus proveedores.

SP1.2 Acordar los requisitos: obtener el acuerdo de todos los participantes en el proyecto.

SP1.3 Gestionar los cambios de los requisitos: gestionar los cambios mientras los requisitos evolucionan durante el proyecto.

SP1.4 Mantener la trazabilidad bidireccional de los requisitos: mantener la trazabilidad entre los requisitos y los productos de trabajo.

SP1.5 Asegurar la consistencia entre los requisitos y los productos de trabajo: mantener alineados los planes y el trabajo realizado con los requisitos acordados.

Además, la gestión de requisitos debe cumplir una serie de prácticas genéricas que son aplicables de manera transversal a todas las áreas (REQM no iba a ser menos). Éstas son, entre otras: establecer una política organizacional para la gestión de requisitos, diseñar y mantener un plan al respecto, proveer recursos, asignar responsabilidades, etc.

Las otras 21 áreas tienen una estructura similar, si bien pueden constar de más metas. Como se observa en el ejemplo de REQM, el modelo no explica cómo hay que implementar las prácticas, sino simplemente qué es lo que hay que obtener (entendimiento, acuerdo, gestión de cambios, trazabilidad y consistencia).

Pero… yo he leído que CMMI va por niveles, ¡no sabía nada de 22 áreas!

Paciencia. Existen dos representaciones alternativas que permiten trepar por CMMI en la búsqueda constante de la excelencia. Una es la representación continua, que permite seleccionar en cuál o cuáles de las áreas queremos mejorar y centrarnos en las metas y prácticas de ese área independientemente de lo bien que gestionemos las demás. Es una opción útil para organizaciones interesadas en la mejora de determinados aspectos del desarrollo, conscientes de sus debilidades y poco interesadas en la obtención de certificados, o al menos no obsesionadas con ello. Por ejemplo, una empresa puede estar preocupada por cómo se gestionan los requisitos y cómo se realiza la medición y análisis de los datos de sus proyectos y acudir por tanto únicamente a las áreas REQM y MA de CMMI, dejando de lado las 20 restantes.

Sin embargo, la opción más habitual es emplear la representación escalonada, que divide las 22 áreas en 5 niveles de madurez, de tal forma que las organizaciones poco conocedoras de sus propios defectos (la mayoría, para qué negarlo), obtienen una hoja de ruta sobre la que emprender su camino hacia la excelencia. Cada nivel supone cumplir las metas de una serie de áreas de proceso nuevas, y además, seguir cumpliendo las de los niveles anteriores. Una empresa que cumpla las 22 áreas de proceso y además satisfaga todas las metas genéricas, tendrá un nivel de madurez 5, la crème de la crème de CMMI. Sólo hay tres empresas así en toda España, así que nada de lanzarse en tromba a por el máximo nivel.

En el próximo post hablaré más en detalle de estos niveles y de cómo CMMI evalúa el grado de madurez de las organizaciones.

<< Ver CMMI para principiantes (I)

Ver CMMI para principiantes (y III) >>

Share