Desde que me mencionaron Personal Software Process (PSP) supe que algo de interesante había en él. Por lo que como todo buen investigador, decidí comenzar a incursionar para ver que cualidades podía ofrecerme al trabajo del día a día.
Obviamente lo primero, era dar con el material de origen de sus creados, y gracias a la guía de mi profesor de Estimación y Métricas (Magister en Ingeniería Informática, Unab, Chile), pude obtener el material tan anhelado en PDF, obtenido desde el SEI (Software Engineering Institute, http://www.sei.cmu.edu/), el cual se puede descargar desde acá: http://www.sei.cmu.edu/tsp/tools/index.cfm.
El PSP amplia el proceso de mejora a la gente que realiza el trabajo de desarrollo de software, concentrándose en las practicas de trabajo de los ingenieros en una forma individual, enseñando como manejar la calidad desde el principio de un producto. PSP son nuestras propias métricas, que permiten estructurar y ordenar nuestro trabajo del día a día (no solo de desarrollo de software, esto lo voy a explicar mas adelante). El resultado de nuestro trabajo, además puede ser llevado a un trabajo en equipo TSP (Team Process Software), el cual es «comandado» por un sistema de gestión de la configuración y por supuesto, un Jefe de Proyecto quien evalúa los resultados y avances de los miembros del equipo.
En el campo del desarrollo del software son pocas las organizaciones que siguen o cumplen planes de trabajo o
metodologías establecidas para desarrollar software (conozco varias que no siguen este proceso), poniendo en duda su calidad; muchos de estos proyectos llegaron al fracaso porque sobrepasaron los costos estimados y/o sobrepasaron los tiempos de planificación. Muchos de estos sistemas que tenían defectos produjeron en algún momento perdida de vidas humanas. Proyectos de millones de dólares que no han cumplidos sus objetivos y su tiempo de planificación dejaron millones de usuarios insatisfechos, principalmente aquellos que trabajan mediante una aplicación de software. Algunas principales causas para que el proceso de desarrollo de software pueden ser que : el personal de desarrollo no se involucre lo suficiente en el control de calidad del producto, la alta dirección no esta consciente de la verdadera importancia del proyecto a causa de que no se cuentan los recursos necesarios (dinero, tiempo, tecnología), las prácticas establecidas no son las adecuadas, las empresas se centran en cómo pero no tienen claro el qué, (Vamos a desarrollar esta aplicación en Biztalk Server con este Framework porque es el último del mercado y además tenemos que aprovechar las licencias… a quien no le ha pasado), la relación problema/necesidad muchas veces no existe, no se preocupan de analizar si los objetivos del proyecto; tienen cobertura con los objetivos de la empresa, etc etc (Echemosle para adelante no mas, en el camino lo vamos arreglando!).
En la actualidad la tecnología avanza a pasos agigantados, así también existe un avance en las metodologías y herramientas para el desarrollo de software. Una de estas metodologías es el denominado Personal Software Process (PSP) diseñado por Watts S. Humphrey del Software Engineering Institute en la Carnegie Mellon University.
La producción de software, debe convertirse en un proceso industrial, que sea medible, cuantificable, testeable, que sea un proceso disciplinado y aceptado por todos. El ciclo de vida clásico (Waterfall) que todos conocemos es el cascada, que tiene las siguiente etapas:
· Análisis de Requerimientos
· Diseño
· Programación
· Pruebas
· Implantación
· Mantenimiento
Esta metodología era muy usada, cuando las actividades eran secuenciales, y ayudaba bastante, pero hoy en día, ya no tenemos este tipo de actividades tan secuenciales, tenemos procesos que se orientan mas al cliente y al producto para satisfacer las necesidades del cliente en distintas fases (llamadas iteraciones), en donde en cada iteración, el cliente puede ver un producto tangible y probarlo. SCRUM es una de estas metodologías. Actualmente existen diversas metodologías de ingeniería del software que guían a los programadores a dar un mejor seguimiento a sus programas, dentro de las que podemos mencionar: COCOMO I, COCOMO II, PROBE (Proxy Based Estimation), etc etc. En algún otro POST vamos a hablar mas a fondo de estimación y métricas en el desarrollo de software.
Volviendo a PSP, es una técnica probada para mejorar el funcionamiento y la productividad individuales de los ingenieros. Surge de la necesidad que tienen los Ingenieros de Software de automatizar sus procesos.
PSP fue diseñado para ayudar a los profesionales del software para que utilicen constantemente practicas sanas de ingeniería del software, enseñándoles a planificar y dar seguimiento a un trabajo, utilizar un proceso bien definido y medido, a establecer metas mesurables y finalmente a rastrear constantemente para obtener las metas definidas (quiero hacer un paralelo en esto último mencionando una técnica bastante entretenida llamada GQM -Goal Question Metrics-).
El PSP es una versión pequeña de CMM donde se preocupa solo por un conjunto de las KPAs (Key Process Areas). La estructura de PSP es como sigue:
Los principios de PSP son:
- Cada ingeniero es diferente, para ser mas eficiente, debe planificar su trabajo basándose en su experiencia personal.
- Usar procesos bien definidos y cuantificados
- Los ingenieros deben asumir la responsabilidad personal de la calidad de sus productos.
- Cuanto antes se detecten y corrijan los errores menos esfuerzo será necesario
- Es mas efectivo evitar los defectos que detectarlos y corregirlos.
- Trabajar bien es siempre la forma mas rápida y económica de trabajar.
El PSP se caracteriza porque es de uso personal y se aplica a programas pequeños de menos de 10.000 líneas de código. Se centra en la administración del tiempo y en la administración de la calidad a través de la eliminación temprana de defectos.
En la próxima entrega, vamos a hablar un poco acerca de los niveles de PSP, y como 14 KPA’s de PSP son posible mapearlas con 18 KPA’s de CMMi.
Algunas pantallas del software que yo uso para llevar por ejemplo, un proyecto de investigación personal usando los principios de PSP, las adjunto mas abajo:
Bueno, será hasta la próxima, espero haber aportado algo en esta primera etapa de PSP.
Juanjo's Blog 
Pingback: Los números de 2010 « Juanjo's Blog
disculpa quisiera saber si puede ayudarme a conseguir una información que necesito y la información es:
personal software process(PSP)
– las métricas del PSP
– Estructura del PSP.
– Indicadores del PSP.
.- Formatos del PSP
Hola Jesús, con gusto puedo adjuntarte algunas referencias que pueden ser de utilidad para lo que necesitas:
1.- Métricas de PSP: http://www.scielo.cl/pdf/ingeniare/v19n1/art05.pdf. Sugiero que bajes el software PSP Dashboard y que veas ahí las métricas que usa y la forma en que recolecta datos, algunas de ellas se mencionan en una imagen que subí en este mismo artículo, métricas relacionadas con el control de avance del proyecto, ratios de comparación, métricas de producto si no me equivoco y otras.
2.- Estructura del PSP: Sugiero que bajes la siguiente referencia: W.S. Humphrey. “The Personal Software Process (PSP)”. Technical Report. The Software Engineering Institute. 2000. http://www.sei.cmu.edu/reports/00tr022.pdf
3.- Indicadores del PSP también se encuentran en el artículo técnico del punto 3. Entiéndase por indicador, medir u objetivar en forma cuantitativa o cualitativa sucesos que en este caso tienen que ver con el desarrollo del software.
4.- ¿A que se refiere con formatos del PSP?, de todas formas, de existir el concepto debiera aparecer en el reporte técnico adjunto en el punto 3.
Espero haberlo guiado en relación a su consulta…
Saludos,
Juan José
Lo que pasa que me dejaron hacer una exposición de esos temas y como apenas voy empezando la ingeniería no se mucho de los temas y como algunas paginas no puedo verlas o descargarlas por que bloquearon MEGAUPLOAT!!
y quisiera hacerla lo mejor posible!!
que estupidez, en la actualidad salen muchas nuevas metodologías, son unas pelotudeces. por que no solo usar metodología agil? o DERCA+metodología agil? realmente nadie usa ésta pavada de PSP.
El Personal Software Process (PSP) fue creado por Watts Humphrey para hacer frente a la necesidad que los Ingenieros de Software adquieran un enfoque disciplinado y eficaz para la construcción de programas de software. La filosofía detrás de PSP corresponde a la capacidad de una organización para construir a gran escala sistemas software con alta dependencia de la capacidad de sus Ingenieros de Software para el desarrollo de alta calidad, de una forma efectiva y disciplinada.
1.- Los ingenieros deben planear su trabajo y basar sus planes en sus propios datos personales.
2.- Los ingenieros deben utilizar procesos bien definidos y medidos, deben comprometerse con la calidad de sus productos, planear de la mejor manera su trabajo antes de comenzarlo y deben utilizar un proceso institucionalizado.
3.- Para que los desarrolladores lleguen a entender su funcionamiento de manera personal, deben medir el tiempo que invierten en cada proceso, los defectos que inyectan y remueven de cada proyecto, y finalmente, medir los diferentes tamaños de los productos que producen.
¿Cuál de las metodologías que usted mencionó propone alguno de estos puntos? ¿Es lo mismo una metodología que un proceso? que usted no lo use y no lo entienda no significa que no se esté usando o se llegue a usar.
Haz clic para acceder a 16_Proceso%20Personal%20de%20Software%20PSP.pdf
Saludos
que cosa no entendiste sobre PERSONAL?
¿Su cuestionamiento está relacionado con qué parte exacta del enunciado expuesto?
Saludos
Hola, me parece muy interesante su artículo. Estoy en el desarrollo de un módulo para la manifestación visual de expresiones emociones a partir de un agente inteligente conversacional, al cual le ha sido implementado un módulo para la gestión de emociones. He llegado a su artículo con la premisa de encontrar una metodología que me permita desarrollar éste módulo de manera individual ya que no cuento con un equipo de trabajo. Es buena la teoría, sin embargo lo realmente importante viene en la práctica y pese a que he leído mucho, entiendo que las metodologías se aplican en el desarrollo de software por equipos de trabajo (Si le es posible, me gustaría usted corrigiera éste pensamiento o lo confirmara). Por lo que leí en su artículo, PSP, es un método para desarrollar software de manera personal, en el que los resultados se unirán al trabajo en equipo de una empresa (Hágame favor de corregirme si estoy equivocado). Deseo me pueda auxiliar con mi búsqueda: ¿Estoy en lo correcto al buscar una metodología de desarrollo de software que me permita crear un producto de manera individual? ¿Existe tales metodologías? ¿Podría orientarme para saber dónde encontrarlas?
Agradezco sus atenciones. Permanezco en espera de alguna respuesta.
Trabajo en Inteligencia Artificial, aquí desarrollamos productos virtuales para la rehabilitación de pacientes con capacidades diferentes.
Le envío un fuerte abrazo.
Hola Marco, primero que todo gracias por comentar.
¿Estoy en lo correcto al buscar una metodología de desarrollo de software que me permita crear un producto de manera individual? ¿Existe tales metodologías? ¿Podría orientarme para saber dónde encontrarlas?
Hasta donde entiendo, la «desventaja» que tienes es que no posees un equipo de trabajo, por lo que debes desarrollar el proyecto solo. Bueno, lo interesante de las metodologías (cuando son bien aplicadas) es que puedes usarlas en grandes empresas con numerosos equipos de trabajo o en pequeños proyectos, claro, asumiendo los riesgos de saber que en un «cascada» probablemente requieras de documentación «más dura» que un proyecto con una metodología más ágil, y que además los «sub-proyectos» van a tener que sacarse en la etapa de mantención. Pero vamos al grano…
Puedes aplicar perfectamente PSP, dado que no es más que un conjunto de prácticas disciplinadas para la gestión del tiempo y la mejora de la productividad personal. Por lo que te sugiero, que adoptes algunas prácticas de gestión de scrum y en desarrollo: XP, que se van a terminar alineando perfectamente al PSP. Si en tu proceso incluyes gestión de defectos, planificación/seguimiento y presentación de informes ya estás alineado al PSP.
Por ejemplo:
El nivel 1 de PSP te solicita un Reporte de pruebas. Esto lo puedes implementar usando la práctica de Integración Continua del xP, que dependiendo de la herramienta de desarrollo que uses, pueden automatizar los test unitarios y presentar gráficas y reportes.
En el nivel 1.1 puedes apoyarte de un tablero Kanban, por ejemplo: https://trello.com/ para la calendarización de tus tareas.
Y así sucesivamente… lo bueno de la ingeniería es que proporciona las herramientas, pero uno debe ser capaz de utilizarlas de forma correcta. Espero haberte guiado aunque sea un poco. Cualquier otra consulta no dudes en contactarme.
Saludos cordiales
Muchas gracias por tus atenciones. Me ha servido de mucho para esclarecer algunas interrogantes. Por otro lado, comenzaré a leer información sobre las recomendaciones que me has brindado. Con todo gusto volveré a consultarte y estoy en la disposición de colaborar también con lo que se necesite. Un placer.
Me encanyo el post. Además me ayudo a entender un poco lo que es psp. Gracias
Me quedé con la duda de los indicadores me podría decir en que punto le dice exactamente al amigo que se encuentra esta información??
El mejor indicador en este caso tiene que ver con la calidad del software: # de defectos encontrados. Tal vez use de forma errónea el concepto de indicador en este caso, porque en realidad es una métrica de software, pero creo que son conceptos intercambiables.
Un saludo cordial
Hola!
El asunto es muy sencillo.
Sector académico o Sector empresarial?
Prácticamente todos los procesos, modelos y metodologías «formales» han salido de la academia. Resulta fácil crear directivas y procedimientos detrás de un escritorio. Contrastado con el mundo ágil, podemos ver a los firmantes del manifiesto ágil y ver figuras como Kent Beck, Martin Fowler, personas meramente inmersas en el desarrollo de software, que se han ensuciado las manos desarrollando software a nivel empresarial (no académico). La academia tiene mucho que ofrecer a las Ciencias de la Computación (a nivel global) pero no a la Ingeniería de Software, ha sido un error dejar que tengan esa injerencia.
Predictivo o Adaptativo?
Es tan simple y a la fecha no me explico porque se intenta aplicar procesos estadísticos a algo que por su naturaleza es implemente cambiante. Martin Fowler escribió un célebre artículo titulado The New Metodology y habla precisamente del tema y la influencia de ingenierías civiles o mecánica donde la mayoría de sus problemas son susceptibles de una planificación previa y análisis matemático. http://www.martinfowler.com/articles/newMethodology.html#SeparationOfDesignAndConstruction
Tú mismo mencionas que conoces empresas que no aplican correctamente PSP y dicen que «no funciona». Este es precisamente el problema de procesos y métodos formales o rígidos, que su base son procesos y herramientas, los anteponen por encima de las personas e interacciones (punto del manifiesto ágil) y eso trae como consecuencia prácticas engañosas, desarrolladores que mienten en sus tiempos, empresas que documentan sin encontrarle un sentido a esa documentación con el fin de obtener la certificación PSP//TSP, CMMI, MoProSoft (México), etc. Sin duda que el aplicar estos procesos y metodologías anteriores funcionan si se aplican al 100%, pero a que costo? A tener muchas más empresas que adquieren malas prácticas, que mienten en su documentación para obtener una certificación, a tener desarrolladores desmotivados en la investigación de nuevas tecnologías, lenguajes de programación, herramientas, etc?? A ese costo?
No estaría mal una encuesta entre desarrolladores y ver cuántos se sienten contentos y motivados usando PSP. Seguro la respuesta sería negativa a PSP. Otro punto del manifiesto ágil es precisamente el bienestar de los desarrolladores.
Todo este tema es digno de un trabajo de Tésis. Yo escribi un artículo (quiza algo extenso) titulado «El Fracaso de los Proyectos de Software», quizá se es muy directo y tendencioso, pero en pocas palabras culpo al sector académico por su influencia en la Ingeniería de Software, no así en las Ciencias Computacionales donde evidentemente su trabajo científico de investigación y teórico ha dado avances importantes a la tecnología.
Veo que te desenvuelves en sector académico y que brindas servicios de consultoria, sin embargo, debo decir que en verdad no es lo mismo dedicarse el mayor tiempo a la investigación y docencia a estar inmerso en el desarrollo de software empresarial.
Es una opinión/crítica constructiva a este artículo y espero no sea mal tomado.
Saludos!!
Y se puede leer mi artículo en http://mundobyte-x.blogspot.mx/2010/03/ultima-revision-17-de-marzo-2010.html
Absolutamente de acuerdo con la crítica. Solo agregaría algunas cosas que considero importantes:
El problema no son las metodologías, porque de hecho quienes las crearon comprobaron científicamente durante años que funcionan (el SEI tiene muy buenos estudios al respecto); por ende sería interesante buscar la causa al problema de porqué «no funcionan» algunas metodologías sobre todo en los ámbitos empresariales. Algo he podido comprobar yo en terreno, y es que una de las causas que más pega es el desconocimiento de cómo se deben aplicar correctamente estas metodologías y peor, saber puntualmente qué metodología usar y en qué momento, sacándose de encima el paradigma de que basta solo una metodología para todos los proyectos, y ese es un mito recurrente en los proyectos de desarrollo de software. Algo que se aprecia también en el ámbito de la gestión, llegando a enfrentar situaciones en que la evaluación de riesgos se hace solo con base en un par de riesgos y listo, como si dichos riesgos fueran la panacea o el patrón recurrente en todos los proyectos. La industria clasifica estas situaciones como «malas prácticas».
Estoy muy de acuerdo con lo que usted menciona entorno a la praxis de estos métodos, cuesta llevar la teoría desde el ámbito académico a la práctica real, pero creo que es algo abordable y factible de realizar, lo he podido comprobar durante 2 años y medio ya de ejecución de proyectos en una pequeña consultoría relacionada con desarrollo de software. El principal problema con el que me tuve que enfrentar, no fue el conocimiento de las metodologías, cosa que puede abordarse fácilmente evangelizando al equipo de trabajo, sino que la resistencia del equipo a cambiar su forma de trabajo (justamente uno de los temas que aborda PSP), a evolucionar a un método que nos permitiera trabajar como fábrica de software, donde yo pudiera obtener métricas e indicadores de producción en función de la calidad del producto final; ahí es donde tuve que poner más esfuerzo, que al final resumo fue cerca del 15% del proyecto, dado que no había tiempo para realizar el mentoring por fuera. Y acá al final que es lo que sucedió, que algunos miembros del equipo no se sintieran cómodos con esta forma de trabajo, lo que impactó en el producto final porque el rendimiento de esos miembros se vio afectado.
Finalizo con la siguiente pregunta:
¿Aseguran en un 100% la correcta ejecución y gestión de los proyectos haciendo buen uso de las metodologías que ofrece el mercado?
No lo sé, pero de lo que estoy seguro, es que es posible llegar a alcanzar ese 100% a través del correcto uso de las metodologías, así como no es posible mitigar en un 100% los riesgos de un proyecto (o evitar que se materialicen todos), con este caso sucede algo similar. Como usted bien lo dijo:
Digno de una tesis, y de post post post doctorado… (que están de moda).
Saludos cordiales y gracias por compartir experiencias
Pingback: Estimación de proyectos de software: cálculo usando el método PROBE (PROxy Based Estimation) | Juanjo's Blog
Hola, buen articulo.
¿Alguien conoce alguna fórmula para medir la productividad de un desarrollador usando PSP, es decir, mediante LOCs/hora ?
Espero puedan ayudarme
Muchas gracias por el comentario. Finalmente la productividad podrás medirla sabiendo la cantidad de cosas que haces (LOC/CU/Unit Test…) en un período de tiempo determinado. ¿Me explico?, si tienes un equipo de 10 programadores, podrías medir la productividad de cada uno de ellos estableciendo ciertas métricas, ejemplo. Necesitas saber la cantidad de casos de uso (de la misma complejidad) que ellos codifican (en el mismo lenguaje) en una unidad de tiempo, por ejemplo 1 día (de 9 horas de trabajo). Ahí tienes las 2 métricas: casos de uso y el tiempo, lo que debes hacer ahora es formar el indicador para que te pueda dar un dato concreto. 8/9 -> P1, 6/9 -> P2, 4/9 -> P3… y así sucesivamente, los datos que obtendrías serían:
P1: 0,88
P2: 0,66
P3: 0,44
…
88% sería tu nivel estándar más alto, es decir, que es el programador con mayor rendimiento de productividad dado que PRODUCE más casos de uso en la misma unidad de tiempo que el resto de los programadores. El preocupante en este caso sería el programador P3, que tiene un rendimiento bajo, y ahí es donde entran las habilidades blandas del Jefe de Proyectos para averiguar que es lo que sucede con esa persona. Si logras equilibrar el nivel de productividad, finalmente vas a lograr un impacto positivo a nivel de costos en la empresa, y hasta puedes ganarte un aumento de sueldo y un ascenso.
Buena suerte!