Reporte del Proyecto de Investigación148.206.53.84/tesiuami/UAMI15666.pdf · trabajo, y...

Reporte del Proyecto de Investigacin

2

CONTENIDO CONTENIDO ................................................................................................................................... 2

INTRODUCCIN ............................................................................................................................. 4

PRESENTACION TSP........................................................................................................................ 5

Presentacin PSP ....................................................................................................................... 8

LANZAMIENTO ............................................................................................................................. 11

Junta 1: Estableciendo las Metas del Producto y del Negocio ................................................... 12

Junta 2: Estableciendo la Autodireccin del Equipo .................................................................. 12

Junta 3: Generando la Estrategia de Desarrollo ........................................................................ 14

Junta 4: Construccin del Plan Descendente ............................................................................ 20

Junta 5: Desarrollo del plan de calidad ..................................................................................... 21

Junta 6: Construccin de los Planes Detallados para la Siguiente Fase ...................................... 21

Junta 7: Conduciendo una Evaluacin de Riesgo ....................................................................... 22

Junta 8: Preparacin de la Presentacin a la Direccin ............................................................. 23

Junta 9: Revisin del Plan con la Direccin................................................................................ 23

Post-mortem del Lanzamiento ................................................................................................. 24

DESARROLLANDO PIGMEX ........................................................................................................... 25

Anlisis de requerimientos ....................................................................................................... 25

Diseo de solucin ................................................................................................................... 28

Relanzamiento del Proyecto ..................................................................................................... 30

Arquitectura ejecutable ........................................................................................................... 36

Prototipo uno ....................................................................................................................... 37

Prototipo dos. ...................................................................................................................... 38

POSTMORTEM ............................................................................................................................. 45

Resultados obtenidos ............................................................................................................... 45

PIPs .......................................................................................................................................... 49

Conclusiones y comentarios ..................................................................................................... 49

David Daz Garca ................................................................................................................. 49

Roberto Carlos Osorno Valdez .............................................................................................. 50


3

FIRMAS ........................................................................................................................................ 51

ANEXOS ....................................................................................................................................... 52

1. Reporte PSP David Daz Garca .......................................................................................... 52

2. Reporte PSP Roberto Carlos Osorno Valdez ...................................................................... 66

3. Estimacin de tamao de componentes ........................................................................... 77

4. Lista de Tareas.................................................................................................................. 78

5. Estimacin de defectos introducidos y eliminados por fase .............................................. 82


4

INTRODUCCIN

La mayora del Sofware usado en la industria es desarrollado por equipos de trabajo, lo que significa que para ser un desarrollador efectivo se debe saber trabajar en equipo. Si se tiene un espritu de cooperacin se tiene la herramienta bsica para ser un exitoso miembro de un equipo. Sin embargo el trabajar con un equipo es mucho ms complicado que eso. Los equipos deben planear sus proyectos, llevar un seguimiento de su progreso y coordinar su trabajo. Ellos tambin tienen que acordar metas y tener un proceso de trabajo en comn as como comunicarse libre y continuamente.

Para cumplir con los tiempos de entrega y construir productos de alta calidad es esencial que los equipos sean prcticos. Sin embargo la practicidad de un equipo de trabajo se obtiene mediante la experiencia y un conjunto especifico de cualidades y mtodos.

El objetivo de realizar el proyecto de investigacin es aprender el Team Software Process y vivir problemas reales que experimenta un equipo de trabajo en la vida real para de esta forma obtener una experiencia prctica. Con la experiencia ganada en este proyecto estaremos preparados para los proyectos a gran escala que se presentan en la industria de software y tendremos una nocin de las buenas prcticas de software y la importancia de aplicarlas en los distintos proyectos en los que participemos en nuestro futuro desarrollo como profesionales.

Este reporte presenta una introduccin al Team Software Process y al Personal software Process tambin los principios detrs de este, como lo son el diseo, estructura y seguimiento al proceso. Tambin se presentan los resultados y experiencias obtenidas en el desarrollo del proyecto mediante las herramientas que brinda el TSP para dar seguimiento al trabajo del equipo.


5

PRESENTACION TSP

El Team Software Process (TSP) es un proceso de trabajo basado en PSP para los equipos de ingenieros.

El (TSP) tiene como objetivo asegurar la calidad de los productos y de este modo obtener software ms seguro. Tambin logra mejorar la administracin de software en una organizacin.

Los equipos usan el TSP para aplicar conceptos de equipos auto dirigidos al desarrollo intensivo de software, parte importante del proceso es el lanzamiento el cual lleva al equipo mediante:

- Establecimiento de metas - Definicin de roles en el equipo - Identificacin de Riesgos - Produccin de un plan de equipo

Los roles que establece el TSP son:

- Lder del equipo - Administrador de la Interfaz con el cliente


6

- Administrador de Diseo - Administrador de Implementacin - Administrador de Planeacin - Administrador de Proceso - Administrador de Calidad - Administrador de Soporte - Administrador de Pruebas

Despus del lanzamiento el TSP proporciona un proceso definido para administrar, dar seguimiento y reportar el progreso del equipo.

Usando TSP una organizacin puede tener equipos auto dirigidos que planeen y sigan su trabajo, y establezcan metas a travs de su propio plan y proceso. Estos pueden ser equipos con una cantidad de 3 a 20 ingenieros.

TSP ayuda a las organizaciones a establecer una disciplina y madurez en los ingenieros lo cual produce seguridad, software confiable y con calidad.

El TSP propone el siguiente proceso, el cual contempla una fase de planeacin conocida como lanzamiento del proyecto, cuatro de desarrollo; una de ellas dedicada al anlisis de requerimientos y otra al diseo de alto nivel. Las otras dos estn dentro del proceso PSP de cada ingeniero y corresponden a las fases de diseo y codificacin.


7

Debido a que la calidad es de suma importancia en el TSP se contemplan varias fases dedicadas a filtrar los defectos de los diversos productos, a continuacin se detallan mas estas fases.

Revisiones. Es un primer filtro de calidad, este lo realiza el autor del producto mediante un checklist previamente elaborado y cumpliendo con los tiempos planeados para esta fase, su objetivo es encontrar errores simples en el producto.

Inspecciones. Al igual que las revisiones se realizan en un tiempo planeado y con ayuda de un checklist, pero en esta ocasin no es el productor quien lo realiza, sino uno o ms colegas del equipo. Una vez terminado el producto el autor solicita que se inspeccione su trabajo, esta inspeccin se lleva a cabo siguiendo el guion correspondiente del TSP en el cual se especifican los pasos y roles de los participantes en la inspeccin, as como los clculos a seguir para no solo saber la cantidad de defectos encontrados sino tambin estimar la cantidad de defectos totales presentes en el producto. Su objetivo es encontrar defectos complejos.

Compilacin. Esta fase se encuentra dentro del proceso PSP de cada ingeniero.

Pruebas unitarias. Estas son las primeras pruebas del producto, las realiza el autor como parte de su proceso PSP, su objetivo principal no es encontrar defectos, ya que estos debieron de haberse encontrado en las revisiones e inspecciones, su objetivo es revisar que el producto funciona de acuerdo a los requerimientos.

Pruebas de integracin. En este filtro se prueba el correcto funcionamiento al unir dos o ms componentes del sistema. Se realiza siguiendo el plan de pruebas de integracin previamente elaborado.

Pruebas de sistema. Es la ltima fase de pruebas, en esta se prueba el sistema en su totalidad para asegurarse que cumpla con los requerimientos. Al igual que las de integracin se realiza siguiendo el plan correspondiente.

Otro tipo de fases contempladas en TSP son las de Check In y Postmortem, en el check in se debe seguir el procedimiento elaborado con anterioridad para ingresar los productos terminados al repositorio del proyecto.

La ltima fase es la de postmortem, en esta se realiza un anlisis de los resultados del proyecto y se comparan con las metas establecidas inicialmente durante el lanzamiento, tambin se analiza que tan eficiente fue el proceso para identificar puntos de mejora.

Como se puede ver en el diagrama, el TSP comienza con fases que se realizan en equipo como lo son el lanzamiento, los requerimientos y diseo de alto nivel. Posteriormente debido a que ya estn establecidas las tareas individuales as como la asignacin de


8

recursos, se realizan procesos PSP para la elaboracin de dichas tareas. Finalmente las tres ltimas etapas que son las pruebas de integracin sistema y postmortem se vuelven a realizar en equipo.

Para dar seguimiento al proyecto el TSP establece juntas semanales, las cuales se realizan siguiendo el guion correspondiente. Estas juntas permiten conocer el estado en el que se encuentra el proyecto y compararlo con el plan, tambin sirve parea dar seguimiento a los riesgos identificados, as mismo se da a conocer de manera individual el progreso de los integrantes para ver si se estn cumpliendo las metas.

Presentacin PSP Personal Software Process (PSP) es un proceso de auto mejora diseado para ayudar a controlar, administrar y mejorar nuestra forma de trabajo. Es un marco estructurado de formas, guiones y procedimientos para desarrollar software. Usndolo apropiadamente, PSP provee de datos histricos necesarios para hacer un mejor trabajo y cumplir con los tiempos propuestos, haciendo nuestro trabajo diario ms predecible y eficiente.

PSP es una herramienta poderosa que podemos usar de diferentes maneras, por ejemplo, para evaluar nuestro talento y/o desarrollar habilidades. Nos ayuda a planear mejor, dar seguimiento de forma precisa y medir la calidad de los productos. Cuando desarrollamos programas, analizamos requerimientos, escribimos documentacin o damos mantenimiento a software, PSP nos puede ayudar a hacer un mejor trabajo.

Ofrece tcnicas de anlisis de datos que podemos usar para determinar que tecnologas adoptar y que mtodos trabajan mejor para nosotros. As como un marco para entender


9

porque cometemos errores y la mejor manera de encontrarlos. Podemos determinar la calidad de nuestras revisiones y los tipos de errores que cometemos.

PSP tiene un marco de madurez semejante al de CMM, en la siguiente figura se muestra en itlicas y con asterisco las Key Process Areas (KPAs) del CMM que estn parcialmente cubiertas por el PSP.

El PSP est definido de manera progresiva como se muestra en la siguiente figura. A continuacin definiremos el proceso de cada fase de mejora.


10

PSP 0: Proceso Base

El primer paso en el PSP es establecer una base que incluya algunas mediciones bsicas y un formato de reporte. Esto provee una base solida sobre la cual se puedan construir mejoras. PSP 0 debe ser el proceso que se usa normalmente para escribir programas solo ajustado para hacer mediciones.

PSP 0 es mejorado a PSP 0.1 agregando un estndar de codificacin, medicin de tamao, y el process improvement proposal (PIP). PIP es un formato que proporciona una forma estructurada de recordar problemas de proceso, experiencias y propuestas de mejora.

PSP 1: Proceso personal de planeacin.

PSP 1 aade pasos de planeacin a PSP 0. Primero agrega un reporte de pruebas y una estimacin de tamao y tiempo. En PSP 1.1 se introducen planeacin de tareas y de calendario.

Algunas de las razones para hacer planeacin son las siguientes:

- Entender la relacin entre el tamao de los programas y el tiempo en desarrollarlos - Cumplir con los tiempos establecidos - Un plan ordenado para hacer el trabajo - Tener un marco para determinar en qu estado est el trabajo.

PSP 2: Proceso personal de manejo de calidad.

PSP2 agrega tcnicas de revisin a PSP 1 que ayudan a encontrar defectos de forma temprana que ms tarde serian costosos de reparar. Esto se logra analizando los defectos encontrados en compilacin y pruebas de los primeros programas. Con estos datos se pueden establecer checklists.

PSP 2.1 ajusta el proceso de diseo, pero de una forma poco tradicional. PSP no dice como disear pero si como debe ser el diseo. PSP 2.1 establece criterios de completes y tcnicas de verificacin de diseo.

PSP3: Proceso personal cclico.

Cuando se tienen que construir programas demasiado grandes se usa PSP3. La estrategia de PSP 3 es subdividir un programa grande en programas de tamao adecuado para PSP 2, el primer desarrollo es un ncleo del programa y sobre este se realizan iteraciones de PSP 2.


11

LANZAMIENTO

El propsito del lanzamiento es establecer un entendimiento comn del equipo acerca de aspectos del proyecto tales como:

Metas de la direccin para el proyecto. Las metas del equipo. Procesos que el equipo utilizar. Roles que los miembros del equipo realizarn. El trabajo de desarrollo a ser realizado. Plan para hacer el trabajo. Sistema de reporte a la direccin y al cliente. Proceso de comunicacin del equipo funcionando.

El lanzamiento de TSP est organizado como un conjunto de juntas, y cada junta TSP tiene roles, una agenda y un reporte de la junta.

Las juntas del lanzamiento son:

Los roles de la junta son:

Moderador: concerta y encabeza la junta Facilitador/cronometrista

o Ayuda al equipo a seguir la agenda y el guin. o Sigue y anota los tiempos de la agenda.


12

Anotador o Registra todas las decisiones importantes (qu y quin) y acciones planeadas

(qu, quin, cundo). o Verifica las acciones y decisiones con los asistentes de la junta al final de la

misma.

Cada junta TSP debe tener una agenda que: describe el propsito de la junta, enlista a los asistentes, proporciona los temas y sus tiempos planeados, y nombra al lder de la discusin, ya que al tener una agenda, las juntas son ms productivas.

El reporte de la junta debe de:

Ser breve. Liste las decisiones clave y las conclusiones. Registre todas las acciones planeadas.

Verificar las acciones y decisiones ayuda a estar de acuerdo en qu ser hecho y recordar hacerlo.

Junta 1: Estableciendo las Metas del Producto y del Negocio En esta junta la direccin da a conocer lo que desea que el equipo desarrolle, as como cuando se necesita el producto, los recursos disponibles para el equipo, la flexibilidad del equipo, por qu el trabajo es importante y cmo la direccin medir el xito.

Para el proyecto PigMex2009 la direccin defini las siguientes metas:

Hacer ms amigable el sistema PigMex para facilitar su uso (interaccin y consulta).

Automatizar el biodigestor (mediano aceptable). Hacer consultas en lnea (ptimo). Finalizar el proyecto en 6 meses. Obtener un producto libre de defectos.

Junta 2: Estableciendo la Autodireccin del Equipo El objetivo de esta junta es definir las metas del equipo y asignar roles.

El equipo define sus metas partiendo de los objetivos que estableci la direccin en la junta anterior, se revisan y se refinan, y as se obtiene un acuerdo sobre las metas especficas del equipo.


13

El equipo divide los roles de administracin del equipo de tal forma que cada miembro tenga al menos una responsabilidad de rol.

Los roles dentro del equipo son:

Interfaz con el cliente Diseo Implementacin Pruebas Planeacin Proceso Calidad Soporte

Para el proyecto PigMex2009 las metas de la direccin y del equipo as como sus respectivas medidas fueron las siguientes:

Meta Medida de la meta

DIRECCIN

Hacer ms amigable el sistema PigMex para facilitar su uso (interaccin y consulta).

Implementar 19 consultas con nueva interfaz.

Automatizar el biodigestor (mediano aceptable). Implementar 1 consulta adicional.

Hacer consultas en lnea (ptimo). Implementar las 20 consultas en una pgina web.

Finalizar el proyecto en 6 meses. Error de estimacin menor a 2.4 semanas.

Obtener un producto libre de defectos. 100% de las pruebas terminadas satisfactoriamente.

EQUIPO

Terminar el lanzamiento el lunes 23 de febrero de 2009.

Llevar a cabo las 9 juntas a ms tardar el 23 de febrero.

Cumplir los requerimientos mnimos establecidos.

Implementar las 19 consultas.

Entregar un producto de alta calidad. Mantener densidad de defectos menor a


14

Para el proyecto PigMex2009 los integrantes del equipo tenan las siguientes responsabilidades de roles:

Germn Gil de Arvalo Cano:

Lder del equipo

Jess Luciano Galvn Peralta:

Administrador de interfaz con el cliente Administrador de soporte Administrador de implementacin

David Daz Garca:

Administrador de planeacin Administrador de calidad

Roberto Carlos Osorno Valdez:

Administrador de proceso Administrador de diseo Administrador de pruebas

Junta 3: Generando la Estrategia de Desarrollo En esta junta los miembros del equipo definen el producto que construirn y como lo realizarn atreves del diseo conceptual y estimacin de tamao, una lista de todos los productos que deben ser generados, una estrategia para cumplir las metas del equipo, un

20 def/Kloc.

Entregar el producto en el tiempo planeado. Mantener error de estimacin menor a 10%

Mantener informado al cliente del estado del proyecto.

Realizar al menos 3 reuniones con el cliente.

Disminuir el costo (tiempo) de error. Mantener A/F Ratio > 2

Tener un alto rendimiento. Mantener Yield mayor a 60%


15

proceso para realizar bien el trabajo a la primera vez, y una lista de cualquier actividad que deba ser hecha por el equipo.

Para el proyecto PigMex2009 la estrategia de desarrollo fue la siguiente:

Para el diseo conceptual se definieron los principales componentes, elementos y caractersticas del producto para representar la forma en la que ser el sistema y cmo los mdulos estarn conectados dentro de este.

En base al diseo conceptual se definieron los mdulos a desarrollar, debido a que se decidi que el diseo sera de 3 capas los mdulos que conformaran el sistema se clasificaron en: mdulos de presentacin (encargados de interactuar con el usuario), mdulos de negocio (encargados de la lgica del programa tal como los clculos o procesamiento de la informacin), y mdulos de datos (encargados de la gestin de la base de datos).

La siguiente imagen muestra el resultado de esta clasificacin.


16

Con la intencin de facilitar la estimacin de tamaos de cada componente que sera desarrollado, el equipo defini un estimado de los tamaos para los componentes dependiendo del tipo o categora del componente, esto debido a que el tamao de un componente depende en gran medida de la capa o categora a la que este corresponda (Presentacin, Negocio, o Datos).

A continuacin se muestra este estimado de tamaos.


17

Al crear la estrategia de desarrollo, el equipo consider: el tamao grueso de cada componente, si el producto debera ser desarrollado en una o varias versiones, cul sera el contenido general de cada versin desarrollada, cul sera el nmero de ciclos de desarrollo y el estimado de tamao y horas de cada uno, si son necesarios prototipos, cundo son necesarios y cul sera el propsito.

En el proyecto PigMex2009 se consider una estrategia de desarrollo por mdulos que constara de cuatro iteraciones con duracin aproximada de 3.5 semanas por iteracin, cuyo contenido se muestran a continuacin:

1. Primera iteracin

Prototipo 0.1 de modulo de clculo de datos. Prototipo 0.1 de modulo Naves de Cerdos. Elaboracin de la Base de Datos. Prototipo 0.1 del modulo de naves de cerdos Relaciones entre PPP y CVA en

la Base de Datos.

2. Segunda iteracin

Prototipo 0.1 del modulo captura de datos. Prototipo 0.1 del modulo despliega consultas. Versin 1.0 del modulo almacena datos de la Base de Datos.

3. Tercera iteracin

Prototipo 0.1 del modulo principal. Versin 1.0 del modulo captura datos. Prototipo 0.2 del modulo despliega consultas.

4. Cuarta iteracin

Versin 1.0 del modulo login. Versin 1.0 del modulo actualiza parmetros. Versin 1.0 del modulo almacena parmetros. Versin 1.0 del modulo principal.


18

Al definir el proceso general de desarrollo que se seguira hasta la entrega final se acordaron: las principales fases del proyecto, las principales actividades de cada fase, y los elementos a incluir en la lnea base en cada fase.

En el proyecto PigMex2009 se defini que el proceso de desarrollo que se seguira sera el propuesto por el TSP, el cual es el siguiente:

Al definir el plan de soporte, el equipo realizo una revisin de las herramientas e instalaciones disponibles de desarrollo y soporte del proceso y una identificacin de cualquiera que no est considerada, algunas herramientas que se consideran para un plan de soporte son tales como: ayudas de requerimientos y diseo, compiladores, editores, ayudas de depuracin, herramientas de prueba, seguimiento de defectos, administracin de configuracin, seguimiento de asuntos pendientes, conteo de LOC, anlisis de datos, entre otras.

En el proyecto PigMex2009, se acord que el plan de soporte que se aplicara hasta la finalizacin del proyecto considerara las siguientes herramientas para el desarrollo y soporte del proceso del mismo:

Requerimientos

Word 2003 Star UML 5.0


19

HLD

Word 2003 Star UML 5.0 Power Point 2003

DLD


Codificacin

Java SE 6 Eclipse 3.4 Plug-in DTP (Data Tools Project) Plug-in EMF (Eclipse Modeling Framework) Plug-in Instantions Designer Plug-in JST (J2EE Standard Tools) Plug-in WST (Web Standard Tools) Plug-in Subclipse (Subversion control)

Servidor de Aplicaciones

TomCat 6.0.1.8

Servidor de BD

MySQL 5.1.3.0

Pruebas unitarias y de integracin del sistema

Word 2003 Excel 2003 Junit 4.3

Control de versiones

Subversion 1.5 Tortoise SVN 1.5.8


20

Debido a la necesidad de una norma o directriz que regule la actividad de gestin y control de versiones, el equipo lleva a cabo la integracin del comit de control de la configuracin (CCB), el proceso de gestin de configuracin tiene como principal objetivo asegurar la integridad de los productos desarrollados.

Para el proyecto PigMex2009 el comit de control de la configuracin (CCB) fue integrado de la siguiente manera.

Integracin del CCB

Administrador de Soporte (Presidente): Jess Galvn Peralta.

Lder del equipo: Germn Gil de Arvalo Cano.

Administrador de la Interfaz con el Cliente: Jess Galvn Peralta.

Administrador de Diseo: Roberto Carlos Osorno Valdez.

Junta 4: Construccin del Plan Descendente En esta junta el equipo construye un plan descendente para todo el trabajo, el cual est conformado por los siguientes puntos:

Estimado de tamao de cada producto del proyecto. Determinar las tareas necesarias para generar cada producto del proyecto. Estimado general de recursos requeridos para cada tarea definida. Estimacin de las horas a la semana que el equipo dedicar a las tareas del proyecto.

Cabe sealar que un producto es todo aquello que se desarrolle durante el proyecto, por ejemplo: HLD, DLD, Cdigo, Manuales, Reporte de pruebas, entre otros.

En el caso del proyecto PigMex2009 este plan tena las siguientes caractersticas:

Estimado de tamao de cada elemento de producto del proyecto (Ver anexo 1). Listado de las tareas de cada elemento de producto del proyecto (Ver anexo 2). Estimado general de recursos requeridos para cada tarea definida (Ver anexo 2). La estimacin de horas agregadas de las tareas del equipo para cada semana del

proyecto fue de 10 para uno de los integrantes del equipo y 12 para los dems integrantes.


21

Junta 5: Desarrollo del plan de calidad En esta junta el equipo construye un plan de calidad del producto que muestre cmo el equipo lograr su meta de calidad del producto, este plan est construido de los siguientes puntos:

Metas de calidad del equipo. Estimacin de los defectos a ser introducidos por cada fase, que son estimados

como las horas planeadas para la fase P por la tasa de introduccin de defectos por hora para la fase P.

Estimacin de los defectos a ser eliminados por cada fase, que es el rendimiento de eliminacin de defectos por los defectos presentes en esa fase dividido entre 100.

Posteriormente el equipo revisa el plan de calidad contra las metas y el plan descendente en busca de los ajustes necesarios para que las metas del equipo y el calendario de trabajo se cumplan, en otras palabras para asegurarse de que sean consistentes.

En el TSP, la calidad del software durante el desarrollo del producto es medida contando los defectos y normalizndolos por la medida apropiada de tamao.

En el caso del proyecto PigMex2009 los acuerdos a los que se llegaron para la construccin de este plan se observan en el anexo 3, adems se definieron las siguientes metas de calidad del equipo.

Junta 6: Construccin de los Planes Detallados para la Siguiente Fase Esta junta tiene los siguientes objetivos:

Asignacin de las tareas a los miembros del equipo: Los integrantes revisan las tareas de la siguiente fase y asignan estas tareas entre los miembros del equipo, cabe sealar que se puede hacer el balanceo de carga durante esta asignacin, o puede hacerse despus de que cada integrante del equipo haya hecho sus planes propios.

Meta Medida de la meta

Entregar un producto de alta calidad. Mantener densidad de defectos menor a 20 def/Kloc.

Disminuir el costo (tiempo) de error. Mantener A/F Ratio > 2

Tener un alto rendimiento. Mantener Yield mayor a 60%


22

Para mantener una carga de trabajo balanceada mientras se asignan las tareas, el equipo trabaja siguiendo el plan a lo largo de una semana a la vez, para as, detectar de manera temprana la necesidad de re-balancear trabajo.

Los desarrolladores construyen sus propios planes: Se crean los planes ascendentes de forma individual usando datos personales donde sea posible, cada miembro del equipo evala su trabajo y agrega cualquier tarea de roles, define su calendario de trabajo y planes de valor generado.

Revisin y rebalanceo de la carga de trabajo del equipo: El equipo revisa los planes ascendentes para: asegurar que se cumplan los criterios de calidad, resolver conflictos y duplicaciones, y re-balancear tareas hasta que se obtiene un calendario de trabajo mnimo.

Producir el Plan de Desarrollo de la Siguiente Fase: Se combinan los planes ascendentes para generar plan consolidado del equipo de la siguiente fase, el cual contiene estimados consolidados del tamao de los productos y el plan de valor generado del equipo para el seguimiento de valor planeado, valor generado proyectado por semana para la siguiente fase.

En el caso del proyecto PigMex2009 la asignacin de tareas y el plan del equipo puede observarse en el anexo 2.

Junta 7: Conduciendo una Evaluacin de Riesgo En esta junta el equipo identifica los riesgos para su plan usando un enfoque de lluvia de ideas donde todos los miembros participan en sugerir riesgos, este proceso contina hasta que no puede pensarse en ms riesgos, cada riesgo mencionado se registra para ayudar al equipo en la evaluacin subsiguiente.

Para cada riesgo, el equipo evala su impacto probable (el impacto se mide como alto, medio o bajo), el impacto es alto si el efecto sobre el calendario de trabajo del proyecto fuera importante.

Para cada riesgo el equipo mide su probabilidad (la probabilidad se mide como alta, media o baja).

Finalmente y con el fin de minimizar el impacto y la probabilidad de los riesgos, cada riesgo se asigna a un miembro del equipo para su investigacin y seguimiento.

En el proyecto de PigMex2009 en esta junta se identificaron los siguientes riesgos:

Riesgo IMPACTO PROBABILIDAD Supuestos de estimacin errneos Alto Media


23

Las horas disponibles planeadas no se proporcionen Alto Baja Alguno de los miembros del equipo tenga un problema personal Bajo Alto

Generacin de un requerimiento nuevo no considerado Medio Baja Cambios en los requerimientos Medio Baja Imposicin de una fecha lmite menor a la fecha fin planeada Alto Baja

Necesidad de cambiar alguna herramienta ya iniciado el proyecto Medio Baja

Error de diseo no detectado hasta pruebas de sistema Alto Baja

De los cuales solo se tom el primero, que es Supuestos de estimacin errneos debido a que su probabilidad es Media, para este riesgo se tomaron las siguientes medidas:

Integrante encargado de su investigacin y seguimiento: DD. Seguimiento y reporte de estado: Semanal. Estrategia de mitigacin: Acolchona miento, Aceptacin, Investigacin.

Junta 8: Preparacin de la Presentacin a la Direccin El objetivo de esta junta es preparar una presentacin del plan a la direccin, primero se analiza el material a ser cubierto, luego el equipo decide qu presentar y quin lo presentar, despus de hacer lo anterior, se asigna el trabajo de preparacin a uno o ms miembros, el equipo debe estar de acuerdo en todo lo definido anteriormente.

Cabe sealar que si el plan del equipo no cumple las metas de la direccin, el equipo incluye planes alternativos que pueden ser: agregar ms recursos al equipo, entregar una versin con funcionalidad reducida, iniciar con una versin pequea y seguir posteriormente con una versin con funcionalidad completa.

Junta 9: Revisin del Plan con la Direccin Aqu el equipo presenta su plan y si es necesario, las alternativas para cumplir las necesidades de negocio.

Adems, en esta junta la direccin prueba el plan del equipo para evaluar la calidad del trabajo del equipo, luego decide si el plan del equipo (o uno alternativo) es aceptable y si es necesario, pide al equipo examinar otras alternativas.

Cabe sealar que la presentacin del plan del equipo del proyecto PigMex2009 a la direccin fue exitosamente aprobada, ya que la direccin no presento ninguna clase de


24

inconformidad o duda, sealando que el plan de trabajo fue generado con gran cuidado y detalle.

Post-mortem del Lanzamiento En esta junta se revisan los resultados obtenidos durante el lanzamiento para obtener una retroalimentacin, adems de que se identifican los puntos susceptibles de mejora y la manera de cmo estos pueden ser mejorados para solucionar problemas que surgen durante el proceso de lanzamiento y con esto el mejoramiento continuo del proceso para obtener mayores beneficios.

Los puntos de mejora del proceso se pueden observar en el tema PIPs de este reporte.


25

DESARROLLANDO PIGMEX

Anlisis de requerimientos La Confederacin de Porcicultores Mexicanos (CPM) necesitaba un programa que le sirviera para la construccin de un biodigestor el cual ayudara al control y utilizacin de aguas residuales y excretas porcinas en Mxico.

El Sistema se diseo para que el porcicultor lleve una adecuada construccin de el biodigestor, as como para indicarle la cantidad de agua residual generada por su granja y la cantidad de gases que va a generar esta agua, con los cuales puede aprovecharlos para crear energa que le ayudara al mantenimiento de la granja o quemar los gases para una menor contaminacin. Los resultados se deban de mostrar de una manera que puedan ser de fcil entendimiento y que estos reflejen el beneficio de utilizar un biodigestor.

Para el tratamiento del agua residual se cre una estructura, los valores de esta estructura se obtienen mediante formulas, las cuales sern proporcionadas por CPM, las variables de estas formulas se le deben de pedir al usuario. Aqu es importante recalcar que el mtodo de obtencin de esta informacin debe de ser de forma comprensible debido a que hay mltiples variables en una sola opcin. Los datos que se piden al porcicultor son:

Nombre de la granja:

Este dato solo es para que el reporte final salga con el

El lugar donde est situada

Con el lugar podemos saber el factor de descomposicin de los residuos ya que no va a ser lo mismo una granja porcina en Guadalajara que en Yucatn debido a su factor de humedad

Estos factores de humedad y descomposicin son proporcionados por CPM y estos deben ir dentro del cdigo dejando una estructura para que en una siguiente versin se puedan actualizar

El tipo de granja.

El usuario debe de poder seleccionar el tipo o tipos de granja que tiene o maneja esto debido a que a veces en una granja se utilizan los tres tipos con lo que los parmetros varan

La granjas se clasifican en tres tipos los cuales son:


26

o Completo ( esto incluye los tres tipos ) o Engorda o Lechonera o Destetes

Aqu dependiendo si la granja es de engorda nicamente, se le pedirn el numero de cerdos en engorda

Peso de venta para sacrificio

En este valor se manejan rangos ya que cada porcicultor maneja distintos rangos para sacrificar a los cerdos

Los siguientes valores se le deberen pedir al porcicultor ya que los rangos que maneja cada porcicultor varia.

Peso de venta para sacrificio

Peso de salida de maternidad o de venta de lechones

Peso de salida o de venta de destetes

Perodo de lactancia

Perodo del destete a la preez

Relacin hembras /semental

Tamao de la camada, nacidos vivos

Ganancia de peso en lechones

Ganancia diaria promedio en destete

Ganancia diaria promedio en crecimiento

Tasa de cambio $ a dls.

Este parmetro se le pide para hacerle un estimado del costo de construccin del biodigestor.

Nmero y tipos de cerdos


27

o Se le pide al usuario el nmero y tipo de cerdos que tiene. Los cerdos se clasifican en Engorda Lechonera Destetes

Para calcular la cantidad aguas residuales que produce la granja es por medio de las UPAS una UPA e s la unidad de 100 Kg. de peso vivo estas unidades las obtiene el sistema por medio de los datos anteriores pedidos al usuario.

Se tuvo que estudiar las formulas proporcionadas por CPM ya que muchos de los parmetros se interrelacionan. Tambin se pidi que se realice una implementacin que posibilite en un futuro la actualizacin de ciertos parmetros como por ejemplo la temperatura ya que esta va variando dependiendo de los estados y del ao con lo que se podr crear un histrico ms exacto de las condiciones que tiene el rea donde se encuentra la granja.

Los datos que se le muestran al porcicultor sern los siguientes:

La cantidad total y las caractersticas de los desechos que genera la granja en su conjunto y sus diferentes edificios

El sistema para el tratamiento de los lquidos y estabilizadores de los slidos El tamao del crcamo de acuerdo con una estimacin gruesa de su costo. Caractersticas de las excretas y aguas residuales generadas por la granja esto ayuda

al porcicultor a saber cuntos gases y de que tipos se obtienen en el biodigestor Las dimensiones del biodigestor. As como el costo de construccin. Y la ganancia de energa obtenida.


28

Diseo de solucin Despus de un Anlisis de los requerimientos y necesidades expuestos por parte de la gente que representa a la Confederacin de Porcicultores Mexicanos se diseo una solucin que automatizar varios de los clculos necesarios para el control y manejo de la granja porcicola.

Se identificaron tres casos de uso, es decir, tres actividades principales en las que el usuario disparara un proceso del sistema. A continuacin se presenta el Diagrama de casos de uso generado y posteriormente se da una explicacin de sus componentes.

Actores: Se identifico que habra dos actores o usuarios del sistema, el Administrador quien tiene el acceso a almacenar en las tablas por primera vez o modificar los valores de aquellas variables necesarias para los clculos del sistema, tambin tiene acceso a las mismas actividades que el Porcicultor. El segundo usuario es el Porcicultor quien no tiene acceso a los datos del Administrador pero si puede realizar clculos y acceder a las diversas consultas que tendr el sistema, as como el poder imprimir las tablas y graficas que se generan.


29

En el diagrama se pueden ver los actores fuera de la caja que representa el sistema y dentro de esta se encuentran valos con los distintos procesos que realiza el sistema. Los procesos que interactan directamente con el usuario se llaman casos de uso principales.

Casos de uso principales: Como se observa en el diagrama son tres; Actualizar parmetros, capturar datos y consultar informacin. Cada uno de estos se describe a continuacin.

- Actualizar parmetros. Este caso de uso se encarga de actualizar los valores de los parmetros que se encuentran en la base de datos. El administrador podr cambiar el valor de los parmetros para que el sistema calcule y presente la informacin actualizada. Su flujo normal es:

1) El administrador selecciona la opcin de Actualizar parmetros en la ventana principal.

2) El sistema muestra una ventana de login.

3) El administrador introduce el nombre del usuario y la contrasea.

4) El sistema verifica que el usuario y la contrasea sean correctas.

5) El sistema muestra la ventana de actualiza parmetros.

6) EL administrador selecciona la categora de parmetros a actualizar.

7) El sistema muestra la ventana de captura de la categora seleccionada.

8) El administrador captura los nuevos valores de los parmetros.

9) El administracin presiona el botn guardar

10) El sistema guarda los nuevos valores en la base de datos.

11) El sistema regresa a la ventana de Actualizar parmetros.

12) El porcicultor selecciona la opcin Regresar principal

13) El sistema regresa a la ventana principal

- Capturar Datos. En este caso de uso, el usuario se encarga de capturar los datos de la granja del porcicultor, los cuales funcionan como insumos para el sistema. Su flujo normal es.

1) El sistema se encuentra en la ventana principal del sistema. 2) El porcicultor selecciona la opcin de Nuevo capturar datos. 3) El sistema muestra la ventana de captura de Captura datos. 4) El porcicultor captura cada uno de los datos pedidos en la ventana. 5) El porcicultor selecciona la opcin de aceptar.


30

6) El sistema guarda los datos de la granja en la base de datos. 7) El sistema regresa a la ventana principal del sistema. 8) El sistema desbloque la opcin de ver consultas.

- Ver consultas. Este caso de uso es en donde el sistema realiza las diferentes consultas. Su flujo es.

1) El porcicultor selecciona la opcin ver consultas. 2) El sistema muestra la ventana de consultas. 3) El porcicultor selecciona la consulta que desea ver. 4) El sistema muestra la consulta en una ventana con la opcin a imprimirla. 5) El porcicultor selecciona la opcin regresar a la ventana principal despus de

haber revisado la informacin deseada. 6) El sistema regresa a la ventana principal.

Relanzamiento del Proyecto Un relanzamiento tiene lugar cuando una vez que se realiz el lanzamiento del proyecto, surgen factores por los cuales es necesario realizar ajustes a la estrategia de desarrollo del proyecto, en el caso del proyecto Pigmex2009, fue necesario un relanzamiento debido al surgimiento de nueva informacin proporcionada por el cliente, la cual no coincida con lo establecido en un inicio, es decir, hubo un cambio en los requerimientos del proyecto.

El propsito del relanzamiento del proyecto es establecer un entendimiento en comn del equipo acerca de los ajustes que fueron necesarios a los diferentes aspectos del proyecto por el cambio a los requerimientos originales.

Para el proyecto Pigmex2009 los ajustes se realizaron a la estrategia de desarrollo la cual se define en la junta 3 del lanzamiento, en esta junta los miembros del equipo definen el producto que construirn y como lo realizarn a travs del diseo conceptual y estimacin del tamao, una lista de todos los productos que deben ser generados, una estrategia para cumplir las metas del equipo, un proceso para realizar bien el trabajo a la primera vez, y una lista de cualquier actividad que deba ser hecha por el equipo.

La estrategia de desarrollo despus de los ajustes consisti en lo siguiente:

Para el diseo conceptual se definieron dos componentes adicionales al diseo original.

El componente Carga datos fue creado a partir de la necesidad de cargar datos ya capturados por el usuario, evitando capturar los datos de una granja ms de una vez, lo cual


31

se traduce en un ahorro de tiempo y esfuerzo para el usuario final, aumentando as la productividad.

El componente Ayuda fue creado a partir de la necesidad de brindar apoyo e informacin adicional al usuario para facilitar el uso y entendimiento del sistema Pigmex2009, para de esta manera disminuir los problemas y confusiones que suelen surgir durante las primeras veces que el usuario utiliza un sistema que inicialmente desconoce.

Despus de los ajustes, el diseo conceptual result de la siguiente manera:

En base al diseo conceptual se definieron los mdulos a desarrollar, debido a que se decidi que el diseo sera de 3 capas los mdulos que conformaran el sistema se clasificaron en: mdulos de presentacin (encargados de interactuar con el usuario), mdulos de negocio (encargados de la lgica del programa tal como los clculos o procesamiento de la informacin), y mdulos de datos (encargados de la gestin de la base de datos).

Con la intencin de facilitar la estimacin de tamaos de cada componente que sera desarrollado, el equipo defini en el lanzamiento un estimado de los tamaos para los componentes dependiendo del tipo o categora del componente, esto debido a que el tamao de un componente depende en gran medida de la capa o categora a la que este corresponda (Presentacin, Negocio, o Datos).


32

Cabe sealar que no se realiz ningn ajuste al estimado de tamaos original, quedando de la siguiente forma:

En el lanzamiento del proyecto PigMex2009 se consider originalmente una estrategia de desarrollo por mdulos que constara de cuatro iteraciones con duracin aproximada de 3.5 semanas por iteracin, cuyo contenido se muestran a continuacin:

5. Primera iteracin Prototipo 0.1 de modulo de clculo de datos. Prototipo 0.1 de modulo Naves de Cerdos. Elaboracin de la Base de Datos. Prototipo 0.1 del modulo de naves de cerdos Relaciones entre PPP y CVA en

la Base de Datos. 6. Segunda iteracin

Prototipo 0.1 del modulo captura de datos. Prototipo 0.1 del modulo despliega consultas. Versin 1.0 del modulo almacena datos de la Base de Datos.

7. Tercera iteracin Prototipo 0.1 del modulo principal. Versin 1.0 del modulo captura datos. Prototipo 0.2 del modulo despliega consultas.

8. Cuarta iteracin Versin 1.0 del modulo login. Versin 1.0 del modulo actualiza parmetros. Versin 1.0 del modulo almacena parmetros. Versin 1.0 del modulo principal.


33

El equipo realiz ajustes en esta estrategia de desarrollo, la cual se redefini en dos fases, en donde la primera fase constara de realizar una arquitectura ejecutable que contemplaria las funciones bsicas que se solicitaban, esta fase se dividira en 3 iteraciones, y en la segunda se agregaran las funciones ms avanzadas del sistema, a continuacin se muestra el contenido de las distintas fases e iteraciones que resultaron de la redefinicin de la estrategia de desarrollo:

Primera Fase

1. Primera iteracin Primer prototipo de arquitectura ejecutable (Mdulo de arquitectura de datos). Versin final de tabla 1 (Mdulo de Naves de Cerdos). Primer prototipo de Base de Datos (que incluya los datos y dependencias de la tabla

1). Primer prototipo de interfaz. Mdulo de almacn de datos.

2. Segunda iteracin

Arquitectura ejecutable final (Mdulo principal y Mdulo despliega datos). Primer prototipo de tabla 2 (Mdulo de separacin de slidos y Mdulo de tamao

de crcamo). Segundo prototipo de Base de Datos (aadiendo los datos dependientes de las tablas

1 y 2). Versin final de la interfaz. Primer prototipo de la tabla 3 (Mdulo de laguna y Mdulo de biodigestor).

3. Tercera iteracin

Mdulo de captura de datos. Mdulo de carga de datos. Mdulo de imprimir consultas. Mdulo de ayuda, Versin final de tabla 2. Versin final de tabla 3.

Segunda Fase

Mdulo login. Mdulo de actualizar parmetros. Mdulo almacenar parmetros.


34

Arquitectura web.

Al definir el proceso general de desarrollo que se seguira hasta la entrega final se acordaron: las principales fases del proyecto, las principales actividades de cada fase, y los elementos a incluir en la lnea base en cada fase.

En el lanzamiento del proyecto PigMex2009 se defini originalmente que el proceso de desarrollo que se seguira sera el propuesto por el TSP, esto en el relanzamiento no se modific, mantenindose de la siguiente manera:

En cuanto al plan de soporte se acord que se seguira el plan original definido en el lanzamiento del proyecto, el cual consideraba las siguientes herramientas para el desarrollo y soporte del proceso:

Requerimientos

Word 2003 Star UML 5.0

HLD

Word 2003


35

Star UML 5.0 Power Point 2003

DLD


Codificacin

Java SE 6 Eclipse 3.4 Plug-in DTP (Data Tools Project) Plug-in EMF (Eclipse Modeling Framework) Plug-in Instantions Designer Plug-in JST (J2EE Standard Tools) Plug-in WST (Web Standard Tools) Plug-in Subclipse (Subversion control)

Servidor de Aplicaciones

TomCat 6.0.1.8

Servidor de BD

MySQL 5.1.3.0

Pruebas unitarias y de integracin del sistema

Word 2003 Excel 2003 Junit 4.3

Control de versiones

Subversion 1.5 Tortoise SVN 1.5.8

Debido a la necesidad de una norma o directriz que regule la actividad de gestin y control de versiones, el equipo lleva a cabo la integracin del comit de control de la configuracin


36

(CCB), el proceso de gestin de configuracin tiene como principal objetivo asegurar la integridad de los productos desarrollados.

Para el proyecto PigMex2009 el comit de control de la configuracin (CCB) fue integrado de la siguiente manera.

Integracin del CCB

Administrador de Soporte (Presidente): Jess Galvn Peralta.

Lder del equipo: Germn Gil de Arvalo Cano.

Administrador de la Interfaz con el Cliente: Jess Galvn Peralta.

Administrador de Diseo: Roberto Carlos Osorno Valdez.

Arquitectura ejecutable Debido a que los integrantes del equipo se vieron en la necesidad de hacer un relanzamiento ocasionado por los cambios en la especificacin de requerimientos original, el equipo desarrollo dos prototipos de la arquitectura del sistema, el primero fue creado para cubrir las necesidades inciales del cliente, posteriormente los cambios en los requerimientos por parte del cliente dieron origen a la creacin del segundo prototipo el cual contemplaba las funcionalidades del primero con algunos ajustes y con un conjunto de funciones avanzadas. A continuacin se muestran los diagramas que representan estos prototipos:


37

Prototipo uno

Este prototipo contemplaba las funcionalidades bsicas del sistema entre las que se encontraban:

La pantalla principal desde la cual sera posible acceder a las diferentes opciones consulta.

La opcin para capturar los datos bsicos de la granja para iniciar las diferentes consultas.

La pantalla de Login asegura que la actualizacin de parmetros sea efectuada solo por el personal capacitado.

La pantalla Despliega consultas es una pantalla que se recicla y se reutiliza mostrando todas las consultas sobre esta misma, evitando con esto el uso de mltiples ventanas.

Los anteriores son solo algunas de las caractersticas que posea este prototipo, y para el cual no se llev a cabo por completo debido a los cambios que sufrieron los requerimientos, los cuales dieron paso al prototipo dos.


38

Prototipo dos.

El desarrollo de este prototipo se inicio inmediatamente con el relanzamiento debido a la necesidad de realizar ajustes en el diseo del sistema, despus de analizar el primer prototipo y evaluar los ajustes que se necesitaban realizar, el equipo llego a la conclusin de que podan utilizar el primer prototipo como base del segundo agregando a este ltimo funciones adicionales, entre las cuales se encuentran las siguientes:

El mdulo de cargar datos se encargara de tomar los datos ya existentes de una granja y colocarlos como datos inciales para llevar a cabo las consultas, evitando as introducir todos los datos de la granja cada vez que se desee hacer alguna consulta.

El mdulo de ayuda se encargara de proporcionar apoyo al usuario en cuanto al uso del sistema para mejorar la experiencia del usuario final con el sistema.

Al trmino de la definicin anterior se concluyo en que la arquitectura de la solucin constara de las siguientes caractersticas:

Arquitectura de tres capas y un nivel

1. Capa de presentacin: es la que ve el usuario (tambin se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la informacin y captura la


39

informacin del usuario en un mnimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Tambin es conocida como interfaz grfica y debe tener la caracterstica de ser "amigable" (entendible y fcil de usar) para el usuario. Esta capa se comunica nicamente con la capa de negocio.

2. Capa de negocio: es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envan las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lgica del negocio) porque es aqu donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentacin, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de l. Tambin se consideran aqu los programas de aplicacin.

3. Capa de datos: es donde residen los datos y es la encargada de acceder a los mismos. Est formada por uno o ms gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperacin de informacin desde la capa de negocio.

En una arquitectura de tres niveles, los trminos "capas" y "niveles" no significan lo mismo ni son similares.

El trmino "capa" hace referencia a la forma como una solucin es segmentada desde el punto de vista lgico. En cambio, el trmino "nivel" corresponde a la forma en que las capas lgicas se encuentran distribuidas de forma fsica. Por ejemplo:

Una solucin de tres capas (presentacin, lgica del negocio, datos) que residen en un solo ordenador (Presentacin + lgica + datos). Se dice que la arquitectura de la solucin es de tres capas y un nivel.

Arquitectura de mquina virtual de java

Para poder ejecutar una aplicacin en una Mquina Virtual de Java, el programa cdigo debe compilarse de acuerdo a un formato binario portable estandarizado, normalmente en forma de ficheros con extensin .class.

El cdigo resultante de la compilacin es ejecutado por la JVM que lleva a cabo la emulacin del conjunto de instrucciones, bien por un proceso de interpretacin o ms habitualmente mediante un compilador JIT (Just In Time), como el HotSpot de Sun. Esta ltima opcin convierte el bytecode a cdigo nativo de la plataforma destino, lo que permite una ejecucin mucho ms rpida. El inconveniente es el tiempo necesario al principio para la compilacin.


40

En un sentido amplio, la Mquina Virtual de Java acta como un puente entre el resultado de la compilacin (el bytecode) y el sistema sobre el que se ejecuta la aplicacin. Para cada dispositivo debe haber una JVM especfica, ya sea un telfono mvil, un PC con Windows XP, o un microondas. En cualquier caso, cada mquina virtual conoce el conjunto de instrucciones de la plataforma destino, y traduce un cdigo escrito en lenguaje Java (comn para todas) al cdigo nativo que es capaz de entender el Hardware de la plataforma.

Vistas de la arquitectura Toda arquitectura de software debe describir diversos aspectos del software. Generalmente, cada uno de estos aspectos se describe de una manera ms comprensible si se utilizan distintos modelos o vistas. Es importante destacar que cada uno de ellos constituye una descripcin parcial de una misma arquitectura y es deseable que exista cierto solapamiento entre ellos. Esto es as porque todas las vistas deben ser coherentes entre s, evidente dado que describen la misma cosa.

A continuacin se presentan las vistas que describen ms a detalle la arquitectura del sistema PigMex2009:

Vista lgica


41

Vista de proceso

Actividad: Actualizar parmetros


42

Actividad: Consultar informacin


43

Actividad: Capturar datos


44

Vista de despliegue

Vista de desarrollo


45

POSTMORTEM

Resultados obtenidos Despus de haber trabajado por 14 semanas en el proyecto Pigmex 2009 varias de las metas se cumplieron, algunas otras desafortunadamente no, a continuacin se realiza un resumen de los resultados obtenidos.

En la siguiente grafica se muestra el valor generado en el proyecto de forma acumulada semanalmente, se puede observar que al final de las 14 semanas se planeaba terminar al 100% el proyecto, sin embargo se logr el 70.1 %.

Agregndole a estas 14 semanas las 2 que duro el lanzamiento, el tiempo de trabajo total en el proyecto fue de 16 semanas o 4 meses. Con estos datos podemos decir que la meta de la direccin de que el proyecto se terminara en 6 meses se estuvo cumpliendo ya que con 2 tercios del tiempo se termino un 70.1% del sistema. Y la meta del equipo de entregar el producto en tiempo planeado no se cumpli ya que se tuvo un error de estimacin mayor al 10%.

En la siguiente grafica se muestra el acumulado de horas trabajadas por el equipo semana tras semana, se observa una estrecha relacin con la grafica anterior, ya que al haber trabajado menos horas de las planeadas tambin origino menos avance de lo planeado en la misma proporcin, por lo tanto, el origen de no haber avanzado lo planeado estuvo en no haber cumplido con las horas pre establecidas y no en una mala estimacin.


46

En la grafica de abajo se aprecia la densidad de defectos por fase, se puede ver que esta se mantuvo siempre por debajo de los 9 def/KLoc lo cual cumple con la meta del equipo de entregar un producto de calidad debajo de los 20 def/KLoc.

En la grfica presentada a continuacin se muestra el rendimiento logrado durante el proceso, se puede apreciar que en todo momento estuvo por encima del 70% y muy cercano


47

a lo planeado. Esto demuestra que la meta del equipo de tener un alto rendimiento mayor al 60% se cumpli de manera satisfactoria.

En la grafica siguiente se muestra el perfil de calidad, este representa la proporcin del tiempo de desarrollo, revisiones y los defectos obtenidos. Esta grafica tiene relacin directa con el resultado de 2.53 A/FR obtenido en el proyecto y que cumple con la meta del equipo de disminuir el tiempo de costo de 2 A/FR.

Otras de las metas establecidas por la direccin, ya sea de manera explcita o implcita, fueron:


48

- Hacer ms amigable el sistema PigMex para facilitar su uso (interaccin y consulta). Esta meta despus del relanzamiento se tradujo en realizar 3 consultas, lo cual debido a que otro equipo de trabajo continuar con el desarrollo, no se cumpli y solo se realizo una.

- Automatizar el biodigestor. Esta meta no se cumpli ya que no se recibieron las especificaciones de cmo hacer la consulta.

- Hacer consultas en lnea. Esta meta no se cumpli, sin embargo no entraba en el plan realizado por el equipo desde un principio.

- Obtener un producto libre de defectos. Esta meta se cumpli ya que todas las pruebas fueron superadas satisfactoriamente.

As mismo, otras metas establecida por el equipo durante el lanzamiento fueron:

- Terminar el lanzamiento el lunes 23 de febrero de 2009. Esta meta no se pudo cumplir ya que el lanzamiento duro dos semanas y no una como se planeo.

- Cumplir los requerimientos mnimos establecidos. No se cumpli ya que por decisin se implemento solo una consulta y no tres.

- Mantener informado al cliente del estado del proyecto. Solo se realizo una junta con el cliente, por lo cual no se cumpli esta meta que pretenda como mnimo tres.

- Poner en prctica el proceso TSP. Esta meta si se cumpli ya que en todo momento se llevo a cabo el proceso TSP.

Finalmente y en base a los resultados presentados podemos decir que con la direccin aun faltan por cumplirse la mayora de las metas, pero cabe mencionar que todava falta que otro equipo de trabajo contine con el desarrollo del sistema Pigmex 2009, por lo que se espera que estas metas lleguen a cumplirse.

Como equipo de trabajo podemos decir que la mayora de las metas establecidas se cumplieron, sobre todo la ms importante, la cual era poner en prctica el proceso de TSP ya que el equipo de trabajo se encontraba en un proceso de aprendizaje mediante la elaboracin de este proyecto usando TSP.


49

PIPs

- Capacitacin previa en la definicin de metas y medidas para las metas. - Junta 7: utilizar plantillas de riesgos de proyectos previos para asegurar que no se

ignoran. - Metas mejor planteadas, Diseo conceptual de mayor calidad.

Conclusiones y comentarios

David Daz Garca

Realizar el proyecto de investigacin mediante un proyecto real usando PSP y TSP fue una gran experiencia, el hecho de haber aprendido dos procesos tan importantes como los mencionados ha cambiado mi modo de ver el desarrollo de software, de una simple actividad de programacin a todo un conjunto de actividades y responsabilidades, que incluye un gran cuidado por la calidad del producto desarrollado y por la planeacin y seguimiento del proyecto.

Tambin el uso de distintas herramientas como lo son JAVA, UML, Eclipse y muchas ms han hecho que el desarrollo del proyecto implique un aprendizaje sobre cmo se integran y complementan las aplicaciones para un fin comn como lo es un proyecto de desarrollo de sistemas.

En cuanto al trabajo en equipo tambin ha representado algo muy til, ya que a diferencia de los trabajos en equipo de otras materias este ha sido algo mucho ms cercano a lo que se presenta en el campo laboral al que nos perfilamos, por lo tanto, hemos ganado gran experiencia en este aspecto.

En trminos generales el realizar el proyecto de investigacin ha tenido muy buenos resultados, que tal vez no se vean reflejados en las metas cumplidas por parte del proyecto o por los nmeros y estadsticas en los reportes de PSP y TSP, pero si en la parte de aprendizaje y experiencia integral de cada uno de los integrantes de este proyecto de investigacin. En lo personal creo que fue la mejor experiencia de mis estudios en la universidad.


50

Roberto Carlos Osorno Valdez

En el transcurso del proyecto fuimos capacitados en el uso del TSP, el cual proporciona un marco de trabajo de procesos definidos que est diseado para apoyar a equipos de ingenieros a organizar y producir proyectos de software de gran escala. Uno de los requerimientos para participar en el TSP era que los integrantes ya estaban capacitados sobre el PSP de tal manera que el proyecto pudiera funcionar adecuadamente.

Pienso que la capacitacin en los procesos PSP y TSP forman profesionales altamente capacitados en definir estrategias y planes de accin, los cuales no solo pueden ser aplicados al mbito profesional, sino tambin al cotidiano, ya que actualmente esta formacin me permite realizando proyecciones y as anticiparme a las distintas situaciones que se puedan presentar, o bien crear planes para mitigar dificultades que ya se estn presentando.

Es importante sealar que durante el desarrollo del proyecto el trabajo en equipo fue un factor fundamental y decisivo para alcanzar las metas definidas en el lanzamiento, y personalmente puedo decir que formar parte de un equipo de desarrolladores que siguen un proceso bien trazado fue una experiencia sumamente enriquecedora tanto profesional como personalmente debido a la responsabilidad, apoyo, y buen trato que siempre se mantuvo entre los integrantes.

Adicionalmente puedo decir que fue una gran oportunidad para aprender y mejorar las habilidades en el uso la herramienta Star UML la cual fue de gran ayuda en el lanzamiento del proyecto ya que nos permiti especificar, construir, y documentar sistema sin dejar lugar a ambigedades.


51

FIRMAS

David Daz Garca

Alumno, Adm. De Calidad, Adm. De Planeacin.

Roberto Carlos Osorno Valdez

Alumno, Adm. Proceso, Adm. Diseo, Adm Pruebas

Luis Fernando Castro Careaga

Profesor, Coach TSP


52

ANEXOS

1. Reporte PSP David Daz Garca

Anlisis de la exactitud de la estimacin de tamao

Compare el reporte intermedio lnea base para la exactitud de estimacin de tamao con los programas posteriores al reporte. Cunto cambi su exactitud de estimacin de tamao? Por qu?

La exactitud en la estimacin, aunque en general, no fue mucho mejor en los programas 7 al 10, pero si se mantuvo ms estable, esto es debido a que se usaron ms los mtodos A y B en la PROBE adems de que se tena ms experiencia en la estimacin de tamao de objetos.

Actual Size

050

100150200250300350400450500

1 2 3 4 5 6 7 8 9 10

Program Number

LOC

Size Estimating Error

-60

-40

-20

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10

Program Number

%


53

Qu tan frecuentemente estuvo mi tamao real del programa dentro de mi intervalo estadstico de prediccin del 70%?

1 2 3 4 5 6 7 8 9 10

UPI70% 309 285 276 362

LPI70% 123 71 137 206

Real 255 171 136 51 214 261 192 229 205 463

De los 4 programas en los que se planea un intervalo de prediccin, 3 veces se obtuvo un valor dentro de este, es decir, el 75% de las veces se acert en esta prediccin, solo se fallo en el programa 10 que fue el mas grande.

Tengo una tendencia a agregar/no considerar objetos completos? En ninguna ocasin se agregaron objetos no considerados, solo en un par de ocasiones se tuvieron que modificar cuando no estaba planeado. Tengo una tendencia a juzgar equivocadamente el tamao relativo de objetos?

programa 4 5 6 7 8 9 10 Objetos con mas de 20 LOCs de equivocacin

0 3 2 1 2 0 2

Mi tendencia, como se ve en la grafica de estimacin de error, es a subestimar los objetos, es decir, 8 de las 10 veces resultaron ms LOCs de las planeadas, con excepcin de los programas 4 y 9 en los cuales ya se usa la plantilla de estimacin de tamao. Y si, frecuentemente se juzga equivocadamente e tamao de los objetos en el size estimating, alrededor de 2 objetos por programa se juzgan con mas de 20 LOCs de error.

Necesito calcular el rango de tamao relativo usando mis datos de objeto histricos? Puedo? Si, seria bueno calcular el rango de tamao relativo, lo cual lograra que el size estimating funcionara mejor, y se podra usando alguna distribucin.


54

Basado en mis datos histricos de exactitud de estimacin de tamao, cul es una meta de estimacin de tamao realista para mi? En la primera mitad la estimacin estuvo en un rango del 90%, en la segunda parte dentro de un rango del 60% y como meta se pretende que la estimacin se mantenga en un rango del 30%. Cmo puedo modificar mi proceso para cumplir esa meta? Lo que necesito es tener una mejor estimacin de tamao, para lo cual puedo implementar una nueva escala de tamao de objetos como la lognormal que en una ocasin le, y que ajustara mejor mi size estimating.

Anlisis de la exactitud de estimacin del tiempo

Compare el reporte intermedio lnea base para la exactitud de estimacin de tiempo con los programas posteriores al reporte. Cunto cambi su exactitud de estimacin de tiempo? Por qu? La estimacin de tiempo fue mas exacta, esto por una mayor experiencia en el uso de la PROBE y el Size estimating, adems de la posibilidad de usar los mtodos Ay B. Qu tan frecuentemente estuvo mi tiempo de desarrollo real dentro de mi intervalo estadstico de prediccin del 70%?

1 2 3 4 5 6 7 8 9 10

UPI70% 616 500 521 698


55

LPI70% 476 232 349 486

Real 440 432 362 315 263 528 367 492 539 739

De los 4 programas en los que planteo un intervalo de prediccin del 70% en 3 de ellos no se obtuvo un tiempo dentro del rango, una vez por debajo y dos veces por arriba, es decir el 75% de las veces no se acert siendo el programa 8 el nico acertado. Mi productividad es estable? Por qu si o por qu no?

Salvo en los programas 4 y 5 que es donde hubo ms variacin, en el resto se mantuvo estable entre el 20% y 40%. Inclusive en el programa 10 creci debido a que se dedico poco tiempo a pruebas y compilacin. Esto debido a que la introduccin de nuevas etapas como las revisiones reduce tiempo de pruebas y compilacin lo cual mantiene o aumenta la productividad. Cmo puedo estabilizar mi productividad? La productividad se comenzara a estabilizar cuando haya una relacin mas estrecha entre el tamao y el tiempo de desarrollo de los programas, y esto se conseguir siendo ms exactos en la estimacin de los dos. Cunto estn mis estimados de tiempo afectados por la exactitud de mis estimados de tamao? (La regresin lineal me ayudara?)


56

La exactitud en las estimaciones de tiempo y tamao no son para nada proporcionales, por lo tanto una regresin lineal no servira, es necesaria una regresin mltiple parecida a la realizada en el programa 10. Inclusive con el uso ms frecuente del mtodo A en los ltimos programas se tienen una pequea correlacin. Basado en mis datos histricos de exactitud de estimacin de tiempo, cul es una meta de estimacin de tiempo realista para mi? En la segunda parte ya no se tuvieron errores tan grandes como en la primera en la que incluso se llego cerca del 80%. El ms grande fue de aproximadamente el 35%, en el programa 8. Creo que una meta realista seria mantener el porcentaje de error por debajo del 20% Cmo puedo modificar mi proceso para cumplir esa meta?

El problema esta en que no se esta haciendo una correcta estimacin de tamao de los objetos, por ello en la etapa de plantacin, al realizar el diagrama, no solo se dividir el programa en objetos, tambin cada objeto se dividir en mtodos y se estimara el numero de LOCs de cada uno.

Anlisis de defectos de rendimiento

Qu tipo de defectos introduzco durante el diseo y la codificacin?

Number Injected

Percentage Injected

Number Removed

Percentage Removed

Type Design Code Design Code Compile Test Compile Test

10 1 1 2.4% 1.6% 0 0 0.0% 0.0%

Size Estimating Error

-60

-40

-20

0

20

40

60

80

100

1 2 3 4 5 6 7 8 9 10

Program Number

%


57

20 2 22 4.8% 34.9% 15 3 45.5% 7.9%

30 1 2 2.4% 3.2% 1 1 3.0% 2.6%

40 2 15 4.8% 23.8% 8 4 24.2% 10.5%

50 3 7 7.1% 11.1% 5 0 15.2% 0.0%

60 7 8 16.7% 12.7% 2 7 6.1% 18.4%

70 4 0 9.5% 0.0% 0 2 0.0% 5.3%

80 17 5 40.5% 7.9% 2 13 6.1% 34.2%

90 0 0 0.0% 0.0% 0 0 0.0% 0.0%

100 5 3 11.9% 4.8% 0 8 0.0% 21.1%

Total 42 63 33 38

El mayor nmero de defectos introducidos durante el diseo son los de tipo 80 que son los de funcin o lgicos, seguidos de los 60 o de chequeo de tipos. En la codificacin se introducen ms del tipo 20 o de sintaxis, que es algo lgico, seguidos de los de tipo 40 que son de asignacin. Qu tendencias son aparentes en los defectos por unidad de tamao (e.g., KLOC) encontrados en las revisiones, compilaciones y pruebas?


58

En la revisin de diseo cada vez se encuentran ms errores lo cual es bueno ya que es el primer filtro de errores en el proceso. En la revisin de cdigo comienzan a encontrarse menos errores lo que nos habla de una mejor codificacin y que tambin se ve reflejada en la compilacin donde el nmero de errores encontrados se ha reducido inclusive a cero. Tambin resaltar que el nmero de errores en pruebas cada vez es menor y esto es muy bueno. En la ltima grafica se observa que el porcentaje de defectos removidos por fase mejora para las revisiones como se buscaba. Qu tendencias son aparentes en los defectos totales por unidad de tamao?


59

El nmero de defectos a excepcin del programa 4 se ha mantenido estable pero en un nivel muy alto cercano a 40 lo cual tiene que corregirse aunque en el programa 10 disminuyo un poco. Cmo mis tasas de eliminacin de defectos (defectos eliminados/hora) se comparan para la revisin de diseo, revisin de cdigo, compilacin y pruebas?

programa 7 8 9 10 Def/Hr-DLDR 12.8 2.09 2.65 4.15 Def/Hr-CDR 37.5 6.61 3.95 4.16 Def/Hr-Comp 25 28.46 Sin errores Sin errores Def/Hr-Test 25 2.22 2.68 2.25

Las tasas de eliminacin en el programa 7 fueron muy altas debido a que no se respeto el tiempo planeado para las etapas contempladas. Sin embargo tomando en cuenta del programa 8 al 10 donde se trato de mantener una revisin de 200 LOCs por hora la revisin de diseo mantuvo una tasa creciente, la revisin de cdigo aunque no fue creciente se mantuvo por encima de 4, la de compilacin fue grande o inclusive no se tuvieron errores encontrados mientras que la de pruebas se mantuvo cerca de los 2.3. en general creo que las tasas de revisin fueron buenas. Cules son mis tasas de revisin (tamao revisado/hora) para la revisin de diseo y revisin de cdigo?


60

Hasta ahora con excepcin del programa 7 donde no se tubo una plantacin correcta se ha planeado para que estas revisiones se encuentren alrededor de las 200 LOCs por hora, lo cual se ha logrado. Cules son mis influencias de eliminacin de defectos para la revisin de diseo, revisin de cdigo y compilacin contra las pruebas unitarias?

7 8 9 10 DRL(DLDR/UT) 0.512 .94 0.99 1.17 DRL(CDR/UT) 1.5 2.98 1.47 1.18 DRL(Compile/UT) 1 12.84 Sin errores Sin errores

A excepcin del programa 7 donde se tubo una plantacin incorrecta al momento de realizarlo, los programas 8 al 10 presentaron valores que fueron creciendo programa a programa y prcticamente en todos los casos se obtuvo valor igual o mayor a uno lo que indica que las tasas de eliminacin fueron mayores a las de pruebas como se busca. Hay alguna relacin entre el rendimiento y la tasa de revisin (tamao revisado/hora) para las revisiones de diseo y cdigo?


61

En cuanto a la revisin de diseo si ignoramos el programa 7 no se encuentra alguna relacin ya que la tasa de reviso estuvo siempre alrededor de los 200 sin embargo el rendimiento fue creciendo. En la revisin de cdigo y en las revisiones juntas se puede observar ligeramente que en el programa 7 donde se revisaron ms de 500 LOCs por hora es donde se presento el menos rendimiento que fue cercano a 50. Hay una relacin entre el rendimiento y A/FR para los programas 6 al 8?


62

Si, en este caso si se puede ver claramente que mientras el Appraisal to Filure Ratio aumento programa a programa el rendimiento tambin fue mejorando.

Anlisis de calidad

Compare el reporte intermedio de base para la calidad en las pruebas unitarias con los programas posteriores al reporte. Cunto cambi la calidad de los programas entrando a las pruebas unitarias? Por qu?

programa 1 2 3 4 5 6 7 8 9 10 Defectos antes de pruebas

2 1 7 1 4 7 2 3 4 2

Defectos totales

9 5 10 11 8 13 8 14 12 16

% defectos

22.22 20 70 9.09 50 53.85 25 21.43 33.33 12.5


63

antes de pruebas

Se puede ver que el porcentaje de defectos antes de las pruebas en los programas 1 al 6 tenan valores variados que alcanzaban inclusive ms de 50 y hasta 70 por ciento. Pero en los programas 7 al 10 disminuyo a no ms de 33.33 e inclusive alcanzo su mnimo valor en el programa 10 con 12.5. Esto muestra que las etapas de revisiones ayudo a que en los programas mas complejos, que fueron los ltimos, se tuviera un programa mas limpio antes de las pruebas. Cmo puedo juzgar la calidad de mi producto final de manera temprana en mi ciclo de desarrollo? La calidad de l producto se podra juzgar por el numero de errores encontrado en compilacin y en pruebas, ya que un producto que en estas fases presento muchos errores es muy probable termine con otra gran cantidad de estos. Estoy encontrando mis defectos en las revisiones de diseo y cdigo? Por qu si o por qu no?

Si esto se puede ver en las lneas verde y rosa de la primer grafica donde los defectos encontrados en revisiones ha aumentado con el paso de los programas, sin embargo el numero de errores totales se mantiene casi estable, lo que indica que cada vez se encuentran mas errores en las revisiones. Cmo puedo hacer ms efectivo y eficiente mi proceso? El proceso seria ms efectivo y eficiente si en lugar de encontrarse lo errores en etapas tempranas, estos no se cometieran. Con esto no solo diminuira el tiempo en pruebas que aun es alto, sino que no seria necesario en un futuro aumentar en nmero de LOCs por hora en las revisiones para alcanzar una mejor calidad de producto.


64

Basado en mis datos histricos, cules son algunas metas de calidad realistas para mi? Se aprecia que el problema esta en que el numero de errores introducidos es aun muy alto y por encima de los 34 errores por KLOC, entonces una meta realista seria este nmero este por debajo de 25. Cmo puedo cambiar mi proceso para cumplir esas metas?

En la grafica pareto se aprecia que los errores mas cometidos son los 20 y 80, creo que con la revisin de cdigo y la compilacin se eliminan prcticamente todos los 20, pero para los de tipo 80 hay que tomar acciones ya que toman mucho tiempo de correccin. Por ello puedo hacer un anlisis de estos errores y en base a ello modificar lo suficiente o inclusive construir un checklist ms eficiente para la revisin de diseo que es donde mas se introducen.

Defects Removed By Type

0

5

10

15

20

25

30

20 80 40 60 50 100 70 30 10 90

Defect Injection % by Phase

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 1

Program Number

%

Code

Design


65

Otros aspectos analizados

Se puede observar que entre el rendimiento, la productividad y el A/F Ratio hay una correlacin que demuestra que al tener ms costos de apreciacin que de falla, lo cual se refleja en un mejor rendimiento, ayuda a aumentar nuestra productividad.

Yield vs. A/FR

0102030405060708090

100

0 2 4 6

Appraisal to Failure Ratio (A/FR)

Yie

ld %

Productivity vs. A/FR

0

10

20

30

40

50

60

0 2 4 6


Pro

duct

ivity

(LO

C/H

our)

Productivity vs. Yield

0

10

20

30

40

50

60

0 20 40 60 80 100

Yield %

Prod

uctiv

ity (L

OC

/Hou

r)


66

Por el contrario se observa que al aumentar el rendimiento y por consecuencia el A/F Ratio tambin disminuyen los errores por KLOC

2. Reporte PSP Roberto Carlos Osorno Valdez

Anlisis de la exactitud de la estimacin de tamao 30 40 -25.00%

Tendencia en la exactitud de estimacin de tamao en los primeros seis programas.

Programa Tamao (LOC's) Error de estimacin Correlacin

# Estimad

o Real (%) Val

Absoluto Abs

Promedio R2 1 260 146 78.08% 78.08% 78.08% 2 200 65 207.69% 207.69% 142.89%

3 100 83 20.48% 20.48% 102.09% 0.4058026

2 4 148 171 -13.45% 13.45% 79.93% 5 63 113 -44.25% 44.25% 72.79%

6 199 321 -38.01% 38.01% 66.99% 0.0931222

1

Test Defects vs. A/FR

0

10

20

30

40

50

60

0 2 4 6


Def

ects

/KLO

C

Test Defects vs. Yield

0

10

20

30

40

50

60

0 20 40 60 80 100

Yield %

Def

ects

/KLO

C


67

Observamos que la exactitud de estimacin de tamao ha mejorado mucho a partir de la introduccin del mtodo PROBE, si examinamos el promedio de exactitud podemos apreciar una disminucin en el error de la exactitud en la estimacin de tamao, esto debido a que:

El error absoluto promedio paso de 102.09% y correlacin R^2=0.41 de los primeros tres programas a 69.99% y correlacin R^2=0.09 para los ltimos tres programas, indicando una mejora en la estimacin de tamao, esto gracias a la introduccin del mtodo PROBE.

-100.00%

-50.00%

0.00%

50.00%

100.00%

150.00%

200.00%

250.00%

1 2 3 4 5 6

Erro

r (%

)

Programa#

Exactitud de estimacin de tamao (%)

0.00%

20.00%

40.00%

60.00%

80.00%

100.00%

120.00%

140.00%

160.00%

1 2 3 4 5 6

Erro

r (%

)

Programa#

Exactitud promedio de tamao (%)


68

Para cada uno de los programa 4, 5 y 6, cmo se comparan las LOC de objeto estimadas con las LOC de objeto reales?

Programa LOC's de objeto Exactitud

# Estimado Real (%) Val

Absoluto 4 220 193 13.99% 13.99% 5 130 120 8.33% 8.33% 6 160 152 5.26% 5.26%

Valor R^2=

0.98589032

La exactitud de estimacin de tamao de objeto mejoro considerablemente de 13.99% en el programa 4A a 8.33% para el programa 5A, y posteriormente a 5.26% con R^2=0.985 para el programa 6A, esta mejora es causada por la introduccin del mtodo PROBE a partir del programa 4A. Esta es una mejora sumamente considerable en la estimacin de LOC's de objeto.

Para cada uno de los programa 4, 5 y 6, si las LOC de objeto estimadas no estn cercanas las LOC de objeto reales, determine por qu.

Debido al resultado del anlisis en el punto anterior (vase 1.2), este caso no sucede.

0.00%2.00%4.00%6.00%8.00%

10.00%12.00%14.00%16.00%

4 5 6

Exac

titu

d

Programa#

Tendencia de exactitud (LOC's objeto)


69

Basado en el anlisis anterior, cul es la mejor cosa que usted podra hacer para mejorar su exactitud en la estimacin?

Debido al resultado del anlisis en el punto 1.2, este caso no sucede.

Vaya a la hoja PROBE de su libro de trabajo del estudiante y ponga el selector del programa para el programa 7. Examine las betas del mtodo A. Son tiles para la estimacin del programa 7? Explique por qu o por qu no.

Las betas del mtodo A para el programa 7 son las siguientes:

Size Estimate 179

Time Estimate 430

Range 147.37 Range 957.39 B0 179 B0 430.46 B1 -0.4 B1 -0.15 R^2 0.49 R^2 0.003

El metodo A resulta til con nuestros datos, esto debido a que contamos con suficientes LOC's de objeto estimadas y LOC's nuevas y modificadas, adems de que el valor de B1 es mu cercano a cero.

Anlisis de la exactitud de estimacin de tiempo

Analice la tendencia en la exactitud de estimacin de esfuerzo en los seis primeros programas.

Programa Total N & C Tiempo (min) Esfuerzo

# Estimad

o Real Estimado Real Estimado Real 1 260 146 360 396 1.38 2.71 2 200 65 370 351 1.85 5.40 3 100 41 330 374 3.30 9.12 4 78 84 532 352 6.82 4.19 5 63 113 359 320 5.70 2.83 6 64 136 354 543 5.53 3.99


70

Programa Exactitud

Correlacin

# (%) Val

Absoluto Abs

Promedio R^2 1 -48.95% 48.95% 48.95% 2 -65.74% 65.74% 57.35%

3 -63.82% 63.82% 59.51% 0.9622205

5 4 62.76% 62.76% 60.32% 5 101.23% 101.23% 68.50% 6 38.54% 38.54% 63.51% 0.0367148

La exactitud de la estimacin de esfuerzo en los primeros seis programas no ha mejorado mucho, pero en el programa seis se puede apreciar un aumento en la exactitud, la estimacin del programa seis es el mejor hasta ahora, lo cual puede indicar una mejora en la exactitud a partir de este programa.

Para los primeros seis programas, qu tan estable fue su productividad?

-80.00%-60.00%-40.00%-20.00%

0.00%20.00%40.00%60.00%80.00%

100.00%120.00%

1 2 3 4 5 6Exac

titu

d (%

)

Programa#

Tendencia de exactitud de esfuerzo


71

Programa Total N & C Tiempo (min) Productividad LOC's/he

# Estimad

o Real Estimado Real Estimado Real 1 260 146 360 396 43.33 22.12 2 200 65 370 351 32.43 11.11 3 100 41 330 374 18.18 6.58 4 78 84 532 352 8.80 14.32 5 63 113 359 320 10.53 21.19 6 64 136 354 543 10.85 15.03

Productividad(LOC/Hr)

Media Desviacin

15.06 5.9245947

9

La productividad media que se tuvo durante los primeros seis programas fue de 15.06 LOC/hr, as mismo la desviacin de la productividad fue de 5.92, indicando una inestabilidad a travs de los seis programas.

Para los primeros seis programas, si la productividad vari, los cambios estn relacionados con la cantidad de tiempo utilizando en corregir los defectos en las fases de

0.00

5.00

10.00

15.00

20.00

25.00

1 2 3 4 5 6

Prod

ucti

vida

d

Programa#

Productividad Real


72

compilacin y pruebas?

Si, la variacin en la productividad se ve fuertemente afectada principalmente por el tiempo invertido en corregir los defectos que son encontrados en la fase de pruebas, ya que estos consumen mucho tiempo.

Cmo fue afectada la exactitud de sus estimados de tiempo por la calidad de sus estimados de tamao?

Tendencia de Exactitud (%)

Tamao Tiempo 78.08% -9.09%

207.69% 5.41% 20.48% -11.76%

-13.45% 51.14% -44.25% 12.1

Reporte del Proyecto de Investigación148.206.53.84/tesiuami/UAMI15666.pdf · trabajo, y...

Documents

Transcript of Reporte del Proyecto de Investigación148.206.53.84/tesiuami/UAMI15666.pdf · trabajo, y...