Mtricas e Estimativas de Software - O incio de um rally de regularidade Imagine que voc faa parte de uma equipe de Rally, e que

voc e sua equipe tenham que atravessar um deserto enorme e cheio de obstculos e que 50% dos fatores crticos de sucesso dependam do seu navegador para estimar o tempo do percurso e a distncia. Agora imagine-se diante de um projeto de Sistemas de Informao onde 50% dos fatores crticos de sucesso esto nos prazos e custos. Certamente voc ter que fazer uma eficiente mtrica e estimativa de software. As mtricas e estimativas de software vem se tornando um dos principais tpicos na Engenharia da Informao com a crescente exigncia de seus consumidores pela qualidade, rapidez, comodidade e baixo custo de implantao e manuteno, impossvel no enxergar tais tcnicas como alavanca para um produto de melhor qualidade, com custos adequados. Mas existem ainda muitas barreiras que impedem os profissionais da rea de utilizarem tais tcnicas ou de o fazerem de maneira errnea, embora a literatura disponvel atualmente sobre engenharia da informao seja relativamente ampla e variada, o que nos leva a questionar: Por que as mtricas e estimativas de software propostas para o desenvolvimento de sistemas no so fiis realidade e dimenso do problema? Tais tcnicas acompanharam a rpida evoluo do setor? Tais questes nos levam a crer que algumas mtricas e estimativas de software ficaram obsoletas e outras ganharam vigor nas pocas atuais, quando a busca da qualidade de software vem crescendo com grande rapidez. Acredito que o ato de medir e estimar a parte mais importante de um projeto de sistema bem-sucedido e alguns fatos como: a falta de maturidade, o desinteresse das empresas de desenvolvimento de sistemas e a baixa popularidade deste assunto entre os profissionais da rea de informtica so algumas da principais causas para o insucesso e o alto custo dos sistemas de informao. O termo mtrica de software refere-se mensurao dos indicadores quantitativos do tamanho e complexidade de um sistema. Estes indicadores so, por sua vez, utilizados para correlatar contra os desempenhos observados no passado afim de derivar previses de desempenho futuro. A mtrica de software tem como princpios especificar as funes de coleta de dados de avaliao e desempenho, atribuir essas responsabilidades a toda a equipe envolvida no projeto, reunir dados de desempenho pertencentes complementao do software, analisar os histricos dos projetos anteriores para determinar o efeito desses fatores e utilizar esses efeitos para pesar as previses futuras. Estes princpios nos permite prever o resto do processo, avaliar o progresso e reduzir a complexidade, como numa prova de rally, onde a cada corrida ficamos mais esclarecidos da condies e limites da equipe. As Mtricas Orientadas ao Tamanho Mtricas de software orientadas ao tamanho so medidas diretas do software e do processo por meio do qual ele desenvolvido. Se uma organizao de software mantiver registros simples, uma tabela de dados orientada ao tamanho poder ser criada. A tabela relaciona cada projeto de desenvolvimento de software que foi includo no decorrer dos ltimos anos aos correspondentes dados orientados ao tamanho deste projeto. A partir dos dados brutos contidos na tabela, um conjunto de mtricas de qualidade e de produtividade orientadas ao tamanho pode ser desenvolvido para cada projeto. Mdias podem ser computadas levando-se em considerao todos os projetos. As mtricas orientadas ao tamanho provocam controvrsias e no so universalmente aceitas como a melhor maneira de se medir o processo de desenvolvimento de software. A maior parte da controvrsia gira em torno do uso das linhas de cdigo (LOC) como uma medida-chave. Os proponentes da afeio de linhas de cdigo afirmam que as mesmas so o "artefato" de todos os projetos de desenvolvimento de software que podem ser facilmente contados, que muitos modelos existentes usam LOC ou KLOC (milhares de linhas de cdigo) como entrada-chave e que j existe um grande volume de literatura e de dados baseados nas linhas de cdigo. Por outro lado, os opositores afirmam que as medidas LOC so dependentes da linguagem de programao utilizada na codificao do projeto, que elas penalizam programas bem projetados, porm mais curtos, que elas no podem acomodar facilmente linguagens no-procedurais e que seu uso em estimativas requer um nvel de detalhes que pode ser difcil de conseguir (isto , o planejador deve estimar as linhas de cdigo a ser produzidas muito antes que a anlise e o projeto tenham sido construdos). Essa forma de medida foi uma herana do modelo de manufatura em que os CIO'S podiam determinar os recursos necessrios para uma "corrida", contando o nmero de produtos manufaturados necessrios. Essa mtrica no leva em considerao o fato de que o desenvolvimento envolve um custo relativo ao ambiente ou linguagem de programao utilizada. Por exemplo, em orientao a objeto (OO), a flexibilidade da ferramenta no uso de mecanismos de herana dilui o resultado final da contagem de linhas. A contagem de linhas de cdigo pode ser uma medida do que foi feito, e no uma medida a ser utilizada para previso. Mtricas Orientadas Funo Consiste em um mtodo para medio de software do ponto de vista do usurio, que determina de forma consistente o tamanho e

complexidade de um software, sob a perspectiva do usurio. Ele dimensiona um software, quantificando a funcionalidade proporcionada ao usurio a partir do seu desenho lgico. Ou seja, so medidas indiretas do software e do processo por meio do qual ele desenvolvido. Em vez de contar linhas de cdigo, a mtrica orientada funo concentra-se na funcionalidade ou utilidade do programa. Uma abordagem foi sugerida baseada nesta proposta chamada de pontos-por-funo (function point). Os pontos-por-funo (FPs) so derivados usando-se uma relao emprica baseada em medidas de informaes e complexidade do software. Um dos princpios da anlise de pontos-por-funo focaliza-se na perspectiva de como os usurios "enxergam" os resultados que um sistema produz. A anlise considera as vrias formas com que os usurios interagem com o sistema, com os seguintes objetivos: 1. Fornecer medidas consistentes; 2. Medir funcionalidades que o usurio solicita ou recebe; 3. Independncia da tecnologia; 4. Mtodo simples. As mtricas orientadas funo apresentam vrios benefcios, dentre eles podemos citar o seguintes: 1. Uma ferramenta para dimensionar aplicaes; 2. Um veculo para quantificar custo, esforo e tempo; 3. Um veculo para calcular ndices de produtividade e qualidade; 4. Um fator de normalizao para comparar software. Tal mtrica parece ser til e funcional para o desenvolvimento tradicional, mas apresenta algumas falhas com o modelo de desenvolvimento em orientao a objeto (OO), pois alguns atributos do design em OO invalidam o clculo de alguns pontos-porfuno. As caractersticas fundamentais de OO tm efeito de reduzir a validade da contagem de funes para a avaliao de esforo e recursos necessrios para a execuo de um projeto. A mtrica de pontos por funo foi originalmente projetada para sistemas de informao comerciais. Para acomodar estas aplicaes, a dimenso dos dados foi enfatizada para a excluso de dimenses funcionais e de controle. Por esta razo, a medida de pontos por funo era adequada para muitos sistemas de engenharia. Um nmero de extenses para a medida bsica de pontos por funo tem sido propostas para remediar esta situao. Uma extenso de pontos por funo chamada "feature points" (ou, pontos caractersticos) uma evoluo da medida de pontos por funo que pode ser aplicada a sistemas e aplicaes de engenharia de software. A medida "feature points" acomoda aplicaes em que a complexidade algortmica alta. Sistemas real-time de controle de processos e outros apresentam alta complexidade algortmica, e so receptivos a mtrica de "feature points". Para computar o "feature point", valores do domnio so contados e ponderados. A mtrica "feature point" conta uma nova caracterstica de software, os algoritmos. Um algoritmo definido como "um problema computacional que includo com um programa de computador especfico". Inverte uma matriz, decodificar um bit de string ou manusear uma interrupo so exemplos de algoritmos. Outra extenso de pontos por funo para sistemas real-time e produtos de engenharia tem sido desenvolvido por Boeing. A aproximao de Boeing integra a dimenso dos dados de software com dimenses funcionais e de controle para obter uma medida orientada funo, chamada pontos por funo 3D, que receptiva a aplicaes que enfatizem capacidades de funo e controle. Caractersticas de todas as trs dimenses do "contadas, quantificadas e transformadas" em uma medida que fornece uma indicao da funcionalidade fornecida pelo software. Contagem de dados retidos (a estrutura de dados interna do programa, isto , arquivos) e dados externos (entradas, sadas e referncias externas) so usados com medidas de complexidade para derivar uma contagem da dimenso de dados. A dimenso funcional medida considerando "o nmero de informaes internas requeridas para transformar entradas em dados de sada". Para os propsitos da computao de pontos por funo 3D, uma transformao vista como uma srie de passos de processamento que so limitados por regras semnticas estabelecidas. Como uma regra geral, a transformao concluda com

um algoritmo que resulta em uma mudana fundamental para dados de entrada como so processados para se transformarem em dados de sada. Passos de processamento que adquirem dados de um arquivo e simplesmente os coloca na memria do programa no poderia ser considerado uma transformao. O dado no sofreu nenhuma mudana. O nvel de complexidade associado a cada transformao uma funo do nmero de passos de processamento e o nmero de regras semnticas que controla os passos de processamento. A dimenso de controle medida pela contagem do nmero de transies entre os estados. Um estado representa algum modo internamente observvel de comportamento e uma transio ocorre como resultado de algum evento que fora o software ou sistema a mudar seu comportamento, isto , mudar seu estado. Quando pontos por funo 3D so computados, transies no so associadas a valores de complexidade. Nota-se que pontos por funo, "feature points" e pontos por funo 3D representam a mesma coisa "funcionalidade" ou "utilidade" fornecida pelo software. De fato, cada uma destas medidas resulta no mesmo valor se somente a dimenso de dados de uma aplicao considerada. Para sistemas real-time mais complexos, a contagem "feature points" de 20 a 35% mais alta que a contagem determinada usando somente pontos por funo. Pontos por funo (e suas extenses), como a medida LOC, controversa. Os proponentes acham que FP independente da linguagem de programao, tornando-se ideal para aplicaes usando linguagens convencionais e no procedurais, e que ela baseada em dados que so conhecidos muito cedo na evoluo do projeto, fazendo a FP mais atrativa como uma estimativa mais prxima. Oponentes acham que o mtodo requer alguma prestidigitao em que a computao baseada em dados subjetivos, que a contagem das informaes de domnio (e outras dimenses) podem ser difceis de coletar aps terminado o projeto, e que FP no tem significado fsico direto. s um nmero. Mtricas Voltadas para Orientao a Objeto Muitas mtricas j foram desenvolvidas para geraes passadas de tecnologia e, em muitos casos, so usadas at para desenvolvimento OO, porm no so muito coerentes, pois a diferena entre sistemas tradicionais e sistemas OO so muito grandes. Existem vrias propostas para mtricas OO que levam em considerao as caractersticas bsicas e interaes do sistema como: nmero de classes, nmero de cases, nmero de mtodos, mdias de mtodos, mdias de mtodos por classe, linhas de cdigo por mtodo, profundidade mxima da hierarquia de classes, a relao existente entre mtodos pblicos e privados, entre outros. Tais mtricas baseiam-se na anlise detalhada do design do sistema. Como na tcnica de pontos-por-funo, faz sentido adicionar um peso s mtricas das classes para produzir uma medida de complexidade do sistema. A maioria das medidas examina atributos em termos dos conceitos de OO, como herana, polimorfismo e encapsulamento. Para tanto, seria necessrio coletar um nmero significativo de contagens, ou seja, seria necessrio tomar valores de vrios projetos e dimencion-los selecionando as classes, os mtodos e os atributos desejveis para medir o tamanho e a complexidade de um novo software , o que nos tomaria um longo tempo. Estimativa de Tempo Aps desenvolver uma estimativa do volume de trabalho a ser feito, voc pode pensar que fcil estimar a extenso do tempo que o projeto exigir. Afinal, se voc tem um projeto estimado em dez pessoas-ms e h cinco pessoas disponveis ele deve levar dois meses para ser concludo. Mas, e se somente duas pessoas estiverem disponveis? O projeto leva cinco meses para ficar pronto? De um modo geral, a nossa preocupao aqui com a relao tempo/pessoal. Muitos anos de dolorosa experincia ensinaram-nos que tal relao no simples. Duplicar o nmero de pessoas em um projeto no reduz necessariamente a durao do projeto pela metade (muito pelo contrrio, se colocarmos mais pessoas num projeto em andamento isso apenas retardar ainda mais o processo, uma vez que estas pessoas devero receber treinamento adequado e "aprender" todo o projeto desde seu incio at a fase atual, e isso consome muito tempo). A estimativa do esforo a tcnica mais comum para se levantar os custos de qualquer projeto de desenvolvimento de engenharia. Um nmero de pessoas-dia, pessoas-ms ou pessoas-ano aplicado soluo de cada tarefa do projeto. Um custo em dlares associado a cada unidade de esforo e um custo estimado ser derivado. Como a tcnica LOC (linhas de cdigo) ou FP (pontos-por-funo), a estimativa de esforo inicia-se com um delineamento das funes do software obtidas a partir do escopo do projeto. Uma srie de tarefas de engenharia de software - anlise de requisitos, projeto, codificao e teste - deve ser

executada para cada funo. O planejador estima o esforo (por exemplo, pessoas-ms) que seria exigido para se concluir cada tarefa de engenharia de software para cada funo de software. Taxas de mo-de-obra (isto , custo/esforo unitrio) so aplicados em cada uma das tarefas de engenharia de software. Muito provavelmente, a taxa de mo-de-obra ir variar para cada tarefa. O pessoal de nvel snior envolver-se- fortemente na anlise de requisitos e nas primeiras tarefas de realizao de projeto; o pessoal de nvel jnior (que inerentemente menos dispendioso) envolver-se- nas ltimas tarefas de projeto, codificao e nos primeiros teste. O custo e o esforo de cada funo e tarefa de engenharia de software so computados como o ltimo passo. Se a estimativa do esforo for realizada independentemente da estimativa LOC ou FP, teremos ento duas estimativas para o custo e para o esforo que podem ser comparadas e reconciliadas. Se os dois conjuntos de estimativas demonstrarem razovel concordncia, haver uma boa razo para acreditar que as estimativas so confiveis. Se, por outro lado, os resultados dessas tcnicas de decomposio exibirem pouca concordncia, ser necessrio levar a efeito a investigao e anlise adicionais. Estimativa de Custo O objetivo desta anlise calcular de maneira antecipada todo e qualquer custo que esteja associado ao sistema, tais como: construo, instalao, operao e manuteno. O custo da construo um tpico importante, visto que graas a ele que sabemos o total de todas as pessoas envolvidas no desenvolvimento do sistema, tais como: burocratas, diretores, membros da comunidade usuria, consultores e programadores, membros da auditoria, do controle de qualidade ou da equipe de operaes. O custo de instalao do sistema um projeto simples que podemos entregar em disquetes ou CD-ROMs e a instalao fica por conta do prprio usurio. Porm, em caso de sistemas grandes, o processo de instalao mais complexo e envolve outros fatores, tais como: custo de treinamento do usurio, custo de converso de banco de dados, custo de instalao do fornecedor, custo da aprovao legal, custo do processamento paralelo, custo da equipe de desenvolvimento durante a instalao. Naturalmente, toda a comunidade de usurios precisar de treinamento para maior familiarizao com o sistema. Este tipo de capital pode ser obtido atravs de emprstimo ou de reservas prprias. Dependendo da organizao temos que express-lo como sendo custo do emprstimo feito ou em termos de juros que o dinheiro poderia estar rendendo se tivesse sido investido em lugar de ser utilizado no projeto. Esta rea deve estar sempre em sintonia com o departamento de contabilidade. O custo operacional entra em ao aps a instalao do sistema. Haver um custo para o usurio manter sua operao. Contudo, isso tambm deve representar uma rea em que seu novo sistema economizar dinheiro, pois ele presumivelmente ser mais barato que o atual sistema. Os custos operacionais mais comuns so: custos de hardware e de suprimentos, custos de software, custo de pessoal, custo de manuteno e custo de recursos. O custo de falhas, ou manuteno, como podemos imaginar, diz respeito s diversas formas de erros que podem tornar o sistema completamente indisponvel at que este erro seja corrigido, enquanto que em outros casos o sistema continua funcionando, porm uma ou mais de suas sadas podem estar incorretas. Este custo importante pelo simples fato de no termos sistemas perfeitos. Devemos checar sempre as estatsticas disponveis acerca da confiabilidade do software. O Fator Humano Quando os objetivos para o desenvolvimento de sistemas no so claros, as pessoas passam a deduzir e criar o produto dentro de suas prprias vises, levando a sistemas inadequados para a funo do negcio a ser atendida e, consequentemente, a mtricas falhas, gerando uma expectativa divergente entre o cliente e os tcnicos ressonveis, isto , uma estimativa irreal. As pessoas so sensveis aos estmulos externos e por meio de tais estmulos so influenciadas suas atitudes e pensamentos. Um analista, ou um grupo de analistas, disposto a estimar o tempo e custo de um projeto no poderia deixar de dar a devida relevncia a este fato. Um grupo de pessoas motivado, trabalhando em um ambiente agradvel, sem sofrer qualquer tipo de presso por parte da empresa ou organizao produziria muito mais do que um grupo de pessoas sujeitas a condies adversas a estas. Mas no apenas o ambiente de trabalho, so as relaes familiares e pessoais, os estudos e uma outra srie de fatores que podem ser aqui classificados como estmulos externos. Para tentar amenizar a dificuldade e se estabelecer critrio para a estimativa em relao a pessoal (fator humano) surge o conceito de "Engenharia Humana", que consiste em aplicar conceitos de psicologia para se projetar uma interao homemcomputador de alta qualidade. Do ponto de vista do especialista em engenharia humana, o homem e a mquina so partes integrantes de todo um sistema homem-mquina. Ele v o homem como um elo de coleta e processamento de dados. Mesmo com tcnicas como esta, o fator humano continuar sendo uma incgnita praticamente indecifrvel na prtica da estimativa de software.

Concluso Em um processo de desenvolvimento de software preciso medir custo, produtividade e qualidade no s do produto final, mas tambm de todo o processo. Com a implantao de um sistema de coleta de mtricas, os desenvolvedores podero avaliar melhor a sua produtividade e adaptabilidade ao processo de desenvolvimento e, com isso, estimar melhor o tempo necessrio para executar cada tarefa. A princpio, necessrio determinar o que se quer medir, afim de se definir como os dados sero coletados. Essas decises devem ser compatveis com o processo de desenvolvimento. Uma metodologia de mtrica e estimativa no vai solucionar de imediato os problemas de um processo de desenvolvimento, no entanto esta deve ser utilizada para tornar possvel o entendimento do processo, para facilitar a previso de suas fases e mostrar como control-las. As estimativas jamais podero ser precisas e exatas, pois no so apenas fatores tcnicos e "contveis", palpveis que fazem parte de um projeto, mas tambm existem pessoas, sentimentos, polticas, crenas, ambiente e outros mais que no se podem medir, so absolutamente variveis. Afinal, no seria possvel estabelecer um padro, ou ainda, transformar em nmeros os sentimentos de uma pessoa, ou provar a ela que, matematicamente, suas supersties no so vlidas. Estimar necessrio sim, mas com forte embasamento terico e prtico, mas estimar no adivinhar. ALVARO EDUARDO GOMES Cargo: Consultor de Sistemas de Informao Empresa: Abu FrameWork - Consultoria em Informtica E-mail: abu@abuframework.com.br