UAMI11541

Reporte de Proyecto final de Investigacin II Desarrollo de un Sistema utilizando el proceso TSP
Elaborado por: Hernndez Garca Adriana 200217146 Lara Soto Enrique 200215479 Larios Vargas Rigoberto 200220868 Silva Molina Elvia Ivonne 97218685
Asesor: Ing. Luis Fernando Castro Careaga
Mxico D.F., Octubre de 2004
ATAIR
DEVPROT
Tabla de Contenido
1. Introduccin... 2. Descripcin del Proceso del Desarrollo 2.1 Qu es TSP?........................................................................................ 2.2 Principios del TSP 2.3 Enfoque de TSP. 2.4 Creacin de equipos.. 2.5 Elementos del TSP 2.7 Lanzamiento de TSP.. 2.8 Proceso de lanzamiento en TSP 2.9 Roles en el equipo. 3. Descripcin del Problema.. 3.1 Descripcin de Login 3.2 Descripcin de Registro de Procesos... 3.3 Descripcin de Registro de Proyecto / Tarea... 3.4 Descripcin de Registro de Usuarios... 3.5 Descripcin de la Plantilla Size Estimate. 3.6 Descripcin de Bitcora de Tiempo.. 3.7 Descripcin de Bitcora de Defectos y Catlogo de Defectos. 3.8 Descripcin de Registro de Estimados. 3.9 Descripcin de Probe 4. Alcance del Proyecto.. 5. Productos de Desarrollo................ 6. Propuesta de Mejora de Proceso.. 7. Conclusiones y Lecciones Aprendidas.. 7.1 Conclusiones. 7.2 Lecciones Aprendidas... 8. Bibliografa. 9. Anexos. 9.1 Anexo A. Documentacin General del Sistema... 9.1.1 Diagrama de Navegacin de Pantallas del Sistema 9.1.2 Diagrama de Modelo de Datos General.. 9.1.3 Interfaz en Java del Men Principal 9.1.4 Plan de Pruebas de Integracin... 9.1.5 Plan de Pruebas de Sistema. 9.12 Anexo B. Lista de Comprobacin para la Revisin de Diseo.. 9.13 Anexo C. Lista de comprobacin para la Revisin de Cdigo de Jbuilder Enterprise . 9.14 Anexo D. Estandar de anlisis y diseo 9.15 Anexo E. Propuestas de Mejora del proceso (PIP).. 9.16 Anexo F. Minutas .. 9.17 Anexo G. Postmortem del reporte. 9.18 Anexo H. Descripcin del Disco Compacto adjunto...... 2 3 3 3 4 4 4 4 5 5 7 8 8 8 9 9 11 12 12 13 15 17 20 21 21 28 29 30 30 30 31 32 33 36 37 39 41 42 48 58 63
1
UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA
ATAIR
DEVPROT
Introduccin
Una de las cosas ms difciles que se le pueden pedir a una persona es que estime el tiempo que emplear para concluir una tarea, y tal dificultad existe debido a que tiene que predecir el futuro, tiene que anticiparse a los imprevistos, a las complicaciones. Normalmente nos basamos en los fallos y los aciertos de otras veces que hemos tenido que estimar cosas similares, es decir, en las experiencias pasadas. Si lo que se hace es planificar todo un proyecto, la cosa se complica, an peor, es imposible acertar dependencias entre tareas, varios programadores, vacaciones por el medio, etc. Gran parte de los proyectos que se realizan se llevan a cabo sin utilizar un proceso adecuado, el cual les permita llevar un control sobre el sistema a desarrollar, es decir, un control en calidad, riesgos que ste conlleve, tiempo dedicado al desarrollo y recursos disponibles. En base a estas premisas, el presente proyecto est enfocado a seguir el proceso conocido como TSP (Team Software Process) el cual ayuda a los ingenieros, equipos y administradores de desarrollo de software al empleo consistente del PSP, es decir, los gua en el desarrollo de grandes productos de software, ya que los ingenieros deben ser capaces de trabajar juntos de manera efectiva en un ambiente de equipo y saber cmo producir consistentemente productos de calidad. Para el seguimiento de este proceso los integrantes del equipo debieron estar capacitados en el PSP (Personal Software Process); el cual es un proceso definido para ayudar al desarrollador a realizar mejor su trabajo; su principal objetivo es obtener y reportar datos exactos y completos del mismo. El proyecto se enfoc a desarrollar un sistema que lleve el registro de las diferentes etapas que deben seguirse en la creacin de proyectos, las cuales son definidas por el PSP. Dicho sistema se bas en la herramienta Process Dashboard, la cual es una aplicacin que se utiliza para registrar las diferentes etapas que especifica dicho proceso.
ATAIR
DEVPROT
Descripcin del Proceso de Desarrollo

El Proceso de Software en Equipo (TSP) fue desarrollado por el Instituto de Ingeniera en Software (SEI), de la Universidad Carnegie Mellon (CMU). El SEI busca promover la evolucin de los mtodos de Ingeniera del Software dentro de la prctica general, para ello necesita de los resultados y datos que se obtendrn de los miembros del equipo para compararlos con los de otros y as: Promover el TSP. Analizar la conducta de la Ingeniera del Software(IS). Avanzar en la prctica de la IS.
Qu es TSP? Es un proceso que sirve para construir y guiar equipos interdisciplinarios. Proporciona: Un proceso definido para construir el equipo de desarrollo. Un marco para el trabajo en equipo. Un ambiente de gestin para soportarlo.
Diseado para equipos de desarrollo y mantenimiento de entre 2 a 20 ingenieros. Incluye: Un proceso completamente definido para el trabajo en equipo. Roles definidos para los miembros del equipo. Un proceso estructurado para el lanzamiento y seguimiento. Una herramienta para soportar el trabajo del equipo y del ingeniero.
Principios del TSP Cuando los ingenieros planifican su propio trabajo, estn comprometidos con el plan. Seguimiento preciso de los planes requiere planes detallados y datos ajustados. Para minimizar el tiempo de realizacin los ingenieros deben balancear su carga de trabajo. Para maximizar la productividad, enfocarse primero en la calidad.
3
ATAIR
DEVPROT
Enfoque de TSP Planificar el trabajo antes de comprometerse y/o comenzar el trabajo. Usar un proceso definido. Medir y seguir el tiempo de desarrollo, tamao y defectos. Planificar, medir y seguir la calidad del producto. Poner nfasis en la calidad desde el comienzo del trabajo. Analizar cada tarea y utilizar los resultados para mejorar el proceso.
Creacin de equipos Para ser efectivos los equipos deben comenzar por: Definir sus objetivos. Establecer roles en el equipo. Definir una estrategia de desarrollo. Definir el proceso. Producir un plan general de desarrollo. Detallar los planes para cada ingeniero. Hacer anlisis de riesgos. Acordar mecanismos de comunicaciones y de informacin.
Elementos del TSP Preparacin: ingenieros se entrenan en PSP y TSP. Lanzamiento (y re-lanzamiento) del equipo: en puntos principales del proyecto el equipo reevala y replanifica el proyecto. Gestin y seguimiento del proyecto: el coach sigue el trabajo y controla el proceso.
Lanzamiento de TSP El estndar del lanzamiento del trabajo de TSP toma cuatro das: Da 1: cubre el manejo, roles y metas del equipo. Da 2: cubre las estrategias y planeacin del proyecto. Da 3: cubre los riesgos y la preparacin del reporte final. Da 4: cubre la revisin del manejo y del plan del equipo.
4
ATAIR
DEVPROT
Proceso de lanzamiento en TSP Reuniones 1 y 2: Gerente/Cliente: definen objetivos del proyecto, responden preguntas del equipo. Equipo: Establece roles, define objetivos del equipo. Reuniones 3, 4 y 5: Equipo: define estrategia y proceso para el proyecto, genera planes de calidad y de soporte, desarrolla un plan general de desarrollo. Reunin 6: Equipo: realiza planes detallados para la prxima fase y equilibra los planes personales de los ingenieros. Reunin 7: Equipo: realiza una evaluacin de riesgos del proyecto, asigna riesgos a los ingenieros para su seguimiento. Reuniones 8 y 9: Equipo: revisa el trabajo completado del lanzamiento, prepara presentacin a los gerentes, realiza postmortem del lanzamiento. Reunin 10: Equipo: presenta y defiende el plan. Gerente/Cliente: Revisa el plan del equipo, resuelven problemas del plan con el equipo.
Roles en el equipo: Los roles distribuyen la tarea entre los ingenieros. Estos roles definen las responsabilidades para gestionar el entorno de trabajo. Los miembros eligen sus roles durante el lanzamiento del equipo. Los roles estndar cubren: Planificacin Proceso Calidad Soporte Interfaz con el usuario Diseo Implementacin Prueba Roles: Interfaz con el cliente. Establece los requerimientos estndar.
ATAIR
DEVPROT
Controla que se implementen los requerimientos. Gua al equipo en la definicin de las necesidades del cliente. Administrador del diseo. Gua al equipo en el desarrollo del producto. Establece los estndares de diseo. Monitorea los puntos de diseo lanzados en el proyecto. Mantiene el control del diseo. Administrador de la implementacin. Desarrolla y mantiene los estndares de implementacin. Establece y mantiene el control sobre el producto implementado. Administrador de planeacin. Gua al equipo produciendo, asesorando, actualizando y reportando lo planeado. Consolida los planes individuales dentro del plan de equipo. Administrador del proceso. Gua al equipo en definir los procesos, prcticas y procedimientos. Asegura que el equipo registre todos los datos requeridos. Maneja las PIP del equipo. Administrador de calidad. Gua al equipo en establecer las metas y estndares de calidad. Asesora en forma individual y de equipo los datos de calidad. Identifica y ayuda a resolver los datos de calidad. Administrador de soporte. Determina las necesidades de soporte del equipo. Obtiene el soporte necesario. Proporciona la configuracin de la administracin del soporte. Administrador de pruebas. Gua al equipo en la planeacin de pruebas. Da soporte al equipo durante el proceso de pruebas. Asegura que cada punto a probar sea considerado en cada fase de desarrollo. Produce y mantiene el mapeo de defectos del sistema. Lder del equipo. Gua al equipo. Mantiene la disciplina del proceso. Maneja el proyecto. Da soporte al equipo en el manejo del proyecto.
ATAIR
DEVPROT
Descripcin del Problema.

El proyecto desarrollado bajo el proceso de TSP que los alumnos realizaron, consiste en disear e implementar una herramienta para el seguimiento de procesos, basndose en el PSP. Los requerimientos funcionales para este sistema son: Los procesos deben poder configurarse con sus fases. Debe poder definirse proyectos. Debe poder incluirse desarrolladores. Debe manejar Bitcora de Tiempo. Debe manejar Bitcora de Defectos. Debe llevar el Size Estimating Template. Permitir hacer Registro de Estimados. Incluir plantilla Summary en los distintos procesos definidos en el PSP (slo para consulta). Debe utilizar el mtodo PROBE. Debe incluir Registro de Tareas y calendario. Debe incluir todos los Scripts del Proceso. Incluir opcionalmente un contador de lneas (estndar de codificacin y estndar de conteo).
Los requerimientos no funcionales son: La interfaz debe ocupar un espacio mnimo en el escritorio. Debe ser multiusuario y/o permitir integracin. Debe permitir registro en lnea o registro fuera de lnea. Debe ser multilenguaje teniendo la primera versin en espaol. La instalacin debe ser lo ms simple posible. Los tiempos de respuesta deben ser instantneos (programa interactivo).
Las interfaces que componen al sistema DEVPROT se enlistan a continuacin: Men: interfaz que contiene todas las opciones para el seguimiento de un proceso. Log-in: el usuario solo podr usar la herramienta si est registrado (esta interfaz tendr la opcin de dar de alta a un usuario). Altas de usuario: el usuario se registrar en el sistema. Altas de Proyectos: el usuario da de alta el (los) proyecto(s) que desee. Altas Tareas: el usuario registrar las tareas correspondientes al proyecto seleccionado. Altas Proceso: el usuario da de alta el proceso que desee. Bitcora de Tiempo: interfaz en la cual el usuario podr registrar el tiempo que se lleve al realizar alguna fase de su proceso, o cualquier tiempo que desee.
ATAIR
DEVPROT
Bitcora de Defectos: El usuario registra los errores que haya encontrado en alguna de las fases que lleve a cabo. Size Estimate Template: plantilla en la cual el usuario puede hacer sus estimados de tiempo y tamao. PROBE: plantilla de consulta de clculo de tiempo y tamao para el usuario segn sus datos histricos.
Dicha herramienta esta basada en el Process Dashboard, pero no est dirigida a seguir exclusivamente el PSP. A continuacin se describe el funcionamiento de los mdulos que estn implicados en el Sistema:
Descripcin de Login. Mdulo para dar acceso al sistema. Interfaz sencilla que debe validar a un usuario verificando la existencia de ste en la Base de Datos, para que comience a utilizar la aplicacin DevProT.
Descripcin de Registro de Procesos. Este mdulo se encarga de dar de alta procesos. Cada proceso necesita un nombre, una descripcin y fases asociadas al proceso. El alta de procesos slo es para aquellos que sean genricos, es decir, procesos que se adecuen a las necesidades actuales del usuario y que no tengan completamente las fases de PSP. Estos procesos tienen por default las fases de Planeacin y Postmortem, y entre estas dos el usuario puede poner cualquier fase que desee. Tambin se permite eliminar procesos genricos, que no estn siendo usados por algn usuario. Interacta con el mdulo de tareas, pues cuando se crea una nueva tarea en un proyecto, sta tiene que tener asociado un proceso, y para asociarlo muestra los procesos que estn en la base de datos actualmente.
Descripcin de Registro de Proyecto / Tarea. Una vez dentro de la aplicacin DevProT, el usuario puede iniciar el proceso de PSP, esto es, dando de alta una nueva tarea, la cual debe estar contenida en un proyecto.
ATAIR
DEVPROT
Dicha tarea utilizar un proceso PSP 0,PSP 1 , PSP 1.1 , etc. (los definidos en PSP u otros definidos por el usuario). Esta interfaz muestra un desglose de los proyectos y tareas del usuario en un rbol de jerarquas. As, el usuario organiza las jerarquas a su conveniencia.
Figura: Desglose de jerarquas
Descripcin de Registro de Usuarios. Mdulo que permite dar de alta nuevos usuarios. Ya que en DevProT no existe el usuario administrador o root, cualquier usuario nuevo puede darse de alta, esto con la finalidad de hacer crecer la aplicacin a una herramienta capaz de utilizar TSP. Este mdulo de Registro de Usuarios se accesa desde la pantalla de Login, la interfaz muestra una tabla que contiene los usuarios registrados (slo login y nombre), con la finalidad de que el usuario pueda seleccionar un login vlido; aun as, en caso de que se repitiera un login, el sistema manda un mensaje de error de redundancia.
Descripcin de Plantilla Size Estimate. Esta plantilla se utiliza para guiar el proceso de estimacin de tamao y para registrar los datos de la estimacin. En ella se registrarn las Locs totales estimadas que comprendan el programa a realizar, adems de las Locs Actuales cuando el programa est completo, y as, el desarrollador podr ver cunta desviacin tuvo su estimacin con respecto a los valores reales. La plantilla esta compuesta de 4 apartados, los cuales se explican a continuacin:
9
ATAIR
DEVPROT LOCs Base del programa: Si el desarrollo del programa que se va a realizar es una modificacin o mejora de un programa existente, se registrarn las Locs del programa a modificar, las Locs estimadas a ser eliminadas, y las Locs a ser agregadas. LOCs de Objeto-adiciones a la base: Si se planea agregar Locs al programa base, estas se registrarn en este apartado con el nombre del objeto, tipo del objeto (L Lgica, I E/S, C Clculo, T Texto, D Datos, S Arranque), nmero de mtodos que lo componen , tamao relativo de los mtodos (VS muy pequeo, S pequeo, M mediano, L grande, VL muy grande), adems de las Locs estimadas para el objeto y las Locs actuales del objeto. Locs de Objeto-objetos nuevos: El registro de estas Locs es parecido al de las Locs de Objeto- adiciones a la base, con la diferencia que stos son objetos que aaden comportamiento nuevo al programa a modificar o extender (eso si hay programa base), de lo contrario, son las Locs que se planean escribir para obtener la funcionalidad deseada del programa. Locs de Objetos reutilizados: En este apartado se registran todos los objetos reutilizados que no se le realizarn cambios durante el desarrollo del programa. Si a estos objetos se le planea realizar cambios, entonces se tienen que registrar como Locs de Programa Base. Clculos: Antes de mandar a llamar al mtodo de estimacin PROBE, este apartado tendr la suma total de las Locs planeadas que tendr nuestro programa sin contar las Locs de objetos reutilizados. Despus de regresar del mtodo PROBE, los campos siguientes se actualizarn con los clculos realizados por este mtodo: Parmetros de regresin B0 y B1 para tamao y tiempo LOC Nuevas y Modificadas Estimadas (N) LOC Totales Estimadas (T): Total de Nuevas Reutilizadas (suma de LOC *): Tiempo de Desarrollo Total Estimado Rango de Prediccin: Intervalo de Prediccin Superior e Inferior Porcentaje de Intervalo de Prediccin Mtodos utilizados para la prediccin de tamao y tiempo.
Esta plantilla es de suma importancia para el manejo del sistema, ya que en ella se plasma lo que el desarrollador va a realizar, adems de los parmetros de estimacin.
10
ATAIR
DEVPROT Descripcin de Bitcora de Tiempo. La Bitcora de Tiempo es una plantilla para facilitar el trabajo al usuario, ya que en vez de registrar y calcular el tiempo que tarda en elaborar una tarea, la bitcora lo hace automticamente con hacer click en dos botones, el de Inicio y el de Fin. Al seleccionar la Bitcora de Tiempo del Men, se despliega la pantalla correspondiente, la cual est dividida en dos secciones. La seccin izquierda contiene una tabla que despliega los proyectos que el usuario ha registrado con sus correspondientes tareas y procesos, los cuales, al seleccionarse, despliegan en la seccin derecha de la pantalla los registros introducidos por el usuario, correspondientes a la seleccin (que puede ser proyecto, proceso o tarea). Si el usuario desea introducir un nuevo registro nicamente necesita oprimir el botn Agregar para que el sistema introduzca la fecha y hora de inicio (del sistema), as como el proyecto, y/o proceso, y/o tarea previamente seleccionados. Con esto, el usuario puede continuar con sus tareas hasta que desee parar el tiempo, slo tiene que oprimir el botn Parar y el sistema automticamente calcula e imprime en el lugar correspondiente la hora de terminacin y el tiempo en minutos (DELTA) que se tard el usuario. Al usuario slo le resta poner comentarios (si lo desea), para terminar y oprimir el botn Guardar para que se guarden los registros. Los botones que contiene la bitcora son: Agregar: ya explicado anteriormente. Parar: ya se explic. Eliminar: borra un registro de la Base de Datos. Guardar: al oprimir el botn manda mensaje de confirmacin y dependiendo de la eleccin guarda los datos o los deja igual. Cerrar: cierra la ventana de Bitcora de Tiempo y regresa a la pantalla de Men. Calendario: muestra el tiempo invertido en el mes y ao (previamente seleccionados). <<: decrementa fechas (en el filtro). >>: incrementa fechas (en el filtro).
El botn calendario muestra, segn el mes y ao seleccionados, los tiempos (totales) que el usuario introdujo. Dicho tiempo aparece en formato de minutos pero se puede cambiar a formato de horas. Tambin contiene un combobox en el cual se despliegan tres datos: Hoy, Mes, Semana; al seleccionar cualquiera de los tres se desplegarn los registros correspondientes a la seleccin, esta seleccin corresponde a fechas que tambin se despliegan al lado del combo que indica el intervalo del da, semana o mes. Estas fechas se pueden incrementar o decrementar con los botones >> (incrementa) o << (decrementa).
11
ATAIR
DEVPROT Descripcin de Bitcora de Defectos y Catlogo de Defectos En la Bitcora de Defectos se llevar un registro de los defectos que el desarrollador tenga en sus distintas tareas de PSP, esto es el objetivo general de la Bitcora. La Bitcora de Defectos va a ser llamada por el mdulo Men. De manera ms detallada, la Bitcora de Defecto tiene una pestaa con el nombre Opciones, en la cual a la hora de hacer click, se despliega un pequeo men, el cual contiene les siguientes opciones: Catlogo de Defectos, Agregar Rengln y Borrar Rengln. Con la opcin Catlogo de Defectos, al dar click enva a la interfaz Catlogo de Defectos; al escoger la opcin Agregar Rengln, se tiene que haber hecho la seleccin del ltimo rengln de tabla que se muestra en la interfaz de la Bitcora de Defectos, si no se encuentra seleccionado se mostrar un panel de error; cuando se escoge la opcin Borrar Rengln se tuvo que haber hecho antes la seleccin del rengln que se desea borrar. La interfaz Bitcora de Defectos tambin tiene un combo donde se muestran los tipos de consultas que se pueden hacer. En el campo Consulta se especifica lo que se est consultando, lo cual se ejecuta cuando el desarrollador oprime el botn Aceptar. Cuando el desarrollador termina de introducir datos nuevos a la tabla tiene que oprimir el botn Salvar para que sus datos nuevos sean guardados en la Base de Datos. Los datos que aparecen en la tabla son clave del proyecto, clave de tarea, clave del proceso, tipo de defecto, fase de introduccin, fase de eliminacin, fecha, tiempo de correccin, referencia, descripcin del defecto. La interfaz de la Bitcora tambin tiene un botn Salir el cual hace que se regrese a la interfaz del Men. En el Catlogo de Defectos se encuentra una clasificacin de los defectos, los cuales aparecen en las tareas de PSP. Cada desarrollador puede editar su propio Catlogo de Defectos, segn lo que piense que debera contener. Cuando los cambios del Catlogo de Defectos estn hechos, el desarrollador tiene que oprimir el botn Salvar. Los datos que se capturan en la tabla del Catlogo de Defectos son: Tipo del Defecto y la Descripcin del Defecto (la clave del tipo del defecto no es editable, es aumentado automticamente). Esta interfaz tambin tiene un botn Salir para regresar a la interfaz Bitcora de Defectos.
Descripcin de Registro de Estimados. El mdulo de Registros de Estimados es un formulario que permite a los desarrolladores registrar sus estimados de diferentes mtricas como son el tiempo planeado, nmero de Locs, defectos a introducir y eliminar en cada fase, adems del registro de los valores reales de tales mtricas obtenidos durante el desarrollo de las tareas. Para poder acceder a este mdulo, es necesario visitar los scripts de los diferentes procesos del PSP (esta restriccin debido a que esta plantilla es exclusiva para los
12
ATAIR
DEVPROT diferentes procesos que conforman el PSP), dentro de ellos se encuentran los vnculos para acceder a los formularios de registro. Dependiendo de la fase en la que se encuentre el desarrollador, y del proceso utilizado para realizar la tarea, se desplegar una interfaz mostrando los datos requeridos por el proceso para realizar el registro. La fase determina si los campos a editar sern de datos planeados o de valores reales. El proceso define qu tipo de valores se solicitarn al desarrollador para llevar a cabo el almacenamiento de informacin. En forma general, la interfaz contendr los campos a editar y dos botones que realizan las siguientes funciones: Guardar: Almacena los datos capturados en la base de datos. Borrar: En caso de que haya habido algn error en la captura de los datos, y se desee limpiar todos los campos de captura, este botn limpiar el formulario de forma total para iniciar nuevamente con un formulario en blanco.
Dentro de esta interfaz no se cuenta con algn botn para cerrar la ventana, ya que los requerimientos establecen que es necesario que se pueda mandar a impresin la informacin de este mdulo, por lo que la interfaz se desarrollar en lenguaje HTML, pudiendo ser abierta en un programa explorador que cuente con una barra de herramientas estndar adems de sus respectivos botones para cerrar, maximizar y minimizar la ventana. Cuando se ha oprimido el botn Guardar, y los datos se han registrado en la base de datos, se despliega otra ventana informativa que contiene datos generales de la tarea, as como los datos almacenados por el programa.
Descripcin de Probe. Este mdulo se encarga de implementar la estimacin de tamao y tiempo por medio del mtodo PROBE. Este mtodo se basa en la utilizacin de datos histricos, regresin lineal y los intervalos de prediccin para producir un estimado de precisin conocida. La regresin proporciona el mejor ajuste, o varianza mnima de una lnea para estos datos. La varianza de los datos se utiliza para determinar el intervalo de prediccin. Para hacer uso del mdulo PROBE, es necesario que se cuente con una serie de datos histricos en cuanto a Locs nuevas y modificadas reales, Locs nuevas y modificadas planeadas y los tiempos reales. Tambin se necesita la utilizacin de la hoja de estimacin de tamao Size Estimating Template, ya que esta hoja proporciona datos importantes para dicha estimacin. Adems, el mdulo PROBE es invocado a travs de dicha hoja.
13
ATAIR
DEVPROT
Con PROBE, los estimados estn basados en uno de los tres mtodos:
Mtodo A B C
Descripcin Regresin con los LOC de objeto estimadas Regresin con LOC nuevas y modificadas estimadas El mtodo de promedio
Para utilizar cualquier mtodo de regresin, se necesitar: Una cantidad razonable de datos histricos. Datos que correlacionen. Parmetros razonables. El Mtodo A utiliza la relacin entre los LOC de objeto estimado y LOC nuevas y modificadas reales. Tiempo de desarrollo real. El criterio para utilizar este mtodo es: Ms de tres puntos que estn correlacionados (R2 > 0.5) Parmetros de regresin razonables. El mtodo B utiliza la relacin entre LOC nuevas y modificadas estimadas y LOC nuevas y modificadas reales. Tiempo de desarrollo real. Los criterios para utilizar este mtodo son: Ms de 3 puntos que estn correlacionados (R2 > 0.5) Parmetros de regresin aceptables. El mtodo C utiliza una razn para ajustar el tamao o el tiempo basado en promedios histricos. El mtodo de promedios es fcil de utilizar y requiere slo un punto de informacin.
14
ATAIR
DEVPROT
Alcance del Proyecto

La estrategia utilizada consisti en dividir el proyecto en 6 ciclos de trabajo, en los cuales habr distintos entregables. Estos ciclos fueron organizados de acuerdo a la complejidad de los mdulos, de tal manera que los desarrolladores de los primeros ciclos apoyaran a los desarrolladores que se encontraban trabajando en los ltimos ciclos al trmino de su trabajo. Se contempl que el sistema debera tener los siguientes mdulos y se entregaran en los ciclos que a continuacin se describen: ciclo1 fecha de inicio: 24/05/04 fecha de finalizacin: 04/06/04 Puntos a cubrir: formas MGMT, forma STRAT, planeacin general del sistema, requerimientos del sistema, plan de pruebas del sistema e Inspeccin de requerimientos. ciclo2 fecha de inicio: 07/06/04 fecha de finalizacin: 18/06/04 Puntos a cubrir: HLD de todos los integrantes del equipo, los alumnos tuvieron que desarrollar su plan de pruebas en forma individual; la integracin del plan de pruebas, Inspeccin del HLD de cada desarrollador. ciclo3 fecha de inicio: 21/06/04 fecha de finalizacin: 09/07/04 Puntos a cubrir: mdulo Log-in, Registro de Procesos, registro de Jerarqua, Registro de Usuarios y Registro de Tareas. ciclo4 fecha de inicio: 12/07/04 fecha de finalizacin: 30/06/04 Puntos a cubrir: mitad de la Plantilla de Size Estimate, Bitcora de Tiempos, Bitcora de Defectos, mitad del Registro de Estimados. ciclo5 fecha de inicio: 02/08/04 fecha de finalizacin: 20/08/04 Puntos a cubrir: culminacin de la plantilla de Size Estimate y Registro de Estimados, PROBE. ciclo6 fecha de inicio: 23/08/04
15
ATAIR
DEVPROT fecha de finalizacin: 10/09/04 Puntos a cubrir: Plan de proyecto.
Dentro del alcance del proyecto no se contemplaron los siguientes puntos: Ser multilenguaje. Contador de lneas. Registro en lnea.
16
ATAIR
DEVPROT
Productos de desarrollo.
Los productos de desarrollo ms relevantes fueron: Minutas: las cuales contienen los acuerdos ms relevantes en las juntas realizadas, el rol de cada integrante del equipo que particip en la junta, el tiempo de cada punto a tratar dentro de las mismas, adems de las decisiones y/o acciones que se realizaran posteriormente. Anlisis de requerimientos: se inicia a partir de la especificacin de los objetivos de la informacin establecida por cada una de las partes que forman la organizacin y que intervendrn en la aplicacin. Este punto consta de: creacin y descripcin de Casos de Uso, Diagramas de Navegacin de Pantallas, modelo de interfaz, modelo de datos.
El modelado de Casos de Uso es la tcnica ms efectiva y a la vez la ms simple para modelar los requisitos del sistema desde la perspectiva del usuario. El modelo de Casos de Uso consiste en actores y descripcin de Casos de Uso. Los actores representan usuarios y otros sistemas que interactan con el sistema. Se dibujan como "muecos de alambre. Actualmente representan el tipo de usuario, no una instancia de usuario. Los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estmulo desde un actor. Un diagrama de estado se modela para todas las clases que se consideran con un comportamiento dinmico. En l, se modela la secuencia de estado que un objeto de la clase atraviesa durante su vida en respuesta a los estmulos recibidos, junto con sus propias respuestas y acciones. Muchas veces los requisitos del sistema ya existen en forma de documentos de requisitos. Los casos de uso se utilizan para correlacionar cada escenario con los requisitos que completa. Si los requisitos no existen, modelar el sistema a travs de los Casos de Uso permite el descubrimiento de estos requisitos. Dentro de la plantilla de Casos de Uso se describe en forma general lo siguiente:

cul es el fin de la operacin, cules son las condiciones que habilitan una operacin, cmo se desarrolla la operacin, si las operaciones se comportan en forma regular, y si no, cules son las condiciones.
17
ATAIR
DEVPROT
Diseo de Alto Nivel: en esta fase de diseo se incluyen los siguientes diagramas: diagramas de secuencia, diagramas de clases dinmicas, diagramas de componentes.
El Diagrama de Secuencia es uno de los diagramas ms efectivos para modelar interaccin entre objetos en un sistema. Se modela un Diagrama de Secuencia para cada Caso de Uso y contiene detalles de implementacin del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. Los objetos encontrados durante el anlisis son modelados en trminos de la clase a la que instancan, y las interacciones entre objetos son referenciados a relaciones entre las clases instanciadas. Un componente es un grupo de objetos o componentes ms pequeos que interaccionan entre ellos y se combinan para dar un servicio. Un componente es similar a una caja negra, en la cual los servicios del componente se especifican por su interfase o interfaces, sin ofrecer conocimiento del diseo e implementacin internas del componente. Diseo de Bajo Nivel: los productos generados en este punto son: plantilla lgica, plantilla de estados. En la plantilla lgica se realiz el pseudocdigo; dentro de la plantilla de estados se especifican las interacciones entre los distintos mdulos. Pruebas: se dividen en tres grandes grupos: unitarias, de integracin y aceptacin. Pruebas Unitarias: stas no verifican que el cdigo funciona sino que indican hasta que punto se puede incrementar funcionalidad sin perder lo ya conseguido. Es decir, son un estimador de la calidad. Pruebas de integracin: se verifica que la clase interacta como se esperaba con otras clases y componentes relacionados. Pruebas de aceptacin: la empresa realiza las pruebas con el cliente y la presencia del jefe de proyecto. De esta forma se busca la conformidad de todas las partes involucradas con el producto realizado. Si el cliente aprueba el producto se les proporciona esa versin para su uso y la empresa va nuevamente a la etapa de iteracin para seguir con los requerimientos restantes. Si el cliente tiene algunas observaciones sobre el software la empresa regresa nuevamente a la fase de iteracin para revisar estas observaciones.
18
ATAIR
DEVPROT El cliente puede generar nuevos requerimientos que aadan funcionalidades nuevas al software.
19
ATAIR
DEVPROT
Propuesta de Mejora de Proceso.

Las propuestas de mejora que el equipo da a conocer en sus formas PIP son: El Coach se encuentre ms tiempo en las reuniones de lanzamiento del proyecto. El beneficio que esta sugerencia traera es que los integrantes del equipo no se desviarn del proceso que se est llevando, por consecuencia, las personas que conforman el equipo pondrn ms atencin en las reuniones, y as stas durarn el tiempo planeado de la junta. Los integrantes del equipo asistan continuamente a las juntas en los horarios establecidos. El beneficio de esta propuesta traer una mejor comunicacin y un ambiente ms amigable entre los integrantes del equipo. Con respecto al proyecto, habra un avance ms notable, adems de que el avance de cada uno de los integrantes ser de dominio de todo el equipo. Seguimiento de estndares de requerimientos. La mejora que sta traera es la uniformidad de la informacin que se entrega. Entrega de documentos en la fecha planeada. Con el seguimiento de esta propuesta el riesgo de atraso en el desarrollo del proyecto se minimiza y la probabilidad de la terminacin del proyecto en la fecha planeada se mantiene en un nivel alto. El tener algn tipo de imposicin, para cumplir con las horas planeadas, adems de tener una mejor organizacin y una mayor responsabilidad por cada integrante del equipo.
20
ATAIR
DEVPROT
Conclusiones y Lecciones aprendidas

Conclusiones.
La siguiente figura nos muestra que los valores reales del Valor Ganado siempre estuvieron por debajo de lo planeado. Como se puede observar, del periodo que abarca de la fecha 11/05/04 a la fecha 29/06/04 el Valor Ganado se mantuvo casi constante debido a que los desarrolladores tenan otras actividades por atender (es decir, asuntos externos al proyecto). Del periodo que inici en la fecha 29/06/04 al da 17/08/04 el Valor Ganado tuvo un crecimiento altamente notable ya que fue el periodo en el que los desarrolladores se encontraban con menos carga de trabajo (en cuanto a asuntos externos). El periodo final de trabajo que abarca de la fecha 17/08/04 a la fecha 12/10/04 se mantuvo casi constante ya que los integrantes del equipo regresaron a clases. Si se hubiera continuado con el proyecto, el valor ganado para el da 09/11/2004 hubiera sido 91.3 % del total del proyecto.
Cumulative Earned Value

100,0 90,0 80,0 70,0 Earned Value 60,0 50,0 40,0 30,0 20,0 10,0 0,0 11-05-04 25-05-04 08-06-04 22-06-04 06-07-04 20-07-04 03-08-04 17-08-04 31-08-04 14/09/2004 28/09/2004 12/10/2004 26/10/2004 09/11/2004 23/11/2004 Cumulative Planned Value Cumulative EV Cumulative Predicted Earned Value
Weeks
Analizando la siguiente grfica nos podemos percatar del por qu el Valor Ganado real siempre estuvo por debajo de lo planeado. Se muestra que una de las razones de sta tendencia fue que no se cumpli con las horas programadas para desarrollar en su totalidad el sistema. Analizando las horas dedicadas reales por equipo, se puede observar
21
ATAIR
DEVPROT que no se cumplieron con las horas asignadas por semana, esto por lo mencionado en la grfica anterior, de que los integrantes tenia asuntos externos al proyecto. Este retraso en el tiempo de dedicacin repercuti en las fechas programadas para el trmino de cada tarea, haciendo que hubiera un desplazamiento de estas, y por lo tanto, una fecha de culminacin de proyecto ms lejana. En conclusin, cuando se va a realizar un proyecto se le debe dedicar el tiempo planeado, logrando con sto menos consecuencias negativas al desarrollo del proyecto. Todo esto se puede cumplir siempre y cuando los integrantes del equipo sean disciplinados en relacin al papel que estn desempeando dentro del equipo de trabajo.
Cumulative Planned and Actual Hours per Week
2500,0
2000,0 Cummulative Hours
1500,0 Cumulative Planned Hours Cumulative Actual Hours 1000,0
500,0
0,0 11-05-04 25-05-04 08-06-04 22-06-04 06-07-04 20-07-04 03-08-04 17-08-04 31-08-04 14/09/2004 28/09/2004 12/10/2004 26/10/2004 09/11/2004 23/11/2004
Weeks
22
ATAIR
DEVPROT Dentro de la calendarizacin, se haba estimado que las horas a la semana que el equipo le tena que dedicar al desarrollo del sistema eran 116; debido a una mala administracin del tiempo, el trabajo del equipo siempre estuvo por debajo de lo planeado (en promedio, las horas trabajadas por semana estuvieron alrededor de 70). Una excepcin fue la semana 9 en la cual las horas dedicadas al proyecto superaron el nmero de horas planeadas por semana; en la semana 14 apenas se alcanz lo planeado. Esto refleja que slo el 15% del tiempo se dedic un tiempo real cercano al planeado.
Planned and Actual Hours per Week
140,0 120,0 100,0 80,0 60,0 40,0 20,0 0,0 11-05-04 25-05-04 08-06-04 22-06-04 06-07-04 20-07-04 03-08-04 17-08-04 31-08-04 14/09/2004 28/09/2004 12/10/2004 26/10/2004 09/11/2004 23/11/2004
Hours
Planned Hours Actual Hours
Weeks
23
ATAIR
DEVPROT Durante las primeras dos fases de eliminacin de defectos (inspeccin de requerimientos, inspeccin de HLD), tuvimos ms errores de los que se planearon; hago referencia a estas dos fases porque en estas fechas el equipo todava llevaba un ritmo de trabajo cercano a lo planeado, por lo que todos los integrantes se encontraban o estaban por llegar a la misma fase. En los periodos de eliminacin de errores restantes, el equipo tuvo menos defectos de los planeados, sto porque hubo integrantes del equipo que ya no llegaron a codificacin, y slo algunos terminaron los mdulos que les haba tocado, en consecuencia, ellos fueron los nicos en registrar los errores que tuvieron en las fases posteriores.
Cumulative Defects Removed by Phase for Assembly SYSTEM

600 500 400 300 200 100 0
Pl a eq nni ng Sy ui re st e m me n Te ts R EQ st P la H In ig n h- s p e Le In c ti o te v e gr n at l D es io n ig H Tes n LD t In Pla sp n D et ai ecti le on d D es D L ig Te D n st R De ev i ve ew l D LD opm e In s p nt ec tio n Co C od de Re e vi ew C od Co m e pi In Bu sp le ild ec an tio d In Uni n te t T gr at e st io n Sy Te ste st m Te st
Cumulative Defects Removed by Phase
Plan Actual
Phase
24
ATAIR
DEVPROT En la siguiente grfica se muestra los defectos que fueron eliminados por fase, en planeado y actual. Como se nota se eliminaron menos defectos reales con respecto a lo planeado, en las primeras cuatro fases se eliminaron ms defectos, ya que todo el equipo cumpli con llevarlas a cabo, en cambio, las fases restantes fueron en las que menos errores se corrigieron, porque slo los integrantes que lograrlon terminar sus mdulos realizaron eliminacin de defectos en ellas.
Defects Removed by Phase for Assembly SYSTEM

200,0 180,0 Defects Removed by Phase 160,0 140,0 120,0 100,0 80,0 60,0 40,0 20,0 0,0
In sp ec ti o H n LD In sp ec tio n D LD R ev ie D w LD In sp ec tio n Co m pi le C od e Te st Te st tio n Re vi ew In sp ec at io n U ni t Te st
Plan Actual
Co de
Co de
Phase
Bu ild
an d
In te gr
EQ
Sy ste m
25
ATAIR
DEVPROT En el siguiente grfico se muestran los defectos por KLOC de cada una de las fases de eliminacin. En las primeras tres fases fue donde se obtuvo la mayora de los errores por KLOC, las cuales fueron las que todo el equipo cumpli con hacerlas, en cambio en el resto slo algunos integrantes las llevarlas a cabo.
Defect Density by Phase for Assembly SYSTEM

18,00 16,00 14,00 Defects/KLOC 12,00 10,00 8,00 6,00 4,00 2,00 0,00
In sp ec tio n R ev ie w Te st Te st pi le tio n R ev ie w C om In sp ec at io n ni t Te st
Plan Actual
C od e
Phase
Bu ild
an d
In te gr
LD
od e
Sy ste m
D LD
26
ATAIR
DEVPROT Esta grfica muestra el rendimiento del equipo, es decir la cantidad de defectos eliminados antes de la primera compilacin de todo el sistema. Se observa que el rendimiento del equipo hasta la inspeccin del DLD, es bueno con respecto a lo planeado, de ah en adelante los rendimientos fueron bajos, en unos casos ni siquiera hay rendimiento, esto es porque todo el equipo trabajo hasta la inspeccin del DLD y solo algunos llegaron a lo que es pruebas unitarias; las fases posteriores ni siquiera se comenzaron.
Phase Yields for Assembly SYSTEM

100% 90% 80% 70% 60% Yield 50% 40% 30% 20% 10% 0%
Pl a eq nni ng u Sy i re st e m me nt s Te R EQ st P la H In n ig h- spe Le ct In io te ve n gr at l De io si n T e gn H LD s t Pl In a De s pe n ct ta io i le n d De DL sig D Te n R st De evie w ve l D LD opm e In s p nt ec tio n C C od od e e R ev ie w C C om od e pi In Bu sp le ild ec tio an n U d ni In tT te gr es at t io Sy n T e ste st Ac m ce Te pt an st ce Te st
Plan Actual
Phase
27
ATAIR
DEVPROT Lecciones aprendidas. Se requiere de una gran responsabilidad para seguir adecuadamente el proceso, ya que cada integrante del equipo tiene una responsabilidad muy especfica y si no se cumple, entonces el equipo se descontrola y se tiene que hacer un rebalance de trabajo. Para proyectos con un grupo de trabajo con ms de 10 personas, es muy difcil controlar al equipo y sobre todo que se pongan de acuerdo sus integrantes. Debido al desarrollo de este proyecto, los alumnos obtuvimos una visin de lo que ser trabajar fuera de las aulas de la Universidad y tener que enfrentarse con problemas en un grupo heterogneo. Con el seguimiento del PSP y TSP el tiempo de desarrollo se reduce enormemente ya que desde los inicios del proyecto los desarrolladores se sumergen en la problemtica del proyecto y como va avanzando su solucin, as se conoce ms del problema. Adems estos procesos dirigen al grupo y al desarrollador por fases bien especificas y que son de gran ayuda para la culminacin del proyecto. Es decir se tiene un mejor control sobre el Sistema a desarrollar y el equipo que lo desarrolla.
28
ATAIR
DEVPROT
Bibliografa.
The Addison-Wesley SEI Series in Software Engineering: A Discipline for Software Engineering: The Complete PSP Book Watts S. Humphrey. ISBN: 0-201-54610-8, 1995. Hardcover, 816 pages Discipline for Software Engineering, A By Watts S. Humphrey. Published by Addison Wesley Professional Series: The SEI Series in Software Engineering Daniel J. Paulish. Architecture-centric Software Project Management. Edit. Addison Wesley. 284 pp. Elaine M. may. Methods for software systems development. Edit. Addison Wesley, 1197, 374 pp.
29
Inicio
Click en boton aceptar en pantalla Login
Login
Login correcto?
Aceptar
Click en boton Aceptar en la pantalla Login
Salir
Cierre del men Seleccin de la pestaa Registro Salir Salir
Menu Principal
Salir Salir
Seleccion pestaa Bit . Defectos
Seleccion de pestaa Consultas Salir Seleccion de pestaa Scripts Sali r
Salir
Salir
Registro de Procesos Bitacora de Def ectos

Editar Catalogo Salir
Registro de Proyectos
Bitacora de Tiempo
Calendario Salir
Salir
Scripts
Consultas
Diagrama de Navegacin de Pantallas del Sistema..
DEVPROT
Seleccion del Script Planeacion Seleccion de Script de Planeacion Salir Agregar Fase
Registro de Fase
Catalgo de Defectos
Agregar Scipts
Calendario
Registro de Estimados
Size Estimating Template

PROBE WIZARD Salvar Cambios Salir
Project Plan Summay
Graficas
Salir
Project Plan Summary

Tal vez esta parte de las
Error
Aceptar
Graficas
Registro de Scripts
PROBE (PROxy Based Estimate)
Mensajes de Confirmacion
Error
Aceptar
Salir
Siguiente
Aceptar
Resultados de Estimacion de Tamao y Tiempo

Aceptar
Siguiente
Error
Despedida de Probe Errores
Aceptar
UNIDAD IZTAPALAPA
Seleccin de la pestaa Registro
Seleccion de Pestaa Bit . Tiempo
Salir
UNIVERSIDAD AUTONOMA METROPOLITANA
Documentacin General del Sistema
ATAIR
Anexo A
30
ATAIR
DEVPROT Diagrama de Modelo de Datos General.
BIT. T IEMPO 1.. * FASE 1

Cv eProc Cv eF ase Nomb Fa se DescFas e
SCRIPTS
Cv eSc ript Cv eFase Cv eProc Descrip
1 1 1
1..*
1..*
PROCESO Cv eProc NomProc DescProc
0..*
Cv eProy Cv eProg Cv eProc Cv eFase FechHoraInicio FechHoraFin Interrumpcion Delta Observ aciones Status
1
PROY ECTO Cv eProy NombProy
CATALOGO DEFECTOS
1..*
CveT ipoDef CveUsua DescDefecto 1
0..*
BIT. DEFECTOS Cv eProy Cv eProg Cv eProc FaseInt Cv eFase FechDef ec TiempoCorrec Ref Def Cv eTipoDef DescDef Status METRICAS x FASE
1 US UARIO
Cv eU su a No mb Usua PwdU su a Cv eL en g
PROGRAMA
1. .* 1 1 1 1 1 1..*
1..* 1 1..*
Cv eP ro y Cv eP ro g Cv eU su a Cv eP ro c De sc Prog
1 0..* 1..*
1 1
CATALOGO METRICAS
CveMetrica CveProy CveProg CveProc CveFase Plan Real Al aFecha StatPlan StatReal StatAlafech
CveMetrica Nom bCorto NombLargo Unidades Descripcion

1.. *
1..* 1..* METRICAS GRALES. CveMetrica CveProy CveProg Plan Real Al aFecha StatPlan StatReal StatAlaFech
1 1 T AL OGO S CA
Cv eCatalogo DescCatalogo
LO C MET H
Cv eUsua NumObj Cv eProy Cv eProg NombObj LocObj MetObj TipoObj
1..*
1 1
1..*
1..*
ENTRADAS CATALOGO
Cv eC atal ogo En tCat alogo De sc
1 ..*
OBJETOS PET Cv eProy Cv eProg Secc ionPET NombObj NumMetodos TipoObj LOCXMet LOCPlan LOCReal PlanNR RealNR
1..*
31
ATAIR
DEVPROT Interfaz en Java del Men Principal.
32
ATAIR
DEVPROT Plan de Pruebas de Integracin.
Mdulos LOG:BD
MP:LOG MP:BD
R_USR:LOG R_USR:BD
R_PRY:MP
R_PRY:BD
R_TSK:R_PRY
R_PRC:MP R_PRC:BD
Condiciones de prueba Pruebas de bsqueda Pruebas de coincidencia Pruebas de atributo Pruebas de bsqueda Pruebas de atributo Prueba de interfaz Pruebas de bsqueda Pruebas de registro o escritura Pruebas de atributo Prueba de interfaz Pruebas de bsqueda Pruebas de registro o escritura Pruebas de coincidencia Prueba de interfaz Prueba de atributos Prueba de registro o escritura Prueba de interfaz Prueba de consulta
Aprobado
No aprobado
Pendiente
33
ATAIR
DEVPROT Prueba de registro o escritura R_FSS:R_PROC Prueba de interfaz Prueba de atributos Prueba de R_FSS:BD registro o escritura Prueba de consulta Prueba de SCR:MP interfaz Prueba de atributos Prueba de archivos Prueba de B_TMP:MP interfaz Prueba de B_TMP:BD bsqueda Prueba de atributo Prueba de registro Prueba de B_DFC:MP atributos Prueba de interfaz Prueba de B_DFC:BD atributo Prueba de bsqueda Prueba de registro o escritura Prueba de R_STM:SCR interfaz Prueba de atributos Prueba de R_STM:BD bsqueda Prueba de
34
ATAIR
DEVPROT registro o escritura Prueba de bsqueda Prueba de atributos Prueba de interfaz Prueba de atributos Prueba de registro o escritura Prueba de atributos Pruebas de interfaz Pruebas de bsqueda Pruebas de atributo Prueba de interfaz Prueba de atributos Prueba de coincidencia Prueba de interfaz Prueba de coincidencia Prueba de atributos Prueba de bsqueda Prueba de atributo
PRB:BD PRB:SZS SZS:PRB
SZS:BD
SZS:SCR GRF:MP GRF:BD
SMR:MP
SMR:SCR
SMR:BD
35
ATAIR
DEVPROT Plan de Pruebas de Sistema.
Comunicacin entre Modulos
Registro de estimados
Registro de proyectos
Registro de procesos
Bitcora de defectos
Bitcora de tiempo
Registro de tareas
Registro de Usuarios
Registro de fases
Menu principal
Size Estimating
Graficas (*)
Modulos Login
Menu principal Registro de procesos Registro de proyectos Registro de tareas Registro de fases Scripts Bitcora de tiempo Bitcora de defectos Registro de estimados Summary Size Estimating PROBE Graficas (*)
Registro de Usuarios
Base de Datos
Summary
PROBE
Scripts
Login
36
ATAIR
DEVPROT
Anexo B Lista de Comprobacin para la Revisin del Diseo

NOMBRE Y NMERO DE PROGRAMA:_________________ Propsito Fecha: _________ Nombre de la unidad del programa
Guiarlo en la conduccin de una revisin de diseo efectiva Conforme usted termine cada paso de revisin, compruebe el elemento en la caja de la derecha. Termine la lista de comprobacin para una unidad del programa antes de comenzar la revisin de la siguiente. Asegrese que el diseo cubre completamente los requerimientos, especificaciones y diseo de alto nivel: Se generan todas las salidas especificadas. Se incluyen todas las entradas necesarias. Se establecen todos los includes requeridos. Se cubren todos los casos del problema. Compruebe que la secuencia del programa es la apropiada: q Las pilas, listas y otros estn en el orden apropiado. q La recursin regresa de manera apropiada. Verifique que todos los ciclos se inicializan, incrementan y terminan de manera apropiada, y que no hay ciclos infinitos. Verifique que no hay divisin entre cero Verifique que las variables pertenecen al tipo correcto y que se inicializan correctamente Compruebe todos los casos especiales: Asegure la operacin apropiada para todas las variables con valores vaco, lleno, completo, mnimo, mximo, negativo, cero. Proteccin por condiciones fuera de los lmites, sobreflujo o bajoflujo. Asegrese que las condiciones imposibles sean absolutamente imposibles. Maneje todas las condiciones de entradas incorrectas. Verifique que todas las funciones, procedimientos u objetos estn completamente comprendidos, se usan de manera apropiada Verifique que todas las abstracciones externas referenciadas estn definidas de manera precisa.
General
Completo
Lgica
Casos Especiales
Uso Funcional
37
ATAIR
DEVPROT
Evitar el uso de variables globales (lo mas que se pueda) Nombres Verifique lo siguiente: Todos los nombres y tipos especiales estn clara y especficamente definidos. Los alcances de todas las variables y parmetros son evidentes o estn definidos. Todos los nombres de los objetos se usan dentro de sus alcances declarados. Estndares Revise que el diseo cumpla con todos los estndares de diseo que sean aplicables
38
ATAIR
DEVPROT
Anexo C
Lista de Comprobacin para la Revisin de Cdigo de Jbuilder8 Interprise NOMBRE Y NMERO DE PROGRAMA:_________________ _________ Propsito Fecha:
General
Completo Includes Inicializaci n
Llamadas
Nombres
Cadenas
Apuntadore s
Formato de Salida Parejas {}
Guiarlo a usted en la conduccin de una revisin de Nombre de la cdigo efectiva unidad del programa Conforme usted termine cada paso de revisin, compruebe el elemento en la caja de la derecha. Termine la lista de comprobacin para una unidad del programa antes de comenzar la revisin de la siguiente. Verifique que el cdigo cubre el diseo. Verifique que los includes estn completos y en el lugar correcto. Compruebe la inicializacin de variables y parmetros: Al inicio del programa Al inicio de cada ciclo En la entrada de las funciones/metodos Compruebe los formatos de llamada a funciones: Apuntadores Parmetros Uso de & Compruebe el uso y escritura de nombres: Es consistente? Est dentro del alcance declarado? Las estructuras usan . en las referencias? Compruebe que todas las cadenas estn identificadas por apuntadores terminan en NULL. Compruebe que los apuntadores estn inicializados con NULL solo se eliminan despus de creados, y los apuntadores nuevos siempre se eliminan despus de usarse. Compruebe el formato de salida: El espaciamiento de lneas es el apropiado? El espaciamiento es el apropiado? Asegrese que las {} son los apropiados y se corresponden.
39
ATAIR
DEVPROT
Operadores Lgicos Revisin Lnea-porlnea
Cierre y Apertura de Archivos Estndares
Verifique el uso apropiado de ==, =, ||, && y dems. Compruebe los ( ) en cada funcin lgica. Compruebe cada LOC por sintaxis de la instruccin y que la puntuacin sea la apropiada. Que todas las lineas que deben terminar con ; realmente terminen con ; Verifique que todos los archivos estn declarados de manera apropiada, abiertos, y cerrados. Asegrese que el cdigo se apega a los estndares de codificacin.
40
ATAIR
DEVPROT
Anexo D
Estndar de anlisis y diseo 1. Anlisis de Requerimientos: Sobre el estndar UML y con las herramientas Rational Rose y MS-Office. Entregables: 2. Diagrama de Secuencia (DS) Diagrama de Clases Dinmicas (DC) Clave para cada entregable: <Clave del Entregable><3 primeras consonantes del nombre del caso> <Nmero> Las claves pueden ser: CU, MI, ME, MD, DS o DC. Ejemplo: MIPRB01 se refiere al modelo de interfaz del caso PROBE nmero 01 Caso de Uso (CU, segn la plantilla adjunta) Modelo de Interfaz (MI) Modelo de Navegacin de Estados (ME) Modelo de Datos (MD)
41
ATAIR
DEVPROT
Anexo E
Propuestas de Mejora del Proceso (PIP) Nombre Correo Proyecto PIP nmero Larios Vargas Rigoberto lvrigoberto@yahoo.com.mx DEVPROT 1 Fecha 27/05/04 Organizacin Proyecto TSP Lanzamiento/Fase Junta 6 Prioridad
Descripcin de la Mejora Brevemente describa la mejora que propone 1.- Que el LAUNCH COACH pase mas tiempo en las juntas 2.- Liderear las juntas con ms autoridad Elementos del Proceso Impactados Si los conoce liste los elementos del proceso que deben ser agregados, modificados o borrados
Beneficios de la Mejora (verifique cada uno) Calidad de la mejora Tiempo reducido del ciclo Riesgo reducido
Describa los beneficios probables de los cambios sugeridos 1.- Si el LAUNCH COACH pasara ms tiempo en las juntas, se reducira el riesgo de que el equipo se desviara del proceso 2.- Los integrantes pondran mas atencin a la reunin y por lo tanto las juntas duraran menos tiempo o al menos lo planeado
Cuando haya completado y revisado su Propuesta de Mejora del Proceso, envela al Process Manager y guarde una copia. No escriba debajo de la siguiente lnea. Control de PIP # Recibida Evaluada Esfuerzo involucrado Autor Notificado Razones Aceptada Devuelta Pospuesta Fecha de entrega
42
ATAIR
DEVPROT
Nombre Correo Proyecto PIP nmero
Ivonne Silva Molina ivonne0805@yahoo.com.mx DEVPROT
Fecha 01/06/04 Organizacin Proyecto TSP Lanzamiento/Fase Prioridad media
Descripcin de la Mejora Brevemente describa la mejora que propone 1.- Asistencia continua por parte de los integrantes del equipo en los horarios establecidos
Elementos del Proceso Impactados Si los conoce liste los elementos del proceso que deben ser agregados, modificados o borrados
Describa los beneficios probables de los cambios sugeridos 1.- Habr un avance ms notable en el desarrollo del proyecto 2.- La comunicacin entre los integrantes ser ms completa 3.- Se tendr una mayor perspectiva del avance de los dems compaeros
Cuando haya completado y revisado su Propuesta de Mejora del Proceso, envela al Process Manager y guarde una copia. No escriba debajo de la siguiente lnea. Control de PIP # Recibida Evaluada Esfuerzo involucrado Aceptada Devuelta Pospuesta Fecha de entrega
43
ATAIR
DEVPROT Autor Notificado Razones Nombre Adriana Hernndez Garca Correo mankoatl@yahoo.com.mx Proyecto DEVPROT PIP nmero
Fecha 01/06/04 Organizacin Proyecto TSP Lanzamiento/Fase Prioridad media
Descripcin de la Mejora Brevemente describa la mejora que propone 1.- Seguimiento correcto de los estndares de requerimientos
Describa los beneficios probables de los cambios sugeridos 1.- Mejor entendimiento de la informacin escrita 2.- Trabajo uniforme de los desarrolladores
Cuando haya completado y revisado su Propuesta de Mejora del Proceso, envela al Process Manager y guarde una copia. No escriba debajo de la siguiente lnea. Control de PIP # Recibida Evaluada Esfuerzo involucrado Aceptada Devuelta Pospuesta Fecha de entrega
44
ATAIR
DEVPROT Autor Notificado Razones Nombre Correo Proyecto PIP nmero Adriana Hernndez Garca mankoatl@yahoo.com.mx DEVPROT Fecha 01/06/04 Organizacin Proyecto TSP Lanzamiento/Fase Prioridad media
Descripcin de la Mejora Brevemente describa la mejora que propone 1.- Entrega de documentos en la fecha planeada
Describa los beneficios probables de los cambios sugeridos 1.- Menor atraso en el desarrollo del proyecto 2.- Termino del proyecto en la fecha planeada 3.- Habr menos tiempo muerto por parte de los desarrolladores que ya hayan terminado sus mdulos
Cuando haya completado y revisado su Propuesta de Mejora del Proceso, envela al Process Manager y guarde una copia. No escriba debajo de la siguiente lnea. Control de PIP # Recibida Evaluada Aceptada Devuelta Pospuesta
45
ATAIR
DEVPROT Esfuerzo involucrado Autor Notificado Razones Nombre Enrique Lara Soto Correo ququ_007@yahoo.com.mx Proyecto DEVPROT PIP nmero 1 Fecha de entrega
Fecha 30/Junio/2004 Organizacin ATAIR Lanzamiento/Fase Anlisis de requerimientos Prioridad Alta
Descripcin de la Mejora Brevemente describa la mejora que propone 1.- Que se haga una junta con el coach, ya que hay muchos retrasos en los entregables a nivel equipo TSP y con el mismo coach. Esto nos afecta a todos, ya que hay un descontrol en el equipo. Por lo anterior todos no estamos cumpliendo las horas planeadas de dedicacin. Elementos del Proceso Impactados Si los conoce liste los elementos del proceso que deben ser agregados, modificados o borrados Una reestructuracin en el equipo Beneficios de la Mejora (verifique cada uno) Calidad de la mejora Tiempo reducido del ciclo Riesgo reducido
Describa los beneficios probables de los cambios sugeridos 1.- Tener una mejor organizacin como equipo. 2.- Los integrantes del equipo sern ms responsable (en todos los aspectos).
Cuando haya completado y revisado su Propuesta de Mejora del Proceso, envela al Process Manager y guarde una copia. No escriba debajo de la siguiente lnea.
Control de PIP # Recibida
Aceptada Devuelta
46
ATAIR
DEVPROT Evaluada Esfuerzo involucrado Autor Notificado Razones Pospuesta Fecha de entrega
47
ATAIR
DEVPROT
Anexo F
Minutas Reporte de Reunin Reunin de Lanzamiento 2 Nombre Jos Alberto Jurez Contreras Fecha 13/05/04 Moderador Launch Coach Lugar Laboratorio T163 Fecha de Reunin 13/05/04 Tiempo de: 13:22 Para: Asunto / Propsito Junta 2 Lanzamiento de TSP: Asignar los roles del equipo y Establecer los objetivos del proyecto. Asistentes Nombre Jos Alberto Jurez Contreras Sofa Cabrera Venegas Carlos Gonzlez Guerra Gustavo Saturno Ivonne Silva Molina Rigoberto Larios Vargas Ricardo A. Fonseca Cisneros Jorge A. Arzate Capin Adriana Hernndez Garca Enrique Lara Soto Luis Fernando Castro Careaga Agenda Tiempos (min.) Planeado Inicio Fin 10 45 45 60 50 25
Rol Lder de Equipo Registro de Objetivos Control de Tiempo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Launch Coach Temas Lidera de Discusin Asesor de Lanzamiento Lder de equipo Lder de equipo Lder de equipo Asesor de lanzamiento Lder de equipo
Proceso de agenda y de reunin Revisin de la gestin de objetivos Definicin de objetivos implcitos Establecimiento de objetivos de equipo Seleccin de roles de equipo Asignacin de responsabilidad de seguimiento de objetivos Conclusin de reunin y reporte Decisiones, acciones e informacin clave
Asesor de lanzamiento
48
ATAIR
DEVPROT
Qu Adjuntos: formas GOAL y forma ROLE Revisin por los asistentes
Quin Registrador Todos los asistentes
Cundo 14/may 14/may
Use copias adicionales si es necesario
49
ATAIR
DEVPROT Reporte de Reunin Reunin de Lanzamiento 3 Nombre Jos Alberto Jurez Contreras Fecha 14/05/04 Moderador Launch Coach Lugar Laboratorio T169 Fecha de Reunin 14/05/04 Tiempo de: 6:31 pm Para: Asunto / Propsito Junta 3 Lanzamiento de TSP: Producir el diseo conceptual y estrategia del proyecto y los planes de soporte y proceso. Asistentes Nombre Rol Jos Alberto Jurez Contreras Lder de Equipo Sofa Cabrera Venegas Registro de Objetivos Carlos Gonzlez Guerra Control de Tiempo Gustavo Saturno Miembro de Equipo Ivonne Silva Molina Miembro de Equipo Rigoberto Larios Vargas Miembro de Equipo Jorge Figueroa Miembro del Equipo Germn Cortes Miembro del Equipo Ricardo A. Fonseca Cisneros Miembro de Equipo Jorge A. Arzate Capin Miembro de Equipo Adriana Hernndez Garca Miembro de Equipo Enrique Lara Soto Miembro de Equipo Luis Fernando Castro Careaga Launch Coach Agenda Tiempos (min.) Temas Lidera de Discusin Planeado Inicio Fin 10 6:31 6:45 Proceso de agenda y de Asesor de Lanzamiento reunin 50 6:45 8:13 Producir el modelo Administrador de Diseo conceptual del producto 12:18 12:27 Producir el modelo Administrador de Diseo conceptual del producto 45 12:28 1:49 Definir estrategia de Lder de equipo desarrollo 30 2:07 2:52 Listar productos ha Lder de equipo producirse 40 4:14 5:46 Definir el proceso de Administrador del proceso desarrollo 20 5:50 6:10 Producir el plan del proyecto Administrador del proceso 20 6:11 6:28 Producir el plan de soporte Administrador de soporte 10 6:29 6:31 Definir los miembros del Asesor de Lanzamiento CCB
50
ATAIR
DEVPROT
10 5
6:32 3:25
6:35 3:35
Definir tareas de los roles y status semanalmente Conclusin de reunin y reporte
Asesor de Lanzamiento Asesor de lanzamiento
Decisiones, acciones e informacin clave Qu Adjuntos: formas STRAT forma INV y SUMS Revisin por los asistentes Miembros del CCB: Carlos Gonzles, Alberto Jurez, Germn Cortes. Se consider una productividad promedio de 25 LOC/hora Se estableci que se generar una sola versin del proyecto Los tamaos relativos para el estimado de tiempo fueron: Muy sencillo 200 Sencillo 400 Mediano 800 Difcil 1500 Muy difcil 2000 Se definieron 6 ciclos. Ciclo 1 y 2 de dos semanas y ciclos 3,4,5 y 6 de a 3 semanas Use copias adicionales si es necesario
Quin Registrador Todos los asistentes Launch Coach Todos Administrador de Soporte Todos
Cundo 19/may 20/may 18/may 18/may 18/may 18/may
Todos
18/may
51
ATAIR
DEVPROT Reporte de Reunin Reunin de Lanzamiento 4 Nombre Rigoberto Larios Vargas Fecha 20/05/04 Moderador Launch Coach Lugar Laboratorio T163 Fecha de Reunin 20/05/04 Tiempo de: 13:00 Para: 20:30 Asunto / Propsito Junta 4: Producir un plan de todo el proyecto Asistentes Nombre Jos Alberto Jurez Contreras Sofa Cabrera Venegas Carlos Gonzlez Guerra Gustavo Saturno Ivonne Silva Molina Rigoberto Larios Vargas Ricardo A. Fonseca Cisneros German Cortes Jorge A. Arzate Capin Jorge Figueroa Adriana Hernndez Garca Enrique Lara Soto Luis Fernando Castro Careaga Agenda Tiempos (min.) Planeado Inicio Fin 10 13:00 13:05 30 13:06 13:50
Rol Lder de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Registro de Objetivos Control de Tiempo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Launch Coach Temas Lidera de Discusin Launch Coach Design Manager Team Leader Planning Manager Planning Manager Planning Manager Launch Coach Cundo
Agenda and meeting process Estimate the size of all Project products 60 13:51 14:51 Determine the project tasks 75 17:30 18:52 Estimate overall resources required 30 18:53 19:30 Determine resources available by week 30 19:30 20:15 Generate and review overall team plan 5 20:15 20:30 Meeting gras-up and report Decisiones, acciones e informacin clave Qu Quin Adjuntos: formas SUMS Plan de todo el equipo (plantillasTASK y SCHED Revision de las formas de la junta 3 Launch Coach
20/05/04
52
ATAIR
DEVPROT
Mostrar formas de la junta 4 Se determino invertir 15 horas por semana para PSP Algunas correcciones de la forma SUMS Discusin del llenado de la forma TASK Llenado de la forma SCHEDULE
Todos Todos Todos Todos Todos
20/05/04 20/05/04 20/05/04 20/05/04 21/05/04
53
ATAIR
DEVPROT Reporte de Reunin Reunin de Lanzamiento 6 Nombre Rigoberto Larios Vargas Fecha 25/05/04 Moderador Launch Coach Lugar Laboratorio T163 Fecha de Reunin 25/05/04 Tiempo de: 14:37 Para: Asunto / Propsito Junta 6: To produce a bottom-up plan for each
Asistentes Nombre Jos Alberto Jurez Contreras Sofa Cabrera Venegas Carlos Gonzlez Guerra Gustavo Saturno Ivonne Silva Molina Rigoberto Larios Vargas Ricardo A. Fonseca Cisneros German Cortes Jorge A. Arzate Capin Jorge Figueroa Adriana Hernndez Garca Enrique Lara Soto Luis Fernando Castro Careaga Agenda Tiempos (min.) Planeado Inicio Fin 10 14:37 14:57 90 17:50 19:16 70 13:15 14:25
Rol Lder de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Registro de Objetivos Miembro de Equipo Miembro de Equipo Miembro de Equipo Control de Tiempo Miembro de Equipo Miembro de Equipo Launch Coach Temas Lidera de Discusin Launch Coach Team Team Team Planning Manager Launch Coach Cundo 25/05/04 y 27/05/04 27/05/04 27/05/04 27/05/04 27/05/04
54
Agenda and meeting process Allocate next-phase tasks Team member produce individual plans 50 14:30 15:00 Balance the team`s workload 15 15:00 16:15 Document the next-phase plan 5 16:15 16:27 Meeting wrap-up and report Decisiones, acciones e informacin clave Qu Quin Completar y balancear el plan por cada ingeniero Todos (plantillas TASK y SCHED) Todos Se escriben los planes individuales de trabajo Todos Correccion de la hoja SUMS Todos 30 lneas de diseo detallado por persona por hora Todos
ATAIR
DEVPROT Las productividades (en cuanto a tiempo) son iguales para todos los mdulos Correccin de la forma SCHEDULE Todos Todos 27/05/04 27/05/04
55
ATAIR
DEVPROT Reporte de Reunin Reunin de Lanzamiento 7 Nombre Rigoberto Larios Vargas Fecha 27/05/04 Moderador Launch Coach Lugar Laboratorio LIS Fecha de Reunin 2705/04 Tiempo de: 18:07 Para: 19:42 Asunto / Propsito Junta 7: To conduct a project risk assessment Asistentes Nombre Jos Alberto Jurez Contreras Sofa Cabrera Venegas Carlos Gonzlez Guerra Gustavo Saturno Ivonne Silva Molina Rigoberto Larios Vargas Ricardo A. Fonseca Cisneros Jorge A. Arzate Capin Jorge Figueroa Adriana Hernndez Garca Enrique Lara Soto Luis Fernando Castro Careaga Agenda Tiempos (min.) Planeado Inicio Fin 10 18:07 18:09 75 18:10 19:37 5 19:37 19:42
Rol Lder de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Miembro de Equipo Registro de Objetivos y Control de Tiempo Miembro de Equipo Miembro de Equipo Control de Tiempo Miembro de Equipo Miembro de Equipo Launch Coach Temas Agenda and meeting process Conduct project risk assessment Meeting wrap-up and report Lidera de Discusin Launch Coach Team Leader Launch Coach
Decisiones, acciones e informacin clave Qu Completar la lista de riesgos con evaluaciones Asignacin de los riesgos claves Llenado de la forma ITRL
Quin Todos Todos Todos
Cundo 27/05/04 27/05/04 27/05/04
56
ATAIR
DEVPROT
PLANES PARA MITIGAR LOS RIESGOS
- No entender los requerimientos Realizar juntas semanales los primeros 4 jueves despus de iniciado el proyecto, con una hora de duracin Entrevistas con el cliente
- Falta de comunicacin con el equipo El lder del equipo lleva un reporte con todas las peticiones y mantiene informados a todos los miembros del equipo (Semanalmente) - Incumplimiento de actividades por miembros del equipo Rebalance de trabajo
- No dar seguimiento a los riesgos Para cada fecha de verificacin de incumplimiento de riesgos, realizar un plan de mitigacion para el riesgo ms cercano que no est resuelto.
57
ATAIR
DEVPROT
Anexo G
Postmortem del reporte. Fechas planeadas de inicio y entrega de reporte de proyecto. Fecha de inicio: viernes 1 de octubre del 2004 Fecha de entrega: viernes 8 de octubre del 2004 Motivos por los cuales se planearon estas fechas: Se trabajaran 150 minutos diarios por integrante, dando un total de 600 minutos diarios por equipo. Distribucin de trabajo:
No. Hojas reales 9
Da
Puntos a cubrir planeados
Portada, tabla de contenido, introduccin, Descripcin del proceso de desarrollo, 01/10/2004 descripcin del problema
puntos a cubrir reales Portada, tabla de contenido, introduccin, Descripcin del proceso de desarrollo Descripcin del proceso de desarrollo, Descripcin del problema Alcance del proyecto, Productos de desarrollo Propuestas de mejora y lecciones aprendidas, Bibliografia Anexos Anexos Anexos Anexos Anexos Anexos Conclusiones Postmortem
No. Planeado de hojas
11 9
Descripcin del problema, 04/10/2004 alcance del proyecto Productos de desarrollo, Propuestas de Mejora de 06/10/2004 proceso Conclusiones y lecciones aprendidas, Bibliografa, Anexos Anexos, postmortem. -
4 4 15 3 33 53 0 0 0 0 0 0 0
07/10/2004 08/10/2004 11/10/2004 12/10/2004 13/10/2004 14/10/2004 15/10/2004 18/10/2004 19/10/2004
125 58 96 87 71 64 7 6
La siguiente grfica nos muestra la relacin entre las horas planeadas y las horas reales invertidas en el desarrollo del reporte del proyecto.
58
Nmero de hojas
01
100
120
140
/1
20
40
60
80
0/ 20 04
02 /1
0/
11
03 /1 0/ 20 04 04 20 0/ 0/ /1 /1 04 05
20 04
9 4
06 /1 0/ 20 04 0/ /1 07
20 04
ATAIR
DEVPROT
08
20
15
/1 0/
04
33
09 /1 0/ 20 04 20 04 04 20 0/ 0/ 0/ /1 /1 /1 10
20 04
53
125
Fechas
11 12
Nmero de hojas planeadas y reales
UNIVERSIDAD AUTONOMA METROPOLITANA

13 /1 0/ 20 0/ 15 16 17 18 19 /1 /1 /1 /1 /1 20 0/ 0/ 0/ 0/ 0/ /1 14 04 04 20 20 20 20 20 04 04 04 04 20 04
58
UNIDAD IZTAPALAPA
0 0 0 0 0
04
96 87
71 64
7 6 0
planeado real
59
ATAIR
DEVPROT Tiempo planeado y real que se le dedic al desarrollo del reporte.
La siguiente tabla nos muestra el tiempo planeado en minutos (para grficas y hojas) que el equipo le pensaba dedicar al reporte del proyecto, adems de los tiempos reales por grfica y por hoja. Tambin se muestra el nmero de minutos totales planeados y los minutos totales reales.
Equipo: ATAIR Instructor: Luis Fernando Castro Careaga
Fecha: 29/09/2004
Objeto
Nmero Planeado
Esfuerzo Est.Xobj (min)
Esfuerzo Est (min)
Nmero Real (min) Total minutos planeados 15 5 60 360 Total minutos reales 11 284 40 323 660 120 120 480 360 516 53 92 53 364 10 395 2585 11 2945 4692
Portada Tabla de Contenido Introduccin Descripcin del proceso de desarrollo Descripcin del problema Alcance del proyecto Productos de desarrollo Propuestas de mejora de proceso Conclusiones y lecciones aprendidas Biubliografia Anexos TOTAL
Nm Nm Nm Nm Nm Nm Nm Nm de de de de de de de de grficas hojas grficas hojas grficas hojas grficas hojas 1 1 5 10 5 10 3 8 0 0 0 4 0 0 0 0 0 3 8 1 1 6 4 2 3 12 6 1 76 113 Total 5 5 5 5 5 5 5 5 5 5 5 60 60 160 60 40 40 60 10 5 0 0 0 20 0 0 0 0 0 15 40 2585 5 60 360 640 120 120 480 360 10 380 2545 0 0 3 8 0 0 0 24 0 1490 1528 284 40 320 508 53 92 53 340 11 1455 3164
La siguiente grfica nos muestra la relacin entre el tiempo total planeado y el tiempo total real que se invirti en el desarrollo de cada punto especificado en la tabla anterior.
60
ATAIR
DEVPROT
minutos planeados y reales por punto a cubrir

3500 3000 2500 minutos 2000 1500 1000 500 284 0 11 15
on te ni do
2945
planeado real
360 40 60 323
660 516 120 53 120 92 53

Bi ub lio gr af ia
480
360 364
395 11 10
An ex os
D es cr ip ci
In tro de du lp cc ro i ce n so de de D sa es rro cr ip llo ci n de lp ro bl em A lc a an ce de lp ro Pr ye od ct uc o Pr to op s d ue e de st as sa de rro C llo m on ej cl or us a io de ne pr s y oc le es cc o io ne s ap re nd id as n
Po rta da Ta bl a de
Puntos a cubrir
61
ATAIR
DEVPROT Tiempo planeado y real para cada fase del reporte. En la tabla que a continuacin se muestra, refleja el tiempo planeado y el tiempo real que se le dedic a cada fase del desarrollo del reporte.
Fase Planeacin Desarrollo Revisin del Desarrollo Integracin Revisin de la Integracin Postmortem Total
Tiempo Plan. 40 2585 60 240 60 20 3005
Tiempo Real 47 4692 286 218 75 28 5346
La siguiente grfica nos muestra la relacin entre el tiempo planeado por fase y el tiempo real.
minutos planeados y reales por fase
6000
5346 5000 4692
4000
m in u to s
3000 2585 2000
3005
planeado Real
1000 240 47 0 40 Planeacin Desarrollo 286 60 Revisin del Desarrollo 218 Integracin fase
75 60 Revisin de la Integracin
28 20 Postmortem Total
62
ATAIR
DEVPROT
Anexo H
Contenido del Disco Compacto adjunto. A continuacin se describe el contenido del disco que se gener con toda la documentacin y el trabajo realizado por el equipo, no se integra en la impresin del reporte este material porque es demasiado extenso y el propsito del reporte es dar a conocer la forma de trabajo tanto personal como en equipo mediante el uso de procesos. Los directorios que se encuentran dentro del disco son: * Minutas Minutas de las juntas de lanzamiento del proyecto TSP * Estndares Estndar de conteo y codificacin Estndar de diseo Estndar de revisin de diseo * Plan de pruebas unitarias Plan de pruebas unitarias de Registro de estimados Plan de pruebas unitarias de Probe Plan de pruebas unitarias de Bitcora de defectos Plan de pruebas unitarias de Bitcora de tiempo * Plan de pruebas de sistema Plan de pruebas de sistema de Bitcora de defectos Plan de pruebas de sistema de Bitcora de tiempo Plan de pruebas de sistema de Grficas Plan de pruebas de sistema de Login, registro de tareas y registro de proyectos Plan de pruebas de sistema de Probe Plan de pruebas de sistema de Registro de Estimados Plan de pruebas de sistema de Registro de procesos Plan de pruebas de sistema de Size Estimate Plan de pruebas de sistema de Summary * Modelo de Requerimientos Modelo de Requerimientos de Bitcora de defectos Modelo de Requerimientos de Bitcora de tiempos Modelo de Requerimientos de Summary Modelo de Requerimientos de Registro de estimados Modelo de Requerimientos de Grficas Modelo de Requerimientos de Registro de procesos Modelo de Requerimientos de Login, registro de tareas y registro de proyectos Modelo de Requerimientos de Probe Modelo de Requerimientos de Size Estimate
63
ATAIR
DEVPROT
* Archivos Racional Rose Diagrama general del sistema Archivos Racional Rose de Base de datos general Archivos Racional Rose de Bitcora de defectos Archivos Racional Rose de Size Estimate Archivos Racional Rose de Grficas Archivos Racional Rose de Probe Archivos Racional Rose de Registro de estimados Archivos Racional Rose de Summary Archivos Racional Rose de Login, registro de tareas y registro de proyectos Archivos Racional Rose de Registro de procesos Archivos Racional Rose de Bitcora de tiempo * DLD DLD de Probe DLD de Bitcora de tiempo DLD de Bitcora de defectos DLD de Size Estimate DLD de Summary DLD de Registro de estimados DLD de Registro de procesos DLD de Grficas DLD de Login, registro de tareas y registro de proyectos * Cdigo fuente Cdigo fuente de Login, registro de tareas, registro de proyectos Cdigo fuente de probe * PIPs Pips generadas durante el proceso. * DEVPROT Script de la BD final. Archivos .java, .class Ejecutables para diferentes plataformas Hojas Excel TSP Hojas excel con el registro de trabajo de cada uno de los integrantes del equipo: ADR, ALB, CAP, CAR, ENR, GUS, IVO, RIC, RIG, SOF Hoja consolidada con el registro de trabajo del equipo Adems de los directorios listados anteriormente, dentro de la carpeta principal se encuentra un archivo devprot.bat para correr el sistema dentro de la plataforma Windows,
64
ATAIR
DEVPROT reportes finales de cada uno de los equipos, adems de un archivo de texto con los pasos a seguir para instalar el sistema.
65

UAMI11541

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

UAMI11541

Încărcat de

Drepturi de autor:

Formate disponibile

Reporte de Proyecto final de Investigacin II Desarrollo de un Sistema utilizando el proceso TSP

Asesor: Ing. Luis Fernando Castro Careaga

Mxico D.F., Octubre de 2004

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Descripcin del Proceso de Desarrollo

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Descripcin del Problema.

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Figura: Desglose de jerarquas

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Alcance del Proyecto

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Propuesta de Mejora de Proceso.

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Conclusiones y Lecciones aprendidas

Cumulative Earned Value

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

2000,0 Cummulative Hours

1500,0 Cumulative Planned Hours Cumulative Actual Hours 1000,0

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Planned Hours Actual Hours

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Cumulative Defects Removed by Phase for Assembly SYSTEM

Cumulative Defects Removed by Phase

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Defects Removed by Phase for Assembly SYSTEM

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Defect Density by Phase for Assembly SYSTEM

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Phase Yields for Assembly SYSTEM

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

UNIVERSIDAD AUTONOMA METROPOLITANA UNIDAD IZTAPALAPA

Click en boton Aceptar en la pantalla Login

Seleccion de pestaa Consultas Salir Seleccion de pestaa Scripts Sali r

Registro de Procesos Bitacora de Def ectos

Diagrama de Navegacin de Pantallas del Sistema..

Size Estimating Template

Project Plan Summay

Project Plan Summary

PROBE (PROxy Based Estimate)

Resultados de Estimacion de Tamao y Tiempo

Despedida de Probe Errores

Seleccin de la pestaa Registro

Seleccion de Pestaa Bit . Tiempo

UNIVERSIDAD AUTONOMA METROPOLITANA

Documentacin General del Sistema

BIT. T IEMPO 1.. * FASE 1

PROCESO Cv eProc NomProc DescProc

CveT ipoDef CveUsua DescDefecto 1