• Author / Uploaded
• mexicano98

Citation preview

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Ingeniería en Desarrollo de Software 6º Semestre

Programa de la asignatura: Desarrollo de software en equipo (TSP)

Unidad 1. Introducción a TSP

Clave: 15143636

Universidad Abierta y a Distancia de México

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Índice 1. Introducción a TSP ......................................................................................................... 2 Presentación de la unidad .................................................................................................. 2 Propósitos .......................................................................................................................... 3 Competencia específica ..................................................................................................... 3 1. 1. Proceso de Desarrollo de Team Software Process (TSP) .......................................... 3 1.1.1. Principios y objetivos de TSP ................................................................................... 6 1.1.2. Estrategia de TSP .................................................................................................... 7 1.1.3. Equipo TSP .............................................................................................................. 8 1.2. Estructura del Team Software Process (TSP) ............................................................. 9 1.2.1. Disciplina de equipo ............................................................................................... 11 1.2.2. Disciplina de administración ................................................................................... 12 1.2.3. Disciplina de ingeniería........................................................................................... 12 1.3. Ciclo de vida del Team Software Process (TSP) ....................................................... 13 1.3.1. Fase de lanzamiento .............................................................................................. 14 1.3.2. Fase de estrategia .................................................................................................. 22 1.3.3. Fase de planeación ................................................................................................ 25 1.3.4. Fase de requerimientos .......................................................................................... 26 1.3.5. Fase de diseño ....................................................................................................... 27 1.3.6. Fase de implementación......................................................................................... 28 1.3.7. Fase de pruebas..................................................................................................... 29 1.3.8. Fase post mórtem................................................................................................... 31 Cierre de la unidad ........................................................................................................... 33 Para saber más ................................................................................................................ 34 Fuentes de consulta ......................................................................................................... 34

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

1

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

1. Introducción a TSP Presentación de la unidad Bienvenido a la asignatura Desarrollo de software en equipo TSP (Team Software Process), la cual forma parte del octavo semestre de la igeniería en Desarrollo de Software. La metodología PSP (Personal Software Process) está orientada a un contexto individual del ingeniero en desarrollo de software, mientras que el TSP se enfoca en los equipos y roles de trabajo. Es necesario contar con la metodología PSP, porque guía a cada individuo a alcanzar sus objetivos personales como parte de un proyecto de desarrollo de software, pero sin olvidar que lo más importante es la colaboración, la retroalimentación entre los miembros del equipo de desarrollo y, por supuesto, conseguir los objetivos trazados al inicio del proyecto. En la Unidad 1. Introducción a TSP, aprenderás los elementos, objetivos y principios en los cuales se basa esta metodología, así como su estrategia y estructura, que se aplica a todo el ciclo de desarrollo del proyecto.

Relación entre PSP y TSP Contenido de la imagen basado en Tuya, Javier y otros, (2007). Imagen basada en Dreamstime (2013).

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

2

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Propósitos Al término de esta unidad lograrás:   

Identificar los elementos y objetivos que componen la metodología TSP. Comprender la relación que existe con PSP. Conocer la estructura TSP.

 Comprender la estrategia que sigue TSP para el desarrollo de sistemas de calidad.

Competencia específica 

Identificar la metodología Team Software Process (TSP) para comprender los conceptos principales y el ciclo de vida a partir del marco contextual del desarrollo de software.

1. 1. Proceso de Desarrollo de Team Software Process (TSP) El Team Software Process (TSP) fue creado por Watts Humphrey en 1996. Es un proceso y una metodología de desarrollo de software en equipo, que guían a los ingenieros para asegurar la calidad en las diferentes etapas del ciclo de vida de desarrollo de software y, principalmente, la productividad de los equipos de trabajo integrados por ingenieros, administradores y desarrolladores de software (Gomez y Ania, 2008). Cuando se habla de objetivos de un proyecto de desarrollo de software, hay uno en particular que se debe cumplir: el tiempo del proyecto puede rebasar lo planeado. Para esto, implementar la metodología TSP dentro de una organización ayuda a tener una métrica exacta de costos. También la experiencia de proyectos pasados cuenta mucho. 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. 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 Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

3

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

al cliente para saber cómo quiere que funcione el sistema solicitado. Después de esto, los analistas e ingenieros de software crean las especificaciones del sistema. En esta fase se integra la documentación requerida para el arranque del proyecto, la cual cambiará de acuerdo con la metodología propuesta; pero nunca deben de faltar los documentos donde se muestren los objetivos, visión, roles, puestos y 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 primer fase para realizar las mejoras para el sistema (Sommerville, 2006).

En la siguiente figura se muestra una representación del modelo en cascada:

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

4

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Definición de requerimientos

Diseño del sistema y del software Implementación y prueba de unidades Integración y prueba del sistema

Funcionamiento y mantenimiento Figura 1. Modelo en cascada (Sommerville, 2006).

Se dice que el TSP es un proceso de desarrollo porque cumple con esta estructura, pero con fases propias que más adelante se explicarán. Se recomienda el uso de TSP en grupos de 2 a 20 personas y en desarrollos de sistemas que sean a gran escala. El TSP se centra en la administración de proyectos, en la construcción de los equipos de trabajo de acuerdo a los roles y en el perfil de cada persona que se necesita para los distintos puestos dentro del proyecto. En un proyecto de desarrollo de software, se selecciona la cantidad de personal requerida para los puestos de acuerdo a lo robusto que sea el sistema, pero los puestos necesarios que propone la metodología TSP son: líder de equipo, administrador de desarrollo, administrador de planeación, administrador de calidad de proceso y administrador de Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

5

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

soporte, cargos que se explicarán con más detalle en el Tema 1.3. Ciclo de vida del Team Software Process. TSP se enfoca en la gestión del equipo de trabajo, y el PSP en la calidad, pero no de todo el proceso de desarrollo ni del equipo, sino de la calidad y la gestión individual, especialmente en los desarrolladores de software, para tener una métrica exacta de su productividad y, con base en esto, mejorar la calidad en su trabajo. Piattini (2011) afirma que el TSP se basa en los siguientes elementos:   







Administración autodirigida para equipos de trabajo. Como ya se mencionó, a comparación de PSP, TSP está totalmente orientado a equipos de trabajo. Está integrado por indicadores: éstos señalan los pasos a realizar y el orden a seguir. Es un sistema de administración de calidad: TSP tiene como principal propósito asegurar la calidad en el desarrollo de software y, de este modo, conseguir la satisfacción total del cliente. 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.

Un punto muy importante de TSP es lograr la comunicación entre los miembros del equipo de desarrollo del proyecto, ya que cada individuo tiene un estilo propio para llevar a cabo las tareas. Sin embargo, el objetivo siempre será asegurar la calidad durante todo el proceso de desarrollo de software.

1.1.1. Principios y objetivos de TSP 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. 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 Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 6

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

buen ambiente de trabajo y que en todo momento exista comunicación y retroalimentación dentro del equipo. TSP está basado en cuatro principios fundamentales (Tuya, J. y otros, 2007): 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. 2. Para que el trabajo sea productivo es necesario definir objetivos claros, liderazgo y un ambiente de trabajo agradable. 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. 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. Hasta ahora se ha revisado el significado de TSP y sus diferencias con PSP; pudiste observar que aunque las dos buscan la calidad, TSP se enfoca en los equipos de trabajo de desarrollo de software, y PSP en cada una de las personas lo integran. También se revisó lo correspondiente al significado del ciclo de vida de desarrollo de software como un proceso; se explicó a detalle el modelo en cascada y cada una de sus fases; por último, los principios y objetivos que tiene esta metodología. En el siguiente subtema se revisará la estrategia de TSP, con la cual podrás identificar la importancia de los equipos de trabajo, así como las estrategias para conformar uno para implementar esta metodología de desarrollo de software dentro de una organización.

1.1.2. Estrategia 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, los cuales se explicarán con más detalle en el Tema 1.3. Ciclo de Vida del Team Software Process (TSP). Toda la fase de desarrollo de software Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

7

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

debe cumplir con un ciclo, el cual será elegido de acuerdo al tamaño y la complejidad del proyecto. Por ejemplo, tomemos el modelo en cascada, el cual cuenta con cinco fases que son: 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 en este caso sería el modelo en cascada (Piattini, 2011). Siempre se inicia con una junta donde los líderes e ingenieros de software presentan los objetivos del proyecto a cada uno de los miembros del equipo; posteriormente, se aplican los otros siete restantes procesos. En la siguiente fase (diseño del sistema y de software, según el modelo cascada) se aplican los mismos ocho procesos, pero se trabaja sobre lo que ya se haya desarrollado en el ciclo anterior. Con esto se logra que el producto que, en este caso sería el software que se está desarrollando, aumente su funcionalidad. Como pudiste darte cuenta, la estrategia de TSP indica que no importa el modelo de ciclo de vida que se elija para el desarrollo de software, siempre se van a utilizar los ocho procesos que nos marca esta metodología, y se van a implementar en cada una de las fases de desarrollo del ciclo de vida del software a desarrollar. En el siguiente capítulo aprenderás las principales características que se requieren para integrar los equipos de trabajo, de acuerdo con algunas condiciones señaladas por el TSP.

1.1.3. Equipo TSP En el contexto de TSP (metodología creada para los grupos de trabajo y la retroalimentación), para que un equipo se forme hay algunas condiciones que deben crearse, las cuales se mencionan a continuación (Piattini, 2011):   



Debe estar formado por al menos dos personas. Los integrantes del equipo deben trabajar en conjunto para lograr el objetivo del proyecto. Todos los miembros del equipo deben de apoyarse mutuamente. Para lograr el objetivo principal del proyecto se necesita de la ayuda y la colaboración de todos los miembros del equipo. Cada persona tiene un rol específico (establecidos por los ingenieros de software y administradores del proyecto), el cual debe seguir porque es una guía de sus deberes.

Para conformar un equipo efectivo de ingenieros se necesita que: Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

8

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

    

Los integrantes estén cualificados con las capacidades y habilidades propias de su rol. El objetivo del proyecto debe ser claro, realista y bien definido. Los recursos que se asignen al equipo deben de ser acordes al trabajo que van a realizar. Los integrantes deben de estar motivados y comprometidos para lograr el objetivo. Los miembros deben de ser disciplinados y responsables en su trabajo.

Para formar el equipo de trabajo se deben de dar las siguientes condiciones:          

El equipo debe formar una estrategia de trabajo en la que todos estén de acuerdo. Establecer objetivos en común y definir los roles por parte de los miembros del equipo. Definir procesos en común. Todos los miembros deben de participar en la creación de un plan. El equipo deberá negociar el plan con la administración. La administración revisará y aceptará el plan realizado por el equipo. Los miembros deben de realizar su trabajo de acuerdo al plan. Deberá existir comunicación frecuente entre los miembros del equipo. Todos los integrantes deberán cooperar y estar comprometidos con un objetivo en común. Los líderes deberán de obtener feedback (retroalimentación) y deben de buscar liderazgo que mantenga motivados a los miembros del equipo.

En este subtema se revisó lo referente a las condiciones necesarias para crear equipos de trabajo adecuados para implementar la metodología TSP. En la siguiente actividad identificarás los elementos de la metodología TSP y la relación que existe entre ellos.

1.2. Estructura del Team Software Process (TSP) TSP es una estructura porque se conforma de partes y procesos que se encuentran relacionados, además indican las acciones o actividades a ejecutar y el orden en el cual deben desarrollarse. Esto es muy importante en la implementación de TSP, ya que indica los pasos a seguir al momento de crear el equipo, trabajar y ejecutar acciones individuales. Una de las más grandes ventajas de TSP consiste en que proporciona una estructura bien definida para guiar a los ingenieros y administradores, con el objetivo de llevar por buen camino al equipo de trabajo. Esta estructura también especifica los pasos y medidas necesarios para formar un equipo eficaz y un buen ambiente de trabajo.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

9

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

En la siguiente figura se muestra la estructura de TSP: TSP

TSP

trabajo en

creación

equipo

del equipo

    

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

Disciplina ingenieril

       

Compromisos Planes agresivos Calidad propia Objetivos del proyecto Plan propio Plan detallado Roles Roles del equipo

Disciplina de equipo

    

Prioridad en la calidad Costo de la calidad Seguir el proceso Revisión de status y calidad Comunicación

Disciplina de administración

Equipos integrados Figura 2 Estructura de TSP (Gomez y Ania, 2008).

En los recuadros de la parte superior de la imagen se encuentra la metodología que va a usarse. Por ejemplo, la disciplina ingenieril hace referencia a PSP ya que se trata del trabajo y habilidades que cada miembro del equipo debe tener. En las siguientes dos disciplinas, de equipo y de administración, se crean los equipos y se ejecuta el trabajo; para ello, se utiliza la metodología TSP. El conjunto de las tres da como resultado equipos de trabajo bien conformados e integrados. Cada una nos muestra los pasos (en TSP se llaman fases) bien definidos y estructurados que van a ejecutarse; se forman equipos integrados hasta que hayan completado al 100% todas sus fases. A continuación se explicarán cada una de las disciplinas que conforman la estructura de TSP.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

10

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

1.2.1. Disciplina de equipo En este subtema aprenderás la disciplina de equipo con sus respectivas fases. La disciplina de equipo consiste en una serie de reglas que deben llevarse a cabo a lo largo del proceso de desarrollo de software. Estas reglas también pueden ser vistas como fases dentro de esta disciplina y a continuación se explicarán a detalle cada una: 















Compromiso: todos los miembros deberán tener bien claro cuáles son los compromisos con la organización y con el cliente, de acuerdo a los objetivos planteados al inicio del proyecto. Planes agresivos: son acciones planeadas y bien estructuradas para ejecutarse rápidamente y lograr objetivos a corto plazo; proporcionan el desempeño eficiente de los miembros del equipo sin que se sientan presionados y reduzcan su productividad. Calidad propia: cada desarrollador debe colocar su propio sello al desarrollo en las pruebas a su cargo, las cuales se realizan de acuerdo al funcionamiento que debe tener el módulo del sistema que estén desarrollando. Es muy importante hacer énfasis en que las pruebas son provisionales, porque las personas de calidad en la fase de pruebas del ciclo de vida del proyecto las hacen de una manera más detallada, con protocolos y estándares bien definidos por el administrador de calidad de proceso. Esto se verá más a detalle en la unidad 3. Gestión en TSP. Objetivo del proyecto: el equipo debe dar su punto de vista de los objetivos que se plantean al inicio del proyecto, y así tener una visión más clara acerca de a dónde se desea llegar. Plan propio: cada equipo debe de tener su propio plan, establecido por los administradores al inicio del proyecto. Aprenderás cómo hacer uno en la unidad 2. implementación de TSP. Plan detallado: en la documentación que se crea al inicio del proyecto (donde se exponen los objetivos, los requerimientos del sistema, etc.) debe haber un plan detallado sobre las actividades a realizarse a través de todo el ciclo de vida del proyecto, y sobre los riesgos que puedan surgir durante el desarrollo del software. Todo esto lo veremos con más detalle en el subtema 2.2. Ejecutar el trabajo en equipo. Roles: cada miembro del grupo debe tener bien claro cuál es su rol dentro del equipo; los roles se asignan con base en las capacidades y cualidades de cada persona, y son establecidos por los ingenieros y administradores al inicio del proyecto. Recursos del equipo: el equipo debe de utilizar, de manera correcta, los recursos proporcionados por parte de la empresa que solicita el proyecto de software, por lo que contrata o integra un equipo TSP.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

11

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

En conclusión, puede decirse que la disciplina de equipo indica reglas muy precisas que guían las actividades para que se logren los objetivos del proyecto.

1.2.2. Disciplina de administración

Esta disciplina muestra la forma en que los administradores del proyecto deben guiar al grupo para cumplir los objetivos del proyecto de software. 









Prioridad de calidad: en todo desarrollo de software, el principal objetivo debe ser la calidad y la satisfacción del cliente. Esta calidad se logra mediante una buena planeación y ejecución al pie de la letra la metodología TSP. Costo de la calidad: de acuerdo a la calidad será el coste. Debe asegurarse que los costos sean adecuados para llegar a la calidad planeada al inicio del proyecto, adecuados al tiempo y de acuerdo con lo robusto del sistema que vaya a desarrollarse. Cabe mencionar que esta planeación se hace al inicio del proyecto por parte de los ingenieros y los administradores. Seguir el proceso: al inicio del proyecto se establecen procesos bien definidos, y los administradores deben de revisar se cumplan. Esto se aprenderá en el tema 1.3. Ciclo de vida del Team Software Process (TSP). Revisión de status de calidad: para este fin, tanto los desarrolladores como los administradores utilizan plantillas y reportes, que tú aprenderás a hacer en la unidad 3. Gestión en TSP. Comunicación: la comunicación entre los miembros del equipo no solo permite que se llegue a los objetivos deseados, también sirve para tener un buen ambiente de trabajo y llevar a cabo la retroalimentación que ayuda a no repetir errores ya cometidos, en el mismo proyecto o en anteriores.

Como se puede notar, la disciplina de la administración se basa en los administradores y en la forma de medir el nivel de calidad del desarrollo del proyecto. En el siguiente subtema conocerás la disciplina que está orientada a las personas que conforman el equipo de desarrollo de un proyecto.

1.2.3. Disciplina de ingeniería Esa disciplina se basa totalmente en PSP, ya que es necesario medir la calidad respecto a las habilidades individuales de los miembros del equipo, quienes deben saber que forman parte del grupo y, al mismo tiempo, ser responsables de sus actividades de acuerdo a los roles que se les hayan asignado. La disciplina de ingeniería se conforma por las siguientes actividades: Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 12

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

   



Planes personales: cada miembro del equipo debe conocer su rol dentro del proyecto y estar consciente de su responsabilidad para que el objetivo se cumpla. Método de planeación: cada miembro debe manejar y planear correctamente sus tiempos y las responsabilidades que tiene. Valor agregado: cada miembro del equipo aportará su experiencia y conocimiento en el desarrollo de los proyectos. Métricas de calidad: las métricas son una referencia exacta para medir el nivel de algo en específico. En este caso sirven para controlar, medir, monitorizar, predecir y probar el desarrollo de software. Por ejemplo, una métrica podría ser una plantilla donde muestre los avances que ha tenido el proyecto mes con mes. Esta fase se explicará con más detalle en el tema 3.2. Diagnóstico: Métricas de calidad versus trabajo realizado. Procesos definidos: muestran a los miembros del equipo un panorama general para comenzar con el desarrollo del software.

Es muy importante entender con claridad cuál es la estructura de TSP y su objetivo en cada disciplina. Como pudiste aprender, las disciplinas son como recetas de cocina que dicen qué acciones tomar en todas y cada una de las fases de desarrollo del proyecto. En el siguiente tema aprenderás la forma en que está estructurado el ciclo de vida de la metodología TSP.

1.3. Ciclo de vida del Team Software Process (TSP) El ciclo de vida del TSP se conforma de una serie de ciclos (puede ir desde uno hasta un número indefinido, dependiendo de la magnitud del proyecto), organizada en ocho fases. Éstas comienzan con los requerimientos del producto de software, donde se establece lo que se quiere lograr y comienza con la creación de diseños detallados del software, que es revisado por todo el equipo. Posteriormente, dicho diseño se convierte en código, el cual también es revisado y analizado para realizar las pruebas pertinentes; finalmente se analiza la calidad del producto de software terminado. Es entonces cuando el ciclo de vida del TSP llega a su fin (Nord, R; McHale, J., & Bachmann, F., 2010). En la aplicación del ciclo de vida del proceso de software de equipo de TSP, se definen las fases del desarrollo de software que se realizarán por parte del equipo de trabajo, las cuales describen una serie de pasos para ayudar a alcanzar productos de calidad. La metodología del TSP contempla ocho faces de desarrollo bien definidas (ver figura 1.1), que deben llevarse a cabo de manera cíclica durante el proceso de desarrollo de software. Es preciso mencionar que el equipo de trabajo realizará el proceso de desarrollo de software y de control de la calidad; sin embargo, el encargado de revisar que esto se cumpla es el administrador de calidad dentro de los roles del equipo, lo que se explicará en el subtema Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

13

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

1.3.1. Fase de lanzamiento. Cada una de las fases describe las actividades que les son propias, y que se explican a continuación (Humphrey, 1999).

Lanzamiento Estrategia Planeación Requerimientos Diseño Implementación

Pruebas Post mórtem Figura 3. Fases del ciclo de vida del TSP (Humphrey, 1999).

1.3.1. Fase de lanzamiento En este subtema se revisarán las directrices a seguir para dar comienzo con el desarrollo del producto de software. Dentro de la fase de lanzamiento se establecen las metas y objetivos del equipo de proyecto; también se determinan los roles y responsabilidades que desempeñarán cada uno de los integrantes, y la manera idónea para forma el equipo de trabajo. Las metas y objetivos se llevan a cabo de forma individual y en equipo, en la tabla 1 observarás un ejemplo de los objetivos planteados de manera individual. Es de gran importancia definir los objetivos de tal manera que sean medibles, y así determinar la calidad del producto generado (ver tabla 1). Deben establecerse objetivos ambiciosos para los miembros del equipo, pero sin alejarse de la realidad (ser un miembro eficiente del cooperativo, realizar un trabajo personal disciplinado, etc.). Poner los objetivos por escrito ayudará de manera significativa al equipo para determinar, de forma periódica, hasta qué grado fue cumplido cada objetivo planteado. Todos los miembros del equipo deben estar comprometidos con los objetivos programados y participar activamente con él. Tabla 1. Objetivos propuestos para los miembros del equipo y sus indicadores Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

14

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Objetivos Ser un miembro del equipo cooperativo y efectivo

Realizar un trabajo personal disciplinado

Planear y dar seguimiento al trabajo personal

Hacer productos de calidad

Indicador 1 El promedio de la evaluación de cada miembro del equipo, efectuada por los pares acerca de la disposición a ayudar y la aportación del trabajo, debe ser mayor a 3 (ésta es una medición de la eficacia y eficiencia que el equipo establece, determina, y califica). El porcentaje de los datos personales (desempeño, eficacia, etcétera) registrados debe ser 100%.

Indicador 2

Indicador 3

Indicador 4

La densidad de defectos encontrados durante la prueba de unidad debe

La densidad de defectos encontrados durante y después de la prueba de

El promedio de la evaluación de cada miembro del equipo, efectuada por los pares acerca de la contribución general hecha al equipo, debe ser mayor a 3.

El porcentaje de semanas registradas en el documento semanal debe ser 100%.

El porcentaje de las tareas del proyecto con plan y datos reales registrados en forma correspondiente debe ser 100%. El porcentaje de La densidad de defectos defectos encontrados encontrados antes de la prime durante la compilación compilación debe ser mayor debe ser menor El porcentaje de los datos del proyecto personal registrados en las formas correspondientes debe ser 100%.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

15

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

a 70%.

a 10/KLOC.

ser menor a 5/KLOC.

unidad debe ser 0.

Gómez y Ania, 2008 Tabla 2. Objetivos propuestos por el equipo y sus indicadores Objetivos Indicador 1 Indicador 2 El porcentaje de La cantidad de defectos defectos Crear producto de encontrados antes encontrados en la calidad de la primera prueba del sistema compilación debe debe ser 0. de ser 80%. Llevar a cabo un proyecto productivo y bien administrado

El error en la estimación del producto debe ser menor a 20%.

Terminar el proyecto a tiempo

El total de días de retraso o adelanto para completar el ciclo debe ser menor a 4.

El error en el número de horas de desarrollo debe ser menor a 20%

Indicador 3 Al terminar el proyecto se debió haber incluido el 100% de las funcionalidades.

El porcentaje de datos del proyecto debe ser 100%.

Gómez y Ania, 2008 En la tabla 1y 2 se muestran los objetivos planteados y sus indicadores, que son los criterios a evaluar en cada objetivo, a los cuales se les establece un valor que el equipo asigna para que puedan ser medidos. En la fase de lanzamiento se programa una serie de reuniones, donde participan todos los miembros del equipo para generar el plan del lanzamiento. Se recomienda dar seguimiento a los planteamientos que se presentan a continuación: Las empresas necesitan metas de gestión de requisitos del producto.

¿Qué?

¿Cómo?

¿Cuándo?

¿Quién?

¿Qué tan bien?

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

¿Qué pasa si...? 16

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Los objetivos del equipo Diseños conceptuales Productos planeados

La estrategia de equipo El equipo define el proceso

Plan de tareas

Funciones del equipo

Plan de calendario

Planes de trabajo

Plan de calidad

Evaluación de riesgos Plan de alternativas

Plan de valor agregado

Tamaño de estimaciones Figura 4. Lanzamiento del TSP (Queensland, 2010).

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

17

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Las preguntas que se plantean en el esquema anterior: ¿qué?, ¿cómo?, ¿quién?, ¿qué tan bien? y ¿qué pasa si...?, permitirán establecer las bases de una estrategia del lanzamiento para llegar a la culminación del proyecto; en conjunto con la anterior, se deben tomar en cuenta los requerimientos que serán establecidos por parte del cliente (Queensland, 2010). Como se mencionó anteriormente, en la fase de lanzamiento se asignan las tareas y roles del equipo de trabajo, a continuación de describen los roles del TSP. Roles de TSP Líder del proyecto “Es aquel que lleva el mando del equipo, el que lo dirige, esta figura se asegura de que todos realicen y completen su trabajo, reporten sus procesos tal cual como fue planeado en fin, es el que maneja los alcances del proyecto” (Osorio, 2013, p.2). El ingeniero que tenga este rol debe realizar reportes semanales sobre los avances del equipo (Osorio, 2013). En la siguiente tabla se muestra un ejemplo para generar los reportes de avances del equipo.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

18

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Tabla 4. Reporte de avances de equipo Reporte semanal TSP Nombre: Fecha:

Equipo: Ciclo:

Datos semanales Horas del proyecto para esta semana Horas del proyecto de este ciclo a la fecha Valor ganado para esta semana Valor ganando en este ciclo a la fecha Horas totales para las tareas terminadas en esta fase a la fecha

Semana:

Planeado

Actual

Datos semanales por rol

Horas planeadas

Horas actuales

Valor planeado

Valor agregado

Tareas de desarrollo terminadas

Horas planeadas

Horas actuales

Valor ganado

Semana planeada

Seguimiento de asuntos o riesgos

Estatus

Otros asuntos importantes

LE Líder de equipo

AP Administrador de planeación

AD Administrador de desarrollo

ACP Administrador de calidad/proceso

AA Administrador de apoyo

UABC, 2005

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

19

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

El líder de proyecto es el representante ante el cliente, el encargado de la integración de la planeación e implementación de todas las tareas de los involucrados en el desarrollo del producto de software, con el objetivo de culminar el proyecto. Administrador de desarrollo Los administradores de desarrollo guían al equipo en la planificación y seguimiento del desarrollo del producto de software. Su principal objetivo se centra en la fase de diseño del proyecto. Aquí toma el mando del proyecto el ingeniero con mayor conocimiento en diseño, quien formulará las actividades que requiera esta etapa, además de asegurarse de que todas se realicen a cabalidad (Osorio, 2013). Las funciones principales del administrador de desarrollo son (Osorio, 2013):      

Proponer estrategias de desarrollo (se describirán más delante). Auxiliar al líder de proyecto para estimar los tiempos, recursos y tamaño del producto de software. Dirigir el análisis de alto nivel. Dirigir el diseño. Dirigir la implementación de pruebas. Colaborar con el equipo de desarrollo.

Como podrás darte cuenta, el administrador de desarrollo debe de colaborar muy de cerca con cada uno de los miembros del equipo que desempeñan los distintos roles. Administrador de planeación El administrador de planeación es el principal responsable de llevar el control de los planes del equipo, y de dar apoyo a cada miembro cuando se presenten problemas que estén relacionadas con el plan. Debe dirigir la generación del plan de trabajo en cada ciclo de desarrollo y establecer cómo estarán definidas las partes del producto final. Administra el qué, quiénes, cómo, cuándo y dónde se va a hacer. De ello depende la complejidad y factibilidad del proyecto. Está ligado a los objetivos propuestos, hasta dónde se va a llegar (Osorio, 2013).

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

20

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Administrador de calidad El administrador de calidad se encarga de proponer el plan de calidad tanto para el proceso como para el producto. Tiene la responsabilidad de determinar las necesidades que se presenta dentro del proceso, y le da seguimiento a la calidad del producto. También determina las necesidades dentro del proceso de calidad que se implementará en el proyecto de software y le da seguimiento, con el fin de mantener la calidad del producto (Osorio, 2013). Sus funciones básicas son éstas:     

Mantener estándares de desarrollo. Mantener los patrones de calidad que se deban seguir durante el mismo proceso. Dirigir las inspecciones de calidad del producto de software. Registrar y documentar las reuniones que se hagan relacionadas con el equipo y su proyecto software, como todos los roles anteriores. Colaborar con el equipo de desarrollo de software (Osorio, 2013).

Es de suma importancia que el administrador de calidad revise que todo el equipo de trabajo alcance los estándares y patrones de calidad; debe alertar al líder del proyecto sobre cualquier trabajo que no los cubra. Administrador de configuraciones “La administración de configuraciones es considerada uno de los factores de mayor influencia para lograr el óptimo desarrollo de productos software de alta calidad, porque es la encargada de garantizar que los cambios sean efectivos y eficientes” (Osorio, 2013,). El administrador de configuraciones debe poseer un documento donde integre el seguimiento del proceso, es decir, un proceso documentado para realizar el manejo de la configuración de los productos y subproductos, donde se indiquen los procedimientos necesarios para llevar a cabo las labores de administración de configuraciones tales como:  

 

Establecer los números de las versiones de los productos o que indican dichos números. Mantener la trazabilidad (conocer el histórico del proyecto, en este caso las versiones del producto) de los productos y subproductos desarrollados (Osorio, 2013). Coordinar todas las actividades de cambio que realice cualquier miembro del equipo. Administrar el “versionamiento” (la gestión de los cambios que se realicen en el producto de software); es decir, administrar el control de cambios y su sistema, Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 21

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP



recomendar los cambios o ajustes que deben realizarse, verificar, mantener y evaluar la persistencia del sistema, fomentar la reutilización del código y recursos Sentirse parte del desarrollo.

Sin duda alguna, la fase de lanzamiento es una de las etapas primordiales y más importantes dentro del ciclo de vida del TSP. De ella emana lo que se va a hacer, cómo se va a hacer y hasta dónde se quiere llegar, la culminación de esta fase dará el banderazo de inicio a la de estrategia.

1.3.2. Fase de estrategia Ya se explicó lo que debe realizarse en la fase de lanzamiento para dar inicio al desarrollo del producto de software. Ya se elaboraron los equipos y se asignaron los roles, ahora es necesario plantear las estrategias a seguir para dar seguimiento a desarrollo del producto de software. En esta fase conocerás las estrategias de desarrollo para entender lo que se va a producir en cada ciclo, analizarás e identificarás las estimaciones de tamaño y esfuerzo que se requieran. En la fase de la estrategia los equipos idean un diseño conceptual del producto previsto. De igual manera se hacen estimaciones sobre el tamaño y el tiempo que tomará el desarrollo, teniendo en cuenta que el tiempo que se llegue a considerar debe ser acorde con el tiempo que se tiene disponible. La fase de estrategia contempla los siguientes puntos principales: 

Medir el tiempo real del desarrollo y el tiempo disponible.

El largo alcance de internet en tiempo real. Tomado de http://www.corbax.com/blog/img/tiempo-real.jpg



Crear el diseño conceptual del producto: es el punto de arranque para realizar la planificación del proyecto. Se establece un plan para la elaboración del producto. Para la elaboración del diseño conceptual, los miembros del equipo deben basarse en experiencias previas con la finalidad de saber cómo puede desarrollarse el siguiente producto; para esto se utilizan los diagramas UML (lenguaje unificado de Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

22

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

modelado), lenguaje grafico que permitirá especificar, visualizar, construir y documentar un sistema de software. Reviste gran importancia como guía del equipo de trabajo en todo el proceso.

Diseño y reorganización. Tomado de http://www.logismarket.es/ip/blife-diseno-y-reorganizacion-de-almacenesdiseno-y-reorganizacion-de-almacenes-491419-FGR.jpg

Establecer la estrategia de desarrollo: el equipo decide cuál es la mejor manera para dividir el trabajo entre los ciclos y lo que será producido en cada uno de éstos. Puede hacer uso de herramientas CASE. Estimación de tamaño y esfuerzo: se refiere al tamaño estimado que tendrá el producto y el tiempo que se llevará en realizarlo. Debe considerarse el tiempo disponible para hacer los a ajustes necesarios a la estrategia, y que los tiempos puedan coincidir. Puedes hacer uso de la guía del PMBOK (capítulo 6.1.) para realizar estas estimaciones.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

23

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Plan de gestión de riesgos: para realizarlo se debe estar totalmente comprometido con el proyecto, para elaborar un producto de calidad. En la siguiente tabla se muestra un ejemplo de gestión de riesgos. Corresponde a un plan de riesgos que se implementó en el desarrollo y mantenimiento de componentes para Web 2.0 en bibliotecas especializadas. Tabla 5. Ejemplo de gestión de Riesgos Riesgo RI-05. Inexperiencia del equipo informático/bibliotecario en el desarrollo e implementación del proyecto. Aspectos a considerar  ¿Por qué el riesgo es importante? Podría alterar la calidad del producto, provocar atrasos en el desarrollo e implementación del proyecto. 



Qué información se necesita para seguir el estado del riesgo: o Documentos de estado de avances de trabajos individuales, en donde se explayen las tareas realizadas y las dificultades presentadas; si éstas fueron solucionadas con éxito y cómo se consiguió. o Planilla de informe de errores y soluciones. Los responsables de realizar el control del riesgo son el jefe del proyecto y los integrantes del equipo de trabajo.



Para realizar un adecuado control del riesgo se necesitará personal capacitado en validar las funciones desde el punto de vista técnico/bibliotecológico. Si el control corresponde a una actividad informática, el personal deberá tener amplios conocimientos sobre la tecnología incluida en el proyecto; si el control corresponde a una actividad bibliotecológica, deberá poseer el conocimiento de la tecnología aplicable a la bibliotecología. Plan de acción  Cursos de capacitación de tecnología y administración de componentes web. 2.0 para el personal bibliotecario.  Realizar talleres y actividades integradoras.  Reuniones semanales entre informáticos y bibliotecarios.  Contratar personal Informático especializado en:  Tecnología web.  Base de datos.  Diseño de páginas web. Plan de contingencia  Disparador: el plan de avance no refleja los resultados esperados, falta de calidad en el producto.  Contratar una consultaría experta en tecnología Web 2.0. Kuna, Caballero et ál., 2008 Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

24

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

El TSP recomienda que las estrategias definidas sean documentadas para darles un continuo seguimiento. En este subtema se describió lo que es una estrategia y la manera en que debe desarrollarse. Esto tiene como objetivo hacer un producto de calidad, para ello el equipo debe estar de acuerdo con los criterios de la estrategia y darle seguimiento. Lo ya mencionado permitirá saber cómo se va a realizar el producto de software. Estas estrategias ayudarán al equipo a preparar la planeación, la cual se explicará en el siguiente subtema.

1.3.3. Fase de planeación En la fase de lanzamiento, el equipo debió haber analizado las necesidades y creado un diseño conceptual de la estimación de tamaño del producto; en la fase de estrategia, debió realizar una estimación de tiempo que llevará el desarrollo. Éstas son las bases para el siguiente proceso que, en este caso, es la planeación. Dentro de la fase de planeación los miembros del equipo generan un plan de trabajo, que puede contener un inventario de los elementos que serán utilizados. Éste puede contener:   



Estimación del tamaño de cada parte a ser desarrollada: éste será determinado por el tamaño del trabajo. Identificación de las tareas, estimación el tiempo necesario para completarlas: para esto es necesario asignar las tareas a cada miembro del equipo. Cronograma semanal para tareas terminadas: se puede hacer uso de herramientas como Microsoft Project, y hacer diagramas de Gantt para llevar el control de las actividades; allí se programan las tareas y se propone una duración, fecha de inicio y término. Por último, se lleva el control semanal sobre el porcentaje de cumplimiento. Plan de calidad: es un documento que especifica quién, cuándo y qué procedimientos y recursos asociados deben aplicarse a un proyecto, producto, proceso o contrato específico (Secretaría Central de ISO, 2005).

Es posible observar los formatos de un plan de gestión de calidad para un programa de capacitación en la página de Dharma Consulting Especialistas en Project Managemen, ahí encontrarás herramientas gratuitas de gestión de proyectos y podrás observar los lineamentos establecidos para realizar un control de calidad. Los objetivos de calidad, que se encuentran en la línea base de calidad del proyecto, se refieren a la medición con la que se evaluará el cumplimiento de las metas establecidas por el equipo de trabajo. La métrica se refiere, de igual manera, a una medida que proporciona Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 25

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

una indicación cuantitativa (dimensión o tamaño de algunos atributos). Otra observación importante es el sponsor, patrocinador o cliente. La complejidad para elaborar un plan de desarrollo depende del tamaño del proyecto. El hacer un plan permitirá trabajar de una manera más eficiente en el rubro de calidad. En el siguiente subtema se aplicará lo planeado con base en los requerimientos del desarrollo del software.

1.3.4. Fase de requerimientos A continuación revisarás algunas recomendaciones necesarias para conocer las especificaciones de requerimientos de software, el análisis de necesidades y los criterios necesarios para realizar lo que en verdad se quiere. Una vez que se ha concluido con la fase de planeación se pueden gestionar los requerimientos, éstos se establecen al entrevistar a los clientes para determinar lo que se va a producir (Humphrey, 1999). En esta fase se construyen las especificaciones de requerimiento de software; esto nos sirve de guía durante el proceso del desarrollo del producto. Es importante que el equipo de trabajo lleve estos requerimientos en documentos y que todos lleguen a un acuerdo acerca de lo que se va desarrollar. En muchas ocasiones los requisitos que especifica el cliente llegan a ser imprecisos, lo que ocasiona que los requerimientos sufran cambios de manera constante. Los clientes creen estar seguro de sus deseos, pero esto no siempre es así. Por ello no se debe caer en suposiciones, y sí tener muy claro lo que el cliente desea en realidad. La fase de requerimientos sugiere las siguientes actividades. Análisis de necesidades del cliente. Se realiza una serie de preguntas y respuestas que deben ser lo suficientemente claras para poder analizar las necesidades del cliente. Debe de haber participación de todos los involucrados, integrantes del equipo y cliente, para llegar a un acuerdo mutuo. En este punto, TSP indica el qué, pero las preguntas respecto al cómo se debe general al interior del equipo, de tal manera que puedan recolectar la información necesaria. Especificación de requerimientos. Éstos se clasifican en: 

Requerimientos funcionales: describen los servicios que debe proporcionar el sistema y el comportamiento que tendrá en ciertas circunstancias. Los requerimientos dependerán del tipo de software que esté en desarrollo. A continuación se presenta un ejemplo de requerimientos funcionales para un sistema de biblioteca universitaria, Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

26

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

denominado Libsys, utilizado por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas. Requerimientos funcionales de Libsys (Olivera, 2010): 1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto. 2. El sistema deberá proporcionar visores adecuados para que el usuario lea documentos en el almacén de documentos. 3. A cada pedido se le deberá asignar un identificador único (id_pedido), que el usuario podrá copiar al área de almacenamiento permanente de la cuenta. 

Requerimientos no funcionales: son aquellos requerimientos que no están involucrados directamente a las funciones del sistema. Pueden ser las capacidades de almacenamiento o restricciones de tiempo de respuesta. Ejemplo: si se requiere desarrollar un programa para un cajero automático y el cliente desea que el programa esté funcionando las 24 horas del día, en este caso se observa que el requerimiento no funciona, es decir, la disponibilidad.

Es indispensable que los requerimientos sean examinados por el equipo de trabajo para desarrollar un plan de pruebas. En conclusión, la fase de requerimiento nos da a conocer lo que el cliente desea y las funciones que se proponen para el producto a realizar; se llega a un acuerdo mutuo sobre lo que se va a construir.

1.3.5. Fase de diseño En este subtema conocerás los aspectos básicos para crear el diseño del producto de software. Aquí se genera la estructura general del producto; para esto se deben definir las especificaciones del diseño del software. Se debe generar un diseño completo de los requisitos para poder precisar claramente el producto que va a desarrollarse (Humphrey, 1999). Después de que se tienen bien definidos los requisitos, se deben llevar acabo las siguientes actividades: 

Crear un diseño de alto nivel: describen los componentes principales del sistema y la forma en que interactúan entre sí. El equipo puede trabajar de forma independiente ya que es posible separar el diseño en partes. Esto se refiere a la creación de las GUI Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

27

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

(interface gráfica de usuario), que será la vía de comunicación entre el usuario y el sistema (software). 

Inspeccionar el diseño: al inspeccionar se puede mejorar de manera importante la calidad de los diseños, pero para esto se tiene que estar lo mejor documentado posible.



Desarrollar un plan de evaluación: diseñar la estructura principal de los requerimientos del sistema permitirá la implementación y codificación de éste.

1.3.6. Fase de implementación Ahora aprenderás las acciones que se llevan a cabo en la etapa de implementación, que está relacionada con la codificación y el uso de estándares dentro del sistema. En esta fase se realiza la implementación del producto de software; se empieza a decodificar, pero antes se debe inspeccionar minuciosamente el código del software (Gómez y Ania, 2008). Los estándares en esta fase cumplen un papel muy importante. El equipo de trabajo debe definir estas normas al inicio de proyecto; esto puede hacerles ahorrar mucho tiempo en desarrollo del sistema. Como ya se mencionó, los estándares de diseño dentro de esta fase son fundamentales. A continuación se muestran algunos de ellos:     

Revisión de estándares Estándares de codificación Estándar de tamaño Estándar de defectos Prevención de defectos

En la fase de aplicación es muy frecuente encontrar errores de transcripción y de codificación, errores producidos al pulsar una tecla por otra. Por esta razón, varios programadores deben revisar e inspeccionar el código (Humphrey, 1999). El uso de estándares te permitirá encontrar y mitigar errores de escritura, así ahorrarás tiempo y esfuerzo; pero para esto se necesitan hacer las pruebas correspondientes que veras en el siguiente subtema.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

28

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

1.3.7. Fase de pruebas Esta fase es una da las más importantes ya que debe probarse el producto y evaluar, detectar y corregir todos sus defectos; de esta manera se evita que los costos lleguen a elevarse considerablemente (Gómez y Ania, 2008). En esta etapa se realizan diferentes pruebas al sistema, con el fin de asegurar su calidad y evaluar el desempeño del equipo de trabajo. Para administrar las pruebas se debe tener una lista de pasos a seguir; se hace por partes, de manera gradual, y se empieza desde el primer nivel hasta el más alto para que, al final, se integre de tal manera que todos los elementos estén incluidos y que funcionen correctamente. A continuación se muestra una guía que contempla TSP para llevar el control de las pruebas al sistema. Tabla 6. Integración y pruebas del sistema Propósito

Para guiar a un equipo a través de la integración y prueba de los componentes del producto en un sistema. Los criterios de ingreso El equipo cuenta con un plan y una estrategia de desarrollo.  Componentes implementados, inspeccionados, y la unidad probada bajo control de configuración. General Cuando los defectos se encuentran en construcción, integración o en la prueba del sistema, el responsable de calidad/proceso determina si la prueba debe continuar. Todo defecto que se encuentra en la integración o pruebas del sistema se consigna en el registro de defectos, y debe de ser revisado por todo el equipo para determinar:  Cuántos defectos similares pueden permanecer en el producto.  Cómo y cuándo encontrar y corregir esos defectos.  El proceso cambia para prevenir defectos similares en el futuro. Paso Actividades  Descripción 1 Prueba descripción El administrador de calidad describe: general del  El proceso de pruebas de integración y de sistema. proceso.  La necesidad de componentes de calidad antes de probar.  La necesidad y el contenido de las normas de ensayo.  La estrategia para el manejo de componentes de baja calidad. 2 Desarrollo de  El administrador de desarrollo conduce el progreso de la Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

29

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

pruebas      

3

Construir

 

prueba. El jefe del equipo de ayuda a asignar el desarrollo de la prueba y ensayo entre los miembros del equipo. Los miembros del equipo de pruebas realizan sus tareas de desarrollo de las pruebas. Definir los procesos y procedimientos de generación requeridas. Desarrollar los procedimientos de ensayo de la integración y las instalaciones. Desarrollar los procedimientos de ensayo de sistemas e instalaciones. Medir el tamaño y el tiempo de funcionamiento para cada prueba. Revisar los materiales de prueba y corregir errores. El equipo construye el producto y comprueba que está completo. Verifica que todas las piezas necesarias están a la mano.



4

Integración

5

Prueba del sistema

6

Documentación

El encargado del desarrollo del software, consigna todos los errores en el registro de defectos. El gerente de desarrollo o alternativas:  Conduce las tareas de integración.  Comprueba la integridad y la integración de la prueba del producto.  Escribe todas las actividades de prueba en el registro de la misma.  El encargado del desarrollo del software, registra todos los defectos en el registro de defectos. El gerente de desarrollo o alternativas conduce las tareas de prueba del sistema.  Prueba el producto en condiciones normales y de estrés.  Prueba el producto para la instalación, la conversión y la recuperación.  Consigna todas las actividades de prueba en el registro de la prueba.  El propietario del producto (desarrollador) asienta todos los errores en el registro de defectos. El gerente de desarrollo o suplente se encarga de:  Producir el contorno usuario-documentación y tareas.  La asignación de estas tareas al equipo de documentación.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

30

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP



Criterios de salida

     

Revisar el esquema con el equipo de pruebas de integridad. Elaborar la documentación de usuario de primer ciclo. Producir, revisar y corregir la documentación del usuario. Un ciclo-1 integrado y probado del producto. Formas logD y LOGTEST completadas para todas las pruebas. Documentación del usuario completada y revisada. Datos de tiempo, tamaño y defectos introducidos en el sistema de apoyo TSPI. Humphrey, 1999

En conclusión, si no se llevan a cabo las pruebas al producto de software no se podrá garantizar su funcionamiento, lo cual ocasiona que no sea un producto de calidad. Ésta es una de las últimas fases del ciclo de vida del TSP. Ahora se tiene que hacer un análisis de todo lo ocurrido durante el desarrollo del producto en la fase post mórtem.

1.3.8. Fase post mórtem Ésta es la fase de la culminación del proceso de TSP. Se comienza con la evaluación de todas las tareas que se definieron para el proyecto, se verifican las metas del plan de calidad y del trabajo del equipo. Es necesario hacer un registro de todos los datos en formatos para su revisión, ver tabla 6. (Humphrey, 1999). A continuación se ofrece un ejemplo de cómo registrar los datos para la fase post mórtem. Tabla 7. Recolección de Datos Propósito Recoger, analizar y registrar los datos del proyecto para evaluar el equipo y el desempeño de cada función. Identificar las formas de mejorar el proceso de ciclo 2 para producir el informe ciclo-1. Los criterios de ingreso Los ingenieros han completado y probado el producto. Se han reunido todos los datos y completado todos los formularios. General El informe de ciclo-1 contiene un análisis del proyecto por cada función. El rendimiento general del equipo: líder del equipo. Plan de actuación frente al actual: gerente de planificación. Diseño de producto global y las normas: gerente de desarrollo. Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

31

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Paso 1

Actividades Post mórtem descripción general del proceso.

2

Revise los datos de proceso.

3

Evaluar el desempeño del rol.

4

Ciclo de preparación1. Informe

5

Preparar evaluaciones de funciones

Criterios de salida

Gestión del cambio y proyecto de apoyo: gerente de soporte. La calidad de proceso y producto: gestor de calidad/proceso. El informe ciclo debe: Utilizar los datos de proceso para apoyar las declaraciones de los ingenieros. Cuidadosamente considerar el significado de los resultados obtenidos. Sea breve y conciso. Descripción El instructor describe el proceso post mórtem. La necesidad de una información completa y precisa del proceso. El contenido del informe de ciclo. El proceso de evaluación por pares y formas. El responsable de calidad/proceso dirige el equipo en el análisis de los datos del proyecto y la identificación de las áreas problemáticas a mejorar. El liderazgo, la planificación, el proceso, la calidad o el apoyo. Acciones y responsabilidades del equipo sugeridas. Áreas de instructor o instalación mejora. Los ingenieros encargados de preparar y presentar PIP en estas sugerencias de mejora. El líder del equipo lo conduce en la evaluación de la eficacia de las funciones del equipo, las acciones del instructor y las instalaciones de apoyo. Cuándo eran eficaces. Dónde hay margen de mejora. El líder del equipo lo conduce al esbozar el informe ciclo-1. La asignación de trabajo; informe a los miembros del equipo. Obtención de compromisos para la sección informe de terminación. Montaje, revisión y corrección del informe completo. Cada ingeniero completa una evaluación del equipo y de cada participación individual con base en el formulario PEER. Dificultad y la contribución de cada función. Los porcentajes deben sumar 100%. La eficacia de cada papel en escala de uno (inadecuado) a cinco (superior). El ciclo de desarrollo ha resultado en un producto de alta calidad con toda la documentación requerida. El producto terminado está bajo control de la configuración. Todos los datos de proceso se han evaluado y presentado PIP.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

32

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Las evaluaciones interpares se realizaron y sometieron (PEER). El informe ciclo-1 se ha completado y presentado. El cuaderno del proyecto se ha actualizado. Humphrey, 1999 Al hacer la revisión de los datos de todo el proceso debe examinarse lo que cada miembro del equipo hizo, además de identificar qué parte del proceso realizó. Después se hace una comparación del rendimiento obtenido por el equipo en lo planeado y metas fijadas al inicio del ciclo, así se podrán identificar las áreas del problema. Cuando se utiliza el proceso post mórtem se podrán hacer los cambios necesarios para el próximo ciclo, corregir problemas encontrados y determinar cuáles fueron las causas que ocasionaron las fallas para, posteriormente, tomar medidas preventivas. Esto permitirá llevar al equipo a la mejora continua.

Cierre de la unidad El TSP es una metodología que sirve de guía para los ingenieros informáticos; provee métodos para el fácil desarrollo de software por medio de miembros que llegan a formarse en equipos, los cuales se desenvuelven de una manera organizada; tienen su roles y actividades propias, los dirige un líder que recopila información y los mantiene ordenados para lograr los objetivos planteados. El ciclo de vida del TSP es una serie de ciclos que se llevan a cabo durante el desarrollo del producto de software. Comienza con la declaración de las necesidades del producto y finaliza con la entrega final. La fase de lanzamiento es pieza clave para el inicio del desarrollo del software; es aquí donde se forman los equipos y se asignan las actividades que desempeñaran cada uno de los miembros, como ya se explicó aquí; pero esto lo verás con más detalle, junto con la elaboración de planes de riesgo y calidad, en la próxima unidad. Si se desea desarrollar un software, siempre es imprescindible utilizar un método como lo es el TSP, para lograr un producto confiable y de buena calidad; asimismo nos permitirá mejorar de una manera significativa todos los procesos implicados en el desarrollo.

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

33

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP

Para saber más En la página del Institute Carnegie Mellon (http://www.sei.cmu.edu/library/abstracts/reports/10tr031.cfm), existe mucha información acerca de las herramientas de medición de la calidad del desarrollo de software, entre ellas TSP, sobre la que encontrarás diversos artículos y documentos. También puedes consultar un caso de uso de PSP y TSP en el documento Uso de tecnologías y metodologías de desarrollo, de Roy Steeven Yarce David, que se encuentra accesible en la sección Material de apoyo. Es recomendable revisar el documento de Watss S. Humprey, The Team Software Process, donde se explica la metodología TSP. La versión original de este documento, escrito en inglés, se encuentra en la sección Material de apoyo; si no posees el nivel de comprensión de este idioma, puedes utilizar alguna de las diversas herramientas de traducción que se encuentran en Internet.

Fuentes de consulta 

Colomo, R., y Paniagua, F. et al. (2011). Team Software Process. Madrid: Universidad Carlos III de Madrid. Recuperado de http://ocw.uc3m.es/ingenieriainformatica/desarrollo-de-sistemas-de-informacion-corporativos/material/TSP.pdf/view



Dharma Consulting Especialistas en Project Management (2013). Herramientas gratuitas de gestión de proyectos. Recuperado de http://dharmacon.net/herramientas/gestion-proyectos-ejemplos/



Gómez, A. y Ania, I. (2008). Introducción a la computación. México: Cenage Learning.



Humphrey, W. (1999). Introduction to the Team Software Process. Massachusetts: Addison Wesley Professional.



Kuna, H., Caballero, S. et al. (2008). Plan de Riesgos para la implementación de componentes de web 2.0. Recuperado de http://www.amicus.udesa.edu.ar/documentos/6jornada/documentos/pdf/PONENCIA% 20MISIONES%20RIESGOS%20web2.0.pdf



Nord, Robert, McHale, J., & Bachmann, F. (2010). Combining Architecture-Centric Engineering with the Team Software Proces. Pensilvania: Carnegie Mellon University Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software 34

Desarrollo de software en equipo (TSP ) Unidad 1. Introducción a TSP



Olivera Sosa, Á. G. (2010). Planificación y modelado. Escárcega: 2010.



Osorio, H. R. (2010). Roles en TSP. [En línea] http://es.slideshare.net/hansellramos/roles-para-t-s-p



Piattini, V. (2011). Calidad de sistemas de información. México: AlfaOmega/Ra-ma.



Queensland, T. U. (2010). Lecture 14: The Team Software Process. CSSE3002 The Software Process. Recuperado de http://itee.uq.edu.au/~csse3002/Lectures/Lect14.pdf



Real Academia Española (2009), Diccionario de la lengua española, 22a. ed. Recuperado de http://lema.rae.es/drae/?val=equipo



Secretaría Central de ISO. (2005). Norma Internacional ISO 9000:2005. Sistemas de gestión de la calidad. Fundamentos y vocabulario. Ginebra: ISO. Recuperado de http://www.congresoson.gob.mx/ISO/normas/ISO-90002005_Fundamentos_y_Vocabulario.pdf



Sommerville, I. (2006). Ingenieria de software. Madrid: Pearson Educación.



Trujillo, D. (2009). Team Software Process. [Mensaje de un blog]. Recuperado de http://dtrujilloa-tsp.blogspot.mx/



Tuya, Javier; Ramos Román, Isabel & Dolado Cosín, Javier (2007). Técnicas cuantitativas para la gestión en la ingeniería del software. La Coruña, España: Netbiblo

Bibliografía de la imagen: 

Dreamstime (2013). Engranajes del asunto. Recuperado de: http://thumbs.dreamstime.com/x/engranajes-del-asunto-28681457.jpg Fecha de consulta: 5 de junio del 2013

Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

35