Unidad 1. Introduccion a TSP

Desarrollo de Software en Equipo TSP Unidad 1. Introducción a TSP

8º Cuatrimestre

Programa de la asignatura: Desarrollo de Software en Equipo TSP

Unidad 1. Introducción a TSP

Clave: 150930934

Universidad Abierta y a Distancia de México UnADM

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


Índice 1.

Introducción a TSP.................................................................................................... 2

Presentación 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 Objetivos de TSP ....................................................................... 7 1.1.2. Estrategia de TSP ......................................................................................... 8 1.1.3. Equipo TSP ................................................................................................... 9

Foro de la asignatura ....................................................................................................... 10 Actividad 1. Elementos Elementos de la metodologí metodología a TSP ................................................................ 10 Team 1.2. Estructura del Team

Softw are Process (TSP). ...................................................... 11

1.2.1. Disciplina de Equipo.................................................................................... 13 1.2.2. Disciplina de Administración Administración........................................................................ 14 14 1.2.3. Disciplina de Ingeniería Ingeniería ............................................................................... 15 Actividad 2. Estructura Estructura base de la metodología metodología TSP TSP ........................................................ 16 1.3. Ciclo de Vida del Team Team

Softw are Process (TSP) ................................................... 16

1.3.1. Fase de Lanzamiento Lanzamiento .................................................................................. 17 1.3.2. Fase de Estrategia Estrategia ...................................................................................... 25 1.3.3. Fase de Planeación Planeación .................................................................................... 28 1.3.4. Fase de Requerimientos Requerimientos ............................................................................. 30 1.3.5. Fase de Diseño ........................................................................................... 31 1.3.6. Fase de Implementación Implementación ............................................................................. 32 1.3.7. Fase de Pruebas......................................................................................... 33 1.3.8. Fase Postmortem ........................................................................................ 35 Autoevaluación Autoevaluación................................................................................................................. 37 Evidencia de aprendizaje. Identificación de los elementos de la metodología TSP .......... 37 Autorreflexiones Autorreflexiones ............................................................................................................... 38 Cierre de la unidad ........................................................................................................... 38 Para saber más ................................................................................................................ 39 Fuentes de consulta ......................................................................................................... 40 Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

1


1. Introducción a TSP Presentación de la unidad Te damos la más cordial bienvenida a la asignatura Desarrollo de software en equipo TSP (Team Software Process), la cual, forma parte del octavo cuatrimestre de la Ingeniería en Desarrollo de Software. La metodología PSP (Personal Software Process) está orientada a un contexto individual del ingeniero en desarrollo de software, sin embargo, TSP es una metodología que está orientada a equipos de trabajo y para que los miembros del equipo logren la efectividad deseada de acuerdo a los roles que desempeñan dentro del mismo, es necesario contar con una metodología como PSP , que guíe 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 alcanzar los objetivos trazados al inicio del proyecto. En la unidad uno Introducción a TSP aprenderás aprenderás los elementos, objetivos y principios en los cuales se basa esta metodología, así como su estrategia y estructura, misma 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


Propósitos   



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. ea m S o f t w a r e P r o c e s s (TSP) 1.1. Proceso de Desarrollo de T ea Team Software Process (TSP) fue creado por Watts Humphrey en 1996. Es un proceso de

desarrollo de software en equipo y una metodología que guía a los Ingenieros de software a asegurar la calidad en los diferentes procesos del ciclo de vida de desarrollo de software y principalmente la productividad de los equipos de trabajo (Ingenieros, administradores y desarrolladores de software) para cumplir con sus objetivos (Gomez de Silva & Ania., Et al 2008). Cuando se habla de objetivos de un proyecto de desarrollo de software hay un objetivo en particular muy importante que se tiene que cumplir, esto es que el tiempo que dure el proyecto no debe de rebasar lo planeado al inicio del mismo. En este contexto, implementar la metodología TSP dentro de una organización ayuda a tener una métrica exacta de costos y la retroalimentación retroalimentació n de proyectos pasados para reducir tiempos y por supuesto costos. Para comprender la metodología TSP es necesario saber qué es un Proceso de desarrollo de software o software o también denominado Ciclo de vida de desarrollo de software. software. No es más que una estructura que nos indica las etapas que tiene que cumplir todo desarrollo de software. Es muy importante saber que es un proceso de desarrollo de software, ya que TSP es una metodología que debe de ser utilizada dentro de este proceso. Existen muchos procesos de desarrollo de software pero la mayoría se basan en el modelo en cascada, TSP puede utilizar cualquier otro modelo de ciclo de vida, la razón por la que se menciona el modelo en cascada es porque es el más utilizado y el 90% de los modelos que existen en la actualidad, están basados en él. El Modelo en Cascada indica que todo desarrollo basado en este modelo debe cumplir con las siguientes fases: Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

3












Análisis y definición de requerimientos: Es muy importante conocer qué desea el cliente, para esto se hace el levantamiento de requerimientos, que no es más que visitas con el 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, esta parte cambiará de acuerdo a la metodología que se implemente para realizar el desarrollo del sistema, pero nunca debe de faltar sea cual sea la metodología a implementar, documentos donde se muestren los objetivos, visión, roles, puestos y los requerimientos del sistema a desarrollarse. Diseño del sistema y el software: En esta fase nuevamente 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: En esta fase intervienen los desarrolladores de software y prácticamente en esta fase se desarrolla por completo el sistema. Integración y pruebas del sistema: Aquí se observa ya un producto terminado y las personas designadas en el área de pruebas y calidad de software revisan que el sistema no tenga fallos y si los hay se devuelve el producto a los desarrolladores para que se 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 cuenta con una versión terminada del sistema que se lleva directamente con el cliente para que lo prueben y verifiquen su correcto funcionamiento ya en el área de producción. Si hay nuevos requerimientos se vuelve a regresar a la primer fase para iniciar las mejoras para el sistema (Sommerville, 2006).

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


4


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).

Entonces decimos que TSP es un Proceso de desarrollo por que cumple con esta estructura pero con sus propias fases que más adelante se explicarán. Se recomienda el uso de TSP en grupos de entre 2 a 20 personas y en desarrollos de sistemas que sean a gran escala. TSP se centra principalmente en la administración de proyectos, la construcción de los equipos de trabajo de acuerdo a los roles y el perfil de cada persona que se necesiten para los distintos puestos dentro del proyecto. En un proyecto de desarrollo de software se selecciona a la cantidad de personal que requieren 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 Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

5


desarrollo, administrador de planeación, administrador de calidad de proceso y administrador de soporte, los cuales se explicarán con más detalle en el apartado 1.3 Fases del ciclo de vida de TSP . A comparación de PSP, TSP se enfoca en la gestión del equipo de trabajo y PSP en la calidad pero no de todo el proceso de desarrollo ni del equipo, si no de la calidad y la gestión individual, en especial enfocada en los desarrolladores de software, para tener una métrica exacta de su productividad y en base a esto poder mejorar la calidad en su trabajo. Retomando a Piattini Velthuis (2011), se afirma que TSP se basa en los siguientes elementos: 











Administración autodirigida a equipos de trabajo: como se mencionó anteriormente a comparación de PSP, TSP está totalmente orientado a equipos de trabajo. Está integrado de indicadores: los indicadores indican los pasos realizar y en qué orden realizarlos. Es un sistema de administración de calidad: TSP tiene como principal propósito asegurar la calidad en el desarrollo de software para que se llegue a 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: 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 se pueden aprender durante el desarrollo del proyecto. Modelo de “ c o a c h i n g ” : Método que tienen como propósito instruir y dirigir a las personas con el único fin de lograr los objetivos y desarrollar habilidades específicas de acuerdo a las actividades y roles que desempeñen dentro del proyecto.

Un desafío muy importante de TSP es la comunicación que existe 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.


6


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 en dicho desarrollo, los objetivos del proyecto de acuerdo a la metodología TSP los establecen los Ingenieros de software. Es importante que todos los involucrados en el proyecto tengan claros los objetivos para poder llegar a la meta en tiempo y forma, pero para lograr esto se debe asignar a cada persona en el puesto indicado de acuerdo a sus habilidades, conocimientos y experiencia, para de esta forma asegurar que se cuente con un 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 por supuesto si existe retroalimentación entre los miembros del equipo. TSP cuenta con mediciones claras establecidas y está diseñado para utilizarse de manera cíclica, el uso de pequeños ciclos 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 el mismo. 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. En este capítulo se revisó el significado de TSP, 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 que integran ese equipo. También se revisó lo correspondiente a el significado del ciclo de vida de desarrollo de software como un proceso, explicando a detalle el modelo en cascada y cada una de sus fases y por último, los principio y objetivos que tiene esta metodología. En el siguiente capítulo se revisará el tema de la estrategia de TSP, donde podrás identificar la importancia de los equipos de trabajo así como las estrategias para conformar un buen equipo de trabajo para poder implementar esta metodología de desarrollo de software dentro de una organización.


7


1.1.2. Estrategia de TSP Se puede decir que las estrategias son actividades bien estructuradas y planificadas para lograr el objetivo o los objetivos que se tengan planeados, según la RAE (2013), la palabra estrategia proviene del latín strategĭa, y ésta del griego στρατηγία , y se define como el “[… ] Arte de dirigir las operaciones militares. […] Arte, traza para dirigir un asunto. […] En un proceso regulable, conjunto de las reglas que aseguran una decisión óptima en cada momento. 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 en cada una de sus etapas. TSP se conforma de ocho procesos: lanzamiento, estrategia, plan, requerimientos, diseño implementación, prueba y postmortem, 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 debe cumplir con un ciclo de desarrollo el cual será elegido de acuerdo al tamaño y la complejidad del proyecto. Por ejemplo tomemos el modelo en cascada, este modelo 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 Velthuis, 2011). Siempre se inicia con una junta donde los ingenieros de software y líderes 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, basándonos en el modelo en 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. Cómo 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 8 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 que nos marca TSP.


8


1.1.3. Equipo TSP En algún momento, a todos nos ha tocado trabajar en equipo en la escuela o al realizar algunos juegos o en el campo laboral, según la RAE (2013) un equipo es “[…] Grupo de personas organizado para una investigación o servicio determinado [.. .].” En el contexto de TSP, metodología que como se mencionó anteriormente, fue creada pensando en los grupos de trabajo y está dirigida hacia el trabajo en conjunto y la retroalimentación, sin embargo, para que un equipo se forme con base en esta metodología hay algunas condiciones que se deben crear para establecer un equipo de trabajo, mismas que se mencionan a continuación (Piattini Velthuis, 2011):  





El equipo 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 (estos los establecen los ingenieros de software y administradores del proyecto) específico el cual debe seguir porque es una guía de lo que debe hacer.

Para poder conformar un equipo efectivo de ingenieros se necesita que: Los integrantes estén cualificados con las capacidades y habilidades necesarias para desempeñar el rol que se les asigne. El objetivo del proyecto sea claro, realista y bien definido. Los recursos que se asignen al equipo deben de ser acordes al trabajo que van a realizar. Los integrantes del equipo deben de estar motivados y comprometidos para lograr el objetivo. Los miembros del equipo 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 roles bien definidos y objetivos en común por parte de los miembros del equipo. Definir procesos en común para su trabajo. 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.  

    


9


 



Deberá existir comunicación frecuente entre los miembros del equipo. Todos los integrantes del equipo 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 capítulo se revisó lo referente a las condiciones necesarias para crear equipos de trabajo adecuados para implementar la metodología TSP. En el siguiente capítulo identificarás los elementos d la metodóloga TSP y la relación que existe entre ellos.

Foro de la asignatura Esta actividad tiene como finalidad, ser un espacio de integración de todos los participantes del grupo y conocer las expectativas que tienen acerca de la asignatura. 1. Realiza una presentación y comparte con tus compañeros algunos datos sobre ti con el fin de que el grupo se integre. 2. Comparte tus expectativas de la asignatura. 3. Utiliza el foro en el transcurso de la asignatura para compartir dudas u observaciones, diversas inquietudes, información adicional que localices y que pueda ser de utilidad a tus compañeros de grupo y facilitador. Es importante que realices tus participaciones en un clima de tolerancia, respeto y colaboración.

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

10


2. Identifica en el problema los elementos del proceso de desarrollo de TSP: elementos, principios y objetivos, estrategias y las condiciones para establecer un equipo TSP. 3. En un archivo de texto o presentación de plantillas elabora un mapa mental donde expongas los elementos gráficos que ejemplifiquen o representen a cada uno de ellos así como la relación que existe entre los mismos y la forma en que solucionan el problema. 4. Explica tu mapa mental mencionando cuál es la relación entre los elementos de TSP, así como las imágenes que consideras ilustran los mismos. 5. A continuación, redacta una conclusión acerca de la importancia de esta metodología en el ámbito del desarrollo de software. 6. Sube tu archivo con el problema, el mapa mental y tus conclusiones a la base de datos. 7. Posteriormente, comenta el trabajo, al menos, dos de tus compañeros(as), respecto al problema, el mapa mental y sus conclusiones. Realiza tus comentarios con respeto y de forma constructiva. 8. Guarda tu actividad con la nomenclatura DDSE_U1_A1_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido. *Consulta el documento Criterios de evaluación de actividades U1 , para ver la rúbrica de la actividad y conocer los parámetros de evaluación

1.2. Estructura del Team

(TSP). So ftware Process

Se puede decir que TSP es una estructura porque se conforma de partes y procesos que se encuentran relacionadas y que indican las acciones o actividades a ejecutar y el orden en el cual deben desarrollarse. Es muy importante en la implementación de TSP, ya que indica los pasos a seguir al momento de trabajar en equipo, al crear el equipo y ejecutar acciones individuales. Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

11


Una de las más grandes ventajas de TSP, es que proporciona una estructura bien definida para guiar a los ingenieros y administradores a llevar por buen camino a un equipo de trabajo. Esta estructura también especifica los pasos y medidas necesarias para formar un equipo eficaz en un buen ambiente de trabajo. En la siguiente figura se muestra la estructura de TSP:

Figura 1.2.1. Estructura de TSP (Gomez de Silva & Ania ). En la parte superior de la imagen en los recuadros se encuentra la metodología que se va a usar en esa disciplina, por ejemplo en disciplina ingenieril se refiere a PSP ya que se trata del trabajo y habilidades que cada miembro del equipo debe tener. En las siguientes dos disciplinas: disciplina de equipo y disciplina de administración, se crean los equipos y se ejecuta el trabajo en equipo, para ello, se utiliza la metodología TSP. El conjunto de las tres disciplinas da como resultado equipos de trabajo bien conformados e integrados. Se refiere a disciplinas porque dentro de cada una nos muestra los pasos (en TSP se llaman fases) bien definidos y estructurados que se van a ejecutar, al ser 3 disciplinas, llegaremos a Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

12


formar equipos integrados hasta que las 3 se hayan completado al 100% ejecutando cada una de sus fases. A continuación se explicarán cada una de las disciplinas que conforman la estructura de TSP.

1.2.1. Disciplina de Equipo Debido a que la estructura de TSP se divide en 3 disciplinas es necesario explicar cada una con sus respectivas fases. En este subtema aprenderás la disciplina de equipo con sus respectivas fases. La disciplina de equipo son una serie de reglas que debe de llevar a cabo el equipo 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: se puede decir que los 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 ponerle su propio sello de calidad al desarrollo, esto se lleva a cabo en las pruebas que cada uno de ellos realiza. Las pruebas se realizan de acuerdo al funcionamiento que debe de tener el módulo del sistema que estén desarrollando. Es muy importante hacer énfasis en que estas pruebas son provisionales por que 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, esta parte 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 para llevar a cabo el desarrollo del software 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, los planes los establecen los administradores al inicio del proyecto y aprenderás como se hacen 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 los riesgos que puedan surgir durante el desarrollo del software, todos Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

13






estos planes los veremos con mas a detalle en la Unidad 2 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 a las capacidades y cualidades de cada persona y sin establecidas 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 realizará el proyecto de software por el cual contrata o integra un equipo TSP.

En conclusión al subtema, se puede decir que esta disciplina de equipo indica reglas muy precisas que guían las actividades del equipo para que se logren los objetivos del proyecto, son 3 disciplinas: ingenieril, de equipo y de administración, en el siguiente subtema hablaremos sobre la disciplina de administración.

1.2.2. Disciplina de Administración Como se mencionó en el subtema anterior la estructura de TSP se basa en tres disciplinas, ya vimos la disciplina que está orientada al equipo, en este subtema aprenderás la disciplina enfocada a la administración del proyecto a desarrollarse. Esa disciplina muestra la forma en que los administradores del proyecto deben guiar al grupo para cumplir los objetivos del proyecto de software que se desarrollará. 









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 ejecutando al pie de la letra la metodología TSP. Costo de la calidad: de acuerdo a la calidad será el coste, hay que asegurar que los costos sean adecuados para llegar a la calidad planeada al inicio del proyecto. Los costos serán adecuados al tiempo y de acuerdo con lo robusto que sea el sistema que se vaya a desarrollar, 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 definen procesos bien definidos los administradores deben de revisar que estos procesos se cumplan, esto se aprenderá en el tema 1.3 Ciclo de Vida del Team Software Process (TSP). Revisión de status de calidad: revisar periódicamente el estado de la calidad del software, esto se revisa en plantillas y reportes de los cuales se auxilian tanto los desarrolladores como los administradores estas revisiones aprenderás como hacerlas en la Unidad 3 Gestión en TSP. Comunicación: la comunicación entre los miembros del equipo de desarrollo del proyecto, no solo permite que se llegue a los objetivos deseados, también nos sirve Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

14


para tener un buen ambiente de trabajo y por supuesto la retroalimentación que ayuda a los miembros del equipo a no cometer errores que se hayan cometido anteriormente ya sea en el mismo proyecto o en proyectos anteriores. Como pudimos observar, la disciplina de la administración se basa totalmente en los administradores y en la forma en que medirán el nivel de calidad que se obtenga durante el 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 saben que forman parte del grupo pero deben de 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: Planes personales: cada miembro del equipo debe conocer su rol dentro del proyecto y tiene que estar consciente de la importancia que representa 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 en ese lapso de tiempo. 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 un nivel de referencia exacto 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 la Unidad 3 subtema 3.2. Diagnóstico: Métricas de calidad versus trabajo realizado

Procesos definidos: estos procesos muestran a los miembros del equipo un panorama general para poder 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 pudimos aprender las disciplinas son como recetas de cocina que nos dicen qué acciones tomar en todas y cada una de las fases de desarrollo del proyecto. En el siguiente tema aprenderemos la forma en que está estructurado el ciclo de vida de la metodología TSP.


15


Actividad 2. Estructura base de la metodología TSP En esta actividad identificarás la estructura base de la metodología TSP mediante un mapa mental, para ello, sigue estos pasos: 1. Elabora un mapa mental en una presentación multimedia o en un archivo de texto, por cada disciplina de la estructura base de la metodología TSP, donde expongas la relación que existe entre ellas, representando con imágenes cada una de sus características y fases de la disciplina correspondiente: ingenieril, de equipo, administrativa. Es necesario que las imágenes y texto tengan relación congruente con cada una de las fases de la disciplina correspondiente. 2. Al finalizar tu mapa mental, explica la imagen que integraste representando a cada disciplina, y por qué consideras que tiene relación con la fase a la que corresponde. Integra en tu explicación la relación que existe entre cada una de ellas y una reflexión sobre la importancia de estas disciplinas en el quehacer del ingeniero en desarrollo de software. 3. Guarda tu actividad con la nomenclatura DDSE_U1_A1_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido. *Consulta el documento Criterios de evaluación de actividades U1 , para ver la rúbrica de la actividad y conocer los parámetros de evaluación

1.3. Ciclo de Vida del

(TSP) Team Software Process

El Ciclo de vida del TSP se conforma de una serie de ciclos organizados en ocho fases los cuales pueden ir desde un ciclo hasta n ciclos, esto dependerá de la magnitud del proyecto estos comienzan con los requerimientos del producto de Software, en cual se establecerá lo que se quiere lograr y se comenzará empezará con la creación de diseños detallados del software y este a su vez será revisado por todo el equipo para que posteriormente este diseño se convierta en código , de igual modo será revisado y analizado para realizar las pruebas pertinentes. Finalmente se analizará la calidad del producto de software terminado, es entonces cuando el ciclo de vida del TSP llega a su fin (Nord, R.L., 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, estas Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

16


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 se deben de llevar 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 tema 1.3.1 Fase de lanzamiento . Cada una de las fases describe las actividades que involucra a cada una de ellas y que se explican a continuación (Humphrey, 1999). Fases de TSP Lanzamiento Estrategia Planeación Requerimientos Diseño Implementación Pruebas Posmortem

Figura 1.1 Fases del Ciclo de Vida del TSP (Humphrey, 1999).

1.3.1. Fase de Lanzamiento En este tema 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, así como 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 manera individual y en equipo, en la tabla 1.3.1 observarás un ejemplo de los objetivos planteados de manera individual.


17


Es de gran importancia definir los objetivos de tal manera que puedan llegar a ser medibles para poder determinar la calidad del producto generado ( Ver Tabl a 1.3.1 ). Se deben establecer objetivos que sean ambicioso para los miembros del equipo, pero sin alejarse de la realidad (ser un miembro del cooperativo y eficiente, Realizar un trabajo personal disciplinado, etc.) . Realizar los objetivos por escrito ayudará de manera significativa al equipo para poder evaluar periódicamente 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.3.1 Objetivos propuestos para los miembros del equipo y sus indicadores. (Garza, 2008). Objetivos Ser un miembro del Equipo cooperativo y efectivo

Realizar un trabajo personal disciplinado

Planear y dar

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. (esta es una medición de la eficacia y/o eficiencia la cual el equipo determina, el equipo es quien establece estas mediciones). El porcentaje de los datos personales (desempeño eficacia, etcétera) registrados debe ser 100% El porcentaje de

Indicador 2

Indicador 3

Indicador 4

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


18


seguimiento al trabajo personal

Hacer productos de calidad

los datos del proyecto personal registrados en las formas correspondientes debe ser 100%

El porcentaje de defectos encontrados antes de la prime compilación debe ser mayor a 70%

las tareas del proyecto con plan y datos reales registradas en forma correspondiente debe ser 100% La densidad de defectos encontrados durante la compilación debe ser menor a 10/KLOC.

La densidad de defectos encontrados durante la prueba de unidad debe ser menor a 5/KLOC.

La densidad de defectos encontrados después encontrados durante la prueba de unidad debe ser 0.

Tabla 1.3.2 Objetivos propuestos por el equipo y sus indicadores. (Garza, 2008) Objetivos Indicador 1 Indicador 2 Indicador 3 El porcentaje de La cantidad de Al terminar el defectos defectos proyecto se debió Producir producto encontrados antes encontrados en la haber incluido el de calidad de la primera prueba del sistema 100% de las compilación debe debe ser 0. funcionalidades 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%

El porcentaje de datos del proyecto debe ser 100%


19


En la tabla 1.3.1 y 1.3.2 se muestran los objetivos planteados y sus indicadores que son los criterios que se evaluarán en cada objetivo, el cual se le establece un valor que el equipo tendrá que asignar para que pueda ser medido. En la fase de lanzamiento se programan una serie de reuniones en las cuales participan todos los miembros del equipo para poder generar el plan del Lanzamiento. Se recomienda darle seguimiento a estos planteamientos para poder generar el plan de Lanzamiento: Las empresas necesitan metas de gestión de requisitos del producto.

¿Qué?

Los objetivos del equipo. Diseños Conceptuales. Productos Planeados.

¿Cómo ?

La estrategia de equipo. El equipo define el proceso.

¿Cuándo?

¿Quién ?

Plan de Tareas

Funciones del Equipo

Plan de Calendario

Planes de trabajo

¿Qué

¿Qué

tan

pasa

Bien?

Si?

Plan de Calidad

Evaluación de Riesgos Plan de Alternativas

Plan de Valor Agregado

Tamaño de estimaciones.

Lanzamiento del TSP (Queensland, 2010).


20


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 seguir para poder 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 había 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). El ingeniero que tenga este rol debe realizar reportes semanales avances del equipo (Osorio, 2013). En la siguiente tabla 1.3.3, se muestra un ejemplo para generar los reportes de avances del equipo. Tabla 1.3.3. Reporte de Avances de Equipo (UABC, 2005). Reporte Semana TSP Nombre: Fecha:

Equipo: Ciclo:

Semana:


21


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

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

El líder de proyecto básicamente es el representante ante el cliente y el encargado de llevar a cabo la integración de la planeación e implementación de todas las tareas que llevaran a Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

22


cabo todos los involucrados en el desarrollo del producto de software dándoles seguimiento para poder 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 precisamente en el instante en que el proyecto se encuentra en fase de diseño, deberá ser el ingeniero con mayor conocimientos en diseño, aquí toma el mando del proyecto. Debe además, formular las actividades que requiera la etapa de diseño y asegurarse de que todas estas se realicen a cabalidad (Osorio, 2013). Las funciones principales del administrador de Desarrollo son (Osorio, 2013):  

   

Proponer estrategias de desarrollo (Se describirá más delante de este tema). 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 mutuamente en algunas ocasiones con cada uno de los roles que desempeñan los miembros del equipo.

Administrador de Planeación El administrador de planeación es el principal responsable de llevar el control de los planes del equipo y de darle a poyo a cada miembro del equipo cuando se presenten problemas que estén relacionadas con el plan. Debe de dirigir la generación del plan de trabajo en cada ciclo de desarrollo y establece como estará definidas las partes del producto final, esto se refiere a lo que se va hacer, quienes lo van a hacer, cuanto se va a hacer, etc. Del cual dependerá la complejidad y factibilidad (está ligado a los objetivos propuestos, hasta donde se va a llegar) del proyecto. (Osorio, 2013).


23


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 de calidad, y le da seguimiento a la calidad del producto. También el administrador de calidad determinar las necesidades dentro del proceso de calidad que se implementara en el proyecto de software y se le pueda dar seguimiento para que este a su vez mantenga la calidad del producto (Osorio, 2013). Son funciones básicas del administrador de calidad:    



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 y como todos los anteriores roles. 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 lleve a cabo los estándares y patrones de calidad y alertar al líder del proyecto cualquier trabajo que no sea de calidad. 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, este documento debe indicar 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).


24


Es el responsable de coordinar todas las actividades de cambio que lleguen a realizar cualquier miembro del equipo El administrador de configuraciones debe administrar el versionamiento (esto se refiere a la gestión de diversos cambios que se llegan a realizar en algún producto de software) del producto de software, es decir, administrar el control de cambios y su sistema, recomendar los cambios que deben realizarse o ajustes cuando esto le amerite, verificar, mantener y evaluar la persistencia del sistema, fomentar el re-uso de código y de recursos y como todos hacer 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 ya que 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 para la fase de Estrategia.

1.3.2. Fase de Estrategia Ya se explicó lo que se debe de realizar en la fase de lanzamiento para dar inicio al desarrollo del producto de software, al tener la elaboración de los equipos y roles ahora es necesario hacer las estrategias a seguir para poder dale 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, analizando e identificando las estimaciones de tamaño y esfuerzos que se requieran. Después de que se finaliza la etapa de lanzamiento se deben llevar a cabo las estrategias a seguir durante el desarrollo del producto en cada una de las fases. 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: Es importante medir el tiempo real del desarrollo y el tiempo disponible.


25


Dcorbaxeo SEO (2009). Crear el diseño conceptual del producto: Es el punto de arranque para poder hacer una planificación del proyecto, ya que se hace un plan para la elaboración del producto. Para la elaboración del diseño conceptual los miembros del equipo deben se basarse en experiencias previas con la finalidad de saber cómo se puede desarrollar el siguiente producto. Esto se crea haciendo uso de diagramas UML (Lenguaje Unificado de Modelado) es un lenguaje grafico que permitirá especificar, visualizar, construir y documentar un sistema de software y reviste gran importancia como guía del equipo de trabajo en todo el proceso de desarrollo de software.

Elementos de diseño de un producto. Logismarket (2013) Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

26


Establecer la estrategia de desarrollo: El equipo decide cual es la mejor manera para dividir el trabajo entre los ciclos y lo que será producido en cada uno de estos. Puede hacer uso de Herramientas CASE. Estimación de tamaño y esfuerzo: Esto se refiere al tamaño estimado que tendrá el producto y el tiempo que se llevará en realizarlo. Se debe considerar el tiempo que se tiene disponible para poder hacer los a ajustes necesarios a la estrategia, para que de esta manera los tiempos puedan coincidir. Puede hacer uso de la guía del PMBOK dentro del capítulo 6.1 para poder hacer las estimaciones dichas anteriormente. Plan de gestión de riesgos: Para realizar un plan de riesgos primeramente se tiene que estar total mente comprometidos con el proyecto, a elaborar un producto de calidad. A continuación en la tabla 1.3.2 se muestra un ejemplo de gestión de riesgos. La siguiente tabla corresponde a ejemplo de un plan de riesgos que se implementó en el desarrollo y mantenimiento de componentes para de Web 2.0 en Bibliotecas especializadas. Tabla 1.3.2. Ejemplo de gestión de Riesgos (Kuna, Caballero, & Eunice, 2008). 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ía atrasos en el desarrollo e implementación del proyecto. Que información se necesita para seguir el estado del riesgo: 





Documentos de estado de avances de trabajos individuales, en donde se explayen las tareas realizadas y las dificultades presentadas y si estas fueron solucionadas con éxito como se solucionaron dichas dificultades. Planilla de informe de Errores y soluciones.

Quien es responsable de realizar las actividades de control del riesgo: el responsable es el Jefe del proyecto, integrantes del equipo de trabajo. Que recursos se necesitan para realizar las actividades de control del riesgo: para realizar un adecuado control de este riesgo se necesitará personal capacitado para validar las funciones desde el punto de vista técnico/bibliotecológico. Si el control corresponde a una actividad informática, este personal deberá tener amplios conocimientos en cuanto a la tecnología incluida en el proyecto, si el control Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

27


corresponde a una actividad bibliotecológica este personal deberá tener conocimiento de tecnología aplicables a la bibliotecología. Plan de Acción Cursos de capacitación de tecnología Web 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: 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 



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

1.3.3. Fase de Planeación Antes de entrar a esta fase el equipo debió de haber analizado las necesidades y crear un diseño conceptual de la estimación de tamaño del producto en la fase de lanzamiento y en la fase de estrategia las estimación de tiempo que llevará su desarrollo, se tendrán las bases para poder pasar al siguiente proceso que en este caso es la planeación, teniendo en cuenta lo antes mencionado en este tema se describirá lo que se debe hacer para poder tener una buena planeación. Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

28


Dentro de la fase de planeación los miembros del equipo generan un plan de trabajo, el cual puede contener un inventario de los elementos que serán utilizados por el equipo. Este puede contener. 







Estima el tamaño de cada parte a ser desarrollada. Este será determinado por el tamaño del trabajo. Se identifican las tareas: se estima el tiempo para completar cada tarea. Para esto es necesario asignar las tareas a cada miembro del equipo. Hacer un cronograma semanal para tareas terminadas. Se puede hacer uso de herramientas como por ejemplo Microsoft Project, y hacer diagramas de Gantt para llevar el control de las actividades, dentro del mismo se programadas las tareas con fecha de inicio y fecha de término, la duración y por último se lleva un control del porcentaje de cumplimiento de dicha actividad por semana. Hacer un plan de calidad. El plan de calidad es un documento que especifica qué procedimientos y recursos asociados deben aplicarse, quién debe aplicarlos y cuándo 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 en la cual encontrarás herramientas gratuitas de gestión de proyectos y podrás observar los lineamentos establecidos para realizar un control de calidad. En el caso de los objetivos de calidad que encontramos en la Línea Base de Calidad del Proyecto se refiere a la medición con la que evaluaran el cumplimiento de estos, las cuales serán establecidas por el equipo de trabajo. En cuanto a la métrica se refiere de igual manera a una medida que proporciona una indicación cuantitativa (dimensión o tamaño de algunos atributos). Otra observación importante es el “SPONSOR” que no es más que el

patrocinador o cliente. Dependiendo del tamaño del proyecto será la complejidad para poder crear un plan de desarrollo, el hacer un plan permitirá trabajar de una manera más eficiente de calidad. En el siguiente tema se aplicará lo planeado con base a los requerimientos del desarrollo del software.


29


1.3.4. Fase de Requerimientos A continuación revisarás algunas recomendaciones necesarias para poder conocer las especificaciones de requerimientos de Software, y el análisis de necesidades y los criterios necesarios para poder hacer lo que en verdad se quiere. Una vez que se ha concluido con la fase de planeación se pueden gestionar los requerimientos, estos se pueden establecer con entrevistas con los clientes para poder ir determinando lo que se va a producir (Humphrey, 1999). En esta fase es donde 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 llega a ocasionar que los requerimientos sufra cambios constante mente, los clientes creen estar seguro de lo que desean, pero esto no siempre es así, es por esto que no se debe de caer en suposiciones de lo que el cliente en realidad desea. Se deben de tener claro de lo que el usuario realmente quiere. La fase de requerimientos sugiere las siguientes actividades: Análisis de necesidades del cliente: Para esto se hacen entrevistas con el cliente donde se realizan una serie de preguntas y respuestas que deben de ser lo suficientemente claras para poder analizar las necesidades del cliente. Debe de haber participación de todos los involucrados tanto por parte del cliente así como los integrantes del equipo para que puedan 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: Estos se clasifican en: 

Requerimientos Funcionales: Estos 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 se esté desarrollando. Se presenta a continuación un ejemplo de requerimientos funcionales para un sistema de biblioteca universitarios, denominados Libsys, utilizado por estudiantes y personal docente que solicitan libros y documentos de otras bibliotecas. Requerimientos Funcionales de Lisbys (Bligo, 2013): Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

30


1. El usuario deberá tener la posibilidad de buscar en el conjunto inicial de la base de datos o seleccionar un subconjunto de ella. 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. Estas pueden ser las capacidades de almacenamiento o restricciones de tiempo de respuesta del sistema. 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.

Finalmente es indispensable que los requerimientos sean examinados por el equipo de trabajo para poder 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 y se llega a un acuerdo mutuo sobre lo que se va a construir.

1.3.5. Fase de Diseño En este tema conocerás los aspectos básicos para poder crear el diseño del producto de Software. Es en esta fase donde 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 se va desarrollar (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: Los diseños de alto nivel son los que 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 (Interface Gráfica de Usuario) que será la vía de comunicación entre el usuario y el sistema (software). Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

31


Inspeccionar el diseño: Al inspeccionar se puede mejorar de manera importante la calidad de los diseños pero para esto tiene que estar lo mejor documentado posible. Desarrollar un plan de evaluación. Al diseñar la estructura principal de los requerimientos del sistema permitirá la implementación y codificación del mismo.

1.3.6. Fase de Implementación En este capítulo aprenderás las acciones que se llevan a cabo en la etapa de implantación la cual básicamente 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 entra en la entapa en la que se empieza a decodificar pero antes que esto se debe de inspeccionar minuciosamente el código del software (Garza A. G., 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 se mencionaba anteriormente 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.

Cuando se está en la fase de aplicación es muy frecuente encontrarse con errores de transcripción y de codificación que son errores que se producen en las pulsaciones de teclas. Por esta razón es que los programadores deben revisar el código y de igual forma otros programadores deben inspeccionar el código (Humphrey, 1999). El uso de estándares te permitirá encontrar y mitigar errores de escritura que permitirán ahorrar tiempo y esfuerzo, pero para esto se necesitan hacer las pruebas correspondientes que es de lo que veras en el siguiente tema.


32


1.3.7. Fase de Pruebas Esta fase es una da las más importantes ya que se debe de probar el producto alcanzado, para así evaluar y detectar todos los defectos que se puedan presentar en el producto y que estos a su vez sean corregidos para evitar que los costos lleguen a elevarse considerablemente (Garza, 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 que tener una lista de pasos a ejecutarse estas se van haciendo por partes de manera incremental empezando desde el primer nivel hasta el más alto para que finalmente se integren asegurándose sé que todos los elementos estén incluidos y que funcione correctamente. A continuación se muestra una guía que contempla TSP para llevar el control de las Pruebas al Sistema. Tabla 1.3.7. Integración y Pruebas del Sistema. (Humphrey, 1999). Propósito Los criterios de ingreso

Para guiar a un equipo a través de la integración y prueba de los componentes del producto en un sistema. El equipo cuenta con una estrategia de desarrollo y el plan. Componentes implementados, inspeccionado, y la unidad probada bajo control de configuración Cuando los defectos se encuentran en construcción, integración, o 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 registra en el registro de defectos y debe de ser revisado por todo el equipo para determinar: Cuando 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 Descripción El administrador de calidad describe el proceso de pruebas de integración y de sistema. 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 

General



 

Paso Actividades 1 Prueba Descripción general del proceso



  


33


2

Desarrollo de Pruebas

calidad El administrador de desarrollo conduce el desarrollo de la 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. Revise los materiales de prueba y corregir errores. El equipo construye el producto y comprueba que está completo. Verifique que todas las piezas necesarias están a la mano. 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 integración. Compruebe la integridad y la integración de la prueba del producto. Registre todas las actividades de prueba en el registro de la prueba. 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. Pruebe el producto en condiciones normales y de estrés. Pruebe el producto para la instalación, la conversión y la recuperación. Registre todas las actividades de prueba en el registro de la prueba. Propietario del producto (desarrollador) registra todos los defectos en el registro de defectos. El gerente de desarrollo o suplente lleva al equipo en: Producir el contorno usuario-documentación y tareas La asignación de estas tareas al equipo de documentación 













3

Construir

 

4

Integración







5

Prueba del Sistema

 





6

Documentación

 


34


  

Criterios de salida

 

 

Revisar el esquema con el equipo de pruebas de integridad Elaboración de la documentación de usuario de primer ciclo Revisar, corregir, y la producción de la documentación del usuario Un ciclo-1 integrado y probado producto Formas logD y LOGTEST completadas para todas las pruebas Documentación del usuario Completado y revisado Datos de tiempo, tamaño y defectos introducidos en el sistema de apoyo TSPI

En conclusión si no se llevan a cabo las pruebas al producto de software no se podrá garantizar el funcionamiento de este, ocasionando que no sea un producto de calidad. Esta es una de las últimas fases del ciclo de vida del TSP, pero ahora se tiene que hacer un análisis de todo lo ocurrido durante el desarrollo del producto, haciendo uso de la fase de P o s t m o r t e m .

1.3.8. Fase P o s t m o r t e m Esta es la fase de la culminación del proceso de Team Software Process . Primeramente se comienza con la evaluación de todas las tareas que se definieron para el proyecto, verificando las metas del plan de calidad y el trabajo del equipo. Es necesario hacer un registro de todos los datos en formatos para su revisión ver tabla 1.3.8. (Humphrey, 1999) La siguiente tabla muestra un ejemplo de cómo registrar los datos para la fase P o s t m o r t e m . Tabla 1.3.8 Recolección de Datos (Humphrey, 1999). Propósito

Los criterios de ingreso General

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 ingenieros han completado y probado el producto. Se han reunido todos los datos y completado todos los formularios. 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 Gestión del cambio y proyecto de apoyo: gerente de soporte


35


Paso 1

2

Actividades Postmortem

Descripción general del proceso 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

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-mortem. 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 y mejorar. El liderazgo, la planificación, el proceso, la calidad o el apoyo Acciones y responsabilidades del equipo sugeridos Áreas de instructor o instalación mejora Los ingenieros de preparar y presentar PIP en estas sugerencias de mejora. El líder del equipo lidera el equipo en la evaluación de la eficacia de las funciones del equipo, las acciones del instructor, y las instalaciones de apoyo. Cuando eran eficaces Donde hay margen de mejora El líder del equipo lidera el equipo en 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 complete una evaluación del equipo y de cada papel en el equipo utilizando el formulario PEER. Dificultad y la contribución de cada función Los porcentajes deben sumar 100% La eficacia de cada papel en una escala de 1 (inadecuado) a 5 (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.


36


Las evaluaciones inter pares se hacen y se sometieron (PEER). El informe ciclo 1 se ha completado y presentado. El cuaderno del proyecto se ha actualizado.

Al hacer la revisión de los datos de todo el proceso se debe examinar lo que cada miembro del equipo hizo e identificar qué parte del proceso trabajo realizó. Después se hace una comparación del rendimiento obtenido por el equipo en lo planeado y metas que se fijaron al inicio del ciclo, así se podrán identificar las áreas del problema. Cuando se utiliza el proceso de p o s t m o r t e m se podrán hacer los cambios necesarios para el próximo ciclo, corrigiendo problemas encontrados y determinando cuáles fueron las causas que ocasionaron las fallas para posteriormente poder hacer medidas preventivas. Esto permitirá llevar al equipo a la mejora continua.

Autoevaluación Una vez concluido el estudio de la Unidad 1. Introducción a TSP y las actividades de aprendizaje. Antes de desarrollar la Evidencia de Aprendizaje, realiza la autoevaluación con el fin de realizar un repaso general de la unidad; así como detectar aquellos temas que no has comprendido en su totalidad y que requieras revisar nuevamente, o bien, consultar con tus compañeros(as) y Facilitador(a). Para realizar la Autoevaluación, ingresa al listado de actividades en el aula.

Evidencia de aprendizaje. Identificación de los elementos de la metodología TSP En la evidencia de aprendizaje identificarás los elementos de la metodología TSP con base en un problema que plantearás y al cual es posible dar solución mediante esta metodología. Para ello, sigue estos pasos: 1. Plantea y describe detalladamente un problema al cual puedas dar solución mediante la Metodología TSP. Puedes investigarlo de acuerdo con tus posibilidades, en tu ámbito laboral, personal, familiar, laboral, puede ser hipotético con base en algunas experiencias en estos ámbitos o con base en tu formación profesional como desarrollador de software. 2. Redacta el problema en un archivo de texto. Ciencias Exactas, Ingeniería y Tecnología | Desarrollo de Software

37


3. Integra un cuadro comparativo en el cual expongas: Elemento de la Metodología TSP, definición de los elementos de la Metodología TSP, ejemplo de cada uno de los elementos de la metodología TSP: a. Principios y objetivos de TSP b. Estrategia de TSP c. Equipo TSP d. Estructura del Team Software Process (TSP): Disciplina de equipo, disciplina de administración, disciplina de ingeniería. e. Ciclo de Vida del Team Software Process (TSP): Lanzamiento, estrategia, planeación, requerimientos, diseño, implementación, pruebas, postmortem. 4. Integra un documento con la descripción del problema, el cuadro comparativo y tus propias conclusiones acerca de la relación que existe entre cada uno de los elementos y la importancia de esta metodología en el quehacer del ingeniero en desarrollo de software. 5. Guarda tu actividad con la nomenclatura DDSE_U1_A1_XXYZ. Sustituye las XX por las dos primeras letras de tu primer nombre, la Y por tu primer apellido y la Z por tu segundo apellido. *Consulta el documento Criterios de evaluación de actividades U1 , para ver la rúbrica de la actividad y conocer los parámetros de evaluación.

Autorreflexiones Además de enviar tu trabajo de la Evidencia de aprendizaje, ingresa al foro Preguntas de Autorreflexión y consulta las preguntas que tu Facilitador(a) presente, a partir de ellas elabora tu Autorreflexión en un archivo de texto llamado DDSE_U1_ATR_XXYZ. Posteriormente envía tu archivo mediante la herramienta Autorreflexiones.

Cierre de la unidad El TSP es una metodología que sirve de guía para ayuda a los ingenieros informáticos, el cual provee métodos para el fácil desarrollo de software por medio de miembros que llegan a formarse en equipos, en el cual se desenvuelven de una manera organizativa; estos miembros tiene su roles y actividades propias y los dirige un líder el cual recopila información y los mantiene ordenados para que logren completar sus objetivos planteados.


38


El ciclo de vida del TSP son una serie de ciclos que se llevan a cabo durante el desarrollo del producto de software, este comienza con la declaración de las necesidades del producto y finalizan con la entrega del producto final. Es la fase de Lanzamiento pisa clave para el inicio del desarrollo del software ya que es aquí donde se forman los equipos y se asignas las actividades que desempeñaran cada uno de los miembros del equipo como se explicó a lo largo de la unidad y que veras más con más detalle en la siguiente unidad, así también la elaboración de planes de riesgo y calidad. Si se desea desarrollar un software, siempre es imprescindible utilizar un método como lo es el Team Software Process , TSP: (Equipo de Procesos de Software), para lograr un producto confiable y de buena calidad, de igual manera nos permitirá mejorar de una manera significativa todos los procesos implicados en el desarrollo de software.

Para saber más En la página del Institute Carnegie Mellon, encontrarás información diversa acerca de las herramientas de medición de la calidad del desarrollo de software, entre ellas TSP. Encontrarás diversos artículos y documentos acerca de esta metodología. Software Engineering Institute Carnegie Mellon (2013). Pittsburgh: https://www.sei.cmu.edu/library/abstracts/books/201731134.cfm Fecha de consulta: 11 de junio del 2013. 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, el cual se encuentra accesible en la sección Material de apoyo . Es recomendable revisar el documento de Watss S. Humprey, The Team Software Process , en el cual se explica la metodología TSP. Este documento se encuentra en su versión original en el idioma inglés, si no cuentas con una un nivel de comprensión de este idioma, puedes utilizar alguna de las diversas herramientas de traducción que se encuentran en la Red Internet. Consulta este documento en la sección Material de apoyo.


39


Fuentes de consulta 















Arcos, D. T. (2009). Team Software Process .dttrujilloa blogspot. Recuperado de: http://dtrujilloa-tsp.blogspot.mx/ Fecha de consulta: 11 de junio del 2013 Colomo Palacios & Paniagua, Ricardo. Et al. (2011). Team Software Process . Madrid, España: Universidad Carlos III de Madrid. Recuperado de: http://ocw.uc3m.es/ingenieria-informatica/desarrollo-de-sistemas-de-informacioncorporativos/material/TSP.pdf/view Fecha de consulta 11 de junio del 2013. Dharma Consulting Especialistas en Project Management (2013). Herramientas gratuitas de gestión de proyectos. Recuperado de: http://dharmacon.net/herramientas/gestion-proyectos-ejemplos/ Fecha de consulta: 10 de junio del 2013 Gomez de Silva Garza, Andrés & Ania Briseño Ignacio de Jesús. (2008). Introduccion a la Computacion. Mexico, D.F: Cenage Learning Editores. Humphrey, Watss S. (1999). Introduction to the Team SoftwareProcess . Massachusetts: Addison Wesley Professional. Kuna, Horacio Daniel & Caballero, Sergio, Et al(2008). Plan de Riesgos para la implementación de componentes de Web 2.0. Buenos Aires: AMICUS. Universidad Nacional de Misiones. Facultad de Humanidades y Ciencias Sociales. Departamento de Bibliotecología. Recuperado de: http://www.amicus.udesa.edu.ar/documentos/6jornada/documentos/pdf/PONENCIA% 20MISIONES%20RIESGOS%20Web2.0.pdf Fecha de consulta: 13 de junio del 2013. Piattini Velthuis, M. (2011). Calidad de Sistemas de información . México, D.F.: Alfa Omega ra-ma. Queensland, T. U. (2010). CSSE3002 The Software Process . Lecture 14: The Team Software Process. Queensland, Australia: School of Information Technology and Electrical Engineering. Recuperado de: http://itee.uq.edu.au/~csse3002/Lectures/Lect14.pdf Fecha de consulta: 11 de junio del 2013.


40

Unidad 1. Introduccion a TSP

Recommend Documents