GERÊNCIA – MÉTRICAS DE SOFTWARE
Processo
de Gerência de Projetos
A
gerência de projetos de software oferece uma compreensão desde o escopo do
trabalho a ser feito, os riscos, recursos exigidos, tarefas a serem executadas,
marcos de referência a serem acompanhados, esforço ( custo) despendido e a
programação a ser seguida.Portanto, ela começa antes do trabalho técnico,
prossegue à medida que o software se desenvolve do modelo conceitual para a
realidade e encerra somente quando o software se torna obsoleto.
Os elementos-chave da gerência de projetos de software são:
Os elementos-chave da gerência de projetos de software são:
- Iniciando um Projeto de Software
- Medidas e Métricas
- Estimativa
- Análise dos Riscos
- Determinação de Prazos
- Monitoração e Controle
Os
objetivos e o escopo do projeto são definidos pelo desenvolvedor de software e
o cliente. Os objetivos identificam as metas globais do projeto sem levar em
consideração como essas metas serão atingidas. O escopo identifica as funções
primárias que o software deve realizar e tenta delimitar essas funções de forma
quantitativa.
Aqui são também consideradas soluções alternativas para possibilitar uma abordagem melhor, visando as restrições impostas por prazos de entrega, orçamento, disponibilidade de pessoal, interfaces técnicas e outros fatores.
Aqui são também consideradas soluções alternativas para possibilitar uma abordagem melhor, visando as restrições impostas por prazos de entrega, orçamento, disponibilidade de pessoal, interfaces técnicas e outros fatores.
Pela
medição é possível quantificar e assim administrar melhor. O processo é medido
num esforço para melhorá-lo. O produto é medido, num esforço para aumentar a
sua qualidade. Porém, às vezes surgem indagações do tipo: Quais são as métricas
apropriadas para o processo e para o produto? É justo usar medições para se
comparar pessoas, processos e produtos? Essas perguntas vem à tona quando é
feita uma tentativa de se medir alguma coisa que não tenha sido medido no
passado. Assim acontece com a engenharia de software (o processo) e o software
(o produto).
Geralmente,
estimativas são feitas usando-se a experiência passado como único guia. Se um
novo projeto for muito semelhante, em termos de tamanho e função, a um projeto
passado, provavelmente esse novo projeto exigirá aproximadamente a mesma
quantidade de esforço, tomará o mesmo tempo em calendário e custará o mesmo
valor em dólares.
Se o projeto romper novos horizontes, novas técnicas de estimativas foram disponibilizadas para o desenvolvimento de software com os seguintes atributos:
* O escopo do projeto deve ser estabelecido antecipadamente.
* Métricas de software são utilizadas e o histórico de aferições passadas é usado como uma base a partir da qual estimativas são feitas.
* O projeto é dividido em pequenas partes que são estimadas individualmente.
Se o projeto romper novos horizontes, novas técnicas de estimativas foram disponibilizadas para o desenvolvimento de software com os seguintes atributos:
* O escopo do projeto deve ser estabelecido antecipadamente.
* Métricas de software são utilizadas e o histórico de aferições passadas é usado como uma base a partir da qual estimativas são feitas.
* O projeto é dividido em pequenas partes que são estimadas individualmente.
A análise
dos riscos é uma série de passos de administração de riscos que nos possibilita
"atacar" o risco: identificação dos riscos, avaliação dos riscos,
disposição dos riscos por ordem de prioridade, estratégias de administração dos
riscos, resolução dos riscos e monitoração dos riscos.
A
programação do projeto de software identifica um conjunto de tarefas de
projeto. Interdependências entre as tarefas são estabelecidas. O esforço
associado a cada tarefa é estimado. Pessoas e outros recursos são atribuídos.
Uma "rede de tarefas"é criada, para garantir que o prazo final seja
cumprido.
A
monitoração e controle se inicia assim que a programação de desenvolvimento for
estabelecida. Cada tarefa anotada no programa é então rastreada pelo gerente de
projetos. Se a tarefa não acompanhar a programação, o gerente pode usar uma
ferramenta de planejamento e controle de projetos automatizada para determinar
o impacto do não-cumprimento dos prazos sobre os marcos de referência
intermediários do projeto e a data de entrega global. Recursos podem ser
redirecionados, tarefas reordenadas e compromissos de entrega modificados para
acomodar o problema que foi descoberto. Assim, o desenvolvimento de software
pode ser mais bem controlado.
Métricas
de Produtividade e Qualidade do Software
Métricas
do Software referem-se a uma ampla variedade de medidas de software de
computador. Dentro do contexto de gerenciamento de projetos de software, a
primeira preocupação são com as métricas de produtividade e qualidade. A seguir
será mostrado a ampla variedade de métricas do software.
Medidas
do Software
O
software é medido por muitas razões: indicar a qualidade do produto, avaliar a
produtividade das pessoas que produzem o produto, avaliar os benefícios
derivados de novos métodos e ferramentas de software, formar uma linha básica
para estimativas, ajudar a justificar os pedidos de novas ferramentas ou
treinamento adicional.
Entre as medidas diretas do processo de engenharia de software incluem-se o custo e o esforço aplicados. As medidas diretas do produto incluem as linhas de código produzidas, velocidade de execução, tamanho de memória e defeitos registrados ao longo de certo espaço de tempo. As medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade e outras.
O domínio das métricas de software pode ainda ser dividido entre métricas da produtividade que se concentra na saída do processo de engenharia de software e métricas da qualidade que mostra o quão o estreitamente o software conforma-se às exigências implícitas e explícitas do cliente. Métricas técnicas concentram-se na característica do software e não no processo pelo qual o software foi desenvolvido.
Métricas Orientadas ao Tamanho são usadas para compilar as medições diretas da saída e da qualidade da engenharia de software. Métricas Orientadas para a função oferecem medidas indiretas e Métricas Orientadas às Pessoas compilam informações sobre a maneira segundo a qual as pessoas desenvolvem software de computador.
Entre as medidas diretas do processo de engenharia de software incluem-se o custo e o esforço aplicados. As medidas diretas do produto incluem as linhas de código produzidas, velocidade de execução, tamanho de memória e defeitos registrados ao longo de certo espaço de tempo. As medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade e outras.
O domínio das métricas de software pode ainda ser dividido entre métricas da produtividade que se concentra na saída do processo de engenharia de software e métricas da qualidade que mostra o quão o estreitamente o software conforma-se às exigências implícitas e explícitas do cliente. Métricas técnicas concentram-se na característica do software e não no processo pelo qual o software foi desenvolvido.
Métricas Orientadas ao Tamanho são usadas para compilar as medições diretas da saída e da qualidade da engenharia de software. Métricas Orientadas para a função oferecem medidas indiretas e Métricas Orientadas às Pessoas compilam informações sobre a maneira segundo a qual as pessoas desenvolvem software de computador.
Métricas
Orientadas ao Tamanho
Aqui, é usada uma tabela de dados orientados ao tamanho, se a organização de software mantiver registros simples.
Esta tabela relaciona cada projeto de desenvolvimento de software que foi concluído no decorrer dos últimos anos aos correspondentes dados orientados ao tamanho desse projeto. Exemplo:
Aqui, é usada uma tabela de dados orientados ao tamanho, se a organização de software mantiver registros simples.
Esta tabela relaciona cada projeto de desenvolvimento de software que foi concluído no decorrer dos últimos anos aos correspondentes dados orientados ao tamanho desse projeto. Exemplo:
Projeto
|
Esforço
|
$
|
KLOC
|
Págs.Docum.
|
Erros
|
Pessoas
|
Aaa-01
|
24
|
168
|
12.1
|
365
|
29
|
3
|
ccc-04
|
62
|
440
|
27.2
|
1224
|
86
|
5
|
Fff-03
|
43
|
314
|
20.2
|
1050
|
64
|
6
|
Para
o projeto aaa-01: 12.1 KLOC ( mil linhas de código) foram desenvolvidas com 24
pessoas-mês de esforço a um custo de 168 mil dólares. 365 páginas de
documentação foram desenvolvidas e 29 erros foram encontrados após a entrega ao
cliente dentro do primeiro ano de operação. Três pessoas trabalharam no
desenvolvimento de software para o projeto aaa-01.
A partir destes dados da tabela, um conjunto de métricas de qualidade e de produtividade orientadas ao tamanho pode ser desenvolvido para cada projeto:
Produtividade = KLOC /pessoa-mês Qualidade = defeitos / KLOC
A partir destes dados da tabela, um conjunto de métricas de qualidade e de produtividade orientadas ao tamanho pode ser desenvolvido para cada projeto:
Produtividade = KLOC /pessoa-mês Qualidade = defeitos / KLOC
As
métricas orientadas ao tamanho provocam controvérsias e não são universalmente
aceitas como a melhor maneira de se medir o processo de desenvolvimento de
software. Esta controvérsia gira em torno do uso de linhas de código como uma
medida-chave.
Métricas
Orientadas à Função
A Métrica
Orientada à Função concentra-se na funcionalidade ou utilidade do programa, ao
invés de contar as linhas de código do projeto. É chamado ponto por
função a abordagem à medição da produtividade.
As organizações que usam métodos de pontos por função desenvolvem critérios para determinar se uma entrada particular é simples, média ou complexa. Para computar os pontos por função, a seguinte relação é usada:
FP = contagem total * [ 0.65 + 0.01 * soma(Fi)], onde a contagem total é a soma de todas as entradas de FP obtidas a partir da tabela acima.
Assim que forem calculados, os pontos por função serão usados de maneira análoga às LOC como medidas de produtividade, qualidade e outros atributos de software :
Produtividade = FP / pessoa-mês Qualidade = defeitos / FP Custo = $ / Fp
Documentação = páginas de documentação / FP
As organizações que usam métodos de pontos por função desenvolvem critérios para determinar se uma entrada particular é simples, média ou complexa. Para computar os pontos por função, a seguinte relação é usada:
FP = contagem total * [ 0.65 + 0.01 * soma(Fi)], onde a contagem total é a soma de todas as entradas de FP obtidas a partir da tabela acima.
Assim que forem calculados, os pontos por função serão usados de maneira análoga às LOC como medidas de produtividade, qualidade e outros atributos de software :
Produtividade = FP / pessoa-mês Qualidade = defeitos / FP Custo = $ / Fp
Documentação = páginas de documentação / FP
A métrica
de ponto por função é controversa. Os que propõe tal métrica afirmam que ela é
ideal para aplicações que usam linguagens convencionais e não-procedimentais e
se baseia em dados que tem maior probabilidade de ser conhecidos logo no início
da evolução do projeto.
Os opositores a tal métrica afirmam que a contagem se baseia parcialmente em dados subjetivos e não objetivos; que os dados sobre o domínio da informação podem ser difíceis de ser compilados a posteriori; e que o FP não tem nenhum significado físico direto - é apenas um número.
Métricas de Qualidade do Software
Os opositores a tal métrica afirmam que a contagem se baseia parcialmente em dados subjetivos e não objetivos; que os dados sobre o domínio da informação podem ser difíceis de ser compilados a posteriori; e que o FP não tem nenhum significado físico direto - é apenas um número.
Métricas de Qualidade do Software
A
qualidade pode ser medida ao longo do processo de engenharia de software e
depois que o software for entregue ao cliente e aos usuários.
Métricas de Qualidade incluem a complexidade do programa, modularidade efetiva e tamanho do programa. Métricas usadas após a entrega concentram-se no número de defeitos descobertos e na manutenibilidade do sistema.
Métricas de Qualidade incluem a complexidade do programa, modularidade efetiva e tamanho do programa. Métricas usadas após a entrega concentram-se no número de defeitos descobertos e na manutenibilidade do sistema.
Medida da
Qualidade
Medida de
Qualidade de Software são algumas definições e medidas amplamente usadas para
medir um software:
Corretitude:
é o grau
em que o software executa a função que é dele exigida. Um programa deve operar
corretamente, senão oferecerá pouco valor aos seus usuários.
Manutenibilidade: é a facilidade com que um
programa pode ser corrigido se um erro for encontrado, adaptado se o seu
ambiente se modificar ou ampliado se o cliente desejar inclusões e alterações
nos requisitos funcionais.
Integridade: mede a capacidade que um sistema
tem de suportar ataques (tanto acidentais como intencionais) à sua integridade.
Dois atributos adicionais devem ser definidos:
Ameaça: é a probabilidade de que um ataque de um tipo específico ocorrerá dentro de um determinado tempo.
Segurança: é a probabilidade de que o ataque de um tipo específico será repelido.
Ameaça: é a probabilidade de que um ataque de um tipo específico ocorrerá dentro de um determinado tempo.
Segurança: é a probabilidade de que o ataque de um tipo específico será repelido.
Usabilidade: é uma tentativa de se
quantificar a user friendliness (amigável ao usuário). Pode ser medido
segundo quatro características:
1. habilidade física ou intelectual exigida para se aprender o sistema;
2. tempo exigido para se tornar moderadamente eficiente no uso do sistema;
3. aumento líquido de produtividade medodo quando o sistema é usado por alguém que seja moderadamente eficiente;
4. uma avaliação subjetiva das atitudes dos usuários em relação ao sistema.
1. habilidade física ou intelectual exigida para se aprender o sistema;
2. tempo exigido para se tornar moderadamente eficiente no uso do sistema;
3. aumento líquido de produtividade medodo quando o sistema é usado por alguém que seja moderadamente eficiente;
4. uma avaliação subjetiva das atitudes dos usuários em relação ao sistema.
Integração
de Métricas dentro do Processo de Engenharia de Software
Estabelecimento
de uma linha básica (baseline)
Consiste
de dados compilados de projetos passados de desenvolvimento de software. Além
das medidas orientadas à função ou ao tamanho, a baseline pode ser
complementada com métricas de qualidade.
A linha básica deve ter os seguintes atributos, para um melhor auxílio no planejamento estratégico ou estimativas de custo e esforço:
A linha básica deve ter os seguintes atributos, para um melhor auxílio no planejamento estratégico ou estimativas de custo e esforço:
- os dados devem ser razoavelmente precisos;
- os dados devem ser obtidos de tantos projetos quanto for possível;
- as medições devem ser consistentes;
- as aplicações devem ser idênticas ao trabalho que será estimado.
Coleta,
Computação e Avaliação das Métricas
O
processo para se estabelecer uma linha básica é ilustrado na figura abaixo:
Coleta de dados: requer uma investigação
histórica dos projetos passados para se reconstruir os dados exigidos;
Computação das Métricas: dependendo da amplitude dos dados coletados, as métricas podem abranger uma ampla variedade de medidas LOC ou FP. Logo após, os dados devem ser avaliados e aplicados na estimativa.
Avaliação dos Dados: concentra-se nas razões subjacentes para os resultados obtidos
Computação das Métricas: dependendo da amplitude dos dados coletados, as métricas podem abranger uma ampla variedade de medidas LOC ou FP. Logo após, os dados devem ser avaliados e aplicados na estimativa.
Avaliação dos Dados: concentra-se nas razões subjacentes para os resultados obtidos
Nenhum comentário:
Postar um comentário