Métricas establecidas en Personal Software Process

Uno de los elementos fundamentales del proceso PSP radica en la generación y análisis de los indicadores del proceso. Para esto incluye métricas en cada uno de sus niveles de proceso para evaluar el desempeño individual de los programadores. En términos generales agrupa métricas de esfuerzo, defecto, tamaño, desempeño, planificación y calidad, que se presentan a continuación. 

Métricas de desempeño para TI

Nicholas Spanos Director general en Computer Aid para Soluciones de Consultoría publica 100 métricas de desempeño para TI. En el documento identifica elementos de información que permiten medir el desempeño de TI para determinadas categorías. Estos indicadores pueden ser útiles como referencia para establecer un sistema de métricas en apoyo a la toma de decisiones, como parte de las prácticas del área de proceso de Measurement & Analysis. Los objetivos que cubren las métricas, y que pueden ser generales a todas las organizaciones de TI, cubren: asegurar la disponibilidad de la capacidad existente, utilizar los recursos humanos de manera eficiente, respuesta en tiempo a solicitudes de negocio, asegurar la implementación exitosa de cambios en los sistemas y gestionar el costo del ofrecimiento de servicios de TI y alcanzar resultados óptimos.

Herramientas para gestión de requisitos

La gestión de requisitos en el modelo CMMI es un área de proceso de nivel 2 en la representación por etapas. Implica el establecimiento de un entendimiento y compromiso de los requisitos, el control de cambios a los requisitos, el mantenimiento de la matriz de trazabilidad y la identificación de inconsistencias entre los requisitos comprometidos y los productos de trabajo. Para apoyar las actividades del proceso se requiere generalmente el uso de alguna herramienta para llevar el control de las solicitudes de cambio, pero es vital llevar la traza de los requisitos hacia las distintas entidades del producto. Realizando una búsqueda en internet sobre herramientas de apoyo al proceso, en la liga http://easyweb.easynet.co.uk/~iany/other/vendors.htm se pueden encontrar ejemplos de diferentes herramientas y la referencia donde pueden obtenerse. Incluye herramientas gratuitas y otras que tienen una versión libre de prueba por 30 días.

Personal Software Process (PSP®), elementos generales

Personal Software Process (PSP®) es una herramienta diseñada para ayudar a controlar, administrar y mejorar el trabajo de los ingenieros. 

Contiene formas, guías y procedimientos para el desarrollo de software. Cuando se utiliza adecuadamente permite obtener la información histórica que se requiere para establecer y cumplir con los compromisos; adicionalmente permite que las tareas rutinarias sean más predecibles y eficientes. Fue creado por Watts Humphrey como respuesta a la carencia de una herramienta para aplicar los principios generales que planteaba el modelo SW CMM® para los procesos de la organización, aplicados a procesos individuales. 

Propósito

• Ayudar al ingeniero de software a realizar mejor su trabajo.
• Proporcionar datos y técnicas de análisis que se pueden utilizar para determinar que tecnología y métodos aplicar.
• Establecer la estructura que permita comprender por qué se cometen los errores y cómo se pueden detectar.

Motivaciones

• Demostrar los principios del proceso personal.
• Apoyar el desarrollo de planes más precisos.
• Determinar los pasos para lograr la mejora de la calidad de los productos.
• Establecer bases de comparación para medir la mejora del proceso personal.
• Determinar el impacto en el desempeño de los cambios del proceso.

Estructura 

Está formado por siete niveles incrementales. Cada nivel contiene todas las actividades del nivel anterior más una o dos actividades nuevas y está enfocado hacia un problema en particular. Cada actividad está acompañada de una o más formas que apoyan el proceso.

Beneficios de PSP

• Los datos y su análisis permitirán determinar las fortalezas y debilidades.
• Los datos y su análisis posterior conducirán hacia nuevas ideas para la mejora del proceso.
• Se tendrá control total sobre el calendario, aceptando sólo aquellos compromisos que se puedan cumplir. Si se enfrenta con una presión no razonable, puede recurrir a la base de datos histórica de desempeño y demostrar que no es posible establecer el compromiso.
• Se gana un sentido de satisfacción personal.
• La parte de calidad ayudará a producir mejores productos de trabajo.
• El equipo de trabajo tendrá mayor confianza porque existe una disciplina para el desarrollo de los productos.

Desventajas de PSP

• El uso de LOC como métrica de estimación tiene sus desventajas, es dependiente del lenguaje, no todos los ingenieros están de acuerdo con lo que es una LOC lógica y son difíciles de visualizar desde la planeación y diseño
• PSP sólo requiere un estimado del tiempo de interrupción, en lugar de obligar al usuario a registrar el tiempo real. Esto hace que el tiempo de interrupción estimado esta sujeto a las preferencias individuales.
• El método de estimación PROBE puede no ser efectivo si no existe suficiente correlación entre los datos históricos.
• Los formatos de diseño de PSP2.1 pueden ser redundantes para programadores que tienen acceso a otras herramientas de diseño.
• Es subjetivo determinar si una parte del software es reutilizable.
• No todos los ingenieros ven la definición de productividad de la misma manera.
• PSP esta especialmente enfocado al desarrollo de software y no toma en cuenta el tiempo empleado en la negociación de los requerimientos con el cliente. La fase de requerimientos es un componente clave en cualquier proyecto.
• Seguir PSP al pie de la letra no es viable para muchos ingenieros. Deben ver el método como una estructura para el desarrollo de una práctica de desarrollo de software con calidad. Cada uno de los métodos debe ser ajustado a la tecnología, práctica, fortalezas y debilidades de cada desarrollador. Es importante destacar que las métricas existen para evaluar el proceso no a las personas.

Herramientas automatizadas 

PSP requiere de herramientas que permitan:

• Simplificar el proceso de recolección de los datos de tiempo y defectos.
• Automatizar los cálculos requeridos.
• Facilitar el acceso a cada una de las formas.
• Llenar automáticamente cada una de las formas con los datos registrados, eliminando la necesidad de copiar la información a mano.
• El control de tiempo puede hacerse más preciso en segundos en lugar de minutos.
• Implementar una guía de tareas automatizada.
• Cada usuario pueda adecuar la herramienta a sus prácticas.
• Salvar automáticamente los datos históricos y dejarlos listos para su análisis.

Costo de PSP 

PSP toma tiempo para aprenderlo y aplicarlo. La mejor manera de aprender PSP es tomando el curso que le toma a un programador un total de 130 horas para completarlo. Después de un poco de práctica se acostumbra a usar el método como hábito, sin embargo la recolección y análisis de los datos requiere de un esfuerzo mayor. Hay que permitir de 30 segundos a un minuto para registrar los tiempos o defectos. Puede tomar hasta una hora completar el reporte de cierre, donde los datos son recolectados y analizados. 

Adoptar el PSP puede ser como adoptar una nueva forma de vida para el programador. Demasiadas expectativas sobre una mejora inmediata pueden terminar en frustración cuando no se obtengan los resultados que se esperaban. PSP puede causar un conflicto interno, no debe nunca pensar mucho en una debilidad sino crecerse con sus fortalezas.

Auditorías a la gestión de la configuración

Las auditorías a la gestión de la configuración permiten confirmar que los registros de gestión de configuración y elementos de configuración son completos, consistentes y precisos. Son realizadas durante el ciclo de vida para demostrar que los planes, procesos y sistemas se están utilizando y son adecuados así como identificar oportunidades de mejora. En las auditorías se revisa que:

• ¿Las políticas y estándares del proceso son adecuadas para cumplir los objetivos de la organización?
• ¿Los planes y procedimientos de gestión de configuración son adecuados para cumplir con las políticas y estándares definidos?
• ¿El personal responsable de las actividades tiene acceso a los planes y procedimientos y están actualizados?
• ¿El personal ha recibido la formación requerida para realizar sus actividades?
• ¿El personal que realiza las actividades de gestión de la configuración cumple con las políticas, estándares y procedimientos definidos?
• ¿El ambiente e infraestructura para realizar las actividades de gestión de de configuración es adecuado?
• ¿Los componentes de configuración están adecuadamente controlados, versionados e integrados en las líneas base correspondientes?
• ¿Los hallazgos identificados en auditorías previas están siendo atendidos?

Las auditorías garantizan un mecanismo independiente para comprobar el cumplimiento de procesos y estándares aplicables en particular a la gestión de la configuración, además de verificar que el producto está listo para liberarse de acuerdo con los requisitos que lo definen. Este tipo de auditoría pueden ser integradas como parte de las revisiones a procesos y productos del área de procesos Process and Product Quality Assurance (PPQA). Referencia. Westfall, Linda. Software Configuration Management audits. www.westfallteam.com

Auditorías físicas a la configuración (PCA)

Son auditorías que permiten verificar que los elementos de configuración integrados cumplen con la especificación técnica que los define. Esto implica que todos los componentes requeridos están presentes, que corresponden con la versión correcta y con la información contenida en los reportes de estado de la línea base. Es una evaluación independiente para demostrar que el código es adecuadamente descrito en la documentación que se entrega y que tanto el código como la documentación están listos para la entrega. De igual forma contribuye a evaluar el cumplimiento de acuerdos legales y requisitos establecidos para el producto. Típicamente se realiza en conjunción con la auditoría funcional (FCA) o una vez que los hallazgos de la FCA han sido resueltos. En esencia la PCA revisa la información de los reportes de estado a la configuración para asegurar que los productos y la documentación asociada son adecuadamente integradas en la línea base antes de liberar el producto. Lista de elementos a verificar Puede considerar como base para la verificación:

• ¿Los hallazgos de FCA han sido resueltos adecuadamente?
• ¿Todos los componentes de configuración identificados están integrados en la línea base?
• ¿Todos los componentes de configuración cumplen con los estándares que los definen?
• ¿El producto ha sido integrado a partir de los componentes de configuración correctos de acuerdo con la especificación que los define?
• ¿La documentación que se entrega está completa?
• ¿El medio en el que se entrega el producto cumple con los requisitos especificados? ¿Está adecuadamente identificado y etiquetado el producto?
• ¿Los entregables cubren con la lista de entregables requeridos?
• ¿Se cumplen los requisitos para la licencia del producto por terceros?
• ¿Se cubren los requisitos de exportación del producto?

Al igual que en FCA, la revisión se hace sobre muestreo de los productos y documentación considerando los elementos más críticos o problemáticos en el pasado. Referencia. Westfall, Linda. Software Configuration Management audits. www.westfallteam.com

Auditorías funcionales a la configuración (FCA)

Son auditorías que permiten verificar que las funcionalidades que han sido probadas de un componente de configuración han cubierto los requisitos especificados en la línea base de documentación funcional y que la documentación para el apoyo y operación es completa y satisfactoria. Es una evaluación independiente que permite determinar que un producto y su documentación cumplen con los requisitos de funcionalidad, desempeño y calidad. 
Típicamente se realiza antes de las pruebas finales o de la liberación del producto. Básicamente permite demostrar que, con base en los resultados de las verificaciones y validaciones, el producto esta listo para ser entregado. 


Lista de elementos a verificar 
Puede considerar como base los siguientes cuestionamientos:

• ¿El código cumple con todos los requisitos documentados?
• ¿Puede ser rastreado el requisito hasta las pruebas que demuestran que está implantado?
• ¿Las pruebas han sido completas para cubrir la funcionalidad, interfaces y atributos de calidad requeridos?
• ¿Todas las fallas identificadas han sido resueltas, o en su caso adecuadamente identificado como renuncias o desviaciones?
• ¿La documentación es consistente con los requisitos y el producto final?
• ¿Los hallazgos de las revisiones entre colegas han sido adecuadamente considerados?
• ¿Las acciones correctivas identificadas en las auditorías han sido atendidas?

Básicamente la revisión se hace sobre muestreo de los productos y documentación considerando los elementos más críticos o problemáticos en el pasado. Por lo general esta auditoría antecede a la auditoría física a la configuración (PCA) Referencia. Westfall, Linda. Software Configuration Management audits. www.westfallteam.com

Auditorías en el modelo CMMI

Una auditoría, según el glosario de CMMI, es una revisión objetiva de un producto o conjunto de productos de trabajo contra criterios establecidos. El uso del criterio le da objetividad a la actividad y es vital para el éxito de la revisión. Una auditoría proporciona el conocimiento de que lo que debiera ser controlado, según el criterio definido, lo está y puede ser ofrecido en su momento. 

En el modelo existe una práctica específica (SP 3.2) en el área de proceso de Gestión de la Configuración (Configuration Management) que establece la necesidad de ejecutar auditorías a la configuración para mantener la integridad de las líneas base de la configuración. Esta actividad confirma que las líneas base obtenidas y la documentación que las acompañada cumplen con los estándares o requisitos especificados, además de que es exacta y completa. El resultado debe ser adecuadamente documentado y controlado para garantizar el cierre o solución de las observaciones realizadas.