Gestión de Proyecto

Conferencia 4 – Buenas prácticas de PSP – Parte 1

2023
Objetivos
 Explicar la necesidad de una disciplina de software personal para
enfrentar el proceso de desarrollo de software.

 Explicar las buenas prácticas propuestas en cada nivel del Proceso de

Software Personal (PSP) y la necesidad de aplicarlas para ser un miembro
efectivo de un equipo de desarrollo de software.
Bibliografía

Humphrey, W. “A discipline for software engineering”, Pearson

Education, 1995.

Humphrey, W. “Introducción al Proceso de Software Personal”, Addison

Wesley, (2001 versión español, 1997 versión inglés).

Pomeroy-Huff, M., Mullaney, M. J., Cannon, R. and Sebern, R. The

Personal Software ProcessSM (PSPSM) Body of
Knowledge, version 1.0, Special report CMU/SEI-2005-
SR-0032005, 2005.
Bibliografía

• Martin, R. Código Limpio. Manual de estilo para el

desarrollado ágil de software, Anaya Multimedia,

(2012-versión en español y 2008-versión en inglés).

 Situación de la industria de software

CHAOS Report - solo entre el 28-32% de los proyectos son exitosos

1 Pobre desempeño de las organizaciones de software.

2 Incremento de la presión por mejorar su desempeño.

3 Dificultades con las mejoras de los procesos de software.

 ¿Cómo enfrentarla la situación?

Las organizaciones requieren:

1 Desarrollar o adquirir una disciplina en el

desarrollo del software.
2 Controlar que los ingenieros usen de forma
consistente los nuevos métodos.
Requerimientos críticos

• Crear planes realistas basados en datos

• Usar prácticas de calidad de software
• Alcanzar equipos comprometidos y
efectivos en el manejo de su trabajo
Planes realistas
1 Deben reflejar:
• cuál es el trabajo
• cómo se hace (cuándo y quién)

2 Deben desarrollarlos:
• quienes ejecutan el trabajo
• basados en Datos históricos (registrar datos reales)
Equipos comprometidos
Para comprometer un equipo, este debe convencerse que:
• Su trabajo es importante
• El plan es factible
• Poseen los conocimientos y los recursos necesarios
• Se complementan los miembros.

“Solo los equipos que elaboran su propio plan, se comprometen

con este”
Prácticas de Calidad
Los equipos requieren un proceso que:
• Promueva la eliminación temprana de defectos
• Dirija la calidad a lo largo del proceso

• planificarla
La calidad hay que: • medirla
• seguirla

“Hablar de calidad sin números es sólo hablar”

 ¿Cómo enfrenta la organización
tales necesidades críticas?

Mejorando su Proceso de Desarrollo de Software

Modelos de mejora del Proceso de Software

Nivel Organizacional - CMMi 1

Capacidades de Dirección

Nivel del Equipo - TSP 3

Ejecución del Equipo

Nivel Individual - PSP 2

Conocimientos y Disciplina Personal
 ¿Son disciplinados los ingenieros de software?,

¿Por qué?

1- La ingeniería de software no tiene tradición de ejecución

personal disciplinada.

2- El proceso de software no le impone una disciplina natural a los

ingenieros, estos deben auto-disciplinarse.

3-Regularmente el trabajo disciplinado en cualquier campo requiere

estándares altos y soporte competente.
¿Qué implica disciplina en el trabajo individual?
1. Usar un proceso personal definido

2. Planificar cada tarea

3. Registrar tiempos, tamaños y defectos

4. Seguir la ejecución del proceso

5. Medir y manejar la calidad del producto

 ¿Qué es PSP?

Proceso de Software Personal

• Es un marco de trabajo diseñado para que los ingenieros

hagan mejor su trabajo.

Muestra cómo:
• Estimar y planificar el trabajo,
• Controlar el rendimiento frente a los planes,
• Mejorar la calidad de los programas que produce un ingeniero.
Estructura incremental del PSP
PSP 3
Desarrollo Cíclico

PSP 2.1
PSP 2 Plantillas de Diseño
Revisar Código
Revisar Diseño
PSP 1.1
Planificación de Tareas
Planificación de Horarios
PSP 1
Estimar Tamaños
Reportar Pruebas

PSP 0.1
Estándares de Codificación
PSP 0
Métricas de Tamaños
Registrar Tiempo
Propuesta de Mejora de Proceso
Registrar Defectos
Estándares de Defectos
 Fases de PSP PSP 3
Desarrollo Cíclico

PSP 2.1
PSP 2 Plantillas de Diseño

PSP0 - PSP 1.1 A partir de PSP 2 Revisar Código

Revisar Diseño
PSP 1.1
1. Planificación PSP 1
Planificación de Tareas
Planificación de Horarios
Estimar Tamaños

2. Diseño Reportar Pruebas

PSP 0.1
3. Revisión del diseño PSP 0
Estándares de Codificación
Métricas de Tamaños
Registrar Tiempo
Propuesta de Mejora de Proceso
Registrar Defectos
4. Codificación Estándares de Defectos

5. Revisión del código

6. Compilación
7. Prueba
8. Postmortem
 Clasificación de las fases de PSP
Fase Descripción Ejemplos
Fases que forman parte del desarrollo del  Diseño
Desarrollo proyecto.  Codificación
 Compilación
 Prueba
Generales Fases generales dentro de un proyecto.  Planificación
 Postmortem
Fases que se desarrollan antes de la  Planificación
Rendimiento primera compilación con independencia del  Diseño
tipo.  Revisión de diseño
 Codificación
Pueden ser de tipo general o de desarrollo.  Revisión de código
Fases donde pueden detectarse fallos en la  Compilación
Fallo aplicación o proyecto.  Prueba
Flujo del Proceso
Requerimientos

Proceso PSP

Planificación
Desarrollo

Desarrollo
Logs de Resumen
Guiones Diseño Defectos Plan
del Revisión del diseño y Proyecto
proceso Codificación
Tiempos
Revisión del código
Compilación
Prueba

Reporte resumen de datos

PostMortem del Proceso y Proyecto

Producto terminado
Estructura incremental del PSP
PSP 3
Desarrollo Cíclico

PSP 2.1
PSP 2 Plantillas de Diseño
Revisar Código
Revisar Diseño
PSP 1.1
Planificación de Tareas
Planificación de Horarios
PSP 1
Estimar Tamaños
Reportar Pruebas

PSP 0.1
Estándares de Codificación
PSP 0
Métricas de Tamaños
Registrar Tiempo
Propuesta de Mejora de Proceso
Registrar Defectos
Estándares de Defectos
¿Cuáles son las buenas prácticas
propuestas en PSP 0?

• Registrar tiempo

• Registrar defectos

• Definir estándar de tipo de defectos

Formulario LOGT
Fecha Hora Hora Tiempo Delta Fase Comentarios
Inicio Fin Interrupción Tiempo
Defecto: Error que fue cometido en una fase y que puede ser encontrado
en esa o en fases siguientes.
Ejemplo de Tipos de defectos
Tipo Defecto Descripción

10 Documentación Pobres comentarios

20 Sintaxis Errores tipográficos, puntuación, tipos, formato de instrucciones
Tipo
30 Defecto
Construcción Descripción
Inapropiado control de versiones, Manejo de cambios mezcla
módulos, bibliotecas

40 Declaración-Asignación Variables no declaradas, duplicadas, alcance, fuera de límites

50 Interfaces Llamadas a procedimientos, funciones y referencias, E/S, formatos de
usuario
60 Chequeos Chequeos inadecuados que muestran mensajes erróneos
70 Datos Los datos reales deben tener adecuada estructura y contenido

80 Función Defectos de la función por lógica, punteros, lazos, recursión, cálculo

90 Sistema Restricciones en la configuración del sistema (tiempo) y memoria. Son

relativas a la máquina
100 Ambiente Problemas con el setup del ambiente de desarrollo: diseño,
compilación, prueba y otros problemas de soporte al sistema
Formulario LOGD
Tipos Defectos
10 Documentación 60 Chequeo
20 Sintaxis 70 Datos
30 Construcción 80 Función
40 Asignación 90 Sistema
50 Interfaces 100 Ambiente

Fecha Número Tipo Inyectado Eliminado Tiempo Corrección Defecto Corregido

Descripción: ___________________________________________________________

Fecha Número Tipo Inyectado Eliminado Tiempo Corrección Defecto Corregido

Descripción: ___________________________________________________________
Formulario Resumen Plan Proyecto

Tiempo en fase (min) Plan Real A la fecha % A la fecha

Planificación ________ ________ ________
Diseño ________ ________ ________
Codificación ________ ________ ________
Compilación ________ ________ ________
Prueba ________ ________ ________
Postmortem ________ ________ ________
Total _________ ________ ________ ________
Formulario Resumen Plan Proyecto
Defectos inyectados Real A la fecha % A la fecha
Planificación ________ ________ ________
Diseño ________ ________ ________
Codificación ________ ________ ________
Compilación ________ ________ ________
Prueba ________ ________ ________
Total Desarrollo ________ ________ ________
Defectos eliminados Real A la fecha % A la fecha
Planificación ________ ________ ________
Diseño ________ ________ ________
Codificación ________ ________ ________
Compilación ________ ________ ________
Prueba ________ ________ ________
Total Desarrollo ________ ________ ________
Después Desarrollo ________ ________
Estructura incremental del PSP
PSP 3
Desarrollo Cíclico

PSP 2.1
PSP 2 Plantillas de Diseño
Revisar Código
Revisar Diseño
PSP 1.1
Planificación de Tareas
Planificación de Horarios
PSP 1
Estimar Tamaños
Reportar Pruebas

PSP 0.1
Estándares de Codificación
PSP 0
Métricas de Tamaños
Registrar Tiempo
Propuesta de Mejora de Proceso
Registrar Defectos
Estándares de Defectos
¿Cuáles son las buenas prácticas propuestas
en PSP 0.1?

• Introduce Métricas de tamaño

• Elaboración y uso de estándar de codificación

• Uso del Formulario PIP - Propuesta de Mejora

del Proceso
PSP0.1: Introducción al Tamaño del Software

¿Cómo medir tamaño?

Líneas de Código (LOC)

Medida concreta y simple de contar

No incluyen comentarios ni líneas en blanco

Hay que adoptar un estándar para contar LOC pues no existe

ninguno en la industria
Métricas de Tamaño del Software

LOC Base (B)

Eliminadas (E)
Modificadas (M)
Adicionadas (A)
Reusadas (R)
Total Nuevas y Modificadas (N)
Total Nuevas-Reusables
Total LOC (T)

Buenas prácticas: • Siempre que sea posible reusar código

• Desarrollar código con potencialidad para ser reusado
Uso del Formulario PIP

PIP - Process Improvement Proposal

(Propuestas de Mejoras del Proceso)

Es usado para registrar:

• Cualquier problema,
• Sugerencia de mejora
• Lecciones aprendidas

A lo largo del proyecto y en el informe final el equipo debe

registrar problemas, soluciones y lecciones aprendidas.
Estándar de Codificación:

Ventajas de su uso
• Reduce los errores.
• Garantiza obtener un código claro y comprensible.
• Garantiza buena comunicación del equipo
• Facilita mantenimiento, reúso y revisión.

• Martin, R. Código Limpio. Manual de estilo para el

desarrollado ágil de software, Anaya Multimedia,

(2012-versión en español y 2008-versión en inglés).

 Resumen - Métricas
PSP0
Métricas de tiempo por fases:
 Tiempo real dedicado a cada fase
 Tiempo Real a la Fecha por fase
 % del Tiempo Real a la Fecha por fase

Métricas de defectos
 Defectos reales inyectados y eliminados por fases y A la fecha
 % de defectos reales inyectados y eliminados por fases A la fecha
 Total de defectos reales y A la Fecha inyectados y eliminados durante y después del
desarrollo
 % de defectos reales inyectados y eliminados durante y después del desarrollo
 Resumen - Métricas
PSP0.1
 Tiempo planificado por fase

Métricas de Tamaño
• LOC Total
• LOC Base
• LOC Modificadas
• LOC Eliminadas
• LOC Reusadas
• LOC Nuevas Reusables
• LOC Nuevas y modificadas
• LOC Adicionadas