Métricas de Software Introdução da Estimativa na Engenharia de Software

...

Tipos de Métricas de Software

Em concordância com o que foi exposto anteriormente, existem muitos desafios para se encontrar uma métrica que possa compreender todo e qualquer projeto de desenvolvimento de software. Para se ter mais conteúdo, ao longo do tempo, as empresas de desenvolvimento de software devem criar uma base local de dados com medidas, métricas e indicadores de projetos anteriores (base histórica) para amparar e provisionar mais subsídios aos engenheiros de software bem como coordenadores e gerentes de projeto.

Na internet é possível encontrar serviços que disponibilizam bases de informação sobre projetos, é possível encontrar informações também em livros e artigos acadêmicos como fontes relevantes e comunidades de Engenharia de Software. Apesar de tudo, desenvolver uma aplicação apoiada em, pelo menos, uma métrica e/ou modelo disponível, escolhida cuidadosamente para atender ao projeto, produzirá resultados úteis se forem utilizadas de acordo com o ambiente especificado.

A Análise de Pontos de Função (APF) é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seu usuário. O Ponto de Função (PF) é a unidade de medida desta técnica que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software.

De maneira geral, quando se faz contagem de pontos por função as empresas procuram focar na medição das funcionalidades do software, ou seja, o que ele efetivamente faz ao invés de procurar saber com qual tecnologia este foi construído. A metodologia foi criada na IBM no início da década de 1970 por Alan Albrecht devido à necessidade de estudar a produtividade de projetos de aplicações desenvolvidas em linguagens de programação distintas, onde não seria inviável a métrica por linhas de código.

Depois de ganhar popularidade, em 1986 foi criado o International Function Point Users Group (IFPUG) visando à padronização da técnica da atividade de contagem de pontos de função. Atualmente a versão mais recente do COM, além de manter um programa de certificação para profissionais especializados em aplicar a técnica, chamado de CFPS (Certified Function Point Specialist).

No Brasil existe o BFPUG (Brazilian Function Point Users Group), constituído em 1998, onde está ligado diretamente com o FPUG no país e possui centenas de associados. A ISBSG (International Software Benchmarking Standards Group), iniciativa de organizações de métricas de software, trata-se de um repositório público de métricas de projetos de software para ajudar na gestão dos recursos de TI, estimativas de projeto e produtividade, análise de riscos e benchmarking.

Contar Funções do Tipo Transação São funcionalidades que representam os requisitos referentes ao processamento de dados do sistema, divididas em:

- Entrada Externa – EE: transações que processam dados ou informação de controle que entram, originalmente, de fora da fronteira da aplicação. Seu objetivo principal é manter um ou mais ALI ou alterar o comportamento do sistema. Exemplo: Operações para inserir, alterar e excluir.

- Saída Externa – SE: transações que enviam dados ou informações de controle para fora da fronteira da aplicação. Seu objetivo principal é apresentar informação para um usuário ou outra aplicação através de um processamento lógico adicional à recuperação de dados ou informação de controle. O processamento lógico deve conter cálculo, ou criar dados derivados, ou manter ALI ou alterar o comportamento do sistema. Exemplo: Relatórios em geral.

- Consulta Externa – CE: transações que enviam dados ou informações de controle para fora da fronteira da aplicação. Seu objetivo principal é apresentar informação para o usuário através da recuperação de dados ou informação de controle de ALI ou AIE. Exemplo: Consultar dados cadastrados por EE.

Para compreender melhor as métricas se faz necessário definir complexidade e calcular o tamanho funcional identificado, assim, os tipos funcionais para cada requisito funcional, consegue-se definir a sua complexidade (Baixa, Média, Alta), bem como para cada Entrada Externa, Saída Externa e Consulta Externa e a contribuição funcional para a contagem de pontos de função. Para garantir que a identificação e a avaliação das complexidades dos tipos funcionais não sejam definidas de forma subjetiva, o IFPUG orienta que a contagem de pontos de função deve seguir rigorosamente as regras de contagem do CPM e as definições complementares do roteiro de métricas do órgão.

Estimar os recursos necessários para realizar o esforço do desenvolvimento do software, recursos esses divididos em: “mão de obra”, componentes de software reusáveis e ambiente de desenvolvimento agregam para o desenvolvimento da atividade. O tamanho de um software é uma variável fundamental para estimar o esforço para sua construção. Logo, saber o seu tamanho é um dos primeiros passos do processo de estimativa de esforço, prazo e custo.

Estimativas em Projetos de Software

As estimativas em projetos iniciam durante as atividades de planejamento onde o objetivo é criar uma estrutura que permita ao gerente do projeto realizar estimativas razoáveis, baseado nos dados levantados, dos recursos necessários, do custo do projeto e do cronograma (prazos) conforme modelo abaixo.

Processo de Estimativa

[pic 1][pic 2][pic 3]

[pic 4]

[pic 5]

[pic 6][pic 7][pic 8][pic 9][pic 10][pic 11][pic 12][pic 13][pic 14][pic 15]

Com base nesses dados, junto com análise de riscos, é possível verificar a viabilidade do projeto. Para realizar a estimativa de custo e esforço no desenvolvimento de software não é uma ciência exata. Os dados históricos são importantes para a etapa de planejamento, onde na definição do escopo se faz necessário estimar a dimensão do software como um todo. O escopo do software descreve as funções (restrições, interface e confiabilidade) a serem entregues ao usuário, os dados e controles a serem processados, bem como o desempenho esperados;

Exercício Resolvido

Requisitos e Características do Projeto:

Sistema de admissão em fase inicial de determinação de requisitos.

Desenvolvimento