CMM y Gestión de Calidad - inteligenciaes

CMM y Gestión de Calidad

Tenga en cuenta que la metodología CMM/CMMI en la que se basa este artículo proviene del Modelo de madurez de capacidad, Directrices para mejorar el proceso de software, Instituto de ingeniería de software (SEI) de la Universidad Carnegie Mellon.

CMM/CMMI enfatizan la importancia y la independencia del grupo Software Quality Assurance (SQA) que es responsable de implementar políticas, estándares y procesos de calidad organizacional, mientras que el PMBOK enfatiza la importancia de la integración de actividades de calidad en el plan general del proyecto. El PMBOK asigna la responsabilidad de los problemas de calidad del proyecto al director del proyecto y trata las políticas, los estándares y los procesos de la organización como un aporte al proceso de planificación. Los 2 enfoques no están necesariamente en conflicto, sino que forman 2 puntos de vista diferentes del problema, tomados desde 2 perspectivas diferentes. Este artículo se enfoca en alinear las mejores prácticas de gestión de proyectos descritas en el PMBOK con los criterios para la certificación CMM/CMMI de Nivel 2. La certificación será imposible sin un grupo SQA que cumpla con los criterios establecidos por CMM/CMMI.

Otra diferencia clave entre CMM/CMMI y PMBOK es el alcance de sus respectivos enfoques: CMM/CMMI solo aborda prácticas de garantía de calidad para proyectos de desarrollo de software, mientras que PMBOK intenta definir las mejores prácticas de calidad para cualquier proyecto. Al igual que con los demás KPA, Software Quality Assurance se organiza en objetivos, compromisos, habilidades, actividades, mediciones y verificaciones.

Metas

Los 4 objetivos de este KPA son:

  1. Las actividades de SQA están planificadas.
  2. El cumplimiento de las normas, procedimientos y requisitos aplicables se verifica objetivamente.
  3. Los grupos afectados son informados de las actividades de SQA.
  4. Los problemas de incumplimiento que no se pueden resolver a nivel de proyecto se escalan a la alta dirección.
Lee mas  Una historia desde las gradas: lo que han aprendido del juego los ex jugadores de fútbol de Nebraska - McGinn

Compromiso de Desempeño

El proyecto se compromete a seguir una política organizacional escrita para implementar SQA que se aplica a todos los proyectos y que el grupo tiene un canal de información a la alta dirección que es independiente del proyecto. La mayoría de las organizaciones de desarrollo de software tendrán un grupo SQA que brindará servicios de prueba al proyecto. Las políticas, estándares y procedimientos utilizados por el grupo deben ser independientes del proyecto y este grupo debe ser responsable ante la alta gerencia por la correcta implementación y uso de los estándares de calidad de la organización. Las políticas, estándares y procedimientos de SQA son insumos para los procesos de gestión de la calidad.

Habilidad para realizar

La capacidad de actuación gira en torno al grupo SQA. Dicho grupo debe existir, estar adecuadamente financiado y capacitado, y capacitar a los miembros del proyecto de software en su función y responsabilidades.

Actividades

  1. Se prepara un plan SQA para el proyecto de software de acuerdo con un procedimiento documentado y el plan se revisa con el resto del plan del proyecto, se gestiona y controla. Las políticas, normas y procedimientos de la organización (activos de la organización) son entradas para el proceso Planificar la calidad. La gestión y el control se logran a través de los procesos Realizar Garantía de Calidad y Realizar Control de Calidad. El control de calidad garantiza que el producto cumpla con las metas y objetivos de calidad establecidos en el plan, mientras que el control de calidad garantiza que el proyecto se adhiera a la política de la organización (básicamente, que el proyecto siga el plan), que se cumplan los estándares y que se implementen los procedimientos.
  2. Las actividades de SQA se realizan de acuerdo con el plan de SQA. Esta actividad aborda las evaluaciones, auditorías y revisiones que debe realizar el grupo SQA. Esta actividad también requiere la implementación de un sistema de notificación de problemas.
  3. El grupo SQA participa en la preparación y revisión del plan de desarrollo del proyecto y tiene aportes a los estándares y procedimientos adoptados para el proyecto. Para cumplir con este criterio, identifique a los expertos en la materia (SME) de SQA y pídales que contribuyan a planificar los planes de prueba del desarrollador, incluidas las revisiones de diseño, los recorridos de código, etc. También serán responsables de identificarle las actividades de prueba de SQA a medida que planifica. el proyecto. Los estándares y procedimientos son Activos de la Organización y se identifican como insumos para el Plan de Calidad.
  4. El grupo SQA revisa las actividades de ingeniería de software para verificar el cumplimiento. Las actividades de ingeniería de software a las que se hace referencia aquí son las actividades de prueba realizadas por los desarrolladores. Las pymes de SQA deben formar parte del equipo que revisa los diseños y el código.
  5. El grupo SQA audita los productos de software designados para verificar el cumplimiento. Las responsabilidades aquí incluyen informar errores y verificar las correcciones de errores. Esta debería ser la competencia central del grupo SQA. Su trabajo como gerente de proyecto será garantizar que el grupo SQA no solo realice pruebas de acuerdo con las políticas, estándares y procedimientos de la organización, sino que estas pruebas satisfagan las necesidades del proyecto.
  6. El SQA informa los resultados al grupo de ingeniería de software periódicamente. Esta actividad debe ser automatizada por su sistema de informes de errores. Los informes de calidad deben estar especificados en su plan de Gestión de la Comunicación.
  7. Las desviaciones en las actividades de software y los productos de trabajo de software se documentan y manejan de acuerdo con un proceso documentado. El proceso de informe y seguimiento de errores debe describirse en el plan de gestión de calidad y comunicarse al grupo SQA y a los desarrolladores. Este proceso debe respaldar un procedimiento de escalamiento que se ocupe de las desviaciones que no son corregidas por los desarrolladores de software.
  8. El grupo SQA realiza revisiones periódicas de sus actividades y hallazgos con el personal de SQA del cliente. Estos pueden venir a través de reuniones especiales programadas para el propósito o reuniones regulares de Gate Review. La reunión de Gate Review que marca la transición de la construcción a la implementación generalmente estará dominada por los hallazgos de SQA.
Lee mas  Diabetes tipo 2: prevención de la isquemia crítica de las extremidades en diabéticos

Medición y Análisis

Se mide el rendimiento del presupuesto y el cronograma de las actividades de SQA. Estas mediciones serán parte del plan general del proyecto para medir el progreso del proyecto en otras áreas.

Verificación de la implementación

Las primeras 2 verificaciones son duplicaciones de las otras KPA: que las actividades de SQA se revisan periódicamente con la alta dirección y el director del proyecto. El lugar apropiado para estas revisiones serán las reuniones del Comité Directivo y/o las reuniones de Revisión de Puerta. La tercera verificación requiere que un grupo independiente de expertos revise las actividades SQA y los productos de trabajo del grupo SQA del proyecto. Esta es una llamada organizacional fuera del alcance de su proyecto de software.

Los consejos y trucos descritos en este artículo implementan algunas de las mejores prácticas promovidas por el PMI (Project Management Institute). Estos se enseñan en la mayoría de los cursos PMP® y otros productos de capacitación de preparación para el examen PMP®.

Leave a Comment