FATTO CONSULTORIA E SISTEMAS

Transcrição

1 Estimativas de Software com o COSMIC Carlos Eduardo Vazquez 19/01/2015 FATTO CONSULTORIA E SISTEMAS 2016 FATTO Consultoria e Sistemas 1

2 ORIENTAÇÕES INICIAIS Dê preferência ao uso de uma conexão de banda larga O evento não fará uso do vídeo (webcam), somente slides e áudio Se necessário, ajuste o idioma da sala na barra de ferramentas superior O evento terá ~45 min. de apresentação e ~15 min. finais para perguntas Você pode mandar suas perguntas pelo chat ao longo da apresentação Para aqueles que possuem certificação PMP, o evento vale 1 PDU A apresentação será gravada e o vídeo publicado posteriormente no site e redes sociais: 2016 FATTO Consultoria e Sistemas 2

3 MISSÃO Apoiar nossos clientes a estabelecer modelos de negócios em que eles tenham o controle e trazer visibilidade do desempenho para a gestão de seus processos de software. DIRECIONAMENTO ESTRATÉGICO COM: Estimativas e Medição de Projetos de Software Implantação da Análise de Pontos de Função (IFPUG, NESMA, COSMIC) Auditoria de Medições de Projetos de Software Medidos com APF Benchmarking e Análises de produtividade Avaliação para Melhoria dos Processos de Software Engenharia de Requisitos Planejamento e avaliação do desempenho (Escopo, Esforço, custo, prazo, qualidade) Construção e Monitoramento de Contratos de Software baseados em Resultados Integração do Desenvolvimento Ágil com a Governança Corporativa de TI usando Métricas Funcionais 2016 FATTO Consultoria e Sistemas 3

4 FORMAÇÃO PROFISSIONAL APF: Fundamentos, Benefícios e Implantação 8 horas (EAD e presencial) Capacitação em APF: Medição e Estimativa de Software 16 horas (EAD e presencial) Workshop APF: Metodologia e Práticas de Medição 16 horas (Presencial) Preparação para o Exame CFPS 96 horas (EAD e presencial) Medição e Estimativa de Software com o Método COSMIC 16 horas (Presencial) Oficina de Contagem de Pontos de Função Sessões de 8 ~ 40 horas Preparação para o Exame de Certificação COSMIC Foundation Level 16 horas (EAD e presencial) Engenharia de Requisitos de Software 24 horas Oficina de Requisitos Sessões de 8 ~ 40 horas Estimativa de Projetos de Software com o COCOMOII 16 horas Introdução ao Gerenciamento de Projetos 16 horas Gestão de Riscos em Projetos 16 horas O livro mais vendido de APF no país foi escrito por nós Formou ~25% de especialistas certificados pelo IFPUG no Brasil Representante do Scope Project Sizing Software 2016 FATTO Consultoria e Sistemas 4

5 ! Estimativas de Software com o COSMIC 2016 FATTO Consultoria e Sistemas 5

6 Objetivos 1. Despertar no público a consciência sobre a problemática na elaboração de estimativas no desenvolvimento de software 2. Apresentar o conceito de unidade de produto e de como aplicá-lo na medição de software para o planejamento e monitoramento da produtividade em seu desenvolvimento 3. Apresentar o método do COSMIC para medição do tamanho funcional e o seu papel na geração de unidades de produto a partir dos requisitos funcionais

7 1. A problemática da estimativa Estimar pequenos elementos é fácil Programar uma Transação Testar uma transação Dificuldade Estimar a realização de uma atividade de 12 horas Pequeno! Impacto Quando se pede uma estimativa para entrega de um programa testado e que implementa uma transação comercial para um desenvolvedor, ele fornece uma estimativa de 12 horas O mais provável é que ele esteja correto, porque se trata de uma peça cujo nível de incerteza é muito pequeno Ainda que erre em 100%, isso representará um erro de 12 horas; montante de impacto marginal comparado ao projeto como um todo

8 1. A problemática da estimativa Um grande elemento como a soma de suas partes memores Dificuldade Fase 01 Fase 02 Fase 03 Fase 04 Grande! Impacto Portanto, a solução para todos os problemas de estimativa é decompor um projeto em suas partes constituintes e estimar o esforço a ser investido em cada uma delas Estimar a entrega de um produto final ao longo de dois anos Com isso, os casos em que a estimativa é mais difícil e cujo erro em sua realização tem impactos negativos significativos para o negócio não serão mais um problema

9 1. A problemática da estimativa escopo preliminar necessidades de negócio A falha nessa lógica processo da engenharia de requisitos evolução no desenvolvimento decisões e acordos sobre a solução????? Não se consegue saber quais são essas atividades de 12 horas quando em estágios iniciais do desenvolvimento Não se sabe de início quais são todos os programas Há trabalho que não é uma função dessa quantidade de programas O nível de informação disponível não permite usar a lógica da estimativa da baixo para cima como solução para os desafíos da estimativa

10 1. A problemática da estimativa #NoEstimates Por que estimar se ao final do trabalho já se tem certeza da informação de interesse Afinal, são apenas entre 15 ou 30 días em um ambiente onde se usam abordagens ágeis de desenvolvimento O mesmo não se pode dizer em decisões sobre quais mudanças devem ser priorizadas dentre os 20% das demandas que consomem os 80% dos recursos. Poderia se esperar por esse momento para saber em vez de acreditar?

11 1. A problemática da estimativa QUANTIDADE (#) ESFORÇO(HH) > HH < 18% HH 82% < HH 39% > HH 61% Decisões executivas de investimentos que devem ser justificadas para quem mantém o governo daquela organização Como fazer isso com #NoEstimates?

12 2. Unidade de produto na prod, de software Uma unidade de produto na construção cívil Orçamento disponível Casa em estilo Santa Fé de Cadu 1 m 1 m Custo unitário médio de construção por m 2 Conclusão de uma estimativa da área compatível com o orçamento disponível permite tomar várias decisões Não se pode usar essa informação em um nível de detalhe de cada cômodo, é muito mais caro (proporcionalmente) construir um banheiro que um quarto Quando chega-se ao ponto de necessitar estimar o custo especificamente com os banheiros, já se tem elementos para realizar estimativas de baixo para acima O importante é que no total os custos não variem em muito da estimativa inicial

13 2. Unidade de produto na prod, de software Produtividade Casa Construída 300 m2 Arquiteto Engenheiros Mestre de obras Pedreiros Ajudantes Impostos e taxas Aprovações e registros Materiais diversos Apropriação Indireta de custos Apropriação direta de custos 1 m US$ 500,00 / m2 1 m Produto Desembolsos com os investimentos US$ ,00 Custo

14 2. Unidade de produto na prod, de software Unidade de Producto?? Qual seria a métrica que cumpre o papel de unidade de produto para o planejamento e monitoramento do desempenho na indústria de software tal qual no exemplo da construção civil? Permitir aproximar ou medir o tamanho do software a partir de seus requisitos Apoiar na estimativa de esforço do projeto ou na quantificação do desempenho a partir da perspectiva do usuário ou dono para fins de análise de produtividade Ser independente de desenvolvimento técnico e decisões de implementação Permitir comparar a produtividade entre as diferentes técnicas e tecnologias disponíveis

15 2. Unidade de produto na prod, de software Outras métricas que permitam quantificar o desempenho técnico de produtos e serviços a partir de como são implementados Análise da eficiência do projeto Melhora no desempenho do projeto Apoio à engenharia de requisitos Dimensão do projeto e qualidade Apoio à verificação e validação

16 Implementação Ambiente 2. Unidade de produto na prod, de software Tipos de requerimientos Qualquer outro tipo de requisito ou de restrição de ordem geral para o produto Interoperabilidade Privacidade Não são Requisitos Funcionais Proteção contra danos Intencionais Acidentais Equipamento alvo Aderência a padrões Locais para operação Requisitos Funcionais Requisitos que estão específicamente associados a uma tarefa ou serviço do usuario e descreve o que o software deve fazer independentemente de como o faz Tecnologias de desenvolvimento, manutenção, suporte e execução Ferramenta de programação e teste, OS, DBMS, UI, etc. Desempenho Compatibilidade Usabilidade Confiabilidade Segurança Manutenção Portabilidade Qualidade Organização Manipulação e Movimentação de dados Transferência Transformação Armazenamento Recuperação

17 2. Unidade de produto na prod, de software Onde vivem os requisitos funcionais? artefatos com definição de requisitos artefatos com decomposição funcional dos requisitos Requisitos Funcionais do Usuário ( RFU ) nos artefatos do software a ser medido artefatos da modelagem /análise de dados préimplementação pósimplementação programas físicos procedimentos e manuais operacionais do software artefatos de armazenamento físico de dados 2016 FATTO Consultoria e Sistemas

18 2. Unidade de produto na prod, de software A relação entre os requisitos funcionáis e não funcionáis ao longo do desenvolvimento 1ª Versão dos Requisitos Versão Posterior dos Requisitos Artefatos de Software Requisitos Funcionais do Usuário Requisitos não Funcionais Requisitos Funcionais do Usuário Verdadeiros R FN Pode ser medido pelo COSMIC Deveria ser registrado, pode ser quantificável Evolução da Linha de Tempo do Projeto

19 2. Unidade de produto na prod, de software A relação entre os requisitos funcionais e não funcionais ao longo do desenvolvimento Inicialmente, RNF O tempo de resposta médio em horários de pico não deve exceder X segs. A disponibilidade deve aumentar Y% em relação à média anual passada RFU a ser desenvolvido ou adquirido Fornecer dados externos em tempo real Monitorar e reportar tempo de médio de resposta Habilitar troca rápida de processamento para um processador alternativo sem interrupção do serviço RNF após requisitos iniciais evoluírem em RFU Equipamento apropriado Parte do software escrito em linguagem de baixo nível Processador alternativo operando em hot stand by

20 2. Unidade de produto na prod, de software Derivação de unidades de produto dos requisitos funcionais ISO/IEC define os princípios da medição do tamanho funcional Implementados em métodos de medição do tamanho funcional por COSMIC (ISO/IEC 19761:2011) IFPUG APF (ISO/IEC 20926:2009) UKSMA Mk II (ISO/IEC 20968:2002) NESMA APF (ISO/IEC 24570:2005) FiSMA (ISO/IEC 29881:2010)

21 3. Medição do tamanho funcional COSMIC Nível de confiabilidade compatíveis por todos os tipos de software Está no domínio público e sem custos Tem reconhecimento total do ISO/IEC Projeto é simples Base conceitual compatíveis com a moderna engenharia de software Métodos de 1ª geração nem sempre tem força suficiente para atender as necessidades do mercado, ou funcionam apenas em domínios muito restritos Estimativas e medição do desempenho com maior acuidade Habilidade de capturar tamanho a partir de múltiplas perspectivas

22 3. Medição do tamanho funcional COSMIC Visão geral do método de medição É um valor de uma magnitude de acordo com o método COSMIC 1 objetivos 2 Requisitos funcionais do usuario nos artefatos de software a ser medido Idependente da implementação relacionada com os artefatos do software a ser medido Expresso em unidades: Pontos de Função COSMIC ou PFC Conjunto de: Modelos Principios Regras Procesos 4 3 tamanho funcional do pedaço de software Descreve o que o software deve fazer para os usuarios, que são os destinatários e emissores dos dados Exclui requisitos técnicos ou de qualidade que expressam como o software funciona A função é relativa ao proceso de informação que o software deve executar para seus usuários

23 3. Medição do tamanho funcional COSMIC As fases da medição COSMIC 1 Objetivos 6 estratégia de medição Definição de cada pedação de software a ser medido da medição exigida Requisitos Funcionais do Usuário em artefatos do software a ser medido 5 Modelo de contexto de software 9 fase de mapeamento Requisitos Funcionais do Usuário na forma do modelo geral de software 10 8 Modelo geral de software fase de medição 11 4 Tamanho funcional do software em unidades de PFC

24 3. Medição do tamanho funcional COSMIC Usuario funcional usuário funciona l humano aplicação sendo medida aplicação par usuário funcional da aplicação sendo medida Usuários funcionais de um pedaço de software a ser medido identificados a partir de seus RFU, como fontes e/ou destinos pretendidos para dados Na visão lógica para um pedaço de software de aplicações de negócio, os RFU costumam descrever só a funcionalidade requerida do ponto de vista de usuários humanos e, talvez, outras aplicações pares que enviem ou recebam dados Quaisquer camadas de software e dispositivos de hardware que suportem a interação dos usuários funcionais com a aplicação são facilitadores da trocas de dados e não remetentes ou destinatários

25 3. Medição do tamanho funcional COSMIC Fronteira fronteira aplicação sendo medida aplicação par fronteira Fronteira definida como interface conceitual entre software e usuário funcional Fronteira não deve ser confundida com qualquer linha desenhada em um diagrama para delimitar o escopo de um pedaço de software ou camada Fronteira permite fazer distinção clara entre qualquer coisa parte do pedaço de software medido (dentro) e qualquer coisa parte do ambiente dos usuários funcionais (fora)

26 camada de aplicação 3. Medição do tamanho funcional COSMIC Movimientos de dados entradas saídas gravações armazenamento persistente aplicação sendo medida exits entries leituras entries exits aplicação par movimentos de dados Usuários funcionais interagem com o software através da fronteira via dois tipos de movimentos de dados (entries e exits) software também troca dados com o dispositivo de armazenamento persistente via dois tipos de movimentos de dados (reads e writes) O dispositivo de armazenamento não é considerado como um usuário do software e portanto está dentro da fronteira do software

27 3. Medição do tamanho funcional COSMIC Exemplo de Movimentos de dados usuário funcional processo funcional objetos de interesse cliente produto pedido itens de pedido pedido item do pedido confirmação de pedido pedido cliente item do pedido produto

28 3. Medição do tamanho funcional COSMIC Medição versus Aproximação do Tamanho 1 PFC G1 = 1,5 PFC G2 ± 25% 1 PFC G2 = 1,33 PFC G3 ± 15% editar e gerenciar pedidos de férias 100 PFC G1 Estimar/Aproximar incluir, alterar, excluir, apreciar PFC G2 especificação completa 200 PFC G3 Medir proposta requisitos projeto construção implementação 1. Avaliar o desempenho pela relação entre a quantidade de horas investidas e a quantdade de pontos de função COSMIC medidos 2. Reavaliar os indicadores de produtividade para que pasem a incluir o desempenho do projeto que acaba de terminar 3. Reavaliar a quantidade de pontos de função COSMIC que correspondem à média dos procesos ou conceitos de negócio 2016 FATTO Consultoria e Sistemas

29 3. Medição do tamanho funcional COSMIC Benchmarking Esforço estimado 1000 HH Aproximação do Tamanho 150 CFP 07 HH/CFP ou menos de 8% de chance 2016 FATTO Consultoria e Sistemas

30 3. Medição do tamanho funcional COSMIC Conhece a si mesmo 2016 FATTO Consultoria e Sistemas

31 Conclusão Existe uma grande diferença entre as respostas para a seguinte pergunta "Por que se solicitam HH para o projeto e não HH?" Há duas respostas: - Porque eu sei - Porque há apenas 2% de probabilidade de entregar um projeto deste tamanho com HH de acordo com os dados históricos. além disso, não há um único projeto da base de dados internacional de avaliação comparativa que dê suporte a essa estimativa

32 PESQUISA! 2016 FATTO Consultoria e Sistemas 32

33 PRÓXIMOS EVENTOS PRÓXIMAS TURMAS: PRÓXIMOS WEBNARS: Gestão de Riscos: como lidar com as incertezas do Projeto? terça-feira, 16 de fevereiro : FATTO Consultoria e Sistemas 33

34 PERGUNTAS? Obrigado pela sua atenção! Carlos Eduardo Vazquez Skype: cvazquezbr Brasília: (61) São Paulo: (11) Vitória: (27) Rio de Janeiro: (21) Belo Horizonte: (31) FATTO Consultoria e Sistemas 34

35 FATTO Consultoria e Sistemas Medição, Estimativas e Requisitos de Software Estimativas de Software com o COSMIC Carlos Eduardo Vazquez 1 Resumo Realizar uma estimativa de baixo para acima é inviável quando não está disponível a estrutura de projeto e estimar apenas com base em uma analogia é subjetivo demais para os objetivos de negócio atuais. Além disso, não se pode aprender com os erros passados. O objetivo deste artigo é apresentar o método de medição do tamanho funcional do COSMIC e apresentar uma proposta para derivar unidades de produto a partir dos requisitos funcionais do usuário em diferentes representações. Keywords COSMIC; Software Measurement; Function Points; ISO/IEC ; ISO/IEC ; Software Benchmarking; ISBSG; Performance Evaluation; NoEstimates 1 FATTO Consultoria e Sistemas, carlos.vazquez@fattocs.com Conteúdo 1 A problemática da estimativa Estimar pequenos elementos é fácil Um grande elemento como a soma de suas partes memores A falha nessa lógica O dilema das estimativas 1.2 #NoEstimates Unidade de produto para o software A unidade de produto na construção civil Productividade Unidade de Produto 2.2 Tipos de requisitos Onde vivem os requisitos funcionais? A relação entre os requisitos funcionais e não funcionais ao longo do desenvolvimento 2.3 A unidade de produto dos requisitos funcionais O método de medição do tamanho funcional do COSMIC Visão geral do método de medição Objetivo de la medición Requisitos funcionais A medição O resultado da medição 3.2 O processo de medição Medição Vs Aproximação do tamanho Estimativas como uma probabilidade As estimativas e os dados de benckmarking Conhece-te a ti mesmo Conclusão 7 5 Referencias Bibliográficas 7 1. A problemática da estimativa 1.1 Estimar pequenos elementos é fácil Quando se pede uma estimativa para a entrega de um programa testado e que implementa uma transação comercial para um desenvolvedor, ele fornece uma estimativa de 12 horas. O mais provável é que ele esteja correto, porque se trata de uma peça cujo nível de incerteza é muito pequeno. Ainda que erre nessa estimativa em 100%, isso representará um erro de 12 horas; montante de impacto marginal comparado ao projeto como um todo (Figura 1). Figura 1. Estimar a realização de uma atividade de 12 horas Um grande elemento como a soma de suas partes memores Portanto, a solução para todos os problemas de estimativa é decompor um projeto em suas partes constituintes e estimar o esforço a ser investido em cada uma delas. Com isso, os casos em que a estimativa é mais difícil e cujo erro em sua realização tem impactos negativos significativos para o negócio não serão mais um problema (Figura 2) A falha nessa lógica A falha nesta lógica é que na concepção de um produto não se conhecem todos os programas e algumas atividades não tem o esforço em sua realização como uma função da quantidade de programas como, por exemplo, a Engenharia de Requisitos e o projeto de arquitetura. Os produtos dessas atividades são os insumos para a programação e os testes de unidade usados no exemplo apresentado. Em outras

36 Estimativas de Software com o COSMIC 2/7 Figura 2. Estimar a entrega de um produto final ao longo de dois anos. palavras, o nível de informação disponível não permite usar a lógica de estimativa de baixo para cima como solução para os desafios da estimativa (Figura 3). Figura 4. Cauda longa: Maior concentração em projetos pequenos. e a melhoria de vários sistemas existentes. Pode-se dizer o mesmo de iniciativas que implicam em uma avaliação preliminar de custo-benefício para apoiar decisões executivas sobre investimentos que devem ser justificados para os responsáveis pela governança corporativa? Estimativas nesses momentos iniciais também facilita que as equipes sejam autoadministradas e que o seu desempenho seja planejado e monitorado de acordo com as exigências de transparência e eficiência da governança corporativa do mundo atual (Figura 5). Figura 3. Não se podem identificar quais são essas atividades de 12 horas durante as fases iniciais do desenvolvimento O dilema das estimativas Nesses casos, o dilema associado com a geração de estimativas se faz mais evidente. Enquanto em atividades menores a complexidade de estimar é baixa e a falha em sua realização tem impactos negativos pouco relevantes, nos projetos maiores existe uma dificuldade inerente para realizar estimativas com a precisão necessária. 1.2 #NoEstimates Por que estimar se ao final do trabalho já se tem certeza da informação de interesse? Afinal, são apenas entre 15 ou 30 dias em um ambiente onde se usam abordagens ágeis de desenvolvimento. Pode-se esperar por esse momento para saber ao invés de acreditar (Figura 4). Pode-se dizer o mesmo das decisões sobre as iniciativas que devem ser priorizadas nos 20% das demandas que consomem os 80% dos recursos? Estimar fornece insumo que viabiliza a gestão de mudanças organizacionais que envolvem orquestrar o desenvolvimento de novos sistemas Figura 5. Poucos são os projetos; mas, muito é neles investido. 2. Unidade de produto para o software 2.1 A unidade de produto na construção civil Alguns argumentarão que o processo de software é único e que está além de qualquer medição. Contudo, existem similaridades deste último com a construção civil em escala industrial. Cada edifício é único apesar de compartilhar elementos arquitetônicos comuns em maior ou menor grau. O processo de entrega de um imóvel inclui desde a concepção de um projeto arquitetônico, passa por vários projetos de engenharia, a construção e testes observando esses projetos, até a aceitação final por parte do proprietário e a garantia por um período de transição. Quando se constrói um edifício, é necessário ter um orçamento disponível para a sua construção e definir parâmetros para estabelecer os requisitos quanto ao seu projeto arquitetônico. Uma informação chave neste momento é o valor do custo unitário médio da construção por metro quadrado (Figura 6). Com essa informação pode-se chegar a conclusão de uma estimativa da área compatível com o orçamento disponível e, c FATTO Consultoria e Sistemas - Proibida a reprodução total ou parcial sem a permissão dos autores por escrito.

37 Estimativas de Software com o COSMIC 3/7 Figura 7. Apropriação directa e indireta de custos. do desempenho na indústria de software tal qual no exemplo da construção civil? Figura 6. Custo unitário médio da construção por m 2. a partir disso, há a oportunidade de tomar várias decisões. Obviamente, não se pode usar essa informação em um nível de detalhe de cada cômodo individualmente. Afinal, é muito mais caro (proporcionalmente) construir um banheiro que um quarto. O banheiro possui custo maior com mão de obra e materiais como a instalação hidrosanitária, por exemplo. Mas, como comentado antes, quando chega-se ao ponto de necessitar estimar o custo especificamente com os banheiros, já se tem elementos para realizar estimativas de baixo para acima... O importante é que no total a soma dessas estimativas, ou mesmo neste ponto da evolução da obra desembolsos já realizados, não ultrapassassem em muito a estimativa inicial baseada na quantidade de metros quadrados e na produtividade média Productividade Neste ponto surge um importante conceito: O de produtividade. Produtividade pode ser definida como a razão entre a quantidade de bens ou serviços produzidos e as unidades de tempo ou custo investidos para a sua entrega. No caso de minha casa e em função dos meus objetivos citados, escolhi como representação de produto a quantidade de metros quadrados construídos e o investimento em dinheiro como representação dos custos. O planejamento da produtividade na construção - que nem planta ainda tinha - foi realizado em termos de reais por metro quadrado. Nessa quantidade de R$/M2 estavam incluídas as despesas sobre como pagar ao arquiteto, aos engenheiros, ao mestre de obras, aos pedreiros, aos ajudantes; quanto pagar em impostos e taxas, aprovações e registros; quanto pagar por materiais diversos. Todos esses custos passaram a ser avaliados por meio de uma apropriação indireta de custos (Figura 7) Unidade de Produto A unidade de produto que cumpre o papel de fator de custo primário é a área construída expressa na unidade metros quadrados. Qual seria a métrica que cumpre o papel de unidade de produto para o planejamento e monitoramento Alguns requisitos podem ser identificados para tal unidade de produto: Permitir aproximar ou medir o tamanho do software a partir de seus requisitos; Apoiar na estimativa de esforço do projeto ou na quantificação do desempenho a partir da perspectiva do usuário ou dono para fins de análise de produtividade; Ser independente de desenvolvimento técnico e decisões de implementação; Permitir comparar a produtividade entre as diferentes técnicas e tecnologias disponíveis. Observe que esse tipo de unidade não elimina a necessidade de outras métricas que permitam quantificar o desempenho técnico de produtos e serviços a partir de como são implementados como, por exemplo: Análise da eficiência do design; Aperfeiçoamento do desempenho do design; Apoio à engenharia de requisitos; Apoio à verificação e validação. Um exemplo de métricas como essas é parte da família ISO/IEC ou Software product Quality Requirements and Evaluation (SQuaRE). 2.2 Tipos de requisitos Considerando as características desejadas para essa unidade de produto para a produção de software, deve-se considerar como objeto de medição os requisitos funcionais do usuário, porque esses são requisitos especificamente associados a uma tarefa ou serviço do usuário e que descrevem o que o software deve fazer independentemente de como ele o fará; coisa que ainda não se sabe quando deseja-se estimar no nível tático e estratégico como discutido aqui. São requisitos que descrevem a manipulação e a movimentação de dados por meio da transferência, transformação, armazenamento e recuperação de dados. Como comentado, esses não são os únicos requisitos para o software. Há os requisitos não funcionais que abordam quaisquer outros tipos de requisito ou de restrição de ordem geral para o produto. São restrições quanto: c FATTO Consultoria e Sistemas - Proibida a reprodução total ou parcial sem a permissão dos autores por escrito.

38 Estimativas de Software com o COSMIC 4/7 Ao ambiente como a interoperabilidade, privacidade e a proteção contra danos a incidentais ou acidentais; Restrições quanto à organização como os equipamentos alvo, a aderência à padrões e locais para operação; Restrições quanto à implementação como as tecnologias de desenvolvimento, manutenção, suporte e execução como, por exemplo, a ferramenta de programação e testes, sistemas operacionais, sistemas gerenciadores de banco de dados, sistema de gerenciamento da interface gráfica com o usuário, etc. Requisitos de qualidade ou nível de serviço como questões relacionadas ao desempenho, compatibilidade, usabilidade, confiabilidade, segurança, facilidade de manutenção e portabilidade Onde vivem os requisitos funcionais? Os requisitos funcionais do usuário encontram-se tanto em artefatos gerados antes da implementação do software como após a sua implementação. No primeiro caso são elementos como especificações de requisitos, modelos de dados, ou estruturas que organizam os requisitos em uma estrutura de decomposição funcinal. No segundo, são programas físicos, procedimentos e manuais operacionais do software e artefatos de armazenamento físico dos dados (Figura 8). Figura 9. A evolução dos requisitos. de uma residência unifamiliar e um padrão normal (não se tratava de uma casa popular, nem de uma casa de luxo). Alguns exemplos dessa evolução: O tempo de resposta médio em horários de pico não deve exceder 10 segundos. Este requisito não funcional evoluiu para o desenvolvimento de software com o objetivo de fornecer dados externos em tempo real e para o monitoramento e reporte do tempo médio de resposta; enquanto, mantiveram-se como requisitos não funcionais a utilização de um equipamento apropriado e a sua programação em uma linguagem de baixo nível. A disponibilidade do software deve aumentar em 5% em relação à média anual passada. Este requisito não funcional evoluiu para o desenvolvimento de software para uma troca rápida de processamento para um processador alternativo sem interrupção no serviço; enquanto, manteve-se como um requisito não funcional haver um processador alternativo operando em hot stand by. Então para fins de medição - e estimativa - deve ser possível adotar uma unidade de produto que permita essa flexibilidade conforme os propósitos da medição. Figura 8. Fontes de informação sobre os requisitos A relação entre os requisitos funcionais e não funcionais ao longo do desenvolvimento Os requisitos não funcionais na perspectiva de um usuário podem ser tratados como requisitos funcionais na perspectiva de outro. Muitos produtos de software que fornecem serviços compartilhados existem com o objetivo de atender requisitos não funcionais de outros produtos de software; seus usuários. Por exemplo, serviços de controle de acesso fornecidos por um sistema de single sign on que fornece funcionalidades de autenticação e autorização compartilhados por todas as aplicações de negócio em uma organização. Ou seja, conforme se avança no desenvolvimento deve ser possível medir usando uma métrica unificada aqueles requisitos originalmente abordando requisitos não funcionais que evoluíram para requisitos funcionais em uma outra perspectiva (Figura 9). Deve-se destacar que haverá sempre requisitos verdadeiramente não funcionais e que devem ser registrados por influenciar uma maior ou menor produtividade. Por exemplo, na avaliação de minha casa tive de considerar tratar-se 2.3 A unidade de produto dos requisitos funcionais Contar os requisitos funcionais parece ser uma boa alternativa para representar as unidades de produto do software; contudo, nem todos os requisitos são iguais e corre-se com isso o risco de misturar em uma mesma conta bananas e laranjas. Para isso a ISO/IEC definiram um padrão para esse tipo de medição, denominado Medição do Tamanho Funcional, e cujo método mais moderno que o observa é o do Consórcio Internacional de Medição de Software em Geral ou COSMIC. 3. O método de medição do tamanho funcional do COSMIC O método de medição do COSMIC é uma segunda geração de métodos de medição do tamanho funcional. Ele oferece nível de confiabilidade compatíveis por todos os tipos de software. Está no domínio público e o acesso à sua documentação não tem custos. O método tem reconhecimento total do ISO/IEC. O seu projeto é simples e possui uma base conceitual compatível com a moderna engenharia de software. Métodos anteriores nem sempre tem a aplicabilidade ampla o suficiente para atender as necessidades do mercado, ou c FATTO Consultoria e Sistemas - Proibida a reprodução total ou parcial sem a permissão dos autores por escrito.

39 Estimativas de Software com o COSMIC 5/7 funcionam apenas em domínios restritos. O planejamento e medição do desempenho tem maior acuidade e, por fim, o método tem a habilidade de capturar tamanho a partir de múltiplas perspectivas. por objetivo consolidar os movimentos identificados considerando o equivalente a um ponto de função COSMIC para cada movimento de dados identificado. 3.1 Visão geral do método de medição Figura 11. O processo de medição COSMIC. Figura 10. Visão geral do método do COSMIC Objetivo de la medición Toda medição depende dos objetivos que a motivaram. Medir a área em de uma construção em metros quadrados por exemplo, a medição é feita de uma forma se o objetivo for assentar o piso e de outra forma se o objetivo é calcular quanta ferragem será necessária para confecção da laje de concreto. Por isso o primeiro insumo na medição do tamanho funcional usando o método do COSMIC é o objetivo daquela medição Requisitos funcionais O objeto da medição são os requisitos funcionais. Quando se discute função, então deve-se considerar função para quem. Portanto, os requisitos funcionais descrevem o que o software deve fazer para seus usuários. Eles são os destinatários e remetentes de dados para o software sendo medido. A medição exige que se estabeleça uma fronteira conceitual entre o software e o usuário (Figura 12). A fronteira não deve ser confundida com qualquer linha desenhada em um diagrama para delimitar o escopo de uma parte do software ou camada. A fronteira permite realizar a distinção clara entre qualquer parte do software medido (dentro) e qualquer parte do ambiente dos usuários (fora). Figura 12. Fronteiras. Os usuários interagem com o software por através da fronteira por meio de movimentos de dados de entrada (E) e saída(x). O software também troca dados com dispositivos de armazenamento por meio de movimentos de dados de leitura (R) e gravação (W). O dispositivo de armazenamento não é considerado como um usuário do software e, portanto, está dentro da fronteira do software (Figura 13) A medição O método de medição consiste em um conjunto de modelos, princípios, regras e procedimentos que se aplicam aos dois insumos mencionados anteriormente. Isso, com o propósito de gerar o valor de uma magnitude para a funcionalidade entregue pelo software expresso em pontos de função COS- MIC O resultado da medição O resultado da medição é um valor de uma quantidade de funcionalidade entregue pelo software em pontos de função COSMIC. 3.2 O processo de medição A medição é muito simples (Figura 11). Na fase de estratégia de medição, se descreve o contexto no qual o software é considerado de acordo com o objetivo da medição. Além disso, delimita o software a ser medido e o usuário externo, que não necessariamente é uma pessoa. A fase seguinte, o mapeamento da medição, identifica os processos naquele contexto. Em cada processo, são identificados movimentos de dados. Finalmente, a fase de medição tem Figura 13. Movimentos de dados. Cada movimento de dados contribui com o equivalente a um ponto de função COSMIC (Figura 14). 3.3 Medição Vs Aproximação do tamanho Neste ponto, surge uma pergunta: Se o interesse é estimar quando ainda não se conhecem os detalhes da solução, como se podem identificar essas transferências de dados nos momentos iniciais? A resposta é que não se pode estimar. Antes de estimar o esforço ou o prazo, deve-se aproximar o tamanho. Para isso, se deve reconhecer qual é o fator de escala mais apropriado (Figura 15). Por exemplo, há conceitos de negócio pré-existentes e sobre os quais existe uma necessidade de manter e recuperar dados apesar de que apenas se tenha informação sobre o domínio do problema. O escopo estará definido em termos c FATTO Consultoria e Sistemas - Proibida a reprodução total ou parcial sem a permissão dos autores por escrito.

40 Estimativas de Software com o COSMIC 6/7 Java considerando 150 Pontos de Função COSMIC (CFP) e um esforço de homens-hora (HH) para entrega. Isso equivale a uma taxa de entrega correspondente a 07 HH/CFP. Isso indica que há uma probabilidade de 8% de que o esforço não esteja subestimado; parece-me otimista por demais. Figura 14. Um movimento de dados, 01 PFC. Figura 15. A diferença entre aproximar o tamanho e fazer uma medição. A figura 16 indica a distribuição de probabilidade derivada da série de projetos presentes na base de dados ISBSG - Grupo Internacional de Padrões de Benchmarking de software. Na linha horizontal, se mostram as faixas com intervalos de produtividade expressos em HH/CFP. Na linha vertical, apresentam-se as percentagens de probabilidade associados. A área assinalada indica a probabilidade acumulada de não subestimar. Algumas probabilidades são destacadas por seu valor de referencia: O ponto onde há 50% de probabilidade de subestimar o superestimar (a mediana) e a faixa de 25% acima e abaixo deste nivel (o primeiro e o terceiro quartil). de macro processos de negócio, áreas funcionais e sistemas impactados. Estes elementos podem ser contados e a sua correlação com o software final entregue e medido em pontos de função COSMIC determinada. Em momentos posteriores no ciclo de vida, quando já existe um escopo definido em termos de quais tarefas do usuário devem ser parcialmente ou totalmente transferidas para o software, é possível identificar processos e aplicar a mesma lógica na extrapolação da quantidade de pontos de função COSMIC a partir da quantidade de processos identificados. No final do projeto, a medição se realiza com o objetivo de: Avaliar o desempenho mediante a relação entre a quantidade de horas investidas e a quantidade de pontos de função COSMIC medidos; Reavaliar os indicadores de produtividade para que passem a incluir o desempenho do projeto que acaba de terminar. Reavaliar a quantidade de pontos de função COS- MIC que correspondem em média a cada processo e a cada conceito de negócio conforme o nível de informação disponível nos diferente pontos que se deseja estimar. 3.4 Estimativas como uma probabilidade Existe uma confusão sobre o conceito de estimativa. Alguns confundem este assunto com uma profecia. Quando a partir da informação incompleta, alguém manifesta uma quantidade de horas-homem ou um prazo que não esteja associado a um intervalo ou a uma probabilidade, ele não está gerando uma estimativa, está profetizando. Enquanto as profecias exigem um toque divino, as estimativas apenas necessitam dados e técnica. Figura 16. Avaliar estimativas com dados de benchmarking 3.6 Conhece-te a ti mesmo Além das referências externas promovidas por organizações que fornecem dados de benchmarking, existem os dados internos que tem até mais valor nas estimativas da produção, já que refletem com maior precisão as condições locais. Por exemplo, a linha horizontal no gráfico indica a medição em pontos de função COSMIC. Cada ponto, então, indica a quantidade de CFP e o esforço corresponde. A partir desses dados, é possível derivar uma tendência geral que descreva essa relação e possa ser utilizada na produção de estimativas. No gráfico são apresentadas algumas faixas. Cada uma delas descreve a projeção de produtividade e os intervalos de 95% confiança e predição. 3.5 As estimativas e os dados de benckmarking Há bases de dados de benchmarking que permitem calcular onde se posiciona uma estimativa em relação ao desempenho dos projetos presentes naquelas bases. Por exemplo, se estimou um projeto para o desenvolvimento em Figura 17. Avaliar estimativas com dados de benchmarking c FATTO Consultoria e Sistemas - Proibida a reprodução total ou parcial sem a permissão dos autores por escrito.

41 4. Conclusão Estimativas de Software com o COSMIC 7/7 Existe uma grande diferença entre as respostas para a seguinte pergunta Por que se solicitam HH para o projeto e não HH? : Há duas respostas: - Porque eu sei. - Porque há apenas 2% de probabilidade de entregar um projeto deste tamanho con HH de acordo com os dados históricos. além disso, não há um único projeto da base de dados internacional de avaliação comparativa que dê suporte a essa estimativa. 5. Referencias Bibliográficas ABRAN, 2010 Alain Abran, Software Metrics and Software Metrology, IEEE Computer Society Publications (Wiley), BOEHM, 2000 Barry W. Boehm, Chris Abts, A. Winsor Brown, Sunita Chulani, Bradford K. Clark, Ellis Horowitz, Ray Madachy, Donald J. Reifer, Bert Steece, Software Cost Estimation with CO- COMOII, Prentice Hall, COSMIC, 2015 The Common Software Measurement International Consortium (COSMIC), The COSMIC Functional Size Measurement Method, Version JONES, 2007 Capers Jones, Estimating Software Costs: Bringing Realism to Estimating, Osborne (McGraw HIll), 2nd. Edition, VAZQUEZ, 2013 Carlos Vazquez, Guilherme Simões, Renato Albert, Análise de Pontos de Função, Medição, Estimativas e Gerenciamento de Projetos de Software, São Paulo, Editora Érica, c FATTO Consultoria e Sistemas - Proibida a reprodução total ou parcial sem a permissão dos autores por escrito.