Gerência de Projetos e Manutenção de Software Aula 4 Planejamento de Projetos (Estimativas) Andréa Magalhães Magdaleno 2017.

Transcrição

1 Gerência de Projetos e Manutenção de Software Aula 4 Planejamento de Projetos (Estimativas) Andréa Magalhães Magdaleno andrea@ic.uff.br

2 Agenda Aulas Anteriores Estimativas Planning Poker Paramétrica COCOMO Análise de Pontos de Função Exercícios 2

3 AULAS ANTERIORES

4 Etapas do planejamento (Métodos Clássicos) 1. Especificar o escopo 2. Detalhar o escopo 3. Definir as atividades 6. Definir o cronograma 5. Estimar a duração das atividades 4. Definir a sequência das atividades 7. Estimar os custos das atividades 8. Definir o orçamento 9. Integrar planos 4

5 Dever de Casa Prepararam a EAP do seu projeto? 5

6 ESTIMATIVAS

7 Passo 5: estimar a duraçã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! 7

8 PLANNING POKER

9 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! 9

10 Estimativa via Planning Poker Artefatos 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. 10

11 Estimativa via Planning Poker Artefatos 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 11

12 Estimativa via Planning Poker Processo 1. 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 12

13 Estimativa via Planning Poker Processo 5. 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 13

14 Exercício Estabeleça a duração das atividades do seu projeto utilizando a técnica de Planning Poker 14

15 ESTIMATIVA PARAMÉTRICA

16 Estimativa paramétrica A partir da execução de diversos projetos semelhantes, é possível construir fórmulas via regressão que representem esses projetos Essas fórmulas normalmente levam em consideração o contexto para aumentar a precisão Linguagem de programação Nível de qualidade Domínio do problema Etc. 16

17 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 17

18 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) 18

19 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 19

20 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 20

21 COCOMO

22 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 Esforço = 2,4 KLOC Projetos de complexidade media: experiência limitada da equipe Esforço = 3,0 KLOC Projetos complexos: software crítico, interagindo com hardware Esforço = 3,6 KLOC OBS: Esforço calculado em homem-mês! 1,05 1,12 1,20 22

23 Estimativa via COCOMO Duração Projetos simples: fácil entendimento e equipe pequena Duração = 2,5 Esforço Projetos de complexidade media: experiência limitada da equipe Duração = 2,5 Esforço Projetos complexos: software crítico, interagindo com hardware Duração = 2,5 Esforço OBS: Duração calculada em meses 0,38 0,35 0,32 23

24 Exercício Calcule o esforço e a duração das atividades do seu projeto utilizando o COCOMO 24

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

26 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 26

27 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. 27

28 Análise de Pontos de Função Histó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 28

29 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 Funções de Dados Funções Transacionais 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 29

30 Estimativa via APF Conceitos 30

31 Estimativa via APF Algoritmo 1. 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 31

32 Estimativa via APF Funções de Dados Exemplo Sistema de registro de vôos Vôos Disponíveis Sistema de reservas Aviões Reservas 2 ALI 0 AIE 1 ALI 1 AIE 32

33 Estimativa via APF Algoritmo 2. 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 e reconhecido pelo usuário TER (Tipos de Elemento de Registro) Subgrupo de informações pode ser entendido como uma entidade fraca, ou seja, uma entidade que só faz sentido quando associada a outra entidade da aplicação TED 1a a ou mais 1 Baixa Baixa Média TER 2 a 5 Baixa Média Alta 6 ou mais Média Alta Alta 33

34 Estimativa via APF Algoritmo 3. 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 34

35 Estimativa via APF Algoritmo 4. 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 35

36 Estimativa via APF Algoritmo 5. 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 36

37 Estimativa via APF Funções de Transação Exemplo Exemplo de contagem: inclusão de editoras 1 TED Comando de disparo da transação (único) 2 TED Editoras 1 TAR TOTAL 1 TAR com 3 TED 37

38 Estimativa via APF Funções de Transação Exemplo Exemplo de contagem: inclusão de livros 1 TED Comando de disparo da transação (único) 3 TED Editoras Autores 3 TAR TOTAL Livros 3 TAR com 4 TED 38

39 Estimativa via APF Algoritmo 5. Determinar o nível de complexidade das funções de transação Para Número de Entradas Externas (EE) TED 1a 4 5 a ou mais 0 ou 1 Baixa Baixa Média TAR 2 Baixa Média Alta 3 ou mais Média Alta Alta Para Número de Saídas Externas (SE) e Número de Consultas Externas (CE) TED 1a 5 6 a ou mais 0 ou 1 Baixa Baixa Média TAR 2 a 3 Baixa Média Alta 4 ou mais Média Alta Alta 39

40 Estimativa via APF Algoritmo 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 40

41 Estimativa via APF Algoritmo 7. Obter Pontos de Função não Ajustados (PFNA) PFNA = Elemento Peso 41

42 Estimativa via APF Algoritmo 8. 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 42

43 Estimativa via APF Questões de ajuste 1. 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 43

44 Estimativa via APF Algoritmo 9. Obter Pontos de Função Ajustados (PF) PF = PFNA ( 0,65 + 0,01 Resposta) 44

45 Estimativa via APF PF x LOC Converter PFNA em LOC 1 PFNA é igual a... Linguagem LOC Assembly 320 C 128 C++ 55 COBOL 91 Linguagem LOC FORTRAN Java 53 PASCAL 91 PERL 27 Linguagem LOC Prolog 64 Shell Script 107 Visual Basic 5 29 Visual C

46 Estimativa via APF Tamanhos de Produtos Conhecidos 46

47 Estimativa via APF Variação de Produtividade em Função da Escala 47

48 Estimativa via APF Qual o valor/preço de 1 PF (R$/PF)? O valor R$/PF irá variar de acordo com as funcionalidades do software, 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 e etc.) As tecnologias disponíveis para desenvolvimento de sistemas 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 a linguagem de programação (Cobol, Java,.Net e etc.) 48

49 Exercício Calcule o número de PF do projeto 49

50 Dúvidas? 50

51 Próxima Aula Atividades Gerenciais Aquisição Planejamento de Projetos Comunicação Monitoramento e Controle Gerência de Riscos Atividades de Desenvolvimento Levantamento de Requisitos Análise de Requisitos Projeto Codificação Atividades de Apoio Garantia de Qualidade Gerência de Configuração Medição e Análise Verificação, Validação e Testes Reutilização 51

52 Gerência de Projetos e Manutenção de Software Aula 4 Planejamento de Projetos (Estimativas) Andréa Magalhães Magdaleno andrea@ic.uff.br