Evaluación del Software Capability Maturity Model

Introducción

El Capability Maturity Model es un modelo de la madurez de los procesos de una organización, para evaluar las capacidades efectivas de desarrollo que tendrá dicha organización y poder predecir con mayor precisión sus éxitos en futuros desarrollos, mejorando al tiempo los puntos débiles de dichos procesos. Aunque ha sido sustituido recientemente por el Capability Maturity Model Integration, por estar muy extendido y sernos requerido haremos el estudio de nuestra organización respecto al original.

Referencia: apuntes de la asignatura, y wikipedia.


Nivel 1

Objetivos

Los procesos en el nivel 1, el punto de partida, están generalmente indocumentados y son implícitos, o bien no se siguen por parte del personal por desconocimiento u otras razones. Aunque es posible el desarrollo exitoso de proyectos, nada garantiza futuros éxitos.


Nivel 2: repetible

Objetivos

La base del nivel 2 del Software Capability Maturity Model, el cual debemos alcanzar necesariamente como requisito del curso, es que el proceso sea repetible, esto es: que el proceso seguido de creación del producto o proyecto permita generar futuros productos de un modo similar, convirtiendo su resultado en algo repetible y no fruto de la casualidad.

Aunque en el nivel 2 la disciplina de procesos pueda no ser rigurosa, se intenta seguir los procesos existentes siempre, incluso en situaciones de presión (entregas, exámenes, etc).

Es importante reseñar que en este nivel aún hay un importante riesgo de exceder las estimaciones de coste y de tiempo en futuros proyectos, al no existir revisiones de los procesos que los mejoren (y a las estimaciones).

Áreas clave de proceso

Gestión de requisitos
  1. Tenemos requisitos y especificación de lo que queremos, para saber hacia dónde orientamos el desarrollo y el trabajo que queda.
  2. Los planes, productos y actividades se mantienen consistente con esa especificación, aunque nos falta un proceso más definido de revisión (que no se requiere para nivel 2).
Planificación de proyecto
  1. Las estimaciones están documentadas y son reales. Se basan en alcanzar un compromiso entre estimaciones bottom-up (lo que los desarrolladores estiman que van a poder hacer, dados sus compromisos) y top-down (lo que consideramos imprescindible de la aplicación que debe estar en cualquier caso), y de momento funcionan con bastante exactitud, habiéndonos mantenido fieles al plan de fase y a la estimación de alcance durante las últimas iteraciones.
  2. Las planificaciones donde se detallan los compromisos del personal están documentadas en los planes de iteración y fase.
  3. El personal se lee los planes y está al corriente de los mismos. Es debido a que la planificación la realizamos siempre con el máximo número posible de miembros del personal, avisando además por lista de correos cuando se actualiza para que la gente sea consciente de sus obligaciones y planificaciones para el siguiente mes, por ejemplo si no pudieron estar presentes en la planificación.
Seguimiento de proyecto
  1. El seguimiento se contrasta con las planificaciones anteriores al realizar la siguiente, imprescindible para saber qué queda por hacer de lo que debiera estar hecho, además de para permitirnos estimar mejor los tiempos de desarrollo.
  2. Se toman acciones correctivas; al hacer los nuevos planes de iteración se tiene en cuenta qué ha fallado y por qué, y de ser necesario (complejidad inesperada, problemas de personal, etc) se replanifica.
  3. Si hay cambios en las responsabilidades, son de mutuo acuerdo por todo el mundo y por las partes. Es debido a que somos todos conscientes de que somos un grupo reducido de personal, y no hay otro modo de sacar el proyecto adelante.
Subcontratas

No aplicable para nuestro caso.

  1. El contratista elige subcontratas cualificadas.
  2. Ambos están de acuerdo con sus compromisos.
  3. Mantienen comunicación.
  4. El contratista comprueba si la subcontrata cumple los compromisos adquiridos.
Garantías de calidad
  1. Hay planificadas actividades de control de calidad desde las últimas iteraciones, así como procesos automáticos de revisión de la misma mediante pylint.
  2. Se verifica objetivamente que todo cumple los estándares, procedimientos y requisitos desde las últimas iteraciones (centradas en esto mismo).
  3. Los individuos afectados son informados de las actividades de calidad y los resultados. Cuando se detectan problemas de calidad se advierten al responsable, y además hay responsables definidos de cada área.
  4. Cuando se falla algo en calidad y no se sabe resolver se decide desde arriba qué hacer. Contamos con cierta jerarquía y proceso de decisión, aunque algo horizontal, que nos funciona por el escaso número de jefes que tenemos.
SCM (Gestión de configuración de software)

Se entiende por configuración de proyecto al conjunto de documentos y material relativo al proyecto en un momento (especificación, diseño, código y pruebas); la gestión de dicha configuración se refiere por tanto al mecanismo de control de cambios (sea de requisitos, de documentación, de código, etc).

  1. Hay. Existe control de código y de su migración entre versiones más o menos inestables (parecido a los baselines). Hay baselines, responsable de releases y de su mantenimiento, y un proceso de testeo manual para decidir cuándo establecemos un nuevo baseline (generalmente, tras la entrega de un baseline y los últimos bugfixes para dejarlo realmente estable).
  2. Existen versiones del software más o menos establecidas, una por release, que pueden obtenerse individualmente.
  3. Los cambios al software están controlados. En nuestro caso, solo están controlados los de código y documentación con control de versiones, no los de arquitectura (pero estos últimos no han sido necesarios, y pueden considerarse como parte de la documentación).
  4. Los grupos afectados están informados del estado y el contenido de los baselines. Antes de cada release se deja claro qué pretendemos que esté, y mientras trabajamos sobre ella mantenemos información sobre el estado de la misma para saber qué problemas son responsabilidad de cada quién.

Nivel 3: definido

Objetivos

En este nivel el proceso de desarrollo no solo es repetible sino que está claramente definido y establecido, y es susceptible de mejorar. Los procesos existentes se usan para conseguir consistencia, y se personalizan para cada proyecto (en nuestro caso, el modelo de desarrollo seguido sería válido para cualquier otro proyecto solo cambiando temas de grupos concretos encargados de subsistemas).

Áreas clave de proceso

Foco del proceso
  1. El desarrollo del proceso y sus mejoras subsiguientes están coordinadas a través del grupo. Aunque el proceso de mejora de procesos sea algo informal y que responda a cómo observamos, algo intuitivamente y poco cuantitativamente, que se comporta el mismo. Los procesos se discuten entre varias personas siempre, y se descartan cuando no son efectivos para el proyecto para poder agilizar nuestro desarrollo.
  2. Identificar ventajas / inconvenientes de cada proceso es algo que ya hacemos por tanto.
  3. Si bien gozamos de poco tiempo, se planifican mejoras del proceso a cada iteración conforme se detectan aspectos que pueden optimizarse en el mismo, o nuevas necesidades que cubra un nuevo proceso.
Definición de procesos
  1. Existe un proceso de desarrollo y se mantiene según detectamos problemas en el mismo (por ejemplo, la decisión de un repositorio donde estabilizar las releases sin aceptar features nuevas).
  2. Pendiente Se obtiene y distribuye información sobre el uso de este proceso (solo informalmente).
Formación
  1. Hay planificadas actividades de formación del personal, centralizadas en los tutoriales.
    1. Justificadas por el uso de tecnologías nuevas para todo el grupo (como el propio control de revisiones o el lenguaje de programación usado), que, investigadas por un grupo o individuo, son luego explicadas al resto del personal.
    2. Justificadas asimismo por la incorporación de personal al grupo.
  2. Se provee de materiales de educación para la formación del personal relativo a la gestión del software (por ejemplo bazaar para el control de versiones).
  3. Los individuos en el grupo de ingeniería del software también reciben formación adecuada (mediante otros tutoriales como sqlite, así como formación horizontal entre compañeros, y las clases propiamente dichas de la asignatura).
Gestión integrada de software
  1. El proceso de desarrollo de software es una versión a medida del estándar de desarrollo (debido a que el estándar ha surgido en paralelo al proceso concreto).
  2. Pendiente el proceso relativo al proyecto se planifica y gestiona sobre el estándar. No es posible dado que no hemos contado con un estándar predefinido del que partir antes de definir nuestros procesos, si bien teníamos ideas sobre "mejores prácticas" a seguir como el control de versiones en todas partes, o la gestión de releases.
Coordinación entre grupos
  1. Pendiente (parcial) Los requisitos del cliente son aceptados por todos los grupos. Si bien los requisitos se discutieron al inicio, los requisitos del cliente pueden estar algo olvidados por parte de los grupos de trabajo, y necesitar nuevo consenso.
  2. Los compromisos de los distintos grupos están acordados entre todos (ya que se planifica también entre todos).
  3. Los propios grupos identifican, siguen y resuelven los problemas entre ellos.
Peer review ("revisión entre iguales").
  1. Hay planificadas revisiones por parte de otros grupos del trabajo de cada uno para la última iteración, como parte de la mejora de calidad.
  2. Los defectos en el software son identificados, seguidos en el bugtracker y eliminados.

Nivel 4: gestionado

Objetivos

En este nivel se controlan con diversas métricas los procesos seguidos, para conseguir adaptarlos a los proyectos concretos sin desviarse significativamente de los objetivos.

Áreas clave de proceso

Gestión cuantitativa de procesos
  1. Pendiente Hay planificadas actividades de gestión cuantitativa de procesos.
  2. Pendiente Se controla cuantitativamente el rendimiento de los determinados procesos de desarrollo.
  3. Pendiente se conocen cuantitativamente las capacidades de desarrollo del grupo.
Gestión de calidad del software
  1. Hay planificadas actividades de gestión de la calidad del software (orientadas hacia el mantenimiento).
  2. Pendiente Hay definidos objetivos medibles en la calidad, y también sus importancias relativas.
  3. Pendiente Se cuantifica el progreso seguido hacia esos objetivos.

Nivel 5: optimizado

Objetivos

Llegados al último nivel, el objetivo es encontrar mejoras aplicables a los procesos (que ya son medibles merced al nivel 4). En particular, es posible mediante adaptaciones de los procesos no desviarse de las planificaciones y costes estimados.

Áreas clave de proceso

Prevención de defectos
  1. Pendiente Hay planificadas actividades de prevención de defectos.
  2. Las causas más comunes de defectos son identificadas (aparte de mediante la experiencia del trabajo común, mediante herramientas que detectan causas comunes como copy-paste).
  3. Se eliminan sistemáticamente dichas causas.
Gestión de cambios tecnológicos
  1. Pendiente Se planifica la incorporación de cambios tecnológicos.
  2. Las nuevas tecnologías son evaluadas para determinar su efecto sobre calidad y productividad. En nuestro grupo de desarrolladores hay bastantes que siempre experimentan con últimas tecnologías de por sí, así que encontrar algunas que sean aplicables al proyecto es casi natural.
  3. Las tecnologías nuevas apropiadas se incorporan a lo largo de la organización. Para ello ayudan dichos "early-adopters", habiendo localizado ya los problemas más comunes con las mismas durante su uso de las tecnologías.
Gestión de cambios en los procesos

Nos es posible obtener alta puntuación en este campo por ser un grupo pequeño y flexible de desarrolladores.

  1. Se planifican cambios continuos a los procesos.
  2. Toda la organización participa en la mejora de los procesos.
  3. Se mejoran continuamente los procesos, tanto el estándar como los de los proyectos.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License