Estimativas de Software com o COSMIC

Transcrição

1 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 pequenas partes 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 Derivação da unidade de produto dos requisitos funcional 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 solicita uma estimativa para um desenvolvedor da entrega de um programa testado que implementa uma transação comercial, 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 pequenas partes 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 necessário investir em sua realização como uma função da quantidade de programas como, por

2 Estimativas de Software com o COSMIC 2/7 Figura 2. Estimar a entrega de um produto final ao longo de dois anos. exemplo, a Engenharia de Requisitos e o projeto de arquitetura. Os produtos dessas atividades são os insumos para a programação e testes de unidade usados no exemplo apresentado na abertura deste texto. Em outras 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. mudanças organizacionais que envolvem orquestrar o desenvolvimento de novos sistemas, a melhoria de vários sistemas existentes. Iniciativas que implicam em uma avaliação preliminar de custo-benefício para apoiar decisões executivas para investimentos que devem ser justificados para os responsáveis pela governança corporativa. Isso também facilita que as equipe 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 pequenos impactos negativos, 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 tabalho 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 mudanças que devem ser priorizadas nos 20% das demandas que consomem os 80% dos recursos? Estimar viabiliza a gestão de 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 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, passando por vários projetos de engenharia, construção e testes, 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).

3 Estimativas de Software com o COSMIC 3/7 Figura 7. Apropriação directa e indireta de custos. unidade de produto para o planejamento e monitoramento 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. Com essa informação eu pude chegar a conclusão de uma estimativa da área pela qual poderia pagar e, a partir disso, tive 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 cheguei ao ponto de necessitar estimar o custo especificamente com os banheiros eu já tinha 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 efetivamente 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 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:

4 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. La evolución de los requerimientos. 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. Fuentes de información sobre los requerimientos 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 Derivação da unidade de produto dos requisitos funcional 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.

5 Estimativas de Software com o COSMIC 5/7 Métodos anteriores nem sempre tem a aplicabilidade ampla o suficiente para atender as necessidades do mercado, ou 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. 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 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. Visión general del 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. Fronteras. 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 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).

6 Estimativas de Software com o COSMIC 6/7 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 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 diferena entre aproximar o tamanho e fazer uma medição. 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 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. 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). 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 Figura 17. Avaliar estimativas com dados de benchmarking

7 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, 2013.