personal software process & team software process148.206.53.84/tesiuami/uami16026.pdf ·...

UNIVERSIDAD AUTÓNOMA METROPOLITANA

Unidad Iztapalapa

PROYECTO DE INVESTIGACION

Personal Software Process & Team Software Process

Autor: Diego Marcial Montiel Juárez

Asesor:

Dr. Humberto Cervantes Maceda

Marzo de 2010

TABLA DE CONTENIDO

1. PRESENTACION ............................................................................................................................ 4

2. PERSONAL SOFTAWARE PROCESS ( PSPSM) ........................................................................... 7

2.1. INTRODUCCIÓN ......................................................................................................................... 7

2.2. REPORTE FINAL DE PSP ........................................................................................................ 10

2.2.1. PLANTILLA DEL GUIÓN DE PROCESO PARA EL REPORTE FINAL DE PSP................... 10

2.2.2. RESUMEN DEL PLAN DEL REPORTE FINAL DE PSP........................................................ 12

2.2.3. BITÁCORA DE REGISTRO DE TIEMPO ............................................................................... 13

2.2.4. ANALISIS DE LA EXACTITUD DE LA ESTIMACIÓN DEL TAMAÑO ..............................14 2.2.5. ANÁLISIS DE LA EXACTITUD DE LA ESTIMACIÓN DEL TIEMPO................................16 2.2.6. ANÁLISIS DE DEFECTOS DE RENDIMIENTO ..................................................................19 2.2.7. ANÁLISIS DE LA CALIDAD ....................................................................................................27 2.2.8. CONCLUSIONES .....................................................................................................................31

3. TEAM SOFTAWARE PROCESS ( TSPSM)................................................................................... 33

3.1. INTRODUCCIÓN ....................................................................................................................... 33

3.2. LANZAMIENTO DE UN EQUIPO TSP ...................................................................................... 35

4. PROYECTOS................................................................................................................................ 39

4.1. INTRODUCCIÓN ....................................................................................................................... 39

4.1.1. SISTEMA DE ADMINISTRACIÓN PIGMEX...............................................................................40 4.1.2. SISTEMA DE FACTURACIÓN DEL SAT....................................................................................41 4.1.3. SISTEMA DE ADMINISTRACIÓN CAMELIA RESEARCH .....................................................42 4.1.4. SISTEMA DE ADMINISTRACIÓN PARA VIDEO-BAR.............................................................43

5. LANZAMIENTO TSP MULTIPROY............................................................................................... 46

5.1. JUNTA 1 ESTABLECER LOS OBJETIVOS DE NEGOCIO Y DE PRODUCTO. ........................................46 5.2. JUNTA 2 ASIGNACIÓN DE ROLES Y DEFINICIÓN DE OBJETIVOS DEL EQUIPO ....................................50 5.3. JUNTA 3 GENERAR UNA ESTRATEGIA DE DESARROLLO ..................................................................51 5.4. JUNTA 4 ELABORACIÓN DESCENDENTE DEL PLAN ...........................................................................52 5.5. JUNTA 5 DESARROLLO DEL PLAN DE CALIDAD .................................................................................52 5.6. JUNTA 6 ELABORACIÓN DE PLANES INDIVIDUALES Y DEL EQUIPO DE LA SIGUIENTE FASE ...............54 5.7. JUNTA 7 CONDUCCIÓN DE LA EVALUACIÓN DEL RIESGO .................................................................55

5.8. JUNTA 8 PREPARAR PRESENTACIÓN A DIRECCIÓN Y REPORTE DE LANZAMIENTO .........................55 5.9. JUNTA 9 REVISIÓN CON LA ALTA DIRECCIÓN.....................................................................................56 5.10. POST MORTEM DEL LANZAMIENTO ........................................................................................57

6. SEGUIMIENTO DEL PROYECTO................................................................................................ 58

6.1. INSPECCIONES EN TSP ................................................................................................................60 6.2. DOCUMENTOS PARA UN PROYECTO TSP...............................................................................61 6.3. ADMINISTRACION DE LA CONFIGURACION ............................................................................62 6.4. SEGUIMIENTO SEMANAL DEL PROYECTO ..............................................................................63

6.4.1. SEMANA 1 .................................................................................................................................64 6.4.2. SEMANA 2 .................................................................................................................................65 6.4.3. SEMANA 3 .................................................................................................................................66 6.4.4. SEMANA 4 .................................................................................................................................67 6.4.5. SEMANA 5 .................................................................................................................................68 6.4.6. SEMANA 6 .................................................................................................................................69 6.4.7. SEMANA 7 .................................................................................................................................70 6.4.8. SEMANA 8 .................................................................................................................................71

7. REPORTE SUMMARY DEL PROYECTO .................................................................................... 72

7.1. ANÁLISIS DEL CALENDARIO DE TRABAJO...............................................................................73 7.2. ANÁLISIS DE RECURSOS ..............................................................................................................75 7.3. ANÁLISIS DE TAMAÑO ...................................................................................................................76 7.4. ANÁLISIS DE PRODUCTIVIDAD ...................................................................................................77 7.5. ANÁLISIS DE DEFECTOS...............................................................................................................78 7.6. ANÁLISIS DE RENDIMIENTO.........................................................................................................81

8. CONCLUSIONES.......................................................................................................................... 86

9. GLOSARIO.................................................................................................................................... 88

10. REFERENCIAS........................................................................................................................... 92

1. PRESENTACION La Ingeniería de Software es una de las industrias más grandes e influyentes en la sociedad moderna, el software afecta incluso en los aspectos más cotidianos de nuestras vidas desde la compra de comestibles en autoservicios o llenar el tanque de combustible de nuestro automóvil hasta realizar operaciones financieras. Sin embargo, a pesar de su influencia penetrante, la Ingeniería de Software es una disciplina relativamente joven. El termino Ingeniería de Software ha estado en el uso popular a finales de los 60’, después de su introducción en el titulo de una conferencia del Comité Científico de la NATO en Garmisch, Alemania [Naur 69]. La Ingeniería de Software es una disciplina o área de la informática o ciencias de la computación que ofrece un método y técnicas para desarrollar y mantener software de calidad que resuelven problemas de todo tipo. Hoy en día una de las críticas frecuentes de la profesión de software es la mala calidad de los productos que produce. El costo, tiempo de desarrollo y calidad del software ahora es un interés crítico de negocio. Este problema se atribuye a muchas causas, una de ellas es la manera en que los ingenieros de software son educados a problemas inherentes de una profesión muy joven. Un artículo en la enciclopedia en línea Wikipedia resumió la crítica de software de la siguiente manera:

“En la ingeniería tradicional hay un claro consenso en cómo las cosas deben ser construidas, ¿Qué normas se deben seguir y cuales riesgos deben ser atendidos: Si un ingeniero no sigue estas prácticas, las cosas fallan. No hay tal consenso en la ingeniería de software: Todo mundo promueve sus propios métodos, alegando enormes beneficios en la productividad, que por lo general no está respaldados por ningunas pruebas científicas. ” [Wikipedia 05].

Una poderosa herramienta a esta critica es la adopción generalizada de la metodología Personal Software Process( PSPSM). Desarrollado en 1993 por Watts S. Humphey, el PSP

es un disciplinado y estructurado enfoque de desarrollo de software. Mediante el uso de sus conceptos y métodos las personas pueden mejorar sus técnicas de estimación y planificación, gestionar la calidad de su trabajo y reducir el número de defectos en sus productos. Una metodología que resuelve los problemas de las industrias de software es el Team Software Process (TSPSM) que guía a los equipos de desarrollo en la producción de software de alta calidad. Muchas organizaciones han encontrado al TSPSM eficaz para mejorar el costo, la calidad y la competitividad de su trabajo. La eficiencia de los conceptos y metodologías de PSPSM y TSPSM tanto en entornos académicos como industriales se encuentran documentados en numerosos informes y artículos. [SEI 09]. En mi formación académica en la Universidad Autónoma Metropolitana unidad Iztapalapa (UAM-I) Licenciatura en Computación, practique estas metodologías de desarrollo de software en las asignaturas Proyecto Terminal I y II respectivamente. En la asignatura Proyecto Terminal I se recibió el curso PSP para Ingenieros, cuando el curso termina el alumno tiene una base probada para el desarrollo de software, puede estimar y planificar su trabajo, resistir a presiones no razonables, cumplir con sus compromisos, comprender sus capacidades para mejorar de manera continua la productividad, calidad, y el grado de predicción de su trabajo. En Proyecto Terminal II tiene como objetivo iniciar con un proyecto de Software organizado para ello se forma un equipo TSP, con la finalidad de establecer un entendimiento común del equipo acerca del proyecto, se hace un Lanzamiento el cual consta de 9 juntas que sirven para establecer un plan de trabajo, para la construcción del proyecto, así como los procedimientos que se llevarán a cabo para cumplir las metas establecidas, siguiendo disciplinadamente el procedimiento que el TSP plantea en su cuaderno de trabajo

El presente documento, es un reporte general de lo realizado durante las asignaturas de Proyecto Terminal I y II, el cual se desglosa en 7 secciones. La segunda sección, presenta la parte del Proyecto Terminal I, en la que se reporta la metodología utilizada y un análisis obtenido de ella durante los 3 meses. Las siguientes secciones, pertenecen a la parte del Proyecto Terminal II, en las cuales se presenta una Introducción a la metodología TSP, los 4 proyectos realizados usando esta metodología, el seguimiento del proyecto y el análisis estadístico del proyecto.

2. PERSONAL SOFTAWARE PROCESS ( PSPSM) 2.1. INTRODUCCIÓN El PSP es una serie de procesos definidos que permiten a los desarrolladores de software producir productos de alta calidad a tiempo y dentro del presupuesto. PSP hace uso de un gran número de formatos los cuales son muy útiles para que se haga un análisis a fondo del programa que se desarrollará. Todo programa tiene una serie de pasos definidos para ir cumpliendo con los requerimientos del cliente de manera uniforme y disciplinada. Los procesos definidos ayudan a administrar grandes proyectos, ya sea trabajando en equipo y/o trabajando sólo. Lo primero que se tiene que hacer para definir los procesos que van a intervenir en un proyecto es:

1. Identificar las actividades principales. 2. Separar los elementos complejos que pueden intervenir. 3. Establecer los criterios de entrada y de salida para cada fase del proceso. 4. Medir de manera correcta el proceso, para tener bien entendido el

desempeño personal. 5. Estimar correctamente cuando debe finalizar cada tarea. 6. Medir con precisión todos los datos que intervinieron para futuros

programas. 7. Identificar las fases del proyecto que más problemas causaron. 8. Mejora continúa tomando en cuenta datos anteriores.

Una vez que se han tomado en cuenta todos estos pasos fundamentales para comenzar con el nivel inicial de PSP, las tareas toman una forma mucho más estructurada y racional (Véase Figura 1 )

Figura 1. Flujo del proceso PSP. [HUMPHEY 97] La Figura 1 muestra la estructura que siguen el proceso PSP, es necesario notar que este flujo es muy general y aplicable a cualquier proceso conocido, debido a que sigue un orden lógico, la primer parte, es tener guiones los cuales definen los pasos para cada parte del proceso, la segunda parte, son las fases de desarrollo del proceso, las bitácoras nos sirven para almacenar los datos para posteriormente hacer análisis estadísticos y por ultimo el Resumen del proyecto es un Reporte final del programa que se elaboro que sigue las normas especificadas en el guión del proceso. El PSP se introduce en 6 pasos compatibles y progresivos (Véase Figura 2). En donde se escriben uno o más programas del tamaño de un módulo en cada paso. Se recolectan y analizan los datos de su trabajo para mejorar su desempeño personal.

Requerimiento

Producto

Resume

n del

Proyect

Reporte de resumen de datos del proyecto y del

proceso

Guiones

Bitácoras

Planeación

Diseño

Codificación

Compilación

Pruebas

PM

Figura 2. Pasos del proceso PSP. La Figura 2 muestra cada uno de los pasos del proceso los cuales cumplen un cierto objetivo:

• PSP0: Establecer una referencia del desempeño. • PSP1: Hacer planes sobre tamaño, recursos y tiempo. • PSP2: Practicar la administración de defectos y del rendimiento o (yield).

PSP2 Revisiones de Código Revisiones de Diseño

PSP2 .1 Plantillas de Diseño

PSP1 Estimación de Tamaño

Reporte de Pruebas

PSP1 .1 Planeación de Tareas

Planeación de Calendario

PSP0 Proceso Actual

Registro de Tiempo Registro de Defectos

Estándar de Tipos de Defectos

PSP0.1 Estándar de Código Medición de Tamaño

Propuesta de Mejora de Procesos (PIP)

2.2. REPORTE FINAL DE PSP En la última parte del Proyecto Terminal I se lleva a cabo el reporte final PSP, en el que se presenta toda la información que el alumno ha generado a lo largo del curso, tiene como objetivos el comprender cual es el desempeño actual en el desarrollo de software y áreas de mejora para el alumno que tienen mayor prioridad, entender cuales fueron las causas por las que el desempeño cambió entre el reporte intermedio y el reporte final, obtener experiencia en establecer metas medibles para definir las acciones de mejora correspondientes y finalmente aprender a actualizar un proceso personal a través de un conjunto preguntas que componen el reporte. A continuación se presenta el Reporte Final. 2.2.1. PLANTILLA DEL GUIÓN DE PROCESO PARA EL REPORTE FINAL DE PSP

La Plantilla muestra como se lleva a cabo el análisis y la estructura del reporte final de PSP en donde su fin es el de proveer un marco que sirva para hacer la recolección y comparación de todos los datos.

Fase #

Propósito Guiar el análisis y la escritura del reporte final de PSP

Criterio de Entrada • Programas 1 a 8 terminados y revisados por los instructores • Copia de los requerimientos del reporte • Reporte intermedio finalizado y revisado por los instructores. Bitácora de registro de tiempo y forma del resumen del reporte final PSP

Planeación Estimar el tamaño del reporte - Número de párrafos de análisis - Número de tablas de datos/ gráficas a crear

• Estimar el esfuerzo basándose en el tamaño del reporte • Registrar los estimados en la Forma de Resumen del Plan Registrar el tiempo de planeación en la Bitácora de tiempo

Desarrollo • Para cada pregunta de análisis

- Generar si es necesario la gráfica o tabla de datos para análisis

- Analizar la gráfica/tabla y otros datos del proceso - Escribir el párrafo del análisis y conclusiones - Metas de mejora cuantitativas y medibles y acciones

específicas que planee tomar para lograr esas metas • Registrar el tiempo de desarrollo de reporte intermedio de PSP en

la Bitácora de Tiempo

Post Mortem • Medir el tamaño del reporte - Número de gráficas/tablas - Número de párrafos de análisis

• Completar la forma de Resumen del Plan Registrar el tiempo del post mortem en la Bitácora de tiempo

Criterio de Salida • Reporte final de PSP finalizado • Resumen del Plan finalizado .

2.2.2. RESUMEN DEL PLAN DEL REPORTE FINAL DE PSP El formato que se presenta a continuación, reúne las estimaciones y los datos reales que conforman el reporte final en toda su amplitud para al final se realicen las comparaciones necesarias y exista un histórico del proyecto realizado.

Estudiante Diego Montiel Juárez Fecha 01/07/09 Instructor Luis Castro Careaga

Datos de Tamaño Estimado de Esfuerzo

Objecto Número

Planeado Número

Real Esf. Estim.

por Objeto Esfuerzo

Estimado Párrafo 36 34 14 min 504 Grafica 9 10 5 min 45 Tabla 6 12 9 min 54

Total 603 min

Datos de Esfuerzo Fase Tiempo Plan Tiempo Real Planeacion 10 min 8 min Desarrollo 578 min 1065 min PostMortem 15 min

Total 633 min 1088 min

2.2.3. BITÁCORA DE REGISTRO DE TIEMPO El formato que se presenta a continuación, es el formato del registro de tiempo en el cual se reportan los tiempos de cada fase y algunos comentarios.

Estudiante Diego Montiel Juárez Fecha 01/07/09 Instructor Luis Castro Careaga

Fecha Inicio Alto Tiempo de Int

Tiempo Delta min Fase Comentarios

01/07/09 1:50pm 1:58pm 8 Planeación Finalizo la fase de Planeación

01/07/09 2:30pm 6:45pm 255 Desarrollo Hora de Cenar

01/07/09 7:30pm

12:00am

270 Desarrollo

Hora de Dormí

02/07/09 10:30am

1:30pm

180 Desarrollo

Horario de Clases

03/07/09 12:30pm

2:25pm

115 Desarrollo

Hora de comer

03/07/09 3:40pm 5:30pm 190 Desarrollo Horade salida

04/07/09 12:30pm

1:25pm

55 Desarrollo

Finalizo fase de

Desarrollo

04/07/09 1:25pm 1:40pm 15 PostMortem Finalizo Post mortem

Total: 1088min

2.2.4. ANALISIS 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é?

Programa Tamaño

Estimado(A&M) (LOC)

Tamaño Real (A&M) (LOC)

Estimado/Real en %

2 320 224 30 por debajo 3 47 107 126.25 por encima 4 95 94 0.66 por debajo

Total 462 425 Tabla 1. Muestra el tamaño de LOC estimado y real de los programas a la fecha

Programa Tamaño

Estimado(A&M) (LOC)

Tamaño Real (A&M) (LOC)

Estimado/Real en %

5 138 180 30 por encima 6 80 56 30 por debajo 7 122 166 36.06 por encima 8 166 212 27.71 por encima

Total 506 614 Tabla 2. Muestra el tamaño de LOC estimado y real de los programas 5 al 8.

En la Tabla 2. Se puede observar que mantuve una mejor estimación a razón de los primeros programas en los que no tenia muchos históricos de contar las LOC de los programas que realizaba, si bien la estimación no fue la correcta veo que se mantiene el porcentaje de estimación por encima de lo planeado y no fluctúa tanto como en los primeros 4 programas, mantiene un ±30% de mi estimación inicial esto se debe a que el proceso nos hace fijarnos mas en todos los detalles que conlleva la planeación de un programa, lo cual antes no tomábamos encuentra.

¿Qué tan frecuentemente estuvo mi tamaño real del programa dentro de mi intervalo estadístico de predicción del 70%? A excepción del programa 6 los demás programas caen dentro de la META de estimación por cual resulta que mis estimaciones no fueron del todo erróneas; puedo ver un gran crecimiento a través del proceso.

Programa Tamaño Real (A&M) (LOC)

Estimado(A&M) (LOC) UPI LPI

5 180 150 6 56 79 7 166 138 176 69 8 212 203 222 110

Tabla 3. Muestra el tamaño de LOC real y estimado estadístico de los programas 5 al 8. ¿Tengo una tendencia a agregar/no considerar objetos completos? No, los problemas que tuve nunca fueron de mala planeación a razón del numero de componentes para le programa, el error se tuvo en el tamaño de los componentes pero al analizar los datos de la pregunta anterior no estuvieron del todo mal. ¿Tengo una tendencia a juzgar equivocadamente el tamaño relativo de objetos? Si, el tamaño de los componentes de los programas mantienen una errónea estimación, pero en general el tamaño del programa tiende a caer dentro del intervalo de estimación del 70%. ¿Necesito calcular el rango de tamaño relativo usando mis datos de objeto históricos? ¿Puedo? Por supuesto la tarea 7 se basa en calcular este rango de tamaño a base de ciertos datos como son los datos históricos, número de puntos de datos históricos y los parámetros de regresión podría hacer este cálculo.

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í? Una meta realista seria mejorar mi estimación individual de los componentes de los programas, generando más históricos en mi haber estoy seguro que mi estimación ira mejorando de manera individual para cada componente.

2.2.5. ANÁLISIS DE LA EXACTITUD DE LA 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é?

Programa Tiempo Estimado (min)

Tiempo Real (min)

Estimado/Real en %

1 200 196 2.0 por debajo 2 420 362 13.89 por debajo 3 76.35 102 33.91 por encima 4 132.62 105 21.03 por debajo

Total 828.97 765

Tabla 4. Muestra el tiempo en min. estimado y real de los programas a la fecha.

Programa Tiempo Estimado (min)

Tiempo Real (min)

Estimado/Real en %

5 256.4 342.5 33.38 por encima 6 120.1 128.8 7.24 por encima 7 178.8 192.2 7.49 por encima 8 243.9 272.5 11.72 por encima

Total 799.2 936

Tabla 5. Muestra el tiempo en min. estimado y real de los programas 5 al 8. Ya no se ve tanta variación en los estimados de tiempo mantiene una tendencia la cual mantiene una relación con la variación de la estimación de LOC por la cual siempre vemos que resulta por encima de lo planeado pero analizando mas los datos con respecto a los tamaños sigue siendo una muy buena estimación de tiempo.

¿Qué tan frecuentemente estuvo mi tiempo de desarrollo real dentro de mi intervalo estadístico de predicción del 70%? A excepción del programa 5 los demás programas entran en la META de acuerdo al intervalo estadístico de predicción como ya se venia observando desde el reporte intermedio el problema era mas de estimación de tamaño que de tiempo. ¿Mi productividad es estable? ¿Por qué si o por qué no?

Grafica 1. Muestra la variación de mi productividad en los programas No, mi productividad no es estable las distintas mejoras dentro del proceso afectaron en cierta manera a diferentes partes del proceso de desarrollo, la alza que se tienen en los programas 7 y 8 es engañosa ya que si bien es claro que la experiencia obtenida fue clave también tiene mucho que ver la reutilización de código que se tuvo en esos programas, en cambio si vemos la tarea 5 y 6 en la cual había cosas nuevas afectaba demasiado. ¿Cómo puedo estabilizar mi productividad? Dentro del curso plantee estabilizar los tiempos de desarrollo y codificación a un 50 – 50 o lo mas cercano a eso, el cual no me fue posible obtenerlo al parecer se debe al hecho de no tener la costumbre de mantener un diseño a tan alto y bajo nivel para mis programas, por lo

cual considero que necesito ganar mas experiencia en base a programas nuevos y en fases de diseño. ¿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?) Por lo que aprecio en la Tabla 4. el error esta un 15% por encima de mis estimados de tiempo lo cual ni siquiera rebasa los rangos UPI, LPI pero en definitiva la regresión lineal es uno de los métodos que me ayudarían a corroborar si existe alguna correlación entre estas dos variables. 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?

Grafica 2. Muestra la variación entre el tiempo planeado y estimado en los programas. En base a los errores obtenidos en el programa 3,5 y analizando por separado cada uno de esto el primero se debió a una decisión errónea que tome para corregir un error y el segundo programa fue la aparición de diagramas en el proceso en el cual no tenia estimado de tiempos para estos y fue lo que paso pero de nueva cuenta los históricos fueron haciendo presente por lo que en la grafica se puede ver que a partir del programa 6 se mantiene

constante la variación, una meta seria mantener la prudencia a no subestimar los programas sin dejar a un lado la experiencia obtenida en el proceso. ¿Cómo puedo modificar mi proceso para cumplir esa meta? Seguir intentando estabilizar los tiempos de diseño y codificación ya que un buen diseño me lleva a cometer menos errores en las siguientes fases.

2.2.6. ANÁLISIS DE DEFECTOS DE RENDIMIENTO

¿Qué tipo de defectos introduzco durante el diseño y la codificación?

Numero de defectos del programa

1 2 3 4 Tipo de defectos

Dld Code Dld Code Dld Code Dld Code

Total del # de defectos en Dld

Total del #de defectos en Code

100 90 80 3 3 70 60 1 1 50 1 2 3 40 3 1 6 6 4 30 20 4 3 7 10

Total 11 7 6 0 6 18 Numero de defectos del programa

5 6 7 8 Tipo de defectos

Dld Code Dld Code Dld Code Dld Code

Total del # de defectos en Dld

Total del #de defectos en Code

100 90 80 5 1 5 1 70 60 50 2 2 40 7 1 3 1 9 3 30 20 10

Total 14 1 4 1 16 4 Tabla 6. Muestra el número de defectos introducidos en Diseño y Codificación.

Analizando al segunda parte del proceso PSP se muestra una tendencia clara hacia el error 40 de asignación tanto en el diseño como en la codificación este fue uno de los problemas recurrentes dentro de los programas de nueva cuenta es importante que centre mas atención en este tipo ya que dentro del análisis del reporte intermedio ya había una advertencia del mismo.

¿Qué tendencias son aparentes en los defectos por unidad de tamaño (e.g., KLOC) encontrados en las revisiones, compilaciones y pruebas?

Numero de defectos en

Revisiones Compilación Pruebas Tipo de

defectos Dld Cod 100 90 80 1 5 70 60 50 2 40 6 4 2 30 20 10

Total 8 5 7

Tabla 7. Muestra el número de defectos removidos en las Revisiones, Compilación y Pruebas.

La tendencia evidente en 3 fases del proceso la muestra la tabla 7. Logre mantener compilaciones limpias de errores pero eso no me aseguraba que el programa hiciera lo que esperaba de igual manera el énfasis que debo hacer en el tipo de defecto 40 ya que en pruebas consumía mas tiempo del esperado en teoría necesito detectar los problemas en fases mas tempranas del proceso por lo que abre que seguir modificando mis checklist.

¿Qué tendencias son aparentes en los defectos totales por unidad de tamaño?

Grafica 3. Muestra la variación de los defectos inyectados en los programas.

Como se ve en la grafica 3. Considero que la variación el los programas nuevos no la tengo controlada, muestro grandes avances en cuanto a reutilización de cosas hechas, pero en cuanto a cosas completamente nuevas aun no siento que tenga un control adecuado por lo cual necesitare poner mayor atención en las fases de detección de errores.

¿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 Pruebas?

Grafica 4. Muestra las variaciones de los defectos removidos por cada fase.

Como ha sido recurrente dentro del reporte la grafica 4. nos da una representación mas clara del problema que he venido mencionando siento que la fase de pruebas remueve gran parte de los defectos lo cual no debería suceder aunque también se aprecia una tendencia clara a la mejora el cual el proceso nos lleva en últimos programas.

¿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?

Las tasas de revisión que utilice fueron las que el Proceso recomienda cuando 200 LOC / hr.

Grafica 5. Muestra las tazas de revisión de Diseño y Codificación.

A medida que iban avanzado los programas el tamaño también era mayor por lo cual las revisiones iban creciendo por lo que la tendencia en la grafica es evidente, la cuales me ayudaron a detectar mas defectos en tempranas fases.

¿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?

Grafica 6. Muestra la variación de los defectos removidos en la revisión de Diseño.

Grafica 7. Muestra la variación de los defectos removidos en la revisión de Codificación.

Grafica 8. Muestra la variación de los defectos removidos en Compilación.

Grafica 9. Muestra la variación de los defectos removidos en Pruebas.

En las siguientes graficas se aprecia como la fase de revisión de código y pruebas fueron en las que mas se removieron defectos en estas graficas es importante ver como la fase de pruebas fue disminuyendo, pero también me sugiere poner énfasis en la revisión la cual al parecer no esta filtrando como es debido los errores.

¿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?

Grafica 10. Muestra la relación entre las revisiones y el rendimiento. Si, por que es necesario que exista una relación ya que el rendimiento nos refleja el % de error y esta relación nos indica si las revisiones están sirviendo como filtro o no, por lo que es necesario que exista una relación ya que nos serviría como un semáforo para saber cuando las revisiones no están realizando su cometido. ¿Hay una relación entre el rendimiento y A/FR para los programas 5 al 8? En el reporte intermedio se sugiere que:

• Su meta de rendimiento deberá estar basada en su reporte de análisis de medio curso. Si no tiene una meta de rendimiento, usted debería intentar lograr un rendimiento mayor de 60%.

Mi yield fluctúa entre el 65% y el a/fr >2.0 en los programas, por lo que las medidas de control de calidad sugieren que se están produciendo programas de buena calidad ya que se están escapando pocos errores aparentemente el proceso va por buen camino aunque siento que pondré mayor énfasis en puntos ya mencionados con anterioridad.

2.2.7. ANÁLISIS DE LA CALIDAD

Compare el reporte intermedio de base para la calidad en las pruebas unitarias con los programas posteriores al reporte.

Tipo de

defectos No. de

Defectos % Tipo de defectos

No. de Defectos % acumulado

10 0 0.00% 40 6 75.00% 20 1 12.50% 20 1 87.50% 30 0 0.00% 80 1 100.00% 40 6 75.00% 10 0 100.00% 50 0 0.00% 30 0 100.00% 60 0 0.00% 50 0 100.00% 70 0 0.00% 60 0 100.00% 80 1 12.50% 70 0 100.00% 90 0 0.00% 90 0 100.00%

100 0 0.00% 100 0 100.00%

Total 8 100.00% Tabla 8. Muestra el número de defectos encontrados en Pruebas del Programa 1 al 4.

Tipo de defectos

No. de Defectos %

tipo de defectos

No. de Defectos

% acumulado

10 0 0.00% 80 5 75.00% 20 0 0.00% 40 2 87.50% 30 0 0.00% 20 0 100.00% 40 2 28.57% 10 0 100.00% 50 0 0.00% 30 0 100.00% 60 0 0.00% 50 0 100.00% 70 0 0.00% 60 0 100.00% 80 5 71.43% 70 0 100.00% 90 0 0.00% 90 0 100.00%

100 0 0.00% 100 0 100.00% Total 7 100.00%

Tabla 9. Muestra el número de defectos encontrados en Pruebas del Programa 5 al 8.

Diagrama de Pareto Defectos en Pruebas

0

1

2

3

4

5

6

7

40 20 80 10 30 50 60 70 90 100

Tipo de defectos

Frec

uenc

ia

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

Grafica 11. Análisis de Defectos encontrados en Pruebas del Programa 1 al 4. La presente grafica me indica que los defectos en los que tengo que poner mayor atención son el tipo 40, ya que al eliminarlos, estaría disminuyendo un 75.00 % de los defectos que se presentan al realizar las pruebas de mis programas.

Diagrama de Pareto Defectos en Pruebas

0

1

2

3

4

5

6

80 40 20 10 30 50 60 70 90 100

Tipo de defectos

Frec

uenc

ia

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

Grafica 12. Análisis de Defectos encontrados en Pruebas del Programa 5 al 8.

La grafica me indica que los defectos en los que tengo que poner mayor atención son el tipo 80, ya que al eliminarlos, estaría disminuyendo un 75.00 % de los defectos que se presentan al realizar las pruebas de mis programas.

Numero de defectos del Programa

Tipo de Defecto 1 2 3 4 5 6 7 8

100 90 80 3 5 1 70 60 1 50 1 2 2 40 3 1 6 7 4 1 30 20 4 3 10

Total 11 7 6 0 14 1 4 1

Tabla 10. Muestra el número de defectos encontrados en cada programa. Desde el primer programa los errores cometidos me han servido para ir poniendo énfasis en los siguientes programas por lo que ha ido decreciendo el numero de errores ¿Cuánto cambió la calidad de los programas entrando a las pruebas unitarias? ¿Por qué? La calidad de los programas fue mejorando debido a las adecuaciones en el proceso, en el reporte intermedio necesitaba poner mayor interés en los errores de tipo 40 que eran los que el análisis me especificaba y al parecer este nuevo análisis demuestra que si lo hice, pero que descuide los demás, por lo que resulta que aparecieron los de tipo 80 pero en cuanto al proceso y el análisis se refiere indica que si muestra avances importantes, pero también sugiere que no tengo que descuidar los demás aspectos en los que no tenían problemas.

¿Cómo puedo juzgar la calidad de mi producto final de manera temprana en mi ciclo de desarrollo? El proceso PSP tiene varias medidas de calidad que permiten indicarnos cuando el proceso va por buen camino, refiriéndome a:

• rendimiento (yield)

• tasa de revisión

• defectos encontrados por unidad de tamaño

• defectos introducidos y eliminados por hora

• influencia de la eliminación de defectos

• costo de la calidad (COQ)

Las revisiones y el índice de defectos que se encuentran también son importantes, en mi caso las revisiones de diseño no encuentran muchos errores por lo que seguramente será necesario que adecue mi checklist de diseño esto quizás represente alguna mejora sustancial para reducir aun mas los errores que llegan a la fase de pruebas. ¿Estoy encontrando mis defectos en las revisiones de diseño y código? ¿Por qué si o por qué no? Las graficas mostradas a lo largo del análisis demuestran que las revisiones si han sido productivas, quizás no como yo esperaba, ya que hay unos puntos que tengo que refinar en ellas, pero en cuanto a las medidas de calidad que el proceso marca resulta que si han logrado su cometido. ¿Cómo puedo hacer más efectivo y eficiente mi proceso? Por el YIELD y el A/FR seria una manera de saber si el proceso va mejorando al menos yo lo vi desde ese punto de vista en cuanto hacerlo mas eficiente he mencionado que rehaciendo mi checklist de Diseño y aumentando los tiempos de diseño.

¿Basado en mis datos históricos, ¿cuáles son algunas metas de calidad realistas para mi? En cuanto el análisis que eh venido haciendo me doy cuenta que mi proceso no es del todo mal requiere unas variaciones en las fases de revisión que seguramente tendrán sus mejoras, como se ha venido mostrando. Seguir mejorando mi yield actual considero una meta realista. ¿Cómo puedo cambiar mi proceso para cumplir esas metas? Considero que si dedico más tiempo a Diseño y a su revisión habrá mucho mas mejoras en mi proceso. 2.2.8. CONCLUSIONES Al finalizar la preparación del curso y analizar los resultados intermedios y finales me doy cuenta de los puntos en los que debo poner mas atención, mis estimaciones de tamaño están por encima del 70% de efectividad y los tiempos están por encima del 80% ya que presentan una menor dispersión. En cuanto a los tiempos en fases del proceso un propósito del reporte intermedio era balancear el tiempo de Diseño y Compilación, logre ajustar un poco esos tiempos pero quizás no el fue el suficiente ya que al analizar los defectos encontrados, me doy cuenta que es necesario invertir mas tiempo en las fases de diseño y revisión, por que los errores encontrados, casi siempre eran lógicos, en los cuales me llevaba mas tiempo la eliminación de estos, por lo que considero prudente hacer las correcciones necesarias antes mencionadas. En defectos inyectados los análisis de Pareto me sirvieron para saber en cuales defectos poner más atención para disminuir mis tiempos, aunque en la práctica siempre aprendo de mis errores e intento no cometerlos de nuevo por lo que no subestimo ningún error que tenga pero si pondré mas énfasis en los resultados de Pareto.

La productividad la considero engañosa ya que las fluctuaciones pasaban cuando había requerimientos totalmente nuevos a los anteriores aunque después ya no fluctúo tanto no me sentí tan a gusto como debería serlo pero es obvio que se ve reflejada la experiencia ganada en todos los programas anteriores. La variación que se tiene en cuanto al reporte intermedio y el final, se debe a las mejoras y a las fases que se agregaron al proceso, las revisiones son filtros para eliminación de defectos en etapas tempranas del desarrollo, estos filtros mejoran la calidad del programa y hacen que lleguen menos errores a siguientes etapas, como mencione anteriormente, aun tengo ligeros problemas en Diseño y Revisión de Diseño por lo que modificare mis Checklist y mejorare esas etapas para continuar con la mejora de mi proceso personal. Me parece que el proceso si marca las bases para hacer nuestros propios

• Planes personales. • Métodos de planeación. • Métricas calidad.

La formación obtenida en el proceso de desarrollo de software es gratificante.

3. TEAM SOFTAWARE PROCESS ( TSPSM) 3.1. INTRODUCCIÓN Los equipos son necesarios para la mayoría de los proyectos de ingeniería. El software no es una actividad aislada tal que no se tiene que trabajar solo, la escala y la complejidad de los sistemas actuales es tal que no resulta práctico para una sola persona hacer todo el trabajo de ingeniería necesario. El desarrollo de sistemas es una actividad de equipo, y la efectividad del equipo determina la calidad del sistema. Un equipo es más que un grupo de personas que trabajan juntas. El trabajo en equipo necesita práctica y requiere de habilidades especiales. Los equipos necesitan procesos comunes, metas acordadas y un líder efectivo. El Team Software Process (TSP) está diseñado para establecer las condiciones que caracterizan a los equipos efectivos. Los principios utilizados en el TSP para la formación de equipos son los siguientes:

• Los miembros del equipo establecen metas comunes y definen los roles.

• El equipo desarrolla una estrategia.

• El equipo define un proceso común para la realización del trabajo.

• Todos los miembros del equipo participan en la realización del plan de trabajo, y cada

miembro conoce su rol en el plan.

• El equipo negocia el plan con la dirección.

• La dirección revisa y acepta el plan generado.

• El equipo hace su trabajo de acuerdo al plan.

• Los miembros del equipo se comunican libre y continuamente.

• Los ingenieros saben su estado y reciben retroalimentación acerca del trabajo que

están realizando.

El TSP es una metodología para guiar y construir equipos de ingeniería efectivos que desarrollan software. Antes de que un ingeniero pueda participar en un equipo TSP, se debe haber recibido entrenamiento en PSP, ya que el entrenamiento incluye aprendizaje para hacer planes detallados, recolección y uso de datos, desarrollo de planes de valor generado, medición y manejo de la calidad de un producto y la definición de procesos (Véase Figura 3).

Figura 3. Estructura del proceso TSP. La figura anterior muestra la estructura del proceso como es notable mantiene una correlación con la estructura del PSP por eso es indispensable que los integrantes tengan esta formación las variaciones que vemos radica en las fases que se agregan como son Diseño de alto nivel, inspecciones pruebas de integración y de sistema.

Planeación Desarrollo Filtro Defectos Postmortem

3.2. LANZAMIENTO DE UN EQUIPO TSP Una vez que los miembros de un equipo están entrenados en PSP y el equipo ha sido formado, este se encuentra listo para el lanzamiento del TSP. El lanzamiento consta de nueve juntas,(Véase Figura 4):

Figura 4. Juntas del Lanzamiento del Equipo TSP. La siguiente estructura muestra el objetivo de cada una de las juntas que se hacen a lo largo del lanzamiento en 4 días tiempo completo, el propósito de estas radica en la elaboración del plan y la gestión de este, que permita trabajar con calidad, incluso frente a presiones graves de la administración u otras eventualidades.

A continuación se mencionan los roles que hay dentro de un equipo TSP: Líder del Equipo: Sirve como el administrador del equipo y del proyecto.

• Obtiene la integración del proyecto, hace las asignaciones de trabajo, aprueba planes, reporta el estado y hace los arreglos para el soporte que sea necesario.

• Encabeza las juntas de lanzamiento y relanzamiento. • Apoya y guía a los miembros para que hagan su trabajo.

Administrador de la Interfaz con el Cliente: Administra los aspectos de requerimientos y cambios.

• Se asegura que todas las suposiciones de requerimientos estén verificadas. • Encabeza los planes de facilidad de uso, instalación, documentación y entrenamiento.

Administrador del Diseño: Encabeza el trabajo de diseño y controla los cambios al diseño.

• Define los estándares de diseño y especificaciones.

Administrador de la Implementación : Encabeza el trabajo de implementación.

• Define los estándares de implementación, tamaño y desempeño. Administrador de la Planeación: Guía la estimación, la planeación, seguimiento y administración de riesgo.

• Establece la línea de trabajo estándar de planeación utilizada para desarrollar los planes personales y de equipo.

• Consolida los planes de los ingenieros en el plan general del equipo.

Administrador del Proceso: Encabeza el trabajo de proceso y definición de procedimientos.

• Administra el proceso de las PIP. • Es propietario y mantiene los procesos del equipo.

Administrador de la Calidad: Desarrolla y sigue el plan de calidad y analiza los datos de calidad.

• Modera (u obtiene un moderador) las inspecciones del equipo. • Alerta al equillo y a la dirección de posibles problemas de calidad.

Administrador de Soporte: Establece el sistema de desarrollo.

• Opera los sistemas de administración de la configuración, administración de cambios y seguimiento de pendientes.

Administrador de las Pruebas: Asegura que los aspectos de pruebas sean considerados en todas las fases.

• Guía la planeación, edición, seguimiento y administración de las pruebas. Después de que se lanzó un equipo TSP, la necesidad principal es que todos los miembros del equipo sigan el plan. Esto incluye los siguientes puntos:

• Liderar al equipo. El líder es responsable de guiar y motivar a los miembros del

equipo, tratar con el usuario y con la dirección. Pero sobre todo, su principal

responsabilidad es mantener la motivación y la energía del equipo y asegurarse de

que el trabajo se está haciendo bien.

• Comunicación. Todos los miembros del equipo deben de saber el estado del proyecto

y saber lo que los demás miembros están haciendo. Para esto se realizan juntas

semanales en las cuales el líder informa del estado del proyecto y asuntos

relacionados con la dirección. Además los otros miembros reportan las actividades

realizadas la semana anterior, las tareas planeadas para la siguiente semana, las

actividades asignadas a su rol y los riesgos que se pudieron haber presentado

durante la semana.

• Mantener el plan. Para hacer esto se utiliza el valor generado, el cual ayuda al equipo

a saber exactamente “donde está parado” y ayuda a la dirección a comprender lo que

se necesita hacer para completar el trabajo a tiempo.

• Re-balancear la carga de trabajo. Esto es necesario cuando un miembro del equipo

tiene más trabajo que los demás. Durante la realización de las juntas semanales

puede tratarse este punto y en caso de ser necesario hacer el balance de tareas.

4. PROYECTOS 4.1. INTRODUCCIÓN

En la actualidad muchas vidas y negocios dependen del software. Ahora necesitamos sistemas de software más grandes, más complejos y más seguros en tiempos predecibles. Pero no podrá ser posible hasta que se maneje una forma diferente de producir software; el Team Software Process (TSP) atiende esta necesidad. El objetivo inicial del TSP es convencer a la administración para que su equipo esté autodirigido. Un equipo autodirigido define sus propios objetivos, establece sus propios roles, decide su propia estrategia de desarrollo, define su propio proceso, desarrolla sus propios planes, mide, administra y controla su propio trabajo. Para ello el equipo debe de mantener planes precisos y exactos, medir y darle seguimiento a su trabajo; además de manera regular debe de mostrar a la administración que se está haciendo un trabajo superior. El nombre del equipo fue “Equipo integrador” y se encuentra formado por 6 integrantes. Normalmente los proyectos realizados en la UAMI acerca del proceso TSP se basan en la realizar un solo proyecto; en esta ocasión el equipo integrador se dio a la tarea de realizar 4 proyectos al mismo tiempo. El objetivo de realizar 4 proyectos guiados mediante el proceso TSP, fue para que el equipo aprendiera a integrarse fácilmente a cualquier proyecto a pesar de desconocerlo por completo, con ello cada integrante del equipo obtendrá una mayor capacidad de adaptación ante cualquier proyecto en cualquier fase de desarrollo. Un objetivo que se busco alcanzar fue que al finalizar el lanzamiento cada miembro conoce los alcances de todos los proyecto. Otro de los objetivos es enriquecer cada proyecto mediante el involucramiento de todos los integrantes. El manejo de 4 proyectos es muy complicado, por ello el equipo decidió realizar una Arquitectura Común para poder cubrir el problema y mantener a todos los miembros

involucrados. Una arquitectura basada en una plataforma Web, donde cada proyecto puede tomar lo que le sea útil para implementarlo en sus arquitecturas. A continuación se describen una breve introducción a los 4 proyectos que fueron realizados así como sus alcances y objetivos. 4.1.1. SISTEMA DE ADMINISTRACIÓN PIGMEX

PIGMEX es una empresa dedicada a la crianza de puercos, para ello es necesario formar Biodigestores. Los cuales son fosas que deben de tener cierto tamaño según el número de animales en la granja; en ellos se arrojan los desechos, y con la ayuda de otras tecnologías se podrán utilizar los residuos como energía y otros recursos. Algunos de estos gases son generados por los desechos de los puercos en las granjas, para ello es necesario aplicar medidas preventivas para usar esos desechos como una fuente de energía y además reducir las emisiones de CO2 a la atmosfera producto de las granjas porcinas. En la actualidad PIGMEX cuenta con un sistema que es capaz de generar todos los datos que se necesitan para crear un Biodigestor; sin embargo es un programa desarrollado en una herramienta poco convencional “Microsoft Excel”. Actualmente este sistema ha tenido aproximadamente 80 actualizaciones, las cuales fueron realizadas por usuarios no especializados en la materia, lo cual ha traído muchos errores para la creación de los Biodigetores. El sistema de PIGMEX básicamente es una calculadora electrónica, El porcicultor debe de accesar todos los datos de su granja como número de animales, alimentación, etc. Como resultado el programa muestra los datos básicos que debe de tener el Biodigestor según la entrada proporcionada. Este sistema fue mejorado como una aplicación desarrollada en java por un equipo TSP anterior. La tarea del equipo integrador consiste en retomar este proyecto para aumentar el número de funcionalidades actuales.

Las funcionalidades que se deben tener el nuevo sistema son:

• Implementar al sistema la calculadora del Biodigestor. • Crear manuales de usuario para el sistema. • Migrar la aplicación de escritorio a una aplicación Web.

4.1.2. SISTEMA DE FACTURACIÓN DEL SAT La facturación electrónica es un método de facturación que utiliza tecnología digital para generar y resguardar comprobantes fiscales digitales. Cada factura que se emite cuenta con un sello digital, así como un folio que indica el número de la transacción que le permite a la Secretaria de Hacienda y Crédito Publico mantener un control ordenado y seguro de las facturas. Las facturas electrónicas pueden ser enviadas y guardadas utilizando medios electrónicos. La factura electrónica es un documento que comprueba la realización de una transacción comercial entre un comprador y un vendedor. Se necesita un programa que genere las facturas electrónicas según las especificaciones emitidas por el Servicio de Administración Tributaria, plasmadas en el Anexo 20.

• Para la primera versión del sistema es necesario generar las facturas tanto impresas como electrónicas, así como poder modificar el precio de los productos según las necesidades del emisor de la factura.

• Para una segunda versión del sistema es necesario poner un catalogo de clientes y un catalogo de productos, de esta manera el emisor podrá seleccionar los productos y clientes a facturar.

Para generar una factura electrónica es necesario que el cliente tenga una llave privada, que servirá como mecanismo de seguridad; Así como los datos del cliente, emisor y productos. La factura creada es un archivo .XML el cual contendrá los datos básicos de la factura, folio, domicilio, etc. así como el sello original definido en el Anexo 20.

El encargado para brindarnos la información del sistema fué el Dr. Eduardo Rodríguez de la Universidad Autónoma Metropolitana. 4.1.3. SISTEMA DE ADMINISTRACIÓN CAMELIA RESEARCH

Camelia Research es el nombre de una empresa francesa dedicada a la investigación de la fauna marina y silvestre en zonas costeras. Esto lo hacen mediante el uso de maquinas especializadas para recoger muestras del suelo acuático y terrestre, una vez que se recolecta los datos, estos son llevados a un sistema implementado en Microsoft Access. La empresa identifico las limitaciones del sistema actual (ya se alcanzó el limite de la duración de vida) y ya no se piensa que se pueda seguir expandiendo el sistema actual que data del 2001. Esto fue debido a que ya existen mejores herramientas para administrar sistemas como este, además cuando se hizo el sistema, no era factible acceder el sistema a distancia. El intermediario entre El equipo integrado TST y el proyecto es el administrador de sistema el francés “Pascal Douillet”, encargado de brindar la información necesaria para la elaboración de la renovación del sistema. La idea principal de este proyecto es renovar el sistema viejo a uno nuevo con nuevas ventajas. Las metas de la organización con respecto a este proyecto son:

• Eficacia, en el sentido de tener un sistema más seguro, más mantenible. • Que el sistema sea usado por más gente al tener un producto más fácil de usar y de

más calidad. • Tener nuevas funcionalidades en el sistema. • Aprovechar que se puede trabajar con gente experta en desarrollo de software para

poder tener un sistema documentado, esto permite que el sistema se renueve. Y que otras personas puedan retomar el desarrollo en un futuro.

• Centralizar todos los datos recopilados durante las investigaciones en una base de

datos centralizada. De esta manera todos los usuarios podrán tener la información actualizada.

4.1.4. SISTEMA DE ADMINISTRACIÓN PARA VIDEO-BAR En la ciudad de México hay lugares de entretenimiento que muestran en sus pantallas videos musicales, con publicidad. Debido a la dificultad para manejar la programación de sus pantallas es necesario crear un sistema que administre este aspecto vía remota. De esta manera el cliente puede pedir una lista de reproducción automática con videos, según las preferencias de la gente, o región geográfica del país, para reproducir en su establecimiento. Actualmente el sistema que se utiliza, es muy viejo y difícil de utilizar, además obliga a que una persona siempre este al pendiente del sistema para poder cambiar las peticiones que el publico demanda. Con la ayuda de las listas de reproducción automática no será necesario que un usuario reproduzca canción por canción, así como video y publicidad. Todos los videos son descargados en un servidor, desde el cual se programara la lista de reproducción, así como su publicidad, mensajes, lugar, fecha y hora. Mostrados en las pantallas del establecimiento. Cuando se muestren los videos es necesario dividir la pantalla en 3 partes. Video, publicidad y mensajes. Este sistema contiene muchas funciones que son tomadas de la arquitectura común1, por lo que sus requerimientos aportaran gran parte a los demás proyectos.

1 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\MaterialJuntasDeLanzamiento\Juanta3\Junta3_1.pptx

Perfil del Proyecto TSP

1. Nombre del proyecto. Multiproy

2. Descripción y estado del proyecto. Se pretende que un equipo TSP trabaje en paralelo con 4 proyectos distintos, siguiendo el

proceso TSP y un mismo lanzamiento para estos 4 proyectos distintos, necesitaremos de una arquitectura común que facilite la reutilización de módulos y mantenga al equipo involucrado en todos los proyectos.

a. CAMELIA : Es un sistema de administración de bases de datos costeras

• El sistema actual esta hecho en ACCES además de haber alcanzado el limite de su ciclo de vida se desea migrar el sistema a uno que soporte las nuevas tendencias tecnológicas que facilite el uso y acceso remoto al mismo, la documentación es muy importante ya que así el sistema podrá ser mantenible aumentando su ciclo de vida.

b. PIGMEX : Calculadora para un Porcicultor

• Actualmente se cuenta con un programa realizado en Excel se desea cambiar a un sistema basado en JAVA manteniendo las funcionalidades del sistema actual

• Automatización de proceso BioDigestor para ayuda de toma de decisiones ( No se cuenta con nada)

• Arquitectura Web (Internet) para la consulta e interacción con los datos del programa (Rehacer la capa de presentación para WEB).

c. FACTURACION ELECTRONICA: Sistema standalone para facturación electrónica los

datos básicos necesarios para generar el sello digital están especificados en el anexo 20 del SAT.

d. VIDEO : El sistema de Video controlara la programación de videos así como también el

mantenimiento de las listas de reproducción de manera remota

3. Nombres de todos los ingenieros en el proyecto y su estado de entrenamiento de PSP. (Para cualquier ingeniero que no haya completado el entrenamiento PSP, favor de proporcionar la fecha de cuándo se planea que concluya.)

• Angel Wingartz Carranza • Diego Montiel Juárez • Rosendo Esparragoza Hernández • Emmanuel Jiménez Almazán • Raziel Carvajal Gómez • Jesús Galván Peralta

4. Nombre del líder del proyecto y el entrenamiento de administración de PSP que ha completado. (Si el líder no ha recibido el entrenamiento de administración de PSP, favor de proporcionar la fecha cuando este entrenamiento esté planeado.)

• Diego Montiel Juárez

5. Nombre, teléfono, dirección de oficina y correo electrónico del coordinador del lanzamiento

• Dr. Humberto Cervantes Maceda • Ing. Luis Castro Careaga

UNIDAD IZTAPALAPA Av. San Rafael Atlixco No. 186, Col. Vicentina, Iztapalapa, México, D.F. C.P. 09340, A.P. 55-534 Tels.: 5804-4630, 4634, 4635, 4636, 4903, 4904 ó 4905 ext. 203 FAX: 58044640 EDIFICIO T 143, T 138

5. LANZAMIENTO TSP MULTIPROY El proceso de TSP sirve para guiarnos a lo largo de la planeación y conducción de un proyecto de software. El propósito del lanzamiento es la elaboración del plan del equipo y su gestión, que nos permita tener la capacidad de trabajar con calidad, incluso frente a presiones graves de la administración u otras eventualidades. A continuación se presentan los productos resultantes del Lanzamiento del proyecto: 5.1. JUNTA 1 Establecer los Objetivos de Negocio y de Producto. Propósito: En esta junta un directivo con el conocimiento correspondiente, presenta el producto o la entrega del producto a ser generado. El objetivo es proporcionar a todos los miembros del equipo un entendimiento común de lo que se espera del futuro proyecto. En esta junta el equipo identifico las expectativas del producto. Esto se logro en la entrevista que se tuvo con el representante de la dirección y de comercialización quienes compartieron su opinión referente a las expectativas del proyecto. La Tala 11. Presenta los temas tratados por el líder durante la junta 1.

CUESTIÓN CLIENTES

1. Quién es el cliente PIGMEX CAMELIA VIDEOS FACTURACION

2. Por qué el cliente desea el producto y que es lo que el cliente pretende hacer con él

Facilitar el uso y la redundancia de muchas funcionalidades del sistema actual.

Sistema accesible vía Web para consulta e interacción con el porcicultor.

Eficacia, en el sentido de tener un sistema más seguro y más mantenible.

Que el sistema sea usado por más gente al tener un producto más fácil de usar y de mayor calidad.

Tener nuevas funcionalidades en el sistema.

Desea un espacio publicitario en sus pantallas y así tener una remuneración de este.

Le interesa poder facturar electrónicamente y todo lo que esto conlleve.

3. Las principales funciones del producto

Automatización de proceso BioDigestor para ayudar en la toma de decisiones

Importar datos (ASCII) Visualizar Campaña Zona geográfica Cuadro geográfico Estaciones Exportar Imprimir

Administración de Playlists. Descarga de nuevos videos. Redimensionamiento de los videos y

la publicidad en el monitor de reproducción.

Reproducción simultanea de videos y publicidad en el mismo monitor de reproducción

Sistema standalone para facturación electrónica los datos básicos necesarios para generar el sello digital (están especificados en el anexo 20 del SAT).

4. El conjunto ideal de las funciones y características del producto

Automatización de proceso BioDigestor para ayuda de toma de decisiones.

Además de las características faltantes de la 1era iteración.

Generar un sistema más robusto que el precedente (que incorpore aspectos tales como seguridad, acceso remoto, internacionalización).

Si se dispone de las mismas funcionalidades que en la aplicación original.

Si se dispone de funcionalidades adicionales. Si se dispone de un sistema documentado

(en inglés) que permita que otras personas puedan retomar el desarrollo en el futuro.

Si aumenta el número de usuarios del sistema (actualmente hay ~20, el doble sería

Administración de Playlists. Descarga de nuevos videos.

Control del numero de facturas. Control de usuarios.

CUESTIÓN CLIENTES

ideal).

5. El conjunto de las funciones y características del producto mínimas aceptable

Arquitectura ejecutable final Modulo Principal Modulo Despliega Consultas Versión final de la interfaz Versión final de Base de Datos Versión final de Tabla 2 Versión final de Tabla 3 Modulo Captura Datos Capa de Interfaz Capa de Negocios Modulo Carga Datos Modulo Imprimir Consultas Modulo Ayuda de cada tabla

Arquitectura + documentación. Base sólida para el desarrollo futuro.

Administración de Playlists. Descarga de nuevos videos.

Sistema standalone para facturación electrónica los datos básicos necesarios para generar el sello digital están especificados en el anexo 20 del SAT

Tabla 11. Temas abordados por el líder.

Después de esta presentación, el equipo aprecio los deseos de la dirección y de los clientes/usuarios; así mismo comenzamos a proceder con la planeación del desarrollo y mejorar los compromisos negocio/funciones/tecnología a lo largo del proyecto para generar un producto más deseable. Los miembros del equipo también anticipan y controlan mejor los problemas no previstos, además de capitalizar mejor nuevas oportunidades y buscarán la guía apropiada cuando sea necesario. Productos generados2

Forma MTG (Reporte de la junta), PIP (sugerencias de mejora al proceso), ITL (Pendientes y Riesgos).

2 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\MaterialJuntasDeLanzamiento\Junta2

5.2. JUNTA 2 Asignación de roles y definición de objetivos del equipo Propósito: Revisar las metas de la dirección y los objetivos del producto con el equipo. El equipo refino los objetivos de la dirección y agregamos los nuestros, la siguiente tabla presenta la manera en que fueron asignados los roles a cada miembro del equipo. Roles de los miembros del Equipo Miembros del Equipo

Adm

inis

trado

r de

la In

terfa

z

con

Clie

nte

Adm

inis

trado

r del

Dis

eño

Adm

inis

trado

r de

la

Impl

emen

taci

ón

Adm

inis

traci

ón d

e la

Plan

eaci

ón

Adm

inis

traci

ón d

el P

roce

so

Adm

inis

traci

ón d

e la

Cal

idad

Adm

inis

trado

r de

Sopo

rte

Adm

inis

trado

r de

Prue

bas

DBA

Líde

r del

Equ

ipo

Angel Wingartz Carranza 1 1

Diego Montiel Juárez 2 1 1

Emmanuel Jiménez Almazán 2 2 1 2

Jesús Luciano Galván Peralta 1 1

Raziel Carvajal Gómez 1 2 2

Rosendo Esparragoza Hernández 2 2 1

Tabla 12. Roles del equipo TSP. Productos generados23

Forma MTG, PIP, ITL, GOAL, ROLE.


5.3. JUNTA 3 Generar una Estrategia de Desarrollo Propósito: Generar la estrategia y proceso de desarrollo, además del plan de soporte. El líder se encargo de que el equipo defina los productos de trabajo a producir, para la fase o ciclo inmediato y todas las fases o ciclos subsecuentes. Estos elementos son registrados en la forma SUMS. Los ejemplos incluyen:

• Lista priorizada de correcciones al producto existente. • Documentos y especificaciones de requerimientos. • Documentos y especificaciones de diseño. • Prototipos. • Elementos o componentes principales del producto. • Manuales de instalación, usuario y mantenimiento. • Programas, guiones, datos y planes de pruebas.

Como parte de la estrategia de desarrollo se elaboro un esquema conceptual de cada proyecto, el plan de soporte, plan de proceso, así como la definición de las tareas de los proyectos. Para ello se generaron la forma STRAT, que hace referencia a los estimados de tamaño para los módulos del conjunto de tareas que se van a codificar para el proyecto y la forma INV, que es un inventario el cual tiene los documentos TSP necesarios (guiones, formas, estándares, etc.), para las diferentes fases del proceso. La estrategia de desarrollo consistió en implementar todos los componentes del sistema a lo largo de 4 iteraciones, en la primera iteración se desarrollarían el 70% de los módulos correspondientes a la arquitectura común entre los proyectos. En la segunda iteración se desarrollara por completo la arquitectura, y se obtendrá el sistema de Facturación al 100%, en esta iteración se empezara con el proyecto de Camelia y video. En la tercera iteración se desarrollara el sistema de video al 100%, y en la cuarta iteración se desarrollara el sistema de Camelia al 100%.

Productos generados4 Forma MTG, PIP, STRAT (estrategia de desarrollo), SUMS (lista de productos a ser generados), planes de proceso y de soporte (forma INV), Asuntos pendientes ITL, Esquema conceptual de cada proyecto. 5.4. JUNTA 4 Elaboración Descendente del Plan Propósito: Guiar al equipo en la producción del plan general. El administrador del diseño encabezo al equipo en la estimación de cada elemento en la forma SUMS. Registrando los estimados en SUMS.

• Páginas de requerimientos, clases de diseño, páginas de diseño de alto nivel, formas de pantallas, reportes, páginas de documentos de texto. • LOC de programas, LOC de casos de pruebas, datos de prueba y operacionales

Productos generados5 Forma MTG, PIP, SUMS, plan de valor ganado (formas TASK y SCHED). 5.5. JUNTA 5 Desarrollo del Plan de Calidad Propósito: Guiar al equipo en la producción del plan de calidad. El administrador de la calidad guío al equipo en una revisión de las metas de calidad (forma GOAL). Usando las guías de calidad y formas SUMP y SUMQ, el administrador de la calidad guío al equipo en la estimación de los defectos a ser introducidos por fase. Los defectos introducidos planeados para la fase P son estimados como las horas planeadas para la fase P por la tasa de introducción de defectos por hora para la fase P.



Defectos introducidosp = Tiempo en fasep × Tasa de introd. de defectosp Como no hay tasas de defectos de introducción por fase, el equipo hizo su mejor estimado, puesto que no hay históricos. Usando las guías de calidad y formas SUMP y SUMQ, el administrador de la calidad guío al equipo en la estimación de los defectos a ser eliminados por fase. • El número de defectos eliminados en una fase es el rendimiento de eliminación de defectos por los defectos presentes en esa fase dividido entre 100. • Defectos eliminadosp = Def. presentes en fasep × Rend. fasep / 100 • Los defectos presentes en fase son el total de defectos introducidos hasta el final de la fase menos el total de defectos eliminados antes de haber entrado a la fase. • Def. presentes en fasep = Def. introducidos(1...p) – Def. eliminados(1..p – 1)

Como no contamos con históricos de rendimientos disponibles, el equipo hizo su mejor estimado. Productos generados6 Forma MTG, PIP, SUMQ, SUMP.


5.6. JUNTA 6 Elaboración de planes individuales y del equipo de la siguiente fase Propósito: Ayudar al equipo a producir un plan balanceado para la siguiente fase El equipo y el líder reviso las tareas de la siguiente fase y fueron asignadas entre los miembros del equipo. El equipo hizo el balanceo de carga durante la asignación de tareas.

• Para mantener una carga de trabajo balanceada mientras se asignan las tareas, el equipo trabajo a lo largo del plan una semana a la vez. • Se acordó qué miembro del equipo realizará cada tarea. • Manteniendo una carga de trabajo balanceada entre los miembros del equipo.

Después se determinó el tiempo de dedicación al proyecto por integrante, se asignaron 9 horas de trabajo a 4 integrantes, dos personas tenían asignadas 18 horas, dando un total de 72 horas de trabajo dedicado al proyecto semanalmente. De esta manera se genero el plan que se debía de seguir en todo el proyecto, asignando las tareas a los integrantes del equipo, en función del rol que cada uno de ellos tenía asignado, así como por habilidades de cada uno de ellos, este plan permite definir las posibles fechas de terminación para el proyecto. Para finalizar la junta el administrador de la planeación tuvo que hacer la revisión de los planes propuestos por cada miembro, evaluando que se cumplan los criterios de calidad, resolviendo conflictos, duplicaciones y conflictos, de esta manera se obtuvo un calendario de trabajo completo, así como un plan consolidado de trabajo. Además se generaron las copias para los integrantes del equipo Productos generados7 Forma MTG, PIP


5.7. JUNTA 7 Conducción de la Evaluación del Riesgo Propósito: Guiar al equipo a lo largo de una evaluación de riesgos del proyecto. El líder del equipo nos guío en la identificación de riesgos .

• Todos los miembros del equipo participamos en sugerir riesgos. • Usando un enfoque de lluvia de ideas; i.e., en este paso no evalúe riesgos.

Para cada riesgo, el equipo evalúo su impacto probable.

• El impacto es alto si el efecto sobre el calendario de trabajo del proyecto fuera importante. • Los riesgos también pueden tener impacto medio o bajo en el calendario de trabajo. Para cada riesgo, el equipo juzgo su probabilidad. • La probabilidad se mide como alta, media o baja.

Todo esto documentando en la forma IRLT que presenta los riesgos identificados en el proyecto y su probabilidad de que ocurran.

Productos generados8 Forma MTG, PIP, IRLT 5.8. JUNTA 8 Preparar Presentación a Dirección y Reporte de Lanzamiento Propósito: Guiar al equipo en la preparación de la junta con la dirección. El equipo reviso el proceso de lanzamiento y los productos del mismo, así como el plan del proyecto, cuando surgieron algunas dudas o situación con este plan el encargado trato la pregunta, pero la finalidad siempre era demostrarle a la dirección que hicimos un plan pensado, realista y completo.


Productos generados9 Forma MTG, PIP, Presentaciones individuales de los proyectos. 5.9. JUNTA 9 Revisión con la alta dirección Propósito: Guiar al equipo a lo largo de la junta final del lanzamiento con la dirección. El equipo reviso junto con la dirección el plan de proyecto y cualquier pregunta o situación que surgieron sobre el plan fueron contestadas, el plan puede que no haya cubierto por completo las metas de la dirección, pero se basa en muchos estimados y suposiciones, el equipo piensa que es el mejor plan que pudimos producir siendo que hay una cantidad de cosas que no se conocen en este punto tan temprano en el proyecto, por lo que se han examinado algunas actividades claves, este plan es agresivo, y esperamos a que la dirección aprobara el plan. Al final de la junta, la dirección entendió el plan, y esta satisfecha de saber que es el mejor plan que el equipo puedo producir y sabe que el equipo están comprometido para cumplirlo. Productos generados10 Forma MTG, PIP, Plan individual de cada proyecto.



5.10. POST MORTEM DEL LANZAMIENTO El administrador de la planeación reviso los datos del lanzamiento para asegurar que todos los datos requeridos del lanzamiento fueran recolectados y registrados apropiadamente en las formas apropiadas, la responsabilidad que se le fue asignada es la preparación de los materiales del lanzamiento, para su introducción al cuaderno de notas del proyecto (NOTEBOOK) El equipo y el líder completaron las formas de evaluación del lanzamiento del equipo (LAUTEAMEVAL) y se envía una copia de estas formas al SEI. El coach del lanzamiento completo la forma de evaluación del lanzamiento y envía una copia de esta forma al SEI.

6. SEGUIMIENTO DEL PROYECTO Una vez que la dirección aprobó el plan realizado en el lanzamiento del equipo TSP, se iniciaron las actividades descritas en el plan, el día 15 de Julio de 2009 con fecha de terminación 24 de Agosto 2009.Se acordó con los directores alcanzar los siguientes objetivos:

1. Construcción de una Arquitectura común que soporte las funcionalidades de los diferentes proyectos Vía Web, dicha estructura será capaz de atender requerimientos de los proyectos, que no se contemplarán en esta versión del producto, realizar grandes cambios en la misma.

2. Implementación de administración de usuarios, utilizando un mecanismo de

autenticación para usuarios registrados.

3. Cubrir el total de requerimientos del sistema de Facturación. El procedimiento que propone el proceso TSP para dar seguimiento en el ciclo de vida del proyecto, es la realización de juntas semanales con todos los integrantes del equipo, para administrar los avances, problemas, riesgos y sucesos inesperados del proyecto. Para llevar un control en el transcurso de la junta, los miembros del equipo designan a una persona que tome el rol de cronometrista, para llevar los tiempos de los temas que se encuentran agendados en la junta, así como un anotador que se encargue de registrar los acuerdos que el equipo definió, los responsables que darán seguimiento en las fechas acordadas y el líder que se encarga de dirigir la junta. Es importante mencionar que todos los integrantes del equipo cursaban asignaturas de los últimos trimestres de la licenciatura en computación de la UAM-I. Las junta semanales tienen como objetivo establecer una comunicación continua al equipo, para dar seguimiento puntual al estado del proyecto, permitir que cada integrante del equipo aprecie las aportaciones que realiza, así como establecer un control preciso del proyecto, dicha junta es dirigida por el administrador que corresponda y apegándose al guión semanal TSP, cada integrante del equipo entrega la copia del libro TSP al administrador de

planeación, en éste libro se encuentran las actividades que el integrante realizó, sus tiempos de desarrollo, sus registros de tiempos, así como sus registros de defectos. En una junta semanal típica del proceso TSP cada integrante prepara una presentación para exponerla ante el equipo, con el siguiente contenido:

• Reporte del administrador TSP : El responsable debe de explicar cuales son los cambios que afectan directamente al proyecto relacionado con su rol, si los cambios ocurrieron tiene que iniciar una lluvia de ideas que permita ofrecer una solución por todos los integrantes del equipo, pero el responsable será el que de seguimiento a los acuerdos que se alcanzaron.

• Reporte de riesgos: Dado que un riesgo es un evento que puede o no ocurrir,

es necesario que se de un reporte del estado para el conjunto de riesgos a los que el responsable se comprometió dar seguimiento. El equipo evalúa el impacto de los problemas que genera la ocurrencia de un riesgo, propone actividades que se tienen que considerar en el plan del proyecto, para la construcción de planes de mitigación.

• Reporte de actividades: Conjunto de actividades que el integrante desarrolló

en la semana actual, ofreciendo su punto de vista cuando lo considere conveniente o en las actividades que tengan dependencias con otras, es necesario que presente si los objetivos planeados comparados con los reales fueron cumplidos, en función del número de horas que el integrante había planeado dedicar y el número de actividades terminadas.

• Plan para la siguiente semana: Es necesario que el responsable realice un

pequeño plan personal para la próxima semana, mismo en el que se debe mencionar el número de horas que se tiene estimado dedicarle al proyecto, es opcional que se ofrezca una justificación. Esto permite evaluar la realización de cambios al plan, para gradualmente alcanzar los objetivos de la dirección y el equipo.

Posteriormente el administrador de planeación realiza una consolidación de los datos de todos los integrantes, para ofrecer los avances a los que se llegaron en la semana

correspondiente a nivel equipo, en función de dichos resultados el equipo de desarrollo puede hacer ajustes a los parámetros en plan del proyecto(teniendo siempre presente los rangos que el proceso TSP ofrece en si libro de trabajo), con el objetivo de que el conjunto de actividades realizadas aproximadamente sean las que se han planeado, en tiempo y forma. Por lo tanto cuando una junta semanal termina, se tienen contemplados los siguientes puntos:

• Realizar ajustes al plan para alcanzar los objetivos que se evaluarán la semana entrante (siempre y cuando sea necesario).

• Se han generado los libros de cada integrante. • El libro con la información consolidada del proyecto. • La forma semanal completa del proceso TSP, al menos una forma PIP (propuesta de

mejora al proceso TSP). • El conjunto de entregables que generan las actividades que a cada integrante le

correspondieron en dicha semana. 6.1. INSPECCIONES EN TSP El equipo de desarrollo tiene como meta generar un producto de alta calidad que satisfaga los requerimientos de los diferentes proyectos utilizando el proceso TSP, mientras en el PSP solo existen las revisiones personales de los entregables para identificar los defectos que pudiesen encontrarse, ahora se implementa la fase de inspecciones en las disciplinas de requerimientos, diseño de alto nivel, diseño detallado, codificación y pruebas, para cada entregable que se genere, en dichas disciplinas a lo largo del proyecto. El asesor del curso presento a todos los integrantes de equipo una explicación detallada de los objetivos que persiguen las inspecciones del proceso, es necesario utilizar el guión que el proceso propone para llenar la forma INS, misma que se genera por los inspectores cuando lleven a cabo su revisión. Un criterio de entrada para la programación de una junta de inspección, es que el productor haya generado un entregable y que haya realizado una revisión personal del mismo, en seguida el productor envía el entregable al administrador de calidad, para que este realice

una revisión (si encuentra defectos importantes se lo hace saber al productor) y determine que es posible organizar la junta con los inspectores asignados, según el plan del proyecto. Cuando una junta de inspección se lleva a cabo es guiada por el administrador de calidad y el productor, junto con los inspectores que se darán a la tarea de encontrar posibles defectos (TSP propone que sean dos personas, pero el equipo determino 3 personas), no se lleva un control de tiempo ni de agenda de la junta. El productor hace una explicación sobre el contenido del entregable, detallando de la mejor manera las partes más importantes y explicando a los inspectores cualquier duda que ellos tuviesen, para un correcto entendimiento. Posteriormente los inspectores fijan una fecha con el productor para poder expresar los comentarios correspondientes en relación a los defectos que se encontraron, siguiendo el proceso de inspección del TSP, para que el productor capture los defectos en su bitácora y los corrija, posteriormente se hace una reunión con el administrador de calidad para corroborar que dichos defectos fueron corregidos, obteniendo un entregable de calidad. 6.2. DOCUMENTOS PARA UN PROYECTO TSP Para que se le de un seguimiento puntual al proceso TSP, es necesario crear un conjunto de documentos que nos ayudarán en la construcción del proyecto, por lo tanto en la planeación del proyecto se agregaron como actividades, la construcción de guiones, estándares y listas de verificación, en seguida se listará el conjunto de documentos y su propósito:

• Guión de requerimientos11: Permite producir una especificación de requerimientos (SRS documento de especificación de requerimientos), completa, válida y exacta.

• Guión de revisión de requerimientos12: Es necesario que el equipo de desarrollo

establezca una única manera para llevar a cabo las revisiones del documento SRS, este guión tiene ese propósito.

• Guión de diseño de alto nivel13: Permite producir una especificación para el diseño de alto nivel (SDS documento de especificación de diseño), completa, válida y exacta.

11 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\GuionesTSP\GUIONREQ.doc

12 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\GuionesTSP\GUIONREVREQ.doc

13 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\GuionesTSP\GUIONHLD.doc

• Guión de revisión de diseño de alto nivel14: Manera para llevar a cabo la revisión del

documento SDS.

• Listas de verificación : El objetivo de estos documentos es que se realice una correcta revisión e inspección para los diferentes documentos que se generan, dando como resultado entregables con el menor número de defectos, las revisiones e inspecciones en las fases del proceso TSP no se puede llevar a cabo sin una lista de verificación, por tanto hay listas de verificación para requerimientos15, diseño de alto nivel16, diseño detallado17 y codificación18, en esta última fase se utilizan las lista de verificación y guión personal para la revisión de los módulos que algún integrante desarrolla.

• Estándares: Cuando se trabaja en equipo es necesario que se establezcan

lineamientos que permitan a todos los integrantes realizar actividades con características homogéneas, como un estándar de codificación19 para los módulos, uno más para contar las líneas de código20, uno de interfaces21 con las que el usuario se comunicará con la aplicación, así como uno de nomenclatura22 para darles nombre a los documentos que se generaran.

6.3. ADMINISTRACION DE LA CONFIGURACION El equipo estableció un repositorio para almacenar toda la documentación que se generó a lo largo del proyecto, la idea es que cada entregable se encuentre en el repositorio además de que se encuentre disponible para todos los integrantes del equipo sea la última versión del mismo y cumpla con los índices de calidad que el TSP establece. Por lo tanto es necesario establecer un control, para que se cuente con las características antes mencionadas, el equipo designo la creación de un guión para el Proceso Check In23, mismo que seguía el

14 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\GuionesTSP\GUIONREVHLD.doc

15 Para revisión e inspección véase los archivos CHECKLISTREVREQ.doc y CHECKLISTISNPREQ.doc respectivamente, en la carpeta

NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\CheckListsTSPCheckListsTSP

16 Para revisión e inspección véase los archivos CHECKLISTREVHLD.doc y CHECKLISTINSPHLD.doc respectivamente, en la carpeta

NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\CheckListsTSP

17 Para inspección véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\CheckListsTSP/CHECKLISTINSPDISDET.doc

18 Para inspección véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\CheckListsTSP/CHECKLISTINSPCOD.doc

19 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\EstandaresTSP/STDCOD.doc

20 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\EstandaresTSP/STDCONT.doc

21 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\EstandaresTSP/STDPANT.doc

22 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\EstandaresTSP/STDNOM.doc

23 Véase el archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\EstandaresTSP/CheckInReqHLD.docx

administrador de soporte cuando almacenaba en el repositorio un documento, que había pasado por el proceso de inspección y liberado por el administrador de calidad. El administrador de soporte era el único integrante del equipo que realizaba dicho procedimiento. 6.4. SEGUIMIENTO SEMANAL DEL PROYECTO En los apartados anteriores que componen el seguimiento del proyecto, fue necesario explicar los procedimientos y documentos que el TSP propone para el desarrollo del mismo, enseguida se mostraran los avances semanales que el equipo generó utilizando tablas que guíen al lector en los aspectos mas importantes. A continuación se muestra una breve explicación de los datos que componen esta tabla. Periodo: Se refiere a la fecha que inicio y fin que abarca la semana. Disciplina: La fase de desarrollo en las que nos encontramos. Weekly Date: Son los datos semanales. Schedule hours for this week: Horas de dedicación planeadas en el proyecto para la semana en curso. Schedule hours this cycle to date: Horas acumuladas en la fase del proceso. Earned value for this week: Valor generado al proyecto para la semana en curso. Earned value this cycle to date: Valor generado en el ciclo a la fecha. To-date hours for task completed: Horas a la fecha para completar las tareas. To-date average hours per week: Promedio de horas por semana. EV per completed task hours date: Valor agregado por hora a la fecha. Plan / Actual: Horas planeadas entre horas actuales. Plan – Actual: Diferencia entre las horas planeadas y las horas actuales. El propósito de esta tabla es mostrar los resultados obtenidos cada semana en el proyecto, las relaciones entre los objetivos planeados y los obtenidos, además del valor agregado y los productos generados semanalmente. Dicha tabla ejemplifica perfectamente el control de variables que deben ser tomadas en cuenta para saber como se va desarrollando el proyecto y si es necesario tomar algunas medidas cuando sea el caso.

6.4.1. SEMANA 124

Periodo Disciplina Resumen de objetivos planeados 15/06/09 al 21/06/09 Requerimientos Realizar el conjunto de documentos que el proceso TSP

y realizar análisis para los requerimientos de los diferentes proyectos.

Resultados de equipo

Interpretación de resultados

El equipo creo los documentos planeados para la semana, se analizaron detalles de los requerimientos para todos los proyectos, pero la dependencia de tareas no permitió alcanzar el EVde 8.4 ni poder continuar, se percibe una aparente sobreestimación en las horas planeadas para las tareas ya que se planeaban 61 hrs para realizarlas de las cuales solo se ocuparon 29.1 hrs. Documentación TSP generada Forma MTG semanal

Hoja con información del proyecto Hojas de integrantes

Entregables agregados al repositorio Guiones, estándares, listas de verificación.

24 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\MaterialJuntasSemanalesTSP\Semana1

6.4.2. SEMANA 225

Periodo Disciplina Resumen de objetivos planeados 22/06/09 al 28/06/09 Requerimientos Realizar la especificación de requerimientos comunes

para los proyectos, sus respectivas inspecciones y diseñar pruebas de sistema.



Se generó la especificación de requerimientos que tienen que ver con funcionalidades comunes para el proyecto, con las inspecciones correspondientes, se inició el diseño de algunas pruebas de sistema. Estamos alrededor del 50% en horas dedicadas y en el EV, existe en demasía varias dependencias entre tareas lo que nos obstaculiza cumplir con lo planeado. Persiste la aparente sobreestimación en las tareas de requerimientos 98.7 hrs planeadas para realizarlas de las cuales solo utilizamos 51.6 hrs. Documentación TSP generada Forma MTG semanal


Entregables agregados al repositorio SRS alta de usuarios26 SRS log in27


26 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto \MultiproyRequerimientos\ArqComun\SRS Alta Usuarios 27 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto \MultiproyRequerimientos\ArqComun\SRS Seguridad Login

6.4.3. SEMANA 328

Periodo Disciplinas Resumen de objetivos planeados 29/06/09 al 05/07/09 Requerimientos Finalizar documentación en pruebas de sistema para alta

de usuarios, log in y especificación de requerimientos comunes a los sistemas, así como del proyecto facturación.



Se generó la documentación que se tenía planeada, el SRS de facturación faltó realizar las inspecciones, además de que se comenzó el análisis y documentación relacionado al diseño de alto nivel para las funcionalidades de la arquitectura común. A 3 semanas del proyecto y manteniendo los problemas de semanas anteriores, es necesario ajustar el plan para minimizar dependencias, la mayoria de los datos oscilan en un 50 % de su productividad. De 225.0 hrs solo llevamos 112.2, el EV de 25.4 solo tenemos 17.4. Documentación TSP generada Forma MTG semanal


Entregables agregados al repositorio SRS autenticación29 SRS facturación30 Pruebas de sistema alta usuarios31 y log in32

28 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\MaterialJuntasSemanalesTSP\Semana3 29 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyRequerimientos\ArqComun\SRS Seguridad Autenticacion

30 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyRequerimientos\FacturacionSAT\SRS-ARC-Facturación

31 Véase archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyRequerimientos\ArqComun\PruebasDeSistema\STPlanArqComunMantenimientoUsuarios.docx

32 Véase archivo NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyRequerimientos\ArqComun\PruebasDeSistema\STESTP-ARC-Login.doc

6.4.4. SEMANA 433

Periodo Disciplinas Resumen de objetivos planeados 06/07/09 al 12/07/09 Requerimientos,

análisis y diseño de alto nivel

Finalizar las inspecciones del SRS facturación, iniciar con el SRS para el sistema de video e iniciar con documentos para el diseño de alto nivel en la arquitectura común.



Se lograron las metas que se tenia planeadas, Los datos presentan mejores aproximaciones vs. lo planeado, un EV planeado de 9 y se logro 5.7, las horas de dedicación tan solo nos faltaron 15 hrs vs. Lo planeado, se presentan cambios sustanciosos en el proyecto a razón de otras semanas. Documentación TSP generada Forma MTG semanal


Entregables agregados al repositorio SRS sistema de video34 Pruebas de sistema para autenticación35 Pruebas de sistema para facturación36 Diseño de alto nivel para autenticación(hasta revisión)


34 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos \TSP \Multiproyecto\MultiproyRequerimientos\Video\SRS Video

35 Véase archivo NOTEBOOK[TSP]\Anexos \TSP\Multiproyecto\MultiproyRequerimientos\ArqComun/PruebasDeSistema\STPlanArqComunAutenticacion.docx

36 Véase archivo NOTEBOOK[TSP]\Anexos \TSP\Multiproyecto\MultiproyRequerimientos\FacturacionSAT\PruebasDeSistema\STESTP-FAC.doc

6.4.5. SEMANA 537 En esta semana el equipo decidió consultar al asesor Dr. Humberto Cervantes Maceda38, para que nos explique en un par de sesiones el proceso de desarrollo de la arquitectura de software, su importancia que tiene en la construcción de proyectos, así como sus requerimientos, ya que el equipo no tiene una experiencia amplia en el tema y dado que se pretende realizar una arquitectura común a todos los proyectos, es necesario tener en consideración dicho tema para cumplir con los requerimientos de los Directores.

Periodo Disciplinas Resumen de objetivos planeados 13/07/09 al 19/07/09 Análisis y diseño

de alto nivel Realizar las pruebas de sistema para el proyecto de video, realizar el diseño de alto nivel de las funciones relacionadas con la arquitectura común que hacen falta y que los integrantes del equipo estén presentes en la exposición del asesor Humberto Cervantes, sobre el tema de Arquitectura de Software.



Se crearon los diseños de alto nivel para log in y autenticación, además se inicio con el documento SRS para el proyecto PigMex, finalmente se inicio con el diseño de alto nivel para una funcionalidad del proyecto de facturación. Se disminuyeron las horas planeadas a razón de las semanas anteriores a 66hrs. el EV mantiene pequeños crecimientos tan solo 2.8 por debajo de lo planeado, si bien no es acorde a lo planeado, se mantiene el crecimiento sin importar las eventualidades que se han tenido, a lo largo del proyecto. Documentación TSP generada Forma MTG semanal


Entregables agregados al repositorio Diseño de alto nivel para log in39

37 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\MaterialJuntasSemanalesTSP\Semana5 38 Presentación de arquitectura de software véase NOTEBOOK[TSP]\Anexos\TSP\PresentacionArquitectura\Introduccion a la Arquitectura.pdf

39 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyHLD\ArqComun\HLD Seguridad Login- ARC

40 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyHLD\ArqComun\HLD Seguridad Autenticacion-ARC

Diseño de alto nivel autenticación40

6.4.6. SEMANA 641


de alto nivel Finalizar el documento SRS para el proyecto PigMex y el diseño de alto nivel de todas las funcionalidades para el proyecto de facturación, así como la creación de las pruebas de sistema para dicho proyecto. Se pretende iniciar con el análisis para la construcción del documento SDA(Software Document Architecture).



Se alcanzaron los planes de esta semana, el equipo analizo los puntos del SDA debe tener para que sea completo, además se determinó quienes serian los encargados de realizar dicho documento(por su complejidad se eligió a 3 personas). Casi se logró cumplir las horas dedicadas para el proyecto, tan solo 9.7 hrs por abajo, se investigaron elementos del SDA. Se volvieron a reducir las horas planeadas esta semana a 57hrs no hubo un repunte en el EV. 3.7 por debajo de lo planeado, pero el manejo de las horas del proyecto ah mejorado en demasía. Documentación TSP generada Forma MTG semanal


Entregables agregados al repositorio SRS PigMex42 Diseño de alto nivel proyecto de facturación43

A partir de esta semana el equipo decidió que tres integrantes estarán realizando el documento SDA, un integrante se enfocara en el proyecto PIGMEX y los dos restantes estarán realizando las actividades correspondientes al proyecto de Facturación. Es importante mencionar que todos los integrantes del equipo tienen las evaluaciones finales

41 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\MaterialJuntasSemanalesTSP\Semana6 42 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos \TSP\Multiproyecto\MultiproyRequerimientos\PigMex

43 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos \TSP\Multiproyecto\MultiproyHLD\FacturacionSAT\HLD UC1 Facturación

del trimestre en el cual están inscritos, por tanto el número de horas de dedicación al proyecto se reducirá. 6.4.7. SEMANA 744


de alto nivel Diseño de alto nivel para el alta de usuarios, finalizar el diseño de alto nivel del proyecto de facturación, tener avances en el SDA, creación de pruebas de sistema para el proyecto de video.



Se alcanzaron los objetivos planteados en la junta semanal, lo cual difiere al plan real del proyecto por ello el despunte de las horas, 23.5 hrs por abajo y 3.7 de EV por abajo, los datos vuelven a sugerir alerta en el plan se trabaja al 50% de los planeado vs. lo real. Se tomaron medidas al respecto. Documentación TSP generada Forma MTG semanal


Entregables agregados al repositorio Pruebas de sistema para proyecto de video45

44 Véase archivos en carpeta NOTEBOOK[TSP]\Anexos\TSP\Multiproyecto\MultiproyDocument\MaterialJuntasSemanalesTSP\Semana7 45 Véase NOTEBOOK[TSP]\Anexos \TSP\Multiproyecto\Video\PruebasDeSistema

6.4.8. SEMANA 846

Periodo Disciplinas Resumen de objetivos planeados 03/08/09 al 09/08/09 Diseño de alto

nivel y diseño detallado

Continuar con los elementos del SDA, crear diseños de alto nivel para funcionalidades de la arquitectura.



Se inició con el diseño detallado de algunas funcionalidades del proyecto de facturación y alta de usuarios de la arquitectura común. En esta semana todos los integrantes tienen que realizar actividades finales en su último trimestre de la UAM-I, por lo cual no se dedicaron las horas planeadas de 58 hrs solo se dedicaron 39.3, lo cual refleja en el plan de proyecto la escasa puntuación del EV 2.1, ya que hay demasiados artefactos que no se alcanzaron a completar los cuales no generan EV, en cuanto a las horas se refleja un avance considerable a razón de la semana anterior solo 18.7hrs por abajo lo que refleja un 75% de la planeación de horas . Documentación TSP generada Forma MTG semanal


Entregables agregados al repositorio No se agregaron documentos, dado que no se llevaron a cabo las inspecciones para los documentos de diseño detallado.


7. REPORTE SUMMARY DEL PROYECTO Después de 8 semanas de trabajo, el equipo obtuvo los siguientes resultados:

• Análisis y documentación formal (documentos SRS) de requerimientos de la Arquitectura común, así como de los proyectos de Facturación, PIGMEX y Video.

• Diseño de pruebas de sistema para la arquitectura común, proyectos de Facturación y Video.

• Análisis y documentación formal para el diseño de alto nivel para las funcionalidades del proyecto de Facturación y de los módulos log in, autenticación, así como administración de usuarios, como parte de la Arquitectura común.

• Análisis de arquitectura común, describiendo sus requerimientos no funcionales, atributos de calidad, restricciones y consideración formales, reflejados en una instancia de un documento SDA, que no se logró terminar del todo.

• Documentación de diseño detallado para el procedimiento log in, alta de usuarios y autenticación, componentes de la arquitectura común.

Para obtener los datos que el proyecto generó, el proceso TSP ofrece la especificación SUMMARY el cual tiene como propósito generar un informe completo de la información que se capturó a lo largo de un proyecto TSP, esto permite ofrecer una base para la evaluación y mejora del proceso, así como tener datos históricos para proyectos futuros.

7.1. ANÁLISIS DEL CALENDARIO DE TRABAJO Para la planeación de proyectos posteriores es necesario conocer el porcentaje de tiempo planeado y actual dedicado a cada fase, para cada uno de los puntos de referencia del proyecto. La siguiente tabla pretende mostrar los tiempos en cada fase del proceso y las tareas desempeñadas en estas, para tener estadísticas de las fases, que sirvan de análisis para nosotros y como referencia a otros proyectos.

FASE PUNTO DE REFERENCIA

TIEMPO PLANEADO

TIEMPO REAL PORCENTAJE DE DEDICACIÓN

JUNTA 1 240 MIN. 244 MIN.









JUNTAS DE LANZAMIENTO

JUNTA POST MORTEM

60 MIN. 75 MIN.

FUERA DE TIEMPO PARA HORAS

DEDICADAS AL PROYECTO

ARQUITECTURA COMÚN

44.03%

PROYECTO FACTURACIÓN

44.03%

PROYECTO VIDEO 44.03%

PROYECTO PIGMEX

44.03%

REVISIÓN DE REQUERIMIENTOS

44.03%

REQUERIMIENTOS

INSPECCIÓN DE REQUERIMIENTOS

190.3 HRS. 132.5 HRS

44.03%

ARQUITECTURA COMÚN

39.30%


39.30%

REVISIÓN DE HLD 39.30%

DISEÑO DE ALTO NIVEL (HLD)

INSPECCIÓN DE HLD

215.6 HRS. 118.9 HRS.

39.30%

ARQUITECTURA COMÚN

5.53%


5.53%

REVISIÓN DLD 5.53%

DISEÑO DETALLADO (DLD)

INSPECCIÓN DLD

107.5 HRS. 19.23 HRS.

5.53%

ARQUITECTURA COMÚN

0.00%


0.00%

CODIFICACIÓN

REVISIÓN DE CODIFICACIÓN

72.4 HRS. 0 HRS.

0.00%

ARQUITECTURA COMÚN

0.00%

COMPILACIÓN PROYECTO FACTURACIÓN

14.1 HRS. 0 HRS.

0.00%

ARQUITECTURA COMÚN

0.00%

PRUEBAS UNITARIAS PROYECTO FACTURACIÓN

28.2 HRS. 0 HRS.

0.00%

ARQUITECTURA COMÚN

4.17% PRUEBAS DE

SISTEMA PROYECTO FACTURACIÓN

33 HRS. 14.49 HRS.

4.17%

ARQUITECTURA COMÚN

0.00% PRUEBAS DE INTEGRACIÓN PROYECTO

FACTURACIÓN

17 HRS. 0 HRS.

0.00%

DOCUMENTOS TSP

GUIONES, ESTÁNDARES, PROCESOS, LISTAS DE VERIFICACIÓN.

46 HRS. 21.25 HRS. 6.11%

Como se puede observar se mantuvo una sobre-estimación a las fases de requerimientos y diseño de alto nivel vs. la actual en las demás fases no es posible hacer un análisis puesto que no se llegaron a ellas.

7.2. ANÁLISIS DE RECURSOS La siguiente tabla muestra un listado de las principales tareas en las fases del proyecto y reporte de tiempo requerido para realizarlas.

TAREAS EN FASE TIEMPO DE DEDICACIÓN(HRS.)

PORCENTAJE DEL TOTAL DE TAREAS

REQUERIMIENTOS 64.76 4.22 REVISIÓN E INSPECCIÓN DE

REQUERIMIENTOS 67.74 8.09

HLD 90.6 10.5 REVISIÓN E INSPECCIÓN DE

HLD 28.3 15.14

PRUEBAS DE SISTEMA 33 2.11 DISEÑO DETALLADO 10.2 1.75 REVISIÓN DE DISEÑO

DETALLADO 9.03 1.05

7.3. ANÁLISIS DE TAMAÑO La siguiente tabla muestra el listado de productos generados en cada una de las tareas claves del proyecto y su tamaño.

ES PARTE DE NOMBRE TAMAÑO DOC GUION REQ 1 DOC GUION REVREQ 2 DOC CHECKLIST REVREQ 1 DOC CHECKLIST INSREQ 2 DOC GUION CHECKINREQ 1.5 DOC FORM PRUUNI 2 DOC GUION HLD 2 DOC GUION REVHLD 2 DOC CHECKLIST REVHLD 1 DOC CHECKLIST INSHLD 2 DOC GUION CHECKINHLD 1.5 DOC CHECKLIST INSDD 1 DOC CHECKLIST INSCOD 1 DOC GUION CHECKIN DES 1 DOC EST COD 2 DOC EST CONT 1 DOC EST NOMENCLATURA 3

DOCUMENTACIÓN TSP (PÁGINAS DE TEXTO)

DOC EST PANTALLAS 1 SRS FACTURACIÓN 11 SRS VIDEO 15 SRS PIGMEX 20 SRS AUTENTICACIÓN 8

REQUERIMIENTOS (PÁGINAS DE

REQUERIMIENTOS)

SRS LOG IN 10 HLD FACTURACIÓN: CASO DE USO 3

4

HLD VIDEO: CASO DE USO 1 10 HLD ARQUITECTURA: LOG IN 7 HLD ARQUITECTURA: AUTENTICACIÓN

5

HLD ARQUITECTURA: SEGURIDAD DATOS

6

HLD (PÁGINAS DE DISEÑO)

HLD ARQUITECTURA: ALTA 4

USUARIOS HLD FACTURACIÓN: CASO DE USO 1

8

PLAN DE PRUEBAS DE SISTEMA PIGMEX

8

PRUEBAS DE SISTEMA VIDEO 4 PRUEBAS DE SISTEMA FACTURACIÓN

1

PRUEBAS DE SISTEMA AUTENTICACIÓN

6

PRUEBAS DE SISTEMA ALTA DE USUARIOS

4

PRUEBAS DE SISTEMA (PÁGINAS DE TEXTO)

PRUEBAS DE SISTEMA LOG IN

2

7.4. ANÁLISIS DE PRODUCTIVIDAD La siguiente tabla presenta las Tasas de productividad de los documentos generados, esto se refiere al tiempo de elaboración de estos.

PRODUCTIVIDAD TAREA PÁGINAS DE TEXTO / HORA

DOC GUION REQ 0.61 DOC GUION REVREQ 3.03 DOC CHECKLIST REVREQ 1.81 DOC CHECKLIST INSREQ 1.48 DOC GUION CHECKINREQ 1.87 DOC FORM PRUUNI 1.83 DOC GUION HLD 1 DOC GUION REVHLD 1.1 DOC CHECKLIST REVHLD 0.79 DOC CHECKLIST INSHLD 1.2 DOC GUION CHECKINHLD 1.45 DOC CHECKLIST INSDD 1.93 DOC CHECKLIST INSCOD 1.97 DOC GUION CHECKIN DES 0.39 DOC EST COD 4.5 DOC EST CONT 0.62

DOC EST NOMENCLATURA 2.05 DOC EST PANTALLAS 1.12 PÁGINAS DE REQUERIMIENTOS / HORA SRS FACTURACIÓN 2.63 SRS VIDEO 2.04 SRS PIGMEX 4.23 SRS AUTENTICACIÓN 2.08 SRS LOG IN 2.58 PÁGINAS DE DISEÑO / HORA HLD FACTURACIÓN: CASO DE USO 3 1.37 HLD VIDEO: CASO DE USO 1 2.15 HLD ARQUITECTURA: LOG IN 1.26 HLD ARQUITECTURA: AUTENTICACIÓN 1.12 HLD ARQUITECTURA: SEGURIDAD DATOS

1.31

HLD ARQUITECTURA: ALTA USUARIOS 1 HLD FACTURACIÓN: CASO DE USO 1 1 PÁGINAS DE TEXTO / HORA PLAN DE PRUEBAS DE SISTEMA PIGMEX 6.2 PRUEBAS DE SISTEMA VIDEO 1.44 PRUEBAS DE SISTEMA FACTURACIÓN 0.77 PRUEBAS DE SISTEMA AUTENTICACIÓN 1.75 PRUEBAS DE SISTEMA ALTA DE USUARIOS

1

PRUEBAS DE SISTEMA LOG IN 1.3

7.5. ANÁLISIS DE DEFECTOS En relación de la calidad del proyecto se presentan las tasas de densidades de introducción y eliminación de defectos por fase. Se presentarán los resultados de que genera el libro de trabajo con la información de la última consolidación realizada, hay que considerar que se utilizan la unidad número de defectos inyectados y eliminados por hora.

Figura 5. Número de defectos inyectados por fase del proyecto.

La Figura 5 presenta los defectos inyectados planeados vs. los actuales, se tiene que mencionar que en este punto especifico del proyecto la planeación resulto ineficiente ya que por mucho se rebasaban los datos esperados en cada fase, los documentos llegaban con mas errores de los esperados pero también se tiene que resaltar que las inspecciones filtraban demasiados de estos errores..

Figura 6.Número de defectos eliminados por fase del proyecto.

En la Figura 6 se puede observar lo que anteriormente veníamos mencionando acerca de las inspecciones, que sirven como filtro de defectos hacia otras fases del proceso en esta figura se excede el numero de defectos que se planeaban encontrar en las fases del proceso, por lo cual las inspecciones realizadas cumplieron su cometido.

7.6. ANÁLISIS DE RENDIMIENTO La siguiente Grafica presenta el informe del porcentaje de defectos inyectados del proyecto por fase.

Gráfica 13. Porcentaje de defectos inyectados por fase.

Se puede observar que la grafica solo contempla 3 fases del proceso, esto se debe a que fueran las únicas a las que se llegaron en el proyecto, en la fase de requerimientos se inyectó el 55% de los defectos, mientras que en HLD el valor fue de 34% y finalmente en la fase de diseño detallado se inyectó el 11% del total de defectos. En fases posteriores a diseño detallado se espera que el porcentaje de defectos ingresados sea cada vez más pequeño, al llevarse a cabo un re lanzamiento del proyecto.

La siguiente Grafica presenta el informe del porcentaje de defectos eliminados del proyecto por fase.

Gráfica 14. Porcentaje de defectos eliminados por fase. De la grafica anterior, hay partes claves que se tiene que resaltan a simple vista, las cuales son las inspecciones de TSP, que fueron una fase primordial que se agrega en el proceso, la cual tiene como propósito la eliminación de defectos en fases posteriores de desarrollo y esta grafica es una muestra de ello, basta revisar los nombres de las fases que removieron mas defectos, para darse cuenta de ello.

Fase Plan Actual Actual % Requerimientos 67 13.5 Inspección de requerimientos 21 210 42.2 Diseño de alto nivel 6 1.2 Inspección de diseño de alto nivel 36 155 31.1 Diseño detallado 6 1.2 Inspección de diseño detallado 14 44 8.8 Revisión de diseño detallado 45 10 2.0

Total de defectos removidos 244 498 100

Tabla 13. Defectos removidos en las fases del proceso La siguiente tabla muestra el número de defectos en las fases del proceso así como el porcentaje de la fase donde se removieron mas defectos, en nuestro caso las inspecciones de requerimientos presentaron el mayor numero de defectos removidos.

En la siguiente gráfica se hace una evaluación entre el número de horas que el equipo planeó dedicar al proyecto y el número de horas reales dedicadas a proyecto.

Gráfica 15. Horas planeadas del proyecto VS horas reales de dedicación. La siguiente grafica muestra una clara diferencia entre las horas que el equipo planeaba dedicar al proyecto vs. las reales, nunca se logró reflejar una buena planeación en la dedicación del número de horas para realizar actividades del proyecto. Por tanto en términos del valor agregado, que se considera el porcentaje que el equipo logra cada vez que termina una tarea, en la Gráfica 15 se hace una evaluación de resultados en función del valor agregado planeado (línea azul) con el valor agregado actual (línea verde), durante las semanas en que se desarrolló el proyecto.

Gráfica 16. Valor agregado planeado VS valor agregado real. La siguiente gráfica muestra las metas que el equipo definió semanalmente para realizar el conjunto de tareas del proyecto (línea azul ) y las que realmente se tuvieron( línea verde) por lo cual nunca se estuvo por encima de lo planeado, al cabo de nueve semanas el proyecto presentaba el 36.36% del proyecto del 60.75% que se había planeado inicialmente, como se percibe esto es una evaluación total del proyecto.

8. CONCLUSIONES Al finalizar este proyecto hay que resaltar algunos puntos, empezare con las metodologías ocupadas, el PSP nos dio las bases para conocer y mejorar nuestro proceso de desarrollo de software tanto para identificar nuestras puntos fuertes como nuestras debilidades y poner énfasis en ciertos aspectos, una vez concluida esa parte, estábamos listos para enfrentar un proyecto utilizando la metodología TSP para controlar y mejorar la manera de diseñar el software, me parece que el proceso resulta al principio demasiado estricto, y esto tiene que ver con nuestra manera de hacer los proyectos y con la que ofrece el TSP pero al final resulta demasiado manejable, ya que llevando de manera correcta el proceso tienes control de el en todo momento. Los objetivos definidos ante la dirección fueron los siguientes los cuales abordare uno a uno. 1. Construcción de una Arquitectura común que soporte las funcionalidades de los diferentes proyectos Vía Web, en este objetivo se tuvieron demasiados problemas ya que dentro de la planeación que había de las tareas del lanzamiento no se contemplo un apartado para generar toda la documentación que se necesitaba hacer previa a una arquitectura común, me refiero al documento de especificación de la arquitectura SDA. Para resolver este problema se hizo un plan para que solo 3 integrantes participáramos en la elaboración de ese documento mientras los demás continuaban con las tareas del proyecto. Por otro lado, nuestro asesor el Dr. Humberto Cervantes nos hizo el favor de dar unas breves clases acerca de los puntos clave que había que tomar en cuenta para esta parte del sistema. Posteriormente los 3 integrantes continuamos, pero de antemano el tiempo ya se nos había venido encima y se redefinieron los objetivos con los asesores, el cual se acordó hacer una instancia de un SDA la cual contemplara los puntos necesarios para realizar la arquitectura común que se necesitaba. En esta parte se resaltan muchas partes las cuales se dieron en las clases vistas con el asesor, como fueron los patrones arquitectónicos, y las pequeñas clases de Q&A para un documento de gran impacto en el sistema. 2. Implementación de administración de usuarios, utilizando un mecanismo de autenticación para usuarios registrados. Tampoco logramos cubrir esta parte ya que los integrantes que hacíamos el documento SDA, éramos los mismos que codificaríamos estas partes del sistema por lo que solo logramos terminar el documento y hacer diseño detallado para algunos de estos módulos, los demás integrantes continuaban con las tareas del proyecto.

3. Se cubrió el total de requerimientos del sistema de Facturación. En general la parte de requerimientos se cubrió para casi todos los proyectos a excepción de Camelia por lo cual este punto si fue cubierto. En general considero que la clave del éxito del proyecto radicaba completamente en el lanzamiento, siento que en su momento no contemplamos demasiadas partes importantes las cuales desconocíamos por completo y que tuvieron grandes impactos en los objetivos contemplados. Si bien el proceso TSP contempla todo estos imprevistos, a nosotros nos rebaso por completo, ya que el tiempo lo teníamos encima, pero en este punto nuestros asesores siempre estuvieron ahí para sacarnos adelante cuando era necesario y no entrar en la desesperación y continuar con el objetivo primordial de la materia, que era seguir el proceso TSP, el cual en el siguiente punto a bordo de una mejor manera. Con respecto a la finalidad del proyecto, resulta obvio que lo que se perseguía desde un principio, era el conocer el proceso y dejarnos guiar por este, con ayuda de nuestros asesores. Ya que 4 proyectos y una arquitectura común previa para realizar dichos proyectos y además siguiendo la metodología TSP, resultaría imposible de realizar con 6 programadores en poco mas de 3 meses, entonces más que resaltar lo mucho o poco que se hizo en el proyecto, tenemos que resaltar el objetivo que se persiguió desde un principio. El cual en lo personal me deja muchos aportes a mi desarrollo profesional, afortunadamente o quizás desafortunadamente fui el Líder del Proyecto, por lo cual estuve mas involucrado en todas las partes del proceso y las diferentes formas de manejar las situaciones que se iban presentando. Como ya es recurrente en la enseñanza de estas metodologías, es la de generar históricos, que son experiencias ganadas, a partir de los errores que vamos teniendo con la finalidad de que no vuelvan a pasar, en esta parte agradezco en demasía el rol que desempeñe, ya que con ayuda de mis asesores me presentaban diferentes soluciones para ir manejando el proyecto, considerando las diferentes eventualidades que se iban presentando a lo largo de su desarrollo. Considero que cada uno de nosotros se lleva buenos aportes en su desarrollo profesional tanto del proceso, como de las eventualidades que se tuvieron y de los conocimientos aportados de nuestros asesores el Dr. Humberto Cervantes Maceda y el Ing. Luis Castro Careaga que agradezco haber compartido esta proyecto terminal con ellos.

9. GLOSARIO Administración de la Configuración: Se encarga de dar seguimiento a los cambios en los distintos artefactos. Típicamente la administración de la configuración se apoya en un sistema de control de versiones.

Arquitectura de Software: La arquitectura de in programa o sistema de cómputo es la estructura del sistema que comprende componentes de software, sus propiedades visibles y las relaciones entre los componentes. Artefactos: Son productos de trabajo del proceso. Bitácora: Es el almacenamiento de los datos en un registro. Calidad del Software: Es el grado con el cual un conjunto de características inherente (del producto) cubren los requerimientos, esta definición necesita que los requerimientos estén bien definidos (de tal forma que se puedan evaluar si se satisfacen), el SEI hace mucho énfasis en que la calidad del producto de Software tiene mucha relación con el numero de efectos que tiene el producto que se entrega. Checklist: Presentan información sobre la manera de desarrollar, evaluar y usar artefactos. Earnead Value (EV): El valor acumulado es un método utilizado para el seguimiento de los progresos reales de trabajo realizado en contra del plan general del proyecto. A medida que cada tarea se ha completado, su PV se suma a la EV acumulado para el proyecto. Las tareas parcialmente completadas no contribuyen al total de EV. Estándares: Proporcionan definiciones precisas y coherentes que orientan el trabajo, recopilación y uso de los datos. Fase: Una Fase es un conjunto de actividades relacionadas con un aspecto particular que se realizan para entregar una porción considerable del proyecto. Fases del Proceso: Un proceso definido consta de un conjunto de pasos, elementos o actividades que generalmente se llaman fases.

Fases del proceso PSP 1. Planeación: Produce un plan para desarrollar el programa definido por los requerimientos. 2. Diseño: Produce una especificación de diseño para el programa definido por los requerimientos. 3. Codificación: Transforma la especificación de diseño en instrucciones del lenguaje de programación. 4. Compilación: Traduce las instrucciones del lenguaje de programación en código ejecutable. 5. Pruebas: Verifica que el código ejecutable satisface los requerimientos. 6. PostMortem: Resume y analiza los datos del proyecto. Formas: Proporcionan un marco de trabajo practico y coherente para la recolección y conservación de los datos. Guión: Proporcionan guía de “nivel-experto” de cómo usar el proceso. Iteración: Es un periodo definido y fijo de tiempo dentro del proyecto, donde se produce una versión estable y ejecutable del producto. Patrones Arquitectónicos: Ofrecen soluciones conceptuales enfocadas a realizar la descomposición de alto nivel de la aplicación.

Percent appraisal cost of quality (COQ): Mide la calidad del proceso en una forma que es significativa para la dirección. Los elementos del COQ son los costos de falla, apreciación y prevención. Phase Yield: El rendimiento de la fase mide el porcentaje de los defectos en el producto que fueron encontrados por esa fase, la efectividad de la eliminación de defectos de ese paso del proceso.

Plan: Define una visión de alto nivel de la calendarización del proyecto. Planned Value (PV): El valor planeado de una tarea es igual a su plazo planeado expresado como un porcentaje del tiempo total previsto para el proyecto. Por ejemplo, una tarea de 5 horas en un proyecto de 50-horas tendría un PV de 10. Proceso: Un proceso describe la secuencia de pasos que un profesional calificado debe seguir para realizar una tarea específica. Proceso Definido: Es una secuencia documentada de pasos requeridos para hacer un trabajo especifico. Los procesos son generalmente definidos para los trabajos que se realizan en varias ocasiones y se hacen de la misma manera cada vez que se realizan. Proceso de Calidad: Un proceso de calidad debe satisfacer las necesidades de sus usuarios para producir productos de calidad de manera eficiente. Un proceso de calidad debe producir un producto utilizable, eficaz, fácil de utilizar y adaptable a las nuevas circunstancias Productos de Calidad: Dicho producto deberá satisfacer un umbral mínimo de funcionalidades y utilidades. El producto también debe satisfacer las expectativas del usuario con respecto a un número criterios. Proyecto: Es una tarea única que busca producir un conjunto de productos ó servicios dentro de un margen de tiempo, costo y calidad bien definidos. Repositorio: Se encarga de guardar todas las versiones de cada artefacto que forma arte de la configuración. Requerimiento: Son las entradas fundamentales para el desarrollo del sistema. Requerimientos de software: Expresan las necesidades y restricciones asociadas a un proyecto de software y que contribuye a la solución de un problema del mundo real. Rol: Es una definición abstracta de un conjunto de responsabilidades para la realización de actividades que deben ser llevadas acabo así como artefactos que deben ser producidos.

Scripts: Son descripciones de alto nivel que guían al personal en un proceso. Tarea: Es una unidad de trabajo que debe ser completada dentro de un proyecto. Se asigna a un responsable y tiene una duración corta, generalmente produce un entregable. Yield: Es el porcentaje de defectos introducidos y eliminados antes de la primera compilación.

10. REFERENCIAS [Naur 69] Naur, Peter & Randell, Brian, eds. Software Engineering: Report of a

Conference Sponsored by the NATO Science Committee. Garmisch, Germany, Oct. 7-11, 1968. Brussels, Belgium: Scientific Affairs Division, NATO, 1969.

[Humphrey 97] Humphrey, Watts S. Introduction to the Personal Process. Reading, MA:

Addison-Wesley, 1997.

[Wikipedia 10] Wikipedia, The Free Encyclopedia. Criticism of software engineering. http://pesona.mmu.edu.my/~wruslan/SE2/Readings/detail/Reading-12.pdf

(2010). [Mullaney 10] The Team Software Process (TSP) in Practice: A Summary of Recent

Results. http://www.sei.cmu.edu/reports/03tr014.pdf (2010).

[SEI 09] Wikipedia, The Free Encyclopedia. Criticism of software engineering. http://www.sei.cmu.edu/library/reportspapers.cfm (2009).

personal software process & team software process148.206.53.84/tesiuami/uami16026.pdf ·...

Documents