DDSE_U1_A1_FEGG

Ingeniería en Desarrollo de

Software

Felipe de Jesús Gutiérrez García (Al12535104) Mario Alberto Talavera Soto Facilitador Grupo DS-DDSE-1502S-B2-001 6º Semestre Desarrollo de Software en equipo Actividad 1 Elementos de la metodología TSP

En esta actividad identificarás los elementos de TSP y la relación que existen entre ellos como un proceso con base en lo estudiado en el Tema 1.1 Proceso de desarrollo de Team Software Process (TSP), para ello, sigue estos pasos: 1. Identifica y redacta un problema hipotético de tu vida cotidiana, escuela, ámbito laboral (si fuera el caso), o con base en tu formación profesional sobre un problema que se presente a un desarrollador de software, al cual puedas dar solución mediante los elementos de la metodología TSP.

2. Identifica en el problema los elementos del proceso de desarrollo de TSP: elementos, principios y objetivos, estrategias y las condiciones para establecer un equipo TSP. 3. En un archivo de texto o presentación de plantillas, elabora un mapa mental donde expongas los elementos gráficos que ejemplifiquen o representen a cada uno de tales elementos, así como la relación que existe entre éstos y la forma en que solucionan el problema. 4. Explica tu mapa mental, menciona cuál es la relación entre los elementos de TSP, así como las imágenes que consideras los ilustran. 5. A continuación, redacta una conclusión acerca de la importancia de esta metodología en el ámbito del desarrollo de software. 6. Integra el desarrollo de tu actividad (el problema, mapa mental y tus conclusiones) en un documento con carátula y los datos de identificación completos, posteriormente guarda tu actividad con el nombre DDSE_U1_A1_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido. 7. Ingresa al Foro y participa respondiendo a los planteamientos y línea de discusión que publique tu Docente en línea mediante el tema abierto por él. Redacta en el cuadro de texto una breve reseña de tu actividad no mayor a cinco renglones y a continuación adjunta tu archivo. Al finalizar da clic en enviar para publicarlo y esté accesible a tus compañeros y docente en línea. 8. Ingresa a la participación de uno de tus compañeros como mínimo, y lee detenidamente su actividad, analízala y realiza un comentario mencionando las aportaciones a tu propia comprensión sobre el tema. 9. Espera y atiende la retroalimentación correspondiente. Revisa la Rúbrica general de participación en foros y los criterios de evaluación de la actividad para que consideres los aspectos a evaluar

Problema hipotético

En la actualidad trabajo para INEA DF (Instituto Nacional para la Educación de los Adultos en el Distrito Federal) en la Coordinación de Zona de la Delegación Azcapotzalco; hablando con el coordinador de la zona en diversas ocasiones ha comentado que el Registro de educandos debería ser digital y ya no manual, es decir, a puño y letra llenando los formatos correspondientes para tal efecto, considera que es mejor introducir los datos en PCs y hacer una BD de la Coordinación, de esta manera no se trabajaría 2 veces: la primera llenando los formatos de registro y la segunda capturando los datos después del registro, de esa forma dice: “Se matan 2 pájaros de un tiro…” . Posteriormente cada asesor podrá ingresar las calificaciones a la BD, toda vez que estas sean publicadas.

Elementos Recordemos que TSP se enfoca en la gestión del equipo de trabajo y PSP en la calidad y la gestión individual, sobre todo en los desarrolladores de software. Es importante que todos los involucrados tengan claros los objetivos para poder llegar a la meta en tiempo y forma, pero para lograrlo se debe asignar a cada persona en el puesto indicado de acuerdo con sus habilidades, conocimientos y experiencia. Así se asegura un buen ambiente de trabajo y que en todo momento exista comunicación y retroalimentación dentro del equipo. 

Administración autodirigida para equipo de trabajo:

Se recomienda el uso de TSP en grupos de 2 a 20 personas y en desarrollos de sistemas que sean a gran escala, para el caso hipotético planteado considero que con 3 personas como lo propone la metodología TSP (El líder del equipo, administrador de desarrollo y planeación, administrador de calidad de proceso y de soporte). 

Integrado por indicadores:

Para comprender la metodología TSP es necesario saber qué es un proceso de desarrollo de software (la primera se realiza dentro del segundo). También denominado ciclo de vida de desarrollo de software, consiste en una estructura que indica las etapas que debe cumplir todo desarrollo de software. Existen muchos modelos de ciclo de vida; TSP puede utilizar cualquiera, pero el de cascada es el más utilizado. El 90% de los que existen en la actualidad están basados en él. Ahora bien, el modelo en cascada indica que todo desarrollo basado en él debe cumplir con las siguientes fases:

 Análisis y definición de requerimientos: es muy importante conocer qué desea el cliente, para esto se hace el levantamiento de requerimientos, que consiste en visitas al cliente para saber cómo quiere que funcione el sistema solicitado. Incluir: Documentación de Objetivos, Visión, Misión, Roles Puestos y los requerimientos del sistema a desarrollarse.  Diseño del sistema y el software: los analistas e ingenieros de software establecen una arquitectura completa del sistema, el diseño nos muestra cómo va a funcionar y si se va a comunicar con otro sistemas.  Implementación y prueba de unidades: prácticamente, en esta fase se desarrolla por completo el sistema.  Integración y pruebas del sistema: aquí se observa ya un producto terminado. Las personas designadas en el área de pruebas y calidad de software revisan que el sistema no tenga fallos; si los hay, se devuelve el producto a los desarrolladores para que hagan las modificaciones correspondientes.  Funcionamiento y mantenimiento: una vez que el sistema fue aprobado por las personas designadas en el área de calidad y pruebas, se le entrega al cliente la primera versión terminada del sistema, para que la pruebe en el área de producción y verifique el correcto funcionamiento. Si hay nuevos requerimientos se regresa a la primera fase para realizar las mejoras para el sistema.



Es un sistema de administración de calidad: se buscará que el software cumpla con las normas de calidad oficiales establecidas por ISO a nivel internacional: ISO 9241 e ISO 13407

Está compuesta por 17 partes. La 1ª y 2ª partes son una introducción y guías para el empleo del estándar. De la 3ª a la 9ª tratan los requisitos y guías relacionadas con el hardware que impactan en el funcionamiento del software. De la 10ª a la 11ª se centran en los aspectos del software. La ISO 9241-11:1998 “Guidance on usability”, define la usabilidad como: La medida con la que un producto se puede usar por usuarios determinados para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso concreto. Por tanto, los tres factores, los tres atributos de calidad son: 

Efectividad: exactitud e integridad con la que los usuarios alcanzan los objetivos especificados, y por tanto implica la facilidad de aprendizaje, la ausencia de errores del sistema o la facilidad del mismo para ser recordado. Las métricas definidas son:           



Número de tareas importantes realizadas Porcentaje de funciones relevantes utilizadas Porcentaje de tareas completadas con éxito al primer intento Número de referencias a la documentación Número de llamadas para soporte Número de accesos a la ayuda Número de funciones aprendidas Porcentaje de usuarios capaces de aprender sus características Porcentaje de errores corregidos o reportados por el sistema Número de errores de los usuarios tolerados Porcentaje de palabras leídas correctamente a una distancia de visualización normal

Eficiencia: recursos empleados (esfuerzo, tiempo, etc.) en relación con la exactitud e integridad con la que los usuarios alcanzan los objetivos especificados. Las métricas definidas son:         

Eficiencia relativa en comparación con un usuario experto Tiempo empleado en el primer intento Eficiencia relativa en el primer intento Tiempo empleado en reaprender funciones Número de errores persistentes Tiempo productivo Tiempo para aprender características Tiempo para reaprender características Eficiencia relativa durante el aprendizaje

 Tiempo empleado en la corrección de errores

Satisfacción: un factor subjetivo que implica una actitud positiva en el uso del producto. Las métricas definidas son:  Calificación (por parte del usuario) de su satisfacción con las características importantes  Tasa de uso voluntario del producto  Frecuencia de reutilización del producto  Calificación (por parte del usuario) de la facilidad de aprendizaje  Calificación (por parte del usuario) del tratamiento de errores La ISO 9241‐11 recomienda un enfoque basado en procesos para evaluar la usabilidad, a través del Diseño Centrado en el Usuario (DCU). Por ello la ISO 9241 debe aplicarse en conjunto con la ISO 13407. ISO 13407:1999. Human centred design processes for interactive systems. La ISO 13407 proporciona una guía para alcanzar la calidad en el uso mediante la incorporación de actividades de naturaleza iterativa involucradas en el Diseño Centrado en el Usuario (DCU). El Diseño Centrado en el Usuario (DCU) lo describe como una actividad multidisciplinar, que incluye factores humanos y conocimientos y técnicas de ergonomía con el objetico de mejorar la efectividad y eficiencia, las condiciones de trabajo y contrarrestar los posibles efectos adversos de su uso.

Describe los cuatro principios del Diseño Centrado en el Usuario:    

Involucrar activamente a los usuarios Asignación adecuada de funciones al sistema y el usuario Soluciones de diseño iterativas Diseño multidisciplinar Y las cuatro actividades del Diseño Centrado en el Usuario:

   

Entender y especificar el contexto de uso Especificar los requisitos del usuario y de la organización Producir más de una solución de diseño candidata Contrastar los diseños con los requisitos



La estrategia del equipo está dirigida al desarrollo rápido: Al utilizar la retroalimentación entre los miembros del equipo se evita cometer errores observados en desarrollos pasados.



Proceso

operativo

apoyado

por

la

formación

y

capacitación

proporcionadas al equipo, y dirigido a toda el área de desarrollo. Aun cuando los desarrolladores ya cuenten con la experiencia y la capacidad de ejecutar el trabajo, siempre hay cosas nuevas y específicas que pueden aprenderse durante el desarrollo del proyecto. 

Modelo de coaching: Método cuyo propósito es instruir y dirigir a las personas con el propósito de que logren los objetivos y desarrollen habilidades específicas de acuerdo a las actividades y roles que desempeñen dentro del proyecto. Principios y Objetivos

El objetivo de TSP es mejorar y asegurar la calidad y productividad en un proyecto de desarrollo de software. Para ayudar a alcanzar los costos y tiempos planeados, los objetivos del proyecto los establecen los ingenieros de software, de acuerdo con la metodología TSP. TSP está basado en cuatro principios fundamentales: 1. El aprendizaje es mucho más eficaz si se sigue un proceso claro y bien definido y, además, si existe retroalimentación entre los miembros del equipo. TSP cuenta con mediciones claras y está diseñado para utilizarse de manera cíclica, esto permite al equipo recibir información continua sobre su desempeño y avances dentro del proyecto.

Desde luego que será importante trabajar con calidad el PSP de los integrantes del equipo que desarrollará el software para la Coordinación de zona de la Delegación azcapotzalco en INEA DF. 2. Para que el trabajo sea productivo es necesario definir objetivos claros, liderazgo y un ambiente de trabajo agradable. Objetivo: El Registro de educandos debe ser digital y ya no manual, es decir, a puño y letra llenando los formatos correspondientes para tal efecto, considerar que es mejor introducir los datos en PCs y hacer una BD de la Coordinación, de esta manera no se trabajaría 2 veces: la primera llenando los formatos de registro y la segunda capturando los datos después del registro, de esa forma dice: “Se matan 2 pájaros de un tiro…”. Además: Los objetivos que tiene el TSP son:  Maximizar calidad software, minimizar costos.  Integrar equipos independientes de alto rendimiento que planeen su trabajo, establezcan metas y san sueños de sus procesos y planes.  Mostrar a los gerentes como monitorear y motivar a sus equipos de trabajo y como ayudarlos a alcanzar su máxima productividad.  Acelerar la mejora continua de monitoreo.  Proveer de una guía para el mejoramiento en organizaciones maduras 3. Es importante contar con guías apropiadas para dar solución a los problemas de desarrollo que surjan durante el tiempo que dure éste. Basados en Microsoft Dynamics AX 2009 que es software de planeamiento de recursos empresariales (ERP) de Microsoft Dynamics brinda a sus empleados las herramientas que necesitan para conectar y administrar por completo su empresa, desde la administración de las finanzas y la cadena de suministro, incluida la fabricación, hasta las operaciones, con el conocimiento que necesita para tomar decisiones inteligentes. Comience ahora con aquello que necesita hoy y adáptese sin problemas a medida que cambien sus necesidades, en la nube o en sus servidores. 4. Las instrucciones son más claras cuando ya se había adquirido el conocimiento y la experiencia en situaciones pasadas. TSP se basa en el conocimiento y la experiencia sobre equipos de desarrollo de software, es decir, siempre apoyados en la retroalimentación o feedback que permitirá tener un mejor manejo y corrección de posibles errores surgidos en otros proyectos. Estrategias de TSP

Las estrategias son actividades bien estructuradas y planificadas para lograr el objetivo o los objetivos que se tengan planeados. La estrategia de TSP es muy importante para que esta metodología se implemente de manera correcta, ya que indica la mejor forma de aplicar los procesos que conforman TSP en todo el ciclo de vida de desarrollo del proyecto, y en cada una de sus etapas. TSP se conforma de ocho procesos: lanzamiento, estrategia, plan, requerimientos, diseño, implementación, prueba y post mórtem. Toda la fase de desarrollo de software debe cumplir con un ciclo, el cual será elegido de acuerdo al tamaño y la complejidad del proyecto. Como ya he mencionado el proyecto se basará en el modelo de cascada, que cuenta con 5 fases: definición de requerimientos, diseño del sistema y de software, implementación y prueba de unidades, integración y pruebas del sistema, funcionamiento y mantenimiento. La estrategia principal de TSP se basa en la búsqueda de la mejor manera de introducir sus ocho procesos dentro de cada fase del ciclo de vida del proyecto, que para el caso de la Coordinación de Zona Azcapotzalco de INEA DF, sería el modelo en cascada. Pero se debe considerar siempre que se van a utilizar los ocho procesos, pero se trabajará con, lo que se haya desarrollado en el ciclo anterior. Equipo TSP

Características para el equipo que se conformará para desarrollar el proyecto:              

Miembros expertos en papeles de liderazgo y pertenencia. Relaciones tranquilas y establecidas entre los miembros. Los miembros se sienten atraídos por el grupo y son fieles. Los valores y metas del grupo son los de sus integrantes Los miembros están motivados por hacer lo que puedan por el grupo. La interacción y toma de decisiones tiene lugar en el ambiente adecuado. El grupo desea ayudar a cada miembro a adquirir su pleno El grupo desea ayudar a cada miembro a adquirir su pleno potencial. Cada miembro acepta con gusto y sin resentimiento las metas y normas establecidas. Los miembros se prestan ayuda mutua cuando es necesaria o recomendable. Existe una atmósfera de creatividad. El grupo conoce el “conformismo constructivo” y se sirve de él. Existe gran motivación para iniciar y recibir las comunicaciones. Los miembros son flexibles y adaptables en sus metas y actitudes. Los miembros se sienten seguros al tomar decisiones que les Los miembros se sienten seguros al tomar decisiones que les parecen apropiadas al entender la filosofía de la operación.

Sus orígenes se deben a las limitaciones que el PSP (Personal Software Process, su antecesor) tenía en el ámbito industrial. PSP resultó muy efectivo para que los ingenieros pudiesen tener el control de su proceso personal mediante la mejora de sus habilidades de estimación y la reducción de los defectos introducidos en los productos sin afectar a su productividad, pero PSP sólo se enfocaba en las fases de desarrollo de software (diseño y pruebas unitarias); la aplicación que lo ingenieros hicieron del PSP dentro de las empresas resulto en prácticas no satisfactorias. Los Roles (responsabilidades) en el equipo son:  Líder del Equipo: Dirige al equipo, se asegura que todos reporten sus datos de los procesos y completen su trabajo tal y como se planeó. Realiza los reportes semanales del avance del equipo.  Gestor de desarrollo: Guía al equipo en el diseño y desarrollo del producto.  Gestor de Planificación: Apoya y guía al equipo en la planificación y seguimiento del trabajo.  Gestor de Calidad/Proceso: Apoya al equipo en definir sus necesidades acerca del proceso y a establecer y administrar el plan de calidad. Genera estándares para obtener un trabajo uniforme. Modera las inspecciones y revisa cada artefacto generado.  Administrador de Requerimientos/Soporte: Dirige al equipo en el desarrollo de requerimientos de software y ayuda a dar a conocer la tecnología y en las necesidades de apoyo administrativo. Administra el plan de configuración Es necesario que los ingenieros que usan TSP estén formados en PSP. Con TSP, los equipos encuentran y reparan defectos en etapas tempranas del proceso de desarrollo, esto reduce de manera importante el tiempo de pruebas. Mapa Mental

TSP Creación de equipo Compromiso Calidad propia Objetivos claros Plan propio Plan detallado Roles Recursos de equipo

PSP Planes personales Método de planeación Valor agregado Métricas de calidad Procesos definidos

Disciplina ingenieril

TSP trabajo en equipo Prioridad en calidad Costo de calidad Seguir el proceso Revisión status y calidad Comunicación

Disciplina de administración

Disciplina de equipo

Equipo Integrado

Conclusión

El desarrollo de un software siempre es hecho en equipo que lo integran ingenieros informáticos donde aplican sus conocimientos para lograr tal objetivo. Este grupo debe

tener asignado responsables y objetivos para lograr su fin. Para lograr que este equipo pueda trabajar de una forma ordenada y precisa, es necesario que tenga miembros capaces y experimentados, que a los cuales sean asignados responsabilidades que ayuden a crecer a este equipo, por lo cual, los procesos que realicen deben ser basados conforme a el método TSP (Team Software Process). De ahí la importancia sustancial del TSP. Bibliografía Carreras O. Usable accesible. (2015). [En línea]. Blogspot. Disponible en: http://olgacarreras.blogspot.com.es/2012/03/estandares-formales-deusabilidad-y-su.html#cap1 [2015, 07 de octubre]. Microsoft. Dynamics. (2015). [En línea]. Página Web. Disponible en: https://www.microsoft.com/es-mx/dynamics/erp.aspx [2015, 07 de octubre]. Unidad 1. Introducción TSP. Desarrollo de Software en equipo (TSP). UnADM. (2015). [En línea]. Pdf. Disponible en: https://unadmexico.blackboard.com/bbcswebdav/pid-288441-dt-content-rid3481516_1/courses/DS-DDSE-1502S-B2-001/U1/Unidad %201.%20Introduccion%20a%20TSP.pdf [2015, 07 de octubre]. Unidad 2. Calidad de software. Gestión de proyectos software. (2015). [En línea]. Página Web. Disponible en: https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidadde-software/2-2-1-psp-y-tsp [2015, 07 de octubre].