requisitos de métodos de rastreabilidade entre os requisitos

8/7/2019 Requisitos de Mtodos de Rastreabilidade entre os Requisitos

1/27


2/27

generalizada [Neumller et al., 2006]. Conseqentemente, muitas empresas ainda registram asligaes de rastreabilidade (trace links ) manualmente, apesar das abordagens automticas esemi-automticas j estarem disponveis. Este artigo no discute de forma abrangente oproblema de rastreabilidade de requisitos, tal discusso pode ser encontrada, por exemplo, notrabalho de Gotel et al. (1994), concentramos nossa ateno nas ligaes de rastreabilidadeentre requisitos e cdigo de software, cuja importncia fica evidente no artigo de Antoniol etal. (2002).

Atualmente j existem diversos mtodos especializados em rastreabilidade com ocdigo de software, que podem ser agregados em categorias bases. Os artigos de Cleland-Huang et al. (2005) ou de Gotel (1994) so exemplos de formas de categorizao destesmtodos. Podemos, por exemplo, citar mtodos baseado em roteiros (scenario ), mtodosbaseados em modelos, mtodos baseados em recuperao de informao (information

retrieval ), mtodos baseados em semntica.Os maiores inibidores para o uso desses mtodos e ferramentas so, segundo

Neumller et al. (2006), a complexidade da rastreabilidade e o manuseio de um grandevolume de informao, que podemos traduzir como falta de aderncia com as necessidadesdas partes interessadas. Se um mtodo parece complexo para um usurio, porque o seudesenvolvedor no observou requisitos de usabilidade para o mtodo. Se h problemas emmanusear um grande volume de informao porque no foi observado requisitos deescalabilidade para o mtodo.

Deixar os mtodos mais aderentes s necessidades das partes interessadas, tem deser o foco dos pesquisadores em rastreabilidade de requisitos. Pohl (1996) deixa claro queos trs principais problemas do uso das ligaes de rastreabilidade so: Primeiro, o uso dasinformaes de rastreabilidade dependem da parte interessada e das atividades do processode desenvolvimento de software, isto , ligaes no so usadas como so gravadas e,consequentemente, recuperaes seletivas, de acordo com necessidades atuais tem de sersuportadas. Segundo, devido ao grande nmero de informaes produzidas durante oprocesso, apenas ligaes orientadas ao contedo so base para o uso apropriado, isto , ouso da informao gravada quase impossvel se as ligaes de rastreabilidade no estoencapsuladas em seus contextos. Terceiro, as pessoas envolvidas na captura das ligaes derastreabilidade so frequentemente diferentes dos usurios da informao.

1.2 Objetivo

Este artigo tem como objetivo apresentar um catlogo de requisitos para os mtodos derastreabilidade entre requisitos e cdigo de software, e assim contribuir para desenvolvimentode mtodos com melhor usabilidade e ajudar os profissionais na escolha de uma boaferramenta. O catlogo aqui apresentado pode alimentar um critrio objetivo de escolha deferramentas, pelo menos no que diz respeito s caractersticas da rastreabilidade entrerequisitos e cdigo.

No catalogamos requisitos para outros tipos de ligaes de rastreabilidade, porexemplo, ligaes de rastreabilidade horizontais (cdigo com cdigo, requisito com requisito),ligaes verticais com outros artefatos (requisito com modelos, requisitos com casos de teste).


3/27

Tambm no tratamos as ligaes de rastreabilidade com os requisitos pr-especificao (pre-requirements specification ), assim como Gotel et al. (1994) o definiu.

1.3 Partes interessadasEste catlogo de requisitos tem interesse para todos que, no ciclo de vida do projeto

de software, precisam usar a rastreabilidade entre requisitos e cdigo. Utilizamos o ProcessoUnificado [Jacobson, 1999] como fonte dos papis de trabalhadores e das atividades tcnicasque necessitam da rastreabilidade. Alm dessas, utilizamos o Rational Unified Process para adescrio dos papeis e das atividades que o Processo Unificado no cobre. Do artigo deAntoniol et al. (2002) obtivemos algumas descries j realizadas de atividades que utilizam arastreabilidade entre requisitos e cdigo para diversos trabalhadores do desenvolvimento desoftware.

Comeando com os programadores, percebe-se que muitas vezes precisam entendercdigos que no foram escritos por eles. Antoniol et al. (2002) mostram-nos queprogramadores usam diferentes tipos de conhecimento para a compreenso do programa,variando do conhecimento especfico do domnio at o conhecimento geral de programao.Ligaes de rastreabilidade entre reas especficas do cdigo e sees relacionadas emdocumentos de especificao de requisitos ajudam na compreenso da motivao efundamentao daquele trecho de cdigo analisado.

Analistas de Sistema, que tm a responsabilidade de modelar o sistema a partir dosrequisitos, tambm so responsveis por garantir a completeza da implementao. Para isso,usam as ligaes de rastreabilidade do tipo aqui tratado para localizar reas do cdigo quecontribuem na implementao de funcionalidades especficas [Pinheiro et al. 1996, Koncli etal., 1988 e Ramesh et al., 1992], e assim, verificar que o seu modelo est permitindo aimplementao dos requisitos indicados.

Projetistas de testes tambm aproveitam dessas ligaes para planejar casos de testescompletos e inferir a cobertura dos testes sobre os requisitos [Antoniol et al., 2002].

As ligaes so de grande uso durante a inspeo de cdigo, provendo aos revisoresas conexes entre o cdigo e os seus objetivos e na garantia da qualidade, observando acompleteza da implementao [Antoniol et al., 2002].

Gerentes de projetos precisam usar a rastreabilidade entre requisitos e cdigo naanlise de impacto de uma alterao no projeto. O gerente deve identificar os produtos detrabalho afetados pela alterao proposta [Arnold et al. (1993)]. Alteraes podeminicialmente afetar qualquer artefato do sistema e propagar-se por outros produtos de trabalho[Fyson, 1998 e Turver, 1994]. Como exemplo, a alterao que adiciona uma novafuncionalidade em um sistema , em muitos casos, iniciada alterando as especificaes derequisitos. As alteraes so ento propagadas at o cdigo fonte. O inverso tambm podeocorrer: uma alterao no algoritmo ou numa estrutura de dados inicia-se no cdigo fonte e ento documentada em sees relevantes do documento de desenho e pode at mesmo afetaralguns requisitos.

Arquitetos corporativos tm nas ligaes entre requisitos e cdigo uma sensvel ajudapara localizar componentes candidatos a reuso[Antoniol et al., 2002]. De fato, desde que


4/27

software freqentemente no so produzidos para o reuso de seus componentes, ligaes derastreabilidade entre cdigo e seus requisitos podem ser de grande ajuda para indexar osativos de acordo com o modelo de domnio da aplicao e implementar mecanismos de buscaque os trazem para uma potencial base de reuso.

Alm desses profissionais que participam do ciclo de vida do software, esse catlogotambm de interesse de pesquisadores da cincia da computao. Estes precisam dominar aquesto da rastreabilidade em todos os seus detalhes para buscarem uma soluo queenglobe os diversos aspectos do problema. O catlogo aqui mostrado sintetiza os requisitosde uma das dimenses da questo da rastreabilidade, sendo til para a criao de novosmtodos mais eficazes do que os j existentes.

Novas ferramentas de gerncia de requisitos podem ser desenvolvidas acrescentando sua lista de requisitos os aqui apresentados. A indstria de software carece de uma baseslida para fabricar ferramentas de gerncia de requisitos eficientes e de simples utilizao.Este catlogo pode ser usado como parte de requisitos de entrada para um projeto dedesenvolvimento de uma ferramenta de gerncia de requisitos.

Os desenvolvedores de ambientes de desenvolvimento de software (IDE ) podemtambm usar este catlogo como fonte de informao, caso queiram disponibilizar umaintegrao com ferramentas de gerncia de requisitos.

1.4 Critrios

A catalogao dos requisitos obedeceu a um critrio bem definido: primeiramente a

compilao dos requisitos que se aplicam rastreabilidade entre requisitos e cdigo extradosde normas e modelos de qualidade. Utilizamos o Chrissis (2007) para a extrao de requisitosa partir do CMMI e a especificao ISO/IEC 12207. O segundo passo foi a extrao derequisitos, que ainda no constava no catlogo, a partir das necessidades dos interessadoslistados acima, observadas nos processos de desenvolvimento de software baseados noprocesso unificado [Jacobson, 1999]. Depois utilizamos artigos que tratam da rastreabilidadede requisitos em geral. o caso do artigo Ramesh et al (1997).

Por fim, recorremos a artigos que tratam de mtodos para rastreabilidade entrecdigo fonte e outros artefatos. Fizemos uma ligao entre as caractersticas desses mtodose os requisitos j catalogados para se descobrir a motivao das caractersticas. Para aquelasem que a motivao no estava catalogada, avaliamos a universalidade da caracterstica paraidentificar se era ou no um novo requisito. Apresentamos aqui os artigos utilizados nestecritrio organizados por mtodo. Para mtodos baseado em roteiros (scenario ), utilizamos oartigo de Egyed et al. (2002) e o de Eisenbarth et al. (2003). Os trabalhos de Murphy (1995)e Antoniol (2000) para mtodos baseados em modelos. No caso de mtodos baseados emRecuperao de Informao (information retrieval ), Zhao et al. (2004). J para os mtodosbaseados em semntica, Collard (2002).

1.5 Estrutura do Catlogo

Este catlogo est estruturado usando trs nveis de hierarquia, seguindo os mesmos princpiosadotados por Hoffmann et al. (2004). O nvel mais alto o agrupamento das partes


5/27

interessadas. O segundo nvel contm um critrio, que especifica a forma que os requisitosdevem ser avaliados. O terceiro nvel composto de requisitos. Como os requisitos no sonecessariamente diferentes para cada interessado, sempre que duas partes interessadasdiferentes compartilharem o mesmo requisito, o mesmo descrito apenas para uma das partesinteressada, enquanto a outra possui uma referncia que aponta para o primeiro.

A classificao dos requisitos feita pelos verbos usados nas sentenas dosrequisitos, seguindo a tcnica MoSCoW , que define prioridades nas tarefas efetuadas.MoSCoW um acrnimo que representa:MUST have this.

SHOULD have this if at all possible.

COULD have this if it does not affect anything else.

WON'T have this time but WOULD like in the future.

Em portugus usamos:TEM de ter isto.DEVE ter isto, se for possvel.PODE ter isto, se no afetar o resto.NO TER isto agora, mas SERIA bom ter no futuro.

2. Modelos e caractersticas dos Mtodos de Rastreabilidade entre osRequisitos e o Cdigo de Software

Esta seo contm conceitos e modelos que caracterizam os mtodos de rastreabilidade entrerequisitos e cdigo de software e que so relevantes para o entendimento do catlogo.

Rastreabilidade de requisitos definida por Gotel et al. (1994), como sendo ahabilidade de descrever e seguir a vida de um requisito nos dois sentidos, de avano eretorno. A simplicidade dessa definio esconde a complexidade do problema. S o fato de arastreabilidade ser feita entre artefatos de naturezas distintas - requisitos, modelos de desenho(Design ) de software, cdigo fonte, casos de teste j torna improvvel o uso de um mesmomtodo para toda e qualquer rastreabilidade. A rastreabilidade entre um requisito de softwaree uma varivel de classe em um cdigo escrito em Java diferente na forma e no contedo deoutra rastreabilidade entre o mesmo requisito e uma associao em um diagrama UML. Umcdigo Java de natureza distinta de um modelo UML.

Ligao de Rastreabilidade (trace link ): o elemento que liga dois itensrastreveis. As ligaes de Rastreabilidade podem tambm ser de naturezas distintas. Umaligao de rastreabilidade normalmente liga dois itens bem definidos. Mas no caso darastreabilidade entre requisitos e cdigo possvel que os itens ligados no sejam bemdefinidos, mas estejam fragmentados e diludos em todo o cdigo, caracterizando uma forma

de ligao diferente da forma da primeira. o caso da ligao com alguns requisitos nofuncionais. O requisito registrar em arquivo qualquer mudana de estado do software um


6/27

exemplo. Ele pode no se ligar em uma rea bem definida e delimitada do cdigo, mas aimplementao que resolve o requisito pode estar fragmentada em todo o cdigo. Outro casode ligao de natureza distinta a ligao indireta. Um requisito pode interferir num cdigoatravs de um modelo de desenho. O projeto de uma soluo arquitetural pode ter suamotivao em um determinado requisito, e ento determinar a estrutura final do cdigo. Nessecaso, no h ligao direta entre o requisito e o cdigo, mas atravs do modelo de desenhoque representa a soluo arquitetural para o requisito e que refletida no cdigo. A ligao derastreabilidade entre o requisito e o cdigo, neste caso, possui caractersticas de indireo.

Unidade Computacional : Eisenbarth e tal (2003) definiram a UnidadeComputacional como uma parte executvel de um sistema. Exemplos de unidadescomputacionais so instrues (como acesso a variveis globais), blocos de cdigo bsicos,rotinas, classes, unidades de compilao, mdulos ou subsistemas. Para efeito de

simplificao, neste artigo, tambm ser includo o cdigo declarativo na definio de unidadecomputacional.Corte Funcional (Slice): o conjunto de Unidades Computacionais que podem

afetar um conjunto determinado de variveis [Beszdes, 2001]. Os algoritmos de cortepodem ser classificados como algoritmo paraCortar esttico (static slicing ), que usaapenas informaes estticas do cdigo para se obter o corte; e o algoritmo deCortardinmico (dynamic slicing ), que usa tambm valores de variveis que podem influenciar ocorte.

Item de Rastreabilidade (traceability item ): O termo definido por Spencer eProbasco (1998) como qualquer item textual ou item de modelo que precisa serexplicitamente rastreado para outro item textual ou item de modelo, para manter a trilha dedependncias entre eles.

Item de cdigo de rastreabilidade (ICR) : Quando o item de rastreabilidade foruma Unidade Computacional ou um Corte Funcional, pode ser designado genericamenteneste artigo por item de cdigo de rastreabilidade ou ICR.

Na figura 1 est exibido um meta-modelo para explicar melhor a diviso do cdigo desoftware. Os meta-modelos aqui apresentados, tanto dessa figura como das seguintes, nopretendem apresentar uma viso encerrada da rastreabilidade. Foram feitos apenas paraauxiliar no entendimento dos conceitos. Tm fins puramente didticos. So escritos em UML1.5 e mostram as relaes entre os conceitos utilizados no catlogo. No caso, a figura 1mostra a generalizao da Unidade Computacional e do Corte Funcional no Item de Cdigode Rastreabilidade (ICR), que, por sua fez, uma especializao do Item de Rastreabilidade.Tambm mostra, atravs de uma agregao, que um Corte Funcional composto de uma oumais Unidades Computacionais.


7/27

Item deRastreabilidade

Item de Cdigo deRastreabilidade (ICR)

Corte FuncionalUnidade Computacional*1..* *1..*

Figura 1. Meta-modelo Item de Rastreabilidade.

Diferente da opo de Ebner e Kaindl (2002), que representam as ligaes derastreabilidade em meta-modelos como associaes entre itens de rastreabilidade, nsoptamos por representar ligaes em forma de classes. Inspiramo-nos na definio de Jarke(1998), que diz que as ligaes so produtos da rastreabilidade, e como produtos tmidentidade e caractersticas bem definidas, e, portanto, devem ser representadas como

classes.A figura 2 mostra o meta-modelo das relaes das ligaes com as unidades

computacionais. Uma ligao de rastreabilidade pode ligar diversos requisitos a diversasUnidades Computacionais. A semntica da ligao no derivada diretamente dos itens queligam, mas o inverso, os itens de rastreabilidade so conseqncias de uma percepocognitiva. Jarke (1998) explica que desta percepo, uma ligao de rastreabilidade capturaobjetos conceituais e os liga de uma forma significativa. possvel que diversos requisitosjuntos tenham um significado nico e que esse significado seja a fundamentao de umaimplementao distribuda em diversas Unidades Computacionais. Assim, podemos alterarrequisitos ou Unidades Computacionais sem alterar a identidade da ligao, j que a idia, apercepo cognitiva, que fundamenta o cdigo pode se manter.


8/27

Constructo

RequisitoLigao de Rastreabilidade entre Requisito e

Unidade Computacional

1..*1..*

+IRR

1..*1..*

fundamenta

UnidadeComputacional

1..*

1..*

+ICR1..*

1..*

satisfaz

Composio de UnidadeComputacional

1..*

*

1..*

*

Figura 2. Ligao de Rastreabilidade entre Requisito e UnidadeComputacional.

Na figura 2 nota-se ainda a possibilidade de uma Unidade Computacional ser acomposio de diversas outras Unidades Computacionais que podem ser fundamentadas emligaes de rastreabilidade diferentes.

O meta-modelo das Ligaes de rastreabilidade entre Requisitos e o Corte Funcional,figura 3, mostra uma realidade diferente. Um requisito funcional tomado como base para aligao que satisfeita num nico corte funcional. Outros requisitos podem colaborar nafundamentao do cdigo, mas apenas um a base. O corte funcional composto pordiversas unidades computacionais, que podem ser fundamentas por outros requisitos.

Um tipo especial de rastreabilidade (Ligaes de rastreabilidade para alteraes)pode ser criado para melhor satisfazer uma prtica pedida pelo CMMI. Na descrio do itemSP 1.4 Manuteno da Rastreabilidade Bidirecional de Requisitos dito que arastreablilidade particularmente necessria na conduo da anlise de impacto dasalteraes de requisitos das atividades de projeto e produtos de trabalho Chrissis, (2007),pgina 492. Ligaes de rastreabilidade para alteraes facilitam a anlise e o histrico dasalteraes.

A figura 4 mostra as ligaes de Rastreabilidade entre Alterao e UnidadeComputacional. Uma alterao, quando realizada, toda mapeada por essa ligao: arequisio que a originou, os requisitos alterados e as unidades computacionais includas,alteradas e excludas.


9/27

Requisito NoFuncional


CorteFuncional

1..*

*

1..*

*

Requisito

RequisitoFuncional

Ligao de Rastreabilidade entreRequisito e Corte Funcional

1

1

+ICR1

+satisfaz1

* *

+colaboradores

*

+realizao* realizado em

1

1

+base

1

+codigo da realizao1define

Figura 3. Ligao de Rastreabilidade entre Requisitos e Corte Funcional.

Requisio deAlterao

Requisito*

*

+candidatos a alterao*

*

impacta


Ligao de Rastreabilidade entre Alterao eUnidade Computacional

1 0..1

+gatilho

1

+realizao

0..1

gera

*+alterado

*

alterao de requisito

*+adicionado

* *

+alterado

**

+removido

*

Figura 4. Ligao de Rastreabilidade entre Alterao e Unidade de Cdigo

importante ressaltar que uma ligao de rastreabilidade entre requisitos e cdigopode ser indireta. Os requisitos podem ser refinados em diferentes artefatos antes de alcanar

o cdigo fonte. Antoniol et al. (2000) dizem que Sistemas de software so desenvolvidosseguindo processos no qual a complexidade da engenharia de software atacada por meio desubseqentes atividades de refinamento. Analise de requisitos, projeto e codificao so fasesque esto presentes em quase todos os processos de desenvolvimento de software. Pode-seento pensar que os requisitos so sempre refinados em algum modelo de projeto, para entoserem implementados. O prprio Antoniol deixa claro que a realidade no essa: entretanto,a manuteno da consistncia entre os artefatos de software e uma atividade custosa etediosa, que freqentemente sacrificada durante o desenvolvimento e manuteno devido spresses do mercado. H requisitos que so implementados diretamente no cdigo e hrequisitos que passam por um projeto antes de serem implementados. Assim necessrio que

as ligaes entre requisitos e cdigo possam ser indiretas ou no. A figura 5 mostra, dentre


10/27

outras ligaes, a Ligao indireta, que uma composio de outras Ligaes deRastreabilidade.

Ligao de Rastreabilidade entre Requisito e Cdigo

Ligao de Rastreabilidade entre Alterao eUnidade Computacional

Ligao de Rastreabilidade entreRequisito e Corte Funcional

Ligao de Rastreabilidade entre Requisito eUnidade Computacional

Ligao deRastreabilidade

Ligao de Rastreabilidade Indiretaentre Requisito e Cdigo

1..*

*

1..*

*

Figura 5. Meta-modelo dos tipos de Ligao de Rastreabilidade.

As ligaes de rastreabilidade entre requisitos e cdigo de software podem serclassificadas quanto ao mbito ou quanto ao tipo de ligao.Classificao quanto ao mbito dos itens de cdigo de rastreabilidade (ICR) : Asligaes de rastreabilidade podem ser classificadas em funo da abrangncia que afundamentao exerce sob o ICR. Criamos esta classificao baseada naquela feita porEisenbarth et al (2003), pgina 218:Especfica : o item de cdigo existe somente por causa do requisito, que satisfeito somentepor este item de cdigo. Em outras palavras, o ICR fundamentado somente pelo requisito,que no fundamento de nenhum outro item de cdigo.Relevante : o item de cdigo fundamentado pelo requisito, mas tambm fundamentadopor outros requisitos.Especfica com condio : o item de cdigo existe somente por causa do requisito, que satisfeito somente por este item de cdigo em determinadas condies.Compartilhada : o item de cdigo existe somente por causa do requisito, mas outros itens decdigo tambm colaboram na sua implementao.Irrelevante : O item de cdigo irrelevante para o requisito.

A classificao quanto ao mbito depende exclusivamente das multiplicidades darelao da ligao com o requisito e com o ICR. A figura 2 mostra que, para ser especfica, aligao de rastreabilidade entre requisito e cdigo deve se associar a apenas um ICR e a um

Requisito. Assim temos que um nico requisito fundamenta um nico ICR.


11/27

Item de Cdigo de Rastreabilidade (ICR)

Requisito Ligao de Rastreabilidade entreRequisito e Cdigo

1+ICR 1

satisfaz

1

+IRR

1

fundamenta

Figura 6. Meta-modelo da ligao de rastreabilidade do tipo de Especfica

O que ligeiramente diferente da Ligao de Rastreabilidade Compartilhada, quepermite a um requisito seja satisfeito por diversos ICR.



2..*+ICR

2..*

satisfaz

1

+IRR

1

fundamenta

Figura 7. Meta-modelo da Ligao de Rastreabilidade Compartilhada.

J no caso da Ligao de Rastreabilidade Relevante, mais de um requisito fundamenta o ICR.



1+ICR 1

satisfaz

2..*

+IRR

2..*

fundamenta

Figura 8. Meta-modelo da Ligao de Rastreabilidade Relevante.


12/27

3. Requisitos

Esta seo contm o catlogo de requisitos para mtodos de rastreabilidade entre requisitos e

cdigo de software, do ponto de vista das partes interessadas.3.1 Requisitos de Programadores

Esta subseo descreve os critrios e seus requisitos dos mtodos de rastreabilidade entrerequisitos e cdigo que cobrem as necessidades do ponto de vista dos programadores.

3.1.1 Indicao da fundamentao do cdigo

O mtodo tem de registrar as ligaes de rastreabilidade entre cdigo (ICR) e requisitos queservem de base, no cdigo fonte, para a lgica desenvolvida, e assim fundamentam o cdigo.- O mtodo deve permitir que a ligao de rastreabilidade seja feita durante a atividade decodificao.- O mtodo deve informar quando novas Unidades Computacionais desenvolvidas podeminterferir em ligaes de rastreabilidade existentes. o caso de alteraes da classificaoquanto ao mbito de ligaes j existentes. Por exemplo: um ICR que era originalmenteEspecfico, com a nova Unidade Computacional, torna-se Compartilhado.- O mtodo deve ser o menos intrusivo possvel na codificao. A codificao deve ser regidapor padres e normas que visam uma melhor estruturao e entendimento do cdigo. Exigiruma forma de codificao para satisfazer um determinado mtodo pode conflitar com padresda organizao e prejudicar a inteligibilidade do cdigo. um recurso que deve serdesencorajado nos mtodos de rastreabilidade.- O mtodo tem de suportar Ligaes de Rastreabilidade Indireta, principalmente arastreabilidade entre cdigo e requisitos atravs de modelos de desenho (design ). Muitosrequisitos so realizados nas atividades de analise e desenho do sistema. Ao ser implementadoa partir de algum modelo, o cdigo est indiretamente realizando os requisitos que motivaramo modelo. O mtodo de rastreabilidade entre requisitos e cdigo deve somar estes requisitosaos outros que so diretamente realizados no cdigo.- O mtodo pode permitir que o programador indique os requisitos que fundamentam asUnidades Computacionais diretamente do ambiente de codificao, para no haverinterrupo no trabalho de programao. Isso pode ocorrer atravs da implementao domtodo diretamente na ferramenta de codificao ou via alguma integrao entre ferramentas.Fundamentao: Ramesh et al.(1997) dizem que a rastreabilidade facilita a compreenso dosprocessos por traz da criao dos artefatos. Durante a codificao, o programador utiliza osrequisitos, direta ou indiretamente, como base lgica para o desenvolvimento das UnidadesComputacionais. importante que o mtodo de rastreabilidade permita o registro dessainformao, j que, obt-la mais tarde, pode ser uma tarefa rdua.Tambm o modelo CMMI, na rea chave Desenvolvimento de Requisitos (RD), a metaespecfica 2, Desenvolver requisitos do produto, pede o registro da rastreabilidade dorequisito at funes e componentes do produto.


13/27

O mtodo proposto por Zhao et al. (2004) baseado em recuperao de informao (IR)lembra-nos da importncia da no interferncia na forma de codificao adotado naorganizao.

3.1.2 Compreenso do cdigo

O mtodo deve ajudar o programador, durante uma manuteno, no entendimento de cdigosque no foram escritos por eles. Deve permitir a anlise de discrepncias e buscar a clarezado cdigo [Ramesh et al., 1997]. A compreenso do cdigo, segundo alguns modeloscognitivos, pode ocorrer da forma ascendente (bottom-up ), isto , a partir de conceituaodetalhes de Unidades Computacionais, que serviro de base para conceitos cada vez maisabstratos; da forma descendente (top-down ), partindo de uma hiptese do funcionamento docdigo, que deve ser verificada junto aos Cortes Funcionais; ou alguma combinao das duasformas [Antoniol, 2002].- O mtodo deve permitir visualizar as Ligaes de Rastreabilidade entre um determinadorequisito funcional e os Cortes Funcionais de cdigo que o resolve. Assim o programadorque utiliza o modelo cognitivo descendente pode usar essa visualizao para, uma vez que ahiptese da estrutura das unidades computacionais tenha sido formulada, procurar por sinaisde sua confirmao ou negao nas ligaes de rastreabilidade.- O mtodo deve permitir uma visualizao das ligaes de rastreabilidade entre umadeterminada Unidade Computacional e os requisitos que a justifica. Assim, Na compreensoascendente, os programadores tm subsdios para atribuir conceitos s unidades de cdigo.

- O mtodo deve permitir uma visualizao das ligaes entre um determinado CorteFuncional e os requisitos funcionais. Essa visualizao ajuda, quando da utilizao dacompreenso ascendente, nos grupamentos das unidades de cdigo em conceitos maisabstratos.- As visualizaes podem mostrar a classificao quanto ao mbito da ligao. Caso o ICRseja classificado como Compartilhado, as visualizaes podem mostrar todos os ICR quejuntos resolvem o requisito. Caso seja classificado como Relevante, podem mostrar todos osrequisitos que fundamentam o ICR.- O mtodo pode capturar as ligaes dinamicamente, permitindo que qualquer alterao no

cdigo reflita imediatamente na rastreabilidade.Fundamentao: Os programadores usam diferentes tipos de conhecimento durante acompreenso do programa, variando do conhecimento especfico do domnio do sistema ato conhecimento geral de programao. Ligaes de rastreabilidade entre reas especficas docdigo e sesses relacionadas em documentos de especificao de requisitos ajudam nacompreenso tanto do modelo ascendente, como no descendente. Na compreensodescendente, uma vez que a hiptese tenha sido formulada, as ligaes de rastreabilidadesugerem onde se deve procurar por sinais de sua confirmao ou negao. Na compreensoascendente, o principal papel da rastreabilidade ajudar os programadores na atribuio deconceitos a pedaos de cdigo e no agrupamento desses pedaos em conceitos maisabstratos [Antoniol, 2002].


14/27


15/27

pelo projeto [Chrissis, 2007, pg. 491]. Isto porque, como Chrissis explica, essencialgerenciar as alteraes no projeto eficientemente.

3.2 Requisitos para Gerentes de ConfiguraoEsta subseo descreve os critrios e seus requisitos que cobrem as necessidades do pontode vista dos Gerentes de Configurao dos mtodos de rastreabilidade entre requisitos ecdigo.

3.2.1 Indexao

O mtodo tem de identificar cada unidade computacional, cada corte funcional, cada requisitoe as ligaes de rastreabilidade entre eles.- O mtodo tem de identificar unicamente cada Item de Rastreabilidade durante seu ciclo devida. Um item de rastreabilidade, especialmente o ICR, tem de receber uma identificaodurante sua criao que deve ser nica e no pode ser alterada durante as manutenes docdigo. A menos que a manuteno a descaracterize, e, portanto, a unidade deixa de existir,dando lugar a uma outra.- O mtodo tem de ser capaz de identificar Unidades Computacionais em diferentes nveis dedetalhe. Uma ligao pode ser feita utilizando tanto linha de cdigo, como mtodos, comoclasses ou subsistemas.- O mtodo tem de ser capaz de identificar unicamente Cortes Funcionais. Uma possvelforma utilizar como identificadores as entidades externas que o Corte Funcional afeta

diretamente. No so as Unidades Computacionais que compe um Corte Funcional que oidentificam, pois, estas Unidades podem ser alteradas sem que a identidade do corte sejaafetada.- O mtodo pode permitir que as Unidades Computacionais que compe um Corte possamvariar em nveis de detalhe, do mais detalhado para o menos detalhado, sem caracterizar umaalterao no corte. Um determinado mtodo, que faz parte de um corte, pode ser substitudopor sua classe sem que aja alguma alterao no corte.- O mtodo tem de identificar as Ligaes de Rastreabilidade e classifica-las quanto ao seutipo e mbito.

- O mtodo deve indexar ICR em linguagens de programao distintas, reconhecendo asUnidades Computacionais segundo os paradigmas de cada uma. Caso seja uma linguagemProcedural, Orientada a Objetos e at mesmo reconhecer mecanismos como Orientao aAspectos.- O mtodo deve reconhecer constructos de linguagens mais sofisticados, como ponteiro evnculos dinmicos (dynamic binding ).Fundamentao: para haver gerncia de configurao sobre as ligaes de rastreabilidade, importante que os componentes da rastreabilidade sejam identificados, s assim pode-seregistrar suas histrias nas ligaes. Pan et al. (2005) mostram esta necessidade.


16/27

O mtodo proposto por Collard et al. (2002) lembra-nos da importncia da identificao dasunidades computacionais sem interferir na estrutura do cdigo proposto pela organizao.

3.2.2 Gesto de configurao da rastreabilidadeAs ligaes de rastreabilidade tm de ser controladas na mesma linha de base dos artefatoscontrolados.- O mtodo tem de garantir a integridade das Ligaes de Rastreabilidade entre Alterao eUnidade Computacional. Sempre que uma alterao ocorrer num ICR, deve existir umaLigao de Rastreabilidade entre Alterao e Unidade Computacional que fundamenta aalterao. O mtodo pode garantir a integridade atravs de um relatrio de itens deRastreabilidade alterados que no possuem Ligao de Rastreabilidade entre Alterao eUnidade Computacional ou no permitir a alterao sem a indicao da Ligao.

- O mtodo tem de permitir a utilizao concorrente das Ligaes de Rastreabilidade e deseus itens. Tem de ser possvel o uso de trancas (lock ), e outros mecanismos de controle, nasLigaes de Rastreabilidade e em seus itens durante edies para quando se estivertrabalhando num ambiente distribudo de uso concorrente.- O mtodo tem de permitir que Ligaes de Rastreabilidade acompanhem as linhas de basedos itens de rastreabilidade que referenciam. Assim uma alterao num item deRastreabilidade que afete Ligaes de Rastreabilidade e a alterao Ligao derastreabilidade, s pode ser percebida por quem estiver utilizando a linha de base que os itense as ligaes fazem parte.

- As Ligaes de Rastreabilidade entre Alterao e Unidade Computacional devem poderreferenciar Itens de Rastreabilidade entre linhas de base. Apesar de fazer parte da linha debase mais atualizada, este tipo de Ligao de Rastreabilidade deve referenciar a versoanterior tanto do ICR como do Requisito, que fazem parte de linhas de base mais antigas.- O mtodo pode permitir que alteraes concorrentes, mas complementares, em ligaes derastreabilidade devam ser percebidas por seus executores, se possvel, durante suaelaborao. Essas alteraes ocorrem em colaborao, e o seu resultado deve ser liberadoem conjunto para integrao numa linha de base.- O mtodo tem de reconhecer conflitos em Ligaes de Rastreabilidade gerados poralteraes em Itens de Rastreabilidade executadas concorrentemente. Duas alteraesdiferentes numa mesma Unidade Computacional (ou em Unidades Computacionais diferentesque fazem parte de uma nica Unidade Computacional maior), que ocorreramconcorrentemente e foram fundidas durante a liberao, podem gerar alteraes nas suasfundamentaes (rastreabilidade com requisitos) que so incompatveis. Isto , o resultado dafuso das alteraes numa unidade computacional, no implica, necessariamente, na soma dasligaes de rastreabilidade alteradas.Fundamentao: As ligaes rastreabilidade tambm so itens de configurao e precisam sergerenciadas num ambiente de desenvolvimento distribudo e concorrente, assim como descritono CMMI (2006), Gerncia de Configurao, pgina 114.


17/27

3.3 Requisitos para Analistas de Sistema

Esta subseo descreve os critrios e seus requisitos que cobrem as necessidades do ponto

de vista dos analistas de sistemas dos mtodos de rastreabilidade entre requisitos e cdigo.Segundo o Processo Unificado, o analista de sistemas , dentre outras coisas, o responsvelpor desenvolver um plano de gerncia de requisitos e depois gerenciar as dependncias dosrequisitos com outros itens de rastreabilidade.

3.3.1 Acompanhamento do estado dos requisitos

O mtodo tem de permitir ao analista acompanhar a evoluo dos requisitos durante o seuciclo de vida, mostrando o estado de sua realizao.

- O mtodo tem de permitir a produo de relatrios de acompanhamento por requisito doproduto que, inferindo as ligaes de rastreabilidade entre requisitos e cdigo, quantifique acompleteza das realizaes dos requisitos. O analista no precisa conhecer as ligaes derastreabilidade entre requisitos e cdigo. As unidades computacionais e os cortes funcionaisso detalhes desnecessrios para suas atividades. Mas precisa destas informaes paraalimentar mtricas que indicam o estado de implementao dos requisitos. Seria interessanteque as medidas utilizadas nessas mtricas fossem coletadas de forma automtica, para pouparo custo de um trabalho de grandes propores. O mtodo deve permitir a gerao derelatrios com essas medidas e se possvel j com os clculos das mtricas.- O mtodo pode permitir, usando os ICR como base comum, a visualizao de relaesentre requisitos. Caso dois requisitos diferentes compartilhem sua realizao numa mesmaUnidade Computacional, h indcios de relao entre esses requisitos, que, a partir de umaanlise, pode levar a uma reavaliao da definio dos mesmos.- O mtodo pode capturar as ligaes dinamicamente, permitindo que qualquer alterao,criao ou remoo nos requisitos reflita imediatamente na rastreabilidade. Pode-se gerarnovas ou alterar Ligaes de Rastreabilidade a partir de criao e alterao em definies derequisitos.- O mtodo tem de garantir a integridade das ligaes. Pode ser feito atravs de verificao,gerando relatrio de inconsistncias ou no permitindo que a inconsistncia ocorra.Fundamentao: [Chrissis, 2007, pg. 491] a rea de processo gerencia de requisitos,prtica especfica 1.3 gerncia de alteraes de requisitos pede para que as alteraes dosrequisitos com as suas evolues durante o projeto sejam acompanhadas. O resultado daanalise da evoluo de um requisito insumo para verificao de sua consistncia, precisocompleteza e correo.

3.4 Projetistas de teste

Esta subseo descreve os critrios e seus requisitos dos mtodos de rastreabilidade entrerequisitos e cdigo que cobrem as necessidades do ponto de vista dos projetistas de teste.


18/27

3.4.1 Inferncia da cobertura do teste

O mtodo deve permitir ao projetista de teste obter informaes da cobertura dos casos de

teste.- A partir de um relatrio de execuo do software, o mtodo deve extrair os ICR e reportartodos os requisitos que se ligam a eles, classificados quanto ao mbito. Estes requisitos devemsatisfazer a necessidade do projetista de confirmar quais os requisitos esto sendo realmentetestados na execuo de cada caso de teste. Assim pode reavaliar o projeto dos testes parauma maior exatido.- O mtodo pode permitir uma visualizao do software com seus cortes funcionais e osrequisitos ligados a eles, para auxiliar na elaborao de testes funcionais.- O mtodo pode permitir a elaborao de um relatrio de referncia cruzada entre os cortes

funcionais e os requisitos no-funcionais, que ajudam na montagem de roteiros usados nostestes de requisitos no-funcionais.- O mtodo pode integrar com a ferramenta de automao de testes utilizada pelaorganizao. As visualizaes e relatrios descritos acima podem ser implementados naprpria ferramenta de automao de testes ou permitir a integrao com a mesma.Fundamentao: Segundo o Processo Unificado, o projetista de teste responsvel pelaintegridade do modelo teste, garantindo que cumpra seu papel. Alm disso, deve selecionar edescrever os casos de teste [Jacobson, 1998, pg. 303]. Para cumprir essas funes oprojetista precisa examinar os motivadores e itens alvos dos testes. Em outras palavras,

precisa conhecer as ligaes de rastreabilidade entre cdigo e os seus motivadores, osrequisitos.

3.5 Revisores Tcnicos

Esta subseo descreve os critrios e seus requisitos dos mtodos de rastreabilidade entrerequisitos e cdigo que cobrem as necessidades do ponto de vista dos Revisores Tcnicos.

3.5.1 Inspees tcnicas

O mtodo pode fornecer indicaes de melhores candidatos inspeo e a fundamentaode cada unidade computacional que inspecionada.- O mtodo pode fornecer um relatrio de ICR que se fundamentam em um nmero maior derequisitos. Estes itens tendem a ser mais complexas e crticos para o funcionamento dosoftware, e devem ser vistos como candidatos a inspeo.- O mtodo deve permitir a compreenso do cdigo pelo revisor [vide o critriocompreenso do cdigo pelos programadores].Fundamentao: [Chrissis, 2007, pg. 580] mostra que a verificao uma rea chave doCMMI, e que a inspeo uma forma de reviso por pares, que por sua vez o mecanismo

mais importante da verificao. Na pgina 583, [Chrissis, 2007] apresenta a sub-prticaidentificar os requisitos satisfeitos por cada produto de trabalho selecionado. Ele ainda


19/27

aponta para a prtica especfica de Manter a Rastreabilidade bidirecional de requisitos narea chave de processo de gerencia de requisitos para ajudar a identificar os requisitos paracada produto de trabalho. A inspeo de cdigo normalmente ocorre por amostragem. Aseleo do cdigo a ser analisado deve seguir critrios objetivos e eficientes. Tambm necessrio que o revisor compreenda o cdigo analisado sob o ponto de vista dos requisitos.

3.6 Gerentes de Projeto

Esta subseo descreve os critrios e seus requisitos dos mtodos de rastreabilidade entrerequisitos e cdigo que cobrem as necessidades do ponto de vista dos Gerentes de Projeto.

3.6.1 Anlise de Impacto de alteraes que afetam primeiramente osrequisitos

O mtodo tem de dar subsdios na anlise de impacto de uma alterao no projeto.- O mtodo tem de, a partir de uma requisio de alterao, gerar um relatrio com oresultado de alguma mtrica que mostre a quantidade e a complexidade dos ICR envolvidos eo seu grau de envolvimento com a alterao. Observe que neste momento no h ainda umaLigao de Rastreabilidade entre Alterao e Unidade Computacional, pois a alterao nofoi realizada, apenas uma requisio que precisa ser analisada. O relatrio possvel atravsde um Ligao de Rastreabilidade Indireta: requisio de alterao que se liga com requisitos,que se ligam com ICR. O gerente do projeto precisa estimar custos e prazos para aprovar ourejeitar a alterao proposta.- O mtodo tem de, a partir de uma requisio de alterao, relatar os artefatos de cdigoque possuem as unidades computacionais envolvidas na alterao. O relatrio possvelatravs de um Ligao de Rastreabilidade Indireta: requisio de alterao que se liga comrequisitos, que se ligam com unidades computacionais que fazem parte de artefatos de cdigo.Os artefatos de cdigo so Unidades Computacionais tratados como unidades fsicas peloprocesso de desenvolvimento de software da corporao. O relatrio deve ser usado paracomplementar a lista de artefatos candidatos a alterao.Fundamentao: Alteraes podem inicialmente afetar qualquer artefato do sistema epropagar-se por outros produtos de trabalho [Fyson, 1998 e Turver, 1994]. O caso aquitratado para toda alterao que diz respeito alterao de requisitos. Como essa alteraodeve ser propagada para outros artefatos do projeto, provavelmente deve afetar tambm ocdigo. O mtodo de rastreabilidade entre requisitos e cdigo deve fornecer subsdios paraajudar na anlise de impacto desse tipo de alterao.

3.6.2 Anlise de Impacto de alteraes que afetam primeiramente o cdigo

- O mtodo tem de identificar os ICR envolvidos na alterao e gerar um relatrio com osrequisitos afetados, o que ajuda na anlise de impacto da alterao.- O mtodo pode identificar e relatar os Cortes Funcionais que utilizam as UnidadesComputacionais envolvidas na alterao, e assim, permitir uma anlise de impacto horizontal

no cdigo afetado.


20/27


21/27

como Especficas. Seguido das Especficas com Condio. Depois as Relevantes. E, por fim,as Compartilhadas. Os requisitos que so implementados em Unidades Computacionaisespecfica so mais facilmente isolados do resto do cdigo do que as outras, j que essasunidades so coesas do ponto de vista do requisito.Fundamentao: A extrao de ativos reusveis a partir de um sistema de software umanecessidade da indstria como descreve Caldiera e Basili (1991).Para se extrair ativos dereuso, a partir de software que no foram originalmente produzidos para o reuso de seuscomponentes, necessrio uma avaliao de quais unidades computacionais faro parte docomponente de reuso e o quanto estas unidades esto dependentes do restante do cdigo.

3.8 Gerente da Qualidade

Esta subseo descreve os critrios e seus requisitos dos mtodos de rastreabilidade entre

requisitos e cdigo que cobrem as necessidades do ponto de vista dos Gerentes daQualidade. Alguns processos, como o Rational Unified Process 2003, atribuem s atividadesaqui tratadas como pertencentes ao gerente de projetos. Como a norma NBR ISO/IEC12207:1998 pede que o processo de garantia da qualidade seja imparcial, e para isso, agarantia da qualidade necessita ter autoridade e autonomia organizacional, independente daspessoas diretamente responsveis pelo desenvolvimento do produto de software ou pelaexecuo do processo no projeto, por tudo isso, optamos por utilizar o papel de gerente daqualidade na execuo destas tarefas.

3.8.1 Gesto de Processos

O mtodo tem de conter a descrio das tarefas que compe fluxo de trabalho para a suautilizao.- O mtodo tem de indicar atividades com suas dependncias, trabalhadores, artefatos deinsumo e resultantes. Deve-se descrever a forma de utilizao do mtodo, e, para cadausurio, descrever as atividades que resolvem os requisitos mostrados neste catlogo. Assimo gerente da qualidade tem como inserir estas atividades no processo de desenvolvimento desoftware da empresa para que a utilizao do mtodo seja integrado s outras tarefas doprocesso.- O mtodo tem de indicar, caso exista, novos papeis para a aplicao do mtodo.- O mtodo tem de indicar, caso exista, dependncias com atividades no definidas pelomtodo. Um apontamento para a definio da atividade deve ser feita. Por exemplo, caso omtodo exija a descrio e execuo de casos de teste assim como definido pelo ProcessoUnificado, deve apontar para a descrio desta atividade no Processo Unificado.- O mtodo pode trazer guias de implantao e customizao, para facilitar sua implantaonuma empresa.Fundamentao: Para se aplicar um mtodo de rastreabilidade entre requisitos e cdigo podeser necessrio a criao de novas atividades, artefatos e perfis no processo, o mtodoapresentado por Eisenbarth e tal. (2003) um exemplo. Caso isso ocorra, esses elementosdevem estar bem articulados com o restante do processo da organizao. O CMMI descritopor [Chrissis, 2007] na pg. 165, na prtica genrica GP 3.1, estabelecer um processo


22/27


23/27

- Relevncia: O mtodo tem de manter apenas as ligaes de rastreabilidade de interesse daspartes envolvidas.

O mtodo tem de satisfazer os requisitos de eficincia:- Comportamento Temporal: o mtodo tem de, na sua utilizao pelas partes interessadas,apresentar os resultados em tempos adequados. Estes tempos devem ser definidos pelaequipe de qualidade de cada organizao.- Utilizao de recursos: o mtodo tem de, na sua utilizao pelas partes interessadas, utilizarum nmero apropriado de recursos. Esses nmeros devem ser definidos pela equipe dequalidade de cada organizao.O mtodo tem de satisfazer os requisitos de manutenibilidade:- Analisabilidade: As ligaes de rastreabilidade resultantes das operaes feitas pelo mtodotm de permitir uma anlise para diagnosticar deficincias ou falhas nas operaes.- Modificabilidade: O mtodo tem de permitir manutenes nas ligaes de rastreabilidadepara corrigir problemas nas operaes, melhorias no resultado ou adaptaes alteraes noambiente.- Estabilidade: As ligaes de rastreabilidade tm de ser imunes a efeitos inesperados devidos modificaes no mtodo.- Testabilidade: As ligaes de rastreabilidade resultantes das operaes do mtodo tm depermitir sua validao.

O mtodo tem de satisfazer os requisitos de portabilidade:- Adaptabilidade: O mtodo pode ser adaptvel a diversas linguagens, ferramentas, e formasde armazenar requisitos.- Instalabilidade: O mtodo deve poder ser implementado no ambiente no qual ele se propea funcionar.- Co-existncia: o mtodo tem de ser capaz de co-existir com outros mtodos que oprocesso da organizao adota e compartilhar artefatos com estes mtodos.- Repetibilidade: Dado uma linha de base dos requisitos e uma linha de base do produto o

mtodo tem de gerar sempre o mesmo conjunto de ligaes de rastreabilidade entre osrequisitos e o cdigo.

Fundamentao: Como o mtodo de rastreabilidade entre requisitos e cdigo um produtode software, os requisitos de qualidade que os gestores de qualidade devem observar so oslistados na norma ISO 9126.

4. Aspectos prticos e operacionais

De acordo com os requisitos identificados para os mtodos de rastreabilidade entre requisitos

e cdigo, os seguintes aspectos prticos e operacionais relacionados sua definio e suautilizao podem ser apontados e/ou sugeridos:


24/27

- Os mtodos especializados em rastreabilidade com o cdigo de software jexistentes e que no cobrem todos os requisitos aqui mostrados podem e devem ser usados,em conjunto com outros mtodos, numa composio articulada de um mtodo maisabrangente.

- Os mtodos que se prope resolver a rastreabilidade entre requisitos e cdigodevem mostrar como implementam cada um dos requisitos aqui mostrados.

- Diversos requisitos pedem formas diferentes de visualizaes das rastreabilidade.Aconselhamos o uso de mecanismos de visualizao grfica, por permitirem inteligibilidade emuma consulta com um grande volume de informao. Um bom exemplo o uso da grade deconceitos (Concept Lattice ) proposto por Einsenbarth (2003).

- Mecanismos de gerncia de configurao que reconhecem UnidadesComputacionais e Cortes Funcionais ajudam bastante na implementao do mtodo. Umexemplo o mtodo de gerncia de configurao proposto por Nguyen et al. (2005).

- Uso de hipertextos so bem vindos nas integraes com ferramentas de trabalho,como o proposto por Munson (2005).

- O catlogo aqui apresentado cobre apenas uma parte do problema derastreabilidade. Precisa ser complementado com requisitos para todos os outros tipos derastreabilidade. A rastreabilidade horizontal entre Unidades Computacionais especialmenteimportante. Tambm necessrio o vinculo do cdigo com a rastreabilidade pr-especificao de requisitos.

- A importncia dos requisitos pode variar de acordo com o tamanho da organizaoe do nvel de maturidade do processo por ela utilizada.- Confrontar este catlogo com os mtodos de rastreabilidade entre requisitos e

cdigo, pode fornecer um ndice de aderncia dos mtodos com as necessidades das partesinteressadas,e funcionar como critrio objetivo na escolha de um mtodo.

5. Concluso

Apresentamos o catlogo de requisitos para mtodos de rastreabilidade entre requisitos e

cdigo de software, do ponto de vista das partes interessadas, com a finalidade de contribuirno desenvolvimento de mtodos mais eficazes: que ocultem sua complexidade de usurios queno precisam conhec-la; que sejam focadas no uso, no na tecnologia. Este catlogo no para ser usado apenas por pesquisadores e desenvolvedores de mtodos, mas tambm poraqueles que montam os processos de desenvolvimento de software numa organizao. Estespodem usar o catlogo como critrio objetivo na escolha do mtodo mais adequado suasnecessidades.

O catlogo no tem a pretenso de ser uma viso encerrada sobre o assunto, mas deser um ponto de partida para a discusso dos requisitos bsicos que possam tornar arastreabilidade vivel nas organizaes. Assim, deve sofrer revises peridicas com o avanoda discusso e mudanas tecnolgicas.


25/27

Os principais requisitos vieram de modelos e normas de qualidade (modelo CMMI,especificao ISO/IEC 12207), observados do ponto de vista das partes interessadas.Acreditamos assim ter construdo um catlogo funcional e confivel.

Mesmo sabendo que o escopo desse trabalho bastante limitado, esperamos tercontribudo para o efetivo uso da rastreabilidade no desenvolvimento de software.

Referncias

Antoniol, G., Caprile, B., Potrich, A., Tonella, P. (2000) "Design-code traceability for object-oriented systems", Annals of Software Engineering 9, p. 3558.

Antoniol, G., Canfora, G., Casazza, G., De Lucia, A. e Merlo, E. (2002) "Recovering

Traceability Links between Code and Documentation", IEEE Transactions on SoftwareEngineering, volume 28, nmero10.Antoniol, G., Merlo, E., Guhneuc, Y., Sahraoui, H. (2005) On Feature Traceability in

Object Oriented Programs, TEFSE05 - Traceability in Emerging Forms of SoftwareEngineering.

Arnold, R. e Bohner, S. (1993) Impact Analisys Towards a Framework for Comparison,International Conference Software Maintenance, p. 292-301.

Caldiera, G.; e Basili, V.R. (1991) Identifying and qualifying reusable software componentsIEEE Computer, volume 24, nmero 2, Pag.:61 70

Cleland-Huang, J. (2005) Toward improved traceability of non-functional requirements,proferido no 3o. International Workshop on Traceability in Emerging Forms of SoftwareEngineering, em conjunto com Automated Software Engineering ASE 2005.

CMMI Product Team (2006) CMMI for Development, Version 1.2, Software EngineeringInstitute of Carnegie Mellon University.

Collard, M., Maletic e J., Marcus, A. (2002) "Supporting Document and Data Views of Source Code", Proceedings of the 2002 ACM symposium on Document engineering.

Ebner, G., Kaindl, H. (2002) Tracing All Around in Reengineering, IEEE Software, volume

19, nmero 3, pginas 70-77.Egyed, A., Grnbacher, P. (2002) "Automating Requirements Traceability: Beyond Record &

Replay Paradigm", Conference on Automated Software Engineering, 2002. Proceedings.ASE 2002. 17th IEEE International.

Eisenbarth, T., Koschke, R., Simon, D. (2003) "Locating Features in Source Code", IEEETransactions On Software Engineering, volume. 29, nmero 3.

Hoffmann, M., Khn, N., Weber, M., Bitter, M. (2004) Requirements for RequirementsManagement Tools, 12o. IEEE International Requirements Engineering Conference.

Fyson,, M. e Boldyreff, C. (1998) Using Application Understanding to Support ImpactAnalysis, Journal Software Maintenance Research and Practice, volume 10, p.93-110.


26/27

Gotel O. e Finkelstein C. (1994) An analysis of the requirements traceability problem,Proceedings of the First International Conference on Requirements Engineering (IEEE).

Jacobson, I., Booch, G., Rumbaugh, J. (1999) The Unified Software Development Process,Addison Wesley, 1a edio.Jarke, M. (1998) Requirements Tracing, Communications of the ACM, volume 41, nmero

12.Koncli, J. e Bergen, M. (1988) Gibis: A Hypertext Tool for Exploratory Policy Discussion,

ACM Trans. Office Information System, volume 6, no. 4, p. 303-331.Munson, E., Nguyen, T. (2005) Concordance, conformance, versions, and traceability,

Automated Software Engineering, Proceedings of the 3rd international workshop onTraceability in emerging forms of software engineering, pag. 62-66.

Murphy, G e Sullivan, D. (1995) Software reflexion models: bridging the gap between sourceand high-level models, Proceedings of the 3rd ACM SIGSOFT symposium onFoundations of software engineering.

Neumller, C., Grnbacher, P. (2006) Automating Software Traceability in Very SmallCompanies: A Case Study and Lessons Learned, 21st IEEE International Conference onAutomated Software Engineering (ASE'06).

Nguyen, T., Munson, E., Boyland, J. (2005) An infrastructure for development of object-oriented, multi-level configuration management services, Proceedings of the 27thinternational conference on Software engineering.

Pan, Kai, Whitehead , E. James, Jr. e Ge, Guozheng (2005) Textual and Behavioral Viewsof Function Changes, Automated Software Engineering, Proceedings of the 3rdinternational workshop on Traceability in emerging forms of software engineering, LongBeach, California.

Pinheiro, F., Goguen, J. (1996) An object-Oriented Tool for Tracing Requirements, IEEESoftware, vol. 13, no. 2, p. 52-64.

Pohl, k., (1996) PRO- ART : Enabling Requirements Pre-Traceability, IEEE InternationalRequirements Engineering Conference.

Ramesh, B., Stubbs, C. e Powers, T. (1997) Requirements traceability: Theory andpractice, In: Annals of Software Engineering 3, p. 397415. J.C. Baltzer AG, SciencePublishers.

Ramesh, B. e Dhar, V. (1992) Supportin Systems Development Using Knowledge CapturedDuring Requirements Engineering, IEEE Trans. Software Eng., volume 9, no. 2, p.498-510.

Spence, I. e Probasco, L. (1998) Traceability Studies for Managing Requirements with UseCases http://www.uml.org.cn/RequirementProject/pdf/traceability.pdf

Turver, R. e Munro, M. (1994) Na Early impact Analisys Techique for SoftwareMaintenance, Journal Software Maintenance Research and Practice, volume 6, no. 1,p.35-52.


27/27

Zhao, W., Zhang, L., Liu, Y., Sun, J., Yang, F. (2004) "SNIAFL: Towards a Static Non-Interactive Approach to Feature Location", Proceedings of the 26th InternationalConference on Software Engineering (ICSE'04).

requisitos de métodos de rastreabilidade entre os requisitos

Documents