UNIVERSIDADE ESTÁCIO DE SÁ PÓS – GRADUAÇÃO GRADUAÇÃO EM ENGENHARIA DE SOFTWARE 1° SEMESTRE – EAD EAD TURMA: 2017.3 DISCIPLINA: MÉTRICAS DE SOFTWARE PROFESSOR: LUIZ ROBERTO
BRUNO BEZERRA DE CARVALHO MATRICULA: 201707242232
VILA VELHA – ES ES 2017
RESUMO Com um cenário cada vez mais exigente e competitivo, empresas de software estão se desdobrando para produzirem produtos cada vez mais rápidos e complexos sem deixar de lado a qualidade e a satisfação do cliente. Para ser possível alcançar estes objetivos, a organização necessita possuir um forte controle ao longo do desenvolvimento, procurando evitar que determinados riscos atrapalhem o sucesso do projeto. Gerenciar riscos é uma atividade primordial para o sucesso do projeto. A falta de atenção devida à ocorrência dos riscos pode modificar o andamento do projeto e prejudicar a qualidade do produto e/ou serviço prestado pela empresa. Visando tornar mais eficiente o processo d e desenvolvi mento de software, auxiliando na identificação dos processos do projeto. O modelo de medição proposto neste trabalho possui um conjunto de atividades a grupadas em fases onde são descritos os passos necessários para sua realização assim como todos os insumos de entrada e artefatos gerados pelo modelo, auxiliando o gerente a possuir um maior controle do projeto e atender os clientes satisfatoriamente.
SUMARIO 1
INTRODUÇÃO .............................................................................................
4
2. MÉTRICAS DE SOFTWARE. ...........................................................................
4
2.1 O que são métricas de software? ........................................................................
4
2.2 Por que medir software? ...................................................................................
5
2.3 O que é tamanho funcional? .............................................................................. 5 2.4 O que são pontos d e f unção? ...........................................................................
5
3 EXEMPLO. .......................................................................................................
6
3.1 INICIANDO O PROCESSO PARA DEFINIÇÃO DOS OBJETIVOS E METAS .. 6 3.2 LISTANDO TODOS OS EVENTOS ESSENCIAIS ...........................................
7
3.3 DESCRIÇÃO INDIVIDUAL DOS EVENTOS .................................................. 7 3.4 AVALIANDO O TAMANHO DO SISTEMA .................................................... 9 3.5 TABELA DE COMPLEXIDADE DO PONTO FUNÇÃO (IFPUG) ..................... 9 3.6 SISTEMA MÉDIO .......................................................................................... 4 CONCLUSÃO .................................................................................................
9
10
1 INTRODUÇÃO
A métrica Pontos de Função (PF), definida por Allan Albrecht em 1979, tem sido utilizada de forma crescente pela indústria de software. O IFPUG (International Function Point Users Group), criado em 1986, é responsável pela atualização das regras de Contagem de Pontos de Função, descritas no CPM (Counting Practices Manual), que se encontra na versão 4.3, está baseada principalmente na Release 4.2.1, publicada em 2005 no IFPUG. O IFPUG também é responsável pelo exame de certificação de especialistas em contagem de Pontos de Função, denominada CFPS ( Certified Function Point Specialist ). A métrica Pontos de Função é uma medida de tamanho funcional de projetos de software, considerando as funcionalidades implementadas, sob o ponto d e vista do usuário. Tamanho funcional é definido como “tamanh o do software derivado pela quantificação dos requisitos funcionais do usuário” (Dekkers, 2003). Pontos por
função são a medida do tamanho das aplicações de computados e os projetos que os constroem. A contagem de Pontos de Função é independentemente da metodologia de desenvolvimento e da plataforma utilizadas no desenvolvimento da aplicação. Assim, recomenda a utilização da métrica por Pontos de Função nas estimativas de tamanho dos projetos de software. Também é utilizada a métrica para estimar os projetos dos clientes, onde se obtém excelentes resultados.
2. MÉTRICAS DE SOFTWARE. 2.1 O que são métricas de software? Uma métrica é a medição de um atributo (propriedades ou características) de uma determinada entidade (produto, processo ou recursos). Exemplos: Tamanho do produto de software (exemplo: número de linhas de código);
Número de pessoas necessárias para implementar um caso de uso;
Número de defeitos encontrados por fase de desenvolvimento.
Então podemos chegar a conclusão que métricas de software são: Esforço para realização de uma tarefa;
Tempo para a realização de uma tarefa;
Custo para a realização de uma tarefa;
Grau de satisfação do cliente.
2.2 Por que medir software? Para entender e aperfeiçoar o processor de desenvolvimento, melhorar a gerência de projetos e o relacionamento com os clientes, reduz ir frustrações e pressões de cronograma, gerenciar contratos de software, indicar a qualidade d e um produto de software, avaliar a produtividade do processo, avaliar os benefícios de novos métodos e ferramentas de engenharia de software, avaliar retorno de investimento, identificar as melhores práticas de desenvolvimento de software, embasar soli citações de novas ferramentas e treinamento e avaliar o impacto da variação de um ou mais atributos do produto ou do processo na qualidade e/ou produtividade.
2.3 O que é tamanho funcional? Tamanho funcional é uma medida de tamanho de software, baseada em um a avaliação padronizada dos requisitos lógicos dos usuários. Na indústria há atualmente várias maneiras para medir tamanho funcional, a mais antiga em uso são os pontos de função. Semelhante aos quadrados de uma casa, pontos de função são independentes dos métodos físicos, ferramentas o u linguagem de desenvolvimentos utilizados para construir o software. O processo de cálculo de pontos de função está contido no manual de práticas d e contagem do grupo internacional de usuários de pontos d e função (IFPUG). Diferentemente de linhas de código, pontos de fun ção não são dependentes da implementação física e linguagens utilizadas no desenvolvimento de software.
2.4 O que são pontos d e f unção? É uma técnica p ara a medição de projetos de desenvolvimento de software, visando a estabelecer uma medida de tamanho, em Pontos de Função(PF), considerando a funcionalidade implementada, sob o ponto de vista do usuário. A medida é
independente da linguagem de programação ou da tecnologia que será empregada na implementação.
3 EXEMPLO. VAMOS USAR ESTE ESTUDO DE CASO PARA SIMPLIFICAR NOSSO ENTEDIMENTO DO TÓPICO EXEMPLO DE CÁLCULO DE PONTOS DE FUNÇÃO (PF) DESCRIÇÃO O restaurante Xing Long deseja implantar um sistema para controlar DO suas atividades principais, desde a contratação de funcionários até o SISTEMA: controle de estoque, passando pelo atendimento ao cliente. O sistema funcionará da seguinte forma: Cada mesa estará equipada com um terminal ligado a um computador central, que fará o controle de todas as transações. Quando o cliente chegar, o garçom fará a "abertura" da mesa. A partir deste momento, o cliente pode fazer pedidos, chamar o garçom e pedir a conta. Cada pedido deverá ser validado pelo cozinheiro assim que o mesmo estiver pronto, caracterizando a baixa definitiva no estoque. A correção do pedido é feita pelo gerente, que também é responsável pelo encerramento da conta e por fazer requisições aos fornece dores. Quando o fornecedor entrega a requisição, o gerente informa a chegada de mercadoria ao sistema.
3.1 INICIANDO O PROCESSO PARA DEFINIÇÃO DOS OBJETIVOS E METAS OBJETIVOS: 1 2 3
Acelerar o atendimento; Evitar erros e acelerar a entrega de pedidos e emissão da conta; Estimular o consumo;
4 5
Diminuir o número de garçons por mesa; Facilitar o controle do estoque.
METAS: 1 2 3 4 5
Instalação de terminais nas mesas, que enviam o pedido diretamente para a cozinha; Passar a responsabilidade do pedido para o cliente, e a da conta para o sistema; Fazer propaganda dos pratos oferecidos pelo restaurante nos terminais; Diminuir o número de funções dos garçons; Integrar todas as funcionalidades do restaurante no mesmo sistema.
3.2 LISTANDO TODOS OS EVENTOS ESSENCIAIS ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Eventos Gerente cadastra fornecedor Gerente cadastra mesa Gerente cadastra produto Gerente cadastra prato Gerente cadastra funcionário Garçom faz a abertura da mesa Cliente faz pedido Cozinheiro valida pedido Cliente chama garçom Gerente faz correção do pedido Cliente pede nota Gerente encerra conta Sistema gera relatório final do dia Gerente faz requisição aos fornecedores Fornecedor entrega requisição e gerente informa ao sistema
Classificação Externo, não esperado Externo, não esperado Externo, não esperado Externo, não esperado Externo, não esperado Externo, não esperado Externo, esperado Externo, esperado Externo, esperado Externo, esperado Externo, esperado Externo, esperado Temporal, esperado Externo, não esperado Externo, esperado
3.3 DESCRIÇÃO INDIVIDUAL DOS EVENTOS ID 1
INICIADO R Gerente
TRANSPORTAD OR Gerente
2
Gerente
Gerente
3
Gerente
Gerente
4
Gerente
Gerente
ESTÍMULO Mudança nas mesas Mudança nos fornecedores Mudança nos produtos
RESPOST A Escreve em mesa Escreve em fornecedor Escreve em estoque
Mudança nos pratos
Escreve em cardápio
SAÍDA
5
Gerente
Gerente
Mudança nos funcionários
Escreve em funcionário s Abertura da mesa
6
Cliente
Garçom
Chegada de cliente
7
Cliente
Cliente
Pedido do cliente
Escreve em pedido e cardápio
8
Cozinheiro
Cozinheiro
Pedido pronto
Escreve em Eliminaçã estoque e o do pedido pedido do visor da cozinha
9
Cliente
Cliente
Chamada do cliente
10
Cliente
Gerente
Solicitação do cliente
11
Cliente
Cliente
Fim dos pedidos
12
Gerente
Gerente
Solicitação do cliente
Escreve em nota e mesa
Fechamen to da mesa
13
-
-
Fim do expediente
Escreve em relatório
Relatório
14
Gerente
Gerente
Limite crítico de estoque
Escreve em requisição
Identificaç ão da requisição
Exibição do cardápio Exibição do pedido no visor da cozinha e atualizaçã o dos terminais
Exibição da Chamada no visor da cozinha Escreve em pedido e cardápio
Exibição do pedido no visor da cozinha e atualizaçã o dos terminais Mensage m para o gerente
15
Fornecedor
Gerente
Chegada de requisição
Escreve em estoque requisição
3.4 AVALIANDO O TAMANHO DO SISTEMA ITEM 1 2 3 4 5 6 7 8 9 10 11 12 13 14
ENTRADAS 1 1 1 1 1 1 1 1 1 1 1 1 -
SAÍDAS 1 1 1 1 1
CONSULTAS -
ARQUIVOS 1 1 1 1 1 1 1 1
3.5 TABELA DE COMPLEXIDADE DO PONTO FUNÇÃO (IFPUG) São utilizados para determinar a complexidade de cada função, baixa, média ou alta, a seguinte tabela do IFPUG, sintetiza o número de pontos de função atribuídos a cada tipo de função. TIPO DE FUNÇÃO EE (ENTRADAS EXTERNAS) SE (SAÍDAS EXTERNAS) CE (CONSULTAS EXTERNAS) ALI (ARQUIVOS LÓGICOS INTERNOS
BAIXA 3 4 3 7
MEDIA 4 5 4 10
ALTA 6 7 6 15
AIE (ARQUIVOS DE INTERFACES EXTERNAS)
5
7
10
3.6 SISTEMA MÉDIO ITENS Entradas
Nº DE ITENS 13
MULTIPLICADORES X4
RESULTADO 52
Saida Consultas Arquivos Interface com outro sistema
Total
15 0 8 0
X5 X4 X10 X7
25 0 80 0
157
4 CONCLUSÃO Há muitos usos para pontos de função além de estimar o cronograma, esforço e custo. Muitos gerentes de projeto não acreditam que os pontos de função possuem qualquer utilidade. De certa forma, eles estão certos. Muitas organizações estão utilizando pontos de função e métricas de software para reportar tendências a nível organizacional. Muitas equipes de projeto enviam dados a um grupo central de métricas e nunca mais tornam a ver seus dados. Isto é análogo a enviar os dados a um buraco negro. Se os gerentes de projetos começarem a entender como os pontos de função podem ser utilizados para estimar casos de teste, calcular custos de manutenção e assim por diante, eles provavelmente investirão na contagem de pontos de função.
