Reporte de Proyecto Final

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.

Página 2

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

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

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.

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.

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

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.

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.

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.

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%

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

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

Página 14 Tarea 3

Tarea 4

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.

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.

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?

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ó.

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)

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

Página 21

Taza de revisión de codificación vs. Rendimiento de revisión de codificación.

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.

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.

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

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

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.