DIVISIÓN DE CIENCIAS BÁSICAS E INGENIERÍA LICENCIATURA EN COMPUTACIÓN REPORTE DE PROYECTO TERMINAL

Transcripción

1 UNIVERSIDAD AUTÓNOMA METROPOLITANA Unidad Iztapalapa DIVISIÓN DE CIENCIAS BÁSICAS E INGENIERÍA LICENCIATURA EN COMPUTACIÓN REPORTE DE PROYECTO TERMINAL PERSONAL SOFTWARE PROCESS (PSP) & TEAM SOFTWARE PROCESS (TSP) Asesor: Luis Fernando Castro Careaga Alumno: Arturo Delgadillo Rivera Matrícula:

2 CONTENIDO 1 PERSONAL SOFTWARE PROCESS (PSP) Qué es PSP? PSP PSP PSP PSP Usando los datos del PSP PSP PSP REPORTE FINAL PSP Análisis de la exactitud de la estimación del tamaño Análisis de la exactitud de estimación del tiempo Análisis de defectos de rendimiento Análisis de calidad TEAM SOFTWARE PROCESS (TSP) Qué es TSP? Estructura del TSP Reporte de lanzamiento del proyecto Descripción de las juntas Junta Junta Junta Junta Junta Junta Junta Junta Junta Postmortem de lanzamiento Seguimiento del proyecto Junta semanal Junta semanal Junta semanal Junta semanal Junta semanal Junta semanal Junta semanal Junta semanal

3 3.4.9 Junta semanal Junta semanal Junta semanal Junta semanal Análisis de tamaño Análisis de tiempo Análisis de defectos Análisis de rendimiento Análisis del proceso CONCLUSIONES PSP TSP

4 1 PERSONAL SOFTWARE PROCESS (PSP) 1.1 Qué es PSP? El software ahora controla la mayoría de los sistemas militares, de negocio y de gobierno. Ejemplo de ello es lo siguiente: Fábricas son manejadas por software. Los productos más avanzados están controlados por software. Las operaciones financieras, administrativas y de negocios son en gran medida ejecutadas por software. El costo, tiempo de desarrollo y calidad del software ahora es un interés crítico de negocio. La calidad de un sistema de software está determinada por la calidad de sus componentes más deficientes; la calidad de un componente de software es gobernada por el individuo que lo desarrolla, esta calidad está involucrada directamente con la calidad del proceso utilizado para desarrollarlo y mantenerlo. La clave para la calidad es la habilidad, compromiso y disciplina de proceso personal individual del desarrollador. El PSP es un proceso personal para desarrollar software o para hacer cualquier otra actividad definida. Proporciona un marco de trabajo de medición y análisis para caracterizar y administrar trabajo personal. El PSP es un proceso diseñado para uso individual, está basado en prácticas de software industriales reducidas. Todo profesional del software es responsable de su proceso personal por lo que un buen desarrollador de software debe medir, darle seguimiento y analizar su trabajo, debe aprender a partir de las variaciones de su desempeño. Es necesario comprender la importancia de procesos definidos y medidos para llegar a nuestro objetivo, software de calidad. Para llegar a esta meta, el PSP ofrece un enfoque basado en procedimientos para el desarrollo de Software, muestra como medir y analizar datos tomados a partir del proceso personal, nos guía para poder utilizar la información recopilada y así incrementar nuestro desempeño personal. Cuando se utiliza el PSP de manera adecuada se notará un claro incremento de conocimientos y habilidades enfocadas siempre hacia una mejora de carácter profesional. 4

5 El PSP proporciona: Una base probada para desarrollar y usar un proceso personal de poder industrial Una disciplina que muestra cómo mejorar el proceso personal Datos para mejorar continuamente la productividad, calidad y la predicción del trabajo Para un desarrollador, el PSP es de gran utilidad, lo ayuda para lograr una buena estimación y planeación de su trabajo lo cual tendrá como consecuencia el poder cumplir bien con sus compromisos laborales, además también le permite resistir presiones por compromisos no razonables. Para concluir con esta breve introducción acerca de lo que es PSP y sus beneficios se muestra el flujo del proceso de PSP. Los conceptos utilizados en esta ilustración se verán más a detalle a lo largo de este Reporte. Requerimiento Guiones guía Planeación Diseño Codificación Compilación Bitácoras Pruebas PM Resumen del Proyecto Producto Reporte de resumen de datos del proyecto y del proceso 5

6 1.2 PSP0 En el PSP0 se realiza un plan utilizando los métodos de diseño y desarrollo con los que el alumno cuenta, teniendo como objetivo el poder producir un programa pequeño, para ello es necesario una recolección de datos de tiempo y defectos de su trabajo. El objetivo del PSP0 es demostrar la efectividad del uso de un proceso definido al escribir programas pequeños incorporando medidas básicas en el proceso de desarrollo de software, esto provocará que el desarrollador (en este caso el alumno) paulatinamente realice algunos cambios a sus prácticas personales. El PSP0 tiene seis fases. Planeación: Consiste en la elaboración de un plan para desarrollar el programa definido por los requerimientos. Diseño: Tiene como objetivo la creación de una especificación de diseño para el programa definido por los requerimientos. Codificación: Transforma la especificación de diseño en instrucciones del lenguaje de programación. Compilación: Traduce las instrucciones del lenguaje de programación en código ejecutable. Pruebas: Verifica que el código ejecutable satisface los requerimientos. Post mortem: Resume y analiza los datos del proyecto. El PSP0 es utilizado en la primera tarea y con esto se empieza el aprendizaje sobre recolección de datos y la elaboración de software mediante un proceso definido. 1.3 PSP0.1 Tiene como objetivo el medir el tamaño de los programas elaborados con mediciones de tamaño exactas y precisas. Cuenta con los elementos del PSP0 y se agregan estándares de conteo y codificación. Además se incluye una forma de propuesta de mejora de proceso (PIP) en la cual se describe algún problema en la elaboración del programa y una propuesta para poder solucionar ese problema. El PSP0.1 es utilizado en la segunda tarea incluyendo los estándares de conteo y codificación, además de la forma PIP. 6

7 1.4 PSP1 El objetivo del PSP1 es establecer un procedimiento ordenado para el desarrollo de estimados de tamaño de software. Además de contener a los elementos del PSP0.1 se tiene también una plantilla de reporte de pruebas la cual es utilizada para registrar algún tipo de prueba para comprobar la efectividad del programa, es necesario reportar los tipos de datos que fueron utilizados y cual fue el resultado de la prueba. El PSP1 es utilizado en la tercera tarea, se maneja la plantilla de reporte de pruebas y con ayuda del método PROBE I se realizan estimaciones de tamaño y tiempo. 1.5 PSP1.1 Los objetivos del PSP1.1 son introducir y practicar métodos para hacer planes de recursos y de calendario de trabajo seguir su desempeño contra estos planes juzgar las fechas probables de finalización del proyecto Se utiliza el método PROBE II para poder tener una buena planeación de recursos y un mejor calendario de trabajo, en esta fase se realiza una aproximación de las fechas probables de elaboración de la cuarta tarea. 1.6 Usando los datos del PSP En esta sección se realiza una recopilación de datos generados a partir de las 4 tareas realizadas por el alumno a lo largo del proceso de PSP, esto con el propósito poder analizar e interpretar estos datos y así poder elaborar un reporte intermedio utilizando un guión construido por el alumno, este guión debe contener las fases de planeación, desarrollo y post mortem. A partir de ciertas preguntas que el PSP plantea el alumno puede observar los resultados de su proceso, principalmente en aspectos de aproximación de tamaño y tiempo, productividad y eliminación de defectos. Se dispone de una bitácora de tiempo para registrar las actividades conforme se construye el reporte, también se cuenta con un Resumen del Plan del Reporte Intermedio de PSP para hacer estimados esfuerzo y tamaño con respecto al reporte, por ejemplo Cuántas tablas se utilizarán?, Cuántas gráficas?, etc. Se elaboran las listas de verificación para las revisiones de diseño y código las cuales serán utilizadas en las siguientes actividades del proceso. 7

8 1.7 PSP2 Tiene como principal objetivo el introducir revisiones de diseño y código con ayuda de las listas de verificación para las revisiones de diseño y código las cuales han sido elaboradas con anterioridad. En el PSP2 se introduce la planeación de la calidad, lo cual involucra: Estimar el número total de defectos que serán introducidos Estimar el número de defectos que serán introducidos y eliminados en cada fase del proceso Estimar la cantidad de tiempo necesaria para las revisiones de diseño y código Ajustar estos parámetros conforme sea necesario para asegurar un resultado de alta calidad El PSP2 se utiliza para la elaboración de la quinta tarea. 1.8 PSP2.1 En el PSP2.1 se introducen las plantillas de diseño, las cuales proporcionan un marco de trabajo ordenado, también se proporcionan formatos para registrar los diseños. En esta sección se le recuerda al alumno la importancia de una buena elaboración de diseño para poder llegar a obtener software de calidad y con un número de defectos en verdad mínimo, para la creación del diseño se cuenta con las siguientes plantillas: Plantilla de especificación operacional Plantilla de especificación funcional Plantilla de especificación de estados Plantilla de especificación lógica El PSP2.1 es utilizado en la elaboración de la sexta, séptima y octava tarea. En la última sesión del curso se ofrece una explicación del proceso TSP para poder familiarizarse con él, ya que será utilizado en la siguiente fase. 8

9 2 REPORTE FINAL PSP 2.1 Análisis de la exactitud de la estimación del tamaño Compare el reporte intermedio línea base para la exactitud de estimación de tamaño con los programas posteriores al reporte. Cuánto cambió su exactitud de estimación de tamaño? Por qué? Datos Históricos Programas Tamaño Estimado Tamaño Real Porcentaje Programa % Programa % Programa % Promedio % Datos Actuales Programas Tamaño Estimado Tamaño Real Porcentaje Programa % Programa % Programa % Programa % Promedio 0.96% Porcentaje de la estimación % % 30.11% % % 0.000% 3.365% 4.046% 7.48% % % % % -8.93% % Programa 2 Programa 3 Programa 4 Programa 5 Programa 6 Programa 7 Programa 8 9

10 De acuerdo con los datos encontrados, si se analizan los programas individualmente se puede notar que en algunos programas no tengo una buena estimación de tamaño, como es en el caso de los programas 6 y 8, pero si se toma un promedio de los programas 5 al 8 contra los programas 2 a 4(promedio) se puede observar que si tuve una cierta mejora. Qué tan frecuentemente estuvo mi tamaño real del programa dentro de mi intervalo estadístico de predicción del 70%? Programa LPI UPI Tamaño Real Programa Programa Programa Programa En general estuve dentro del rango a excepción del programa 8 en el que si estuve por encima del rango de predicción. Tengo una tendencia a agregar/no considerar objetos completos? Programa Objetos planeados Objetos reales Programa Programa Programa Programa Se puede decir que ocupo los objetos que he planeado, con base a lo planeado realizo el diseño y es por esto que son similares los objetos planeados y los reales, con excepción del programa 6 que se me hizo una mejor opción el crear otro objeto en base a los requerimientos. 10

11 Tengo una tendencia a juzgar equivocadamente el tamaño relativo de objetos? Programa 5 Programa 6 Programa 7 Programa 8 Objeto Tamaño Planeado Tamaño Real TOTAL TOTAL TOTAL TOTAL En general tuve una buena aproximación del tamaño de los objetos, sin embargo en el programa 6 no estime bien el número de objetos a utilizar aunque no significó gran variación entre el tamaño planeado y el real; El programa 8 es en el que tuve una mala aproximación a pesar de estimar correctamente el número de objetos a utilizar. En general creo que no tengo una tendencia a juzgar mal el tamaño de los objetos. Necesito calcular el rango de tamaño relativo usando mis datos de objeto históricos? Puedo? Dado que la estimación en el tamaño de los objetos no es tan mala considero que no es necesario calcular el rango de tamaño relativo. 11

12 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 mi? Que el número de objetos planeados sea el mismo al real. Que el tamaño estimado de cada objeto sea lo mas cercano posible al real, digamos un 10% de error como máximo. Que el número de métodos utilizados sea el mismo al planeado. Cómo puedo modificar mi proceso para cumplir esa meta? Elaboración de una mejor planeación leyendo cuidadosamente las especificaciones (esto influye mucho en el tamaño planeado), elaborar el diseño a partir de la planeación, en general creo que lo indispensable es el entendimiento de los requerimientos. 12

13 2.2 Análisis de la exactitud de estimación del tiempo Compare el reporte intermedio línea base para la exactitud de estimación de tiempo con los programas posteriores al reporte. Cuánto cambió su exactitud de estimación de tiempo? Por qué? Datos históricos Programas Tiempo Estimado Tiempo Real Porcentaje Programa % Programa % Programa % Programa % Promedio % Datos Actuales Programas Tiempo Estimado Tiempo Real Porcentaje Programa % Programa % Programa % Programa % Promedio % Porcentaje estimación tiempo 20.00% 10.00% 0.00% % % % 1.99% 7.27% 7.78% 2.963% % % % % % % Programa % Programa 2 Programa 3 Programa 4 Programa 5 Programa 6 Programa 7 Programa 8 13

14 Como se puede observar, en los programas 1-4 tuve una subestimación de 9.031%, esto debido a una muy mala estimación en el segundo programa; en los programas 5-8 se aprecia una mejoría, sin embargo también tuve una mala estimación en el programa 8, por lo cual tuve una subestimación promedio de 7.55%. Tuve una mejoría, sin embargo tengo que trabajar un poco más para lograr mejores estimaciones en todos los programas. Qué tan frecuentemente estuvo mi tiempo de desarrollo real dentro de mi intervalo estadístico de predicción del 70%? Programa LPI UPI Tamaño Real Programa Programa Programa Programa Con respecto a los programas 5 y 6 no hay intervalos dado que se trabajo con el método D por lo que no se tienen intervalos de predicción porque los datos son introducidos manualmente; El programa 7 si se encuentra dentro del intervalo de predicción, por el contrario, el programa 8 no está dentro del intervalo, producto de una mala estimación. Mi productividad es estable? Por qué si o por qué no? PROGRAMA LOC HORA LOC/HORA Programa Programa Programa Programa Programa Programa Programa Programa

15 Productividad LOC/HORA Programa 1 Programa 2 Programa 3 Programa 4 Programa 5 Programa 6 Programa 7 Programa 8 Como se puede observar la productividad se ha mantenido estable, con excepción del programa 4 en el que se elevo demasiado el valor, con respecto a los valores actuales (programas 5 al 8) los valores se han mantenido de forma similar. Cómo puedo estabilizar mi productividad? Aunque mi productividad se ha mantenido estable, para poder seguir con esta productividad es necesario realizar un buen proceso de planeación y de diseño, además de realizar una buena estimación como las que he realizado a lo largo del curso de PSP. 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?) Si no se realiza una buena estimación en el número de objetos a realizar y en el tamaño de los mismos es muy probable que los estimados de tiempo también sean equivocados; un ejemplo de esto es lo ocurrido en el programa 8 en el cual la estimación de tamaño influyo en que la estimación de tiempo fuera errónea. La regresión lineal puede ayudarme, sin embargo debo de realizar una mejor estimación de tamaño para obtener mejores resultados. 15

16 Basado en mis datos históricos de exactitud de estimación de tiempo, cuál es una meta de estimación de tiempo realista para mi? Realizar una estimación de tiempo con un 10% de error como máximo. Mantener una buena estimación de tamaño en los programas futuros. Cómo puedo modificar mi proceso para cumplir esa meta? Debo de tener en cuenta todas las estimaciones realizadas con anterioridad para poder tener una mejor en la estimación de tiempo. A pesar de que mi estimación de tiempo no fue tan mala y que aparentemente mis estimaciones fueron muy buenas a partir del programa 5, en el programa 8 tuve una muy mala estimación por lo que es notable que todavía tengo que seguir trabajando para que mis estimaciones sean lo mas cercano posible al valor real. 16

17 2.3 Análisis de defectos de rendimiento Qué tipo de defectos introduzco durante el diseño y la codificación? Programa 5 Programa 6 Programa 7 Programa 8 Errores Asignación Sintaxis TOTAL Diseño Codificación Diseño Codificación Diseño Codificación Diseño Codificación TOTAL Errores cometidos Asignación Sintaxis Numero de errores Diseño Codificación Diseño Codificación Diseño Codificación Diseño Codificación Programa 5 Programa 6 Programa 7 Programa 8 Tipo de error Como se puede observar en diseño cometo solo errores de asignación, mientras que en codificación cometo errores de asignación y de sintaxis, siendo este último el error mas cometido en la fase de codificación. 17

18 Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g., KLOC) encontrados en las revisiones, compilaciones y pruebas? Revisiones Compilación Pruebas Locs Programa Programa Programa Programa Revisiones Compilación Pruebas Programa Programa Programa Programa Defectos/Kloc Revisiones Compilacion Pruebas Programa 5 Programa 6 Programa 7 Programa 8 Como se puede observar en la gráfica, la mayor cantidad de errores se detectan en las revisiones lo cual involucra una menor cantidad de errores en compilación y pruebas; este resultado también refleja una menor cantidad de tiempo en la elaboración del programa. 18

19 Qué tendencias son aparentes en los defectos totales por unidad de tamaño? Defectos totales Programa Programa Programa Programa Defectos totales Programa 5 Programa 6 Programa 7 Programa 8 La tendencia indica una disminución de defectos, con excepción del programa 6 en el que se nota claramente el aumento de los defectos. 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? Revisión de Diseño Revisión de Código Compilación Pruebas Programa Programa Programa Programa

20 Revision de Diseño Revision de Codigo Compilacion Pruebas Los resultados indican que compilación es la fase con mayor eficiencia para la eliminación de defectos, seguida de 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? Como se puede observar las tasas fueron muy similares, sin embargo la tasa de CRR está un poco por encima que las de DLDR, aunque al final tienen un valor muy parecido. 20

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? DLDR/UT CR/UT Comp/UT Programa Programa Programa Programa Total Eliminación de defectos Revision de Diseño Revision de Codigo Compilacion Se puede observar una tendencia de detección de errores en revisión de diseño y de código, por lo que el número de errores en compilación disminuye considerablemente. Además de un mejor trabajo den el diseño la detección de errores en las revisiones son de gran ayuda en la disminución de tiempo en la elaboración del programa. 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? Revisión de Diseño Revisión de Código Rendimiento Programa Programa Programa Programa Promedio Con tasas más bajas de revisión se obtiene un mejor rendimiento, como puede observarse en la tabla. 21

22 Hay una relación entre el rendimiento y A/FR para los programas 5 al 8? Revisión de Diseño Revisión de Código Rendimiento A/F Programa Programa Programa Programa Promedio A/FR = (COQ de apreciación) / (COQ de falla) El costo de fallas en PSP, es el tiempo de compilación y pruebas. El costo de apreciación en PSP es el tiempo de las revisiones de diseño y código. Una A/FR alta está asociada con números bajos de defectos en pruebas y alta calidad de producto. Como puede observarse con un mayor rendimiento se obtiene un mayor número de A/F, este resultado es debido a que el costo de apreciación involucra el tiempo en revisiones de diseño y código los cuales están relacionados con el rendimiento. 22

23 2.4 Análisis de calidad Compare el reporte intermedio de base para la calidad en las pruebas unitarias con los programas posteriores al reporte. Cuánto cambió la calidad de los programas entrando a las pruebas unitarias? Por qué? Programas Defectos Pruebas Programa 1 4 Programa 2 3 Programa 3 3 Programa 4 2 Total 12 Programa 5 3 Programa 6 1 Programa 7 1 Programa 8 1 Total 6 Errores en UT Final 33% Intermedio 67% Observando la gráfica y la tabla se puede apreciar una baja notable en cuanto a la disminución de defectos, ya que en los programas del 1 al 4 el total de errores es de 12, mientras que en los programas 5 al 8 es de 6; al disminuir el número de errores se obtiene una mejor calidad en los programas, el tiempo es menor y la productividad se eleva. Las revisiones fueron un punto importante para llegar a este resultado además de que realizaba un mejor trabajo en los diseños. 23

24 Cómo puedo juzgar la calidad de mi producto final de manera temprana en mi ciclo de desarrollo? Al corregir una mayor cantidad de errores antes de la compilación, le estamos dando al programa una mayor calidad ya que provocamos que el número de errores posteriores a la compilación se reduzca considerablemente. Para poder llegar a un número muy pequeño de errores posteriores a la compilación es necesario realizar las revisiones ya que considero que son indispensables para evitar la fuga de defectos. El encontrar los errores tempranamente incrementa la posibilidad de llegar a un programa con calidad; de otra manera podrían resultar muy costosos los errores. Estoy encontrando mis defectos en las revisiones de diseño y código? Por qué si o por qué no? Programas DLDR CR UT Programa Programa Programa Programa Total UT 22% Detección defectos DLDR 41% CR 37% Como se puede observar el mayor número de defectos son encontrados en las revisiones, sobre todo en revisiones de diseño. Creo que es muy importante que los defectos sean encontrados en esas fases ya que es mejor encontrarlos tempranamente para poder ofrecer un programa con mejor calidad y en mejor tiempo. 24

25 Cómo puedo hacer más efectivo y eficiente mi proceso? Analizando muy bien los requisitos de programa que desarrollaré, de este punto es del que se desprende una buena planeación. Realizar un buen diseño en base a lo planeado y ejecutar una buena revisión del diseño. Codificar siguiendo el diseño; es indispensable conocer muy bien el lenguaje en el que se codificará ya que se saca un mejor provecho al conocer las distintas herramientas que nos puede ofrecer el lenguaje que utilicemos; realizar una buena revisión ya que suele suceder que al pasar de diseño a código quizá se cambie un poco la estructura y con la revisión podemos rectificar esa estructura. Creo que si puedo cubrir esto y mantenerlo puedo realizar programas de muy buena calidad. Basado en mis datos históricos, cuáles son algunas metas de calidad realistas para mi? Encontrar todos los defectos hasta antes de la compilación, lo que representaría también el tener cero defectos en UT. Reducir el número de defectos de sintaxis y asignación a 0. Cómo puedo cambiar mi proceso para cumplir esas metas? Realizando una buena planeación y un buen diseño tendré una base de calidad para elaborar el programa, es necesario que el diseño esté basado en lo planeado y tomando en cuenta cumplir con todos los requisitos del sistema; en cuanto a las revisiones es necesario que se cumpla con más determinación para asegurarme de que el diseño si sea el indicado. Al momento de codificar tengo que tener una mejor concentración para que los errores de sintaxis y asignación se reduzcan 0. La revisión de codificación también debe de ser realizada con más empeño para poder eliminar todos los errores y así poder llegar al objetivo de 0 defectos en UT. 25

26 3 TEAM SOFTWARE PROCESS (TSP) 3.1 Qué es TSP? En la actualidad muchas vidas y negocios dependen del software, necesitamos sistemas de software más grandes, más complejos y más seguros en tiempos predecibles, sin prácticas de software diferentes, esto no sucederá. Existen distintos factores que provocan que la construcción de software se estanque o no se cumpla con las expectativas que se tenían, principalmente por una mala administración en la construcción del sistema, sin tomar en cuenta que mientras más grande sea el proyecto será más difícil de controlar. Los problemas empeoran con el tamaño del proyecto. En los sistemas de software, si alguna parte tiene problemas de calidad, el sistema tendrá problemas de calidad. Si los desarrolladores no administran la calidad, sus equipos no pueden administrar calidad. La calidad siempre será pobre, cuando no se administra. Otro factor importante es la eficacia del equipo que construye el software, los equipos exitosos son tanto satisfactorios como escasos. Aunque muchos equipos se acercan bastante a cumplir con sus objetivos de producto y de negocio, con frecuencia lo hacen así por el desgaste del equipo. Algunos de los puntos que debe de tener un equipo efectivo son los siguientes: Tiene una ética, una actitud y una energía que se refleja en todo lo que hacen. Los compañeros de equipo apoyan unos a otros Ellos intuitivamente saben cuándo y cómo ayudar. Ellos se reunirán en el momento justo Los miembros son parte de un esfuerzo común. Ellos tienen un sentido de pertenencia y sentimiento de camaradería. El Team Software Process (TSP) pretende establecer nuevas prácticas en la construcción de sistemas de software. El TSP proporciona el conocimiento y habilidad que los desarrolladores necesitan para trabajar en equipo. Uno de sus principales objetivos es construir y mantener equipos consolidados. El TSP es un marco de trabajo y una estructura de proceso para construir y guiar los equipos de ingeniería. 26

27 El TSP contiene Un proceso de construcción de equipo que construye metas compartidas, compromisos compartidos y cohesión Un proceso de un equipo trabajando que guía los procesos y prácticas de ingeniería del equipo Un prerrequisito de los equipo TSP es dominar la ingeniería de software y las habilidades de procesos impartidos en el curso de PSP. PSP Construcción de habilidades Mediciones personales Disciplina de proceso Estimación y planeación Administración de la calidad Miembros del Equipo TSP Construcción equipos Objetivos del proyecto Roles del equipo Proceso del equipo Plan del proyecto Plan balanceado Disciplina del equipo TSP Trabajo en equipo Comunicación del equipo Coordinación del equipo Seguimiento del estatus Análisis del riesgo Reporteo del proyecto Administración del equipo Equipos de Producto Integrados El TSP establece un ambiente que construye, desarrolla, y apoya el trabajo en equipo autodirigido. Un equipo autodirigido Define sus propias metas Establece sus propios roles Decide sobre su propia estrategia de desarrollo Define sus propios procesos Desarrolla sus propios planes Mide, administra y controla su propio trabajo Los equipos autodirigidos son equipos consolidados y ellos hacen el mejor trabajo. 27

28 3.2 Estructura del TSP El desarrollo del TSP consta de 6 etapas: Lanzamiento, Requerimientos, Diseño de Alto Nivel, Implementación, Integración y Pruebas, Postmortem; estas distintas fases que conforman el proceso de TSP serán descritas a continuación. Lanzamiento En este punto se asignan los roles del equipo, se definen métricas de calidad, se definen los objetivos del equipo así como los de la dirección y del cliente, mejoras al proceso, se realiza la planeación del proyecto. En esta etapa se llevan a cabo 9 juntas que tienen como objetivo analizar y construir la información necesaria para ofrecer una solución de software a un problema específico. Los objetivos principales a definir en estas juntas son: Revisión de objetivos a perseguir Asignación de equipos y roles a perseguir Se describen las necesidades del cliente Se establecen las metas individuales y del equipo Requerimientos En esta fase se identifican todos los requerimientos del sistema mediante entrevistas plasmadas en documentos, estos servirán como referencia para crear una arquitectura y un diseño. Todo documento será inspeccionado por un grupo del equipo asignado para esta tarea. En esta etapa se realizan las pruebas del sistema. Los principales requerimientos a seguir son: Se analizan las necesidades del cliente y se entrevistan Se especifican los requerimientos Se hace inspección de los requerimientos Se diseña un plan de pruebas del sistema 28

29 Diseño de alto nivel En esta etapa se define una arquitectura así como el diseño de alto nivel de los módulos encontrados para el sistema. Se crea el diseño de alto nivel y se inspeccionan los documentos, también se crean las pruebas de integración. Los principales objetivos a cubrir son: Se crea un diseño de alto nivel Se especifica el diseño Se revisa el diseño Se inspecciona el diseño Se desarrolla un plan de pruebas de integración Implementación En esta fase se desarrollan las técnicas, métricas y estándares usados en el PSP, en esta fase se crea el diseño detallado, y se procede a la codificación; todo esto se realiza con la ayuda de estándares y revisiones. Se comprende las siguientes fases: Se usa PSP para implementar módulos y unidades Se convierte el DLD a código Se inspecciona el código Integración y pruebas. Etapa en la cual se realizan las pruebas desde unitarias, pasando por las pruebas de integración, y si el sistema lo requiere se realizan las pruebas de sistema. Post Mortem Esta etapa es la que funciona para recopilar las metas y saber si se obtuvieron los resultados deseados, en esta fase se hacen los ajustes de mejora del proceso para el siguiente proyecto de desarrollo y se producen evaluaciones del equipo. 29

30 3.3 Reporte de lanzamiento del proyecto Descripción de las juntas Como se mencionó anteriormente, para llegar a una planeación correcta de proyecto, en el TSP son necesarias 9 juntas para lograr un lanzamiento de proyecto exitoso. Cada junta TSP tiene roles, una agenda y un reporte de la junta. Los roles de la junta son moderador: encabeza la junta facilitador/cronometrista - ayuda al equipo a seguir la agenda y el guión - sigue y anota los tiempos de la agenda anotador - registra todas las decisiones importantes (qué y quién) y acciones planeadas (qué, quién, cuándo) - verifica las acciones y decisiones con los asistentes de la junta al final de la misma Cada junta TSP debe tener una agenda que describe el propósito de la junta enlista a los asistentes proporciona los temas y sus tiempos planeados nombra al líder de la discusión El reporte de la junta debe ser breve, es necesario listar las decisiones clave y las conclusiones, además de registrar todas las acciones planeadas Concluyendo las juntas satisfactoriamente podemos llegar a nuestro primer objetivo en el desarrollo del proceso de TSP, el lanzamiento. El lanzamiento establece un entendimiento común del equipo acerca del proyecto, en el se definen: Metas de la dirección para el proyecto Las metas del equipo y metas de los miembros del equipo Procesos que el equipo utilizará Roles que los miembros del equipo realizarán El trabajo de desarrollo a ser realizado Plan para hacer el trabajo Sistema de reporte a la dirección y al cliente Proceso de comunicación del equipo funcionando 30

31 3.3.2 Junta 1 La junta 1 proporciona a los miembros del equipo (desarrolladores del sistema) la información necesaria para producir su plan. Esta junta fue guiada por el Coach, estuvieron presentes todos los miembros del equipo incluyendo el líder, y la alta dirección (el cliente o representante del cliente) El principal objetivo de esta junta es que la alta dirección de a conocer: Lo que ellos desean que el equipo desarrolle Cuando se necesita el producto Los recursos disponibles para el equipo La flexibilidad del equipo Por qué el trabajo es importante Cómo la dirección medirá el éxito La dirección usualmente describe los productos necesarios y los tiempos en que se requieren. El equipo debe entender las verdaderas necesidades de la dirección para resolverlas. No implica que se piense que los objetivos de la dirección no son realistas. La actitud debería ser: si eso es lo que la dirección quiere, nosotros haremos nuestro máximo para hacerlo. En esta junta es necesario que el equipo realice suficientes preguntas para poder entender las necesidades de la dirección Junta 2 El principal objetivo de esta junta es que el equipo defina sus metas y seleccione sus roles. El equipo parte de las metas que estableció la dirección en la junta de apertura. revisa y refina estas metas agrega metas específicas del equipo se obtiene un acuerdo sobre las metas del equipo El equipo divide los roles de administración del equipo de tal forma que cada miembro tenga una responsabilidad de rol. 31

32 Los roles son los siguientes Administrador de la interfaz con el cliente es el punto focal para aspectos de requerimientos y relacionados con el cliente. Administrador de diseño establece los estándares de diseño y guía el trabajo de diseño. Administrador de implementación define los estándares de implementación y maneja los aspectos de implementación. Administrador de pruebas asegura que las situaciones de pruebas sean consideradas apropiadamente y maneja la planeación y coordinación de las pruebas. Administrador de planeación ayuda al equipo a mantener, seguir y reportar el plan y el estado del plan. Administrador de procesos guía el trabajo de definición de procesos, maneja los PIPs y revisa los datos del proceso. Administrador de calidad revisa la calidad del proceso y del producto y está pendiente de las inspecciones. Administrador de apoyo asegura que las herramientas de apoyo y ayudas apropiadas estén disponibles y maneja situaciones de apoyo El líder del equipo por lo regular no toma ningún rol del equipo, sin embargo en algunos casos si puede tomar algún otro rol, además del desarrollo del software. En el caso de nuestro sistema el líder sólo tuvo que desempeñar su rol de líder y además ser desarrollador. Las responsabilidades del líder del equipo son Dar liderazgo al equipo sostener la motivación, priorizar el trabajo, guiar a los miembros del equipo. Mantener la comunicación del equipo tener juntas semanales y comunicar a la dirección necesidades y acciones. Obtener recursos obtener el número de integrantes necesarios y proteger a los miembros del equipo de demandas no proyectadas. Reportar a la dirección informar a la dirección acerca del avance y situaciones del equipo y obtiene ayuda cuando es necesario. 32

33 Antes de comenzar, es necesario mencionar a los integrantes del equipo: Miembros del equipo Integrante Adriana Rojas Eduardo Andrés Olivia Ortega Martín Chacón Alfonso Alcántara Eduardo Ayala Miguel Ángel Álvarez Miguel Ramírez Arturo Delgadillo Pavel Rosales Iniciales AR EA OO MC AA EDW MAA MR AD PR Estos son los resultados de esta junta: Asignación de roles Rol Responsable Suplente Líder de equipo Pavel Rosales Adriana Rojas Administrador de la interfaz con el cliente Olivia Ortega Martín Chacón Administrador de diseño Alfonso Alcántara Eduardo Andrés Administrador de implementación Eduardo Ayala Arturo Delgadillo Administrador de planeación Miguel Ramírez Eduardo Ayala Administrador de procesos Adriana Rojas Miguel Ramírez Administrador de calidad Miguel Ángel Álvarez Olivia Ortega Administrador de apoyo Martín Chacón Adriana Rojas Administrador de pruebas Administrador de base de datos Arturo Delgadillo Eduardo Andrés Miguel Ángel Álvarez Alfonso Alcántara Nota: El administrador de base de datos fue propuesto por el equipo, esto debido a la dificultad para controlar la administración relacionada con las base de datos, principalmente con la estructura de la base, implementación y e/s de la información a la base. 33

34 Metas explicitas de la dirección Responsable Meta Medida Responsable Tiempo Dirección Aumentar los beneficios del programa del GDF OO Con cada Iteración Dirección Dirección Tener un prototipo para enero Reducir al máximo el efecto contraproducente de las recetas En un Sist. Op. y navegador definidos. En un 15% MC OO Con cada Iteración En la última iteración Dirección Cumplimiento de la lista de enfermedades. OO En cada iteración Metas implícitas de la dirección Responsable Meta Medida Responsable Tiempo Dirección Crear un sistema amigable OO En cada iteración Dirección Crear un sistema seguro AA En cada iteración Dirección Dirección Dirección El Sistema debe manejar un número limitado de alertas Entregar un demo con Calidad Confiabilidad (consistencia y completitud en los datos) Usar las métricas del TCP OO MA EA En cada iteración En cada iteración En cada iteración 34

35 Metas de mercadotecnia Responsable Meta Medida Responsable Tiempo Mercadotecnia Movilidad Acceso vía Web EDW Mercadotecnia Disponibilidad 24h AA En cada iteración En cada iteración Metas de Equipo Meta Responsable Tiempo Integración del equipo de diez personas (minimizar conflictos, maximizar la comunicación) PR Semanalmente Experimentar el Proceso TSP AR Semanalmente Experimentar un proceso ágil (Extreme Programming ) Apegarse a la descripción de los Roles AR AR Semanalmente Semanalmente Respetar horarios de trabajo PR Semanalmente Cubrir la mayor parte de los requerimientos para enero. MR Semanalmente Junta 3 En esta junta los miembros del equipo definen el producto que construirán y como lo realizarán. El equipo visualiza el proyecto desde varias perspectivas: Diseño conceptual y estimación del tamaño Lista de todos los productos que deben ser generados Estrategia para cumplir las metas del equipo Proceso para realizar bien el trabajo Lista de cualquier actividad que deba ser hecha por el equipo 35

36 Estos fueron los resultados obtenidos: Unid de Trab Elementos de Proceso Mod Nue 2 2 Cuando se necesita Inicio 1era Iteración Inicio 1era Iteración Inicio 1era Iteración Inicio 1era Iteración Inicio 1era Horas est. 3 Ingeniero Diseño, Calidad y Planeación Estándar de conteo 2 2 DBA y Pruebas Contador de Locs 60 Implementación y 2 (Java) LOCS Proceso Contador de Locs Implementación y 3 (web) LOCS LOCS Proceso Documento de 25 requerimientos Iteración 10 Interfaz con el Usuario Documento de Inicio 1era 300 Diseño Iteración 30 Diseño Checklist de Inicio 1era revisión de 2 Iteración requerimientos 2 Interfaz con el Usuario Checklist de Inicio 1era inspección de 2 Iteración requerimientos 2 Interfaz con el Usuario Checklist de inspección de Inicio 1era 2 diseño de nivel Iteración 2 Diseño detallado Checklist de Inicio 1era inspección de 2 Iteración codificación 2 Implementación Guía de Inicio 1era 2 Integración Iteración 2 Soporte y proceso Modificar el script Inicio 1era 1 de codificación Iteración 1 Proceso Proceso de Inicio 1era 3 cambios Iteración 3 CCB Totales LOCS LOCS Junta 4 Se tiene como objetivo el construir un plan descendente para todo el trabajo. Además se definen las tareas en secuencia de inicio al final del proyecto. 36

37 El tiempo necesario para cada tarea se estima en base al tamaño y los datos de productividad o directamente sobre experiencias anteriores. Las tareas son programadas basándose en las horas disponibles del equipo. Si el plan descendente parece que no satisface las metas de la dirección, el equipo puede crear algunas propuestas alternativas. Los tiempos y tamaños estimados por el equipo en esta junta fueron: La creación de documentos se estimo en 0.5 Pág. / Hr. Para la revisión de documentos se estimo hacerlo en 1.0 Pág. / Hr. Se determino que la revisión de código y la revisión de diseño detallado se harían en 200 LOC/ Hr. Así mismo se estimaron los recursos generales requeridos, se determinaron los recursos disponibles por semana y se generaron y reviso el plan general del equipo Junta 5 Esta junta es para determinar un plan de calidad. Los miembros del equipo estiman los defectos introducidos a partir de las tasas históricas de introducción de defectos y tiempos planeados por fase. También usan datos históricos de rendimiento para estimar los defectos eliminados por fase. El equipo analiza y acuerda sobre la estrategia y el plan de administración de calidad. Se revisa el plan de calidad contra las metas y el plan descendente para asegurar consistencia y se realizan los ajustes necesarios. En el TSP, la calidad del software durante el desarrollo del producto es medida contando los defectos normalizándolos por la medida apropiada de tamaño Junta 6 En la junta 6 los miembros del equipo hacen planes personales para el siguiente periodo del plan. El administrador de planeación del equipo guía este esfuerzo, bajo la guía del coach de TSP. 37

38 En esta junta: Los desarrolladores construyen sus propios planes. El equipo balancea la carga de trabajo de tal forma que todos terminan sus tareas de la siguiente fase aproximadamente al mismo tiempo. El equipo junta los planes de trabajo individuales para formar el plan consolidado del equipo. Este plan es usado por el equipo para guiar y seguir su trabajo durante la siguiente fase del proyecto. El equipo revisa el plan consolidado y se hace un balance sobre la carga de trabajo de los miembros del equipo si es necesario Junta 7 En la junta 7 el equipo evalúa los riesgos percibidos para su plan. Un riesgo puede o no suceder mientras que una situación (issue) es cierto que va a suceder. El equipo decide qué riesgos seguir y administrar y qué planes de mitigación son necesarios. Una vez que el equipo identifica y evalúa los riesgos: Cada riesgo es evaluado con respecto a impacto y probabilidad. Se definen planes de mitigación para los riesgos de alta y media prioridad. Cada riesgo se asigna a un miembro del equipo para su investigación y seguimiento Junta 8 En esta junta el equipo prepara una presentación del plan a la dirección. En caso de que el plan del equipo no cumpla las metas de la dirección, el equipo incluye planes alternativos que pueden agregar más recursos, o pueden entregar una versión con funcionalidad reducida. Es recomendable iniciar con una versión pequeña y seguir posteriormente con una versión con funcionalidad completa El líder del equipo por lo regular presenta el plan con los miembros del equipo participando como el equipo elija. Es importante proporcionar información del resumen del plan pero también hay que tener disponibles los detalles si son solicitados. 38

39 Para la elaboración del plan es necesario tener muy claro que es lo que se pretende realizar, cual es la estrategia para realizar ese proyecto?, en que tiempo quedará finalizado el proyecto?, El producto final es de calidad? Necesidades de Negocio Metas de Dirección Requerimientos de Producto Qué? Cómo? Cuando? Quién? Qué tan bien? Qué pasa si? Metas del equipo Diseño Conceptual Productos planeados Estrategia de Equipo Proceso del Equipo Plan de Tareas y horas Plan de calendario Roles del Equipo Planes de Tareas Plan de Calidad Evaluación de riesgo Planes Alternativos Estimados de Tamaño Plan de Valor Generado Planes Detallados Difícilmente se pueden cumplir todas las exigencias de la dirección, sin embargo un plan alternativo puede dejar satisfecho a la dirección y al equipo Junta 9 El propósito de esta junta es describir el plan del equipo a la dirección, contestar las preguntas de la dirección y obtener la aprobación de la dirección al plan o a la alternativa seleccionada. Cuando la dirección no está de acuerdo con ninguno de los planes, ellos usualmente deciden reconsiderar sus necesidades. En esta junta el equipo debe explicar cómo se realizó el plan, los datos usados y las suposiciones realizadas. En el caso de nuestro proyecto, el plan mostrado fue aceptado después de ser presentado y de una serie de preguntas por lo que no fue necesario replantear necesidades o crear planes alternativos. 39

40 Postmortem de lanzamiento El postmortem del lanzamiento es para consolidar el plan y los datos del lanzamiento, se examinan los problemas abiertos y acordar cómo manejarlos. En esta junta de postmortem se analizaron los errores cometidos en el lanzamiento, se crearon propuestas de mejoras para el proceso (PIP) y una forma MTG con el resumen de la junta de lanzamiento. 40

41 3.4 Seguimiento del proyecto Cada semana se reúne el equipo para informar el estado del proyecto, se realiza una pequeña junta en la que cada miembro expone el estado en el que se encuentra en el proyecto, es decir, si las tareas que tenia que realizar en esa semana fueron cumplidas o no, o cual fue su avance. Los administradores de cada rol informan sobre actividades que estén involucradas con su rol, sobre posibles cambios que afecten el proyecto o aspectos necesarios para cumplir alguna meta. Posteriormente se recopila toda la información y se realiza una consolidación de proyecto en esa semana, se muestra el avance que ha tenido el equipo con respecto a las metas planeadas y sobre el calendario de trabajo. Al terminar de mostrar el estado actual del proyecto, se realiza una planeación para la siguiente semana, en la cual cada miembro del equipo se compromete a realizar sus actividades para lograr una meta. Cada administrador tiene el deber de ayudar a los miembros del equipo en caso de que alguna actividad esté relacionada con su rol. Finalmente se documenta lo acordado en la junta en una forma MTG en la cual se registran las decisiones y acciones que se tomaron en esa junta Junta semanal 1 Para la primera semana se toma el trabajo realizado al 25/10/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 1 DOC Guía de integración DOC AR DLD Contador de LOC (Java) DLD AR CODE Contador de LOC (Java) CODE AR DOC Check List Rev. Req DOC OO DOC Check List Ins. Req DOC OO DOC Proceso de cambios DOC MC DOC Check List Ins. HLD DOC AA DOC Checl List Ins. DLD DOC AA DOC Estándar de codificación DOC EDW DOC Estándar de conteo DOC EDW DOC Check List Ins. Cod DOC EDW REQ LOGIN REQ MR

42 REQ BUS REQ AR REQ LOGIN REQ AA REQ BUS REQ EDW REQ VISITAS REQ MAA REQ VISITAS REQ AD REQ ALARMA REQ EA REQ ALARMA REQ PR Los resultados obtenidos para esta semana son: Se puede observar una sobreestimación, ya que el valor generado planeado está por encima del que se obtuvo, puesto que únicamente se obtuvo 6.0, esto sucedió principalmente a la mala distribución de tiempo ya que como se puede observar, sólo se generó casi la mitad de horas de las que se habían planeado, por lo que se debía de trabajar más para llegar a nuestra meta de 100 horas en la semana Junta semanal 2 Para esta semana se toma el trabajo realizado al 01/11/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 2 HLD SYSTEM High-Level Design 1a Itera AR HLD SYSTEM High-Level Design 1a Itera EA HLD SYSTEM High-Level Design 1a Itera MAA HLD SYSTEM High-Level Design 1a Itera AD HLD SYSTEM High-Level Design 1a Itera PR HLD SYSTEM High-Level Design 1a Itera EDW

43 Los resultados obtenidos para esta semana son: Las horas trabajadas están muy por debajo de lo estimado por lo que el valor generado también es demasiado bajo, esto sucedió principalmente porque varios miembros del equipo no le dedicaron el tiempo necesario al proyecto por cuestiones personales, por lo cual se pensó en una nueva estrategia de repartición de tiempos para tener una meta de tiempos un poco más realista Junta semanal 3 Para esta semana se toma el trabajo realizado al 08/11/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 3 COMPILE Contador de LOC (Java) COMPILE AR UT Contador de LOC (Java) UT AR DLD Contador de LOC (Web) DLD EDW CODE Contador de LOC (Web) CODE EDW COMPILE Contador de LOC (Web) COMPILE EDW UT Contador de LOC (Web) UT EDW REQINSP LOGIN REQINSP MAA REQINSP ALARMA REQINSP AD Los resultados para esta semana son: 43

44 En esta semana se obtuvo una mejor aproximación con respecto a las horas planeadas, sin embargo, el número de horas trabajadas sigue por debajo, aunque se hizo un mejor esfuerzo para lograr nuestra meta, el valor generado estuvo muy por debajo de lo planeado Junta semanal 4 Para esta semana se toma el trabajo realizado al 15/11/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 4 REQINSP BUS REQINSP EA HLD SYSTEM High-Level Design 1a Itera OO REQINSP BUS REQINSP OO HLD SYSTEM High-Level Design 1a Itera MC REQINSP BUS REQINSP MC REQINSP SEGURIDAD REQINSP PR REQINSP SEGURIDAD REQINSP AA REQINSP SEGURIDAD REQINSP MR REQINSP LOGIN REQINSP AR REQINSP LOGIN REQINSP EDW REQINSP RECETAS REQINSP AR REQINSP RECETAS REQINSP EA REQINSP RECETAS REQINSP EDW REQINSP VISITAS REQINSP EDW REQINSP VISITAS REQINSP PR Los resultados para esta semana son: A pesar de que se dedica un poco más de horas, el valor generado es muy poco en comparación a lo planeado, nuevamente se piensa en optar por una nueva estrategia para poder llegar a una aproximación más exacta, sin embargo los miembros del equipo se comprometen a cumplir con las horas planeadas y generar las metas propuestas. 44

45 3.4.5 Junta semanal 5 Para esta semana se toma el trabajo realizado al 22/11/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 5 ITP SYSTEM Integration Test Plan 1a Itera AR ITP SYSTEM Integration Test Plan 1a Itera EA ITP SYSTEM Integration Test Plan 1a Itera OO ITP SYSTEM Integration Test Plan 1a Itera MC HLD SYSTEM High-Level Design 1a Itera AA ITP SYSTEM Integration Test Plan 1a Itera AA ITP SYSTEM Integration Test Plan 1a Itera MAA HLD SYSTEM High-Level Design 1a Itera MR ITP SYSTEM Integration Test Plan 1a Itera MR ITP SYSTEM Integration Test Plan 1a Itera AD ITP SYSTEM Integration Test Plan 1a Itera PR ITP BUS ITP AR ITP LOGIN ITP AA ITP SYSTEM Integration Test Plan 1a Itera EDW ITP LOGIN ITP MR DLD LOGIN Detailed Design MR DLD BUS Detailed Design AR DLD SEGURIDAD Detailed Design MC DLDR SEGURIDAD DLD Review MC DLD LOGIN Detailed Design AA DLDR LOGIN DLD Review AA DLD ALARMA Detailed Design EA DLD SEGURIDAD Detailed Design OO DLDR SEGURIDAD DLD Review OO DLD BUS Detailed Design EDW DLD ALARMA Detailed Design PR DLD ALARMA Detailed Design EA DLDR ALARMA DLD Review EA DLD ALARMA Detailed Design PR DLDR ALARMA DLD Review PR REQINSP ALARMA REQINSP AA REQINSP ALARMA REQINSP MR Los resultados obtenidos son: 45

46 En esta semana se aprecia una mejoría con respecto a horas planeadas y trabajadas, por primera vez se pasa el valor generado por lo que el equipo toma mas confianza y se compromete aún más para poder cubrir las horas planeadas Junta semanal 6 Para esta semana se toma el trabajo realizado al 29/11/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 6 DLDINSP BUS DLD Inspection EA DLDINSP BUS DLD Inspection MC DLDINSP SEGURIDAD DLD Inspection PR DLDINSP BUS DLD Inspection OO REQ SEGURIDAD REQ OO REQ SEGURIDAD REQ MC ITP SEGURIDAD ITP OO ITP BUS ITP EDW ITP VISITAS ITP MAA ITP VISITAS ITP AD DLD VISITAS Detailed Design MAA DLD VISITAS Detailed Design MAA DLDR VISITAS DLD Review MAA DLD VISITAS Detailed Design AD DLD VISITAS Detailed Design AD DLDR VISITAS DLD Review AD DLDINSP SEGURIDAD DLD Inspection MR DLDINSP LOGIN DLD Inspection AR DLDINSP SEGURIDAD DLD Inspection AA DLDINSP LOGIN DLD Inspection EDW DLDINSP LOGIN DLD Inspection MAA DLDINSP ALARMA DLD Inspection MR DLDINSP ALARMA DLD Inspection AD DLDINSP ALARMA DLD Inspection AA REQINSP VISITAS REQINSP AR DLDINSP VISITAS DLD Inspection AR DLDINSP VISITAS DLD Inspection EDW DLDINSP VISITAS DLD Inspection PR

47 Los resultados obtenidos son: Casi se cubren las horas planeadas lo cual se ve reflejado en el valor generado ya que nuevamente se sobrepasa el valor planeado, aunque falta mucho para poder llegar al valor generado total que se debería, ya se cumple con más de la mitad Junta semanal 7 Para esta semana se toma el trabajo realizado al 06/12/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 7 HLDINSP SYSTEM HLD Inspection 1a Itera AR HLDINSP SYSTEM HLD Inspection 1a Itera EA HLDINSP SYSTEM HLD Inspection 1a Itera OO HLDINSP SYSTEM HLD Inspection 1a Itera MC HLDINSP SYSTEM HLD Inspection 1a Itera AA HLDINSP SYSTEM HLD Inspection 1a Itera MAA HLDINSP SYSTEM HLD Inspection 1a Itera MR HLDINSP SYSTEM HLD Inspection 1a Itera AD HLDINSP SYSTEM HLD Inspection 1a Itera PR HLDINSP SYSTEM HLD Inspection 1a Itera EDW ITP ALARMA ITP EA ITP SEGURIDAD ITP MC ITP ALARMA ITP PR TD BUS Test Development AR TD SEGURIDAD Test Development OO TD SEGURIDAD Test Development MC TD BUS Test Development EDW TD ALARMA Test Development EA TD ALARMA Test Development PR TD ALARMA Test Development EA TD ALARMA Test Development PR

48 Los resultados obtenidos son: Los esfuerzos para cubrir las horas planeadas se incrementaron ya que también se tenían que cumplir con las tareas atrasadas y cumplir con las nuevas, este factor provocó que no se pudiera llegar al valor generado planeado, sin embargo, el valor alcanzado no fue tan bajo como en semanas anteriores Junta semanal 8 Para esta semana se toma el trabajo realizado al 13/12/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 8 CODEINSP BUS Code Inspection EA CODE LOGIN Code AA CODE LOGIN Code MR CODE BUS Code AR CODE BUS Code EDW TD VISITAS Test Development MAA TD VISITAS Test Development AD TD VISITAS Test Development MAA TD VISITAS Test Development AD REQ RECETAS REQ AR CODE ALARMA Code EA CODE ALARMA Code EA CR ALARMA Code Review EA COMPILE ALARMA Compile EA REQ RECETAS REQ EDW CODE ALARMA Code PR CODE ALARMA Code PR CR ALARMA Code Review PR

49 Los resultados obtenidos son: Nuevamente las horas trabajadas son más que las horas planeadas y el valor generado es casi el mismo, esto es debido a que las tareas atrasadas prácticamente están cubiertas y las tareas planeadas para la semana se llevan a cabo de forma satisfactoria Junta semanal 9 Para esta semana se toma el trabajo realizado al 20/12/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 9 CODEINSP BUS Code Inspection OO CODEINSP BUS Code Inspection MC CODE SEGURIDAD Code OO CR SEGURIDAD Code Review OO CODE SEGURIDAD Code MC CR SEGURIDAD Code Review MC CODEINSP LOGIN Code Inspection AR CODEINSP SEGURIDAD Code Inspection AA CODEINSP LOGIN Code Inspection EDW CODE VISITAS Code MAA CODE VISITAS Code AD ITP RECETAS ITP AR CODEINSP ALARMA Code Inspection AA ITP RECETAS ITP EDW CODE VISITAS Code MAA CR VISITAS Code Review MAA CODE VISITAS Code AD CR VISITAS Code Review AD CODEINSP LOGIN Code Inspection MAA CODEINSP ALARMA Code Inspection AD CODEINSP VISITAS Code Inspection AR CODEINSP SEGURIDAD CODEINSP EA CODEINSP VISTAS CODE Inspection EDW

50 Los resultados obtenidos son: Dado que era difícil conseguir las metas planeadas en el tiempo estimado tuvo que realizarse un reajuste para poder llegar a cumplir con metas alcanzables en el tiempo que se había planeado, lo cual se ve reflejado en el valor generado, el cual es muy superior al esperado. Puede observarse también que con el nuevo ajuste el número de horas con las que se espera cumplir bajó a 60 y no 100 como estaba anteriormente Junta semanal 10 Para esta semana se toma el trabajo realizado al 27/12/2010 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 10 TD LOGIN Test Development AA CR LOGIN Code Review AA COMPILE LOGIN Compile AA COMPILE BUS Compile AR UT BUS Unit Test AR UT LOGIN Unit Test AA COMPILE BUS Compile EDW UT SEGURIDAD Unit Test OO UT SEGURIDAD Unit Test MC UT BUS Unit Test EDW COMPILE VISITAS Compile MAA COMPILE VISITAS Compile AD

51 Los resultados obtenidos son: A pesar de que no se cubrieron las horas planeadas, el valor generado es casi el que se esperaba, aunque falta todavía para llegar al total del valor generado que se esperaba, con el reajuste de metas es posible alcanzarlo Junta semanal 11 Para esta semana se toma el trabajo realizado al 03/01/2011 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 11 IT CONSTRUCCION DEMO 1 MAA IT CONSTRUCCION DEMO 1 AD IT CONSTRUCCION DEMO 1 EA COMPILE SEGURIDAD Compile OO COMPILE SEGURIDAD Compile MC IT LOGIN IT AA IT SEGURIDAD IT OO IT CONSTRUCCION DEMO 1 OO IT SEGURIDAD IT MC IT CONSTRUCCION DEMO 1 MC IT CONSTRUCCION DEMO 1 AA IT CONSTRUCCION DEMO 1 AR CODEINSP ALARMA CODEINSP MC IT CONSTRUCCION DEMO 1 EDW DLD RECETAS DLD AR DLD RECETAS DLD AR UT ALARMA Unit Test EA DLD RECETAS DLD EDW UT ALARMA Unit Test EA DLD RECETAS DLD EDW UT VISITAS Unit Test MAA UT VISITAS Unit Test MAA UT VISITAS Unit Test AD UT VISITAS Unit Test AD

52 Los resultados obtenidos son: El número de horas se incrementó un poco, sin embargo, las horas trabajadas casi cubren al número de horas planeadas. El valor generado superó al planeado, aun así el valor generado total esperado es todavía mayor que el real Junta semanal 12 Para esta semana se toma el trabajo realizado al 10/01/2011 Phase Task Resource Plan Hrs. Actual Hrs. EV or PV CPI TASKS COMPLETED IN WEEK 12 PM SYSTEM 1a iteración MAA PM SYSTEM 1a iteración AD PM SYSTEM 1a iteración EA MGMT RELAUNCH 2a Iteración EA MGMT RELAUNCH 2a Iteración MAA DLDR LOGIN DLD Review MR MGMT RELAUNCH 2a Iteración AD CODEINSP SEGURIDAD Code Inspection PR IT CONSTRUCCION DEMO 1 PR PM SYSTEM 1a iteración PR MGMT RELAUNCH 2a Iteración PR TD LOGIN Test Development MR CR LOGIN Code Review MR COMPILE LOGIN Compile MR IT BUS IT AR UT LOGIN Unit Test MR IT LOGIN IT MR IT BUS IT EDW CODEINSP SEGURIDAD Code Inspection MR IT CONSTRUCCION DEMO 1 MR PM SYSTEM 1a iteración MR PM SYSTEM 1a iteración AR MGMT RELAUNCH 2a Iteración AR PM SYSTEM 1a iteración OO MGMT RELAUNCH 2a Iteración OO PM SYSTEM 1a iteración MC MGMT RELAUNCH 2a Iteración MC

53 PM SYSTEM 1a iteración AA MGMT RELAUNCH 2a Iteración AA PM SYSTEM 1a iteración EDW MGMT RELAUNCH 2a Iteración MR CODEINSP ALARMAS CODEINSP OO IT CONSTRUCCION DEMO 2 OO IT CONSTRUCCION DEMO 2 MC IT CONSTRUCCION DEMO 2 AA MGMT RELAUNCH 2a Iteración EDW DLDINSP RECETAS DLDINSP MR COMPILE ALARMA Compile PR CODEINSP RECETAS CODEINSP MR IT CONSTRUCCION DEMO 2 MR UT ALARMA Unit Test PR IT ALARMA IT EA IT CONSTRUCCION DEMO 2 EA IT VISITAS IT MAA IT VISITAS IT AD UT ALARMA Unit Test PR IT ALARMA IT PR IT CONSTRUCCION DEMO 2 MAA IT CONSTRUCCION DEMO 2 AD CODEINSP VISITAS Code Inspection PR IT CONSTRUCCION DEMO 2 AR IT CONSTRUCCION DEMO 2 EDW IT CONSTRUCCION DEMO 2 PR Los resultados obtenidos son: Para esta última semana casi se alcanza el número de horas planeadas, el valor generado es superior al planeado y el valor generado total por fin es alcanzado completamente. 53

54 3.5 Análisis de tamaño Al igual que en el curso de PSP, es necesario realizar una estimación de tamaño y conocer cuales fueron los resultados, a partir del alcance que se le da al proyecto se pueden realizar estimaciones, las cuales nos ayudan para poder tener un enfoque con respecto a la complejidad que puede tener el proyecto. A continuación se muestra una lista con los tamaños de distintos productos utilizados en el proyecto: Fase Medida Tamaño planeado Tamaño Real Sistema de Alarmas Req Req Pages 18 9 Sistema de Alarmas Text Text Pages Sistema de Alarmas Hld HLD Pages Sistema de Alarmas Dld DLD Lines Sistema de Alarmas LOC BUS Req Pages 3 1 BUS Text Pages 0 0 BUS HLD Pages 4 2 BUS DLD Lines BUS LOC ALARMA Req Pages 3 1 ALARMA Text Pages 0 0 ALARMA HLD Pages 4 3 ALARMA DLD Lines ALARMA LOC LOGIN Req Pages 3 4 LOGIN Text Pages 0 3 LOGIN HLD Pages 4 4 LOGIN DLD Lines LOGIN LOC VISITAS Req Pages 3 1 VISITAS Text Pages 0 0 VISITAS HLD Pages 4 7 VISITAS DLD Lines VISITAS LOC

55 RECETAS Req Pages 3 1 RECETAS Text Pages 0 0 RECETAS HLD Pages 4 0 RECETAS DLD Lines 26 0 RECETAS LOC SEGURIDAD Req Pages 3 1 SEGURIDAD Text Pages 0 0 SEGURIDAD HLD Pages 4 1 SEGURIDAD DLD Lines SEGURIDAD LOC Estándar de codificación Text Pages 4 1 Estándar de conteo Text Pages 4 1 Contador de LOC (Java) LOC Contador de LOC (Web) LOC Check List Rev. Req Text Pages 2 2 Check List Ins. Req Text Pages 2 2 Check List Ins. HLD Text Pages 2 1 Check List Ins. DLD Text Pages 2 1 Check List Ins. Cod Text Pages 2 2 Guía de integración Text Pages 2 1 Proceso de cambios Text Pages 3 2 Al principio del proyecto, el equipo tenía ciertas metas, tenía planeado cubrir distintas funcionalidades en el sistema, conforme fue avanzando el proyecto, nos dimos cuenta que esas metas no eran alcanzables en el tiempo pensado, por lo cual se realizó un reajuste de objetivos, observando la tabla se puede apreciar que el número de LOCS reales es mucho menor a las planeadas, uno de los factores que nos llevó a ese resultado fue que con el cambio de metas se eliminaron funcionalidades en el sistema, por lo cual disminuyó el número de LOCS generadas, sin embargo, en general se tuvo una sobreestimación, ya que no sólo fue en el número de LOCS en donde se falló, sino también en todo lo demás. 55

56 3.6 Análisis de tiempo Al igual que con la estimación de tamaño, es necesaria una estimación de tiempo, esto nos puede servir no sólo para el proyecto actual, sino para poder realizar una planeación de futuros proyectos, al tener un historial de tamaño y tiempo en los proyectos se puede realizar una estimación con mayor precisión, lo cual nos ayudará a saber en cuanto tiempo se tendrá listo un proyecto con ciertas funcionalidades. A continuación se muestra una lista con los tiempos planeados en distintas fases del proyecto: Time in Phase (hours) Plan Real % Management and Miscellaneous % Launch and Strategy % Planning % Requirements % System Test Plan % REQ Inspection % High-Level Design % Integration Test Plan % HLD Inspection % Detailed Design % DLD Review % Test Development % DLD Inspection % Code % Code Review % Compile % Code Inspection % Unit Test % Build and Integration Test % System Test % Documentation % Postmortem % Total % Como se puede observar, en general se tuvo una sobreestimación, ya que el tiempo planeado fue de y se tuvo 884.4, esto principalmente porque en las primeras semanas del proyecto el equipo no le dedicaba el tiempo que se había establecido, esto ocasionó que se realizara un reajuste de metas en el cual se realizaban ciertas funcionalidades del sistema y nos llevó un menor tiempo. Es de gran importancia notar que el mayor número de horas fueron dedicadas a diseño detallado, esto es porque en esa fase se centra la estructura del proyecto, ya que sin un buen diseño es probable que el proyecto no tenga el resultado esperado. 56

57 3.7 Análisis de defectos Para poder tener un sistema de calidad es necesario reducir el número de defectos, por lo que es buena idea el hacer una estimación y verificar posteriormente el número de defectos reales, además de que se puede ver en que fase es en la que se tienen más defectos y así poder corregir ese problema. Todo esto nos ayudará para que cada vez se elaboren sistemas con una mejor calidad en menor tiempo. En la siguiente tabla se muestran los defectos esperados y los que realmente se introdujeron: Como se puede observar se tuvo una sobreestimación en el número de defectos, sobre todo en la fase de Code, ya que el número esperado era de 231 y el real fue de tan sólo 58, por otro lado, en la fase de Detailed Design es en donde se introdujeron más defectos y aun así se tuvo una sobreestimación en el número de errores que se esperaban. Es importante saber el número de errores cometidos y en que fase, pero también es importante conocer en que fase es donde se remueven esos defectos para saber si las inspecciones son de ayuda o no. 57

58 En la siguiente tabla se muestra la fase en la que fueron removidos los defectos localizados: Como se puede observar, el mayor número de defectos fueron removidos durante las inspecciones, lo cual indica que son de gran ayuda y con esto podemos tener un sistema de mayor calidad. 58