Ingeniera en Desarrollo de

Software
Facilitador
Mario Alberto Talavera Soto
Javier Chvez Mocios
(Al12535104)
Grupo
DS-DDSE-1502S-B2-001
6 Semestre
Desarrollo de Software en
equipo
Actividad 1
Elementos de la metodologa
TSP

Problema hipottico
Trabaje en la empresa PARYBEL en el Departamento de Control de Calidad; hablando
con el coordinador de Producto terminado ha comentado que el Registro de productos,
proveedores y clientes debera ser digital y no manual, llenando los formatos
correspondientes para tal efecto, considera que es mejor introducir los datos en PCs y
hacer una BD en el Departamento de Sistemas, de esta manera no se trabajara 2 veces:
la primera llenando los formatos de registro y la segunda capturando los datos despus
del registro.
Para tener un control y registro de los productos que ingresan y los que salen una vez
terminado el proceso de produccin.
Elementos
TSP se enfoca en la gestin del equipo de trabajo y PSP en la calidad y la gestin
individual, sobre todo en los desarrolladores de software. Todos los involucrados deben
tener claros los objetivos para poder llegar a la meta en tiempo y forma, pero para lograrlo
se debe asignar en el puesto indicado a cada persona de acuerdo con sus habilidades,
conocimientos y experiencia. Asegurando un buen ambiente de trabajo y que en todo
momento exista comunicacin y retroalimentacin dentro del equipo.
Administracin 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 hipottico planteado se pueden considerar 3
personas como lo propone la metodologa TSP (El lder del equipo, administrador de
desarrollo y planeacin, administrador de calidad de proceso y de soporte).
Integrado por indicadores:
Para comprender la metodologa TSP es necesario saber qu es un proceso de
desarrollo de software (la primera se realiza dentro del segundo). Tambin 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 ms utilizado. El modelo en
cascada indica que todo desarrollo basado en l debe cumplir con las siguientes fases:

Anlisis y definicin 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 cmo quiere que funcione el sistema
solicitado.

 Incluir: Documentacin de Objetivos, Visin, Misin, Roles Puestos y los

requerimientos del sistema a desarrollarse.
Diseo del sistema y el software: los analistas e ingenieros de software
establecen una arquitectura completa del sistema, el diseo nos muestra
cmo va a funcionar y si se va a comunicar con otro sistemas.
Implementacin y prueba de unidades: prcticamente, en esta fase se
desarrolla por completo el sistema.
Integracin 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 versin terminada del sistema, para que la pruebe en el rea
de produccin y verifique el correcto funcionamiento. Si hay nuevos
requerimientos se regresa a la primera fase para realizar las mejoras para el
sistema.
En un sistema de administracin 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 introduccin y guas para el
empleo del estndar. De la 3 a la 9 tratan los requisitos y guas 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 especficos con efectividad, eficiencia y satisfaccin 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, e implica la facilidad de aprendizaje, la ausencia de
errores del sistema o la facilidad del mismo para ser recordado. Las mtricas
definidas son:
Nmero de tareas importantes realizadas
Porcentaje de funciones relevantes utilizadas
Porcentaje de tareas completadas con xito al primer intento
Nmero de referencias a la documentacin
Nmero de llamadas para soporte
Nmero de accesos a la ayuda
Nmero de funciones aprendidas
Porcentaje de usuarios capaces de aprender sus caractersticas
Porcentaje de errores corregidos o reportados por el sistema
Nmero de errores de los usuarios tolerados
Porcentaje de palabras ledas correctamente a una distancia de
visualizacin normal
Eficiencia: recursos empleados (esfuerzo, tiempo, etc.) en relacin con la
exactitud e integridad con la que los usuarios alcanzan los objetivos
especificados. Las mtricas definidas son:

 Eficiencia relativa en comparacin con un usuario experto

Tiempo empleado en el primer intento
Eficiencia relativa en el primer intento
Tiempo empleado en reaprender funciones
Nmero de errores persistentes
Tiempo productivo
Tiempo para aprender caractersticas
Tiempo para reaprender caractersticas
Eficiencia relativa durante el aprendizaje
Tiempo empleado en la correccin de errores
Satisfaccin: un factor subjetivo que implica una actitud positiva en el uso del
producto. Las mtricas definidas son:
Calificacin (por parte del usuario) de su satisfaccin con las
caractersticas importantes
Tasa de uso voluntario del producto
Frecuencia de reutilizacin del producto
Calificacin (por parte del usuario) de la facilidad de aprendizaje
Calificacin (por parte del usuario) del tratamiento de errores
La ISO 924111 recomienda un enfoque basado en procesos para evaluar la usabilidad, a
travs del Diseo 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 gua para alcanzar la calidad en el uso mediante la
incorporacin de actividades de naturaleza iterativa involucradas en el Diseo Centrado
en el Usuario (DCU).
El Diseo Centrado en el Usuario (DCU) lo describe como una actividad multidisciplinar,
que incluye factores humanos y conocimientos y tcnicas de ergonoma con el objetico de
mejorar la efectividad y eficiencia, las condiciones de trabajo y contrarrestar los posibles
efectos adversos de su uso.
Los cuatro principios del Diseo Centrado en el Usuario:
Involucrar activamente a los usuarios
Asignacin adecuada de funciones al sistema y el usuario
Soluciones de diseo iterativas
Diseo multidisciplinar
Las cuatro actividades del Diseo Centrado en el Usuario:
Entender y especificar el contexto de uso
Especificar los requisitos del usuario y de la organizacin
Producir ms de una solucin de diseo candidata
Contrastar los diseos con los requisitos

 La estrategia del equipo est dirigida al desarrollo rpido:

Al utilizar la retroalimentacin entre los miembros del equipo se evita cometer
errores observados en desarrollos pasados.
Proceso operativo apoyado por la formacin y capacitacin 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 especficas que pueden aprenderse
durante el desarrollo del proyecto.
Modelo de coaching:
Mtodo cuyo propsito es instruir y dirigir a las personas con el propsito de que
logren los objetivos y desarrollen habilidades especficas de acuerdo a las
actividades y roles que desempeen 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
metodologa TSP.
TSP est basado en cuatro principios fundamentales:
1. Aprendizaje es mucho ms eficaz si se sigue un proceso claro y bien definido y,
adems, si existe retroalimentacin entre los miembros del equipo. TSP cuenta con
mediciones claras y est diseado para utilizarse de manera cclica, esto permite al
equipo recibir informacin continua sobre su desempeo 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 Coordinacin de zona de la Delegacin
azcapotzalco en INEA DF.
2. Trabajo para que sea productivo es necesario definir objetivos claros, liderazgo y un
ambiente de trabajo agradable.
Objetivo:

Registro de proveedores y clientes debera ser digital y no manual, llenando los formatos
correspondientes para tal efecto, considera que es mejor introducir los datos en PCs y
hacer una BD en el Departamento de Sistemas, de esta manera no se trabajara 2 veces:
la primera llenando los formatos de registro y la segunda capturando los datos despus
del registro.
Adems:
Los objetivos que tiene el TSP son:
Maximizar calidad software, minimizar costos.
Integrar equipos de alto rendimiento independientes que planeen su trabajo,
establezcan metas de sus procesos y planes.
Mostrar a los gerentes como monitorear y motivar a su equipos de trabajo y
como ayudarlos a alcanzar su mxima productividad.
Acelerar la mejora continua de monitoreo.
Proveer de una gua para el mejoramiento en organizaciones maduras
3. Guas apropiadas para dar solucin a los problemas de desarrollo que surjan durante
el tiempo que ste dure.
Basados en Microsoft Dynamics AX 2009 que es software de planeamiento de recursos
empresariales (ERP) de Microsoft Dynamics brinda a los empleados las herramientas
necesarias para conectar y administrar por completo la empresa, desde la administracin
de las finanzas y la cadena de suministro, incluida la fabricacin, hasta las operaciones,
con el conocimiento necesario para toma de decisiones inteligentes. Comenzando con lo
que se necesita hoy y adaptndose sin problemas a medida que cambian las
necesidades, en la nube o en los servidores.
4. Instrucciones deben ser ms claras cuando ya se haba adquirido el conocimiento y la
experiencia en situaciones pasadas.
TSP se basa en el conocimiento y la experiencia sobre equipos de desarrollo de software,
siempre apoyados en la retroalimentacin que permitir tener un mejor manejo y
correccin 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 metodologa 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,
diseo, implementacin, prueba y post mrtem.
Toda la fase de desarrollo de software debe cumplir con un ciclo, el cual ser elegido de
acuerdo al tamao y la complejidad del proyecto. Como ya he mencionado el proyecto se
basar en el modelo de cascada, que cuenta con 5 fases: definicin de requerimientos,
diseo del sistema y de software, implementacin y prueba de unidades, integracin y
pruebas del sistema, funcionamiento y mantenimiento.
La estrategia principal de TSP se basa en la bsqueda 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 Coordinacin de Zona Azcapotzalco de INEA DF, sera 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
Caractersticas del 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 atrados por el grupo y son fieles.

Los valores y metas del grupo son los de sus integrantes
Los miembros estn motivados por hacer lo que puedan por el grupo.
La interaccin 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 atmsfera de creatividad.
El grupo conoce el conformismo constructivo y se sirve de l.
Existe gran motivacin 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 parecen
apropiadas al entender la filosofa de la operacin.
Sus orgenes se deben a las limitaciones que el PSP (Personal Software Process, su
antecesor)tena 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 estimacin y la reduccin de los defectos introducidos en los productos sin afectar a su
productividad, pero PSP slo seenfocaba en las fases de desarrollo de software (diseo y
pruebas unitarias); la aplicacin que loingenieros hicieron del PSP dentro de las empresas
resulto en prcticas no satisfactorias.
Los Roles (responsabilidades) en el equipo son:
Lder 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: Gua al equipo en el diseo y desarrollo del producto.
Gestor de Planificacin: Apoya y gua al equipo en la planificacin 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 estndares
para obtener un trabajouniforme. 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 tecnologa y en las
necesidades de apoyo administrativo. Administra el plan de configuracin.
Es necesario que los ingenieros que usan TSP estn 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

Conclusin
El desarrollo de un software debe ser realizado en equipo, el cual es integrado por
ingenieros informticos, en el cual aplican sus conocimientos para lograr el 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, a los cuales sean asignados responsabilidades que
ayuden a crecer al mismo, por lo cual, los procesos que realicen deben ser basados
conforme a el mtodo TSP (Team Software Process). De ah la importancia sustancial
del TSP.
Bibliografa
Carreras O. Usable accesible. (2015). [En lnea]. Blogspot.
Link:
http://olgacarreras.blogspot.com.es/2012/03/estandares-formales-deusabilidad-y-su.html#cap1.
Microsoft. Dynamics. (2015).
Link: https://www.microsoft.com/es-mx/dynamics/erp.aspx.
Unidad 1. Introduccin TSP. Desarrollo de Software en equipo (TSP). UnADM
Link:
https://unadmexico.blackboard.com/bbcswebdav/pid-288441-dt-content-rid3481516_1/courses/DS-DDSE-1502S-B2-001/U1/Unidad%201.%20Introduccion%20a
%20TSP.pdf.
Unidad 2. Calidad de software. Gestin de proyectos software. (2015).
Link: https://sites.google.com/site/gestiondeproyectossoftware/unidad-2-calidad-desoftware/2-2-1-psp-y-tsp.