DIVISIÓN DE CIENCIAS BÁSICA E INGENIERÍA DEPARTAMENTO DE INGENIERÍA ELÉCTRICA REPORTE DE PROYECTO TERMINAL DESARROLLO DE UN SISTEMA DE ALARMAS MÉDICAS

Transcripción

1 DIVISIÓN DE CIENCIAS BÁSICA E INGENIERÍA DEPARTAMENTO DE INGENIERÍA ELÉCTRICA REPORTE DE PROYECTO TERMINAL DESARROLLO DE UN SISTEMA DE ALARMAS MÉDICAS A TRAVÉS DE LA METODOLOGÍA TSP ASESOR M. en C. Luis F. Castro Careaga Prof. Dep. de Ing. Eléctrica ALUMNO Martín David Chacón Pizá Junio 2012.

2 1. Presentación El presente reporte detalla las actividades realizadas como Proyecto Terminal en la creación de un Sistema de Alarmas Médicas llevado a cabo a través de las metodologías PSP y TSP, Personal Software Process y Team Software Process. 2. Introducción La Ingeniería de Software ofrece metodologías para el desarrollo y mantenimiento de software de calidad. Se trata de una disciplina relativamente nueva que trata con diversas áreas de la computación. No existe una definición única, sin embargo se enuncia la siguiente: La Ingeniería de Software es la aplicación práctica del conocimiento científico al diseño y construcción de programas de computadora y a la documentación requerida para desarrollar, operar y mantenerlos. EL PSP desarrollado en 1993 por Watts S. Humphrey, Personal Software Process, es una disciplina que ofrece un enfoque estructurado para el desarrollo de software, ya que al utilizar sus métodos las personas pueden mejorar sus habilidades de estimación y planificación en casi cualquier área, administrando la calidad de su trabajo y reduciendo el número de defectos en sus productos. Con ayuda de su contraparte TSP, Team Software Process, que fue desarrollada en el SEI, Software Engineering Instituteunidad, del Carnegie Mellon University, permite a los equipos mejorar su productividad mientras ofrece habilidades y métodos para administrar su trabajo, con el objetivo de producir sistemas de alta calidad. Cuando se plantea la realización de un proyecto de Software, con frecuencia los compromisos no son realistas debido a diferentes factores. Cuando los proyectos son grandes, es más difícil de controlar su realización. Para ser efectivos, los equipos necesitan un liderazgo y una administración adecuada. Es aquí donde el PSP, proporciona la metodología y habilidad que los desarrolladores necesitan para trabajar dentro de un equipo auto dirigido. La calidad de un sistema de software puede no estar clara pero en general está determinada por la calidad de sus componentes más deficientes, es gobernada por el individuo que lo desarrolla y depende del proceso utilizado para desarrollarlo y mantenerlo El PSP es un proceso personal para desarrollar software o cualquier otra actividad definida. Proporciona un marco de trabajo de medición y análisis para caracterizar y administrar el trabajo personal. Es un proceso definido que ayuda a mejorar el desempeño personal. El PSP propone a los ingenieros de software una forma disciplinada de estructurar su trabajo personal. Consta de métodos, formularios y procedimientos que ayudan a los

3 ingenieros de software a planificar, medir, y gestionar su trabajo. Además sirve para trabajar con cualquier lenguaje de programación y metodología de diseño, contempla la mayoría de los aspectos de los trabajos de desarrollo de software, como especificación de requerimientos, pruebas, definición de procesos, y eliminación de defectos. Al usar el PSP, el objetivo del proceso debería ser obtener productos sin defectos y dentro de los plazos y costos previstos. Utilizado en conjunción con el Team Software Process (TSP), el PSP permite lograr efectivamente estos objetivos trabajando de forma autodirigida en grupo. PRIMERA PARTE, TAREAS DE APRENDIZAJE DE PSP 3. Personal Software Process (PSP) El PSP está diseñado para su uso individual, basado en prácticas de software industriales en pequeña escala. El PSP se introduce en seis pasos compatibles y progresivos. El estudiante escribe uno o más programas del tamaño de un módulo en cada paso; posteriormente recolecta y analiza datos de su trabajo; y finalmente usa los resultados para mejorar su desempeño personal. El proceso del PSP inicia al revisar y comprender los Guiones; en los cuales se establece la lección de aprendizaje a la tarea correspondiente. Una vez que se ha comprendido la lección, se debe de realizar la tarea correspondiente. De aquí deberá de realizarse la planeación de su tarea. Mediante la etapa de diseño se podrá comprender mejor los requerimientos del sistema, de esta manera la Codificación será más rápida y se podrá obtener una compilación libre de errores para el funcionamiento correcto de la aplicación. En el PM (Post Mortem) se deberá hacer el análisis del proceso que se llevo. La bitácoras se usan para registrar tiempos y anotaciones de la etapa de Diseño, compilación y PM. Las fases principales en la metodología PSP son las siguientes: Planeación, Diseño, Codificación, Compilación, Pruebas y Post Mortem. El aprendizaje PSP se divide en tres versiones: PSP0, PSP1 y PSP2, llevadas a cabo a través de las siguientes tareas: PSP0: Establece una referencia del desempeño Tarea 1: Calcular la media y la desviación estándar de un conjunto de n números reales

4 mediante un programa desarrollado en el lenguaje de programación elegido. Tarea 2: Programa para contar en líneas de código los elementos de un programa. Tamaño total de un programa, tamaño total de cada una de sus partes (clases, funciones procedimientos), y el número de elementos (o métodos). PSP1: Hacer planes sobre tamaño, recursos y tiempo. Tarea 3: Programa para calcular los parámetros de la regresión lineal 0 y 1, los coeficientes de correlación rx,y y r2 para un conjunto de n parejas de datos. Dado un estimado, xk calcular una predicción mejorada yk donde:yk = xk. Tarea 4: Programa para calcular los rangos de tamaño relativos para establecer rangos muy pequeños, pequeños, medianos, grandes y muy grandes utilizando la desviación estándar. PSP2 Practicar la administración de defectos y el rendimiento. Tarea 5: Programa para integrar numéricamente una función usando la regla de Simpson. Tarea 6: Programa para encontrar el valor de x. Al integrar la función t de 0 a x da el resultado p. Tarea 7: Programa para calcular la correlación entre dos conjuntos de números x e y, calcular la significancia de esa correlación, calcular los parámetros de regresión lineal 0 y 1 para un conjunto de n parejas de datos. Dado un estimado, xk calcular una predicción mejorada, yk donde yk= 0+ 1xk Calcular el intervalo de predicción del 70% para ese estimado. Tarea 8: Programa para calcular los parámetros de estimación de regresión múltiple de tres variables. SEGUNDA PARTE, DESARROLLO DEL SISTEMA DE ALARMAS MÉDICAS 4. Team Software Process (TSP) El proceso TSP es una metodología para dirigir el trabajo de mejora y desarrollo de software además de establecer un entorno donde el trabajo efectivo de equipo sea normal y natural. Dando seguimiento con base en un marco de trabajo a partir de una estructura de proceso para construir y guiar los equipos de ingeniería mediante un proceso de construcción de equipo, que construye metas compartidas, compromisos compartidos y cohesión. Al trabajar con el modelo TSP se mejora la calidad de los procesos, se reducen los costos lo mayor posible, esto gracias a la generación mínima de errores y el poco tiempo en que estos procesos se realizan. Los objetivos del TSP son:

5 Mostrar a los gerentes como monitorear, motivar a sus equipos de trabajo y ayudarlos a alcanzar su máxima productividad. Esto se logra mediante las habilidades adoptadas en el PSP. Conforme se avanza en un proyecto, es indispensable la mejora continua de procesos. Proveer de una guía para el mejoramiento en organizaciones maduras. Establecer estándares para medir la calidad, y controlar el proceso. El TSP está basado en los siguientes principios: Los ingenieros conocen más acerca de su trabajo y pueden hacer mejores planes. Cuando los ingenieros planifican su propio trabajo, ellos se comprometen con el plan. Para minimizar la duración del proyecto los ingenieros pueden balancear su carga de trabajo. Sólo la gente que hace el trabajo, puede recoger datos precisos. Para maximizar la productividad, hay que centrarse primero en la calidad. El TSP consta de las siguientes fases: Lanzamiento: Se llevan a cabo 9 juntas que tienen como objetivo analizar y construir la información necesaria para ofrecer una solución de software a un problema específico. En la junta uno la dirección explica a los miembros del equipo cual es la problemática que se tiene respondiendo a todas las preguntas que sean necesarias, con ello el equipo utiliza el conjunto de guiones que el proceso proporciona para que a través de la segunda a la octava junta, se genere una solución estratégica respaldada por un plan detallado y planes alternativos, que el equipo ofrece por medio de una presentación que se lleva a cabo en la novena junta, con el fin de convencer a la dirección en que dicha solución es idónea para la problemática que se planteó, el reto es que el equipo de desarrollo y la dirección lleguen a un acuerdo para iniciar con el proyecto. Requerimientos: Se analiza el conjunto de consideraciones necesarias para el entendimiento del problema, es necesario que se realicen entrevistas con las personas que estén familiarizadas con el problema, para generar documentación formal y no ambigua que permita expresar lo que la dirección necesita para resolver su problema. Diseño de alto nivel (HLD): Una vez que se han entendido los requerimientos es necesario hacer modelos plasmados en un conjunto de documentos, que ofrecen una serie de perspectivas a un alto nivel del diseño de la solución, para que los desarrolladores realicen los componentes que se definen en el mismo. Diseño detallado (DLD): Los desarrolladores utilizan los conocimientos adquiridos en el PSP para crear estrategias que realicen una traducción de la problemática (con los

6 requerimientos definidos) a un conjunto de objetos que se comunican entre sí, para resolver la lógica del sistema. Codificación: Elaboración de los modelos detallados que los desarrolladores crearon, representados en líneas de código de un lenguaje de programación. Compilación: Fase en la que el compilador del lenguaje de programación evalúa la correcta escritura de la codificación, es deseable que al llegar a este punto se encuentre el menor número de errores. Pruebas Unitarias: Diseño de escenarios que permitan evaluar de manera individual los módulos que los desarrolladores crearon. Pruebas de Integración: En esta fase se evalúa la correcta comunicación entre componentes. Pruebas de Sistema: Conjunto de evaluaciones que se realizan cuando ya se ha construido la aplicación, para finalmente determinar que se alcanzaron las expectativas de la dirección en función de los requerimientos. Revisiones e inspecciones: Sin contar el lanzamiento, estas etapas se realizan en la documentación que se genera en las fases antes mencionadas del TSP, su objetivo es encontrar de manera oportuna el mayor número de defectos en cada fase. 5. Actividades realizadas 5.1 Equipo de desarrollo para el Sistema de Alarmas Médicas El Sistema de Alarmas Médicas, empleando la metodología TSP, se desarrolló por el siguiente equipo: 5.2 Lanzamiento del proyecto TSP A continuación se presenta la información de lo realizado durante las 9 juntas y el Post Mortem de lanzamiento TSP, referente al proyecto desarrollado. Junta 1

7 Repaso de TSP y del taller. Presentación de la dirección sobre las necesidades de negocio del proyecto. Presentación de mercadotecnia sobre las necesidades de mercado. Asistentes: Coach, miembros del equipo, líder del equipo y alta dirección. Junta 2 Revisión de las metas de la dirección: o Obtener prototipo operacional. o Entrega a tiempo del prototipo. o Obtener el prototipo con eficiencia respecto al tiempo de respuesta. Definición de metas implícitas: o Terminar el prototipo con una alta calidad. o Diseñar una interfaz amigable. o Implementar una interfaz web. o Desarrollar un prototipo seguro. o Terminar un prototipo portable y robusto. Establecimiento de las metas del equipo: o Aplicar y aprende el TSP. o Aprender lenguajes de programación para aplicaciones web o Utilizar preferentemente software libre. o Mantener durante el desarrollo del proyecto un buen ambiente de equipo. Selección de los roles del equipo. Asignación de la responsabilidad de seguimiento de las metas. Junta 3 Generación del diseño conceptual del producto. Definición de la estrategia de desarrollo. Enlistar los productos a ser generados. Definición del proceso de desarrollo.

8 Se llegó al acuerdo de manejar un proceso de desarrollo con tres iteraciones, las cuales comprenden las fases de: Análisis de Requerimientos Inspección de Requerimientos Diseño de Alto Nivel. Revisión Inspección HLD. Diseño Detallado. Revisión Inspección DLD. Codificación. Revisión Inspección. Pruebas de Integración. Generación del plan de proceso. Generación del plan de soporte. Definición de las tareas de los roles. Junta 4 Estimación del tamaño de todos los productos del proyecto. Determinar las tareas del proyecto. Creación de documentos. Revisión de documentos. Revisión de código. Revisión de diseño detallado. Estimar los recursos generales requeridos. Determinar los recursos disponibles por semana. Generar y revisar el plan general del equipo. Junta 5 Revisión de las metas de calidad. Estimación de defectos introducidos. Estimación de defectos eliminados. Producir el plan de calidad. En esta junta se realizó la revisión de las metas de calidad del equipo, por lo cual fue encabezada por el administrador de calidad, utilizando las guías de calidad que el proceso TSP propone. Una vez establecidas las metas de calidad del equipo se realizó la estimación de defectos por hora con la siguiente fórmula: Defectos introducidos(x) = Tiempo en fase(x) * Tasa de introd. de defectos(x)donde x es la fase El administrador de calidad encabeza al equipo para evaluar y ajustar el plan para que las metas se cumplan a lo largo de la realización del proyecto, para ello se evaluaron las

9 densidades de los defectos y tasas de eliminación resultantes, y se ajustaron los tiempos y/o rendimientos de cada fase. Junta 6 Asignación de tareas a los miembros del equipo. Se realizan los planes individuales de los miembros del equipo. Se realiza un balance de carga de trabajo del equipo Junta 7 Evaluación de los riesgos del proyecto En esta junta se establecieron los riesgos que se pueden generar a lo largo del proyecto, cada integrante del equipo sugirió algún riesgo para ser tomado en cuenta, para después evaluar el impacto que pudieran tener en el calendario de trabajo. Para cada riesgo mencionado por los integrantes del equipo se juzga la probabilidad de que ocurra Baja, Media o Alta. Una vez identificada la probabilidad y el impacto, se asignan los riesgos de mayor prioridad a los integrantes del equipo, para que cada uno de los integrantes del equipo le dé seguimiento al riesgo que le fue asignado. Junta 8 Preparación del plan de la junta de presentación a la dirección. Los puntos que se acordaron presentar a la dirección fueron los siguientes: Resumen del Plan. Asignación de roles. Metas explicitas de la dirección. Metas del equipo. Componentes generados y estimado de su tamaño por ciclo. Calendario de trabajo del equipo. Estrategias y fechas clave del equipo. Descripción de iteraciones. Plan de calidad del equipo. Planes alternativos. Evaluación de riesgos. Tiempos de lanzamiento TSP del equipo. Junta 9 Reporte de lanzamiento a la dirección. Se presentaron los resultados que el equipo generó, tanto del plan de trabajo como los planes alternativos, con el fin de que la dirección apruebe o no las propuestas planteadas y así iniciar con el proyecto.

10 5.3 Resultados del Lanzamiento Fin planeado 27 de febrero del semanas delante de la fecha objetivo de la dirección EL Plan alternativo reduce 6 semanas recortando el alcance Existen riesgos de alto impacto y probabilidad que podrían afectar significativamente las fechas planeadas Metas de la Dirección Explícita Meta Medida de la meta Plan Aumentar los beneficios del programa del GDF Cumplir el 100% de los requerimientos Esta considerada dentro del plan alternativo Tener un prototipo para enero Reducir al máximo el efecto contraproducente de las recetas Cumplimiento de la lista de enfermedades. 11 de enero del /- 7 Esta considerada dentro días del plan alternativo En un 15% Esta considerado en el plan Requerimientos al 100% Esta considerado Metas de la Dirección Implícitas Meta Medida de la meta Plan Crear un sistema amigable Crear un sistema seguro El Sist. debe manejar un número limitado de alertas Entregar un demo con Calidad Una buena aceptación del usuario para el sistema beta Una buena aceptación del usuario para el sistema beta Cubrir todas las enfermedades especificadas en requerimientos 0,2 Defectos por Kloc usando las métricas de TSP Considerado en el plan Considerado en el plan Considerado en el plan Considerado en el plan Confiabilidad (consistencia y completitud en los datos) Cubra el 100% de los requerimientos del usuario Esta considerado

11 5.3.3 Metas del Equipo Meta Medida de la meta Plan Integración del equipo de diez personas (minimizar conflictos, maximizar la comunicación) Experimentar el Proceso TSP Experimentar un proceso ágil (Extreme Programming ) Apegarse a la descripción de los Roles Respetar horarios de trabajo Cero discusiones personales Cubrir el valor acumulado planeado Objetividad en los scripts de las juntas Juntas semanales Programación en parejas Esta considerado Seguir siempre los guiones de rol de TSP 10 horas planeadas semanales Esta considerado Se considera en el plan Cubrir la mayor parte de los requerimientos para enero. Cubrir el 80% de valor acumulado del sistema Se considera en el plan Diagrama del Proceso

12 5.3.5 Plan Original Plan Original con Módulos a eliminar

13 Plan Alternativo Plan Alternativo Actividad a Eliminar Modulo de Análisis de Bitácora 105 Modulo de Administración de Bitácora Modulo de Administración de Usuarios Modulo de Administración de Tabla de Contradicciones Tiempo en Horas SUMA hrs. Por semana Aproximadamente equivale a 6 semanas Semana de Termino 28/Feb/2011 Semana de Termino Ajustado 17/Ene/ Resumen del Lanzamiento Tiempos del lanzamiento TSP (Planeado vs Real ) Junta Real (minutos) Plan (minutos)

14 Totales Horas Post Mortem de las juntas En la junta final que corresponde al lanzamiento, se concluyó que todos los datos fueron correctamente recolectados, que todas las tareas pendientes fueron finalizadas y registradas en las formas apropiadas. También se evaluó y documentó las metas del equipo y al término de esta junta se obtuvo una forma MTG con el resumen de la misma. En la junta de Post Mortem y con todos los datos reunidos, se verificaron las mejoras, también se identificaron los errores que se cometieron en el lanzamiento, se crearon PIP s (propuesta de mejora del proceso) para establecer los puntos potenciales de mejora y de esta manera obtener mejores resultados en proyectos futuros. 5.5 Seguimiento semanal del proyecto. Cada semana se reúne el equipo TSP para asegurar que todos los miembros del equipo comprenden el estado actual del proyecto y dar a conocer qué es lo que sigue por hacer en el proyecto. La agenda y proceso de la junta en cada semana es la siguiente: o o o o o o Reporte de la administración. Reporte de los roles. Reporte de metas. Reporte de riesgos. Estado del proyecto. Planes de la siguiente semana. Al final de cada junta se revisa el reporte de la junta (forma mtg) en el cual se registran las decisiones, acciones e información clave de la junta Junta Semanal 1 El trabajo realizado por los integrantes del equipo TSP en la semana 1 del 25/10/2010 al 31/11/2010 comprende lo siguiente:

15 Los resultados del trabajo realizado son los siguientes: En la tabla se observa que el equipo en la semana 1 no alcanzó el trabajo planeado para éste periodo Junta Semanal 2 El trabajo realizado por los integrantes del equipo TSP en la semana 2 del 01/11/2010 al 07/11/2010 comprende lo siguiente: Los resultados del trabajo realizado son los siguientes:

16 5.5.3 Junta Semanal 3 El trabajo realizado por los integrantes del equipo TSP en la semana 3 del 08/11/2010 al 14/11/2010 comprende lo siguiente: Los resultados del trabajo realizado son los siguientes: En la tabla se observa una mejoría en el rendimiento del equipo respecto a las dos semanas anteriores. Sin embargo no se alcanzaron los objetivos establecidos en la planeación Junta Semanal 4 El trabajo realizado por los integrantes del equipo TSP en la semana 4 del 15/11/2010 al 21/11/2010 comprende lo siguiente:

17 Los resultados del trabajo realizado son los siguientes: En esta semana, la cuarta, se tuvo un rendimiento similar al de la semana tres. Mucho mejor que el obtenido en las dos primeras. Sin embargo con este rendimiento se requeriría más del doble del tiempo estimado para cubrir los alcances del Proyecto.

18 A partir de esta junta se cambiaron de roles a varios integrantes del equipo y se dio importancia a los suplentes de cada rol. Así como el peso de la responsabilidad al suplente cuando el titular del rol no pudiera desarrollar su función de manera completa Junta Semanal 5 El trabajo realizado por los integrantes del equipo TSP en la semana 5 del 22/11/2010 al 28/11/2010 comprende lo siguiente: Los resultados del trabajo realizado son los siguientes: En la tabla superior se aprecia el efecto de los cambios de Roles de varios integrantes del PSP, pues se estuvo a pocos puntos de alcanzar el objetivo.

19 5.5.6 Junta Semanal 6 El trabajo realizado por los integrantes del equipo TSP en la semana 6 del 29/11/2010 al 05/12/2010 comprende lo siguiente: Los resultados del trabajo realizado son los siguientes: En esta semana, la sexta, aunque faltó poco para llegar al tiempo planeado, se obtuvo un Valor Generado mayor al planeado ya que se completaron varias de las actividades iniciadas en las semanas pasadas Junta Semanal 7 El trabajo realizado por los integrantes del equipo TSP en la semana 7 del 06/12/2010 al 12/06/2010 comprende lo siguiente:

20 Los resultados del trabajo realizado son los siguientes: La séptima semana mostró un equipo trabajando de forma sincronizada, llegando a sus objetivos y manteniendo al día el código mediante el repositorio y los entregables (diseños, documentación, etc) Junta Semanal 8 El trabajo realizado por los integrantes del equipo TSP en la semana 8 del 13/12/2010 al 19/12/2010 comprende lo siguiente:

21 Los resultados del trabajo realizado son los siguientes: En esta semana hubo una votación debido a que el Team Leader dejó su función para integrarse al mercado laboral. Después de la votación resulté electo para tomar el rol de Team Leader con Adriana Rojas como Suplente. Este fue un cambio transparente para desarrollo del Sistema, ya que cada quien conocía sus funciones. Realmente el trabajo importante del Team Leader está en el lanzamiento del proyecto Junta Semanal 9 El trabajo realizado por los integrantes del equipo TSP en la semana 9 del 20/12/2010 al 26/12/2010 comprende lo siguiente: Los resultados del trabajo realizado son los siguientes:

22 Para esta semana se planearon 60 horas ya que iniciaba el periodo vacacional navideño. Se analizó el efecto que pudiera tener este cambio al proyecto y gracias a la estimación del TSP se cambió la planeación sin afectar o poner en riesgo al proyecto Junta Semanal 10 El trabajo realizado por los integrantes del equipo TSP en la semana 10 del 27/12/2010 al 02/01/2011 comprende lo siguiente: En esta semana se realiza la integración de los modulos del proyecto para la entrega de la primera iteración: Modulo de Login Modulo de Seguridad Modulo de Alarmas Modulo de Recetas Modulo de Visitas

23 Se unificó y estandarizó la base de datos. Hubo una baja en el equipo, sin embargo esto no afectó de manera considerable al proyecto. El suplente tomó su rol y sus actividades se divieron entre el equipo. Como se observa en la grafica el comportamiento de las horas actuales en cada semana se acerca mucho a las horas planeadas por semana Junta Semanal 11 El trabajo realizado por los integrantes del equipo TSP en la semana 11 del 03/01/2011 al 09/01/2011 comprende lo siguiente: Los resultados del trabajo realizado son los siguientes:

24 Junta Semanal 12 El trabajo realizado por los integrantes del equipo TSP en la semana 12 del 10/01/2011 al 16/01/2011 comprende lo siguiente: Los resultados del trabajo realizado son los siguientes:

25 En esta semana se lleva a cabo la clausura del proyecto. Se presentó el proyecto con los representantes del GDF y con excepción de algunos cambios de funcionalidad y de contenido quedaron satisfechos con el producto. Se expuso un Servidor de Aplicaciones en internet con el Sistema de Alarmas Médicas asociado a un DNS para su presentación fuera de las instalaciones del Laboratorio de Ingeniería en Software. 6. Objetivos y Metas Alcanzadas Después de 11 semanas de trabajo, el equipo obtuvo los siguientes resultados: Análisis y documentación formal (documentos SRS, DRS y documento de casos de uso), de requerimientos de la arquitectura, documentos de captación, evaluación respuesta e integración de nuevos requerimientos. Análisis y documentación formal para el diseño de alto nivel para las funcionalidades del proyecto, como: documentos de procedimiento, revisión e inspección de HLD. Documentación de diseño detallado para el sistema, como: documento de procedimiento, revisión e inspección de DLD. Documentos de procedimiento y validación de pruebas para el sistema. Diseño de pruebas de sistema para el proyecto. Para obtener los datos que el proyecto generó, el proceso TSP ofrece la especificación SUMMARY en la hoja SUMP, el cual tiene como propósito generar un informe de la productividad obtenida al final de un proyecto TSP, esto permite ofrecer una base para la evaluación y mejora del proceso, así como tener datos históricos para mejorar la planeación de proyectos futuros. 6.1 Análisis de defectos Con respecto a la calidad del proyecto a continuación se presentan las tasas de densidades de introducción y eliminación de defectos por fase. Se pueden observar los resultados que se obtienen en el libro de trabajo con la información de la última consolidación realizada, hay que considerar que se utilizan la unidad número de defectos inyectados y eliminados por hora.

26

27 7. Resultados y Conclusiones. Dentro de los principales resultados obtenidos en el desarrollo del Sistema de Alarmas Médicas se observó que cumple con los requerimientos establecidos de acuerdo al plan aceptado por el cliente. Cubre el 80% de los casos de uso del Sistema de Alarmas Médicas. Al hacer el recorte en los alcances del proyecto quedaron fuera los módulos de Administración. Módulo de Login. Módulo de Visitas del Médico. Módulo de Seguridad y BUS. Módulo de Alarmas Módulo de Recetas Es sencillo de utilizar. Es amigable Es rápido. Considera seguridad. Es robusto. Es un producto bien probado con alta calidad. 8. Recomendaciones. Uno de los problemas sobresalientes fue la baja productividad durante las primeras cuatro semanas, esto se debía a que en forma regular se tenían menos horas de trabajo de las planeadas. La solución fue detectar la fuente del problema y realizar un cambio estratégico en los roles del equipo. Así como canalizar las responsabilidades a los suplentes de los roles. A lo largo de la realización del proyecto uno de los problemas encontrados es que los estándares no contemplaban algunos casos, los cuales se fueron descubriendo a lo largo de la realización del proyecto, como son los estándares de lenguaje web. La solución fue adecuar los estándares de forma periódica, cada vez que se hallaba algo faltante en los estándares se fueron complementando y versionando. Cabe mencionar que otro problema fue la duplicidad y falta de integridad de la información, esto ocurrió en las primeras semanas. Se solucionó cuando el administrador de soporte implemento el repositorio y aunque en un principio tomó más tiempo el adecuarse a su uso, al final fue la herramienta más

28 importante. Finalmente se expuso el repositorio en internet, de esta forma se pudo trabajar haciendo las integraciones de código incluso durante el periodo vacacional. 9. Bibliografía. Introducción al Proceso Software Personal, Watts S. Humphrey. Introduction to the Team Software Process, Watts S. Humphrey. TSP: Leading a Development Team, Watts S. Humphrey.