TSP – The Team Software Process

Apresentação em tema: "TSP – The Team Software Process"— Transcrição da apresentação:

1 TSP – The Team Software Process
Alunos - Paulo Aragão Kleucio Profa. - Eliane Martins Disciplina – MO 409 (Engenharia de Software) IC - UNICAMP 1

2 Introdução e Motivação CMM e TSP Modelo TSP Estrutura do TSP
Roteiro Introdução e Motivação CMM e TSP Modelo TSP Estrutura do TSP Processo TSP Launch Ciclo de Desenvolvimento Conclusões Referências IC - UNICAMP 2

3 1 – Introdução Foi desenvolvido em 1996 por Humprey no SEI
Equipes de 2 a 20 membros/multi-equipe de até 150 membros Seu foco é a formação de uma equipe capaz de desenvolver produtos de alta qualidade dentro de prazos agressivos Utiliza o PSP para capacitação individual Foi desenvolvido pelo SEI (Software Engineer Institute) , responsável por desenvolver o modelo CMM Formado por equipes de 2 a 20 membros ou mult-equipe de até 150 membros. Portanto nao se restringe apenas a projetos pequenos Para se formar uma boa equipe é necessário que cada indivíduo esteja preparado. O PSP preenche este requisito. O PSP está focado na habilidade individual e capacita cada membro da equipe: Medir o tamanho, tempo e defeitos no produto Planejamento e rastreamento das atividades Uso de estratégias de qualidade para gerenciar os defeitos no seu trabalho IC - UNICAMP 3

4 1 – Motivação Equipes são necessárias na maioria dos projetos
A eficiência da equipe determina o sucesso do produto A eficiência: Formação de uma boa equipe Embora alguns hardware ou software possa ser desenvolvido individualmente, a escala e complexidade dos sistemas tem aumentado e tempo para desenvolvimento tem diminuido. Portanto, nao é mais possivel um sistema ser desenvolvido por apenas uma pessao A principal motivação para a criação do TSP foi a convicção de que os engenheiros de software podem fazer um bom trabalho somente se estes são bem formados, treinados, agrupados com membros habilidosos e possuindo um bom líder IC - UNICAMP 4

5 2 – CMM e TSP CMM – Foco na Organização
. CMM – Foco na Organização TSP –Foco na formação da equipe e no seu gerenciamento PSP – Foco na habilidade individual do desenvolvedor O CMM especifica uma serie de requisitos que a organizacao deve atender para atingir um determinado nivel de maturidade (1-5) O CMM foca em que a organização deve fazer, mas nao especifica como atingir estes objetivos. O PSP provê um guia de como o engenheiro de software (individuo) pode melhorar seu desempenho O TSP prové um guia em como engenheiros treinado em TSP podem trabalhar como membros de uma equipe eficiente Em essencia, o CMM e o PSP provê o contexto e a habilidade individual para o trabalho efetivo enquanto o TSP guia os desenvolvedores em fazer o trabalho. IC - UNICAMP 5

6 2 – CMM e TSP TSP Quality Source: CMU/SEI-2003-TR-014 Defects/KLOC 7.5 8 7 6.24 6 4.73 5 4 3 2.28 2 1.05 This chart illustrates impact on delivered product quality. Based on data from Capers Jones, higher maturity organizations produce higher quality products. Grafico baseado em dados de Capers Jones. Como uma avancada versao do nível 5 do CMM, a media de qualidade de produtos para projetos TSP é da ordem de vinte vezes melhor que a media de um projeto CMM de nivel 5 Os dados obtidos é baseado nos seguintes numeros de projetos: Nivel 1 – Centenas de projetos Nivel projetos Nivel projetos Nivel projetos Nivel projetos Os dados do TSP é do CMU/SEI TR 2003-TR-014 e é baseado em 20 projetos 1 0.06 Level 1 Level 2 Level 3 Level 4 Level 5 TSP IC - UNICAMP 6

7 Comunicação entre os membros
3 – Modelo do TSP Comunicação entre os membros O gerente define o produto a ser desenvolvido bem como o tempo de desenvolvimento. Se comunica diretamente com os coordenadores. Muitas vezes o gerente ja foi tecnico algum dia e muitas vezes se envolvem em problemas tecnicos. O coordenador determina as atividades e os esforcos para cada atividade Desenvolvimento sem qualquer tipo de informação oficial sobre o real objetivo do projeto, o que desmotiva os membros da equipe Prazos impostos e não o que foi considerado pelo desenvolvedor. Desenvolvedor realiza o desenvolvimento IC - UNICAMP 7

8 Comunicação entre os membros
3 – Modelo do TSP Comunicação entre os membros O gerente apresenta o objetivo global do produto a ser desenvolvido Os membros da equipe (desenvolvedores e lider) desenvolve um plano envolvondo esforcos, cronograma e qualidade do produto. Os membros apresenta ao gerente o plano desenvolvido. Os membros da equipe desenvolveram o plano, logo eles estao motivados e comprometidos com o resultado final do trabalho IC - UNICAMP 8

9 4 – Estrutura do TSP TSP PSP TSP Disciplina Individual Disciplina da
Formação da Equipe (Team Launch) Habilidade Individual Gerenciamento Metricas individuais Objetivos do Projeto Disciplina Comunicacao Estimativa e Planejamento Planos de Qualidades Gerenciamento da Qualidade Análise de Riscos Acompanhamento Relatório final Disciplina Individual Disciplina da Equipe Gerenciamento Das Atividades PSP é requerido para prover ao engenheiros de software conhecimento e habilidade para usar o TSP. Treinamento em TSP inclui: Treinamento em como realizar um planejamento detalhado Recuperacao e uso de dados do processo (metricas) Medicao e gerenciamento da qualidade do produto Definicao e uso dos processos operacionais Em TSP a formacao da equipe é denominada de Team Launch e é um processo que gasta quatro dias. Nesta etapa todos os membros da equipe desenvolvem uma estratégia, um processo e um plano para fazer seu projeto. Depois de completar o launch a equipe segue seu trabalho com o processo definido Equipe Integrada IC - UNICAMP 9

10 5 – Processo TSP Launch 1 Ciclo 1 Launch 2 Ciclo 2 Launch 3 Ciclo 3
O launch é necessário em cada ciclo de forma que o conhecimento gerado no ciclo anterior possa ser utilizado neste ciclo. Tambem o launch atualiza os planos detalhados No ciclo de desenvolvimento o TSP nao exige que o modelo seja orientado a objetos ou que use o UML. Ele está focado mais na capacidade de gerenciamento através das medidas obtidas por cada membro da equipe. Assim, o coordenador pode acompanhar o andamento das atividades e tomar algumas medidas caso confirme um possivel atraso no cronograma (aumentar a equipe, diminuir o numero de facilidades a serem desenvolvidas, etc.) Dados Processados Relatório de Status IC - UNICAMP 10

11 6 – Launch 1. Estabelecimento do produto e objetivos do negócio 2. Atribuição dos papéis e definição dos objetivos da equipe 3. Geração da estratégia de desenvolvimento 4. Construção dos planos top-down e planos do próximo ciclo 5. Desenvolvimento de um plano de qualidade 6. Construção dos planos bottom-up e dos planos balanceados 7. Análise dos riscos 8. Preparação do relatório final para apresentação à gerência 9. Revisão da gerência do relatório apresentado Realização do Post-Mortem Dia 1 Dia 2 Dia 3 Dia 4 . Launch 1- Informar aos membros da equipe sobre o trabalho, descrever os objetivos da gerencia e convencer aos membros da equipe que a gerencia está contando com eles para a execução do projeto Launch 2 – Documenta os objetivos do projeto e seleciona os papeis de cada membro da equipe (coordenador, gerente de interface com o usuário, gerente de design, gerente de implementação, gerente de teste, gerente de planejamento, gerente de processo, gerente de qualidade e gerente de suporte). Cada membro da equipe desempenha pelo menos um papel. Launch 3 – Define a estratégia global. Os membros produzem um projeto conceitual, desenvolve estratégia de desenvolvimento, define detalhadamente os processos a serem utilizados e determina as ferramentas necessárias. Launch 4 – Desenvolve o Plano. Ou seja, estimativa dos produtos a serem desenvolvidos, identificacao das atividades e estimativas dos seus esforcos, definir as atividades para o proximo nível de desenvolvimento e definição de um cronograma semanal para a equipe. Launch 5 – Define um plano de qualidade baseado no plano global. Ou seja, Estimativa do numero de defeitos introduzidos e removidos em cada fase e calculando o defeito e densidade do produto final. O plano de qualidade provê uma metrica básica para acompanhamento da qualidade Launch 6 – Faz um plano detalhado para o proximo ciclo e revisa o carga de trabalho atribuida a cada membro. Launch 7 – Os membros identificam os maiores riscos do projeto. Tambem é atribuído a um membro da equipe a responsabilidade de rastrear cada risco e prepara um plano alternativo para os riscos mais significativos Lauch 8 – Preparacao do relatorio do plano elaborado para revisao da gerencia. IC - UNICAMP 11

12 7 – Ciclo de Desenvolvimento
Focado no gerenciamento das atividades planejadas Cada membro da equipe realiza as medidas As medidas são agrupadas pelo líder Não estã preso a tecnologia (OO, UML, etc..) O ciclo de desenvolvimento está focado no gerenciamento das atividades planejadas durante o Launch Cada membro da equipe faz as medidas. As métricas adotadas são aquela do PSP As medidas são agrupadas pelo líder tornando possível o acompanhamento das atividades. Não se restringe a nenhuma tecnologia ou metodologia IC - UNICAMP 12

13 8 – Conclusões Pequenas equipes de desenvolvimento
Sua motivação é a necessidade de equipes Objetiva construir uma equipe e gerenciar as atividades planejadas Equipe é auto-suficiente – define seus planos e estratégias Foca acompanhamento das atividades O ciclo de desenvolvimento está focado no gerenciamento das atividades planejadas durante o Launch Cada membro da equipe faz as medidas. As métricas adotadas são aquela do PSP As medidas são agrupadas pelo líder tornando possível o acompanhamento das atividades. Não se restringe a nenhuma tecnologia ou metodologia IC - UNICAMP 13

14 9 – Referências Introduction to the Personal Software Process. Acessado em 07/09/04. SEI Software Engineering Process Management Program. Acessado em 07/09/04. TSP. Acessado em 08/09/04. Pathways to Process Maturity: The Personal Software Process and Team Software Process. Acessado em 07/09/04. The Team Sotware Process (TSP) reports/pdf/00tr023.pdf. Acessado em 10/09/04. The Team Software Process (TSP) in Practice: A Summary of Recent Results. Reference%20Materials/Recent%20Results.pdf. Acessado em 08/09/04 View Module. Acessado em 11/09/04 Introduction to Software Engineer Processes. Acessado em 09/09/04 Maturity models and process improvement. Acessado em 08/09/04 Personal Software Process Life Cycle. Acessado em 07/09/04 14