relatório de projecto - departamento de engenharia...

Relatório de Projecto

Projecto – Personal Software Process and Team Software Process

ISEP – Setembro de 2002 Página 2 de 49

Autoria: João Paulo Santos Nunes Ferreira Aluno nº 890082

Personal Software Process

e Team Software Process



Prefácio Serve o presente relatório para apresentar o trabalho por mim desenvolvido no âmbito

da cadeira de Projecto do 5º ano do ramo de Computadores e Sistemas.

Este relatório aborda de um modo geral algumas metodologias usadas na gestão do

desenvolvimento de software, quer a nível pessoal quer em grupo.



Índice

Prefácio ............................................................................................................................3 Introdução ........................................................................................................................6 Personal Software Process (PSP)........................................................................................7 1. Introdução ................................................................................................................. 8 2. Qualidade do software .............................................................................................. 8 3. Princípios do PSP ..................................................................................................... 9 4. Estrutura do processo PSP ........................................................................................ 9

4.1 Planeamento...................................................................................................... 13 4.1.1 Requisitos .................................................................................................. 13 4.1.2 Método de Probe ........................................................................................ 13

4.1.2.1 Modelo conceptual.............................................................................. 13 4.1.2.2 Estimar o tamanho do produto............................................................ 14 4.1.2.3 Estimar os recursos ............................................................................. 14

4.1.3 Produção do calendário .............................................................................. 15 4.1.4 Desenvolver o produto............................................................................... 15 4.1.5 Analisar o processo .................................................................................... 15

5. Recolha de informação ........................................................................................... 15 5.1 Medir tempos .................................................................................................... 15 5.2 Calcular tamanhos ............................................................................................ 16

5.2.1 Linhas de código ........................................................................................ 16 5.2.2 Categorias dos tamanhos ........................................................................... 16

5.3 Contabilizar tamanhos ...................................................................................... 17 5.3 Medidas de qualidade ....................................................................................... 17

6. Gestão da qualidade ................................................................................................ 22 6.1 Defeitos e qualidade ......................................................................................... 22 6.2 A responsabilidade do engenheiro .................................................................... 23 6.3 Remoção de defeitos ......................................................................................... 23 6.4 Prevenção de defeitos ....................................................................................... 23

7. Design em PSP ....................................................................................................... 24 8. O PSP e as melhorias no processo de desenvolvimento ......................................... 25

Team Software Process (TSP) ..................................................................................... 27 1 Qualidade do software ............................................................................................. 28 2 Como foi desenvolvido o TSP................................................................................. 28

2.1 Equipas de trabalho ........................................................................................... 28 2.2 Condições para o trabalho em equipa ............................................................... 29 2.3 Equipas eficazes................................................................................................ 29 2.4 Criar equipas eficazes ....................................................................................... 30

3 Processos operacionais para equipas ....................................................................... 30 4 A estrutura do TSP................................................................................................... 32 5 Lançamento de uma equipa TSP ............................................................................. 34 6 TSP processos de trabalho em equipa ..................................................................... 37

6.1 Liderar a equipa ................................................................................................ 37 6.2 Comunicação .................................................................................................... 38 6.3 Manter o plano .................................................................................................. 38 6.4 Balancear a carga de trabalho ........................................................................... 39



7 Gestão da qualidade ................................................................................................. 40 7.1 O plano de qualidade ........................................................................................ 40 7.2 Identificação de problemas de qualidade.......................................................... 43 7.3 Encontrar e prevenir problemas de qualidade .................................................. 44

8 Resultados obtidos com o TSP ................................................................................ 45 9 Estado e tendências futuras...................................................................................... 47

9.1 Tendências futuras ............................................................................................ 47 Conclusão ........................................................................................................................ 48 Bibliografia ...................................................................................................................... 49



Introdução Este relatório é composto por duas partes distintas:

A primeira parte é composta por uma descrição da metodologia Personal Software

Process (PSP), nomeadamente, estrutura do processo, recolha de informação e a gestão

da qualidade.

Na segunda parte é apresentada a metodologia Team Software Process (TSP), nas

suas componentes de qualidade de software, processos operacionais, estrutura PSP,

lançamento de uma equipa e gestão da qualidade.

É ainda feita uma breve referência à metodologia Capacity Maturity Model (CMM).



Personal Software Process (PSP)



1. Introdução

O Personal Software Process (PSP) procura ajudar os engenheiros a melhorar o seu desempenho, trazendo disciplina e uma certa metodologia ao modo como eles desenvolvem o software. Baseado nas regras do Capacity Maturity Model (CMM), o PSP pode ser usado pelos engenheiros como guia para uma aproximação disciplinada e estruturada ao desenvolvimento de software.

Dado que 70 % dos custos de desenvolvimento de software são atribuídos a custos de

pessoal, competência técnica, experiência e hábitos de trabalho dos engenheiros determinam seriamente os resultados do processo de desenvolvimento do software. Esta relação entre o engenheiro e os resultados do processo de desenvolvimento de software é premissa na qual o PSP se baseia.

Na maioria das profissões, o trabalho competente e eficiente requer o uso disciplinado de

práticas estabelecidas. Não se trata de uma questão de criatividade relativamente à disciplina, mas sim, trazer disciplina ao trabalho para que a criatividade possa surgir. O uso de planos e procedimentos traz organização e eficiência a qualquer trabalho e permite aos trabalhadores concentrarem-se na produção de algo ainda melhor. Um esforço disciplinado remove o desperdício, o erro, e a ineficiência, libertando assim recursos financeiros que poderão ser utilizados de uma forma mais proveitosa.

Dado que os engenheiros de software, geralmente não estão habituados a planear, optimizar

e a controlar a qualidade do seu trabalho, normalmente não planeiam o trabalho e a qualidade do software é raramente controlada. O PSP mostra aos engenheiros como gerir a qualidade dos seus produtos e como estabelecer objectivos que possam cumprir. O PSP fornece também um conjunto de dados que permitem justificar os planos. O PSP pode ser aplicado a várias fases do processo de desenvolvimento de software, incluindo pequenos programas, definição de requisitos, criação de documentação, testes, manutenção e em melhorias de grandes sistemas de software.

PSP melhora substancialmente a habilidade de planear e estimar dos engenheiros reduzindo

significativamente os defeitos nos produtos por eles criados. 2. Qualidade do software

Até pouco depois da Segunda Grande Guerra a estratégia de qualidade na maioria das organizações industriais era baseada quase inteiramente em testes, tipicamente eram estabelecidos departamentos de qualidade especiais para procurar e corrigir eventuais erros depois de produzidos os produtos, até à década de setenta, altura em que W. Edwards Deming e J.M. Juran convenceram a indústria norte-americana a concentrar-se em melhorar o modo como as pessoas faziam o seu trabalho. Nos anos seguintes, esta especial atenção dada aos processos de desenvolvimento foi responsável por melhorias assinaláveis na qualidade dos automóveis, da electrónica, e em qualquer outro tipo de produto. A tradicional estratégia de testar e corrigir é hoje reconhecida como cara, demorada, e ineficaz para a engenharia e para o processo de fabrico.

Embora a maioria das organizações industriais nesta fase tenha adoptado princípios de

qualidade modernos, a comunidade de software continuou a apostar nos testes como principal método de gestão de qualidade. Neste ramo o primeiro grande passo foi dado por Michael Fagan quando em 1976 introduziu as inspecções de software. Com a introdução do uso de inspecções as organizações melhoraram substancialmente a qualidade do software. Outro



passo significativo para a melhoria da qualidade foi dado com a introdução inicial do Capacity Maturity Model (CMM) para software em 1987. O CMM dava mais relevância ao sistema de gestão e ao apoio e ajuda que este fornecia aos engenheiros. O CMM teve um efeito positivo bastante significativo no desempenho das organizações de software.

Outro passo significativo para a melhoria da qualidade do software foi dado com o Personal

Software Process (PSP). O PSP estende o processo de melhorias às pessoas que realmente fazem o trabalho — os engenheiros, concentra-se nas práticas de trabalho destes, e baseia -se no principio de que para produzir sistemas de software de qualidade, todo engenheiro que trabalha no sistema tem que desenvolver trabalho de qualidade.

O PSP é projectado para ajudar os profissionais de software de forma consistente,

mostrando-lhes como planear e gerir o seu trabalho, como usar um processo definido, como estabelecer objectivos mensuráveis e como medir o desempenho mediante esses objectivos. O PSP mostra aos engenheiros como gerir a qua lidade desde o início do trabalho, como analisar os resultados de cada trabalho e como usar essa informação para melhorar o processo de desenvolvimento de projectos futuros.

3. Princípios do PSP

O desenvolvimento de software usando o PSP baseia -se nos seguintes princípios de planeamento e qualidade:

? todo o engenheiro é diferente: para o engenheiro ser mais eficaz, tem de planear o seu

trabalho, e tem de basear esse planeamento na sua experiência e na sua informação pessoal;

? para melhorar constantemente o seu desempenho o engenheiro tem de usar processos avaliados e bem definidos;

? para produzir produtos de qualidade o engenheiro deve sentir-se pessoalmente responsável pela qualidade dos seus produtos ("Produtos de qualidade superior não são produzidos por acaso"). É imperativo que o engenheiro se esforce por produzir com qualidade;

? custa menos encontrar e corrigir defeitos em fases iniciais do processo de desenvolvimento do que em fases finais ou após a conclusão;

? é mais eficiente prevenir defeitos do que encontrá-los e corrigi-los; ? o caminho mais correcto nem sempre é o mais rápido e mais barato para executar um

trabalho;

Em resumo podemos dizer que para se fazer um trabalho de engenharia de software da forma correcta, um engenheiro tem de planear o seu trabalho antes de se comprometer ou começar eficazmente a trabalhar no projecto. Para fazer tal planeamento deve usar um processo definido. Para compreender e retirar dividendos do seu desempenho pessoal deve medir o tempo que gasta em cada passo do trabalho, os defeitos que introduzem e removem e os tamanhos dos produtos criados. Para criar produtos de qualidade, o engenheiro deve planear, medir, e concentrar-se na qualidade desde o início do processo, deve ainda analisar os resultados de cada trabalho e usá-los para melhorar.

4. Estrutura do processo PSP

A estrutura do processo de desenvolvimento baseado em PSP é mostrada conceptualmente na figura 1. Começando com a especificação dos requisitos, o primeiro passo no processo é o planeamento. Há um script de planeamento que guia o trabalho e um sumário de projecto que



regista todos os dados de planeamento. Enquanto os engenheiros seguem o script na execução do o seu trabalho, registam, ao mesmo tempo, informação relativa aos seus tempos e aos defeitos detectados e introduzidos nos logs correspondentes.

Uma vez terminado o trabalho, durante a fase postmortem (PM), resumem a informação relativa a tempos e defeitos dos logs correspondentes, avaliam o tamanho do programa, e introduzem esta informação no sumário de projecto. Terminada esta operação, entregam o produto acabado juntamente com o sumário de projecto (tabela 1) mencionado.

Figura 1- Fluxo do processo PSP de outra forma,

Figura 2 – Projecto PSP



Um script de PSP (tabela 2) é o que Deming chamou de processo operacional. Por outras palavras, é um processo projectado para ser usado, é construído num formato simples de usar com instruções curtas e precisas. No entanto importa salientar que os scripts não incluem os materiais didácticos que seriam necessários para utilizadores inexperientes (principiantes).

O propósito do script é guiar o engenheiro a usar, constantemente, um processo por ele

entendido. Nos vários tópicos desta secção vamos então especificar os vários métodos que o PSP usa para planear, estimar, recolher informação e gerir qualidade e design.

Figura 3 – Resumo de um plano de projecto PSP



Figura 4 – Elementos do processo PSP

Tabela 1 – Script de processo em PSP1

Fase Objectivo Guia do desenvolvimento de módulos das aplicaçõesDescrição do problemaFormulário relativo ao sumário do plano de um projecto PSP.Formulário para estimar o tamanho.Calcular tamanho com base nos dados de histórico e actuais.Logs para registo de tempos e defeitos.Tipos de defeitos 'standard'.Paragem para verificação (opcional).Produzir ou obter especificações de requisitos.Usar o método de PROBE para estimar o total de linhas de código novas e alteradas.Completar o formulário de estimativa de tamanho.Estimar o tempo de desenvolvimento necessário.Introduzir o plano no formulário correspondente ao sumário do projecto.Completar o log de registo de tempos.Desenhar o programa.Implementar o programa.Compilar o programa, corrigir e registar todos os defeitos encontrados.Testar o programa, corrigir e registar todos os defeitos encontrados.Completar o log de registo de tempos.

3 Pós Desenvolvimento Completar o sumário do plano do projecto com o tempo actual, defeitos e tamanho.Teste completo do programa.Completar o sumário do plano do projecto com os dados estimados e actuais.Completar o formulário de estimativa de tamanhos.Completar o formulário de relatório de testes.Completar o formulário PIP.Completar os logs de defeitos e de registo de tempos.

1

2

Critério de entrada

Planeamento

Desenvolvimento

Critério de saída



4.1 Planeamento

O processo de planeamento é mostrado na figura 5.

Figura 5 – Processo de planeamento do projecto

4.1.1 Requisitos

No inicio de qualquer projecto é necessário conhecer com exactidão o que é necessário executar para que o planeamento seja feito com o maior rigor possível. O engenheiro começa o planeamento definindo o trabalho que precisa ser executado com o maior detalhe e rigor possível. A precisão da estimativa e a fiabilidade do plano sofrem uma influência inversamente proporcional ao volume de informação recolhida (quanto menor for a informação maior a probabilidade do plano falhar).

4.1.2 Método de PROBE

4.1.2.1 Modelo Conceptual

Para se fazer uma estimativa e construir um plano, um engenheiro define em primeiro lugar como o produto será projectado e construído. No entanto, como na fase de



planeamento ainda é muito cedo para produzir uma especificação completa do produto, é produzido o modelo conceptual.

Este modelo representa uma primeira aproximação ao que será o produto final caso fosse construído apenas com a informação disponível naquele momento. Mais tarde, durante a fase de design, são examinadas alternativas de especificação e é finalmente produzida uma especificação completa do produto.

4.1.2.2 Estimar o Tamanho do Produto

A correlação existente entre o tamanho do programa e o tempo de desenvolvimento é, apenas, moderadamente boa para equipas de engenharia ou para organizações. No entanto, para engenheiros a nível individual, a correlação é geralmente bastante alta, então todo o processo de desenvolvimento individual de software começa com o engenheiro a estimar os tamanhos dos produtos que irão desenvolver. Depois, baseado no tamanho e na informação de produtividade, especificada por cada um deles estima o tempo necessário à execução do trabalho. Usando PSP as estimativas de tamanho e recursos são feitas usando o método PROBE que iremos analisar de seguida.

PROBE representa PROxy Based Estimating e usa proxies ou objectos como a base

para estimar o tamanho de um produto. Usando o PROBE, os engenheiros determinam primeiro, usando o modelo conceptual, os objectos exigidos para construir o produto, em seguida determinam o tipo provável e número de métodos para cada objecto, finalmente e para determinar o tamanho global provável do produto, ou o total de código que planeiam desenvolver, recorrem a informação pessoal relativa aos tamanhos de objectos semelhantes já desenvolvidos utilizando uma regressão linear. Na regressão linear, os engenheiros devem possuir um histórico de informação referente a tamanhos estimados e tamanhos reais de, pelo menos, três programas anteriores.

Os exemplos de tamanhos para objectos da tabela 2 mostram as cinco gamas de tamanhos usados em PSP. Uma vez que os tamanhos dos objectos são uma função do estilo de programação, o PROBE mostra aos engenheiros como usar os dados nos programas por eles desenvolvidos para gerar gamas de tamanho para uso pessoal.

Categoria Muito Pequeno

Pequeno Médio Grande Muito Grande

Cálculo 2.34 5.13 11.25 24.66 54.04 Dados 2.60 4.79 8.84 16.31 30.09 I/O 9.01 12.06 16.15 21.62 28.93 Lógica 7.55 10.98 15.98 23.25 33.83 Set-up 3.88 5.04 6.56 8.53 11.09 Texto 3.75 8.00 17.07 36.41 77.66

Tabela 2 - C++ Tamanho dos objectos em linhas de código (LOC) por método

4.1.2.3 Estimar os recursos

O método PROBE também usa regressão linear para estimar os recursos necessários

ao processo de desenvolvimento. Mais uma vez esta estimativa é baseada na informação relativa a tamanhos estimados e tamanhos reais de, pelos menos, três programas



anteriores. Os dados devem demonstrar uma correlação razoável entre tamanho do programa e tempo de desenvolvimento. O PSP requer que a correlação seja de, pelo menos, 0.5.

Uma vez estimado o tempo total para o trabalho, o engenheiro utiliza a sua informação na estimativa do tempo necessário para cada fase do trabalho, aqui entra a coluna ToDate% do sumário de projecto mostrado na figura 3. ToDate% mantém uma “conta corrente” da percentagem de tempo de desenvolvimento total que um engenheiro passou em cada fase de desenvolvimento. Usando estas percentagens como referência, os engenheiros alocam o seu tempo de desenvolvimento total estimado às fases de planeamento, design, revisão do design, codificação, revisão de código, compilação, teste, e postmortem. Terminada a alocação de tempos obtém-se uma estimativa para:

? O tamanho do programa ? O tempo de desenvolvimento total ? O tempo requerido em cada fase de desenvolvimento

4.1.3 Produção do Calendário

Uma vez conhecido, pelo engenheiro, o tempo necessário para cada passo do processo, este deve estimar o tempo que será gasto a trabalhar no projecto por dia ou por semana. Com esta informação, podem então distribuir o tempo de cada tarefa pelas horas planeadas disponíveis para assim obterem o tempo planeado para completar cada tarefa.

4.1.4 Desenvolver o Produto

Neste passo o engenheiro faz o trabalho de programação propriamente dito. Apesar deste trabalho não ser, normalmente, considerado como parte integrante do processo de planeamento, o engenheiro deve usar a informação resultante deste processo para planeamentos futuros.

4.1.5 Analisar o Processo

Depois de completar um projecto, os engenheiros fazem uma análise postmortem, nesta fase actualiza o sumário de projecto com dados actuais, calcula o desempenho e analisa a sua resposta ao planeado. Ainda como passo de planeamento final actualizam a informação pessoal relativa à produtividade, examina qualquer proposta de melhoria do processo e ajustes ao mesmo. Revê os erros encontrados nas fases de compilação e testes e actualiza mais uma vez a informação pessoal, que o poderá ajudar a encontrar e corrigir erros semelhantes no futuro.

5. Recolha de informação

O engenheiro usa a informação para monitorizar o seu trabalho e para o ajudar a construir planos melhores. Para isso recolhe informação relativamente ao tempo gasto em cada fase do processo, aos tamanhos dos produtos produzidos, e à qualidade dos mesmos.

5.1 Medir Tempos

Em PSP os engenheiros medem o tempo gasto em cada fase do processo (“time recording log”). Neste log são registados todos os tempos que interferem nas fases do processo, como



sendo, o início do trabalho, tempos de interrupção e duração da interrupção. Com este controlo de tempo de uma maneira sistemática e precisa é possível ter uma noção do esforço gasto nas tarefas do projecto.

Ignorar os tempos de interrupção implica um aumento significativo da redução da

precisão da estimativa.

5.2 Calcular Tamanhos

Uma vez que o tempo gasto para desenvolver um produto é essencialmente determinado pelo seu tamanho, ao usar PSP estimam-se inicialmente os tamanhos dos produtos a desenvolver e em seguida, quando estes estiverem concluídos, medem-se os tamanhos reais. Isto proporciona ao engenheiro informação relativa a tamanhos necessários para que possam fazer estimativas de tamanhos precisas. Porém, para que esta informação seja útil, a medida de tamanho devem ser correlacionadas com o tempo de desenvolvimento do produto. Apesar do número de linhas de código (LC) ser a principal medida de tamanho em PSP, qualquer medida de tamanho pode ser usada, proporcionando uma correlação razoável entre tempo de desenvolvimento e tamanho de produto.

5.2.1 Linhas de Código (LC)

Os engenheiros devem definir precisamente como pretendem medir as linhas de código (LC). Quando trabalham em equipa ou numa organização de software, devem usar o padrão de linhas de código da equipa ou organização, caso não exista nenhum padrão definido, o PSP guia-os na definição do seu próprio padrão.

Considerando que ao usar PSP é exigido que se meçam os tamanhos dos programas a produzir, e uma vez que contar manualmente as linhas de código é dispendioso e pouco exacto, o PSP ajuda os engenheiros na escrita de dois contadores automáticos de linhas de código.

5.2.2 Categorias dos Tamanhos

Para ser possível controlar a variação do tamanho do programa durante o desenvolvimento, é necessário considerar várias categorias avaliadas segundo o número de linhas de código.

? Base - Quando um produto é aumentado, o base LC, é o tamanho da versão

original do produto antes de qualquer modificação ser feita. ? Adicionadas - corresponde à quantidade de código novo escrito, para um novo

programa ou para um programa base existente. ? Modificadas - corresponde à quantidade de código alterada num programa. ? Eliminadas - corresponde à quantidade de código eliminado do programa base

existente. ? Novas e modificadas - Quando os engenheiros desenvolvem software, ocupa-lhes

muito mais tempo adicionar ou modificar linhas de código do que apagar ou reutilizar. Assim, ao usar PSP, os engenheiros só usam o código adicionado ou modificado para fazer estimativas de tamanho e de recursos.

? Reutilizadas - corresponde ao código que é retirado duma biblioteca de código reutilizável e que é utilizado sem qualquer modificação num novo programa ou numa nova versão do programa. Esta categoria não contabiliza as linhas de código base duma versão anterior do programa, assim como não contabiliza o código que é reutilizado com modificações.



? Novas reutilizadas - corresponde às linhas de código desenvolvidas e que contribuem para o aumento das bibliotecas de código reutilizável.

? Total - Corresponde ao tamanho do programa independentemente da categoria do código.

5.2.3 Contabilizar Tamanhos

Ao modificar programas, é frequentemente necessário identificar mudanças feitas ao programa original, estes dados são usados para determinar o volume do produto desenvolvido, a produtividade do engenheiro, e a qualidade do produto. Para obter estes dados o PSP usa o método size accounting para identificar todas as adições, remoções, e mudanças feitas num programa.

Para usar o método size accounting os engenheiros precisam de dados relativos à quantidade de código referente a cada categoria de tamanho. Exemplo: Se um produto de 10,000 LC fosse usado para desenvolver uma versão nova, e havia 2,000 LC de código apagado, 3,000 LC de código adicionado, 500 LC de código modificado, e 300 LC de código reutilizado, então:

LC Novas e Modificadas = LC Novas + LC Modificadas

LC Novas e Modificadas = 3000 + 500

Para medir o tamanho total de um produto, os cálculos a efectuar são os seguintes:

LC Total = Base + Eliminadas + Reutilizadas Total LOC = 10,000-2,000 + 300 + 3,000 = 11,300 LOC

Nota: LC modificadas e LC novas reutilizadas não são incluídas em LC Total uma vez que as LC modificadas podem ser representadas por LC eliminadas e LC adicionadas. LC Novas reutilizadas já está incluído em LC adicionadas.

5.3 Medidas de Qualidade

Em PSP a atenção principal a nível da qualidade reside nos defeitos do produto. Para fazer uma gestão de defeitos os engenheiros precisam de informação relativa a defeitos introduzidos, às fases em que foram introduzidos, às fases em que foram detectados e corrigidos e ao tempo gasto para os corrigir. Em PSP, e como já foi visto anteriormente, os engenheiros registam todos os defeitos encontrados em todas as fases, incluindo as fases de revisão, inspecção, compilação e de testes no log de registo de defeitos (defect recording log).

Quando nos referimos a defeito é o mesmo que referir a algo que está errado no

programa, pode ser uma palavra mal escrita, um erro de pontuação, ou uma linha de código incorrecta. Os defeitos podem ser encontrados no código, no design ou até mesmo nos requisitos ou outra documentação, ou seja, podem ser encontrados em qualquer fase do processo de desenvolvimento. Na realidade, um defeito é algo que faz com que o objectivo final do desenvolvimento do programa (satisfação dos requisitos) não seja atingido de todo ou parcialmente.



Com informação relativa a tamanhos, tempos, e defeitos, há muitas formas de medir, avaliar, e gerir a qualidade de um programa. O PSP fornece um conjunto de medidas que ajudam os engenheiros a examinar a qualidade dos seus programas de várias perspectivas, são as designadas medidas de qualidade. Uma vez que nenhuma medida, quando usada isoladamente, consegue fornecer um indicador adequado da qualidade global do programa, é conveniente utilizarmos todo o conjunto de medidas para que se possa obter um indicador de qualidade fiel.

As principais medidas de qualidade são:

? Densidade de defeitos ? Taxa de revisão ? Taxas de tempos de desenvolvimento ? Taxas de defeitos ? Rendimento ? Defeitos por hora ? Força de remoção de defeitos ? Apreciação das taxas de falhas (A/FR)

Densidade de defeitos - Consiste nos defeitos LC Novas e LC modificadas no

programa. É medida para todo o processo de desenvolvimento e para algumas fases específicas do processo.

Atendendo ao facto de na fase de testes apenas se conseguir remover uma pequena parte

dos defeitos no produto então é fácil concluir que quando existem defeitos de entrada na fase de testes existirão muitos mais na sua conclusão.

O número de defeitos detectados durante a fase de testes é um bom indicador do

número de defeitos que permanecerão após a conclusão do projecto. Quando na fase de testes são detectados poucos defeitos pode-se pressupor que a

qualidade dos programas é elevada. Para se considerar um programa de boa qualidade na fase de testes é necessário que o número de defeitos/KLC seja menor ou igual a cinco (em situações sem que não á aplicada a metodologia PSP temos valores entre 0s 20 e 40 defeitos/KLC).

Taxa de revisão - Dados estatísticos mostram que quando os engenheiros nas fases de revisão analisam mais do que 150 a 200 LC (Novas e Modificadas) por hora os defeitos são mais frequentes. Usando PSP os engenheiros juntam informação relativa às revisões feitas, isto para que possam determinar a sua velocidade máxima de revisão, de forma a encontrar um maior número de defeitos do programa.

Taxas de tempos de desenvolvimento – consiste nas relações de tempo gasto em duas fases de desenvolvimento. As três relações de tempo de desenvolvimento usadas na avaliação do processo são:

? Tempo de relativamente ao tempo de codificação ? Tempo de revisão de relativamente ao tempo design ? Tempo de revisão de código relativamente ao tempo de codificação.

A relação entre o tempo de design e o tempo de codificação é bastante útil para

determinar a qualidade do trabalho de design. Quando é gasto menos tempo no design do



que na codificação, significa que grande parte do design está a ser produzido durante o processo de codificação, ou seja, o design não é documentado, não podendo assim ser revisto ou inspeccionado. Nesta situação a qualidade do design é provavelmente pobre.

Uma das directrizes da metodologia PSP diz que o tempo gasto para produzir um design

(detalhado) deve ser, pelo menos, igual ao tempo gasto a codificar. A relação sugerida entre tempo de revisão de design e tempo de design é baseada nos

dados mostrados na tabela seguinte. Pela avaliação da tabela podemos ver que foram introduzidos em média 1.76 defeitos/hora na fase de design detalhado e removidos em média 2.96 defeitos/hora nas revisões de design. Isto leva-nos a outra directriz da metodologia PSP que diz que o tempo da fase de revisão de design deve ser pelo menos metade do tempo da fase de design.

Fase Def. Introduzidos

/ Hora

Def. Removidos /

Hora Design 1.76 0.10 Revisão do design

0.11 2.96

Codificação 4.20 0.51 Revisão do código

0.11 6.52

Compilação 0.60 15.84 Teste 0.38 2.21

Tabela 3 - Introdução e remoção de defeitos

A relação entre tempo de revisão de código e tempo de codificação é, também, útil para

avaliar a qualidade do processo. Recorrendo à tabela anterior verificamos que durante a fase de codificação em média são introduzidos 4.20 defeitos/hora e removidos em média 6.52 defeitos/hora nas revisões de código. Uma outra directriz da metodologia PSP diz respeito à relação entre tempo de revisão de código e tempo de codificação, a qual deve ser de aproximadamente 50%.

Taxas de defeitos - estes rácios comparam os defeitos detectados numa fase aos defeitos detectados noutra. Os rácios principais a considerar são:

compilação a durante detectados defeitos

código de revisão durante detectados defeitos

testes de fase a durante detectados defeitos

design de revisão a durante detectados defeitos

Uma das regras definidas é que os engenheiros deveriam detectar, pelo menos, o dobro

dos defeitos detectados na fase de compilação na fase de revisão de código. A quantidade de defeitos detectados na fase de compilação é uma medida objectiva da qualidade do código gerado. Quando os engenheiros detectam mais do dobro dos defeitos na fase de revisão do código significa, geralmente, que fizeram uma revisão de código competente ou então não registaram todos os defeitos detectados durante a fase de compilação.



Uma outra regra definida é relativa ao rácio, o qual relaciona a revisão de design com a fase de testes deverá ser igual ou maior que dois. Para analisar se uma boa revisão de design foi feita podemos comparar o número de defeitos detectados durante a fase de revisão de design com o número de defeitos detectados durante a fase de testes, se o primeiro valor corresponder ao dobro do segundo então podemos conclu ir que realmente houve uma boa revisão de design.

Em PSP usam-se estes dois rácios em combinação com os rácios temporais e medidas

de densidade de defeitos para indicar se o programa está ou não pronto para ser integrado e testado. O rácio dado pela revisão de código e compilação indica a qualidade de código, enquanto que o rácio dado entre revisão de design e testes indica a qualidade de design. Se qualquer uma destas duas medida for fraca, os critérios de qualidade de PSP sugerem que provavelmente o programa virá a ter problemas em testes ou usos posteriores.

Rendimento - o rendimento é medido de duas formas:

? Rendimento de fase ? Rendimento de processo

O rendimento de fase mede a percentagem global de defeitos detectados e removidos na

fase em causa. Por exemplo, se um programa entrasse na fase de testes com 20 defeitos e só fossem detectados 9, o rendimento seria de 45%. De forma semelhante se um programa entrasse na fase de revisão de código com 50 defeitos e só fossem detectados 28, o rendimento seria de 56%.

O rendimento de processo contabiliza a percentagem de defeitos removida antes da

primeira fase de compilação e de testes. Considerando que o objectivo da metodologia PSP é o de produzir programas de alta qualidade, o valor que se deve ter como referência para o rendimento de processo é de pelo menos 70%.

A medida de rendimento não pode ser calculada com precisão antes do fim do ciclo de

vida útil de um programa. Até essa altura, presumivelmente, todos os defeitos teriam sido detectados e registados. No entanto quando os programas são de alta qualidade podem, normalmente, ser feitas bastante cedo estimativas de rendimento razoavelmente boas.

É importante referir uma outra directriz da metodologia PSP segundo a qual para

estimar o rendimento é preciso assumir que o número de defeitos que permanecem no programa é igual ao número de defeitos detectados na última fase de testes. Sendo assim, na tabela 4, é provável que sete defeitos permaneçam após a fase de testes.

Fase Defeitos removidos Revisão do design

11

Revisão do código

28

Compilação 12 Teste 7 Total 58

Tabela 4 – Defeitos removidos



Fase Defeitos introduzidos

Defeitos removidos

Design detalhado

26 0

Revisão do Design

0 11

Código 39 0 Revisão de código

0 28

Compilação 0 12 Teste 0 7 Após Teste 0 7 Total 65 65

Tabela 5 - Defeitos introduzidos e removidos

Para calcular o rendimento é usada a informação relativa às fases nas quais os defeitos foram introduzidos. É necessário assumir os defeitos que permanecem depois da fase de testes, foram introduzidos nas mesmas fases que os defeitos detectados durante esta fase de teste. Na tabela anterior temos um defeito deste tipo na fase de codificação e seis na fase de design detalhado.

Como podemos ver na tabela seguinte, o total de defeitos introduzidos, incluindo os que

se estimam permanecer, é de 65. Na célula destinada à revisão de design temos 26 defeitos presentes sendo assim o rendimento da fase de revisão de design 100*(11/26) = 42.3%. Na célula correspondente à revisão de código, temos um total de 65 defeitos aos quais se reduz os que foram removidos na revisão de design, ou seja, 65 - 11 = 54, assim o rendimento da fase de revisão de código foi de 100*28/54 = 51.9%. De uma forma semelhante, o rendimento da fase de compilação foi 100*12/(65-11-28) = 46.2%.

O rendimento de processo é a melhor medida global de qualidade do processo, e

corresponde à percentagem de defeitos introduzidos antes da fase de compilação que são removidos antes dessa mesma fase. Para os dados da tabela 6, o rendimento de processo é 100*39/65 = 60.0%.

Fase Defeitos introduzidos

Defeitos removidos

Defeitos no inicio da fase

Rendimento da fase

Design detalhado 26 0 0 --

Revisão do design 0 11 26 42.3%

Codificação 39 0 15 -- Revisão do código 0 28 54 51.9%

Compilação 0 12 26 46.2% Teste 0 7 14 50.0% Após teste 0 7 7 -- Total 65 65 -- --

Tabela 6 – Cálculos de Rendimento



Defeitos por hora - com a informação que vai sendo recolhida os engenheiros podem calcular o números de defeitos que introduzem e removem por hora, e podem usar esta medida para guiar o planeamento pessoal. Por exemplo, se um engenheiro introduziu quatro defeitos por hora na fase de codificação e corrigiu oito defeitos por hora na fase de revisão de código, ele precisaria de passar aproximadamente 30 minutos em revisões de código por cada hora de codificação. As taxas de defeitos por hora podem ser calculadas a partir da informação presente no sumário de projecto.

Força de remoção de defeitos - mede a eficácia relativa de duas fases de remoção de defeitos. Por exemplo, dos exemplos prévios, a influência de remoção de defeitos na revisão de design relativamente à detestes seria de 3.06/1.71 = 1.79. Isto significa que o engenheiro seria 1.79 vezes mais eficaz a detectar defeitos na fase de revisão de design do que na fase de testes. O DRL ajuda o engenheiro a definir o plano de remoção de defeitos da forma mais eficaz.

A/FR - mede a qualidade do processo de engenharia. O A representa o custo da avaliação de qualidade, ou a percentagem de tempo de

desenvolvimento gasto em actividades de avaliação de qualidade. Em PSP o custo de avaliação é o tempo gasto em revisões de design e de código, incluindo o tempo gasto a corrigir os defeitos detectados nessas revisões.

O F representa o tempo gasto na recuperação de um fracasso. O custo de fracasso é o

tempo gasto nas fases de compilação e de testes, incluindo o tempo gasto a procurar, corrigir, recompilar, e voltar a testar os defeitos detectados.

Esta medida fornece um modo útil para que se possa avaliar qualidade, tanto para

programas individuais como para comparar a qualidade dos processos de desenvolvimento usado para vários programas. Indica também o grau de brevidade com que o engenheiro tentou detectar e corrigir os erros no processo de desenvolvimento.

O valor de referência para esta medida é maior ou igual a dois, isto garante que o design

e a revisão de código foram planeados com um tempo adequado. 6 Gestão de Qualidade

A qualidade do software é um factor cada vez mais importante; um software com erros pode causar sérios problemas. Com a tendência de crescimento da velocidade de processamento, complexidade e de automatismo aumenta também a probabilidade de existirem falhas nesses mesmos sistemas, falhas essas que podem ser bastante prejudiciais.

Em sistemas de software de grande dimensão a qualidade destes sistemas depende da

qualidade de todas as partes constituintes do software (módulos, componentes).

6.1 Defeitos e Qualidade

Os produtos de software de qualidade devem satisfazer os requisitos do utilizador e executar as tarefas para as quais foram concebidos de uma forma fiável e consistente. Apesar da funcionalidade do software ser muito importante para os utilizadores, ela não é utilizável a menos que o software funcione bem, portanto para cumprir esta obrigatoriedade é necessário que todos os seus defeitos sejam removidos.



Apesar de existirem muitos aspectos relacionados com a qualidade de software, a primeira preocupação do engenheiro deve ser necessariamente detectar e corrigir defeitos. Dados estatísticos mostram que até mesmo os programadores mais experientes introduzem um defeito em cada sete a dez linhas de código. No entanto durante as fase de compilação e de testes a maioria destes defeitos são detectados e corrigidos.

Simples enganos de codificação podem produzir defeitos muito destrutivos ou difíceis

de detectar, reciprocamente muitos defeitos de design sofisticados são frequentemente fáceis de detectar, logo, podemos concluir que o engano e as suas consequências são bastante independentes. É importante ter em conta que até mesmo erros de implementação triviais podem causar problemas sérios ao sistemas, isto é particularmente importante dado que a fonte da maioria dos defeitos de software são simples omissões ou enganos por parte do programador. Apesar dos pormenores de design serem sempre bastante importantes, o software que é desenvolvido de raiz tem tipicamente muito poucos erros de design quando comparados com a quantidade de simples enganos.

6.2 A Responsabilidade do Engenheiro

A metodologia PSP tem como primeiro principio de qualidade a responsabilização do engenheiro pela qualidade do software que produz. Uma vez que está mais familiarizado com o software e por consequência é a pessoa que de uma forma eficiente e eficaz pode detectar, corrigir e prevenir defeitos do programa. A metodologia PSP fornece uma série de práticas e medidas para ajudar o engenheiro a avaliar a qualidade dos programas que produz e para o guiar na detecção e correcção dos defeitos do programa de uma forma rápida.

6.3 Remoção de Defeitos

O principal objectivo de qualidade em PSP é detectar e corrigir defeitos antes da primeira fase de compilação ou de testes. O processo de PSP inclui passos de revisão de design e de código nos quais o engenheiros revê pessoalmente os seus produtos antes destes serem inspeccionados, compilados, ou testados. O princípio que está por trás do processo de revisão em PSP é de que as pessoas tendem a cometer os mesmos erros repetidamente, então analisando dados relativos aos defeitos introduzidos e construindo uma checklist das acções necessárias para detectar esses defeitos, os engenheiros podem detectar e corrigir defeitos de uma forma muito mais eficaz.

Como exemplo podemos referir que engenheiros experientes na aplicação dos

princípios de PSP detectam uma média de 6.52 defeitos/hora em revisões de código pessoal e 2.96 defeitos/hora em revisões de design pessoal.

6.4 Prevenção de Defeitos

O modo mais eficaz para gerir defeitos é prevenir a sua introdução. Em PSP, existem três formas de prevenção de defeitos:

1º Exigir que os engenheiros registem a informação relativa a cada defeito que detectam e

corrigem, para que possam posteriormente rever toda esta informação e determinar causa dos defeitos, fazendo assim mudanças no processo a fim de as eliminar. Avaliando os seus defeitos, os engenheiros estão mais conscientes e atentos aos seus erros, estão mais sensíveis às suas consequências, tendo a informação necessária para evitar cometer os mesmos erros no futuro;



2º Usar um método de design eficaz e uma notação para produzir um design completo, é

vital que os engenheiros entendam isto claramente, pois não só produz melhores designs , como leva a uma menor introdução de defeitos de design;

3 º Com um design mais completo, o tempo de codificação será menor, reduzindo assim a

introdução de defeitos.

Estatisticamente : durante a fase de design são introduzidos em média de 1.76 defeitos/hora, enquanto que durante a fase de codificação introduzem 4.20 defeitos/hora. Considerando que o tempo de codificação de um design bem documentado e especificado é reduzido, podemos deduzir que o número de defeitos introduzidos é consequentemente reduzido.

7. Design em PSP

Apesar do PSP poder ser usado com qualquer método de design, este requer que o design seja completo. O PSP considera que um design está completo quando este define as quatro dimensões referidas na estrutura de especificação do objecto mostrada na tabela 7. A correspondência entre os quatro modelos e a estrutura de especificação do objecto é mostrada na tabela 8.

Object

Specification Internal External

Static Attributes

Constraints

Inheritance

Class Structure

Dynamic State Machine

Services

Messages

Tabela 7 – Estrutura de especificação do objecto

Object Specification Templates

Internal External

Static Logic Specification Template

Function Specification Template (Inheritance Class Structure)

Dynamic State Machine Template

Functional Specification Template (User Interaction)

Operational Scenario Template Tabela 8 – Correspondência entre modelos e estruturas de especificação

Onde:



? Operational Scenario Template - define a forma de interacção dos utilizadores com o sistema;

? Function Specification Template – define o comportamento de chamada, de

retorno dos objectos, das classes do programa e define a estrutura de classes e heranças;

? State Specification Template - define o comportamento da máquina de estados do

programa; ? Logic Specification Template - específica a lógica interna do programa,

normalmente em pseudocódigo; 8. O PSP e as Melhorias no Processo de Desenvolvimento

Existem três abordagens possíveis para a melhoria dos processos de desenvolvimento, que são:

? O Capacity Maturity Model (CMM) que incide sobre aspectos de gestão de

software; ? O Personal Software Process (PSP); ? O Team Software Process (TSP), guia engenheiros, equipas e gestores treinados

no uso das práticas de PSP no desenvolvimento intensivo de produtos.

Apesar destes métodos estarem todos relacionados, eles focam diferentes aspectos da capacidade organizacional. Temos portanto que ter em conta também quatro requisitos fundamentais.

1º Para elaborar produtos superiores a administração da organização deve

obrigatoriamente ter uma boa estratégia, um bom plano empresarial, assim como um conjunto de produtos que estejam de acordo com as necessidades de mercado. Sem estas três componentes mencionadas as organizações não podem ter sucesso independentemente das suas outras características;

2º Para elaborar produtos superiores a administração deve obter altos desempenhos

dos seus engenheiros. Isto requer a contratação de pessoas capazes orientação e apoio satisfatórios;

3º Os engenheiros devem poder trabalhar em conjunto eficazmente e num ambiente

em que o espirito de equipa é dominante. Para além disto, devem saber como elaborar produtos de qualidade de forma consistente;

4º As equipas de engenharia devem ser treinadas correctamente e ser capazes de fazer

um trabalho de engenharia disciplinado.

Sem qualquer uma destas condições as organizações têm pouca probabilidade de fazer um trabalho superior. Das condições referidas acima, temos o Capacity Maturity Model (CMM) projectado para satisfazer o segundo requisito, o Team Software Process (TSP) para o terceiro e o PSP para o quarto.

Em resumo podemos concluir que se os engenheiros não tiverem as capacidades fornecidas pelo treino em PSP, não conseguem apoiar as suas equipas de desenvolvimento, nem produzir correcta e consistente produtos de qualidade. Assim se as equipas não forem formadas e



orientadas convenientemente, não podem gerir o seu trabalho nem cumprir prazos. Finalmente, sem uma administração conveniente e liderança executiva, as organizações não podem ter sucesso independentemente de possuir outras capacidades.



Team Software Process (TSP)



1 Qualidade do software

O desenvolvimento com a metodologia Team Software Process (TSP) segue a estratégia de qualidade que foi criada por W. Edwards Deming e J.M. Juran. Esta estratégia foi extendida aos processos de software por Michael Fagan em 1976. Posteriormente foi introduzido o modelo “Capability Maturity Model” (CMM) em 1987 e o Personal Software Process (PSP) em 1995.

A seguir ao PSP, o passo mais importante na melhoria dos processos de software refere-se à

introdução do Team Software Process (TSP), o qual fornece um contexto disciplinado para o trabalho de engenharia. O principal factor motivador para o desenvolvimento do PSP foi a convicção de que equipas de engenheiros podem realizar um trabalho extraordinário, mas somente se estiverem convenientemente formados, treinados, trabalharem em conjunto com elementos experientes, se forem geridos por elementos experientes e com uma gestão eficaz. O objectivo do PSP é o de construir e guiar tais equipas.

2 Como foi desenvolvido o TSP

Em 1996, Watts Humphrey desenvolveu a versão inicial do processo TSP. O seu objectivo

era fornecer um processo operacional para ajudar de uma forma consistente os engenheiros a realizarem o seu trabalho com qualidade. Foi então desenhado o TSP0 que deveria ser o mais simples possível, testado com duas equipas e posteriormente analisado o resultado para verificar a forma como tal decorreu. Foi então identificado onde as equipas necessitavam de mais ajuda e de melhoria dos processos.

Baseado nos resultados obtidos das equipas iniciais de TSP, ficou claro que o TSP ajudava

engenheiros a disciplinar o seu trabalho mas era necessário mais acompanhamento e suporte. Um melhoramento TSP0.1 foi então usado por outras equipas, fornecendo mais informação ao nível dos refinamentos dos processos.

Ao longo de três anos, Humphrey desenvolveu mais nove versões do TSP. No inicio a sua

intenção era verificar se um objectivo geral ao nível dos processos poderia ajudar as equipas de engenheiros no seu trabalho. Uma vez que ficou claro que o TSP atingia o seu objectivo básico, o esforço de desenvolvimento do TSP foi direccionado para a melhoria de processos, redução do seu tamanho, e fornecimento de suporte e orientação necessária para tornar o processo mais eficiente e útil.

Como resultado, verifica-se que as versões mais recentes do TSP, são substancialmente

mais pequenas do que as versões de TSP0.1 e TSP0.2 desenvolvidas em 1996 e 1997.

À medida que o número de grupos a utilizarem o TSP foi aumentando, vários métodos de melhoria foram desenvolvidos para assistirem os engenheiros e gestores na construção das equipas, no seguimento dos processos e num replaneamento periódico dos projectos. Foram também desenvolvidas várias ferramentas de suporte para simplificar o planeamento, registo de dados, análise dos dados e de relatórios de actividade.

2.1 Equipas de trabalho

As equipas são necessárias para a maior parte de projectos de engenharia. Todavia alguns pequenos produtos de software ou hardware podem ser desenvolvidos individualmente. O tamanho e a complexidade dos sistemas modernos é tão grande que obriga a curtos prazos de desenvolvimento, inviabilizando a realização dos trabalhos por parte de uma só pessoa.



O desenvolvimento dos sistemas é uma actividade de equipa cuja dimensão determina a qualidade dos projectos.

Embora as equipas de desenvolvimento possam ter muitos especialistas, todos os

membros trabalham em conjunto no caminho de um único objectivo. Uma equipa é algo mais do que simplesmente um grupo de pessoas que trabalham no mesmo local. Equipas requerem processos comuns, devem acordar os objectivos e necessitam de encaminhamento e liderança. Os métodos para o encaminhamento e liderança de tais equipas são bem conhecidos mas não são óbvios.

2.2 Condições para o trabalho em equipa

Uma equipa consiste num conjunto de pessoas que partilham um objectivo comum. Todas elas devem estar comprometidas com esse mesmo objectivo e partilharem as ferramentas de trabalho.

Definição de equipa adoptada por Dyer em 84:

? Uma equipa é constituída pelo menos por duas pessoas. ? Os membros da equipa trabalham em conjunto em direcção a um objectivo comum. ? A cada pessoa é atribuído um papel específico. ? O atingir do objectivo requer alguma dependência entre os membros do grupo.

Não é óbvio o porquê dos membros da equipa necessitarem de ter papeis definidos. Os

papeis dão a cada elemento da equipa uma sensação de pertença e posse. Eles ajudam a focar os membros da equipa na realização do seu trabalho, previnem os conflitos, a duplicação de trabalho e eliminam o esforço desperdiçado, bem como, dão ao elemento um elevado grau de controlo sobre o seu ambiente de trabalho.

A interdependência também é um elemento importante numa equipa de trabalho. Onde cada elemento da equipa depende em algum grau do desempenho de algum dos seus membros. A interdependência melhora o desempenho individual uma vez que os elementos da equipa ajudam-se e complementam-se mutuamente. Com a interajuda mutua e a interdependência, as equipas são algo mais do que uma soma dos seus elementos de uma forma individual.

2.3 Equipas eficazes

Para ser uma equipa eficaz, é necessário que esteja habilitada para as tarefas e que seja capaz de trabalhar em unidades coesas. Equipas eficazes têm determinadas características comuns:

? Os membros são habilitados; ? O objectivo da equipa é importante, definido, visível e realista; ? Os recursos da equipa são adequados para o trabalho; ? Os membros da equipa estão motivados e comprometidos no objectivo a atingir; ? Os membros da equipa colaboram entre eles; ? Os membros da equipa são disciplinados no seu trabalho.

Outra característica de uma equipa eficaz é a sua capacidade para inovar. Inovar é algo mais do que ter brilhantes ideias, requer criatividade e muito trabalho. As equipas inovadoras devem ter elementos habilitados e capazes altamente motivados. Estes devem ser criativos,



flexíveis e disciplinados, devem esforçar-se por cumprir o plano e ajustarem-se ás mudanças necessárias, bem como controlar custos e planos enquanto mantêm os gestores informados dos seus progressos.

Para ser inovadora e eficaz, uma equipa deve trabalhar sob um ambiente de confiança e de interajuda. As equipas são compostas por pessoas extremamente capazes que podem rapidamente sentir a necessidade de confiança. Quando os gestores não confiam nas suas equipas para realizar planos agressivos ou para se esforçarem para atingirem os objectivos, os elementos da equipa saberão isso. Quando os elementos da equipa não sentem que têm confiança neles e quando não são respeitados, muitas vezes sentem-se colocados á parte e manipulados. Estes elementos já não sentem comprometidos com a organização e podem facilmente perder o compromisso com a equipa.

Tendo em conta que as pessoas geralmente trabalham arduamente quando enfrentam

grandes desafios, é importante para a gestão desafiar os seus elementos com objectivos agressivos. Mas quando as equipas respondem ao desafio com um plano, a gestão deve estar disposta a negociar compromissos realistas que os elementos acreditem que podem cumprir. Poucas pessoas trabalham de uma forma empenhada sobre um plano que parece inatingível ou irrealista. Para trabalhar de uma forma eficiente, as equipas devem acreditar que os seus projectos são importantes e que os objectivos são exequíveis.

2.4 Criar equipas eficazes

O TSP foi desenhado para estabelecer as condições que caracterizam as equipas eficazes. Os princípios fundamentais da criação de uma equipa eficaz são os seguintes:

? ?Os elementos da equipa estabelecem os objectivos comuns e definem os papeis; ? Os elementos da equipa concordam com a estratégia definida; ? Os elementos da equipa definem um processo comum para o seu trabalho; ? Todos os elementos da equipa participam na produção do plano, e cada elemento

sabe qual o seu papel no referido plano; ? A equipa negoceia o plano com o seu gestor; ? Os elementos da equipa realizam o seu trabalho da forma como ele estava planeado; ? Os elementos comunicam de uma forma livre e continuada; ? A equipa forma um grupo coeso, na qual os elementos cooperam e estão

comprometidos com o objectivo a atingir; ? Os elementos da equipa conhecem o seu estatuto, recebem informação sobre o seu

desempenho e têm uma liderança que sustenta e fomenta a sua motivação;

Uma formação para uma equipa eficaz requer que todos os elementos percebam claramente o que é suposto fazer, concordem com a forma como devem executar o trabalho e acreditem que os planos são exequíveis. Estas condições podem ser todas obtidas com o envolvimento dos elementos na produção dos seus próprios planos. Então assumindo que estes planos estão concluídos, as equipas fornecem-nos à gestão. Toda estas condições são necessárias para equipas de trabalho eficazes, a forma especifica para estabelecer estas condições não ó óbvia. O TSP fornece um guia explicito para que as organizações construam equipas eficazes.

3 Processos operacionais para equipas

Para realizar um trabalho disciplinado, os engenheiros necessitam de processos operacionais, os quais definem de uma forma precisa como o trabalho deve ser realizado. Um processo



operacional é parecido com um script. Ele é desenhado para ser usado pelos elementos da equipa enquanto fazem o seu trabalho. O TSP define um processo operacional para orientar engenheiros e gestores através dos passos de construção de uma equipa. Este processo especifica os paços necessários para criar uma equipa eficaz.

Com um processo definido e um plano que o respeita, os engenheiros podem ser bastante eficientes. Se eles não tiverem tal processo, então devem parar em cada fase para delinear os próximos passos e definir como devem ser executados. Muitos processos de engenharia são bastante complicados e envolvem muitas fases.

Sem orientação especifica, os engenheiros poderão executar as fases numa ordem improdutiva, ou perder tempo a equacionar o que fazer a seguir. O TSP fornece os processos operacionais necessários para formar as equipas, estabelecer um ambiente para equipas eficazes e orienta-las na realização do trabalho. Conforme é apresentado na figura 6, o TSP é um de uma série de métodos que podem ajudar equipas de engenharia de forma a serem mais eficazes no desenvolvimento e no suporte de sistemas de software. O modelo de Capacidade e Maturidade (CMM) define uma plataforma para melhoramento global necessário a um trabalho eficaz. O PSP fornece disciplina, necessária para usar de forma consistente os processos definidos, planeados e dimensionados. O TSP agrega os princípios de equipas de produção integradas com os métodos de PSP e CMM para criar equipas eficazes. Em resumo poderemos dizer que o CMM e PSP dão contexto e habilitações para tornar o trabalho eficaz, ao passo que o TSP indica a forma de como fazer o trabalho.



CMM – Melhora a capacidade e gestão da organização; TSP – Melhora o desempenho da equipa e o foco no produto. PSP- melhora as habilitações pessoais e a disciplina.

Figura 6 - Métodos de melhoria de processos 4 A estrutura do TSP

Os principais elementos do processo TSP são mostrados na figura 7. Antes dos elementos fazerem parte de uma equipa TSP, eles devem saber como fazer um trabalho disciplinado. Como é mostrado nesta figura, a formação em PSP é necessária para fornecer aos engenheiros com conhecimentos e habilitações para usar o TSP. Na formação em PSP é explicado como fazer planos detalhados, reunir e usar dados do processo, desenvolver planos relativos aos valores ganhos, utilizar o valor ganho para acompanhar o projecto, medir e gerir a qualidade do produto, definir e usar processos operacionais. Os engenheiros devem estar formados nestes pontos antes que possam participar na construção de uma equipa TSP ou seguir os processos TSP definidos.



Figura 7 - Construção da equipa TSP

Existem várias formas para criar equipas de trabalho, mas todas elas requerem que todos os elementos trabalhem em conjunto de forma a concluir determinadas tarefas. Em TSP esta equipa de execução de tarefas é definida num processo de planeamento a quarto dias, processo esse que tem o nome lançamento de equipa. Num lançamento, todos os elementos da equipa desenvolvem a estratégia, processo e o plano de execução do projecto. Após a conclusão da fase de lançamento, a equipa segue o processo para ela definido para a execução do trabalho.

Como é mostrado na figura 8, as equipas de TSP são relançadas de uma forma periódica. Uma vez que o processo TSP segue uma estratégia de desenvolvimento iterativa e extendida, são necessários relançamentos para que cada fase ou ciclo possa ser planeada com base nos conhecimentos adquiridos na fase ou ciclo anterior. O relançamento também é necessário para actualizar os planos detalhados que normalmente só estão em dia por poucos meses. No lançamento do TSP, as equipas elaboram um plano global e um plano detalhado para os três meses seguintes aproximadamente. Depois dos elementos da equipa terem completado todo ou quase todo o trabalho da fase ou ciclo, revêm todo o plano e se necessário fazem um novo plano para os próximos três a quatro meses. Eles são orientados nesse sentido pelo relançamento do processo TSP.



Figura 8 – Fluxo do processo TSP

5 Lançamento de uma equipa TSP

Após toda a equipa ter tido uma formação adequada, esta participa na fase de lançamento da equipa TSP. O processo de lançamento é mostrado na figura 9 e na. tabela 9. Cada uma das 9 sessões de lançamento tem um formulário onde são descritas as actividades de uma forma detalhada, o que permite ao responsável pelo lançamento orientar a equipa através dos pontos pretendidos. Ao realizar o processo de lançamento as equipas produzem um plano detalhado. Para se tornarem numa equipa coesa e eficaz, todos os elementos devem estar comprometidos com o plano. Para criar este compromisso, o TSP envolve todos os elementos na produção do plano. Deste modo, após o lançamento da equipa todos os elementos participaram e concordaram com o plano que eles produzido.

Figura 9 – Processo de lançamento de uma equipa TSP

1. Establecer osobjectivos do

produto e do negócio

2. Atribuição depapeis e definir

objectivos da equipa

3. Criar estratégiade desenvolvimento

do produto

4. Construir planos dotipo “top-down” e

“next-phase”

5. Desenvolver oplano de qualidade

6. Construir planos dotipo “bottom-up” e de

equilibrio de carga

7. Prever/planear osriscos

8. Preparar reuniãode gestão e relatório

de lançamento

9. Considerarrevisão de gestão

Realizar olançamento final

Para novasequipas: Rever o

processo TSP

1º dia 2º dia 3º dia 4º dia



Tabela 9 – Script de lançamento de uma equipa TSP

Geralmente as equipas necessitam de orientação profissional para completarem de forma correcta e eficiente o processo de lançamento, esta orientação é dada por um elemento com formação específica que chefia o processo de lançamento.

Embora os formulários TSP forneçam a orientação essencial, cada equipa tem os seus

próprios problemas e particularidades. Portanto um processo simples pode não fornecer todo o material necessário para orientar uma equipa inexperiente no processo de lançamento da equipa, a menos que as equipas sejam muitos experientes e com um líder que tenha realizado vários projectos TSP, necessitam de um orientador com formação e experiência.

Passo Actividades Descrição

Convocar a equipa para a reunião de lançamento nº 1 - Revisão do processo de lançamento e apresentação dos elementos da equipa.

- Discussão das metas do projecto e espaço para perguntas e respostas.

Convocar a equipa para a reunião de lançamento nº 2 - Escolher os papeis da equipa e os papeis de segurança. - Definir e documentar os objectivos da equipa.Convocar a equipa para a reunião de lançamento nº 3 - Criar um desenho conceptual do sistema and fix list (se necessário). - Determinar a estratégia de desenvolvimento e os produtos a criar. - Definir o processo de desenvolvimento a usar. - Produção dos planos do processo e de suporte.Convocar a equipa para a reunião de lançamento nº 4 - Estimar o tamanho do desenvolvimento e do plano global.Convocar a equipa para a reunião de lançamento nº 5 - Desenvolver o plano de qualidade.Convocar a equipa para a reunião de lançamento nº 6 - Alocação dos elementos da equipa ao trabalho a realizar. - Criar planos 'bottom-up' com base na próxima fase para cada elemento da equipa. - Plano distribuido (equilibrado) das próximas fases para a equipa e cada um dos seus elementos.Convocar a equipa para a reunião de lançamento nº 7 - Identificar e avaliar os riscos do projecto. - Definir pontos de verificação de risco e responsabilidades.

- Propor acções de contigência para situações de risco com algum impacto.Convocar a equipa para a reunião de lançamento nº 8

- Preparar um relatório de lançamento para a gestão.Convocar a equipa para a reunião de lançamento nº 9

- Rever as actividades de lançamento e os planos do projecto com a gestão.

- Discutir os ricos do projecto, responsabilidades e as acções planeadas.Convocar a equipa para a reunião de lançamento nº 9- Percorrer a preparação do relatório semanal.- Recolher dados do lançamento e produzir um relatório de lançamento.- Avaliar o processo de lançamento.

- Lançamento completo com a documentação completa dos planos da equipa e dos seus elementos.- Papeis, processos, objectivos e responsabilidades da equipa completamente definidos.- Concordância da gestão relativamente ao plano da equipa, acções de decisão e atribuição de responsabilidades.

4

3

2

1

8

7

6

5

Revisão de gestão

Lançar a fase 'Postmortem'

Critério de saida

PM

9

Plano de qualidade

Plano equlibrado/distribuido

Análise do risco do projecto

Relatório de preparação do lançamento

Estratégia e suporte do projecto

Objectivos e papeis da equipa

Objectivos de projecto e gestão

Plano global



No primeiro encontro de lançamento, a equipa, o chefe da equipa e o responsável pelo lançamento encontram-se com um gestor sénior e representantes do markting. O gestor sénior informa a equipa do objectivo do projecto, o porquê da sua necessidade, as razões para o seu inicio e as metas a atingir. O elemento do markting explica as necessidades de markting do produto, algumas características competitivas importantes e algumas considerações especiais colocadas pelo cliente que a equipa de desenvolvimento deva saber. O objectivo deste primeiro encontro é de informar todos os elementos sobre o trabalho, descrever as expectativas da equipa de gestão em relação à equipa e convencer os seus elementos de que a gestão confia neles para a realização de tão importante projecto.

Entre o segundo e o oitavo encontro, a equipa, o líder e os gestores encontram-se com

observadores ou visitantes. Durante estes encontros, a equipa é guiada através de um conjunto de passos desenhados para produzir as condições para um trabalho de equipa eficaz. No segundo encontro de lançamento a equipa documenta os seus objectivos e escolhe os papeis para cada um dos seus elementos.

Os papeis principais usados em PSP são: chefe de equipa, responsável pela ligação com o

cliente, responsável pela análise, responsável pela implementação, responsável pelos testes, responsável pelo planeamento, responsável pelos processos, responsável pela qualidade e responsável pelo apoio. Outros papeis podem ainda ser atribuídos conforme as necessidades, como por exemplo: responsável pelo desempenho e responsável pela segurança.

Cada um dos elementos da equipa desempenha pelo menos um papel dentro dela. Quando a

equipa tem mais de oito elementos, podem ser criados mais papeis ou alguns elementos podem servir de assistentes aos elementos com determinado papel. Geralmente o chefe da equipa não assume mais nenhum papel.

Nos encontros de lançamento número 3 e 4, a equipa cria a estratégia global para o projecto

e plano. É produzida uma análise conceptual, idealizada uma estratégia de desenvolvimento, definir de forma detalhada os processos a utilizar e determinar as ferramentas de suporte que serão necessárias. Listam os produtos a serem produzidos, estimam o tamanho de cada produto, recalculam o tempo necessário para a realização de cada nível do processo. Uma vez definidas e estimadas as tarefas, é estimado o número de horas que cada elemento da equipa despenderá no projecto por semana. A partir da estimativa das tarefas e das horas semanais a equipa gera o calendário do projecto.

Uma vez na posse do plano global, são produzidos os parâmetros de qualidade e é planeada a reunião de lançamento número 5. Este plano define as acções de qualidade que a equipa deve executar e fornece bases mensuráveis para o acompanhamento do trabalho à medida que este vai sendo executado. Na criação do plano de qualidade, os elementos da equipa estimam o número de defeitos que vão introduzir e remover em cada uma das fases, a quantidade de defeitos em teste de sistema, testes de aceitação e por fim a entrega do produto. Na reunião 6, é feito um plano detalhado da próxima fase e revista toda a carga para assegurar que as tarefas estão bem distribuídas pelos elementos da equipa. O resultado deste trabalho é o chamado plano de equipa balanceado.

Durante a reunião 7, são identificados os maiores riscos do projecto e ordenados de acordo

com o impacto. É atribuída a um elemento da equipa a responsabilidade de identificar quais os maiores riscos e como consequência preparar um plano para esses mesmos riscos.

Na reunião número 9, é explicado o plano, como ele foi produzido e é demonstrado que

todos os elementos da equipa concordaram e estão comprometidos com ele. Se a equipa não concorda com os objectivos, deve preparar e apresentar um plano alternativo onde seja mostrado o que poderá ser feito com a adição de recursos ou alterações de requisitos. A



principal razão para a apresentação de planos alternativos é a de disponibilizar várias opções à gestão do projecto para que sejam consideradas caso estejam de acordo com as necessidades de negócio. No final do lançamento do TSP, a equipa e a gestão devem acordar a forma como a equipa vai prosseguir com o projecto. No passo final de lançamento, a equipa revê o processo de lançamento e coloca à disposição propostas de melhorias aos processos.

6 TSP processos de trabalho em equipa

Após a sessão de lançamento da equipa de TSP a principal necessidade é de garantir que todos os elementos da equipa seguem o plano estabelecido, o que significa obedecer aos seguintes tópicos:

? Chefia da equipa. ? Disciplina de processo ? Acompanhamento da evolução. ? Comunicação ? Relatórios de gestão ? Manutenção do plano. ? Estimar a conclusão do projecto ? Reequilibrar a carga de trabalho da equipa. ? Relançar o projecto. ? Gestão da qualidade TSP.

6.1 Liderar a equipa

O líder da equipa é responsável pela orientação e motivação dos seus elementos bem como, de tratar das necessidades dos clientes e da gestão. Isto inclui uma definição diária do trabalho, protecção dos recursos da equipa, resolver conflitos, orientar as reuniões e efectuar relatórios sobre o trabalho desenvolvido. Apesar disso a principal responsabilidade do chefe de equipa é de manter a motivação e energia da dentro da equipa de forma a garantir que ela seja eficaz no desenrolar do trabalho. Uma responsabilidade chave do líder da equipa é de manter a disciplina relativamente aos processos. É aqui que o líder assegura que o trabalho é realizado da forma planeada. Durante o lançamento é definido o processo para a execução do trabalho. Durante a execução do trabalho o líder monitoriza-o de forma a assegurar que todos os elementos seguem os processos e os plano que a equipa produziu.

Quase todos os projectos enfrentam uma grande pressão de calendário e recursos, o que

conduz a uma tentação de cortes. Todavia, quando as equipas deixam de seguir os processos definidos, elas não têm forma de sugerir o que deveriam fazer ou mesmo o estado do projecto. Com a disciplina de monitorização do processo, o chefe de equipa deve verificar se todos os seus elementos sabem os processos a seguir e deve ainda efectuar semanalmente relatórios do seu estado de evolução.

Uma outra responsabilidade importante do líder da equipa é de assegurar que todas as necessidades publicadas pelos seus membros são geridas e distribuídas. Com o TSP, os engenheiros trocam informações sobre os problemas no seu encontro semanal. O líder deve assegurar em primeiro lugar se as necessidades devem ser tratadas pela e se for, e se for o caso, decidir qual o elemento da equipa deve ser responsável por geri-lo e orientá-lo. Por fim, a equipa regista cada necessidade no Log de necessidades, e revê todas as necessidades pendentes em cada reunião semanal.



6.2 Comunicação

O líder da equipa é responsável por manter uma comunicação aberta e efectiva.

Quando os elementos da equipa não conhecem o estado do projecto, não percebem o que os restantes colegas estão a fazer ou desconhecem desafios que estão pela frente, então é extremamente difícil continuarem motivados. A comunicação é a chave para manter a energia e o esforço da equipa, facilitar a comunicação é uma das responsabilidades dos lideres de equipa.

Durante o encontro semanal, o líder da equipa revê em primeiro lugar o estado do

projecto, depois algumas necessidades de gestão e outros assuntos de interesse. Então cada membro da equipa faz uma revisão do seu trabalho durante a semana anterior, bem como do planeado para a semana seguinte, e os riscos que estão a correr. Discutem as suas necessidades, dificuldades e descrevem as áreas onde vão necessitar de ajuda ou suporte durante a semana seguinte.

Uma outra responsabilidade critica do líder é manter a equipa de gestão informada

do estado e o progresso do projecto. O TSP aconselha os elementos da equipa a fazerem relatórios semanais mostrando a posição actual do projecto em comparação com o planeado.

6.3 Manter o plano

Uma vez completo o processo de lançamento do projecto por parte das equipas o plano guia o trabalho, bem como fornece indicadores de referência para estimar o progresso e medidas que possam ajudar a identificar problemas que possam comprometer a calendarização do projecto. Com indicadores de aviso em quantidade suficiente, as equipas podem tomar decisões em tempo oportuno para evitar a derrapagem do projecto. As equipas de TSP acompanham o progresso comparativamente com o plano todas as semanas usando o método ‘valor ganho’. Com o “valor obtido”, a cada tarefa é atribuído um valor baseado numa percentagem do total do projecto estimada em função da tarefa. Se o projecto foi planeado para 1000 horas de tarefas, uma tarefa de 32 horas terá um valor planeado de 3.2, ou seja, 100*32/1000= 3.2%. Quando a equipa terminar a tarefa, o projecto terá ganho um valor acumulado de 3.2, independentemente do tempo que a tarefa durou na realidade. As equipas têm muitos tipos de tarefas e em qualquer projecto com uma complexidade razoável, as quais muitas vezes são realizadas numa ordem diferente da originalmente planeada. Uma vez que algumas tarefas ficarão completas mais cedo e outras mais tarde, não existe uma forma simples para indicar quando o projecto está atrasado ou adiantada em relação ao fim previsto. O método do “valor ganho” atribui um valor para cada tarefa, e quando esta está completa a equipa ganha o valor. Com o valor ganho, a equipa pode dizer com precisão qual a situação do projecto. Por exemplo, a equipa pode reportar semanalmente os dados mostrados na tabela 10.



Semana 3 Planeado Actual Horas de tarefas 106 98 Horas de tarefa até à data 300 274 Valor ganho 1.9 2.1 Valor ganho até à data 5.8 5.3

Tabela 10 – Dados semanais da equipa

Ainda que a equipa esteja adiantada relativamente aos requisitos ou design, esta reporta à gestão a posição actual relativamente ao plano. Por exemplo, através dos dados da tabela 10, a gestão pode ver que o desempenho da equipa melhorou de forma significativa na última semana. Nas duas últimas semanas, ela tinha 176 horas de tarefas (274-98), ou uma média de 88 tarefas por semana. Nesta semana atingiu um valor de 98 horas. Embora esteja atrás no “valor ganho” acumulado, realizou mais tarefas do que o planeado na semana anterior.

O método do valor ganho também ajuda as equipas a estimar a altura de conclusão do trabalho. Por semana pode medir-se o número de horas despendidas em cada ponto do “valor ganho”. Depois, assumem que continuando o trabalho à mesma velocidade podem estimar quando o vão acabar.

Exemplo: a partir da tabela 10, a equipa acumulou 5.3 pontos do “valor ganho” em 3 semanas, ou seja 1.7667 por semana. A essa taxa, demorará 100/1.7667 = 56.6 semanas. Desde que completaram a semana, isto é 53.6 semanas a mais de trabalho. Se a equipa for capaz de continuar ao mesmo ritmo o tempo de trabalho será somente de (100-5.8)/2.1 = 44.9 semanas.

O método do “valor ganho” não só ajuda os elementos da equipa a situarem-se, como também ajuda a gestão a compreender quais as necessidades para a conclusão do trabalho no tempo determinado. Com o método do “valor ganho”, as equipas de TSP e os seus gestores podem antecipar os problemas das datas de conclusão. E assim, geralmente têm tempo para tomar acções de recuperação. O “valor ganho” é útil no acompanhamento do progresso do projecto e fornece um sentimento de dever cumprido, no entanto não fornece nenhuma ajuda relacionada com as prioridades e dependência das tarefas. Para gerir correctamente as relações entre as tarefas, é necessário manter os planos pessoais e assegurar que elas são identificadas e correctamente tratadas. Em equipas grandes, ajudar os elementos da equipa a terem esta visão é responsabilidade do gestor do plano.

6.4 Balancear a carga de trabalho

Uma carga de trabalho não balanceada pode causar ineficiência na equipa. Isto acontece quando determinados elementos têm muito mais trabalho do que outros. Este problema tem inúmeras causas. Primeiro, os elementos mais experientes da equipa são geralmente envolvidos em mais trabalho comparativamente com elementos com menos experiência. Provavelmente os elementos com mais experiência executam as tarefas de uma forma mais rápida e melhor do que os outros, deixando-lhes pouco para fazer. Uma outra causa é a variação do desempenho. Alguns elementos acabam as suas tarefas antes do tempo determinado e outros acabam depois.

Embora o trabalho não balanceado seja natural, ele não é eficiente, a não ser que todos os

elementos da equipa estejam sempre ocupados por completo. Sempre que existe trabalho não balanceado a equipa não pode ser 100% eficaz. Semanalmente, quando a equipa analisa



o estado do projecto, os seus elementos devem ver se a sua carga de trabalho não está balanceada, e devem redistribuir o plano. Com o TSP as equipas fazem esta tarefa as vezes consideradas necessárias. Após os elementos da equipa completarem o lançamento do TSP e terem os seus planos pessoais detalhados, podem geralmente redistribuir a carga de trabalho em somente uma ou duas horas.

A equipa de lançamento do TSP produz um projecto global como extensão do plano

inicial. Dependendo do projecto, o plano pode ser de algumas semanas ou mesmo de alguns anos. Com o TSP, cada elemento da equipa produz um plano detalhado para a próxima fase do projecto. Uma vez que os elementos geralmente não conseguem fazer planos detalhados para mais do que três ou quatro meses, o TSP quebra o projecto em fases com aproximadamente três a quatro meses de duração.

As equipas relançam os seus projectos no inicio de cada fase ou ciclo. Sempre que as equipas acharem que o plano estabelecido já não os ajuda a executar o seu trabalho, então devem relançar os seus projectos. Assim como os projectos, as equipas também devem ser relançadas quando existirem grandes mudanças no trabalho a ser feito ou alterações a nível da sua composição.

7 Gestão da qualidade

Enquanto a maior parte das organizações concorda com o facto de a qualidade ser importante, poucas equipas sabem como gerir a qualidade dos seus produtos. Além de não existirem métodos genéricos para prevenir a introdução de defeitos. As pessoas que desenvolvem software cometem erros, que são a fonte dos defeitos de software. Em TSP o principal ênfase de qualidade é o da gestão dos defeitos. Para gerir a qualidade, as equipas devem estabelecer medidas de qualidade, objectivos de qualidade, criar planos para atingir tais objectivos, comparar o progresso com o planeado e tomar medidas de acção quando os objectivos não são cumpridos. O TSP mostra às equipas como o fazer.

7.1 O plano de qualidade

Durante o lançamento das equipas TSP, estas elaboram um plano de qualidade, baseado no tamanho estimado do produto e no histórico referente à introdução de defeitos, estimam também a quantidade de defeitos que vão provavelmente introduzir em cada fase. Para situações em que não existe histórico podem usar a tabela guia do método TSP que se mostra na tabela 11, ajudando-os a estabelecer objectivos de qualidade. Uma vez estimados os defeitos introduzidos, estimam os removidos recorrendo novamente aos dados de histórico ou à tabela 12. Esta estimativa de remoção é baseada para no rendimento relativo à remoção de defeitos em cada fase. O rendimento é calculado com base na percentagem de defeitos do produto, no início de uma determinada fase e com o número de defeitos removidos nessa mesma fase. Uma vez feita a estimativa dos defeitos introduzidos e removidos, a equipa pode gerar então o plano de qualidade. Por fim, esta deve examinar o plano para verificar se os parâmetros de qualidade são razoáveis e se obedecem aos objectivos de qualidade da equipa. Em caso negativo, devem ocorrer ajustes e ser gerado um novo plano.



Tabela 11 – Tabela guia para a qualidade em TSP, só devem ser usados estes valores até existirem dados históricos que permitam substitui-los.

Uma vez gerado o plano de qualidade pelos elementos da equipa, o gestor da qualidade

ajuda-os a comparar o desempenho com esse mesmo plano. O plano de qualidade contém a informação mostrada na tabela 12. O gestor da qualidade compara os dados em cada fase e

Objectivo ComentáriosPercentagem sem defeitos

Compilação > 10%Testes unitários > 50%Testes de integração > 70%Testes de sistema > 90%

Defeitos/KLC:Total de defeitos introduzidos 75 - 150 Se não fôr um PSP treinado, usar entre

100 e 200.Compilação < 10 Todos os defeitosTestes unitários < 5 Só os defeitos principais (na fonte LC)Testes de integração < 0.5 Só os defeitos principais (na fonte LC)Testes de sistema < 0.2 Só os defeitos principais (na fonte LC)

Taxas de defeitosDefeitos na revisão detalhada do design/defeitos nos testes unitários > 2.0

Só os defeitos principais (na fonte LC)

Defeitos na revisão de código/defeitos de compilação > 2.0 Só os defeitos principais (na fonte LC)Taxas de tempos de desenvolvimento

Requisitos de inspecção/requisitos de tempo > 0.25 Inspecção do design a alto nível/tempo de design a alto nível > 0.5Design detalhado/tempo de codificação > 1.00Revisão detalhada do design/tempo de design detalhado > 0.5Revisão do código/tempo de codificação > 0.5

Taxas de revisão e inspecçãoPáginas de requisitos/hora < 2 Páginas de design de alto nível/hora < 5 Linhas de design detalhado/hora < 100 Pseudocódigo ~ igual a 3 LCLinhas de código/hora < 200 LC Lógica

Taxas de intodução e de remoção de defeitosDefeitos de requisitos introduzidos/hora 0.25 Só os defeitos principaisDefeitos removidos pela inspecção de requisitos/hora 0.5 Só os defeitos principaisDefeitos introduzidos a alto nível de design/hora 0.25 Só os defeitos principais

Defeitos removidos na inspecção de alto nível do design/hora 0.5 Só os defeitos principaisDefeitos introduzidos ao nível do detalhe do design/hora 0.75 Só defeitos de designDefeitos removidos ao nível do detalhe do design/hora 1.5 Só defeitos de designDefeitos removidos na inspecção detalhada do design/hora 0.5 Só defeitos de designDefeitos de código introduzidos/hora 2 Todos os defeitosRemoção na revisão de defeitos/hora 4 Todos os defeitos em LC fonteDefeitos introduzidos na compilação/hora 0.3 Todos os defeitosDefeitos removidos na inspecção de código/hora 1 Todos os defeitos em LC fonteDefeitos introduzidos em testes unitários/hora 0.067 Qualquer defeito

Rendimento das fasesExigências de inspecções da equipa ~ 70% Sem contar comentáriosRevisão do design e inspecções ~ 70% Usando análise de estadoRevisão de código e inspecções ~ 70% Usar checklists pessoaisCompilação ~ 50% 90+ % dos defeitos de sintaxTestes unitários - 5 ou menos defeitos/KLC ~ 90% Integração e testes de sistema - at < 1.0 defeito/KLC ~ 80%Antes de compilar >75% Antes dos testes unitários > 85% Presumindo verificações de lógica nas

revisõesAntes dos testes de integração

> 97.5% Para todos oso produtos, 1 defeito máximo.

Antes dos testes de sistema> 99%

Para todos oso produtos, 1 defeito máximo.

Medir



para cada parte do sistema, para verificar se os valores encontrados estão dentro dos limites definidos no plano de qualidade. Caso contrário, o gestor da qualidade na reunião semanal sugere à equipa o que esta deve fazer para corrigir.

Tabela 12 – Plano de qualidade TSP (formulário sumário)

Nome DataProjecto Lançamento/FaseProduto/Versão Nivel de agregação

Percentagem livre de defeitos Planeado ActualEm compilaçãoEm testes unitáriosEm testes de integraçãoEm testes de sistemaEm testes de aceitaçãoNum ano de usoNa vida do produto

Defeitos/páginaInpecção de requisitosRevisão HLDInspecção HLD

Defeitos/KLCRevisão DLDInspecção DLDRevisão de códigoCompilaçãoInspecção de códigoTestes unitáriosConstrução e integraçãoTeste de sistema

Total desenvolvimentoTestes de aceitaçãoVida do produto

Total

Taxas de defeitosRevisão de código/CompilaçãoRevisão DLD/Testes unitários

Taxas de tempos de desenvolvimento (%)Requisitos de inspecção/TempoInspecção HLD/Tempo HLDDLD/CódigoRevisão DLD/DesignRevisão de código/Código

A/FRTaxas de revisão pessoais

Linhas DLD/HoraLC/Hora

Taxas de inspecçãoPaginas de requisitos/horaPáginas HLD /horaLinhas DLD/horaLC/Hora

Artigo/montagem Data

Taxas de introdução de defeitosRequisitosHLDDLDCodificaçãoCompilaçãoTeste unitárioConstrução e integraçãoTeste de sistema

Taxas de remoção de defeitosRequisitosPlaneamento de testes de sistemaInspecção de requisitosHLDPlaneamento dos testes de integraçãoInspecção HLDRevisão DLD



7.2 Identificação de problemas de qualidade

No TSP, existem vária formas para identificar problemas de qualidade. Por exemplo,

através da comparação dos dados de qualquer módulo ou componente com o plano de qualidade, pode-se ver rapidamente onde as densidades dos defeitos existem, rever taxas de revisão, rendimento e o desvio de outras medidas relevantes para os objectivos da equipa. Mesmo para projectos significativamente pequenos, pode levar muito tempo a examinar os dados do processo. Para ajudar a aliviar este problema, o TSP introduz as seguintes séries de medidas de qualidade:

? Percentagem livre de defeitos - PLD ? Gama de remoção de defeitos ? Gama de qualidade ? Índice de qualidade do processo - IQP

Um gráfico simples PLD é mostrado na figura 10, onde se mostra a percentagem de componentes do sistema isentos de problemas numa fase particular da remoção de problemas. Através da análise das curvas PLD, pode verif icar-se se existe uma fase especifica com defeitos. Isto pode ser observado através da comparação das curvas do PLD para vários projectos similares. Onde existirem problemas, o gestor da qualidade pode analisar os dados no seu nível mais baixo para identif icar a fonte do problema e recomendar as acções a tomar.

Figura 10 – Percentagem livre de defeitos (PLD).

A figura 11 mostra a gama típica para a remoção de defeitos. Uma vez que o PDF só pode ser produzido para a totalidade do sistema ou para um grande componente, a gama típica para a remoção de defeitos pode ser definida para o sistema, para cada um dos seus sub-sistemas, para qualquer componente ou até descer ao nível do modelo. Assim, se o PLD ou o nível de remoção de defeitos do sistema indicarem problemas, o gestor da qualidade pode examinar progressivamente a partir do nível mais baixo da gama tipo de remoção de defeitos para encontrar a fonte do problema.



Figura 11 – Remoção de defeitos

O índice de qualidade do processo (IQP) é produzido através da obtenção de cinco valores dimensionais da gama de valores de qualidade a produzir. Com o índice de qualidade abaixo de 0.4, os módulos do programa estão geralmente isentos de defeitos. As organizações podem ordenar um grande número de módulos pelo seu índice de qualidade. Isto é particularmente útil com sistemas muito grandes compostos por centenas ou milhares de módulos.

7.3 Encontrar e prevenir problemas de qualidade

As medidas de qualidade podem fornecer indicações sobre eventuais problemas e mesmo antes da primeira compilação, e fornecem uma medida fiável da qualidade do módulo ou componente antes do inicio da fase de integração ou da fase de testes do sistema Uma vez identificados os módulos ou componentes que provavelmente têm problemas de qualidade, devem ser efectuadas as seguintes acções de actuação sugeridas pelo TSP:

? Monitorizar o módulo durante os testes para verificar se são encontrados problemas e

como consequência determinar a acção correctiva a tomar; ? Reinspecionar o módulo antes da integração e testes de sistema; ? Determinar se é necessário redesenvolver o modulo para corrigir problemas; ? Redesenvolver o módulo.

Os processos para desenvolvimento de software em PSP e TSP foram desenhados para

prevenir problemas antes deles ocorrerem. Na formação em PSP os engenheiros adquirem conhecimento por forma a reduzir a introdução de defeitos (taxas entre 40% a 50%).

Com o TSP, o gestor do projecto pode contribuir para reduzir a introdução de defeitos ao

assegurar-se que a equipa produz um projecto completo e de alta qualidade. O plano de qualidade e o acompanhamento do processo torna os engenheiros mais sensíveis para as questões de qualidade e em consequência trona-os mais cuidadosos, reduzindo cada vez mais os defeitos por eles criados. Finalmente o TSP faz uma revisão dos defeitos em que



cada um introduzido pelo desenvolvimento é analisado para identificar potenciais alterações aos processos ou prevenir a ocorrência de defeitos similares no futuro.

Figura 12 – Relatório em TSP

8 Resultados obtidos com o TSP

Como o TSP era relativamente novo, foram disponibilizados alguns relatórios reportados por algumas organizações. Alguns exemplos são mostrados de seguida: ? Teradyne constatou que a média de defeitos nos testes de integração, testes de

sistema e testes de aceitação era de 20 defeitos por KLC (1000 linhas de código).



Com a realização do primeiro projecto em TSP o número de defeitos passou para 1 por KLC.

?? A base aérea de Hill, perto de Salt Lake City, Utah, foi a primeira organização

governamental a ser criada com o nível 5 do CMM. O primeiro projecto de TSP em Hill obteve resultados de 123% relativamente à produtividade e o tempo de teste foi reduzido em média 22% a 27% relativamente ao tempo do projecto.

?? Boeing em vários projectos de sistemas para os seus aviões, obteve resultados que

são mostrados nas figuras 13 e 14. A redução em 94% do tempo de teste de sistema resultou numa melhoria substancial nos tempos de desenvolvimento dos projectos e permitiu á Boeing fornecer produtos de alta qualidade de uma forma mais rápida.

Figura 13 – TSP defeitos

Figura 14 – TSP tempo de teste



9 Estado e tendências futuras

A razão inicial para o desenvolvimento do TSP era a de fornecer um contexto em que elementos com formação em PSP achassem natural usar métodos disciplinadores. A formação em PSP por si só não é suficiente para que os elementos usem os métodos de forma consistente. Existem várias razões para tal facto, em primeiro lugar sem formação os gestores geralmente não entendem os métodos do PSP ou avaliam quais os seus benefícios. Em segundo lugar, o trabalho disciplinado não é trabalhoso mesmo com o suporte de um orientador. Sem tal acompanhamento, o longo períodos de trabalho sustentado e disciplinado é quase impossível. A motivação inicial do desenho do TSP era o de tratar estes problemas.

9.1 Tendências futuras

Uma vez que os objectivos do TSP foram largamente atingidos, o próximo passo no

esforço do desenvolvimento da metodologia TSP será a transição dos processos básicos do TSP para o uso industrial e também o aumento do número de instituições académicas a leccionarem a metodologia.

O principal foco do trabalho industrial é a melhoria da formação, treino e introdução métodos para que os engenheiros sigam o processo com dedicação e encorajar o desenvolvimento de ferramentas comerciais de suporte do TSP. As próximas versões incluirão extensões de processos TSP para várias dimensões de equipas. A longo prazo serão necessárias extensões para equipas muito grande. Devido a uma larga diversidade de tipos de grupos de trabalho, serão necessárias séries de processos TSP.

O TSP básico foi desenhado para grupos com dimensões compreendidas entre os 2 e os 20 elementos, mas o número ideal está compreendido entre os 3 e os 12 elementos. Os múltiplos processos TSP, são desenhados para equipas com um número de elementos entre 100 e 150.

Como complemento serão necessárias várias extensões ao TSP para equipas distribuídas

compostas por elementos em localizações físicas diferentes e para grandes projectos com várias equipas em múltiplos locais. Por fim, será necessária uma extensão para equipas realmente grandes (várias centenas de pessoas) que trabalham em grandes programas de projectos com grande amplitude. À medida que as equipas crescem, as relações entre os métodos de PSP, TSP e CMM tornam-se mais importantes



Conclusão

Este trabalho realizado revelou-se bastante importante, na medida em que, me

permitiu adquirir novos conhecimentos aplicáveis às funções que actualmente exerço.

As metodologias apresentadas neste relatório revelam a potencialidade a nível

prático, na organização, disciplina e qualidade do trabalho em equipa e individual.

Transmitindo noções simples e práticas, que quando aplicadas beneficiam trabalhadores

e empresas.



Bibliografia

http://www.dacs.dtic.mil/awareness/newsletters/stn3-4/teamspi.html

http://www.sei.cmu.edu/tsp/tsp.html

http://interactive.sei.cmu.edu/news@sei/features/2000/spring/feature_1/feature_1.

htm

http://interactive.sei.cmu.edu/Features/1999/June/Background/Background.jun99.

pdf

http://wuarchive.wustl.edu/languages/ada/sei/documents/01.reports/tech-

prog/tsp.pdf

http://www.software.org/quagmire/descriptions/tsp.asp

http://www.sei.cmu.edu/tsp/psp.html

http://www.sysmod.com/psp.htm

http://davidfrico.com/pspexec-d.pdf

http://www.ipd.uka.de/PSP/

relatório de projecto - departamento de engenharia...

Documents