Relatório de Projecto

Transcrição

1 Relatório de Projecto

2 Personal Software Process e Team Software Process Autoria: João Paulo Santos Nunes Ferreira Aluno nº ISEP Setembro de 2002 Página 2 de 49

3 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. ISEP Setembro de 2002 Página 3 de 49

4 Índice Prefácio...3 Introdução...6 Personal Software Process (PSP) Introdução Qualidade do software Princípios do PSP Estrutura do processo PSP Planeamento Requisitos Método de Probe Modelo conceptual Estimar o tamanho do produto Estimar os recursos Produção do calendário Desenvolver o produto Analisar o processo Recolha de informação Medir tempos Calcular tamanhos Linhas de código Categorias dos tamanhos Contabilizar tamanhos Medidas de qualidade Gestão da qualidade Defeitos e qualidade A responsabilidade do engenheiro Remoção de defeitos Prevenção de defeitos Design em PSP O PSP e as melhorias no processo de desenvolvimento Team Software Process (TSP) Qualidade do software Como foi desenvolvido o TSP Equipas de trabalho Condições para o trabalho em equipa Equipas eficazes Criar equipas eficazes Processos operacionais para equipas A estrutura do TSP Lançamento de uma equipa TSP TSP processos de trabalho em equipa Liderar a equipa Comunicação Manter o plano Balancear a carga de trabalho ISEP Setembro de 2002 Página 4 de 49

5 7 Gestão da qualidade O plano de qualidade Identificação de problemas de qualidade Encontrar e prevenir problemas de qualidade Resultados obtidos com o TSP Estado e tendências futuras Tendências futuras Conclusão Bibliografia ISEP Setembro de 2002 Página 5 de 49

6 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). ISEP Setembro de 2002 Página 6 de 49

7 Personal Software Process (PSP) ISEP Setembro de 2002 Página 7 de 49

8 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 pla nos. 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 ISEP Setembro de 2002 Página 8 de 49

9 passo significativo para a melhoria da qualidade foi dado com a introdução inicial do Capacity Maturity Model (CMM) para software em 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 ISEP Setembro de 2002 Página 9 de 49

10 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. de outra forma, Figura 1- Fluxo do processo PSP Figura 2 Projecto PSP ISEP Setembro de 2002 Página 10 de 49

11 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 ISEP Setembro de 2002 Página 11 de 49

12 Figura 4 Elementos do processo PSP Fase Objectivo Guia do desenvolvimento de módulos das aplicações 1 Critério de entrada Planeamento Desenvolvimento Descrição do problema Formulá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. 2 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. Critério de saída 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. Tabela 1 Script de processo em PSP1 ISEP Setembro de 2002 Página 12 de 49

13 4.1 Planeamento O processo de planeamento é mostrado na figura 5. Figura 5 Processo de planeamento do projecto 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) Método de PROBE 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 ISEP Setembro de 2002 Página 13 de 49

14 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 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 Dados I/O Lógica Set-up Texto Tabela 2 - C++ Tamanho dos objectos em linhas de código (LOC) por método 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 ISEP Setembro de 2002 Página 14 de 49

15 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 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 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 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 ISEP Setembro de 2002 Página 15 de 49

16 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 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 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. ISEP Setembro de 2002 Página 16 de 49

17 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 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 = 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 = 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. ISEP Setembro de 2002 Página 17 de 49

18 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 ISEP Setembro de 2002 Página 18 de 49

19 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 Revisão do design Codificação Revisão do código Compilação Teste 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: defeitos detectados durante revisão de código defeitos detectados durante a compilação defeitos detectados durante a revisão de design defeitos detectados durante a fase de testes 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. ISEP Setembro de 2002 Página 19 de 49

20 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 concluir 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 11 design Revisão do 28 código Compilação 12 Teste 7 Total 58 Tabela 4 Defeitos removidos ISEP Setembro de 2002 Página 20 de 49

21 Fase Defeitos introduzidos Defeitos removidos Design 26 0 detalhado Revisão do 0 11 Design Código 39 0 Revisão de 0 28 código Compilação 0 12 Teste 0 7 Após Teste 0 7 Total 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, = 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/( ) = 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 Revisão do design % Codificação Revisão do código % Compilação % Teste % Após teste Total Tabela 6 Cálculos de Rendimento ISEP Setembro de 2002 Página 21 de 49

22 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 = 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 De feitos 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. ISEP Setembro de 2002 Página 22 de 49

23 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; ISEP Setembro de 2002 Página 23 de 49

24 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 Static Dynamic Internal Attributes Constraints State Machine External Inheritance Class Structure Services Messages Tabela 7 Estrutura de especificação do objecto Static Object Specification Templates Dynamic Internal Logic Specification Template State Machine Template External Function Specification Template (Inheritance Class Structure) Functional Specification Template (User Interaction) Operational Scenario Template Tabela 8 Correspondência entre modelos e estruturas de especificação Onde: ISEP Setembro de 2002 Página 24 de 49

25 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 ISEP Setembro de 2002 Página 25 de 49

26 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. ISEP Setembro de 2002 Página 26 de 49

27 Team Software Process (TSP) ISEP Setembro de 2002 Página 27 de 49

28 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 Posteriormente foi introduzido o modelo Capability Maturity Model (CMM) em 1987 e o Personal Software Process (PSP) em 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 À 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. ISEP Setembro de 2002 Página 28 de 49

29 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, ISEP Setembro de 2002 Página 29 de 49