No se trata de un proceso o prescripción a seguir.
Es un conjunto de operativas de organización que han demostrado ser útiles en el desarrollo de software e ingeniería de sistemas
¿Por qué utilizar un modelo?
Proporciona un marco de trabajo y un lenguaje común que ayudan en la comunicación
Permite adquirir comprensión de elementos discretos de nuestra organización
Mientras que nos ayuda a tener la «foto» permite centrarnos en áreas particulares para mejorar
Evidentemente no se ha probado que sea un buen indicador económico de la empresa.
Considerar los niveles de madurez como una especie de «hoja de ruta» puede ser arriesgado ya que CMMI no es un proceso o workflow, si no que proporciona objetivos que los procesos y workflows deben de lograr. Alcanzar dichos objetivos mejorará el grado de madurez de la organización.
Los niveles 4 y 5 son, frecuente conocidos como niveles de mayor madurez.
CMMI está dividido en 22 áreas de proceso.
Si bien funcionalmente las diferentes áreas pueden caer en cuatro grupos diferentes cada nivel de madurez se centra en diferentes áreas de proceso
Cada área de proceso está constituida por componentes requeridos, esperados e informativos. Sólo los componentes requeridos son necesarios para contrastar las actividades organizativas contra el modelo.
Algunos ejemplos de áreas son:
CAR: Causal Analysis & Resolution
CM: Configuration Management
DAR: Decision Analysis & Resolution
IPM: Integrated Project Management
MA: Measurement & Analysis
OID: Organizational Innovation & Deployment
OPD: Organizational Process Definition
OPF: Organizational Process Focus
OPP: Organizational Process Performance
OT: Organizational Training
PI: Product Integration
PMC: Project Monitoring & Control
PP: Project Planning
PPQA: Process & Product Quality Assurance
QPM: Quantitative Project Management
RD: Requirements Definition
REQM: Requirements Management
RSKM: Risk Management
SAM: Supplier Agreement Management
TS: Technical Solution
VER: Verification
VAL: Validation
Gestión de Requerimientos
Control de Versiones
Gestión de los Casos de Prueba
Gestión del Proyecto
Construcción automática y CI
Reporting
Extensibilidad…
Como puede observarse se da soporte a áreas de proceso en niveles 2, 3 y 4 de madurez.
Las áreas de proceso soportadas son
Project Planning (PP)
Project Monitoring And Control (PMC)
Supplier Agreement Management (SAM)
Integrated Project Management (IPM)
Risk Management (RSKM)
Quantitative Project Management (QPM)
Merece la pena destacar que uno de los problemas principales a la hora de apoyarnos en versiones previas de TFS era la trazabilidad entre artefactos. ¿Cómo asocio un plan de pruebas a un requerimiento? ¿Cómo asocio tests automáticos a casos de pruebas?
Burndown /Burn Rate Reports:
Una representación visual del cómputo acumulado de horas invertidas en todas las tareas en las últimas cuatro semanas.
Trabajo completado
Trabajo pendiente
Tendencia ideal
Un gráfico de barras que muestra el burn rate (hrs /day) requerido y el llevado a cabo por el equipo.
Lista Con Los Requerimientos Activos.
Web Access Web Part
Lista con los Próximos Eventos
Derivada de un Web Part de SharePoint
Resumen de work items activos, resueltos y cerrados
Compilaciones Recientes y su estado
En progreso, no iniciado, finalizado con éxito, finalizado con error, detenido y finalizado con éxito parcial
Check-in más recientes
Id y su comentario
Burndown /Burn Rate Reports:
Una representación visual del cómputo acumulado de horas invertidas en todas las tareas en las últimas cuatro semanas.
Un gráfico de barras que muestra el burn rate (hrs /day) requerido y el llevado a cabo por el equipo.
Lista Con Los Requerimientos Activos.
Web Access Web Part
Lista con los Próximos Eventos
Derivada de un Web Part de SharePoint
Resumen de work items activos, resueltos y cerrados
Compilaciones Recientes y su estado
En progreso, no iniciado, finalizado con éxito, finalizado con error, detenido y finalizado con éxito parcial
Check-in más recientes
Avance de Tareas (horas)
Trabajo restante
Trabajo completado
Tendencia ideal
Avance de Tareas (número)
Activas frente a cerradas
Progreso de Requerimientos
Una representación visual del número acumulado de requerimientos, agrupados por estado (abierto, resuelto, cerrado) durante las últimas cuatro semanas
Tendencia semanal de defectos
Un gráfico lineal que muestra la media móvil de defectos que el equipo ha abierto y cerrado las últimas cuatro semanas. La media se toma en los últimos siete días previos al momento en que es calculada
Elementos de Trabajo del Proyecto
Resumen con los elementos de trabajo del proyecto activos, resueltos y cerrados.
Lista con las compilaciones recientes y su estado (finalizada con éxito, fallo, no iniciada, detenida y finalizada con éxito parcial)
Lista con los últimos check-in y sus comentarios
Burndown /Burn Rate Reports:
Una representación visual del cómputo acumulado de horas invertidas en todas las tareas en las últimas cuatro semanas.
Un gráfico de barras que muestra el burn rate (hrs /day) requerido y el llevado a cabo por el equipo.
Lista Con Los Requerimientos Activos.
Web Access Web Part
Lista con los Próximos Eventos
Derivada de un Web Part de SharePoint
Resumen de work items activos, resueltos y cerrados
Compilaciones Recientes y su estado
En progreso, no iniciado, finalizado con éxito, finalizado con error, detenido y finalizado con éxito parcial
Check-in más recientes
Merece la pena destacar que uno de los problemas principales a la hora de apoyarnos en versiones previas de TFS era la trazabilidad entre artefactos. ¿Cómo asocio un plan de pruebas a un requerimiento? ¿Cómo asocio tests automáticos a casos de pruebas?
Una característica (Feature) es un ítem dentro del Plan de Producto que agrupa varias tareas. Cada característica se da de alta como un requerimiento (p.e. el cliente puede escoger un restaurante de una lista disponible y añadirlo a su lista de favoritos)
Una característica se asigna a una iteración en el plan de producto (y en consecuencia cada una de las tareas que la componen).
Una característica completa parcialmente un requerimiento de cliente
Cada Iteración consistirá en construir una o más características
La descomposición en escenarios y features permite revisar el diseño del sistema y comenzar una construcción incremental y probable
Los requerimientos de cliente se cumplen de manera incremental, completando las características que lo componen.
Una característica se considera completada cuando supera con éxito todos los casos de prueba asociados a la misma
No se trata de centrarse en las tareas de construcción ya que no son muy diferentes de las llevadas a cabo en otros modelos. Sí conviene recalcar la tarea de Code Review que es una de las recomendadas en CMMI
El quid en CMMI es llevar seguimiento no sólo de los casos de prueba diseñados, pasados o fallidos.
Hay que dar el siguiente paso y es trazar dichos casos de prueba hacia los casos de uso correspondientes, de forma que, cuando algún caso de prueba falla, el caso de uso no está completo (y en consecuencia tampoco puede estarlo el requerimiento) y que cuando todos los casos de prueba de un caso de uso han pasado con éxito y todos los casos de uso de un requerimiento están completados, también lo está el requerimiento correspondiente.
Incidencia: No se trata de un defecto de código. Se trata de un evento o situación que podría bloquear (o de hecho bloquea) el avance del trabajo. Se diferencia de los riesgos en que las incidencias se identifican de manera espontánea.
Pasos Compartidos (Shared Steps): Se pueden utilizar para la definición y mantenimiento en serie de casos de prueba. Al crear Pasos Compartidos, es posible definir una secuencia de pasos una vez e insertar en ella varios casos de prueba (p.e. el usuario se valida en la aplicación, navega a una sección determinada y añade un elemento al carro de la compra)
Enlazables: Esta característica es nueva en la actual versión y permite una mejor trazabilidad de los work items (imprescindible para cumplir con el modelo CMMI). Por ejemplo, permite ver el estado de un requerimiento a través del estado de sus casos de uso, a través de sus casos de pruebas.
Econtrar tu trabajo asignado
My Test Cases
My Work Items
Construcción y Pruebas
Active Bugs
Development Tasks
My Test Cases
Open Tasks
Open Test Cases
Resolved Bugs
Test Tasks
Planificación y Seguimiento
Customer Requirements
Product Requirements
Open Requirements
Open Requirements without Test Cases
Open Work Items
Proposed Work Items
Reviews
Untriaged Work Items
Work Breakdown
Work Items With Summary Values
Gestión del Cambio
Change Requests
Open Change Requests with Requirements
Requirements with Open Change Requests
Solución de Problemas (Troubleshooting)
Blocked Work Items
Corrective Action Status
Mitigation Actions
Open Issues
Risks
Ya se ha podido ver Dashboards de ejemplo en el capítulo de gestión de proyectos.