sábado, 28 de abril de 2007

Métricas

Várias métricas podem ser utilizadas na elaboração de estimativas. As mais utilizadas são: o tamanho do software, a produtividade dos desenvolvedores, a taxa de defeitos e o esforço humano.

Linhas de código fonte

Uma das métricas mais comuns para software é o número de linha de código fonte (LOC – lines-of-code, em inglês). As linhas de código são, de fato, um resultado imediato da atividade de desenvolvimento do produto final. No entanto, ela não considera diretamente, diversas outras atividades envolvidas, como requisitos, arquitetura, testes e outras. Alguns autores consideram que estas atividades estão implicitamente consideradas, ou seja, para se produzir um certo número de LOC, livre de defeitos, utilizando um certo processo de software, é necessário especificar os requisitos, projetar e modelar a arquitetura e testar o código, por exemplo.

Linhas de código têm a vantagem de ser uma métrica bastante objetiva. Basta analisar o código e se tem o valor do que foi produzido. Estimar LOC é prever quanto precisará ser feito para se obter o produto final.

O tamanho de um software em linhas de código varia de uma linguagem de programação para outra. Isto significa que as estimativas devem considerar dados de projetos similares apenas naquela mesma linguagem. Ou seja, se existe uma métrica de produtividade com uma certa linguagem, não se pode aplicar a mesma métrica numa outra linguagem. O mesmo vale para a funcionalidade. Se numa certa linguagem, para implementar uma certa função, são necessárias 200 LOC, numa outra linguagem a funcionalidade pode ser implementada com apenas 100 LOC. Por fim, pode-se argumentar que programadores mais eficientes conseguem implementar uma mesma funcionalidade, numa mesma linguagem utilizando menos LOC que outro programador. No entanto, em um processo de software bem controlado, a exigência de padrões e normas de programação limita esta variação.

Ponto de função

Análise de pontos de função é um método para identificar uma métrica que é independente da linguagem de programação utiliza e depende apenas da funcionalidade do software. Os pontos-de-função (FP) são dependentes de fatores relacionados aos serviços que o software precisa realizar. Eles são calculados com base em 5 valores que precisam ser atribuídos:

  • Número de entradas externas (EI)
  • Número de saídas externas (EO)
  • Número de consultas externas (EQ)
  • Número de tabelas lógicas internas (ILF)
  • Número de interfaces externas (EIF)

Uma vez que todos os valores tenham sido atribuídos, eles precisam ser aplicados numa fórmula empírica para se determinar o número de pontos-de-função. Estes valores são multiplicadores que variam de acordo com a complexidade, sendo classificada em baixa, média e alta.

A tabela a seguir mostra o cálculo do número de pontos-de-função não ajustados (UFP).


Complexidade

Baixa

Média

Alta

Total

Entradas externas (EI)

__* 3=EI1

__* 4=EI2

__* 6=EI3

EI1+EI2+EI3

Saídas externas (EO)

__* 4=EO1

__* 5=EO2

__* 7=EO3

EO1+EO2+EO3

Consultas externas (EQ)

__* 3=EQ1

__* 4=EQ2

__* 6=EQ3

EQ1+EQ2+EQ3

Arquivos Lógicos Internos (ILF)

__* 7=ILF1

__* 10=ILF2

__* 15=ILF3

ILF1+ILF2+ILF3

Interfaces externas (EIF)

__* 5=EIF1

__* 7=EIF2

__* 10=EIF3

EIF1+EIF2+EIF3

Total UAF

(EI1+EI2+EI3) + (EO1+EO2+EO3) + (EQ1+EQ2+EQ3) + (ILF1+ILF2+ILF3) + (EIF1+EIF2+EIF3)

O valor final de pontos de função precisa ser ajustado de acordo com 14 características gerais de sistemas, com valores que variam numa escala de 0 a 5 graus, com um menor indicando “sem influência” e o maior indicando “forte influência”.

As 14 características são:

  1. Comunicação de dados
  2. Funções distribuídas
  3. Objetivos de desempenho
  4. Configuração utilizada
  5. Taxa de transação
  6. Entrada de dados on-line
  7. Eficiência do usuário final
  8. Atualização on-line
  9. Processamento complexo
  10. Reusabilidade
  11. Facilidade de instalação
  12. Facilidade de operação
  13. Múltiplos locais
  14. Facilidade de mudança

A soma dos valores de 0 a 5, atribuídos a cada uma das características, é utilizada na fórmula do valor ajustado (VAF), descrita abaixo.

O valor de ajuste VAF é dado pela fórmula abaixo:

VAF = 0.65 + (soma dos valores)/100

O valor final de pontos de função é dado pela fórmula

FP = UAF + VAF

Estimar estes valores para um sistema de informação não é difícil. No entanto, para sistemas de controle, sistemas multimídia, sistema embutidos e outros, não é fácil identificar os valores para estas variáveis.

Esforço Humano

Estimar o esforço humano é fundamental para o planejamento. O esforço humano define uma métrica que estabelece a relação entre o tempo necessário para realizar uma atividade e o número de pessoas envolvidas. Isto porque a duração da atividade pode variar de acordo com o número de pessoas envolvidas com ela. Para isto é necessário que a tarefa possa ser dividida e compartilhada entre os desenvolvedores.

Por exemplo, um trabalhador pode colher um laranjal em 10 dias. Se 10 trabalhadores forem utilizados, em apenas 1 dia o laranjal será colhido. No entanto, nem sempre é possível compartilhar uma tarefa, pois embora uma mulher possa gerar 1 filho em 9 meses, 9 mulheres não podem gerar 1 filho em 1 mês!

Estimar o esforço é indicar a quantidade de pessoas necessária para realizar uma atividade num certo período de tempo. As unidades utilizadas são: pessoa-mês, pessoa-hora, homem-mês, ou qualquer combinação entre ser humano e unidade de tempo.

Para entender melhor, o esforço reflete a relação inversa entre o número de trabalhadores e o tempo para realizar a atividade. Isto, no entanto, não pode deixar de levar em consideração fatores externos que limitam o aumento do número de trabalhadores. Quanto mais trabalhadores compartilhando uma tarefa, mais canais de comunicação são estabelecidos, mais compromissos são gerados, maior cooperação é necessária e maiores conflitos podem existir. Tudo isso pode limitar o aumento da produtividade global da equipe.

No livro “The Mythical Man-Month", um clássico da engenharia de software, Fred Brooks relata sua experiência no desenvolvimento do OS 360 da IBM e mostra que tentar cumprir prazos de projetos atrasados com o aumento do número de trabalhadores pode ter efeito contrário.

Para saber mais:

Brooks, Jr., F.P. The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Reading, MA: Addison-Wesley, 1995, 322 pages.

Estimativas de Software

As estimativas do produto e do processo são a base para o planejamento do projeto de software. As estimativas fornecem dados que permite prever a quantidade de pessoas que serão necessárias, o tempo necessário e os custos do projeto. Não é possível elaborar cronograma e orçamento sem o uso de estimativas.

É importante ressaltar que os diversos elementos do planejamento estão relacionados entre si. Por exemplo, um dos maiores impactos nos custos de um software são os recursos humanos. Normalmente, um desenvolvedor ganha um salário mensal tornado este custo diretamente proporcional ao tempo de desenvolvimento.

Para determinar o tempo de desenvolvimento é necessário estimar a duração das atividades do software. Estimativas da duração do software dependem do tamanho do software que é necessário produzir e da produtividade dos desenvolvedores.

Estimativas são realizadas com base em métricas. Métricas de tamanho, duração, produtividade e esforço estão entre as mais utilizadas. Para fazer as estimativas, pode optar por duas estratégias:

  • Métricas com base no histórico da organização
  • Métricas estatísticas de diferentes organizações

As métricas históricas funcionam bem quando a organização é estável e já possui informações colhidas em anos de experiência. Para isso, é fundamental que exista um processo de gerenciamento do processo de software cuidadoso e que todos os dados sejam obtidos para serem analisados e avaliados. Como isso, pode-se estimar como a equipe irá produzir ou qual será o tamanho do software a partir de casos anteriores semelhantes.

Neste caso, as estimativas podem ser realizadas por especialistas que atribuem valores com base em sua experiência de projetos anteriores. Neste caso, pode-se utilizar analogias com projetos anteriores e estimar quais seriam os valores para o novo projeto.

A métricas estatísticas são elaboradas por empresas especializadas que obtêm dados de diversas organizações de desenvolvimento de software. Estes dados devem levar em consideração as diversas condições e características que causem impacto no desenvolvimento do software. Com base nestes valores, os especialistas elaboram tabelas, fórmulas e algoritmos que podem ser aplicadas no planejamento de um processo de software. Isto permite que as organizações de desenvolvimento possam elaborar o seu planejamento ajustando os valores às suas próprias condições.

Os métodos algorítmicos para a realização de estimativas oferecem uma opção mais independente e objetiva. Um exemplo desses métodos são as estimativas de esforço. Esses métodos estão centrados no tamanho do software e da produtividade da equipe:

Esforço = Produtividade*Tamanho^B*M

Existem diversas variantes desta fórmula de maneira que se possa realizar ajustes de acordo com as características da organização e de outros fatores relacionados ao produto.

Um exemplo de modelo baseado nesta fórmula é o COCOMO (Modelo de custos construtivo). A versão inicial foi proposta em 1981, por Barry Boehm. Esta versão evoluiu para o COCOMO II que considera características dos software atuais. O COCOMO II permite associar multiplicadores que levam em consideração o nível (fase) do projeto e a sua complexidade.

Veja a apresentação powerpoint sobre este assunto.

Para saber mais:

COCOMO II

Planejamento e Gerenciamento de Projetos de Software

Quase todas as atividades que desempenhamos precisam ser planejadas e gerenciadas. Atividades de engenharia requerem um planejamento cuidadoso. Normalmente, os produtos são complexos, com muitas partes envolvidas, e as atividades são realizadas por um grupo muito grande de pessoas.

Na engenharia de software não é diferente. Um projeto de engenharia de software deve estar baseado em um planejamento para que se possa gerenciar adequadamente a sua realização.

Planejamento

Planejar é estimar quais as atividades deverão ser realizadas; quem deverá realizá-las; quando devem ser realizadas e finalizadas; e quanto elas deverão custar. Tudo isto requer a elaboração de estimativas em relação ao número e à dimensão dos artefatos, do número de pessoas necessárias, dos prazos e dos custos.

Para isto, a atividade de planejamento deverá resultar:

  • Na realização de estimativas
  • Na elaboração da estrutura de divisão do trabalho (WBS – Work Breakdown Structure)
  • Na definição da equipe e demais recursos
  • Na alocação de pessoa-atividade
  • Na elaboração do cronograma
  • Na elaboração do orçamento

Além disso, a análise de riscos e as revisões periódicas do plano são fundamentais para garantir que ele seja cumprido.

O planejamento está diretamente ligado ao processo de software. Conforme dissemos anteriormente, um processo de software é resultado do planejamento associado a um modelo de processo (método). O modelo de processo indica quais atividades devem ser realizadas e qual a dependência entre elas. Por exemplo, no modelo cascata, deve-se especificar os requisitos, desenhar a arquitetura, fazer o design detalhado, implementar as unidades, integrar as unidades e, finalmente, entregar o software. O planejamento deve indicar quem faz estas atividades, quanto tempo é necessário para eles, quando elas serão realizadas e quanto custará cada um delas.

Sem um planejamento adequado, os desenvolvedores não saberão o que fazer e não terão datas para iniciar ou terminar o trabalho. Sem estimativas, o responsável pelo planejamento não terá como dimensionar o tamanho e a quantidade dos artefatos a serem produzidos e o esforço necessário para produzi-los. Por fim, sem um orçamento, não se terá noção quanto o software irá custar e se haverá recursos para o desenvolvimento.

Gerenciamento

Gerenciar é fazer cumprir o que foi planejado. O papel do gerente de projetos de software é coordenar a equipe, controlar a produção dos artefatos, fazer cumprir prazos e custos, analisar métricas de produção.

O gerenciamento de software está diretamente ligado à garantia da qualidade do processo e do produto de software. O uso de métricas de qualidade, tanto do produto como do processo, são fundamentais para o gerenciamento. Com base em métricas, o gerente tem condições de avaliar se o planejamento está sendo cumprido ou não. Neste caso, as métricas podem apontar as causas dos problemas e permitir as revisões no planejamento.

Exemplos de métricas do produto utilizadas no planejamento são: tamanho do software em linha de código fonte; número de pontos-de-função; número de diagramas de arquitetura; números de defeitos; entre outras.

Exemplos de métricas de processo utilizadas no planejamento são: o esforço; a produtividade; entre outras.

Plano de Projeto de Software

O resultado de um plano de projeto de software é um documento contendo a equipe, o WBS, a alocação pessoa-tarefa, a análise de riscos, o cronograma, o orçamento entre outros.

A estrutura de um plano de projeto de software, segundo Ian Sommerville (2004) é a seguinte.

  1. Introdução
  2. Organização de projeto
  3. Análise de riscos
  4. Requisitos necessários de hardware e software
  5. Estrutura analítica de trabalho
  6. Cronograma de projeto
  7. Mecanismos de monitoramento e elaboração de relatórios

Esta estrutura pode variar de acordo com as características do projeto.

Diversos outros documentos podem complementar informações importantes:

  • Plano de qualidade – descreve os procedimentos de testes de qualidade que serão utilizados.
  • Plano de validação – descreve a abordagem, os recursos e o método utilizados pa validação.
  • Plano de manutenção – prevê requisitos, custos e esforço necessário para a manutenção.
  • Plano de desenvolvimento da equipe – descreve como as habilidades e a experiência serão desenvolvidas.
Veja mais em nosso slides.

Referência

Ian Sommerville - Engenharia de Software