PDF de programación - CAPITULO 2. PROCESO PERSONAL DE SOFTWARE

CAPITULO 2. PROCESO PERSONAL DE SOFTWARE.



Después de la segunda guerra mundial, la estrategia de calidad en la mayoría de las

organizaciones industriales se basaba casi por completo en las pruebas. Las empresas

establecieron departamentos especiales de la calidad para encontrar y arreglar problemas

después de la producción de los productos. No fué sino hasta los años 70 y los años 80 que

W. Edwards Deming y J.M. Juran convencieron a la industria estadounidense que se

centrara en mejorar la forma en la que la gente hacía sus trabajos y desarrollaban sus

procesos. [ DEMING; 82 ], [ JURAN 88]

En los siguientes años, este enfoque a los procesos de trabajo, ha sido responsable

de las mejoras importantes en la calidad de automóviles, de la electrónica, o de casi

cualquier otra clase de producto. La estrategia tradicional que había de "prueba-y-arregla"

ahora es reconocida como costosa, que desperdicia tiempo y que además es ineficaz para el

trabajo de la ingeniería y de la fabricación.

Aunque la mayoría de las organizaciones industriales ahora han adoptado principios

modernos de calidad, la comunidad del software ha continuado confiando en la prueba

como el método principal de la administración de la calidad. Para el software, la primera

medida principal en la dirección iniciada por Deming y Juran fué tomada por Michael

Fagan cuando en 1976 él introdujo las inspecciones del software [ FAGAN; 86]

Usando inspecciones, las organizaciones han mejorado substancialmente la calidad

del software. Otra medida significativa en la mejora de calidad del software fué tomada con

la introducción del modelo de capacidad de madurez (CMM) en 1987.



El enfoque principal de CMM estaba en el sistema que administraba la ayuda que se

le proporcionaba a los ingenieros de desarrollo. CMM ha tenido un efecto positivo en el

funcionamiento de las organizaciones del software [ HERBSLEB; 97]

Otra medida significativa en la mejora de calidad del software fué tomada con la

esencia del proceso personal del software (PSP) ya que PSP amplía el proceso de mejora a

la gente que realiza el trabajo de desarrollo de software.

PSP se concentra en las prácticas de trabajo de los ingenieros en una forma

individual. El principio detrás de PSP es ése, sirve para producir software de calidad, cada

ingeniero debe trabajar en la necesidad de realizar trabajo de calidad. PSP se diseñó para

ayudar a profesionales del software para que utilicen constantemente prácticas sanas de

ingeniería de software.

Asímismo les enseña a cómo planear y darle un seguimiento a su trabajo, a utilizar

un proceso bien definido y medido, a establecer metas mesurables, y finalmente a la

utilización del rastreo constante para alcanzar dichas metas. PSP les demuestra a los

ingenieros a cómo manejar la calidad desde el principio del trabajo, a cómo analizar los

resultados de cada trabajo, y a cómo utilizar los resultados para mejorar el proceso del

proyecto siguiente. [SEI; 2000]



2.1 ¿CÓMO FUÉ DESARROLLADO PSP?



Después de que Watts S. Humphrey condujera el desarrollo inicial de CMM para

software, se decidió a aplicar los principios de CMM a los programas pequeños.

Después de eso mucha gente preguntaba cómo aplicar CMM a las organizaciones

pequeñas o al trabajo de los equipos pequeños de software.

Mientras que los principios de CMM se aplicaron a tales grupos, cada vez se volvía

mas necesaria la asesoría para saber que hacer. Fué entonces cuando Humphrey decidió

personalmente utilizar los principios de CMM para desarrollar programas modulares para

ver si dicho enfoque podría funcionar para convencer a los ingenieros de software a que

adoptaran tales prácticas.

Fué entonces en el desarrollo de estos programas modulares, cuando Humphrey

utilizó personalmente todas las prácticas de CMM para que él subiera poco a poco hasta

llegar al nivel 5. Poco después él comenzó a trabajar en el proyecto tiempo completo en

abril de 1989, el Instituto de la Ingeniería de Software (SEI) hizo a Humphrey un

colaborador del SEI, permitiéndole trabajar tiempo completo en la investigación detallada

de PSP.

Durante los siguientes tres años, él desarrolló un total de 62 programas y definió

cerca de 15 versiones de PSP. Utilizó los siguientes lenguajes de programación: PASCAL y

C++ , para desarrollar cerca de 25.000 líneas de código que ayudarían a darle la forma final

a PSP. [SEI; 2002]

De esta experiencia, él concluyó que los principios de la administración de procesos

que desarrolló Deming y de Juran eran totalmente aplicables tanto al trabajo de los

ingenieros de software de manera individual como a ingenieros enfocados al trabajo en

equipo, el resultado? Proceso en equipo de software (TSP)

Humphrey después escribió un libro que les proporcionó a varios asociados el

material necesario para enseñar cursos de PSP. En septiembre de 1993, Howie Dow enseñó

el primer curso de PSP a cuatro estudiantes graduados en la Universidad de Massachusetts.



Humphrey también enseñó el curso de PSP durante el semestre del invierno de

1993-1994 en la universidad de Carnegie Mellon, al igual que Nazim Madhavji en la

Universidad McGill y Soheil Khajanoori lo enseñó en la Universidad Aeronáutica de

Embry. De acuerdo con las experiencias y los datos que proporcionaron estos cursos,

Humphrey realizó la revisión del libro de PSP y publicó la versión final a finales de 1994.

[HUMPHREY; 95 ]

Casi al mismo tiempo, Jim Over y Neil Reizer del SEI y Robert Powels de la

compañía de Servicios Informativos Avanzados (AIS por sus siglas en inglés) desarrollaron

el primer curso para entrenar a los instructores a enseñar el curso de PSP en la industria.

Humphrey junto con el SEI han continuado trabajando en el desarrollo de PSP y asímismo

han aplicado los mismos principios al Proceso en Equipo de Software o TSP.



2.2 PRINCIPIOS DE PSP



El diseño de PSP se basa en los siguientes principios de planeación y de calidad

[HUMPHREY; 95]

• Cada ingeniero es esencialmente diferente; para ser más precisos, los

ingenieros deben planear su trabajo y basar sus planes en sus propios datos

personales.

• Para mejorar constantemente su funcionamiento, los ingenieros deben

utilizar personalmente procesos bien definidos y medidos.

• Para desarrollar productos de calidad, los ingenieros deben sentirse

personalmente comprometidos con la calidad de sus productos.

• Cuesta menos encontrar y arreglar errores en la etapa inicial del proyecto

que encontrarlos en las etapas subsecuentes.

• Es más eficiente prevenir defectos que encontrarlos y arreglarlos.

•

La manera correcta de hacer las cosas es siempre la manera más rápida y

más barata de hacer un trabajo.



Para hacer un trabajo de ingeniería de software de la manera correcta, los ingenieros

deben planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un

proceso bien definido para realizar de la mejor manera la planeación del trabajo.

Para que los desarrolladores lleguen a entender su funcionamiento de manera

personal, deben medir el tiempo que pasan en cada proceso, los defectos que inyectan y

remueven de cada proyecto y finalmente medir los diferentes tamaños de los productos que

llegan a producir.

Para producir constantemente productos de calidad, los ingenieros deben planear,

medir y rastrear constantemente la calidad del producto y deben centrarse en la calidad

desde el principio de un trabajo.

Finalmente, deben analizar los resultados de cada trabajo y utilizar estos resultados

para mejorar sus procesos personales.



2.3 NIVELES DE PSP



PSP tiene un marco de proceso de evolución similar al que tiene CMM. PSP trata

parcialmente 12 de las 18 KPA´s definidas en el CMM.

Las KPA´s son las áreas de procesos clave o Key Process Areas por su significado en

inglés, estas áreas ayudan a guiar a los programadores a que exista un mejoramiento

notable en el proceso de software.

En CMM un nivel de madurez sólo se alcanza si se logran cumplir todas las KPA´s

que exige cada nivel. Sin embargo PSP sólamente cubre de manera parcial estas KPA´s

debido a que es un complemento de CMM y no depende uno del otro en ningún sentido por

lo que es considerado como material de apoyo.

Como se ha visto anteriormente el Instituto de la Ingeniería del Software (SEI) ha

desarrollado el proceso personal del software para definir y reparar la holgura que existe

entre el modelo de la madurez de la capacidad y el individuo. Por lo tanto es ideal utilizarlo

junto con CMM pero no es obligatorio ya que es un proceso y no un modelo como lo es

CMM.

Para desarrollar software de alta calidad, cada componente individual también debe de

contar con la más alta calidad posible. La estrategia total de PSP es cerciorarse de que todos

los componentes individuales se desarrollen con la más alta calidad. PSP logra esto

proporcionando un marco de proceso personal ya definido que el programador puede

utilizar. Este marco es:

• Desarrollar un plan para cada proyecto y/o componente.

• Registrar su tiempo de desarrollo.

• Registrar sus defectos

• Conservar sus datos en informes del proyecto

• Utilizar sus datos para planear los proyectos y/o los componentes futuros.

• Analizar sus datos para desarrollar sus procesos con mas calidad para mejorar su

funcionamiento.



El proceso personal de