Gerência de Projetos e Manutenção de Software Aula 4...

52
Gerência de Projetos e Manutenção de Software Aula 4 – Planejamento de Projetos (Estimativas) Andréa Magalhães Magdaleno [email protected] 2017.02

Transcript of Gerência de Projetos e Manutenção de Software Aula 4...

Gerência de Projetos e Manutenção de Software

Aula 4 – Planejamento de Projetos (Estimativas)

Andréa Magalhães [email protected]

2017.02

2GPMS 2017.02

Agenda

• Aulas Anteriores

• Estimativas• Planning Poker• Paramétrica

• COCOMO

• Análise de Pontos de Função

• Exercícios

AULAS ANTERIORES

4GPMS 2017.02

Etapas do planejamento (Métodos Clássicos)

1. Especificar o

escopo

2. Detalhar o

escopo

3. Definir as

atividades

4. Definir a

sequência das

atividades

5. Estimar a

duração das

atividades

6. Definir o

cronograma

7. Estimar os

custos das

atividades

8. Definir o

orçamento

9. Integrar

planos

5GPMS 2017.02

Dever de Casa

• Prepararam a EAP do seu projeto?

ESTIMATIVAS

7GPMS 2017.02

Passo 5: estimar aduração das atividades• Cada atividade tem uma duração esperada

• Caso a atividade seja ainda muito grande, será complexo determinar a sua duração• Neste caso, decomponha a atividade

• Técnicas para estipular a duração da atividade:• Opinião de especialista• Estimativa por analogia (projeto anterior)• Planning Poker (Métodos Ágeis)• Estimativas paramétricas (fórmulas)• Combinação de alternativas: nem sempre todas estão

disponíveis!

PLANNING POKER

9GPMS 2017.02

Estimativa via Planning Poker

• Técnica que visa o comprometimento dos membros da equipe• Todos participam do processo de estimativa• Todos são responsáveis pela sua concretização

• Permite rapidamente chegar a uma estimativa

• Normalmente cativa os envolvidos por ter uma dimensão lúdica

• Baseada em consenso!

10GPMS 2017.02

Estimativa via Planning PokerArtefatos necessários

• Elementos a serem estimados• Histórias

• Casos de Uso

• Pacotes de trabalho

• Atividades

• Etc.Título: Pagamento em cartão de crédito

Descrição: O usuário será capaz de pagar a

compra em cartão de crédito VISA.

11GPMS 2017.02

Estimativa via Planning PokerArtefatos necessários

• Um deque, usualmente de 13 cartas, para cada membro da equipe• As cartas representam esforço (pontos, homens-dia,

homem-hora, etc.)• Ex.: 3 = 3 pessoas em 1 dia ou 1 pessoa em 3 dias

12GPMS 2017.02

Estimativa via Planning PokerProcesso1. Coloque o elemento a ser estimado no centro da mesa

2. Cada membro coloca a sua carta de estimativa na mesa, virada para baixo

• A estimativa não é só codificação, mas inclui também modelagem, testes, integração, etc.

• Nenhum membro deve argumentar a razão da sua escolha

3. As cartas são viradas para cima ao mesmo tempo• Raramente cartas iguais aparecem. Isso é normal!!!

4. Calcula-se a média das estimativas

13GPMS 2017.02

Estimativa via Planning PokerProcesso5. As estimativas são analisadas

• Os membros com estimativas distantes da média explicam seus raciocínios (eles podem ser os certos!!!)

• Se a média está muito alta, pode ser necessário decompor o elemento sendo estimado e estimar as partes

• Se as estimativas estiverem baseadas em hipóteses não fundamentadas, essas hipóteses devem ser discutidas com o usuário

6. O processo se repete até que o consenso seja obtido

14GPMS 2017.02

Exercício

• Estabeleça a duração das atividades do seu projeto utilizando a técnica de Planning Poker

ESTIMATIVA PARAMÉTRICA

16GPMS 2017.02

Estimativa paramétrica

• A partir da execução de diversos projetossemelhantes, é possível construir fórmulas viaregressão que representem esses projetos

• Essas fórmulas normalmente levam emconsideração o contexto para aumentar aprecisão• Linguagem de programação• Nível de qualidade• Domínio do problema• Etc.

17GPMS 2017.02

Estimativa paramétrica• Cada organização deve adaptar as fórmulas para a sua

situação específica!!!

• Não é necessária a decomposição das atividades do projeto para sua utilização

• Normalmente são utilizadas como complemento a outras técnicas, com intuito comparativo

• Alguns modelos paramétricos para estimativas:• COnstructive COst Model (COCOMO) • Análise de pontos de função (APF)• Pontos por caso de uso

18GPMS 2017.02

Estimativas e Medidas• Estimativas se baseiam em medidas de esforço

• Medidas de esforço se baseiam em medidas de tamanho• Medidas diretas são apuráveis diretamente do produto ou do

processo (como linhas de código, consumo de memória, ...)• Medidas indiretas são dependentes de avaliação subjetiva (ex.:

funcionalidade, eficiência, complexidade, ...)

• Medidas de tamanho são definidas com o objetivo de determinar o tamanho de um projeto de software, com o intuito de estimar seu custo e tempo de desenvolvimento• Medidas orientadas a tamanho (linhas de código � direta)• Medidas orientadas a funcionalidade (pontos por função �

indireta)

19GPMS 2017.02

Linhas de Código (KLOC)

• Vantagens• Medida direta, avaliada a partir do código• Possibilidade de automação do processo de

medição• Existência de dados históricos na literatura• Existência de modelos empíricos de custos

• Desvantagens• Dependência de linguagem de programação• Desconsidera programas mais curtos e inteligentes• Nível de detalhe difícil de estimar no início do projeto

20GPMS 2017.02

Linhas de Código - Contagem

• Identificar o número de linhas de código de um módulo não é simples• Depende do que é considerado como linha de código

• O objetivo geral é medir o tamanho do esforço intelectual que foi colocado na produção do programa

• Em geral, somente os comandos e declarações de um programa são contados como linhas de código (COCOMO II)

• Isto exclui as linhas em branco, os comentários e as diretivas de compilação

COCOMO

22GPMS 2017.02

Estimativa via COCOMO

• Modelo paramétrico criado por Berry Boehm no início da década de 1980

• O modelo é dividido em níveis de complexidade

• Fórmula básica:• Projetos simples: fácil entendimento e equipe pequena

• Projetos de complexidade media: experiência limitada da equipe

• Projetos complexos: software crítico, interagindo com hardware

• OBS: Esforço calculado em homem-mês!

05,14,2 KLOCEsforço ×=

12,10,3 KLOCEsforço ×=

20,16,3 KLOCEsforço ×=

23GPMS 2017.02

Estimativa via COCOMO

• Duração• Projetos simples: fácil entendimento e equipe pequena

• Projetos de complexidade media: experiência limitada da equipe

• Projetos complexos: software crítico, interagindo com hardware

• OBS: Duração calculada em meses

38,05,2 EsforçoDuração ×=

35,05,2 EsforçoDuração ×=

32,05,2 EsforçoDuração ×=

24GPMS 2017.02

Exercício

• Calcule o esforço e a duração dasatividades do seu projeto utilizando oCOCOMO

ANÁLISE DE PONTOS DE FUNÇÃO (APF)

26GPMS 2017.02

Mas como saber o número de LOC antes de ter o produto?• Análise de Pontos de Função (APF) visa contar a

quantidade de funcionalidades de um sistema• É independente da linguagem de programação• Útil para estimativas e normalização de outras métricas• Focaliza os requisitos do sistema em desenvolvimento• É uma medida do ponto de vista do usuário• Aplicável principalmente em sistemas de informação• Existência de um processo padronizado para contagem

• Existem constantes de transformação entre pontos de função e LOC

27GPMS 2017.02

Análise de Pontos de Função

• Técnica de medição de funcionalidades fornecidas por um software do ponto de vista de seus usuários

• Ponto de função (PF) : Unidade de medida da APF• Torna a medição independente da tecnologia usada para

a construção do software.• Usado como fator normalizador do tamanho do software

• A APF busca medir o que o software faz e não como ele foi construído• Portanto, não é preciso ser desenvolvedor de software

para utilizá-la.

28GPMS 2017.02

Análise de Pontos de FunçãoHistórico• Criada em 1977 por Allan

Albrecht. • Pesquisador da IBM

• APF surgiu como resultado de um estudo de produtividade para projetos de software desenvolvidos por uma unidade de serviços da IBM• Motivo: Nem todos os projetos

usavam a mesma linguagem de programação

29GPMS 2017.02

Pontos por Função – Processo de contagem• Cinco informações básicas são estimadas

• Número de arquivos internos• Número de arquivos de interfaces externas• Número de entradas externas• Número de saídas externas• Número de consultas externas

• Um fator de complexidade é associado a cada informação• Baixa• Média• Alta

• As informações são ponderadas e agregadas (somadas)• Resultado: número de pontos por função

Funções de Dados

Funções Transacionais

30GPMS 2017.02

Estimativa via APFConceitos

31GPMS 2017.02

Estimativa via APFAlgoritmo1. Contar as funções de dados do software

• Número de Arquivos Lógicos Internos (ALI): entidades únicas manipuladas pelo sistema

• Dados mantidos dentro do escopo da aplicação• As tabelas ou classes do sistema• Ex.: entidade pedido

• Número de Arquivos de Interface Externos (AIE): entidades compartilhadas por diferentes sistemas externos

• Dados referenciados pela aplicação, embora sejam mantidos por outra aplicação• Tabelas acessadas em um outro sistema• Ex.: estoque sendo compartilhado pelos sistemas de vendas e financeiro

• Para a identificação do ALI e AIE, o desenvolvedor deve construir um “modelo de dados” conceitual simplificado da aplicação

• Importante: O nome “arquivo” refere-se a grupos de dados logicamente correlatos e não à sua implementação física

32GPMS 2017.02

Estimativa via APFFunções de Dados – Exemplo

VôosDisponíveis

Sistema deregistrode vôos

Aviões

Sistema dereservas

Reservas

2 ALI

0 AIE

1 ALI

1 AIE

33GPMS 2017.02

Estimativa via APFAlgoritmo2. Determinar o nível de complexidade das funções de dados (ALI e AIE)

• TED (Tipos de Elemento de Dados) – Campo único, não repetitível ereconhecido pelo usuário

• TER (Tipos de Elemento de Registro) – Subgrupo de informaçõespode ser entendido como uma entidade fraca, ou seja, uma entidade

que só faz sentido quando associada a outra entidade da aplicação

TED

1 a 19 20 a 50 51 ou mais

TE

R

1 Baixa Baixa Média

2 a 5 Baixa Média Alta

6 ou mais Média Alta Alta

34GPMS 2017.02

Estimativa via APFAlgoritmo3. Atribuir peso para as contagens das funções de dados

Elemento\Complexidade Baixa Média Alta

Arquivos Lógicos Internos (ALI) X7 X10 X15

Arquivos de Interface Externos (AIE) X5 X7 X10

35GPMS 2017.02

Estimativa via APFAlgoritmo4. Contar as funções de transação

Representa a funcionalidade oferecida ao usuário para processar dados da aplicação

• Número de Entradas Externas (EE): conjunto de dados únicos que entram na fronteira do sistema – Ex.: tela de cadastro de produtos

• Número de Saídas Externas (SE): conjunto de dados únicos que saem da fronteira do sistema – Ex.: relatórios, mensagens

• Número de Consultas Externas (CE): combinação de entrada e saída onde a saída ocorre em função da entrada sem que haja um processamento nem alteração no conteúdo de arquivos internos–Ex: consulta ao cadastro de clientes

• Desenhar as telas em que ocorrerão os processos de entrada, saída e consultas ajuda a identificar seus campos e arquivos referenciados

36GPMS 2017.02

Estimativa via APFAlgoritmo5. Determinar o nível de complexidade das funções de transação

• TED (Tipos de Elemento de Dados)– Campo único, não repetitível e reconhecido pelo usuário

• TAR (Tipos de Arquivos Referenciados)– Quantidade de ALI e

AIE mantidos ou referenciados pela função de transação

37GPMS 2017.02

Estimativa via APFFunções de Transação– Exemplo• Exemplo de contagem: inclusão de editoras

Comando de disparo da transação (único)

2 TED

1 TED

1 TAREditorasTOTAL

1 TAR com 3 TED

38GPMS 2017.02

Estimativa via APFFunções de Transação– Exemplo• Exemplo de contagem: inclusão de livros

Comando de disparo da transação (único)

3 TED

TOTAL

3 TAR com 4 TED

3 TAREditoras Autores

Livros

1 TED

39GPMS 2017.02

Estimativa via APFAlgoritmo5. Determinar o nível de complexidade das funções de transação

• Para Número de Entradas Externas (EE)

• Para Número de Saídas Externas (SE) e Número de Consultas Externas (CE)

TED

1 a 4 5 a 15 16 ou mais

TAR

0 ou 1 Baixa Baixa Média

2 Baixa Média Alta

3 ou mais Média Alta Alta

TED

1 a 5 6 a 19 20 ou mais

TAR

0 ou 1 Baixa Baixa Média

2 a 3 Baixa Média Alta

4 ou mais Média Alta Alta

40GPMS 2017.02

Estimativa via APFAlgoritmo

6. Atribuir peso para as contagens das funções de transação

Elemento\Complexidade Baixa Média Alta

Entradas Externas (EE) X3 X4 X6

Saídas Externas (SE) X4 X5 X7

Consultas Externas (CE) X3 X4 X6

41GPMS 2017.02

Estimativa via APFAlgoritmo7. Obter Pontos de Função não Ajustados (PFNA)

∑ ×= PesoElementoPFNA

42GPMS 2017.02

Estimativa via APFAlgoritmo8. Ajustar os pontos de função

• Avalia restrições adicionais do negócio

• Características não funcionais interferem na complexidade do produto

• Ajustar os pontos de função não ajustados em ± 35%

• Responder a 14 questões• Menor nota: 0 (não importante ou não aplicável)

• Maior nota: 5 (absolutamente essencial)

• O IFPUG (International Function Point Users Group), órgão responsável pela técnica, tornou o fator de ajuste opcional

43GPMS 2017.02

Estimativa via APFQuestões de ajuste1. Necessita de backup?2. Necessita de mecanismos especializados de comunicação?3. Tem processamento distribuído?4. Precisa de alto desempenho?5. Terá grande número de usuários em paralelo?6. Precisará de entrada de dados on-line?7. No caso de entradas on-line, existirão múltiplas telas?8. A atualização das entidades será feita on-line?9. As entradas e saídas de dados serão complexas?10. O processamento interno será complexo?11. O código será projetado para ser reutilizado?12. Migração e instalação estarão incluídos?13. O sistema será instalado em diversas organizações?14. O projeto pretende facilitar mudanças e operação do usuário?

OBS: As versões mais recentes do manual de contagem deixaram de utilizar os

fatores de ajuste

44GPMS 2017.02

Estimativa via APFAlgoritmo9. Obter Pontos de Função Ajustados (PF)

∑×+×= )01,065,0( RespostaPFNAPF

45GPMS 2017.02

Estimativa via APFPF x LOC• Converter PFNA em LOC

� 1 PFNA é igual a...

Linguagem LOC

Assembly 320

C 128

C++ 55

COBOL 91

Linguagem LOC

FORTRAN 77 107

Java 53

PASCAL 91

PERL 27

Linguagem LOC

Prolog 64

Shell Script 107

Visual Basic 5 29

Visual C++ 34

46GPMS 2017.02

Estimativa via APFTamanhos de Produtos Conhecidos

47GPMS 2017.02

Estimativa via APFVariação de Produtividade em Função da Escala

48GPMS 2017.02

Estimativa via APFQual o valor/preço de 1 PF (R$/PF)?

• O valor R$/PF irá variar de acordo com as funcionalidades dosoftware, considerando:• A produtividade e experiência da equipe nas tecnologias e padrões

• O grau de qualidade solicitado pelo cliente

• A complexidade do software

• A quantidade de entregáveis (artefatos, documentos, modelos eetc.)

• As tecnologias disponíveis para desenvolvimento desistemas influenciam (+/-) diretamente na produtividade• Comum no mercado a diferenciação do valor do PF de acordo com

a plataforma tecnológica (mainframe, web, cliente-servidor) e alinguagem de programação (Cobol, Java, .Net e etc.)

49GPMS 2017.02

Exercício

• Calcule o número de PF do projeto

50GPMS 2017.02

Dúvidas?

51GPMS 2017.02

Próxima Aula

Gerência de

Configuração

Garantia de

Qualidade

Verificação,

Validação e Testes

Planejamento

de Projetos

Gerência

de Riscos

Monitoramento

e Controle

Reutilização

Medição e

Análise

Levantamento

de Requisitos

Análise de

RequisitosProjeto Codificação

Comunicação

Atividades

Gerenciais

Atividades de

Desenvolvimento

Atividades de

Apoio

Aquisição

Gerência de Projetos e Manutenção de Software

Aula 4 – Planejamento de Projetos (Estimativas)

Andréa Magalhães [email protected]

2017.02