lunes, 27 de diciembre de 2010

Otras doce uvas en la mejora de procesos

Al final de cada año se evalúan los resultados alcanzados, los logros personales, los sueños realizados. Es una época para replantearse metas y objetivos y buscar nuevos propósitos en el nuevo año. 
El año pasado elaboré este artículo y creo que aún es vigente como metas en el caso de la mejora de procesos, con algunas prioridades y adecuaciones que considero apropiadas y tomando en cuenta los hábitos que debemos integrar en la organización.
  1. Lograr el crecimiento del negocio. El objetivo final de un negocio es crecer y obtener ingresos, independiente de los medios para lograr esto si no se alcanza este resultado no puede ser exitoso. El objetivo final de un proyecto de mejora es lograr el crecimiento del negocio, el cumplimiento de un modelo de referencia es un medio y no el fin.
  2. Mejorar la satisfacción del cliente. Un negocio exitoso requiere de clientes satisfechos. Un cambio en la dinámica del negocio que no resulte en un incremento de la satisfacción del cliente, no va a dar los resultados que se esperan. No pierda de vista lo que es importante para el cliente y lleva al negocio a alcanzar ese objetivo de la manera más eficiente posible, la nueva versión de CMMI hace mayor énfasis en esto.
  3. Mejor definición de requerimientos. Los problemas y fallas en los productos por una mala definición de requerimientos representan alrededor del 60% de los defectos presentes en el producto, representan entre 10 y 200 veces más de costo corregirlo en producción y entre un 40% y 80% de re-trabajo. Definir adecuadamente las necesidades y expectativas y validarlo con los clientes o usuarios finales puede ayudar a disminuir esa incidencia.
  4. Gestionar la configuración de los componentes del producto. Los problemas asociados con la calidad y re-trabajo asociados con la integración y liberación de productos que no consideran los componentes adecuados o las versiones correctas, provocan desmotivación y pérdida de recursos. Una adecuada identificación y control de versiones de los componentes pueden cambiar los resultados.
  5. Eliminar de forma temprana los defectos en el producto. El costo y esfuerzo asociado a la detección y corrección de un defecto se incrementa de manera exponencial mientras más lejos esté del momento en que es introducido o generado. Una detección temprana de los defectos puede disminuir hasta en 100 veces ese costo y re-trabajo, además de incrementar la calidad del producto y la satisfacción del cliente.
  6. Mejorar la precisión en la estimación. La mala estimación de los proyectos conllevan re-trabajos, pérdidas económicas y clientes insatisfechos. Atender esta situación puede marcar la diferencia en los proyectos y lograr algo que los clientes esperan, más que entregar rápido desean saber cuándo se le va a entregar y tener certeza de ello.
  7. Gestionar los compromisos del proyecto. Una buena estimación es un elemento deseado en el proyecto, pero si no es controlada y monitoreada la ejecución, no podemos garantizar que se cumplan los resultados que se esperan o que se tomen acciones correctivas de manera oportuna. La gestión de compromisos también considera el control sobre todos los acuerdos y acciones que han sido tomadas durante el proyecto, incluso el cumplimiento de los procesos definidos que resulta en un compromiso más.
  8. Establecer indicadores efectivos. La recolección de métricas es costoso para un proyecto y cuando estas no son utilizadas o no reflejan el comportamiento como base para la toma de decisiones, entonces es dinero perdido. Es importante establecer indicadores efectivos que permitan mejorar la toma de decisiones y optimizar los recursos destinados a la recolección de información.
  9. Establecer mecanismos efectivos de comunicación. Cuando todo está dicho, aún falta mucho por decir. La comunicación es un sistema dinámico y lo que en un momento fue efectivo, en otro deja de serlo. Es importante mantener una comunicación abierta, incluyente, influyente y efectiva para el proceso de mejora con todos los interesados.
  10. Aprender de la experiencia y hacer uso de ella. La inversión que se hace para recolectar y poner a disposición el conocimiento en la organización no ve resultados mientras no se utilice adecuadamente. La base del proyecto de mejora es el aprendizaje colectivo en la organización y el compartir esas experiencias. Si este ciclo no es completo, mediante el uso de ese conocimiento, es tiempo perdido. .
  11. Establecer la mejora continua como una forma de vida en la organización. El ciclo de mejora no es suficiente con la definición de procesos porque requiere aplicarse e instituirse en los proyectos de la organización. Pero tampoco termina con la evaluación de que los procesos están siendo utilizados porque los resultados nos dirán que ya existen mejoras a considerar, es por ello que es un ciclo continuo. Una vez que inicia la mejora, no termina.
  12. Mejorar la satisfacción personal. El motor de la organización es su personal, y su valor se da como resultado de la combinación de: trabajo, actitud y motivación. El equilibrio entre los tres es importante, pero muchas veces el último es el que menos en cuenta se toma. Enfocarse en el beneficio del cambio hacia las personas puede lograr la motivación adicional y acelerar la transformación. Muchas veces el apoyo en la formación, bien orientada, constituye un motivador para las personas que les ayuda a crecer.
Los deseos no quedan a la buena suerte, fortuna y buenas intenciones. Hay que trabajar y enfocarse en los resultados que se esperan. Al final queda la satisfacción y el reconocimiento por los frutos alcanzados.
Safe Creative #1012288147673

miércoles, 22 de diciembre de 2010

Siete hábitos de las empresas altamente efectivas

De acuerdo con las premisas descritas por Stephen R. Covey en su libro “Los siete hábitos de las personas altamente efectivas” podemos hacer un símil hacia el modelo CMMI para lograr comportamientos que hacen efectivas a las organizaciones. 


Los hábitos que enuncia Covey son: 
  • Proactividad 
  • Comenzar con un fin en mente 
  • Primero lo primero 
  • Pensar en el beneficio mutuo (ganar/ganar) 
  • Respeto por los demás, comprender primero para ser comprendido 
  • Sinergizar, sintetizar ideas diversas de un grupo por encimas de las individuales 
  • Afilar la sierra, en el sentido de la mejora continua 
Estos comportamientos tienen un fin ético y ayudan a las personas a lograr una mayor efectividad en sus vidas. El modelo CMMI integra un conjunto de prácticas que ayudan a las empresas a ser efectivas y alcanzar sus objetivos. Existen comportamientos y dinámicas que identifican a estas organizaciones en la ejecución de sus procesos y que podríamos agrupar como hábitos efectivos. 
  • Proactividad. La evolución del proceso permite llevar a la organización de un proceso pobremente controlado y reactivo a un proceso de mejora continua y proactivo. Para ello es fundamental la actitud en la ejecución de las actividades para la identificación de necesidades, problemas, riesgos y defectos que se pueden presentar en los diferentes ámbitos de un proyecto. La detección temprana y oportuna de éstos permite reducir costos, incrementar la calidad y mejorar la productividad. 
  • Orientación al negocio. Las prácticas que se utilizan en la organización deben estar orientadas a las necesidades del negocio, y en consecuencia a mejorar la satisfacción del cliente. No sirve de nada implementar acciones que no tengan este propósito como fin puesto que al final confundir los medios con el fin lleva al fracaso y decepción en la organización. 
  • Seguimiento a compromisos. En todos los contextos de la organización, el cumplimiento de compromisos es esencial para lograr el éxito. Implica un adecuado establecimiento de los mismos y el seguimiento a su cumplimiento para tomar acciones o medidas efectivas en caso de que se identifiquen desviaciones que impidan el logro de éstos. En este caso las medidas que se toman se convierten a su vez en nuevos compromisos. 
  • Medición de resultados. La medición de los resultados es crítico para tomar acciones o decisiones efectivas. No podemos controlar lo que no se mide y la objetividad en esas mediciones es elemental para lograr un buen resultado y comportamiento correcto. 
  • Comunicación efectiva. La comunicación adecuada y efectiva hacia todos los interesados es vital en la organización. La salud de una organización se puede medir por el nivel de comunicación que existe, tanto por los medios como por los participantes en el proceso. Cuando no es efectiva se provocan problemas y situaciones que producen comportamientos inesperados y fuera de control. 
  • Aprendizaje de la experiencia. La organización aprende de sus experiencias y cuando ese conocimiento no es adecuadamente controlado y recolectado, se pierde un “activo” imprescindible para la vitalidad de la misma. Los mecanismos de gestión del conocimiento son primordiales para el crecimiento del negocio. 
  • Mejora continua. Las prácticas establecidas en una organización cambian en la medida que cambian los objetivos, las necesidades y el entorno de la misma. Requiere mecanismos efectivos para gestionar el ciclo de mejora continua y garantizar la evolución hacia niveles más efectivos de operación. La evaluación e identificación de oportunidades de mejora y la implementación y difusión de las acciones definidas son críticas en los resultados para la organización.
Estos comportamientos se logran con un uso apropiado de las prácticas descritas en las diferentes áreas de proceso, aplicadas adecuadamente para lograr un uso, no solo efectivo sino, eficaz para la organización.
Safe Creative #1012228117780

martes, 21 de diciembre de 2010

Atributos de calidad en CMMI

El modelo CMMI establece la identificación de los atributos de calidad. A partir de la versión 1.3 se hace un mayor énfasis en su detección y consideración como parte del proceso de desarrollo. 


Según el glosario, son una propiedad del producto o servicio que determina el punto de vista de calidad de los interesados principales y que son caracterizados por determinadas métricas. No están directamente asociados a funcionalidades del producto o servicio aunque tienen una influencia significativa en la arquitectura. Se consideran como atributos de calidad los relacionados con: la seguridad, confiabilidad, utilización, capacidad de mantenimiento y de respuesta, tiempo de desarrollo y rendimiento. 


RD identifica como parte de los requisitos del cliente los atributos de calidad que se consideran como parte del producto resultante y que deben ser considerados en la descomposición e identificación de requisitos de productos, componentes del producto e interfaz durante la creación de la arquitectura del producto. 


Es parte de la práctica específica 3.2 donde se establece la funcionalidad requerida y los atributos de calidad. Adicionalmente considera el atributo de calidad como uno de los elementos de revisión en la definición de escenarios operativos, evaluación de requisitos y criterios de aceptación. Este mismo criterio se complementa con lo establecido por REQM para aceptar los requisitos que van a ser comprometidos. 


Como parte de las soluciones que se plantean y diseñan en TS se debe considerar los criterios relacionados con los atributos de calidad, de manera que el producto cumpla con los requisitos y propiedades que determinan la aceptación del producto por el cliente e interesados. 


Otras áreas de proceso que consideran de alguna manera los atributos de calidad son: 

  • CM revisa mediante las auditorias de la configuración que los componentes que se entregan o desarrollan cumplen con los atributos de calidad como parte de la evaluación de la consistencia. 
  • DAR los considera para las guías de decisión en casos que afecte la arquitectura del producto.
  • IPM los toma en cuenta para el ajuste y establecimiento de los entornos de trabajo.
  • OPM revisa estos atributos como parte de las necesidades del negocio para considerar mejoras a la calidad del producto.
  • IPM como consideración de los elementos que debe cubrir el producto integrado, los entornos y criterios de integración. 
  • QPM los analiza como parte de los indicadores a controlar cuantitativamente en el proyecto.
  • RSKM considera una posible fuente de riesgos y por tanto se identifican riesgos asociados que pueden afectar, o ser afectados por, los atributos de calidad.
Para el caso de los atributos de calidad del software, están definidos en la ISO/IEC 9126 de la que se puede encontrar un resumen en la siguiente dirección http://www.sqa.net/iso9126.html
Safe Creative #1012218113112

lunes, 20 de diciembre de 2010

Curso Introduction to CMMI for Development v1.3

La nueva versión del curso Introduction to CMMI, para el modelo DEV en su versión 1.3, permite ofrecer un enfoque mucho más práctico y aterrizado a las necesidades de los participantes del mismo. Además de la nueva imagen mucho más fresca y adecuada para trabajar los contenidos, se puede aprovechar mucho mejor los tiempos.


Dos módulos menos, queda en 12 módulos, y un ejercicio adicional, para completar 9 ejercicios de los cuales 3 son completamente nuevos, permiten al instructor enfocarse en la revisión de las áreas de proceso y a los estudiantes trabajar durante el curso para "aterrizar" los conceptos. Lástima por los que ya han "sufrido" versiones anteriores pero, como instructor, he disfrutado mucho más con este nuevo enfoque.


Los ejercicios que se eliminaron estaban relaciones con la definición y revisión de procesos que resultaba confusa para los participantes, y muchas veces no les aportaba prácticamente nada. Los ejercicios nuevos permiten revisar un documento resultante del proceso e identificar en este como se cumplen determinadas prácticas, con lo que se reafirma el concepto de que el modelo puede ser ajustado a las necesidades de cada organización, independiente de la división conceptual por áreas de proceso.


Otra adición interesante es la aplicación de un caso de estudio que se va analizando a lo largo de las diferentes áreas de proceso. Sobre una línea de discusión se pueden revisar diferentes enfoques de aplicación de las prácticas. Lo interesante es que cada área de proceso presenta un enfoque diferente para presentar el caso de estudio, lo que hace dinámico el curso y rompe un poco con la monotonía del contenido.


El modulo que se replanteó completamente es el que toca los elementos de alta madurez, que fueron los que más adecuaciones tuvieron por el cambio de versión. Ahora se concentraron en un solo módulo las cuatro áreas de proceso y no se dan por separado como se presentaba anteriormente. Así los conceptos se entienden y aplican en un sólo lugar, sin fragmentar la información para presentar las prácticas antes de entender de que se trata.


Ha sido un año muy fructífero, con 14 cursos impartidos para 169 asistentes. Esperemos que el próximo año sea similar o mejor, con la oportunidad de entrar en contacto con los asistentes y enriquecernos de experiencias en la aplicación del modelo. Al fin de cuentas esto es lo que cuenta, compartir el conocimiento y disfrutar el curso. Nos vemos por ahí, en algún lugar.
Safe Creative #1012208108166

miércoles, 8 de diciembre de 2010

Calidad, niveles de madurez y niveles de capacidad

Recibí una pregunta a través de un comentario en un artículo y trataré de darle respuesta por aquí. Básicamente la duda tiene que ver con la calidad y los niveles de madurez y capacidad. La pregunta es: "Una empresa que obtenga un determinado nivel de madurez puede asegurar al cliente que su software es de mejor calidad (porque sus procesos son de mejor calidad) que la que obtuvo un nivel más bajo. Por ejemplo la que obtuvo 3 es mejor, en cuanto a calidad de sus productos, que una que obtuvo el 2. ¿Lo mismo pasa con los niveles de capacidad?".

Hay que establecer en principio qué es la calidad. En general se entiende o asume la calidad como el conjunto de propiedades o características que satisfacen las necesidades, implícitas o explícitas, que se esperan de un producto servicio desde el punto de vista del cliente. Considerando esto, la calidad puede variar desde el punto de vista del cliente para el mismo producto o servicio pero podemos tener elementos para minimizar esa variación a través de los procesos.

viernes, 26 de noviembre de 2010

Mejora continua y cambio

El cambio es inherente a la mejora, para ser mejores se requiere cambiar el comportamiento actual. Pero no necesariamente ese cambio es continuo.


Cambio es la "acción y efecto de cambiar", "es dejar una cosa o situación para tomar otra". El paso del ahora al después, requiere de una transición que, en el cambio organizacional, implica factores complejos que involucran personas, proyectos y a la organización como tal.


La mejora continua esta asociada con el conjunto de factores que integran objetivos, infraestructura, políticas, mecanismos de control y supervisión, que garantizan que los cambios realizados son aplicados, pero que además sienta las bases para identificar nuevos cambios en un ciclo que es parte de la dinámica de la organización. La mejora continua no se puede considerar como un proyecto temporal, constituye una forma de vida en la organización.


En muchos proyectos de mejora se considera el cambio como parte del proyecto, pero no se establecen los mecanismos para la permanencia en el estado deseado y la identificación de nuevas posibilidades de mejora. Muchas veces se confunde el propósito sin visualizar el beneficio a largo plazo. 


En el caso de CMMI el logro de un nivel de madurez, como resultado de una evaluación, solamente es una etapa del proceso y no el objetivo en sí. Esto sería equivalente a pedirle a nuestros niños y jóvenes que estudien para prepararse para un examen y no que estudien para prepararse en la vida. La preparación para la vida requiere pasar por muchos exámenes, pero ahí no termina el conocimiento. Cada día es un reto para la organización y con un proceso de mejora continua puede estar preparado para enfrentarlos y mantener sus resultados a largo plazo.


Muchos proyectos de apoyo económico, para las organizaciones, fijan sus metas en el logro de una evaluación o "certificación" en lugar de alcanzar las mejoras que se requieren. Comprometiendo esos recursos económicos con el resultado, se ha logrado incentivar el interés por la calidad y la mejora en la organización. Pero también con el compromiso económico se trabaja para cumplir con las condiciones para el apoyo, a toda costa, incluso forzando a la organización al extremo y establecer "algo" que no se puede mantener. Al final la organización se evalúa, cumple con el compromiso económico pero deja de lado los verdaderos objetivos de la mejora.


Estos apoyos logran estimular el cambio, pero sin una visión a largo plazo orientada a la mejora continua. El "examen" solo es una etapa del proceso, el verdadero cambio se da cuando la organización puede crecer, desarrollar y madurar su comportamiento y alcanzar los objetivos definidos. Cuando esos apoyos económicos realmente estén condicionados a la mejora en los resultados y no en el logro del nivel no se escuchará la frase "Un día después que terminó el appraisal, murió CMMI" (Frase tomada del twitter @rnestCMMI).
Safe Creative #1011267939599

jueves, 25 de noviembre de 2010

Adopción y transición a CMMI v1.3

La nueva versión del modelo CMMI implica algunas consideraciones para las organizaciones que ya están utilizando el modelo, pero que no implican mayor afectación en una adopción que puede ser transparente para el resto de la organización.


La nueva versión está disponible libremente en el sitio del SEI. A partir de esta publicación la versión 1.2 estará disponible durante un años más, es decir, hasta el mes de noviembre del 2011. Esto implica que durante ese periodo son válidas las evaluaciones SCAMPI utilizando la versión 1.2.


La capacitación para actualizarse en el modelo no es un requisito en la versión 1.3, para las organizaciones que trabajan con niveles bajos de madurez. Solamente es un requisito, a discreción del evaluador líder, para los miembros del equipo de evaluación en las organizaciones que buscan evaluar niveles de madurez 4 y 5. 


El curso de formación "Introduction to CMMI", para los que comienzan a utilizar el modelo, está disponible desde el mes de noviembre del 2010 en que se hizo pública la nueva versión. Si está interesado en tomar un curso de este tipo puede contactar a los asociados o Partners del SEI o, como es mi caso, un Instructor Certificado que puede ofrecer esa capacitación en cualquier momento.


Las organizaciones que actualmente utilizan el modelo CMMI con la versión 1.2 no deben tener mayor problema en hacer la transición hacia la nueva versión. Los cambios mayormente son para clarificar y precisar prácticas que podían ser ambiguas o interpretadas de manera incorrecta. 


Los cambios fundamentales se dan en los niveles de madurez 4 y 5, donde aunque no se agrega mayor rigor si se homologa el esquema de aplicación y evaluación que podía ser un tanto ambiguo en la versión anterior. Se elimina el área de proceso de OID que se sustituye por  OPM y se realizan ajustes en CAR, OPP y QPM.


A nivel de madurez 2 básicamente SAM es el área de proceso que más cambios sufrió al desaparecer dos prácticas específicas e integrarse como subprácticas. Otra consideración en REQM es que anteriormente se mencionaba identificar inconsistencias entre planes y productos y ahora el enfoque cambia para asegurar que no existan esas diferencias. 


A nivel de madurez 3 OPD e IPM se modificaron para manejar como parte de las prácticas específicas los conceptos que anteriormente se tenían como IPPD (Integrated Process and Product Development). En la nueva versión se habla de "equipos" y es un punto a considerar en la implantación de estas prácticas. También en PI se regresa a la definición de la estrategia de integración, que inicialmente se tenía en la versión 1.1.


Las evaluaciones SCAMPI utilizando la versión 1.3 deberán esperar al próximo año para poder realizarse. El método de evaluación actualizado se publica en enero del 2011 y a partir de ese momento es que los evaluadores podrán hacer uso del nuevo esquema de evaluación.
Safe Creative #1011257934023

miércoles, 24 de noviembre de 2010

Biblioteca de procesos en CMMI

El área de procesos de OPD establece la necesidad de establecer una biblioteca de activos de procesos (PAL por sus siglas en inglés) como base para el establecimiento del proceso definido y gestionar el conocimiento de la organización. Constituye un repositorio de información que permite almacenar y publicar activos del proceso útiles para los que tienen que definir, implementar o gestionar los procesos en la Organización.  

martes, 23 de noviembre de 2010

Mejora de procesos y consultoría

La implementación de prácticas para mejorar los procesos existentes, o introducir nuevas prácticas en la organización, requiere del apoyo de especialistas internos o externos que puedan ofrecer alternativas, con base en su experiencia y puntos de vista, para cambiar la situación actual. Estos especialistas constituyen consultores que deben considerar tres principios básicos para lograr un buen resultado: precisión, involucramiento y compromiso.

lunes, 22 de noviembre de 2010

CMMI no es suficiente

En un artículo publicado por Channel Partner se comenta sobre la problemáticas de las factorías de software en España. En el análisis se plantea que la mejora del proceso con la adopción de prácticas de CMMI no es suficiente para mejorar la competitividad de la industria de software, en particular en España, pero que es completamente aplicable a nivel internacional.


Se plantea como líneas de trabajo la relación con el cliente, especialización del personal técnico, mejor reutilización del software y mejoramiento de la efectividad del modelo de producción, valorar el producto, competitividad internacional y esquemas de subcontratación.


En general las líneas que se deben fortalecer son la formación del cliente en la calidad ante el costo del producto, incrementar el nivel profesional de los recursos humanos que son la base del desarrollo de software, internacionalización del servicio como parte de la globalización de la industria y la posibilidad de contratación de servicios a nivel mundial y mejorar el uso y operación del modelo de fábrica de software.


El trabajo en la implementación de procesos con base en el modelo CMMI sin una adecuada estrategia en la Organización o en la industria, en términos globales, no permitirá llevar un proceso artesanal a un proceso industrializado de creación y producción de software. Esta puede ser la expectativa y objetivo de muchas organizaciones y gobiernos en diferentes países, que trabajan en el fortalecimiento de la industria con programas gubernamentales. 


Al fin de cuentas CMMI sólo cubre una parte de la realidad de las organizaciones. Existen otros procesos y elementos a tomar en cuenta como parte de la mejora de procesos, que no deben ser pasados por alto.

Safe Creative #1011237914335

viernes, 19 de noviembre de 2010

Resumen de Verificación en CMMI DEV v1.3

El área de proceso de Verification (VER) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito asegurar que los productos de trabajo seleccionados cumplen sus requerimientos especificados.

Resumen de Validación en CMMI DEV v1.3

El área de proceso de Validation (VAL) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito demostrar que un producto o componente de producto se ajusta a su uso previsto cuando se sitúa en su entorno previsto.


Las prácticas definidas en el área de proceso de VAL, en conjunto con VER, tienen elementos muy similares pero desde diferentes perspectivas. En su aplicación pueden coincidir utilizando las mismas técnicas, pero cuidando que se demuestren ambos enfoques. Mientras que en VER se busca demostrar que los productos de trabajo cumplen con los requerimientos que los definen en VAL se demuestra que el producto generado puede ser utilizado.


Una diferencia entre VER y VAL está en que el primero puede ser aplicado a productos internos, no necesariamente dirigidos al cliente, mientras que el segundo está orientado a los productos que serán entregados y utilizados por el cliente o usuarios finales. Una pequeña diferencia que se aprecia al leer detenidamente el propósito y entender la diferencia entre productos de trabajo y componentes del producto, en el glosario del modelo. Lo cual no quiere decir que se aplique hasta el final del desarrollo, sino que por principio son prácticas que se aplican en todas las fases del desarrollo del producto utilizando las diferentes perspectivas que se van obteniendo del producto final.


Otro elemento diferente en el momento de aplicar las validaciones es el entorno de operación. Las prácticas de validación deben aplicarse en un ambiente similar, o lo más cercano posible, al ambiente real de operación del producto, que permita ubicar al usuario en el contexto de uso y determinar cualquier problema que se pueda presentar. La creación de este ambiente de validación es un elemento fundamental en la preparación, sobre todo por la cuestión de presupuesto y tiempos para su preparación.


La identificación, investigación, exploración y definición adecuada de los requerimientos en RD puede reducir las diferencias de perspectivas entre VER y VAL. Al final cuando los requerimientos implícitos, muchas veces relacionados con el uso y operación, son establecidos de manera explícita la diferencia entre VER y VAL son reducidas considerablemente.

La aplicación de VER y VAL se da en conjunto con otras áreas de proceso de ingeniería como RD y TS, pero son fundamentales para cumplir la meta específica 3 de PI que tiene que ver con la integración de los componentes y liberación del producto.


VAL requiere por una meta establecer la estrategia de validación y por la otra ejecutar las validaciones definidas en la estrategia y analizar los resultados.


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso.


Estrategia de validación
SG1 La preparación para la validación es llevada a cabo.
  • SP1.1 Seleccionar los productos y los componentes de producto a validar y los métodos de validación que serán usados.
  • SP1.2 Establecer y mantener el entorno necesario para dar soporte a la validación.
  • SP1.3 Establecer y mantener procedimientos y criterios de validación
Ejecutar las validaciones
SG2 El producto o los componentes de producto son validados para asegurar que sean adecuados para usar en su entorno operacional previsto.
  • SP2.1 Realizar la validación sobre productos y componentes de producto seleccionados.
  • SP2.2 Analizar resultados de las actividades de validación.

jueves, 18 de noviembre de 2010

Resumen de Solución técnica en CMMI DEV v1.3


El área de proceso de Technical Solution (TS) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito diseñar, desarrollar e implementar soluciones para los requerimientos. Las soluciones, los diseños y las implementaciones engloban productos, componentes de producto y procesos del ciclo de vida asociados al producto, de manera individual o en combinación, según sea apropiado.


TS es el centro del desarrollo y mantenimiento del producto, depende de los requerimientos definidos en RD para generar el producto y que se mantienen actualizados a través de REQM. Como parte de las prácticas definidas se desarrolla, de manera iterativa, las diferentes soluciones a los requerimientos del cliente, productos y componentes del producto. Esas soluciones son diseñadas y finalmente construidas para crear el producto o servicio y los procesos asociados durante todo el ciclo de vida.


Las metas definidas en TS interactúan en diferentes etapas del desarrollo y en diferentes instancias del producto y sus componentes. El establecimiento de soluciones, el desarrollo del diseño y la implementación del diseño se ejecutan de manera iterativa de acuerdo con las necesidades del desarrollo.


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso. 


Establecer soluciones
SG1 Las soluciones de producto o de componentes de producto son seleccionadas a partir de soluciones alternativas.
  • SP1.1 Desarrollar las soluciones alternativas y los criterios de selección.
  • SP1.2 Seleccionar las soluciones de componentes de producto con base en los criterios de selección.
Desarrollar el diseño a las soluciones
SG2 Los diseños de producto o de los componentes de producto son desarrollados.
  • SP2.1 Desarrollar un diseño para el producto o el componente de producto.
  • SP2.2 Establecer y mantener un paquete de datos técnicos.
  • SP2.3 Diseñar las interfaces de componentes de producto usando los criterios establecidos.
  • SP2.4 Evaluar si los componentes de producto se deberían desarrollar, comprar o reutilizar en base a los criterios establecidos.
Implementar el diseño
SG3 Los componentes de producto y la documentación de soporte asociada son implementadas a partir de sus diseños.
  • SP3.1 Implementar los diseños de los componentes de producto.
  • SP3.2 Desarrollar y mantener la documentación de uso final

Resumen de Integración del producto en CMMI DEV v1.3

El área de proceso de Product Integration (PI) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito ensamblar el producto a partir de sus componentes, asegurar que el producto, una vez integrado, funciona correctamente (ej. posee la funcionalidad requerida y los atributos de calidad), y entregar el producto.


Aunque PI maneja como propósito el ensamblado de componentes y comprobación del funcionamiento del producto ensamblado antes de la entrega, eso solamente hace referencia a la meta específica 3 del área de proceso. Para cubrir las otras dos metas específicas se requiere definir y establecer la infraestructura para la integración del producto y gestionar las interfaces durante todo el ciclo de desarrollo del producto para garantizar, en el momento de la integración, que no se presenten problemas.


Por ello, aunque el resultado de PI es el producto integrado, para poder llegar hasta ahí es fundamental una efectiva gestión de las interfaces. Las interfaces se identifican como requerimientos en RD, se diseñan en TS y finalmente se gestionan para facilitar la integración en PI. 


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso. En general se hace énfasis en el establecimiento de la estrategia de integración y se aclaran algunos términos que no eran bien interpretados.


Establecer la infraestructura para la integración
SG1 La preparación para la integración del producto es llevada a cabo.
  • SP1.1 Establecer y mantener la estrategia de integración del producto.
  • SP1.2 Establecer y mantener el entorno necesario para dar soporte a la integración de los componentes del producto.
  • SP1.3 Establecer y mantener los procedimientos y los criterios para integración de los componentes del producto
Gestionar las interfaces entre componentes
SG2 Las interfaces del componente de producto, tanto internas como externas, son compatibles.
  • SP2.1 Revisar las descripciones de la interfaz en cuanto a cobertura y completitud.
  • SP2.2 Gestionar las definiciones, diseños y cambios de las interfaces internas y externas para los productos y los componentes de producto.
Ensamblar los componentes para liberar el producto
SG3 Los componentes de producto verificados son ensamblados y el producto integrado, verificado y validado es entregado.
  • SP3.1 Confirmar, antes de ensamblar, que cada componente de producto requerido para ensamblar el producto ha sido identificado correctamente, funciona de acuerdo con su descripción y que las interfaces de componente de producto cumplen con las descripciones de la interfaz.
  • SP3.2 Ensamblar los componentes de producto de acuerdo a los procedimientos y estrategia de integración del producto.
  • SP3.3 Evaluar los componentes de producto ensamblados para compatibilidad de la interfaz.
  • SP3.4 Empaquetar el producto o componente de producto ensamblado y entregarlo al cliente.

miércoles, 17 de noviembre de 2010

Resumen de Desarrollo de requisitos en CMMI DEV v1.3

El área de proceso de Requirements Development (RD) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Ingeniería para la representación continua. Tiene como propósito producir y analizar los requisitos del cliente, del producto y de los componentes del producto.


Las prácticas definidas en esta área de proceso permiten determinar todos los requisitos del proyecto, ya sea para el desarrollo o mantenimiento. Parte de los requisitos del cliente que son derivados en requisitos del producto hasta refinarlos al nivel de requisitos de los componentes del producto, todo esto durante el ciclo de vida del producto. El proceso de obtención y refinamiento de los requisitos va estrechamente vinculado con el diseño del producto por lo que estas prácticas están relacionadas, de manera recursiva, con las establecidas en el área de proceso de Technical Solution (TS).


Los cambios que se requieran a los requisitos establecidos en RD son gestionados por REQM, por lo que RD, TS y REQM están estrechamente relacionados y operan de manera concurrente. La razón por la que REQM está en un nivel de madurez inferior a RD puede estar relacionado con el principio que establece que primero hay que establecer un control y orden en las actividades que se realizan, esto se logra con REQM, para después especializar la forma en que se realizan las actividades, en este caso las prácticas de RD.


RD establece en las primeras metas específicas la definición de los requisitos del cliente y los requisitos del producto y componentes. Con la meta tres complementa las dos anteriores para garantizar que todos los requisitos obtenidos son adecuadamente analizados y validados durante las diferentes etapas del desarrollo del producto. 


En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso.


Definir los requisitos del cliente
SG1 Las necesidades, expectativas, restricciones e interfaces de los interesados son recogidas y traducidas a requisitos del cliente.
  • SP1.1 Obtener las necesidades, las expectativas, las restricciones, y las interfaces de los interesados para todas las fases del ciclo de vida del producto.
  • SP1.2 Transformar las necesidades, las expectativas, las restricciones y las interfaces de las partes interesadas en requisitos del cliente.
Derivar los requisitos del producto y componentes del producto
SG2 Los requisitos del cliente son refinados y elaborados para desarrollar los requisitos del producto y de componentes del producto.
  • SP2.1 Establecer y mantener los requisitos del producto y de componentes del producto, los cuáles están basados en los requisitos del cliente.
  • SP2.2 Asignar los  requisitos  para cada componente del producto.
  • SP2.3 Identificar los  requisitos  de la interfaz.
Analizar y validar los requisitos definidos
SG3 Los  requisitos son analizados y validados, y una definición de la funcionalidad requerida es desarrollada.
  • SP3.1 Establecer y mantener los conceptos operativos y los escenarios asociados.
  • SP3.2 Establecer y mantener una definición de la funcionalidad requerida y los atributos de calidad.
  • SP3.3 Analizar los requisitos para asegurarse de que son necesarios y suficientes.
  • SP3.4 Analizar los requisitos para equilibrar las necesidades y las restricciones de los interesados.
  • SP3.5 Validar los requisitos para asegurar que el producto resultante se ejecutará según lo previsto en el entorno del usuario.

Resumen de Gestión de requisitos en CMMI v1.3

El área de proceso de Requirements Management (REQM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito gestionar los requisitos de los productos y de los componentes del producto del proyecto, e identificar inconsistencias entre esos requisitos y los planes y productos de trabajo del proyecto.

Las prácticas de REQM son la base para la definición y ejecución de las actividades del proyecto y constituyen la entrada para PP. Básicamente aquí se garantiza que los 
requisitos  son válidos, tanto por el contenido como por la fuente de donde se originan, que están comprometidos y que si son modificados se realiza de manera controlada. Para poder determinar el impacto de los cambios es imprescindible contar con una traza de los  requisitos hacia las diferentes entidades del producto y a la inversa.

martes, 16 de noviembre de 2010

Resumen de Gestión de acuerdos con proveedores en CMMI v1.3


El área de proceso de Supplier Agreement Management (SAM) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito gestionar la adquisición de productos y servicios del proveedor.

SAM puede ser considerada como no aplicable para efectos de una organización, en el sentido que las prácticas de adquisición que establece no tienen sentido en el contexto del negocio o no representan un riesgo para el proyecto. En principio cubre la adquisición de productos o servicios que serán entregados al cliente o que se requieren para su desarrollo o mantenimiento. No considera, directamente, la adquisición de proveedores que forman parte de los equipos de desarrollo y que siguen los mismos procesos y mecanismos de reporte que el resto de la organización.

Las prácticas del área de proceso van orientadas a la selección y establecimiento de acuerdos con proveedores y por otra parte a revisar el cumplimiento de los acuerdos tanto por el proveedor como por la organización.



En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso. En el caso de la meta específica 2 se reduce el número de prácticas específicas.

Establecer acuerdos con proveedores

SG1 Se establecen y mantienen los acuerdos con los proveedores.
  • SP1.1 Determinar el tipo de adquisición para cada producto o componente del producto a adquirir.
  • SP1.2 Seleccionar los proveedores en base a una evaluación de su habilidad para cumplir los requerimientos especificados y criterios establecidos.
  • SP1.3 Establecer y mantener acuerdos con proveedores.
Cumplir los acuerdos establecidos
SG2 Los acuerdos con los proveedores deben satisfacerse tanto por el proyecto como por el proveedor.
  • SP2.1 Desarrollar las actividades con el proveedor como se especifican en el acuerdo con proveedor.
  • SP2.2 Asegurar que el acuerdo con proveedor se cumple antes de aceptar el producto adquirido.
  • SP2.3 Asegurar la transición de productos adquiridos del proveedor.

lunes, 15 de noviembre de 2010

Resumen de Gestión de riesgos en CMMI v1.3

El área de proceso de Risk Management (RSKM) corresponde al nivel 3 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito identificar los problemas potenciales antes de que ocurran para que las actividades de gestión de riesgos puedan ser planificadas y utilizadas según sea necesario a lo largo de la vida del producto o del proyecto para mitigar los impactos adversos para alcanzar los objetivos.

viernes, 12 de noviembre de 2010

Resumen de Gestión cuantitativa del proyecto en CMMI v1.3

El área de proceso de Quantitative Project Management (QPM) corresponde al nivel 4 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito gestionar cuantitativamente el proyecto para alcanzar los objetivos establecidos de calidad y de rendimiento del proceso del proyecto.


QPM evoluciona la gestión de proyectos iniciada con las prácticas de PP y PMC y ampliadas con el proceso definido en IPM para introducir los conceptos de gestión estadística del proceso y la gestión cuantitativa del proceso para alcanzar los objetivos definidos en el proyecto. Requiere contar con información histórica suficiente de los indicadores del proceso recolectada por MA y controlada en OPD.


Requiere de los artefactos del proceso de OPP: objetivos de calidad y rendimiento del proceso en la organización, líneas base de rendimiento del proceso (PPB) y los modelos de rendimiento del proceso (PPM), para poder gestionar cuantitativamente la capacidad del proceso y lograr un proceso predecible que es la característica a este nivel.


La primera meta contribuye a establecer las bases para la gestión cuantitativa del proyecto y que sirve en la segunda meta para gestionar cuantitativamente el proyecto, eliminando las desviaciones por variaciones excepcionales en el comportamiento del proceso. 


En la versión 1.3 las metas y prácticas específicas del área de proceso se reformularon y ordenaron, sobre la base de las existentes, para darle un mejor entendimiento en el modelo y facilitar su uso. En particular se integró el análisis de causas raíz de los problemas que impiden el logro de lo objetivos de calidad y rendimiento definidos en el proyecto. En el CMMI SVC se cambia el nombre del área de proceso por Gestión cuantitativa del trabajo (Quantitative Work Management, QWM) para ser consistente en el uso del término "trabajo" en lugar de "proyecto".

Preparación para la gestión cuantitativa del proyecto

SG1 La preparación para la gestión cuantitativa es realizada.
  • SP1.1 Establecer y mantener los objetivos de calidad y de rendimiento del proceso del proyecto.
  • SP1.2 Utilizar la estadística y otras técnicas cuantitativas para componer el proceso definido que permite al proyecto alcanzar los objetivos de calidad y de rendimiento del proceso.
  • SP1.3 Seleccionar los subprocesos y atributos críticos para evaluar el rendimiento y que ayudan a alcanzar los objetivos de calidad y rendimiento del proceso del proyecto.
  • SP1.4 Seleccionar las medidas y las técnicas analíticas a usarse en la gestión cuantitativa.
Gestión cuantitativa del proyecto
SG2 El proyecto es gestionado cuantitativamente.
  • SP2.1 Monitorizar el rendimiento de los subprocesos seleccionados utilizando la estadística y otras técnicas cuantitativas.
  • SP2.2 Gestionar el proyecto utilizando la estadística y otras técnicas cuantitativas para determinar si o no los objetivos de calidad y rendimiento rendimiento del proceso del proyecto serán satisfechos.
  • SP2.3 Realizar análisis de causa raíz de los problemas seleccionados para atender las deficiencias en el logro de los objetivos de calidad y rendimiento rendimiento del proceso del proyecto.

Resumen de Aseguramiento de la calidad del proceso y producto en CMMI v1.3


El área de proceso de Process and Product Quality Assurance (PPQA) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Soporte para la representación continua. Tiene como propósito proporcionar al personal y a la gerencia una visión objetiva de los procesos y de los productos de trabajo asociados.

jueves, 11 de noviembre de 2010

Resumen de Planificación del proyecto en CMMI v1.3


El área de proceso de Project Planning (PP) corresponde al nivel 2 en la representación por etapas y está ubicada dentro de la categoría de proceso de Gestión de proyectos para la representación continua. Tiene como propósito establecer y mantener planes que definan las actividades del proyecto.

Las prácticas en PP en conjunto con PMC son base para la gestión del proyecto y establecimiento de un proceso gestionado que es el fundamento para alcanzar un proceso definido.


Con PP se establecen y actualizan los planes que permiten ejecutar las actividades del proyecto. Parte de la estimación y dimensionamiento del proyecto, la generación de los planes para cubrir las diferentes actividades que se requieren y la obtención de los compromisos de los interesados respecto a los planes definidos.


Los compromisos deben ser documentados, entendidos y aceptados por ambas partes y finalmente deben comprometer recursos en el tiempo. Los compromisos se reflejan desde REQM, se establecen en PP y finalmente son controlados en PMC



En la versión 1.3 del modelo no existen cambios significativos en cuanto a las metas y prácticas específicas para esta área de proceso. En el CMMI SVC se cambia el nombre del área de proceso por Planificación del trabajo (Work Planning, WP) para ser consistente en el uso del término "trabajo" en lugar de "proyecto".

Establecer estimados del proyecto

SG1
Las estimaciones de los parámetros de planificación del proyecto son establecidas y mantenidas.
  • SP1.1 Establecer una estructura de descomposición del trabajo (WBS) de alto nivel para estimar el alcance del proyecto.
  • SP1.2 Establecer y mantener las estimaciones de los atributos de los productos de trabajo y de las tareas.
  • SP1.3 Definir las fases del ciclo de vida del proyecto que abarcan el esfuerzo de la planificación.
  • SP1.4 Estimar el esfuerzo y el coste del proyecto para los productos de trabajo y para las tareas, basándose en estimaciones razonadas.
Establecer los planes del proyecto
SG2
Un plan de proyecto es establecido y mantenido como la base para gestionar el proyecto.
  • SP2.1 Establecer y mantener el presupuesto y el calendario del proyecto.
  • SP2.2 Identificar y analizar los riesgos del proyecto.
  • SP2.3 Planificar la gestión de los datos del proyecto.
  • SP2.4 Planificar los recursos necesarios para ejecutar el proyecto.
  • SP2.5 Planificar las necesidades de conocimiento y de habilidades para ejecutar el proyecto.
  • SP2.6 Planificar el involucramiento de las partes interesadas identificadas.
  • SP2.7 Establecer y mantener el contenido del plan global del proyecto
Establecer los compromisos con los planes del proyecto
SG3
Los compromisos con el plan del proyecto son establecidos y mantenidos
  • SP3.1 Revisar todos los planes que afectan al proyecto para entender los compromisos del proyecto.
  • SP3.2 Ajustar el plan del proyecto para reconciliar los recursos disponibles y los estimados.
  • SP3.3 Obtener el compromiso de las partes interesadas relevantes responsables de ejecutar y de dar soporte a la ejecución del plan.