Cada ciclo de desenvolvimento do TSP é composto por oito fases, mas este número pode variar dependendo da necessidade da equipe. Estas fases são lançamento, desenvolvimento de estratégia, planejamento, requisitos, projeto, implementação, testes e avaliação.
Na fase de lançamento são definidos os seguintes tópicos:
· Qual o papel de cada membro na equipe;
· Quem serão os membros da equipe;
· O objetivo da equipe;
· O produto que se deseja produzir.
Os papéis que cada um desempenha dentro da equipe podem mudar nos ciclos seguintes visto que algum membro pode não se identificar com o papel que lhe foi designado. São definidas reuniões semanais para se observar o andamento do projeto e o desempenho da equipe.
Tendo em vista que toda a equipe está formada e ciente do projeto, nesta fase a equipe desenvolve a estratégia para realizar os trabalhos durante o ciclo. Será criado um modelo conceitual, estimativas de tamanho e tempo de desenvolvimento do produto. Se o tempo ultrapassar o que foi previsto para o ciclo, a estratégia deverá ser revista e um novo módulo funcional do produto deverá ser definido para ser desenvolvido durante o ciclo. Na fase de estratégia são gerados artefatos que serão úteis na fase de planejamento. Nesta fase a equipe começa a produzir o plano de gerência de configuração. Este plano é fundamental para o controle da versão do produto. Quando uma equipe desenvolve um produto sempre há problemas de coordenação e o plano de gerência de configuração visa resolver este problema.
Há várias razões para se fazer um plano. Quando se tem um plano detalhado, sabe-se com exatidão o que deve ser feito e quando será feito. Quando não se usa o planejamento, geralmente a equipe encontra dificuldades no desenvolvimento do projeto. O plano pode variar dependendo do contexto em que é aplicado. O planejamento ainda é uma fase que requer tempo e paciência. Entretanto, como o TSP utiliza-se da estratégia de desenvolvimento cíclico e são desenvolvidas pequenas versões, os planos são simples [HUMPHREY, 1999].
Um dos problemas do cumprimento de tarefas é o trabalho não balanceado [HUMPHREY, 1999]. Em uma equipe sincronizada, todos os membros terminam suas tarefas em uma ordem correta e no mesmo tempo. No TSP, a equipe desenvolve o planejamento distribuindo as tarefas de forma balanceada. Este balanceamento sempre é verificado nas fases de avaliação dos ciclos de desenvolvimento.
Na fase de estratégia, gerou-se o modelo conceitual do projeto. É a partir deste modelo que o plano será confeccionado. Serão determinados artefatos relacionados como especificação de requisitos e planos de testes. Todos os produtos desenvolvidos neste ciclo deverão ser listados e seus tamanhos estimados. Com base nesses dados, também será criado o plano de qualidade. O plano de qualidade prevê medidas como tempo de desenvolvimento, número de erros por KLOC (mil linhas de código), porcentagem livre de erros, porcentagem de reusabilidade, porcentagem de remoção de erros, etc. Nos finais dos ciclos, estas medidas são utilizadas para uma avaliação do controle de qualidade do produto a ser produzido.
Na fase de requisitos, a equipe desenvolve a especificação de requisitos do software. Este artefato prevê exatamente o que o produto será. Através dele é que será feita a avaliação final do produto e a constatação se ele é realmente o que o cliente desejava. Uma das causas de insatisfação do cliente é a má funcionalidade do software. Criando a especificação, a equipe evita esse problema. Para gerar esta especificação, relatam-se todas as necessidades do cliente com relação ao que ele espera do produto final. Existem muitos padrões para documento de requisitos, entretanto o TSP se concentra nos requisitos funcionais e operacionais. Entre eles estão:
No TSP, o objetivo principal do documento de requisitos é documentar os acordos da equipe em relação às funcionalidades e interfaces externas.
O projeto é a fase onde a equipe irá decidir como construir o produto. Não somente descrever idéias gerais, mas produzir uma especificação completa e precisa de como o produto será construído.
Quando um projeto é mal definido, os membros da equipe perdem tempo resolvendo problemas da má especificação. Esta situação gera incompatibilidades entre os componentes desenvolvidos criando um produto de má qualidade. Ao contrário, quando um projeto é bem definido, o produto gerado segue exatamente o que foi descrito no documento de requisitos, proporcionando qualidade, usabilidade e a satisfação do cliente.
No TSP, a construção do projeto consiste dos seguintes passos:
A fase de implementação é a geração do código fonte do produto. Esta implementação deve seguir o que foi proposto na fase de projeto. Os principais passos na fase de implementação são: planejamento de implementação, projeto detalhado, inspeção do projeto detalhado, codificação, inspeção de código, testes unitários, revisão da qualidade dos componentes e lançamento dos componentes. Uma das características da fase de implementação no TSP é a utilização de padrões. Os padrões de implementação utilizados são:
Nesta fase, os módulos desenvolvidos no ciclo são testados e integrados para formar o produto final. O objetivo é verificar se tais módulos produzirão um produto de qualidade. As principais atividades de testes no TSP são:
Durante estas atividades, também é desejado:
De um modo geral a fase de Testes é composta pela construção, testes de integração e teste do produto. A construção é caracterizada pela união dos módulos para compor o produto final. Os testes de integração garantem que todos os módulos estão presentes e que trabalham perfeitamente juntos. O teste do produto avalia as funcionalidades e desempenho em relação aos requisitos especificados pelo cliente.
A documentação é uma parte essencial de um software de qualidade. Em alguns casos, ela é mais importante que o código do programa [HUMPHREY, 1999]. É na fase de testes que a documentação é criada e revista. Enquanto alguns engenheiros estão ocupados com testes, outros devem ficar responsáveis pela documentação do produto.
A análise é a fase final do TSP. Nela todo o trabalho da equipe é revisto para garantir que tudo o que foi planejado foi realmente cumprido. Também é verificado se todos os dados foram registrados pelos membros da equipe. É analisado o que foi desenvolvido no ciclo e quais são as melhorias para o próximo ciclo ou para o próximo produto. Se o modo de como o trabalho é feito não for mudado, os resultados adquiridos serão os mesmos.
Através da análise, serão definidas melhorias tanto no processo de desenvolvimento quanto no processo gerencial da equipe. No aspecto gerencial serão analisados os rendimentos, desempenho, pontos de vista e dificuldades dos engenheiros que desempenharam os papéis de gerentes e líder. Com os resultados em mãos, verificar a necessidade de mudar os membros que desempenharam tais papéis. Toda a análise tem como objetivo prover um método par avaliar todo o processo de desenvolvimento e estipular melhorias.