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
TSP trabajo en equipo
Planes personales
Prioridad en calidad
Método de planeación
Costo de calidad
Valor agregado
Seguir el proceso
Métricas de calidad
Revisión status y calidad
Procesos definidos
Comunicación

Disciplina Disciplina de Disciplina

ingenieril administración 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-de-
usabilidad-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-rid-
3481516_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-calidad-
de-software/2-2-1-psp-y-tsp
[2015, 07 de octubre].