ISO; Modelos de calidad de software

Capability Maturity Model Integration (CMMi) – Versión 1.1

 El modelo CMMi Versión 1.1 tiene el propósito de proporcionar una única guía unificada para la mejora de múltiples disciplinas tales como Ingeniería de Sistemas (SE – System Engineering), Ingeniería del Software y el Desarrollo Integrado del Producto y del Proceso (IPPD). Más recientemente, el esfuerzo está siendo ampliado para incluir requisitos específicos para la gestión y control de proveedores. Además, debido a la existencia de un modelo internacional para la mejora de los procesos del software; y determinación y evaluación de su capacidad (ISO/IEC TR 15504), hay un compromiso que el CMMi tenga conformidad y compatibilidad con dicho modelo internacional.

El CMMi está caracterizado por áreas de proceso para las 4 disciplinas que cubre actualmente, es decir: Ingeniería de Sistemas (SE), Ingeniería del Software, Desarrollo Integrado del Producto y del Proceso (IPPD) y la Fuente proveedora (A). Aunque muchas de las áreas de proceso (Process Area - PA) definidas en el CMMi tengan los mismos nombres que las áreas clave de proceso (Key Process Area - KPA), definidas en su modelo 41 anterior el SW-CMM, existen una serie de cambios significativos en cuanto al enfoque y al alcance de sus actividades y objetivos.

Los enfoques de CMMi están diseñados para describir los niveles de mejoramiento del proceso. Los Enfoques del CMMi tienen como finalidad atender a las diversas necesidades de las organizaciones que quieren realizar la mejora de sus procesos. Existen 2 enfoques: (1) Continuo y (2) Escalonado.

El Enfoque Continuo hace hincapié en la capacidad de ciertas áreas para realizar sus actividades de manera adecuada. El Enfoque Escalonado hace especial énfasis en el grado de madurez de los procesos (a semejanza del SW-CMM). Ambos enfoques reconocen que las áreas de proceso se pueden agrupar en 4 categorías generales: (1) Gestión de Proyectos, (2) Gestión de Procesos, (3) Ingeniería y (4) Apoyo; y dos categorías opcionales: (1) Desarrollo Integrado del Producto y del Servicio; y (2) Gestión de Compras

Personal Software Process (PSP)

El Personal Software Process (PSP) es un proceso de software definido y medido diseñado para ser usado por medio de un Ingeniero de Software individual. El PSP fue desarrollado por Watts Humphrey y tiene como objetivo guiar el planeamiento y desarrollo de los módulos de software o pequeños programas; y es adaptable a otras tareas del personal.

 Es una tecnología de SEI (Software Engineering Institute) que trae disciplina a las prácticas de los Ingenieros de Software, mejorando la calidad del producto, aumentando los costos y reduciendo el tiempo del ciclo de desarrollo del software. El PSP está basado en los principios de mejoramiento del proceso. CMM está enfocado respecto del mejoramiento de la capacidad organizacional.

El enfoque de PSP es el Ingeniero individual. Para fomentar el mejoramiento a nivel personal, PSP ofrece la administración y control del proceso al Ingeniero de Software. Con PSP los Ingenieros desarrollan software usando una propuesta estructurada y disciplinada. Los Ingenieros se ocupan de:

(1)  seguir un proceso definido

(2)  planificar, medir y seguir su trabajo

(3)  administrar la calidad del producto y     

(4)  aplicar aspectos cuantitativos para mejorar los procesos de trabajo personales.

 El proceso de PSP consiste de un conjunto de métodos, formularios y scripts que muestran a los Ingenieros de Software cómo planificar, medir y administrar su trabajo. El PSP está diseñado para ser usado en algún lenguaje de programación o metodología de diseño, y puede ser usado en varios aspectos del trabajo de software. Consiste en un proceso de nivel 5 de CMM diseñado para calcular el costo individual. Se aplica en la mayoría de las tareas de desarrollo de software como ser:

(1)  definición de requerimientos

(2)  diseño de la 97 arquitectura

(3)  desarrollo del módulo

(4)  producción de la documentación

(5)  pruebas del sistema

(6)  mantenimiento del sistema

(7)  desarrollo de pequeños programas.

Es un prerrequisito del planeamiento de la organización para producir el TSP (Team Software Process).

El proyecto PSP estuvo apuntando a demostrar que un proceso de nivel 5 de CMM podría ser usado por un particular para desarrollar software de alta calidad. PSP requiere de la participación de todos los niveles del management.

Una estrategia efectiva es primero involucrar a los principales Ejecutivos y Gerentes para luego entrenar a los Ingenieros respecto de PSP. El PSP muestra a los Ingenieros como:

(1)  administrar la calidad de sus proyectos

(2)  mejorar las estimaciones y planificaciones

(3)  reducir los defectos de sus productos.

El diseño de PSP está basado en los siguientes principios de planificación y calidad:

(1)  Todo Ingeniero es diferente y para ser más efectivo, los Ingenieros deben planificar su trabajo y deben basar sus planes en sus datos personales

(2)  Para mejorar el performance, los Ingenieros deben usar los procesos bien definidos y medidos (3) Para producir productos de calidad, los Ingenieros deben ser responsables de la calidad de sus productos. Los productos superiores no son producidos por medio de errores, los Ingenieros deben hacer lo posible por realizar un trabajo de calidad

(3)  Menor costo en encontrar y arreglar los defectos de un proceso

(4)  Es más eficiente prevenir defectos que encontrar y arreglarlos.

Team Software Process (TSP)

El proceso TSP (Team Software Process) fue desarrollado por Watt Humphrey en 1996. El objetivo era suministrar un proceso operacional que ayude a los Ingenieros hacer trabajos de calidad. El principal motivador para el desarrollo de TSP fue la convicción que los equipos de Ingenieros puedan hacer el trabajo de manera extraordinaria, pero solo si ellos son formados y entrenados.

El objetivo del TSP es construir y guiar a los equipos. Los equipos son requeridos para la mayoría de los proyectos de Ingeniería. El desarrollo de sistemas es una actividad en equipo, y la efectividad del equipo determina la calidad de la Ingeniería.

En Ingeniería, los equipos de desarrollo tienen múltiples especialidades y todos los miembros trabajan en vista de un objetivo en común. Los objetivos de TSP son:

(1)  ayudar a los equipos de Ingeniería de Software a elaborar productos de calidad dentro de los costos y tiempos establecidos

(2)  tener equipos rápidos y confiables

(3)  optimizar el performance del equipo durante todo el proyecto.

Para el uso de TSP, los desarrolladores de software deben ser entrenados primero en PSP. Usando PSP, los desarrolladores:

(1)  siguen un proceso personal definido y medido

(2)  planifican el trabajo antes de hacerlo

(3)  reúnen datos acerca del tiempo, tamaño y defecto

(4)  utilizan estos datos para administrar el trabajo del personal y asegurar la calidad de los productos que se desarrollan.

 107 TSP es una manera de guiar a los Ingenieros y a sus Gerentes en la utilización de métodos de trabajo en equipos efectivos. El equipo es un grupo de personas que comparten un objetivo en común. Un equipo debe tener más de un miembro y debe trabajar para alcanzar un objetivo en común. Los miembros del equipo deben tener roles, los cuales proveen un sentido de liderazgo y pertenencia. Los roles ayudan a los miembros del equipo a realizar sus trabajos, prevenir conflictos y establecer un grado de control respecto de su ambiente de trabajo. El sentido de control es un requerimiento fundamental para que los miembros estén motivados. La interdependencia es un elemento importante del equipo de trabajo. Significa que cada miembro del equipo depende del performance de los otros miembros. La interdependencia mejora el performance individual debido a que los miembros pueden ayudarse

Proceso de mejora

Se admite, estadísticamente, que en las organizaciones sin " Gestión de mejora Continua" el volumen de la ineficiencia puede estar entre un 15 y 25 % de sus ventas. Las que si la hacen, oscila entre 4 y 6%. Un rápido cálculo nos hará descubrir la magnitud de la respectiva "Mina de Oro" y el efecto que tiene sobre los resultados y la competitividad. La mayoría de los fallos o ineficiencias que configuran el despilfarro son desconocidos, considerados como normales, ignorados y con frecuencia ocultados. Actitudes que impiden buscar soluciones y evitar su repetición. La gestión de mejora continua en una organización requiere:

• -          - El liderazgo de la dirección
• -         -  Un comité de mejora continua
• -         -  Formación y motivación específicas 
• - - Un sistema de gestión documentado
• -        -  Asesoramiento externo

Según la NTP-ISO 9000:2001, Mejora continua es una "actividad recurrente para aumentar la capacidad para cumplir los requisitos" siendo los requisitos la "necesidad o expectativa establecida, generalmente implícita u obligatoria".

• -          Análisis y evaluación de la situación existente.
• -          Objetivos para la mejora.
• -          Implementación de posible solución.
• -          Medición, verificación, análisis y evaluación de los resultados de la implementación. 
• -          Formalización de los cambios.

Los resultados se revisan para detectar oportunidades de mejora. La mejora es una actividad continua, y parte de la información recibida del propio sistema y de los clientes. Dentro del contexto de un sistema de gestión de la calidad, el ciclo PHVA es un ciclo que esta en pleno movimiento. Que se puede desarrollar en cada uno de los procesos. Está ligado a la planificación, implementación, control y mejora continua, tanto para los productos como para los procesos del sistema de gestión de la calidad

Dentro del contexto de un sistema de gestión de la calidad, el ciclo PHVA es un ciclo que esta en pleno movimiento. Que se puede desarrollar en cada uno de los procesos. Está ligado a la planificación, implementación, control y mejora continua, tanto para los productos como para los procesos del sistema de gestión de la calidad.

El ciclo PHVA se explica de la siguiente forma:

Planificar:

- Involucrar a la gente correcta

- Recopilar los datos disponibles

- Comprender las necesidades de los clientes

- Estudiar exhaustivamente el/los procesos involucrados

- ¿Es el proceso capaz de cumplir las necesidades?

- Desarrollar el plan/entrenar al personal

Hacer:

- Implementar la mejora/verificar las causas de los problemas

- Recopilar los datos apropiados

Verificar:

- Analizar y desplegar los datos

- ¿Se han alcanzado los resultados deseados?

- Comprender y documentar las diferencias

- Revisar los problemas y errores

- ¿Qué se aprendió?

- ¿Qué queda aún por resolver?

Actuar:

- Incorporar la mejora al proceso

- Comunicar la mejora a todos los integrantes de la empresa

- Identificar nuevos proyectos/problemas.