Nombre del alumno:

Alfonso Tolentino Hernndez

Matricula:
61248

Grupo:
IS06

Materia:
Metodologa personal de desarrollo de software

Docente asesor de materia:

Mtro. Erick Ibarra Cruz

Numero de actividad:
Actividad 1

Tema:
Importancia de la metodologa de PSP

Mxico, DF a 17 de mayo de 2015

Instrucciones
1.- Investiga en la empresa en la que laboras, si la metodologa de desarrollo de software que se
ha implementado cumple con los tres criterios que se citan a continuacin. Indica someramente el
porcentaje de cumplimiento de cada uno de ellos:
Planificar su trabajo,
Hacer su trabajo de acuerdo con el plan,
Y esforzarse por producir productos de alta calidad.
2.- Realiza un anlisis sobre la capacidad de los ingenieros de software para cumplir
sistemticamente sus compromisos laborales con calidad y eficiencia.
3.- En caso de usar metodologas de desarrollo, indica, las que se han utilizado, as como, la
capacitacin que se ha proporcionado al capital humano con respecto a PSP.
4.- Desarrolla una conclusin donde describas la importancia y objetivos de la metodologa PSP
para controlar errores, costos, tiempos de desarrollo, disminucin del riesgo para el cliente, la
empresa y para el ingeniero de software.

Desarrollo
1.- Investiga en la empresa en la que laboras, si la metodologa de desarrollo de software
que se ha implementado cumple con los tres criterios que se citan a continuacin. Indica
someramente el porcentaje de cumplimiento de cada uno de ellos:
Especificacin
Planificar su trabajo,

Porcentaje (%)
80%
50%

Hacer su trabajo de acuerdo con el plan,

70%
Y esforzarse por producir productos de alta
calidad.
2.- Realiza un anlisis sobre la capacidad de los ingenieros de software para cumplir
sistemticamente sus compromisos laborales con calidad y eficiencia.

Desde mi perspectiva, el personal que labora en la Subdireccin de Innovacin y Sistemas

Operativos, considero que el personal cuenta con la capacidad necesaria para poder cumplir con
sus compromisos, ya que lo han demostrado cuando se ha presentado la oportunidad, esto
derivado de que no siempre se pide cumplir con las pruebas de calidad, ya que en ocasiones
solicitan sistemas que son de carcter urgente, en donde lo principal que les interesa a los
solicitantes es la funcionalidad del mismo.

3.- En caso de usar metodologas de desarrollo, indica, las que se han utilizado, as como, la
capacitacin que se ha proporcionado al capital humano con respecto a PSP.
Actualmente se utiliza el modelo de Cascada como la metodologa de desarrollo
El modelo de cascada clsico data de la dcada de los 60s y 70s (Royce 1970, Boehm 1981). El
modelo de cascada se define como una secuencia de actividades a ser seguidas en orden, donde
la estrategia principal es definir y seguir el progreso del desarrollo de software hacia puntos de
revisin bien definidos (milestones o checkpoints).
Las siguientes mximas sirven de base para el Modelo de Cascada (Goldberg y Rubin 1995):
Las metas se logran de mejor manera teniendo como fin puntos de revisin bien definidas y
documentadas, dividiendo el desarrollo en etapas secuenciales bien definidas.
Documentos tcnicos son comprensibles para usuarios y administradores no-tcnicos, y estos
participantes no-tcnicos pueden comunicarse de forma efectiva durante las diversas actividades.
Cada detalle sobre los requisitos puede conocerse de antemano antes de desarrollarse el software,
y estos detalles son estables a travs del desarrollo.
Pruebas y evaluaciones pueden llevarse a cabo eficientemente al final del desarrollo.
El modelo de cascada fue inicialmente bien recibido ya que identificaba etapas razonables y
lgicas para las diversas actividades. Lamentablemente, el modelo no explicaba entre otras cosas
cmo modificar un resultado. No exista una gua del por qu y cundo se deba revisar un
resultado previo para sus posibles cambios, en especial considerando que es extremadamente
difcil definir todos los requisitos de un sistema al inicio y que estos se mantengan estables y sin
cambios a lo largo del desarrollo. Esta rigidez trajo dudas sobre la utilidad del modelo. La irona en
la mayora de los proyectos de desarrollo que usan este modelo es que los administradores no

estn de acuerdo con las mximas bsicas, aunque eligen modelos de proceso basados en ellas. A
menudo, el requisito de producir entregas intermedias (mayormente documentos) para ser
seguidos por financiamiento obliga a seguir este enfoque secuencial, separando drsticamente las
actividades, an cuando los administradores crean que otro enfoque sera mejor. Por lo tanto, el
modelo de cascada dej de ser utilizado de acuerdo a su definicin original, llevando a los usuarios
a utilizar variantes del modelo bsico.
Ed Yourdon, en su libro Decline and Fall of the American Programmer (Yourdon 1992), discute los
problemas con el Modelo de Cascada:

Los documentos a entregar rigen el proceso de software.

Toma demasiado tiempo ver resultados.
Depende de requisitos estables correctos.
Hace difcil rastrear (ver la dependencia) de los requisitos iniciales y el cdigo final.
Retrasa la deteccin de errores hasta el final.
No promueve el reuso de software.
No promueve el uso de prototipos.
No se practica de manera formal.

Actualemente no se ha recibido alguna capacitacion para el personal respecto a PSP, aunque

considero que es una metodologa muy practica que serivira de mucho para incrementar la calidad
de los sistemas que se desarrollan.

4.- Desarrolla una conclusin donde describas la importancia y objetivos de la metodologa

PSP para controlar errores, costos, tiempos de desarrollo, disminucin del riesgo para el
cliente, la empresa y para el ingeniero de software.
El PSP (Personal Software Process) es una tecnologa que tiene como justificacin la premisa de
que la calidad de software depende del trabajo de cada uno de los ingenieros de software y de aqu
que el proceso diseado debe ayudar a controlar, manejar y mejorar el trabajo de los ingenieros
[Humphrey, 1998]. El objetivo de PSP es lograr una mejor planeacin del trabajo, conocer con
precisin el desempeo, medir la calidad de productos y mejorar las tcnicas para su desarrollo. La
instrumentacin de esta tecnologa consiste en lo que se denomina evolucin del PSP. Se siguen
ciertos pasos comenzando con las lneas base PSP0 y PSP0.1, el proceso personal de planeacin
PSP1 y PSP1.1, el manejo personal de calidad PSP2 y PSP2.1 y por ltimo el proceso personal
cclico PSP3.

Imagen 1. Los niveles de PSP.

PSP0 (i) define el proceso de trabajo personal identificando y ordenando las principales (ii)
introduce la recoleccin de datos para medir la productividad y calidad a travs del registro de
tiempo y defectos (iii) establece las bases para las mejoras en planificacin de trabajo por tiempos
y evaluacin de resultados y (iv) documenta el proceso usando formas especficas. PSP0.1 (i)
registra el tamao del producto a travs de puntos funcionales y estandarizacin de la codificacin
y (ii) registra los problemas y propuestas de mejora.
PSP1 (i) mejora la planeacin introduciendo la estimacin del tamao del producto y (ii) introduce
los reportes de pruebas. PSP1.1 (i) introduce las estimaciones de recursos e (ii) introduce la
calendarizacin.
PSP2 (i) introduce las actividades de deteccin temprana de defectos a travs de revisiones de
diseo, cdigo y uso de listas de verificacin. PSP2.1 (i) introduce formas para el diseo detallado
facilitando as la revisin del diseo.
PSP3 (i) introduce el proceso cclico para desarrollar programas de mayor tamao, (ii) introduce el
registro de seguimiento de asuntos y (iii) lleva el resumen de planeacin y registro de tiempo,
tamao y defectos por ciclo.
El PSP se considera la solucin para pasar rpidamente entre niveles de CMM al lograr un mejor
entendimiento de nuestras capacidades y habilidades y un mejor control sobre nuestro trabajo. Sin
embargo, PSP tiene el problema de que es implementada a nivel individual. Al momento de la
integracin colectiva existen conflictos en el nivel organizativo, por lo cual se defini TSP (Team
Software Process). El TSP se concentra en los aspectos del desarrollo de software realizados por

equipos de trabajo, definiendo aspectos como la asignacin y control de tareas para los diversos
miembros del equipo.

Referencias

J.J. Pelez, El Modelo de Capacidad de Madurez y su Enfoque al Proceso Personal de

Software

(PSP).

Captulo

2.

Proceso

Personal

de

Software.

http://www.pue.udlap.mx/~tesis/lis/pelaez_r_jj/capitu lo2.pdf,
Letelier, T. P. (2009). Proceso de desarrollo de software. Departamento de Sistemas
Informticos y Computacin. Universidad Politcnica de Valencia.
Introduccin al proceso software personal. Watts Humphrey, Addison Wesley
Carnegie Mellon University. What is PSP? http://www.sei.cmu.edu/tsp/psp.html