Métricas de Software.
• Medições podem ser aplicadas ao processo de software com a intenção de melhoria contínua. As medições podem ser usadas durante um projeto para ajudar nas estimativas, controle de qualidade, produtividade, e controle de projeto. Finalmente, a medição pode ser usada pelos engenheiros de software para
ajudar a avaliar a qualidade dos artefatos e auxiliar na tomada de
decisões táticas na medida em que o projeto evolui. [PRESSMAN,
2011].
• As métricas de projeto e processo são medidas quantitativas que permitem o discernimento sobre a eficácia do processo de
software e os projetos que são executados usando o processo como uma estrutura.
• As métricas de software são analisadas e avaliadas por gerentes de
software e normalmente coletadas por engenheiros de software.
• Métricas nos domínios de processo e projeto.
• Métricas de processo são coletadas ao longo prazo no decorrer de vários projetos.
• Métricas de projeto permitem ao gerente de projetos:
• Avaliar o estado de um projeto.
• Rastrear os riscos em potencial.
• Descobrir áreas problemáticas antes que se tornem críticas.
• Ajustar o fluxo de trabalho ou tarefas.
• Avaliar a habilidade da equipe de projeto para controlar a
qualidade dos produtos finais de software. (...)
• Métricas nos domínios de processo e projeto.
• A melhoria de qualquer processo é orientada à medição de seus atributos específicos, ao
desenvolvimento de uma série de métricas
significativas com base nestes atributos e a utilização
das métricas para fornecer indicadores que levarão a
uma estratégia de aperfeiçoamento. (...)
• Métricas nos domínios de processo e projeto.
• As métrica de projeto são diferentes das métricas de processo, pois estas são estratégicas e aquelas são táticas. As métricas de projetos são usadas para adaptar o fluxo de trabalho do projeto e as atividades técnicas. Sua primeira aplicação ocorre justamente nas estimativas de esforços e tempo para o trabalho do software, a medida que evoluem, elas são utilizadas para comparação com
medidas de esforço e tempo coletadas no decorrer do projeto e o
gerente de projeto usa esses dados para monitorar e controlar o
progresso do projeto.
• Medidas de Software.
• Medidas diretas:
• Custos e trabalho aplicado.
• Linhas de código (LOC – line of code).
• Velocidade de execução.
• Tamanho de memória.
• Defeitos relatados durante um determinado período de tempo.
(... )
• Medidas de Software.
• Medidas indiretas:
• Funcionalidade.
• Qualidade.
• Complexidade.
• Eficiência.
• Confiabilidade.
• Manutenibilidade. (...)
• Medidas de Software.
• Métricas orientadas a tamanho:
• São criadas normalizando-se as medidas de qualidade ou produtividade considerando o tamanho do software que foi produzido.
• Seu maior representante é o LOC – Linhas de código fonte, mas
gera problemas, pois está orientado diretamente à linguagem
de programação utilizada.
• Medidas de Software.
• Métricas orientadas a função.
• Utilizam uma medida da funcionalidade fornecida pela aplicação como um valor de normalização, veja que ela é independente de linguagem de programação o que a torna ideal para utilização em linguagens de programação convencionais e não procedurais.
• Seu maior representante é o PF – Ponto de Função, mas gera
problemas, pois está orientado à função desejada na visão do
usuário e que acaba gerando uma avaliação subjetiva.
• Medidas de Software.
• Métricas orientadas a objeto.
• Números de script de cenários: um script de cenário é um sequencia detalhada de passos que descrevem a interação entre o usuário e a aplicação. {iniciador, ação, participante}.
Está relacionado com o tamanho da aplicação e com o número de casos de testes que devem ser desenvolvidos.
• Número de classes-chave: classes-chave são os componentes independentes que são definidos logo no inicio em análise OO.
Utilizadas como medida de esforço e reutilização. (...)
• Medidas de Software.
• Métricas orientadas a objeto (cont.)
• Número de classes de apoio: são necessárias para implementar o sistema, mas não estão relacionadas com o domínio do problema.
• Número médio de classes de apoio pra cada classe-chave: as classes- chave são conhecidas logo no início do projeto. As classes de apoio são definidas durante o projeto. Neste caso se o número médio de classes de apoio para cada classe-chave fosse conhecido para um dado
domínio de problema, a estimativa seria bem simples.
• Número de subsistemas: um subsistema é uma agregação de classes que apoia uma função visível ao usuário final.
• Medidas de Software.
• Métricas orientadas a casos de uso.
• Assim como um FP, um caso de uso é definido no inicio do processo de software, permitindo que ele seja usado pra estimativas antes de
iniciar atividades de modelagem e construção do software.
• Os UCs descrevem funções e características visíveis aos usuário que são requisitos básicos para o sistema.
• Ele é independente de linguagem de programação.
• Como eles podem ser criados em níveis diferentes de abstração, não há um “tamanho” padrão para um UC, o que torna essa medida um pouco
Métricas de Software – APF.
• A técnica de Análise de Pontos de Função é utilizada para medir software em contratos, possibilitando dimensionar os projetos da organização oferecendo assim indicadores.
• Traz facilidades na gestão de projetos de software.
• Possibilita a implantação de processos de medição como citado, por
exemplo, no CMMI.
• Entendemos a métrica de software como uma medida de alguma propriedade de um software ou de suas especificações.
• Tamanho.
• Defeitos.
• Esforço.
• Tempo de duração.
• Custo.
• Pontos de Função (PF) é uma métrica padrão para dimensionar o tamanho funcional de projetos de software.
• A métrica PF quantifica o tamanho de um projeto de software com base na análise dos requisitos funcionais do projeto. Foi criada por Allan Albrecht em 1979 e é mantida pelo International Function
Point Users Group (IFPUG).
• PF é reconhecida pelo padrão ISO, sendo seu uso recomendado em Acórdãos do Tribunal de Contas da União para contratos de software de órgãos públicos.
• Motivos para medirmos software:
• Melhoria dos processos.
• Baseline histórico para estimativas.
• Atingimento das metas de produtividade do processo.
• Atingimento de metas de qualidade do processo.
• Atingimento de metas de qualidade do produto.(...)
• Motivos para medirmos software (cont.):
• Avaliação de benefícios de novas ferramentas e métodos.
• Relacionamento com o cliente.
• Gerência de contratos de software.
• Contratações de TI.
Segundo Tom De Marco: "Não se pode gerenciar o que não se pode medir".
Segundo Pressman: "Se você não sabe onde quer ir, qualquer
caminho pode seguir. Se você não sabe onde está, um mapa não vai
ajudar."
• Objetivos de um processo de medição.
• Fornecer um conjunto de dados, úteis e tangíveis, para apoiar a
gestão de projetos desenvolvidos internamente ou contratados.
• Objetivos de um processo de medição.
• Apoiar nas atividades:
• Comunicar eficientemente dos objetivos e entre organizações contratantes e contratadas.
• Acompanhar objetivos de projetos específicos por meio de status dos processos e dos produtos do projeto de software.
• Identificar e corrigir problemas por meio de uma gerência proativa e identificação de problemas potenciais e priorização de problemas existentes.
• Tomar decisões chaves em relação à gestão e qualidade do projeto (escopo, tempo e custo).
• Apoiar decisões fornecendo base para estimativas e planos com dados de desempenho histórico.
• Objetivos da APF:
• Medir as funcionalidades requisitadas e recebidas pelo usuário.
• Medir projetos de desenvolvimento e de melhoria. (independente de linguagem o projeto terá sempre o mesmo tamanho funcional).
• Ela deve ser:
• Simples para minimizar o trabalho adicional envolvido no processo de contagem.
• Possuir uma media consistente entre projetos e organizações.
• A contagem de Pontos de Função deve ser realizada com base na análise de um documento de requisitos funcionais do sistema. E ainda, este
documento deve ser validado e aprovado pelo cliente.
• A contagem de Pontos de Função é baseada no projeto lógico da
aplicação. Nas fases iniciais do ciclo de vida, onde existem apenas
requisitos de negócio, pode-se realizar uma estimativa de Pontos de
Função do projeto (contagem estimada).
• Existem vários métodos para se estimar o tamanho funcional de projetos em Pontos de Função.
• O Manual de Práticas de Contagem trata apenas o Procedimento
Contagem de Pontos de Função.
• Benefícios da Análise de Pontos de Função
• O uso da técnica Análise de Pontos de Função (APF) traz diversos benefícios para as organizações, sob ponto de vista gerencial:
gestão de projetos de desenvolvimento e de manutenção de sistemas, gestão do processo de desenvolvimento de sistemas, gestão de contratos de projetos de software.
• Apoiar a análise de qualidade e produtividade.
• Estimar o custo e os recursos de um projeto de software.
• (...)
• Benefícios da Análise de Pontos de Função
• Fornecer um fator de normalização para a comparação de software.
• Determinar o tamanho de um pacote de software adquirido, por
meio do dimensionamento funcional de todas as funções incluídas no
mesmo.
• Limitações da APF.
• Não mede requisitos não funcionais (usabilidade, segurança e performance estão fora).
• Mesmo que o tamanho do projeto em PF influencie seu custo e esforço de desenvolvimento, projetos semelhantes poderão ter esforços e custos diferentes. (PFs de linguagens diferentes terão esforços e custos
diferentes).
• Manutenções adaptativas que impliquem em mudanças de requisitos não funcionais são dimensionadas com PF = 0.
• Existe para tanto um roteiro a ser criado dentro dos órgãos para que possam adaptar a APF para sua realidade como o do SISP
www.governoeletronico.gov.br.
• Processo de Contagem de PF.
• Processo de Contagem de PF.
• De acordo com o Function Point Counting Practices Manual.
• Obter a documentação disponível do projeto.
• Análise da documentação com foco na elicitação de requisitos funcionais como base da contagem de PF.
• Se não houver documentação, recorrer ao especialista de negócio.
• A documentação poderá conter:
• Requisitos.
• Modelos de dados/objetos.
• Diagramas de classe.
• Diagramas de fluxo de dados.
• Casos de uso.
• Descrições procedurais.
• Identificar o Propósito da Contagem.
• Responder à questão do negócio a ser resolvida. O propósito da
contagem irá influenciar o estabelecimento da fronteira do software e do escopo da contagem, bem como o tipo da contagem.
• Determina:
• O tipo de contagem de PF e o escopo.
• Influência o posicionamento da fronteira da aplicação sendo medida.
• Identificar o Tipo de Contagem.
• Podem estar associados ao projeto e à aplicação e podem ser:
• Projeto de desenvolvimento: medida de funcionalidade oferecida aos usuários com a primeira instalação do software. Novos sistemas.
• Projeto de melhoria: medida de funcionalidades incluídas, alteradas e excluídas pelo projeto de melhoria na aplicação. Observar que
dentro da Engenharia de software este tipo de projeto é chamado de projeto de melhoria funcional ou projeto de manutenção evolutiva.
• Aplicação (uma aplicação instalada): medida de funcionalidade que uma aplicação oferece ao usuário. É também denominada de
baseline ou tamanho funcional instalado. (...)
• Identificar o Tipo de Contagem.
• A contagem inicial é uma estimativa, a contagem final deverá ser feita
mediante entrega e homologação da solução final ao cliente, isto pois que poderá haver mudanças bem interessantes devido às mudanças de
requisitos no decorrer do projeto.
• Determinar o Escopo da Contagem.
• Conjunto de funcionalidades (requisitos funcionais) a ser considerado na contagem de PF.
• O escopo da contagem:
• Define o (sub)conjunto do software que está sendo medido.
• É determinado pelo propósito da contagem de pontos de função.
• Identifica quais funcionalidades serão incluídas na contagem de PF.
• Pode incluir mais de uma aplicação. (cada aplicação constitui uma fronteira de contagem).
• Determinar a Fronteira da Aplicação.
• Determinação do limite lógico entre o projeto que está sendo contado e o usuário (usuário, outra aplicação hardware, middleware ou software que interage com o sistema sendo contado).
• Deve ser determinada sob uma perspectiva de negócio.
• (...)
• Determinar a Fronteira da Aplicação.
• A fronteira:
• Define o que é externo e interno.
• Indica o limite entre software e usuário.
• Agrupa os dados lógicos mantidos pela aplicação (ALI).
• Auxilia na identificação dos dados lógicos referenciados mas não mantidos (AIE).
• É independente de técnicas de arquitetura.
• Contar Funções de Dados.
• Representam as funcionalidades fornecidas ao usuário (os requisitos de negócio da aplicação) através de dados internos ou externos. São
identificadas como:
• grupo de dados logicamente Arquivo Lógico Interno (ALI):
relacionados, reconhecido pelo usuário, mantido por meio de um processo elementar da aplicação que está sendo contada. (tabelas estáticas mantidas pela equipe de desenvolvimento não são contadas e as entidades dependentes fazem parte de um mesmo ALI).(...)
• Contar Funções de Dados.
• Arquivo de Interface Externa (AIE): grupo de dados logicamente relacionados, reconhecido pelo usuário, mantido por meio de um processo elementar de outra aplicação e referenciado pela aplicação que está sendo contada. Ele não é mantido pelas funcionalidades da aplicação que está sendo contada, ao contrário do ALI.
• OBS.: UM AIE será obrigatoriamente um ALI de outra aplicação.
• Contar Funções Transacionais.
• Representam funcionalidades de processamento providas ao usuário, são processos elementares que fornecem funcionalidades para processar
dados (todos eles são processos elementares).(...)
• Processo elementar é a menor unidade de atividade significativa para o usuário, é uma transação completa.
• Entrada Externa (EE): trata dados ou informações de controle que
“entram” pela fronteira da aplicação. Mantem um ou mais arquivos lógicos Internos ou altera o comportamento do sistema.
• Saída Externa (SE): envia dados ou informações de controle para fora da fronteira. Apresenta informações para um usuário, por meio de um processamento adicional à recuperação de dados ou informações de controle. Pode também manter arquivos lógicos internos ou alterar o comportamento do sistema.
• Consulta Externa (CE): envia dados ou informações de controle para fora da fronteira da aplicação. Apresenta informações para o usuário por meio da recuperação de dados ou informações de controle de ALIs ou AIEs.
• OBS.: toda CE deve ler dados de pelo menos um Arquivo Lógico (ALI ou AIE).
• O processo consiste em;
• Identificar os processos elementares.
• Definir se o processo identificado é uma EE, CE ou SE.
• Arquivo Referenciado (AR): considera os ALIs e AIEs atualizados ou lidos durante o processamento de uma EE, SE ou CE.
• Tipo de Dado (TD): seu quantitativo é dado pelo número total de atributos identificados pelo usuário que atravessam a fronteira da aplicação durante uma EE, SE ou CE. Não devem ser considerados como TD os campos que são apenas utilizados pela função para processamento interno, bem como número de páginas, data e hora. É contado 1 TD para ação, botões de ação e 1 TD para mensagem, considerando 1 TD para todas as ações e 1 TD para todas as mensagens.
Métricas de Software – APF – Complexidade funcional.
• Entrada Externa (EE).
• Baixa: 3 PF.
• Média: 4 PF.
• Alta: 6 PF.
1 a 4 tipos de dados
5 a 15 tipos de dados
16 ou mais tipos de dados
0 ou 1 arquivo referenciado
Baixa Baixa Média
2 arquivos referenciados
Baixa Média Alta
3 ou mais arquivos referenciados
Média Alta Alta
• Saída Externa (SE)
• Baixa: 4 PF.
• Média 5 PF.
• Alta: 7 PF.
1 a 5 tipos de dados
6 a 19 tipos de dados
20 ou mais tipos de dados
0 a 1 arquivo referenciado
Baixa Baixa Média
2 a 3 arquivos referenciados
Baixa Média Alta
• Consulta Externa (CE)
• Baixa: 3 PF.
• Média: 4 PF.
• Alta: 6 PF.
1 a 5 tipos de dados referenciados
6 a 19 tipos de dados referenciado
20 ou mais tipos de dados referenciado
0 a 1 arquivo referenciado
Baixa Baixa Média
2 a 3 arquivos referenciados
Baixa Média Alta
4 ou mais arquivos referenciados
Média Alta Alta
• Registro Lógico: faz parte do ALI ou AIE e é identificado como um subgrupo de dados, reconhecido pelo usuário.
• Funções de Dados.
• ALI
• Baixa: 7 PF.
• Média: 10 PF.
• Alta: 15 PF.
• AIE
• Baixa: 5 PF.
• Média: 7 PF.
• Alta: 10 PF.
1 a 19 tipos de dados
20 a 50 tipos de dados
51 ou mais tipos de dados
1 Registro Lógico Baixa Baixa Média
2 a 5 Registros Lógicos
Baixa Média Alta
6 ou mais Registros Lógicos
Média Alta Alta
• Determinar valor do fator de reajuste (4.1.1).
• Na época do lançamento da técnica de Pontos de Função, lançada por Allan Albrecht, não havia as 14 CGS – Características Gerais do Sistema e o fator de ajuste era determinado de forma totalmente subjetiva.
• O valor do fator de ajuste (VAF – Value Adjustment Factor) é baseado em 14 características gerais de sistemas (CGS), listadas em seguida.
• Determinar valor do fator de reajuste (4.1.1). (cont.)
• Comunicação de Dados.
• Processamento Distribuído.
• Performance.
• Configuração Altamente Utilizada.
• Taxa de Transações.
• Entrada de Dados On-Line.
• Eficiência do Usuário Final.(...)
• Determinar valor do fator de reajuste (4.1.1). (cont.)
• Atualização On-line.
• Processamento Complexo.
• Reutilização.
• Facilidade de Instalação.
• Facilidade de Operação.
• Múltiplos Locais.
• Modificações Facilitadas.
• Determinar valor do fator de reajuste (4.1.1). (cont.)
• Estas características refletem funções que afetam a aplicação de
maneira geral e cada uma delas possui um nível de influência sobre a aplicação que pode variar em um intervalo discreto de 0 a 5.
• 0 – Nenhuma influência.
• 1 – Influência mínima.
• 2 – Influência moderada.
• 3 – Influência média.
• 4 – Influência significativa.
• 5 – Grande influência.
• Determinar valor do fator de reajuste (4.1.1). (cont.)
• Após determinados os níveis de influência, o fator de reajuste é calculado com a fórmula:
• VAF = (TDI X 0,01) + 0,65, onde TDI é Total Degree of Influence.
• Calcular o Tamanho Funcional / Cálculo dos Pontos de função ajustados [4.1.1]
• Cada tipo funcional (ALI, AIE, EE, SE e CE) possui uma complexidade (Baixa, Média ou Alta).
• Cada funcionalidade possui uma contribuição funcional para a contagem de PFs de acordo com a complexidade definida.
Tipo Funcional Complexidade
Baixa Média Alta
Arquivo Lógico Interno (ALI) 7 10 15
Arquivo de Interface Externa (AIE) 5 7 10
Entrada Externa (EE) 3 4 6
Saída Externa (SE) 4 5 7
Consulta Externa (CE) 3 4 6
• Calcular o Tamanho Funcional / Cálculo dos Pontos de função ajustados [4.1.1] (cont.)
• Dependendo do tipo de contagem definida, o cálculo do PF poderá ser apresentado de formas diferentes de acordo com as funcionalidades associadas à conversão de dados e que não devem ser associadas às cargas iniciais de dados que são
executadas apenas uma vez na implantação do sistema, pois esta não entra na contagem:
• PF-Desenvolvimento = PF-Incluído + PF-Conversão.
• PF-Incluído: associados às funcionalidades incluídas na aplicação por meio do projeto de desenvolvimento.
• PF-Conversão: associados às funcionalidades de conversão de dados dos projetos.
• Calcular o Tamanho Funcional / Cálculo dos Pontos de função ajustados [4.1.1] (cont.)
• PF-Melhoria = PF-Incluído + PF-Alterado + PF-Excluído + PF-Conversão.
• PF-Incluído: associados às funcionalidades incluídas na aplicação por meio do projeto de melhoria.
• PF-Alterado: associados às funcionalidades alteradas no projeto de melhoria.
• PF-Excluído: associados às funcionalidades existentes na aplicação que serão excluídas no projeto de melhoria.
• PF-Conversão: contagem de PF associada às funcionalidades de conversão de dados dos projetos.
• Calcular o Tamanho Funcional / Cálculo dos Pontos de função ajustados [4.1.1]
(cont.)
• PF-Melhoria = [(PF-Incluído + PF-Alterado + PF-Conversão) * VAFA] + [PF-Excluído
* VAFB]. [4.1.1]
• VAFA: Valor do fator de ajuste da aplicação depois do projeto de melhoria.
• VAFB: Valor do fator de ajuste de aplicação antes do projeto de melhoria.
• PF-Aplicação = PF-Incluído.
• PF-Incluído: associados às funcionalidades incluída na aplicação por meio do projeto de desenvolvimento.
• PF-Aplicação = PF-Incluído * VAF. [4.1.1]
• Documentar e Reportar a Contagem.
• Dever ser clara o suficiente para que um revisor ou auditor possa compreender a contagem apresentada e chegar aos mesmos
resultados, ele deverá ser rastreável para os requisitos funcionais analisados.
• Estimativas feitas com especialistas são inexatas e difíceis de serem realizadas quando temos projetos grandes.
• A utilização de APF nos traz melhor qualidade na especificação dos
requisitos, visto que esta se apresenta como base para o processo de PF e como tal deverão estar claras e em nível de detalhamento adequado.
Estimativas
• Deverá ser realizada na etapa de planejamento do projeto.
• As premissas e estimativas deverão ser documentadas e utilizadas no decorrer do acompanhamento do projeto.
• Estimativa: obtida por meio de uma atividade técnica. Não deve sofrer interferências.
• Meta: objetivo a ser alcançado de acordo com necessidades de negócio.
• Compromisso: acordo fechado entre a gerência e as equipe técnicas para alcance das metas.
