Reporte de Proyecto Final
PROYECTO DE INVESTIGACIÓN
DESARROLLO DE SISTEMAS DE SOFTWARE
CON PSP Y TSP.
DATOS GENERALES Y MATRÍCULA DEL
PRESTADOR.
Nombre: Luis Alberto Díaz Hernández.
Matricula: 209216189.
NOMBRE Y CARGO DEL ASESOR.
Ing. Luis Fernando Castro Careaga.
Profesor del Departamento de Ing. Eléctrica.
Reporte de Proyecto Final
Página 2
Reporte de Proyecto Final
Página 3
Contenido INTRODUCCIÓN: ........................................................................................................................ 5
OBJETIVOS: ................................................................................................................................. 6
DESARROLLO (Tareas y Resultados): ......................................................................................... 7
Análisis de la exactitud de la estimación de tamaño ........................................................................ 7
¿Qué tan frecuentemente estuvo mi tamaño real del programa dentro de mi intervalo estadístico de
predicción del 70%? ....................................................................................................................... 7
¿Tengo una tendencia a agregar/no considerar objetos completos? ............................................. 8
¿Tengo una tendencia a juzgar equivocadamente el tamaño relativo de los objetos? .................... 8
Tarea 3 ................................................................................................................................... 8
Tarea 4 ................................................................................................................................... 9
Tarea 5 ................................................................................................................................... 9
Tarea 6 .................................................................................................................................. 10
¿Necesito calcular el rango relativo usando mis datos de objetos históricos? .............................. 10
¿Puedo? .................................................................................................................................... 10
Basado en mis datos históricos de exactitud de estimación de tamaño, ¿cuál es una meta de
estimación de tamaño realista para mí? ...................................................................................... 10
¿Cómo puedo modificar mi proceso para cumplir la meta? ......................................................... 11
Análisis de la exactitud de estimación de tiempo ............................................................................ 11
Error de estimación de tiempo ................................................................................................ 11
¿Mi productividad es estable? ¿Por qué si o por qué no? ............................................................ 12
Productividad vs Rendimiento ............................................................................................... 12
¿Cómo puedo estabilizar mi productividad? .............................................................................. 13
¿Cuánto están mis estimados de tiempo afectados por la exactitud de mis estimados de tamaño?
(¿La regresión lineal me ayudaría?) ........................................................................................... 13
Basado en mis datos históricos de exactitud de estimación de tiempo, ¿cuál es una meta de
estimación realista para mí? ...................................................................................................... 16
¿Cómo puedo modificar mi proceso para cumplir esa meta? ...................................................... 16
Análisis de defectos de rendimiento .............................................................................................. 17
¿Qué tipo de defectos introduzco durante el diseño y la modificación? ...................................... 17
¿Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g., KLOC) encontrados
en las revisiones, compilaciones y pruebas? ............................................................................... 17
¿Qué tendencias son aparentes en los defectos totales por unidad de tamaño? ............................ 18
Reporte de Proyecto Final
Página 4
¿Cómo mis tasas de eliminación de defectos (defectos eliminados/hora) se comparan para la
revisión de diseño, revisión de código, compilación y pruebas? ................................................. 19
Tazas de eliminación de defectos (Defectos eliminados/hora) ................................................ 19
¿Cuáles son mis tasas de revisión (tamaño revisado/hora) para la revisión de diseño y revisión de
código? .................................................................................................................................... 20
Taza de Revisión de diseño vs. Rendimiento de revisión de diseño ....................................... 20
Taza de revisión de codificación vs. Rendimiento de revisión de codificación. ....................... 21
¿Cuáles son mis influencias de eliminación de defectos para la revisión de diseño, revisión de
código y compilación contra las pruebas unitarias? .................................................................... 22
¿Hay alguna relación entre el rendimiento y la tasa de revisión (tamaño revisado/hora) para las
revisiones de diseño y código? .................................................................................................. 23
Análisis de calidad ........................................................................................................................ 23
¿Cómo puedo juzgar la calidad de mi producto final de manera temprana en mi ciclo de
desarrollo? ................................................................................................................................ 23
¿Estoy encontrando mis defectos en las revisiones de diseño y código? ¿Por qué si o por qué no?
................................................................................................................................................. 23
¿Cómo puedo hacer más efectivo y eficiente mi proceso? .......................................................... 23
Basado en mis datos históricos, ¿cuáles son algunas de las metas realistas para mí? ................... 23
Bitácora de registro de tiempo ....................................................................................................... 25
CONCLUSIÓN: .......................................................................................................................... 26
BIBLIOGRAFÍA: ........................................................................................................................ 26
Reporte de Proyecto Final
Página 5
INTRODUCCIÓN:
El desarrollo de sistemas de software es una actividad de alta complejidad técnica y de
organización de recursos humanos. Para maximizar las probabilidades de éxito de los
proyectos de desarrollo es necesario contar con equipos de desarrolladores entrenados,
formar equipos eficaces y un compromiso con la calidad en el trabajo. La estrategia de PSP
y TSP proporcionan estos elementos. En este Proyecto de Investigación, se pretende la
formación de un equipo de alto rendimiento mediante una capacitación sobre PSP.
PSP es una alternativa dirigida a los ingenieros de sistemas, que les permite mejorar la
forma en la que construyen software. Considerando aspectos como la planeación, calidad,
estimación de costos y productividad, PSP es una metodología que vale la pena revisar
cuando el ingeniero de software está interesado en aumentar la calidad de los productos de
software que desarrolla dentro de un contexto de trabajo individual.
En PSP todas las tareas y actividades que el ingeniero de software debe realizar durante el
proceso de desarrollo de un producto de software, están puntualmente definidas en un
conjunto de documentos conocidos como scripts. Los scripts son el punto medular de PSP,
por lo que se hace mucho énfasis en que deben ser seguidos en forma disciplinada, ya que
de ello dependerá el éxito de la mejora que se busca. Gran parte de las tareas y actividades
definidas en los scripts generará en su realización un conjunto de datos, fundamentalmente
de carácter estadístico. La aplicación de PSP en varios procesos de desarrollo, y el análisis
de la información estadística generada en cada uno de éstos, permitirán al ingeniero de
software identificar, tanto sus fortalezas como sus debilidades, y crecer a través de un
proceso de auto aprendizaje y auto mejora.
Reporte de Proyecto Final
Página 6
OBJETIVOS:
Este proyecto se decidió desarrollar para proporcionarles a los alumnos contacto con
procesos de software de clase mundial y que los alumnos sean agentes de cambio en la
industria al momento que se desempeñen como profesionistas.
También para poder hacer una evaluación objetiva de las mejores prácticas relacionadas
con proyectos de software.
Al final del curso el alumno:
Conocerá de manera formal un proceso de desarrollo software a nivel personal.
o Conocerá el Proceso Personal de Software
o Podrá caracterizar su proceso personal que hacía antes del PSP
o Será capaz de usar métodos formales para hacer planeación
o Será capaz de administrar la calidad de productos de programación
o Será capaz de mejorar su proceso de manera cuantitativa
Será capaz de medir y analizar su desempeño a nivel personal
o Será capaz de medir y analizar su desempeño de tiempo, tamaño y defectos
o Será capaz de medir y analizar su desempeño de productividad
o Será capaz de medir y analizar su desempeño de la calidad de su estimación de esfuerzo
Será capaz de proponer e implementar mejoras a su proceso de software.
o Será capaz de proponer mejoras para ajustar formas, procedimientos, guiones, o cualquier
otro elemento del proceso
o Será capaz de medir y analizar el impacto de las mejoras al proceso de software.
Conocerá de manera formal un proceso de desarrollo software a nivel personal.
o Conocerá el Proceso Personal de Software
o Podrá caracterizar su proceso personal que hacía antes del PSP
o Será capaz de usar métodos formales para hacer planeación
o Será capaz de administrar la calidad de productos de programación
o Será capaz de mejorar su proceso de manera cuantitativa
Será capaz de medir y analizar su desempeño a nivel personal
o Será capaz de medir y analizar su desempeño de tiempo, tamaño y defectos
o Será capaz de medir y analizar su desempeño de productividad
o Será capaz de medir y analizar su desempeño de la calidad de su estimación de esfuerzo
Será capaz de proponer e implementar mejoras a su proceso de software.
o Será capaz de proponer mejoras para ajustar formas, procedimientos, guiones, o cualquier
otro elemento del proceso
o Será capaz de medir y analizar el impacto de las mejoras al proceso de software.
Reporte de Proyecto Final
Página 7
DESARROLLO (Tareas y Resultados):
Análisis de la exactitud de la estimación de tamaño
¿Qué tan frecuentemente estuvo mi tamaño real del programa dentro de
mi intervalo estadístico de predicción del 70%?
Se podría indicar que al realizar las primeras tareas, se tuvo una muy alta sobreestimación,
dado que no se conocía por completo los requisitos, y las complicaciones que traería
escribir código sin margen de error, en las tareas finales se corrigieron estas estimaciones,
se aprendió a estimar tamaños de programas, módulos y el tiempo que tardaríamos al
realizar cada tarea en específico, logrando un valor absoluto que se acercaba al eje del
error en 0%.
En la tabla anterior podemos observar el valor porcentual de error en la estimación con
respecto al tamaño previsto de la tarea. Con forme se fue avanzando en la realización de las
tareas, el error fue aumentando, y con la ayuda de las mejores prácticas adquiridas con la
Reporte de Proyecto Final
Página 8
metodología PSP, se obtuvo un valor positivo. En la tarea 1 no se muestra un valor de
estimación, ya que en ésta no se realizó dicho ejercicio.
¿Tengo una tendencia a agregar/no considerar objetos completos?
En la elaboración de la planeación de cada programa, pude planificar cada vez de mejor
manera los elementos necesarios que se requerían para el cumplimiento de dicha tarea. Sin
embargo, en el desarrollo del sistema, me faltaban elementos que no se contemplaban,
provocando errores que se resolvían hasta la compilación del sistema y sus respectivas
pruebas.
La tendencia en la que me veo inclinado sería en la de no considerar los objetos como
completos.
¿Tengo una tendencia a juzgar equivocadamente el tamaño relativo de los
objetos?
Tarea 3
En la tarea 3, existió una sobreestimación del módulo principal, en el cual se esperaba que
se realizaran más instrucciones, pero eso rompió con el encapsulamiento de código,
generando así un módulo principal más especializado en coordinar las tareas que en realizar
otras actividades. En contraparte, se esperaba un módulo de despliegue pequeño, pues solo
iba a presentar los resultados. El crecimiento se debió a que parte de esa presentación debía
llevar una formato especifico de despliegue, lo cual produjo un cambio en el tamaño. En
general, ambos módulos se compensaron, teniendo un pequeño error de 4 LOCs, lo cual es
una predicción aceptable con respecto a la realidad.
Reporte de Proyecto Final
Página 9
Tarea 4
En la tarea 4, se subestimó el módulo principal, debido al parentesco con la tarea anterior,
cosa que afecto en la predicción. Con respecto al módulo de los cálculos, se llevó una
predicción muy cercana a la realidad, teniendo un error de estimación de 93.34%, el cual se
encuentra dentro del rango aceptable de error, que es 70%. De nueva cuenta, se sobreestimó
el módulo de Despliegue de resultados, esta vez por poco más del triple de lo que realmente
iba a presentarse, debido a que solo se tenía que presentar unos cuantos resultados. Con
respecto a los datos, también existió una mala predicción, al sobreestimar el módulo,
llevándolo al 33.94% de certeza, la cual es una mala medida. Este error fue generado
gracias a que se había planteado una técnica mejor de guardar los datos, cosa que llevó
menos LOCs de lo que se esperaba.
Tarea 5
En la tarea 5, se pudo apreciar una disminución de código nuevo generado, el cual fueron
pequeños módulos, en el cual su predicción estuvo cerca de ser acertada. En total, los
módulos generados crearon una compensación tal, que la predicción fue de 83.34%, el cual
se encuentra dentro de los rangos aceptados.
Reporte de Proyecto Final
Página 10
Tarea 6
En la última tarea, se sobreestimo de mala manera el módulo de cálculos, pues como
realizaba muchos cálculos nuevos, o determinados de otros módulos pasados, pero no se
requerían gran parte de todo el contenido de los otros módulos, se optó por generar una
nueva clase que realizara el trabajo. Por otro lado, se realizó un nuevo módulo del manejo
de los datos, el cual no se tenía contemplado, provocando una compensación suficiente para
que la predicción de tamaño del sistema tuviera el valor de 98.59%, lo cual se acerca
fuertemente a una predicción perfecta. El problema aquí, es que no debía de haber pasado
la mala predicción de estos módulos, los cuales reflejan una inexperiencia en el uso de este
método, para sistemas grandes.
¿Necesito calcular el rango relativo usando mis datos de objetos
históricos?
Claro, pues los datos que se van obteniendo con la realización de las distintas tareas, nos
dan una relación en cuanto a nuestro avance y predicción de las tareas futuras, que cuenten
con características parecidas con tareas anteriormente realizadas.
¿Puedo?
Si se puede, ya que uno puede obtener los datos necesarios con los trabajos que se vayan
realizando y capturar el tiempo y tamaño de los sistemas, haciendo cada vez más grandes y
precisas las predicciones de futuras tareas.
Basado en mis datos históricos de exactitud de estimación de tamaño,
¿cuál es una meta de estimación de tamaño realista para mí?
La tarea número 4, ya que cuenta con la predicción más precisa con respecto a la realidad
obtenida al final de la realización de la misma.
Reporte de Proyecto Final
Página 11
¿Cómo puedo modificar mi proceso para cumplir la meta?
Basándome en la experiencia obtenida en las tareas realizadas, puedo aprender de los
errores cometidos y realizar una mejor predicción de las tareas futuras, así como seguir
capturando los datos y hacer más grande y precisa mi forma de pronosticar los tiempos y
tamaños de los sistemas.
Análisis de la exactitud de estimación de tiempo
Error de estimación de tiempo
Tarea Error
Tarea 1 64.30%
Tarea 2 124%
Tarea 3 -3.62%
Tarea 4 -43.60%
Tarea 5 -3.05%
Tarea 6 -22.1%
Reporte de Proyecto Final
Página 12
Me puedo dar cuenta que las tareas cada vez fueron mejor estimadas en algunas ocasiones
que en otras, debido a la cantidad de código nuevo que se agregó a la tarea, pues es más
preciso calcular sistemas que no se requieren hacer cambios importantes, que sistemas en
las que se requieren realizar procesos nuevos y pesados.
¿Mi productividad es estable? ¿Por qué si o por qué no?
Productividad vs Rendimiento
Tarea Rendimiento Productividad (LOC/Hr)
Tarea 1 17.00% 0
Tarea 2 0.00% 27.2
Tarea 3 0.00% 18.9
Tarea 4 0.00% 33.6
Tarea 5 0.00% 20.8
Tarea 6 47.20% 32.7
Reporte de Proyecto Final
Página 13
En la tabla puede verse que la productividad va aumentando con respecto al avance de las
tareas, logrando el cumplimiento del proceso de forma correcta.
¿Cómo puedo estabilizar mi productividad?
Realizando una mejor predicción de tiempos, así como estudiar las herramientas en las
cuales se piensa desarrollar, para poder realizar de una manera más rápida el desarrollo de
sistemas.
¿Cuánto están mis estimados de tiempo afectados por la exactitud de mis
estimados de tamaño? (¿La regresión lineal me ayudaría?)
Tarea 1
Tarea 2
Reporte de Proyecto Final
Página 14
Tarea 3
Tarea 4
Reporte de Proyecto Final
Página 15
Tarea 5
Tarea 6
Las tablas reflejan los valores que se observaron en la gráfica de error de tiempo, en el cual
se fue pronosticando entre tareas de una mejor manera, logrando así un mejor control en el
proceso de desarrollo de cada sistema.
En ocasiones, el tiempo entre cada capa del proceso de desarrollo se vio alterado en
medida, pero se compensaba con el tiempo de desarrollo de las capas subsecuentes.
Reporte de Proyecto Final
Página 16
Basado en mis datos históricos de exactitud de estimación de tiempo,
¿cuál es una meta de estimación realista para mí?
Se puede observar en la gráfica, que el error de estimación fue más grave en la segunda
tarea, provocando algo de inestabilidad en la obtención de los promedios, pero regresando
al equilibrio en las dos tareas siguientes, logrando una mejor estimación y cálculo en la
previsión de estos. Con respecto a la realización de las tareas, se logró una mejor
aproximación en las tareas 3 y 5.
¿Cómo puedo modificar mi proceso para cumplir esa meta?
Calculando la cantidad de LOCs por programa requerido, basándome en la información
obtenida históricamente de tareas anteriores, y teniendo una biblioteca de ejemplos que me
ayuden a realizar una mejor investigación de la solución que se busca resolver del sistema.
Reporte de Proyecto Final
Página 17
Análisis de defectos de rendimiento
¿Qué tipo de defectos introduzco durante el diseño y la modificación?
La tabla anterior nos muestra que la mayor cantidad de defectos que se han dado
históricamente son de tipo asignación, interface y sintaxis.
¿Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g.,
KLOC) encontrados en las revisiones, compilaciones y pruebas?
Reporte de Proyecto Final
Página 18
Se observa que con el paso de cada desarrollo de las tareas, al llevar a cabo los procesos
indicados por PSP, existe una notable disminución en el tiempo de compilación a 0 en 2 de
las últimas tareas, así como una disminución de los errores cometidos por las revisiones que
mostraban errores antes de pasar a la siguiente capa en el desarrollo de las tareas.
¿Qué tendencias son aparentes en los defectos totales por unidad de
tamaño?
Se puede observar que la cantidad de defectos por unidad de tamaño se vieron realmente
disminuidos en dos de las últimas 3 tareas. En la última tarea, aumentó la cantidad de
errores, por la demanda de código nuevo en la que se escribió.
Reporte de Proyecto Final
Página 19
¿Cómo mis tasas de eliminación de defectos (defectos eliminados/hora) se
comparan para la revisión de diseño, revisión de código, compilación y
pruebas?
Tazas de eliminación de defectos (Defectos eliminados/hora)
Reporte de Proyecto Final
Página 20
Se puede observar tanto en la tabla de valores como en la gráfica, que la mayor cantidad de
errores encontrados fueron en la fase de compilación. Se puede concluir que la fase de
revisión de diseño y código no se realizó correctamente, pues se siguieron encontrando gran
cantidad de errores en la fase de compilación y pruebas.
¿Cuáles son mis tasas de revisión (tamaño revisado/hora) para la revisión
de diseño y revisión de código?
Taza de Revisión de diseño vs. Rendimiento de revisión de diseño
Reporte de Proyecto Final
Página 21
Taza de revisión de codificación vs. Rendimiento de revisión de codificación.
Reporte de Proyecto Final
Página 22
¿Cuáles son mis influencias de eliminación de defectos para la revisión de
diseño, revisión de código y compilación contra las pruebas unitarias?
Son por medio de las checklist, en donde se proponen soluciones en donde se encuentran
más errores que hayan costado más en el desarrollo de las tareas.
Reporte de Proyecto Final
Página 23
¿Hay alguna relación entre el rendimiento y la tasa de revisión (tamaño
revisado/hora) para las revisiones de diseño y código?
En las tablas anteriores, se puede ver la disminución de los errores con respecto al análisis
en la revisión de diseño y código, así como técnicas de reutilización, se puede ver un
aumento del rendimiento en el desarrollo de las tareas.
Análisis de calidad
¿Cómo puedo juzgar la calidad de mi producto final de manera temprana
en mi ciclo de desarrollo?
Por la cantidad de errores encontradas en las revisiones, que le dan calidad al producto.
¿Estoy encontrando mis defectos en las revisiones de diseño y código?
¿Por qué si o por qué no?
Si, pues en la última tarea, pude percatarme de unos cuantos errores que pude haber
encontrado en la fase de compilación y pruebas. Sin embargo, estas revisiones no fueron
suficientemente buenas, pues en estas fases si se encontraron muchos errores, y se perdió
tiempo en la resolución de los problemas, disminuyendo el rendimiento de desarrollo de las
tareas.
¿Cómo puedo hacer más efectivo y eficiente mi proceso?
Tomando en cuenta los tipos de errores encontrados en el historial de tareas, y modificando
mis revisiones para que se adapten a las nuevas problemáticas que me sigan apareciendo en
las fases del proceso.
Basado en mis datos históricos, ¿cuáles son algunas de las metas realistas
para mí?
Disminuir el tiempo de compilación y pruebas, además de la realización de más sistemas,
para tener menos errores de desconocimiento de las herramientas de desarrollo. Otro paso
importante, es modificar constantemente las revisiones de diseño y codificación, para
encontrar más tempranamente, errores que nos puedan hacer más lento el proceso de
desarrollo.
Reporte de Proyecto Final
Página 24
¿Cómo puedo cambiar mi proceso para cumplir esas metas?
Tomando real importancia al proceso de revisiones con los checklist, además de realizar un
diseño más detallado para la realización de la tarea, tomando ejemplos de cualquier fuente
en donde se resuelve un problema similar, y adaptarlo a la tarea que se requiere analizar.
Resumen del plan del reporte Final de PSP
Estudiante Luis Alberto Díaz Hernández Fecha
Instructor Luis Fernando Castro Careaga
Datos de tamaño
Objeto Número planeado Número real
Párrafos 20 25
Tablas 10 14
Gráficas 10 8
Estimado de esfuerzo
Objeto Esfuerzo estimado por
objeto
Esfuerzo estimado
Párrafos 4 70
Tablas 2 25
Gráficas 2 25
Total 120
Datos de esfuerzo
Fase Tiempo plan Tiempo real
Planeación 00:45 00:58
Desarrollo 02:45 05:30
Postmortem 00:25 00:10
Reporte de Proyecto Final
Página 25
Bitácora de registro de tiempo
Estudiante Luis Alberto Díaz Hernández Fecha
Fecha Inicio Alto Tiempo de
interrupción
Tiempo
de alta
Fase Comentarios
23 02
2015
9:00 9:58 Planeación Se terminó la planeación, se
estimó la cantidad de
información
23 02
2015
10:00 13:00 2:00 Desarrollo Salida a comer
23 02
2015
15:00 17:30 Desarrollo Resolución de las preguntas
con los datos históricos
contenidos en el Dashboard,
donde se consiguieron las
tablas de los valores y las
gráficas. Se terminó el
desarrollo.
23 02
2015
17:30 17:40 Postmortem Se terminó la documentación
Reporte de Proyecto Final
Página 26
CONCLUSIÓN:
La calidad es algo que se debe lograr en la medida que mejoren los puntos señalados
anteriormente, la reducción de errores inyectados en las diferentes etapas que constituyen el
proceso, así como una mejor estimación de LOC y tiempo son importantes metas a seguir si
quiero mejorar.
En la etapa de planeación debo de poner más atención en los requerimientos, para poder
hacer una mejor planeación, en la etapa de diseño creo debo ser mas especifico en mis
diseños y dejar menos cosas ambiguas, así el tiempo de codificación será menor y los errores
introducidos disminuirán, lo que lleva a un menor tiempo en las fases de compilación y
pruebas.
Puesto que la mayoría de los errores encontrados son de tipo código es de suma
importancia mejorar en esta etapa, prestando una mayor atención en codificar se irán
reduciendo los errores que encontremos en la etapa de revisión y de esta forma mejorar
nuestro rendimiento así mismo la etapa de revisión debe enriquecerse a un mas haciendo un
mayor uso de los checklist para disminuir aun mas los errores que pasan a las siguientes
etapas.
Estos son los puntos donde preste mayor atención para poder crear Software de alta calidad
y poder integrarme a un equipo de desarrollo tomando un papel con alta eficiencia y ética
laboral.
BIBLIOGRAFÍA:
The Personal Software ProcessSM (PSPSM) Body of Knowledge, Version 2.0.