ktricas para Medi5o e Memoria de Processos deSoftware

Augusto Gomes, Ktbia Mal de Olineira, An& Regina Rocha

COPP~-Programa de Engenharia de Sistemas e ComputaoCaixa Postal 68 511 - Rio de Janeiro - RJ - Brasil - Cep 21945-970

e-mail: {azomes~ kathia, darocha }@ cos.ufrj.br

Abstract

A melhoria do processo de software umobjetino fundamental para as organiza6es e deveestar baseado em mediV6es. Entretanto, definir,coletar e analisar um conjunto de m6tricas nAo urns tarefa trivial. Neste artigo descrevemos umaabordagem para definiVo de metricas, realizaode mediJes e ava2iao do processo de softwarebaseada nos seguintes passos: (I) identifica20 dosobjetivos da medi20, defini&o das quest5esrelacionadas a estes objetivos e seliio dasmtricas adequadas seguindo a abordagem GQM(Goal-Question-Metrics); (2) realiza5o demedi6es como parte integrante do processo dedesenvolvimento; (3) aruilise dos resultados apoiadaem um sistema baseado em conhecimento. Asmetricas coletadas so utilizadas para: (i)caracterizar o projeto para comparaAo deresultados; (ii) sugerir melhorias no processo combase no resultado das m6tricas e (iii) realizerestudos emp!ricos comparando resultados obtidosem diversos projetos.

1. Introdu5oCom o intuito de aperfeioar o desenvolvimento

de software e obter produtos com os niveisdesejaveis de qualidade, dentro do cronograma eoramento propostos, a l:iltima d6cads assistiu auma mudana de enfoque com relaAo ao processode software. Tern-se, entiio, uma nova abordagemna qual o foco principal das aten6es esni nagarantia da qualidade do pr6prio processoprodutivo, visto Que este tern Se mostrado o fatordeterminante para o alcance da qualidade doproduto final.

A partir desta mudana de foco, intensificou-sea pesquisa sobre o processo de desenvolvimento evarias normas e padr6es foram definidos a fim deauxiliar na definio e melhoria de processos desoftware. Com a intensifies&o dos estudos,

constatou-se Que. para alcanar niveis cada vezmais altos de qualidade, era necessio melhorarcada passo do ciclo de vida de desenvolvimento [ll.Por6m, para Que isso se tornasse possivel, dadosquantitativos, Que pudessem descrever a realidadedo processo, precisavam ser obtidos e devidamenteanalisados.

Muitas metricas foram, eno, propostas eaplicadas em casos prticos a fim de alcanar osseguintes objetivos: i) melhorar o entendimentosobre o processo, produto, recursos e ambiente dedesenvolvimento e, assim, estabelecer bases paracomparago entre mediJes; ii) avaliar o andamentodo projeto comparando com dados planejados; iii)razer previs5es sobre o futuro andamento do projetobaseado em comportamentos passados; iv)promover melhorias identificando falhas,ineficincias e outras oportunidades para melhorar aqualidade do produto e o desempenho do processo[2}.

Porem, ao contrlirio do Que possa parecer,definir, coletar e analisar um conjunto de m6tricas uma tarefa custosa Que demands grandeconhecimento para enitar Que o sen uso n2oaumente ainda mais Os problemas enfrentadosdurante o desenvolvimento de software. Al6mdisso, propor um conjunto de modifies6es para oprocesso a fim de melhorar os resultados obtidos urns tarefa ainda mais desafiadora.

Este trabalho descreve uma abordagem paramedi80 e melhoria do processo dedesenvolvimento de software baseada nos seguintespassos; (1) identifiesAo dos objetivos da medio,defini&o das quest6es relacionadas a estesobjetivos e selo das m6tricas adequadasseguindo a abordagem GQM (GoaI-Question-Metrics); (2) realizao de wadiJes corno parteintegrante do processo de desenvolvimento; (3)analise dos resultados apoiada pela constru50 deum sistema baseado em conhecimento. AconstruAo do sistema baseado em conhecimentofol realizada considerando as m6tricas definidas e

QuaTIC'2OOI / 71

Os possiveis probJemas ou causas para result&dosno satisfat6rios para as mesmas.

0 artigo esui organizado da seguinte forma. Asegunda s5o &presents o passo CI) da abordagemproposta. Na sAo seguinte, 6 discutida a mediAodo processo, na quarta apresentado como estdsendo desenvoJvido o sistema base&do emconhecimento para apolar a andJise dos result&dos.Na Quinta sAo discutimos a utilizao dediferentes mdtricas coJetadas para processo desoftware com o objetivo de avaJiar e poder definirmeJhorias sobre o mesmo. FinaJmente, na uJtimaSe&o 6 apresentado as conclus6es desse trabaJho.

2. Defmio dos Objetivos e Mtricas

O primeiro passo para a reaZiza5o destetrabalho foi a selo de um conjunto de metricasQue seriam utiJizadas para a avaJia5o de processesde desenvoJvimento de software. For6m, umprocesso de 56169o de m6tricas nAo deve ser feitode forma aleat6ria, pois isto pode dificultar aanise dos result&dos devido ao grande volume dedados Colet&dos, aJ6m de provocar um aumento doesforgo empregado no desenvoJvimento com olevantamento destas inform&Jes.

Experiencias em mediJes orientadas aobjetivos mostrararn a imponcia da definiopr6via de metas para faciJitar a escolha de m6tricase a correta interpret&Ao dos result&dos obtidos nasmedi6es. Assim, a abordagem GQM (GoalQuestion Metric) fol a soJu5o que concJuimos seradequada para resolver este probJema. Estaabordagem se baseia na suposio de Que para umaorgamza80 medir de forma eficiente, 6 necessario,primeiro, especiflcar objetivos a screw aJcanados,reJacionar estes objetivos com dados reais obtidosatrav6s de mediJes e, finalmente, prover umframework para a interpret&2o destes dados deacordo com os objetivos propostos [3]..

Seguindo esta abordagem, Jevantamos comespecialistas os probJemas mats comumenteenfrentados no desenvoJvimento de sistemas deforma a facilitar a definiVAo dos objetivos. Vosforam os probJemas citados, por6rn tr6s sedestacaram como sendo os mais reJevantes ao Seiniciar uma abordagem de meJhoria baseada emmedi: (i) faJta de precis&o das estimativas deprojetos; (ii) baixa qualidade dos produtos liberadospara uso; e (iii) alto custo dos projetos. A partlydestes problemas, definimos Que a abordagemproposta teria trSs objetivos: (1) meJhorar aprecisAo das estimativas de projeto; (2) meJhorar aqualidade dos produtos Jiberados para uso; e, (3)diminuir o custo final dos projetos.

A partir da definiiio dos objetivos, passamospara a elaboraV2o de quest5es a screw investigadasa fim de analisar Se as metas definidas foramdevidamente aJcanadas. Para cada urna destasquest5es, deveria ser vidveZ a coJeta de vaJoresquantitativos Que representassem corretarnente arealidade enfrentada no decorrer dodesenvolvimento. Forarn eno, seJecionadasaJgumas quest6es e suas respectivas m6tricas, comopode ser visto nas figuras 1 2 e 3, Na figura 2,consideramos Erro qualquer problema encontradoem uma revisAo na fase em Que este foi gerado,ModificaVo 6 um problem& encontrado em umdocumento em fases posteriores a suas aceitao eo Tamanho do Sistema medido em nl:imero de

Objetivo 1:' Melborar a preciso das estimativasde projeto.

QuestAo 1.1: Qua} 6 a precisgo das estimativasde cronograma?

M6trica l~la) Preciso da estimativa decronograma de todo o projeto

PrecisAo = Tempo real de todo o projetoTempo estimado do projeto

M6trica 1.lb) Preciso da estimativa decronograma por lase do projeto

Precisko = Tempo real de cada fase do projetoTempo estimado para a fase

Queso 1.2; QuaI 6 a precis&o das estimativasde esforo?

M6trica I.2a) Preciso da estimativa de esforode todo o projeto

Precis2o = Esforo real de todo o projetoEsforo estimado para o projeto

M6trica 1.2b) Precio da estimativa de esforopor fase do projeto

Precio = Esforo real de cada fase do projetoEsforo estimado para a

lase

Figura 1 - M6tricas para o objetivo meJhorarprecisAo de estimativas

72 / QuaTIC'2001

linhas de c6digo (exceto as em branco e ascontendo somente comentarios).

Alem destas, outras m6tricas foram selecionadaspara screw utilizadas na anise e melhoria doprocesso como ser nisto nas pr6ximas Se6es desteartigo. Vale ressaltar que todas as m6tricasutilizadas aqui e no decorrer deste trabalho forumextrafdas ou adaptadas da literatura [4, 5, 6, 7, 8, 9,10, ll, 12, 13]. Sabemos, no entanto, que este estalonge de ser o melfxor conjunto de mtrices para aavaliao de qualquer projeto, nem g este nossoobjetivo, porem, um conjunto que acreditamos servalido para colocarmos esta idia em pratica e, apartir dos resultados obtidos, poder melhorlo.

3. Medio do Processo

Para tomar possfvel a medi8o e a melhoria deum processo de software, este deve ser definido deforrna Clara e precisa a fim de evitar problemas nasua interpreta5o e deve ser devidamente executadopela equipe de desenvoZnimento para que Os vaZorescoletados sejam validos para a sua avaliaBo.

A tarefa de defini8o do processo de software seinicia pela elaboraAo de urn processo bastantegen ico de forma a tornar possinel suaespecializaAo para o desennolvimento dediferentes tipos de software (como, por exemplo,software para Web ou com orientao a objetos) epara diferentes cultnras organizacionais. Adefinio deste processo (chamado de processopadr8o) permite, tam1::)6m, sua instanciao paraprojetos especificos, considerando-se ascaracteristicas particulates de cada projeto dedesennolvimento. Esta instancia&o pode ser feitadiretamente a partir do processo padrAo on a partirde especializa6es j existentes para tipos desoftware e empresas especificas. O modelo paradefiniVAo de processos utilizado est ilustrado nafigura 4. Mais detalhes sobre esta abordagem paradefiniao de processos pode ser encontrada em[14].

Assim, a partir da definio do processo,adaptamos alguns dos documentos jd previsto descrem elaborados durante o desenvolvimento doprojeto de forma que todos Os dados necessariospara a anise do processo fossem faciJmenteobtidos destes documentos. Desta forrna, aatividade de medio passou a ser parte integrantedo pr6prio processo de desenvolvimento o queminimiza o tempo gasto na coleta de dados e nosperrnite separar as atividades de desenvolvimentodas atividades de an:ilise e melhoria do processo.Esta e uma caracteristica muito importante, poispermite que a equipe de desenvolvimento possaconcentrar sens esforOs na realizao dasatividades de produ80 enquanto as atividades deamilise da qualidade podem ser feitas por umaequipe especializada. Podemos citar comoexemplos: o registro das datas dos marcosimportantes no desenvolvimento em documentos deacompanhamento de projetos; a contagem donOmero de erros e modifxca6es nos laudos dereuni6es de inspe30; e o controle de tempo gastoem atividades de desenvolvimento.

�" - \ 1- | Est)al DI II

edio e Av:alliao do cesSo I ______________________________________________________

Figura 4: Modelo para Defini80 de Processos de Software`

pmjao`

73

4. An:Sise dos Result&dos dasMediBes

Neste ponto da abordagem temos os objetivosdefinidos e o processo de coleta de dados integradoao pr6prio processo produtivo. For6m, ainda nosfalta defmir como analisar o resultado final dasmediBes e, a partir desta andlise, sugerirmodificaJes e melhorias para o processo utilizado.E importante enfatizar Que neste trabalho o objetivoprincipal nAo e medir o processo, mas Sim encontrarpossibilidades para sua melhOria sendo utilizado,para isso, mediJes apenas como uma ferramentade orienta&o [6]. Assim, quando o custo accessariopara a coleta de urna mtrica suplantar senbeneficio para o processo de melhoria, esta mtricasera excluida do conjunto a ser coletado, pois suafinalidade bdsica foi violad/a.

For6rn a analise dos resultados obtidos atrav6sde mediJes 6 um processo que demanda tempo eum conhecimento profundo sobre processo,m6tricas e melhoria. Alem disso, sabe-Se Que boaparte das empresas n5o possui em sua equipepessoa! capacitado para desempenhar tal tarefa.Decidimos, portanto, pela construao de de umsistema capaz de apoiar a andlise e julgamento dosresultados das mediJes, identificar aspectos doprocesso Que necessitem de melhoria e, quandopossi"vel, sugerir modificaJes para corrigir sensproblemas e defici6ncias. Esse sisterna utiliza comoentrada os valores das m6tricas definidas na Se&o 2coletadas de um projeto especifico. A partir dessesvalores 6 feito uxna andJise dos possiveis problemasQue levaram a resultados r]do satisfat6rios para umdos objetivos definidos (ver Se5o 2).

A construo deste sisterna especialista estasendo feita a partir do conhecimento obtido deespecialistas em rela8o A imerpretao dosresultados obtidos nas mediV6es e da relaAo entreestes resultados e aspectos do processo utilizado nodesenvolvimento. O resultado d um conjunto derecomendag6es para melhoria do processo.

Com este objetivo, procuramos obter oconhecimento sobre os possiveis problemasexistences no processo quando resultados ruins paraas mdtricas aiio detectados. Sample Que um valormio aceitdvet para o resultado de urna mdtrica forobtido, algurna infer8ncIa deverd ser feita emrelaAo ks caracteristicas do processo.

Fara validar esta id6ia, tomamos o primeiroobjetivo definido no primeiro passo destaabordagem (melhorar a precis5o das estimativas) equestionamos os especialistas quais as possiveiscausas para a obten1;;5o de um valor n5o aceitavel

para a mdtrica de preciso de cronograma, ou seja,o Que pode tel levado o projeto a atrasar (mdtricadefinida para o objetivo I na Se&o 2). Ap6s definiras possiveis causas diretas deste problema,relacionamos estas causas com metricas quepudessem descrevas de forma quantitativa. Forexemplo, podemos citar como causa de atraso nocronograma um alto indice de retrabalho Que 6avaliado Feta mdtrica percentagem de retrabalho.Esta metodologia segue a abordagem GQMprocurando encontrar rnetricas para analisar cadaum dos sub-objetivos Que possam auxiliar naanalise dos objetivos principais~ For6rn Nestaproposta estamos encadeando os objetivos demaneira bierarquica onde os niveis inferioresdefinem causas para problemas encontrados nasmetricas dos nfveis superiores [15]. Para cada umdos sub-objetivos, repetimos esta pesquisa atdencontrarmos causas Que nAo pudessem ser matshem detalhadas Con Que n8o era de nosso interessedetalhar neste estagio em Que Se encontram ostrabalhos). Na figura 5, pode ser visto, a tftulo deexemplo, um grafo gerado seguindo estametOdologia. Nesse grafo, apresentamos Quepossfvets causas de problemas na preciso daestinxativas (elipse na parte superior da figura)podem ser: problema com a forma das estimativas,problemas de baixo desempenho de pessoal oumotto retrabalho nas lases de desenvolvimento.Cada um desses problemas por sua vez pode tersido gerado por varias raz6es. A causa do baixodesempenho de pessoal, por exemplo, pode ser pelofato do pessoal ser val preparado ou porque houvealta rotatividade de pessoal. Finalmente a causa dopessoal ser mal preparado pode ser pela falta deexperincia no dominio da aplica&o, naferramenta, no mtodo, no processo ou mesmo nalinguagem de programa5o. Quando desejarrnosrazer a analise dos resultados de mdtricas de umdeterminado projeto vamos avaJiar Os valores demetricas de cada uma dessas causes e assimidentifxcar qual ou quais foram os problemas paraos resultados nAo satisfat6rios para um determinadoobjetivo~

E importante observer que, para cada novametrica introduzida na construho da base deconhecimento do sistema especialista 6 necessariaa readapta&o dos documentos do processo comoexplicado anteriormente na 8o 3. Ou seja, todosas m6tricas utilizadas no sistema especialista estAosendo coletados dos pr6prios documentos doprocesso. A incluso de nma nova metrica paraanalise no sistema implica em definirmos de ondevamos coletar os valores a serem avaliados.

Fara Que seja possfvel a constru&o do sisternabaseado em conhecimento utiJizando um grafo

74 / QuaTIC'2OOI

como o descrito anteriormente, ainda 6 necessdriodefinir para cada n6 do grafo Que foi representadocom urns m6trica, o Que deve ser consider&do umvalor ruim ou no aceiuivel para o resultado damedio. Este procedimento deve, de algumaforms, perrnitir Que empresas com realidadesdiferentes possam utilizar valores distintos Quemelhor se adequem iis suas condi6es ecaracteristicas, al6m das pr6prias caracteristicas doprojeto (ex: sistemas medicos necessitam umaconfiabilidade maior Que jogos on aplicativossimples).

Estamos resolvendo este problems utilizando aparametriza5o destes valores de forma a perfflitirQue os usuios do sistema possam defini-los noinfcio de cada projeto. Essa d urns alternativainteressante, pois valores cada vez melhores podemser utilizados de maneira a permitir uma Constantamelhoria no processo de desenvolvimento e

Com Os possfveis problemas definidos,passamos para a etapa final da elicita2o deconhecimento com Os especialistas Que, Hasteporno, deveriam sugerir, para cads um dosproblemas encontrados, modifiesJes para corrigire melhorar o processo utilizado.

Como p6de ser vista, a abordagem propostaabrange desde a defirliAo das metricas para aanalise da melhoria do processo, integraV5o destasao pr6prio processo produtivo at6 a aruilise dosresultados das mediJes e sugeso de melhoriapara o processo.

5. Ampliando a AvaliaAo doProcesso de Software

O conhecimento utilizado na construo da basedo sistema especialista Se baseia somente em

,"'r -/ l..'"J

possibilitando o estabelecimento de metes a scramalcanadas.

Quando possivel, 6 interessante Que umprimeiro projeto seja medido para avaliar qual om�vel em Que se encontram estes valores de forma afacilitar a definio dos par&metros. OutraorientsV&o Que d passada para Os usuios 6 a devalores extraidos da literatura, como exemplo,podemos citar a proposta de [16] Que define Que umvalor no aceitavel para a metrics rotatividade depessoal saris acima de 5%.

entrevistas feitas com especialistas no assunto. Noentanto, tomouse o cuidado de selecionar asinformsJes Que pudessem ser utilizadas por urnsvaried&do maior de projetos. Desta forms, naconstruV5o do sistema especialista nAo foraminclufdas, por exemplo, regras Que pudessem serespecfficas de um determinado dominio ouempress. Contudo, este ganho em generalidadeimplicou em urns sensivel perda de poder deandlise, pois regras Que no pudessem ser utilizadasem projetos com determinadas caracteristicas,

QuaTIC2OOI / 75

mesmo que pertinences para a rnaioria, n5opoderiarn compor a base de conhecimento.

Com a finalidade de contornar mais esteproblema, fol selecionado um Segundo grupo demenleas que seriam utilizadas para definir �tipos"de projetos contendo caracteristicas similares. Estegrupo de m6tricas atualmente 6 composto por:tamanbo do sistema (em nurnero de linhas dec6digo, exceto as em branco e as contendo somentecomenuirios), tempo total de desenvolvimento eexperiimcia da equipe (obtida atrav6s de urnquestiondrio). Acredita-se Que projetos de ummesmo Forte em tempo e tarnanho e com equipesem um mesmo nivel tnico, normalmenteenfrentam problemas similares, dai utilizarmosestas trEs caracteristicas para classifxcar dlferentesprojetos. Por6m, sabemos que pode ser necessdria ainclusAo de outras m6tricas ou caracterfsticas paramelhorar a classifica30 dos projetos e, destaforma, serd permitida a modificaAo deste conjuntoquando necessdrio.

Alem deste Segundo grupo utilizado paraidentificar o que consideramos 'tipos" de projetos,fol ainda definido um terceiro para o qual Ser5oselecionadas m6tricas que Se pretende estudarmelhor seu comportamento e relacionamento comas demais. Assim, sera construfda uma base dedados de m6t:ricas contendo dados obtidos emdiferentes projetos de forma a corner possivel arealizaAo de estudos empiricos neste banco dedados comparando os resultados obtidos nosdiferentes projetos de um mesmo �tipo". A medidaque esta base aumentar, relaVSes entre metricaspoderiio Se rnostrar pertinences e podero orientarno estabelecimento de novas regras a sereminseridas na base de conhecimento do sistemaespecialiSta. Assim, conhecirnentos especificos dedeterminadas ax"eas podeo compor a base dosistema especialista melhorando a qualidade dasinfer&ncias e permitindo que respostas cada vezmais precisas possum ser obtidas e, desta forma,serd possivel orienter melhor os desenvolvedores desistemas. Somente para exemplificar este processo,podemos citar como exemplo a an;ilise daexistencia de relacionamento entre o conhecimentodo dorninio e a qualidade da especifxca5o derequisitos gerada na lase de anaIise do problema.

6. ConclusAo

Com o aurnento da competitividade observadono mercado mundial, a melhoria da qualidade dosprodutos de software passou a ser n5o mais umdiferencial para a empresa desenvolvedora, masSim, um fator crftico para sua sobrevivncia. pastaforma, a tentativa de encontrar abordagens que

possibilitem a melhoria do processo dedesenvolvimento tern sido uma constante canto naacademia quanto na industria.

Neste artigo apresentamos tuna abordagem queinclui uma forma de escolha adequada de m6tricas,sua coleta de forma integrada ao pr6prio processoprodutivo, ana1ise dos resultados e sugest6es para amelhoria do processo de software baseado noconhecimento extraido de especialistas.

Atualmente, os trabalhos estiio concentrados naimplementa2o em prolog do sistema baseado emconbecimento que serti ntilizado para apolar a etapade andlise proposta nests abordagem. 0 sistemafinal devera ser integrado ao ambiente de definiAode processos, o TABA [17], de forma a compor aarLause da qualidade dos processos definidos nestaferramenta.

Referncias[IJ Oman P.. Pflegeer S.I , Applying Sofiware

Meln"cs~ Los Alamitos~ CA, IEEE Computer Society.[2} Park RE.. Goethert W.B", Florac W.A., Goal-

Driven SofrWare Measurement - A Guidebook,CMUISEI-96 HB-002, Pittsburgh, PA, SoftwareEngineering Institute Carnegie Mellon University~August 1996.

[3] Basin V.R., Caldiera G., Rombach H.D.. GoalQuestion Metric Paradigm, Encyclopedia of Sof1;wareEngineering, 2 Volume Set John Wiley & Sons, Inc,1994.

[4] Carleton A.D., Park R.E, Goethert W.B.. FloracW.A., Bailey E"K., Pfieeger S.L., Sofiware Measurementfor DOD Systems: Recommendation for Initial CoreMeasures, CMU/SEI-92-TR-19, ESC-TR-92-19,Pittsburgh, PA Software Engineering Institute, CarnegieMellon University, September 1992.

[5] Comte, S.D., Dunsmore, H.D., Shen. V.Y.,Sojtware Engineering Metrics and Models, Benjamin"Cummings. Menlo Park, CA, 1986 in [I:;ENTON 97}

[6] Daskalantonakis M.K", A Practz-cal V.zew ofSofiware Measurement and Implementation ExperiencesWz.thin Motorola, IEEE Tr"ansacu`on SoftwareEngineering, ̀Vol 18 No. 11, November 1992 in [OMAN97].

[71 Penton N.E., Pfleeger S.L, Sofiware Melrics - ARigorous & Practical Approach, Second Edition. Boston,MA.. PWS Publishing Company, 1997

[8] Plorac W.A., Software Quality Measurement: AFramework for Counting Problems, Failures and Faults,CMU/SEI-92-TR-22, ESC-TR- 92-22, Pittsburgh, PA,

` Sofcware Engineen`ng Institute, Carnegie MellonUnl.varsity, September 1992.

[9] Plorac W.A., Park R.E., Practical SoftwareMeasurement: Measun"ng for Process Management andImprovement, CMU/SEI-97-HB-Ofl3, Pittsburooh, PA.Software Enoaineering Insu'tute, Carnegie MellonUrn.versity April 1997.

[10} Goethert W.B., Bailey E.K., Busby M.B.,Sofiware Eort & Schedule Measurement: A Frame"workfor Counting Stag-hours and Reporting Schedule

76 / QuaTIC'2001

Informan"on, CMUISE192`TR-2I, ESC-TR-92-21,Pittsburgh, PA, Software Engineering Institute, CarnegieMellon University. September 1992.

[11] Park R-E.." Sofiware Sz.ze Measurement: AFramework for Count`mg Source Statements, CMUISEI-92-TR-20, ESC-TR-92-20, Pittsburgh. PA, SoftwareEngineering Institute. Carnegie Mellon University,September 1992.

[12] Roberts MA, Experiences in AnaLyzz`ngSoliware Inspeczz`on Data, Software Enfineering ProcessGroup, McDonnell Douglas Aerospace, McDonnellDouglas Corporation. St Louis. MO, May 1996 in[FLORAC 97}

[13] Tajima D., Matsubara T., The ComputerSofcware Industry in Japan.. IEEE Computer, 14(5)." 1981in [FENTON 97].

[14] Machado,L.F.C. et al DEF-PRO: UlnaFerramenta para Apoiar a Defmi50 do Processo Pado,XI CIfS . Curitiba Junho 2000

[I5] Fencon N.E,, Neil. M., Sojtware Metrics:Roadmap. Computer Science Departarnent. Queen Maryand Westfleld College." London. UK 2000.

[16] Sofiware Program Managers Network. -07Departrnem of the Navy (US). January 1995 in (71

[17] OlI" veira K.M Rocha A.R. Travassos G.."Menezes C.; Using Domain-Knowledge in SoftwareDevelopment Environments, Software Engineering andKnowledge Engineering SEKE 99; Kaiserlautern,Germany, July 1999.

QuaTIC 2001 / 77