Introducción PSP    

Procesos del desarrollo del software

Hoy, existen distintos procesos de desarrollo del software: Modelo de Capacidad de Madurez (CMM), Racional Unified Process (RUP®), Personal Software Process (PSP), y Team Software Process (TSP), son algunos de ellos. En particular en Facultad de Ingeniería se utiliza el Proceso Modularizado Unificado y Medible (MUM)

Muchos de estos procesos se enfocan únicamente en una dimensión, en lo que refiere a soporte en la mejora de proceso. RUP y CMM por ejemplo, proporcionan soporte para el desarrollo de software en un nivel organizacional; TSP proporciona soporte en un nivel de equipo; y PSP lo proporciona en un nivel individual.

En particular MUM, por tratarse de una adaptación del RUP, ofrece también soporte a un nivel organizacional.

Los procesos como el RUP y TSP brindan soporte a las organizaciones para desarrollar software, pero no apoyan los procesos de software a nivel del individuo. El foco y el esfuerzo de las actividades de coordinación del trabajo en un nivel de equipo, no incluye pautas individuales dirigidas a los integrantes del equipo. Por consiguiente, depende de cada integrante en forma individual e independiente, encontrar maneras de supervisar, controlar, y mejorar su propio proceso personal de desarrollo de software.

Las principales ventajas de incorporar PSP a MUM son:

> Plantillas para la identificación de tareas y armado del cronograma.

MUM proporciona limitada ayuda a los miembros del equipo en cómo manejar el trabajo dentro de cada iteración. En MUM, las iteraciones pueden durar semanas o meses. El administrador del proyecto asigna tareas y responsabilidades a los participantes. Queda en manos de cada miembro del equipo planificar su trabajo individual durante la iteración. MUM no proporciona ninguna ayuda para esto. PSP, en cambio, proporciona las plantillas Task and Schedule Planning Template, para supervisar el progreso del proyecto. Con estas herramientas, los ingenieros pueden monitorear su progreso y saber cuándo se están atrasando. Pueden entonces informar al encargado de proyecto sobre este estado para poder tomar acciones correctivas apropiadas.

 

> Checklists basados en datos personales sobre defectos

En MUM los miembros del equipo no realizan las revisiones basadas en datos personales sobre defectos del implementador o diseñador. Se utilizan listas de comprobación basadas en los tipos típicos de defectos, recogidos en desarrollos anteriores. Por consiguiente, los miembros del equipo podrían llegar a destinar tiempo en buscar defectos que nunca inyectaron. PSP, en cambio, utiliza listas de comprobación que se basan en datos personales de defectos. De esta forma los ingenieros realizarán las revisiones de su trabajo en busca de los defectos que suelen cometer.

 

 

> Plantillas para registrar ideas de mejora de proceso.

 

MUM no proporciona medios para anotar ideas que aporten a la mejora de proceso. PSP si, proporciona plantillas para registrar ideas de mejora y también para anotar tareas que deberían realizarse o chequearse más adelante en el proyecto.

 

 

 

> Métricas de soporte en la mejora del proceso personal.

 

MUM no proporciona métricas predefinidas que pueda utilizar el ingeniero para supervisar y controlar sus procesos personales de software. Antes de cada nuevo proyecto, la métrica se debe definir y explicar a todos los participantes del proyecto. No hay garantía, sin embargo, que la métrica definida proporcione la clase de información que un ingeniero de software desea o necesita para supervisar su proceso de desarrollo de software. En estos casos, queda en manos del ingeniero, definir y aplicar métrica apropiada. PSP, en cambio, tiene un número de métricas que proporcionan información para mejorar el proceso personal del desarrollo de software.