A melhoria do processo de software um objetino fundamentalpara as organiza6es e deve estar baseado em mediV6es. Entretanto, definir, coletar e analisar um conjunto de m6tricas nAo urns tarefa trivial. Neste artigo descrevemos uma abordagempara definiVo de metricas, realizao de mediJes e ava2iao do processo de software baseadanos seguintes passos: (I) identifica20 dos objetivos da medi20, defini&o das quest5es relacionadas a estes objetivos e seliio das mtricas adequadas seguindo a abordagem GQM (Goal-Question-Metrics); (2) realiza5o de medi6es como parte integrante do processo de desenvolvimento;(3) aruilisedos resultadosapoiada em um sistema baseado em conhecimento. As metricas coletadas so utilizadas para: (i) caracterizar o projeto para comparaAo de resultados;(ii) sugerir melhorias no processo com base no resultado das m6tricas e (iii) realizer estudos emp!ricos comparando resultados obtidos em diversos projetos.
Com o intuito de aperfeioar o desenvolvimento de software e obter produtos com os niveis desejaveis de qualidade, dentro do cronogramae oramento propostos, a l:iltima d6cads assistiu a uma mudana de enfoque com relaAo ao processo de software. Tern-se, entiio, uma nova abordagem na qual o foco principal das aten6es esni na garantia da qualidade do pr6prio processo produtivo, visto Que este tern Se mostrado o fator determinante para o alcance da qualidade do produtofinal.
A partirdesta mudana de foco, intensificou-se a pesquisa sobre o processo de desenvolvimento e varias normas e padr6es foram definidos a fim de auxiliar na definio e melhoria de processos de software. Com a intensifies&o dos estudos, constatou-se Que. para alcanar niveis cada vez mais altos de qualidade, era necessio melhorar cada passo do ciclo de vida de desenvolvimento [ll.
Muitas metricas foram, eno, propostas e aplicadas em casos prticos a fim de alcanar os seguintes objetivos: i) melhorar o entendimento sobre o processo, produto, recursos e ambiente de desenvolvimento e, assim, estabelecer bases para comparago entremediJes; ii) avaliaro andamento do projeto comparandocom dados planejados; iii) razerprevis5es sobre o futuro andamentodo projeto baseado em comportamentos passados; iv) promover melhorias identificando falhas, ineficincias e outrasoportunidadesparamelhorara qualidadedo produto e o desempenho do processo [2}.
Porem, ao contrlirio do Que possa parecer, definir,coletare analisarum conjunto de m6tricas uma tarefa custosa Que demands grande conhecimento para enitar Que o sen uso n2o aumente ainda mais Os problemas enfrentados durante o desenvolvimento de software. Al6m disso, propor um conjunto de modifies6es para o processo a fim de melhorar os resultados obtidos urnstarefaaindamais desafiadora.
Este trabalho descreve uma abordagem para medi80 e melhoria do processo de desenvolvimento de software baseadanos seguintes passos; (1) identifiesAo dos objetivos da medio, defini&o das quest6es relacionadas a estes objetivos e selo das m6tricas adequadas seguindo a abordagem GQM (GoaI-Question
integrante do processo de desenvolvimento; (
0 artigo esui organizado da seguinte forma. A segunda s5o &presentso passo CI) da abordagem proposta. Na sAo seguinte, 6 discutidaa mediAo do processo, na quarta apresentado como estd sendo desenvoJvido o sistema base&do em conhecimento para apolar a andJisedos result&dos.
diferentes mdtricas coJetadas para processo de software com o objetivo de avaJiare poder definir meJhoriassobre o mesmo. FinaJmente,na uJtima
trabalhofoi a selo de um conjunto de metricas Queseriam utiJizadaspara a avaJia5o de processes de desenvoJvimento de software. For6m, um processo de 56169o de m6tricasnAodeve ser feito de forma aleat6ria, pois isto pode dificultar a anise dos result&dosdevido ao grandevolume de dados Colet&dosa, J6mde provocar um aumentodo esforgo empregado no desenvoJvimento com o levantamentodestas inform&Jes.
objetivos mostrararna imponcia da definio pr6via de metas para faciJitara escolha de m6tricas e a correta interpret&Aodos result&dosobtidos nas medi6es. Assim, a abordagem GQM (Goal QuestionMetric) fol a soJu5o que concJuimos ser adequada para resolver este probJema. Esta abordagemse baseia na suposio de Quepara uma orgamza80 medir de forma eficiente, 6 necessario, primeiro, especiflcar objetivos a screw aJcanados, reJacionarestes objetivos com dados reais obtidos atrav6s de mediJes e, finalmente, prover um framework para a interpret&2o destes dados de acordo com os objetivospropostos [3]..
Seguindo esta abordagem, Jevantamos com
especialistas os probJemas mats comumente
enfrentados no desenvoJvimento de sistemas de
forma a facilitar a definiVAodos objetivos. Vos
foram os probJemas citados, por6rn tr6s se
destacaramcomo sendo os mais reJevantesao Se
iniciar uma abordagem de meJhoria baseada em
medi: (i) faJta de precis&odas estimativas de
projetos;(ii) baixa qualidadedos produtosliberados
para uso; e (iii) alto custo dos projetos. A partly
destes problemas, definimos Que a abordagem
proposta teria trSs objetivos: (1) meJhorar a
precisAodas estimativas de projeto;(
A partir da definiiio dos objetivos, passamos para a elaboraV2ode quest5es a screw investigadas a fim de analisar Se as metas definidas foram devidamente aJcanadas. Para cada urna destas quest5es, deveria ser vidveZa coJeta de vaJores quantitativos Que representassem corretarnente a realidade enfrentada no decorrer do desenvolvimento. Forarn eno, seJecionadas aJgumasquest6es e suas respectivas m6tricas,como pode ser visto nas figuras 1 2 e 3, Na figura 2, consideramos Erro qualquer problema encontrado em uma revisAo na fase em Que este foi gerado,
PrecisAo=Tempo real de todo o projeto
Precisko = Tempo real de cada fase do projeto
Precis2o = Esforo real de todo o projeto
Precio = Esforo real de cada fase do projeto
linhas de c6digo (exceto as em branco e as contendo somente comentarios).
Alem destas, outras m6tricas foram selecionadas para screw utilizadas na anise e melhoria do processo como ser nisto nas pr6ximas Se6es deste artigo. Vale ressaltar que todas as m6tricas utilizadas aqui e no decorrer deste trabalho forum extrafdas ou adaptadas da literatura [4, 5, 6, 7, 8, 9, 10, ll, 12, 13]. Sabemos, no entanto, que este esta longe de ser o melfxor conjunto de mtrices para a avaliao de qualquer projeto, nem g este nosso objetivo, porem, um conjunto que acreditamos ser valido para colocarmos esta idia em pratica e, a partir dos resultados obtidos, poder melhorlo.
um processo de software, este deve ser definido de forrna Clarae precisa a fim de evitar problemas na sua interpreta5o e deve ser devidamenteexecutado pela equipe de desenvoZnimentopara que OsvaZores coletados sejam validos para a suaavaliaBo.
A tarefa de defini8o do processo de software se inicia pela elaboraAo de urn processo bastante gen ico de forma a tornar possinel sua especializaAo para o desennolvimento de diferentes tipos de software (como, por exemplo, software para Web ou com orientao a objetos) e para diferentes cultnras organizacionais. A definio deste processo (chamado de processo padr8o) permite, tam1::)6m,sua instanciao para projetos especificos, considerando-se as caracteristicas particulates de cada projeto de desennolvimento. Esta instancia&o pode ser feita diretamente a partir do processo padrAo on a partir de especializa6es j existentes para tipos de software e empresas especificas. O modelo para definiVAode processos utilizado est ilustrado na figura 4. Mais detalhes sobre esta abordagem para definiao de processos pode ser encontrada em [14].
Assim, a partir da definio do processo, adaptamos alguns dos documentos jd previsto de screm elaborados durante o desenvolvimento do projeto de forma que todos Os dados necessarios para a anise do processo fossem faciJmente obtidos destes documentos. Desta forrna, a atividade de medio passou a ser parte integrante do pr6prio processo de desenvolvimento o que minimiza o tempo gasto na coleta de dados e nos perrnite separar as atividades de desenvolvimento das atividades de an:ilise e melhoria do processo.
Esta e uma caracteristica muito importante, pois permite que a equipe de desenvolvimento possa concentrar sens esforOs na realizao das atividades de produ80 enquanto as atividades de amilise da qualidade podem ser feitas por uma equipe especializada. Podemos citar como exemplos: o registro das datas dos marcos importantes no desenvolvimento em documentos de acompanhamento de projetos; a contagem do nOmero de erros e modifxca6es nos laudos de reuni6es de inspe30; e o controle de tempo gasto em atividades de desenvolvimento.
" pmjao` |
\ Est)al
DI 1 I
I edio e Av:alliao do cesSo I_ _________________________________7_3 ____
Figura 4: Modelo para Defini80 de Processos de Software`
definidos e o processo de coleta de dados integrado ao pr6prio processo produtivo. For6m, ainda nos falta defmir como analisar o resultado final das mediBes e, a partir desta andlise, sugerir modificaJes e melhoriaspara o processo utilizado. E importanteenfatizarQueneste trabalhoo objetivo principalnAoe medir o processo,mas Sim encontrar possibilidades para sua melhOria sendo utilizado, para isso, mediJes apenas como uma ferramenta de orienta&o [6]. Assim, quandoo custo accessario para a coleta de urna mtrica suplantar sen beneficio para o processo de melhoria, esta mtrica sera excluida do conjunto a ser coletado, pois sua finalidade bdsicafoi violad/a.
de mediJes 6 um processo que demandatempo e um conhecimento profundo sobre processo, m6tricas e melhoria. Alem disso, sabe-Se Queboa parte das empresas n5o possui em sua equipe pessoa! capacitado para desempenhar tal tarefa. Decidimos, portanto, pela construao de de um sistema capaz de apoiar a andlise e julgamento dos resultados das mediJes, identificar aspectos do processo Que necessitem de melhoria e, quando possi"vel,sugerir modificaJes para corrigir sens problemas e defici6ncias.Esse sisternautiliza como entradaos valores dasm6tricas definidas na Se&o 2 coletadas de um projeto especifico. A partirdesses valores6 feito uxnaandJisedos possiveis problemas
dos objetivos definidos (ver Se5o 2).
A construo deste sisterna especialista esta sendo feita a partir do conhecimento obtido de especialistas em rela8o A imerpretao dos resultados obtidos nas mediV6es e da relaAo entre estes resultados e aspectos do processo utilizado no desenvolvimento. O resultado d um conjunto de recomendag6esparamelhoria do processo.
Com este objetivo, procuramos obter o conhecimento sobre os possiveis problemas existencesno processo quandoresultadosruinspara as mdtricas aiio detectados. Sample Que um valor mio aceitdvet para o resultado de urnamdtrica for obtido, algurna infer8ncIa deverd ser feita em relaAo ks caracteristicasdo processo.
Fara validar esta id6ia, tomamos o primeiro objetivo definido no primeiro passo desta abordagem(melhorara precis5o das estimativas) e questionamos os especialistas quais as possiveis causas para a obten1;;5ode um valor n5o aceitavel para a mdtricade preciso de cronograma,ou seja, o Quepode tel levado o projeto a atrasar(mdtrica definidapara o objetivo I na Se&o 2). Ap6s definir as possiveis causas diretas deste problema, relacionamos estas causas com metricas que pudessem descrevas de forma quantitativa.For exemplo, podemos citar como causa de atraso no cronograma um alto indice de retrabalho Que 6 avaliado Feta mdtrica percentagem de retrabalho. Esta metodologia segue a abordagem GQM procurandoencontrar rnetricas para analisar cada um dos sub-objetivos Que possam auxiliar na analise dos objetivos principais~ For6rn Nesta proposta estamos encadeando os objetivos de maneira bierarquica onde os niveis inferiores definem causas para problemas encontrados nas metricas dos nfveis superiores [15]. Para cada um dos sub-objetivos, repetimos esta pesquisa atd encontrarmoscausas Que nAo pudessem ser mats hem detalhadasConQue n8o era de nosso interesse detalhar neste estagio em Que Se encontram os trabalhos).Na figura 5, pode ser visto, a tftulo de exemplo, um grafo gerado seguindo esta metOdologia. Nesse grafo, apresentamos Que possfvets causas de problemas na preciso da estinxativas (elipse na parte superior da figura) podem ser: problema com a forma das estimativas, problemas de baixo desempenho de pessoal ou motto retrabalho nas lases de desenvolvimento. Cada um desses problemas por sua vez pode ter sido gerado por varias raz6es. A causa do baixo desempenhode pessoal, por exemplo, pode ser pelo fato do pessoal ser val preparadoou porque houve alta rotatividadede pessoal. Finalmentea causa do pessoal ser mal preparado pode ser pela falta de experincia no dominio da aplica&o, na ferramenta,no mtodo, no processo ou mesmo na linguagem de programa5o. Quando desejarrnos razer a analise dos resultados de mdtricas de um determinadoprojeto vamos avaJiarOs valores de metricas de cada uma dessas causes e assim identifxcarqual ou quais foram os problemas para os resultadosnAosatisfat6rios paraum determinado objetivo~
E importante observer que, para cada nova metrica introduzida na construho da base de conhecimento do sistema especialista 6 necessaria a readapta&o dos documentos do processo como explicado anteriormentena 8o 3. Ou seja, todos as m6tricas utilizadas no sistema especialista estAo sendo coletados dos pr6prios documentos do processo. A incluso de nma nova metrica para analise no sistema implica em definirmos de onde vamos coletaros valores a serem avaliados.
Fara Que seja possfvel a constru&o do sisterna baseado em conhecimento utiJizando um grafo como o descrito anteriormente, ainda 6 necessdrio definir para cada n6 do grafo Que foi representado com urns m6trica, o Que deve ser consider&do um valor ruim ou no aceiuivel para o resultado da medio. Este procedimento deve, de alguma forms, perrnitir Que empresas com realidades diferentes possam utilizar valores distintos Que melhor se adequem iis suas condi6es e caracteristicas, al6m das pr6prias caracteristicas do projeto (ex: sistemas medicos necessitam uma confiabilidade maior Que jogos on aplicativos simples).
Estamos resolvendo este problems utilizando a parametriza5o destes valores de forma a perfflitir Que os usuios do sistema possam defini-los no infcio de cada projeto. Essa d urns alternativa interessante, pois valores cada vez melhores podem ser utilizados de maneira a permitir uma Constanta melhoria no processo de desenvolvimento e ,"'-r/ l..'"J
Com Os possfveis problemas definidos, passamos para a etapa final da elicita2o de conhecimento com Os especialistas Que, Haste porno, deveriam sugerir, para cads um dos problemas encontrados, modifiesJes para corrigir e melhorar o processo utilizado.
Como p6de ser vista, a abordagem proposta abrange desde a defirliAo das metricas para a analise da melhoria do processo, integraV5o destas ao pr6prio processo produtivo at6 a aruilise dos resultados das mediJes e sugeso de melhoria para o processo.
O conhecimento utilizado na construo da base do sistema especialista Se baseia somente em possibilitando o estabelecimento de metes a scram alcanadas.
Quando possivel, 6 interessante Que um primeiro projeto seja medido para avaliar qual o mvel em Que se encontram estes valores de forma a facilitar a definio dos par&metros. Outra orientsV&oQue d passada para Os usuios 6 a de valores extraidos da literatura, como exemplo, podemos citar a proposta de [16] Que define Queum valor no aceitavel para a metrics rotatividade de pessoal saris acima de 5%. entrevistasfeitas com especialistas no assunto. No entanto, tomouse o cuidado de selecionar as informsJes Que pudessem ser utilizadas por urns varied&domaior de projetos. Desta forms, na construV5o do sistema especialista nAo foram inclufdas, por exemplo, regras Que pudessem ser especfficas de um determinado dominio ou empress. Contudo, este ganho em generalidade implicou em urns sensivel perda de poder de andlise,pois regrasQueno pudessem ser utilizadas em projetos com determinadas caracteristicas, mesmo que pertinences para a rnaioria, n5o poderiarncompor a base de conhecimento.
Com a finalidade de contornar mais este problema, fol selecionado um Segundo grupo de menleas que seriam utilizadas para definir tipos" de projetos contendo caracteristicassimilares. Este grupo de m6tricas atualmente 6 composto por: tamanbo do sistema (em nurnero de linhas de c6digo, exceto as em branco e as contendo somente comenuirios), tempo total de desenvolvimento e experiimcia da equipe (obtida atrav6s de urn questiondrio). Acredita-se Que projetos de um mesmo Forte em tempo e tarnanhoe com equipes em um mesmo nivel tnico, normalmente enfrentam problemas similares, dai utilizarmos estas trEscaracteristicaspara classifxcardlferentes projetos.Por6m,sabemos que pode ser necessdriaa inclusAode outrasm6tricas ou caracterfsticaspara melhorar a classifica30 dos projetos e, desta forma, serdpermitidaa modificaAo deste conjunto quandonecessdrio.
Alem deste Segundo grupo utilizado para identificaro que consideramos'tipos" de projetos, fol ainda definido um terceiro para o qual Ser5o selecionadas m6tricas que Se pretende estudar melhor seu comportamento e relacionamento com as demais. Assim, sera construfda uma base de dados de m6t:ricas contendo dados obtidos em diferentes projetos de forma a corner possivel a realizaAo de estudos empiricos neste banco de dados comparando os resultados obtidos nos diferentesprojetos de um mesmo tipo". A medida que esta base aumentar,relaVSes entre metricas poderiio Se rnostrarpertinencese podero orientar no estabelecimento de novas regras a serem inseridas na base de conhecimento do sistema especialiSta.Assim, conhecirnentos especificos de determinadas ax"easpodeo compor a base do sistema especialista melhorando a qualidade das infer&nciase permitindo que respostas cada vez mais precisas possum ser obtidas e, desta forma, serdpossivel orientermelhor os desenvolvedores de sistemas. Somente para exemplificar este processo, podemos citar como exemplo a an;ilise da existencia de relacionamento entreo conhecimento do dorninio e a qualidade da especifxca5o de requisitos geradana lase de anaIisedo problema.
no mercado mundial, a melhoria da qualidade dos produtos de software passou a ser n5o mais um diferencial para a empresa desenvolvedora, mas
forma, a tentativa de encontrar abordagens que possibilitem a melhoria do processo de desenvolvimento tern sido uma constante cantona academiaquanto na industria.
inclui uma forma de escolha adequadade m6tricas, sua coleta de forma integrada ao pr6prio processo produtivo,ana1isedos resultados e sugest6es para a melhoria do processo de software baseado no conhecimentoextraidode especialistas.
Atualmente,os trabalhosestiio concentrados na implementa2o em prolog do sistema baseado em conbecimento que sertintilizadopara apolara etapa de andlise proposta nests abordagem. 0 sistema final devera ser integrado ao ambientede definiAo de processos, o TABA [17], de forma a compor a arLauseda qualidade dos processos definidos nesta ferramenta.