- Después de la Segunda Guerra Mundial, las organizaciones que se dedicaban a la industria del
software, normalmente basaban su principal estándar de calidad en pruebas al software,
generando departamentos dedicados en buscar y arreglar defectos después de la producción de
sus productos.
- Entre los años 70’s y 80’s, la industria estadounidense se enfocó a conocer la manera en que los
ingenieros de software realizaban sus trabajos y cómo era que desarrollaban sus procesos, lo cual
permitió reconocer que el anterior modelo de “probar y corregir” era muy costoso en tiempo y
recursos.
- En 1976, se comenzaron a incluir prácticas de inspecciones al software.
- En 1987, Watts S. Humphrey, aplicó su Modelo de Capacidad de Madurez (CMM).
- En 1995, los primeros cursos de PSP fueron dados por su creador, en la universidad de Carnegie
Mellon.
- En 1997, el Ing. Watts Humphrey lanzó el libro An introduction to the personal software process
con un enfoque a los ingenieros de software.
Características de PSP.
Es una metodología de la Ingeniería de Software con fundamentos de CMMI.
Tiene un enfoque hacia la producción de software de calidad.
Favorece los procesos de estimación, planeación y desarrollo de
software.
Como todo proceso de calidad, está orientada a mantener la mejora continua.
Se puede establecer junto con los modelos de calidad TSP y CMMI.
Es un proceso definido y ayuda a medir la mejora..
Involucra actividades de revisión e inspección. .
Está diseñado para uso individual.
Se combinan actividades de: administración de proyectos,
Ingeniería de software y calidad.
Ventajas
Estimación más precisa de
tiempos, costos y recursos. .
Cumplir con los compromisos. .
Productividad en aumento.
Localización de los
defectos desde fases
iniciales.
Mejora los tiempos del ciclo de
vida.
Facilita el seguimiento a
procesos.
Los desarrolladores comprenden su condición
actual y obtienen un ambiente y disciplina que
propicia la mejora de su capacidad.
Reduce
costos.
Desventajas
Puede considerarse como un proceso
burocrático porque genera
documentación.
La metodología es muy precisa, puede
propiciar la exageración en su aplicación.
Implementar esta metodología puede
consumir mucho tiempo extra.
La renuencia por parte de los desarrolladores de
aplicar la documentación y por sentirse expuestos al
evidenciar sus tiempos de desarrollo y defectos.
Si no se considera como una inversión, generará la
idea de ser un proceso muy costoso a un corto y
mediano plazo.