Requisitos de Métodos de Rastreabilidade entre os Requisitos
e o Código de Software
Pedro L. R. Leal Jr1
1
Departamento da Ciência da Computação – Universidade Federal de Minas Gerais (UFMG) - Av. Antônio Carlos, 6627 - Pampulha - Belo Horizonte - MG
Pedro.leal.junior@gmail.com
Abstract. The practices of requirements traceability, which exist to ensure compliance with their software requirements, don’t have a systematic use in most companies. This is because existing methods so far failed to meet stakeholders in all their needs [Neumüller et al., 2006] [Antoniol et al., 2005]. On that basis, we present here a list of requirements for methods of traceability between requirements and code of software, from the point of view of stakeholders. We hope thus to contribute to the development of more effective methods: not seem complex to its users; covering the entire scope of the needs of stakeholders; they are focused on the use, not technology.
Resumo. As práticas de rastreabilidade de requisitos, que existem para garantir a conformidade do software com os seus requisitos, não conseguem ter um uso sistematizado na maioria das empresas. Isto ocorre porque os métodos existentes até então falharam em satisfazer as partes interessadas em todas as suas necessidades [Neumüller et al., 2006] [Antoniol et al., 2005]. Com base nisso, apresentamos neste artigo um catálogo de requisitos para métodos de rastreabilidade entre requisitos e código, do ponto de vista das partes interessadas. Esperamos assim contribuir para o desenvolvimento de métodos mais eficazes: que não pareçam complexos para seus usuários; cubram todo o escopo das necessidades das partes interessadas; que sejam focadas no uso, não na tecnologia.
1. Introdução
1.1 Contextualização
A garantia da conformidade do software com os seus requisitos é uma exigência básica da indústria de desenvolvimento de software, mas nem sempre é alcançada. Com o objetivo de resolver esse problema, surgiram as práticas de Rastreabilidade de Requisitos, que, apesar de já serem utilizadas há alguns anos, códigos fonte freqüentemente evoluem sem a atualização dos requisitos [Ramesh et al. 1997]. Isso ocorre porque manter a consistência e a rastreabilidade entre abstrações de alto-nível, funcionalidades e componentes de software é custoso e consome tempo [Antoniol et al. 2005]. Tentando minimizar esse problema, pesquisadores e a indústria de software desenvolveram diferentes métodos e ferramentas para aperfeiçoar a gerência de requisitos. Mas infelizmente falharam em alcançar uma adoção
generalizada [Neumüller et al., 2006]. Conseqüentemente, muitas empresas ainda registram as ligações de rastreabilidade (trace links) manualmente, apesar das abordagens automáticas e semi-automáticas já estarem disponíveis. Este artigo não discute de forma abrangente o problema de rastreabilidade de requisitos, tal discussão pode ser encontrada, por exemplo, no trabalho de Gotel et al. (1994), concentramos nossa atenção nas ligações de rastreabilidade entre requisitos e código de software, cuja importância fica evidente no artigo de Antoniol et al. (2002).
Atualmente já existem diversos métodos especializados em rastreabilidade com o código de software, que podem ser agregados em categorias bases. Os artigos de Cleland-Huang et al. (2005) ou de Gotel (1994) são exemplos de formas de categorização destes métodos. Podemos, por exemplo, citar métodos baseado em roteiros (scenario), métodos baseados em modelos, métodos baseados em recuperação de informação (information
retrieval), métodos baseados em semântica.
Os maiores inibidores para o uso desses métodos e ferramentas são, segundo Neumüller et al. (2006), a complexidade da rastreabilidade e o manuseio de um grande volume de informação, que podemos traduzir como falta de aderência com as necessidades das partes interessadas. Se um método parece complexo para um usuário, é porque o seu desenvolvedor não observou requisitos de usabilidade para o método. Se há problemas em manusear um grande volume de informação é porque não foi observado requisitos de escalabilidade para o método.
Deixar os métodos mais aderentes às necessidades das partes interessadas, tem de ser o foco dos pesquisadores em rastreabilidade de requisitos. Pohl (1996) deixa claro que “os três principais problemas do uso das ligações de rastreabilidade são: Primeiro, o uso das informações de rastreabilidade dependem da parte interessada e das atividades do processo de desenvolvimento de software, isto é, ligações não são usadas como são gravadas e, consequentemente, recuperações seletivas, de acordo com necessidades atuais tem de ser suportadas. Segundo, devido ao grande número de informações produzidas durante o processo, apenas ligações orientadas ao conteúdo são base para o uso apropriado, isto é, o uso da informação gravada é quase impossível se as ligações de rastreabilidade não estão encapsuladas em seus contextos. Terceiro, as pessoas envolvidas na captura das ligações de rastreabilidade são frequentemente diferentes dos usuários da informação”.
1.2 Objetivo
Este artigo tem como objetivo apresentar um catálogo de requisitos para os métodos de rastreabilidade entre requisitos e código de software, e assim contribuir para desenvolvimento de métodos com melhor usabilidade e ajudar os profissionais na escolha de uma boa ferramenta. O catálogo aqui apresentado pode alimentar um critério objetivo de escolha de ferramentas, pelo menos no que diz respeito às características da rastreabilidade entre requisitos e código.
Não catalogamos requisitos para outros tipos de ligações de rastreabilidade, por exemplo, ligações de rastreabilidade horizontais (código com código, requisito com requisito), ligações verticais com outros artefatos (requisito com modelos, requisitos com casos de teste).
Também não tratamos as ligações de rastreabilidade com os requisitos pré-especificação (pre-requirements specification), assim como Gotel et al. (1994) o definiu.
1.3 Partes interessadas
Este catálogo de requisitos tem interesse para todos que, no ciclo de vida do projeto de software, precisam usar a rastreabilidade entre requisitos e código. Utilizamos o Processo Unificado [Jacobson, 1999] como fonte dos papéis de trabalhadores e das atividades técnicas que necessitam da rastreabilidade. Além dessas, utilizamos o Rational Unified Process para a descrição dos papeis e das atividades que o Processo Unificado não cobre. Do artigo de Antoniol et al. (2002) obtivemos algumas descrições já realizadas de atividades que utilizam a rastreabilidade entre requisitos e código para diversos trabalhadores do desenvolvimento de software.
Começando com os programadores, percebe-se que muitas vezes precisam entender códigos que não foram escritos por eles. Antoniol et al. (2002) mostram-nos que programadores usam diferentes tipos de conhecimento para a compreensão do programa, variando do conhecimento específico do domínio até o conhecimento geral de programação. Ligações de rastreabilidade entre áreas específicas do código e seções relacionadas em documentos de especificação de requisitos ajudam na compreensão da motivação e fundamentação daquele trecho de código analisado.
Analistas de Sistema, que têm a responsabilidade de modelar o sistema a partir dos requisitos, também são responsáveis por garantir a completeza da implementação. Para isso, usam as ligações de rastreabilidade do tipo aqui tratado para localizar áreas do código que contribuem na implementação de funcionalidades específicas [Pinheiro et al. 1996, Koncli et al., 1988 e Ramesh et al., 1992], e assim, verificar que o seu modelo está permitindo a implementação dos requisitos indicados.
Projetistas de testes também aproveitam dessas ligações para planejar casos de testes completos e inferir a cobertura dos testes sobre os requisitos [Antoniol et al., 2002].
As ligações são de grande uso durante a inspeção de código, provendo aos revisores as conexões entre o código e os seus objetivos e na garantia da qualidade, observando a completeza da implementação [Antoniol et al., 2002].
Gerentes de projetos precisam usar a rastreabilidade entre requisitos e código na análise de impacto de uma alteração no projeto. O gerente deve identificar os produtos de trabalho afetados pela alteração proposta [Arnold et al. (1993)]. Alterações podem inicialmente afetar qualquer artefato do sistema e propagar-se por outros produtos de trabalho [Fyson, 1998 e Turver, 1994]. Como exemplo, a alteração que adiciona uma nova funcionalidade em um sistema é, em muitos casos, iniciada alterando as especificações de requisitos. As alterações são então propagadas até o código fonte. O inverso também pode ocorrer: uma alteração no algoritmo ou numa estrutura de dados inicia-se no código fonte e é então documentada em seções relevantes do documento de desenho e pode até mesmo afetar alguns requisitos.
Arquitetos corporativos têm nas ligações entre requisitos e código uma sensível ajuda para localizar componentes candidatos a reuso[Antoniol et al., 2002]. De fato, desde que
software freqüentemente não são produzidos para o reuso de seus componentes, ligações de rastreabilidade entre código e seus requisitos podem ser de grande ajuda para indexar os ativos de acordo com o modelo de domínio da aplicação e implementar mecanismos de busca que os trazem para uma potencial base de reuso.
Além desses profissionais que participam do ciclo de vida do software, esse catálogo também é de interesse de pesquisadores da ciência da computação. Estes precisam dominar a questão da rastreabilidade em todos os seus detalhes para buscarem uma solução que englobe os diversos aspectos do problema. O catálogo aqui mostrado sintetiza os requisitos de uma das dimensões da questão da rastreabilidade, sendo útil para a criação de novos métodos mais eficazes do que os já existentes.
Novas ferramentas de gerência de requisitos podem ser desenvolvidas acrescentando à sua lista de requisitos os aqui apresentados. A indústria de software carece de uma base sólida para fabricar ferramentas de gerência de requisitos eficientes e de simples utilização. Este catálogo pode ser usado como parte de requisitos de entrada para um projeto de desenvolvimento de uma ferramenta de gerência de requisitos.
Os desenvolvedores de ambientes de desenvolvimento de software (IDE) podem também usar este catálogo como fonte de informação, caso queiram disponibilizar uma integração com ferramentas de gerência de requisitos.
1.4 Critérios
A catalogação dos requisitos obedeceu a um critério bem definido: primeiramente a compilação dos requisitos que se aplicam à rastreabilidade entre requisitos e código extraídos de normas e modelos de qualidade. Utilizamos o Chrissis (2007) para a extração de requisitos a partir do CMMI e a especificação ISO/IEC 12207. O segundo passo foi a extração de requisitos, que ainda não constava no catálogo, a partir das necessidades dos interessados listados acima, observadas nos processos de desenvolvimento de software baseados no processo unificado [Jacobson, 1999]. Depois utilizamos artigos que tratam da rastreabilidade de requisitos em geral. É o caso do artigo Ramesh et al (1997).
Por fim, recorremos a artigos que tratam de métodos para rastreabilidade entre código fonte e outros artefatos. Fizemos uma ligação entre as características desses métodos e os requisitos já catalogados para se descobrir a motivação das características. Para aquelas em que a motivação não estava catalogada, avaliamos a universalidade da característica para identificar se era ou não um novo requisito. Apresentamos aqui os artigos utilizados neste critério organizados por método. Para métodos baseado em roteiros (scenario), utilizamos o artigo de Egyed et al. (2002) e o de Eisenbarth et al. (2003). Os trabalhos de Murphy (1995) e Antoniol (2000) para métodos baseados em modelos. No caso de métodos baseados em Recuperação de Informação (information retrieval), Zhao et al. (2004). Já para os métodos baseados em semântica, Collard (2002).
1.5 Estrutura do Catálogo
Este catálogo está estruturado usando três níveis de hierarquia, seguindo os mesmos princípios adotados por Hoffmann et al. (2004). O nível mais alto é o agrupamento das partes
interessadas. O segundo nível contém um critério, que especifica a forma que os requisitos devem ser avaliados. O terceiro nível é composto de requisitos. Como os requisitos não são necessariamente diferentes para cada interessado, sempre que duas partes interessadas diferentes compartilharem o mesmo requisito, o mesmo é descrito apenas para uma das partes interessada, enquanto a outra possui uma referência que aponta para o primeiro.
A classificação dos requisitos é feita pelos verbos usados nas sentenças dos requisitos, seguindo a técnica “MoSCoW”, que define prioridades nas tarefas efetuadas. “MoSCoW” é um acrônimo 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 português usamos: TEM de ter isto.
DEVE ter isto, se for possível. PODE ter isto, se não afetar o resto.
NÃO TERÁ isto agora, mas SERIA bom ter no futuro.
2. Modelos e características dos Métodos de Rastreabilidade entre os Requisitos e o Código de Software
Esta seção contém conceitos e modelos que caracterizam os métodos de rastreabilidade entre requisitos e código de software e que são relevantes para o entendimento do catálogo.
Rastreabilidade de requisitos é definida por Gotel et al. (1994), como sendo a habilidade de descrever e seguir a vida de um requisito nos dois sentidos, de avanço e retorno. A simplicidade dessa definição esconde a complexidade do problema. Só o fato de a rastreabilidade ser feita entre artefatos de naturezas distintas - requisitos, modelos de desenho (Design) de software, código fonte, casos de teste – já torna improvável o uso de um mesmo método para toda e qualquer rastreabilidade. A rastreabilidade entre um requisito de software e uma variável de classe em um código escrito em Java é diferente na forma e no conteúdo de outra rastreabilidade entre o mesmo requisito e uma associação em um diagrama UML. Um código Java é de natureza distinta de um modelo UML.
Ligação de Rastreabilidade (trace link): é o elemento que liga dois itens rastreáveis. As ligações de Rastreabilidade podem também ser de naturezas distintas. Uma ligação de rastreabilidade normalmente liga dois itens bem definidos. Mas no caso da rastreabilidade entre requisitos e código é possível que os itens ligados não sejam bem definidos, mas estejam fragmentados e diluídos em todo o código, caracterizando uma forma de ligação diferente da forma da primeira. É o caso da ligação com alguns requisitos não funcionais. O requisito “registrar em arquivo qualquer mudança de estado do software” é um
exemplo. Ele pode não se ligar em uma área bem definida e delimitada do código, mas a implementação que resolve o requisito pode estar fragmentada em todo o código. Outro caso de ligação de natureza distinta é a ligação indireta. Um requisito pode interferir num código através de um modelo de desenho. O projeto de uma solução arquitetural pode ter sua motivação em um determinado requisito, e então determinar a estrutura final do código. Nesse caso, não há ligação direta entre o requisito e o código, mas através do modelo de desenho que representa a solução arquitetural para o requisito e que é refletida no código. A ligação de rastreabilidade entre o requisito e o código, neste caso, possui características de indireção.
Unidade Computacional: Eisenbarth e tal (2003) definiram a Unidade Computacional como uma parte executável de um sistema. Exemplos de unidades computacionais são instruções (como acesso a variáveis globais), blocos de código básicos, rotinas, classes, unidades de compilação, módulos ou subsistemas. Para efeito de simplificação, neste artigo, também será incluído o código declarativo na definição de unidade computacional.
Corte Funcional (Slice): é o conjunto de Unidades Computacionais que podem afetar um conjunto determinado de variáveis [Beszédes, 2001]. Os algoritmos de corte podem ser classificados como algoritmo para Cortar estático (static slicing), que usa apenas informações estáticas do código para se obter o corte; e o algoritmo de Cortar dinâmico (dynamic slicing), que usa também valores de variáveis que podem influenciar o corte.
Item de Rastreabilidade (traceability item): O termo é definido por Spencer e Probasco (1998) como “qualquer item textual ou item de modelo que precisa ser explicitamente rastreado para outro item textual ou item de modelo, para manter a trilha de dependências entre eles”.
Item de código de rastreabilidade (ICR): Quando o item de rastreabilidade for uma Unidade Computacional ou um Corte Funcional, pode ser designado genericamente neste artigo por item de código de rastreabilidade ou ICR.
Na figura 1 está exibido um meta-modelo para explicar melhor a divisão do código de software. Os meta-modelos aqui apresentados, tanto dessa figura como das seguintes, não pretendem apresentar uma visão encerrada da rastreabilidade. Foram feitos apenas para auxiliar no entendimento dos conceitos. Têm fins puramente didáticos. São escritos em UML 1.5 e mostram as relações entre os conceitos utilizados no catálogo. No caso, a figura 1 mostra a generalização da Unidade Computacional e do Corte Funcional no Item de Código de Rastreabilidade (ICR), que, por sua fez, é uma especialização do Item de Rastreabilidade. Também mostra, através de uma agregação, que um Corte Funcional é composto de uma ou mais Unidades Computacionais.
Item de Rastreabilidade Item de Código de Rastreabilidade (ICR) Corte Funcional Unidade Computacional * 1..* * 1..*
Figura 1. Meta-modelo Item de Rastreabilidade.
Diferente da opção de Ebner e Kaindl (2002), que representam as ligações de rastreabilidade em meta-modelos como “associações” entre itens de rastreabilidade, nós optamos por representar ligações em forma de “classes”. Inspiramo-nos na definição de Jarke (1998), que diz que as ligações são produtos da rastreabilidade, e como produtos têm identidade e características bem definidas, e, portanto, devem ser representadas como “classes”.
A figura 2 mostra o meta-modelo das relações das ligações com as unidades computacionais. Uma ligação de rastreabilidade pode ligar diversos requisitos a diversas Unidades Computacionais. A semântica da ligação não é derivada diretamente dos itens que ligam, mas o inverso, os itens de rastreabilidade são conseqüências de uma percepção cognitiva. Jarke (1998) explica que “desta percepção, uma ligação de rastreabilidade captura objetos conceituais e os liga de uma forma significativa”. É possível que diversos requisitos juntos tenham um significado único e que esse significado seja a fundamentação de uma implementação distribuída em diversas Unidades Computacionais. Assim, podemos alterar requisitos ou Unidades Computacionais sem alterar a identidade da ligação, já que a idéia, a percepção cognitiva, que fundamenta o código pode se manter.
Constructo Requisito
Ligação de Rastreabilidade entre Requisito e Unidade Computacional 1..* 1..* +IRR 1..* 1..* fundamenta Unidade Computacional 1..* 1..* +ICR 1..* 1..* satisfaz Composição de Unidade Computacional 1..* * 1..* *
Figura 2. Ligação de Rastreabilidade entre Requisito e Unidade Computacional.
Na figura 2 nota-se ainda a possibilidade de uma Unidade Computacional ser a composição de diversas outras Unidades Computacionais que podem ser fundamentadas em ligações de rastreabilidade diferentes.
O meta-modelo das Ligações de rastreabilidade entre Requisitos e o Corte Funcional, figura 3, mostra uma realidade diferente. Um requisito funcional é tomado como base para a ligação que é satisfeita num único corte funcional. Outros requisitos podem colaborar na fundamentação do código, mas apenas um é a base. O corte funcional é composto por diversas unidades computacionais, que podem ser fundamentas por outros requisitos.
Um tipo especial de rastreabilidade (Ligações de rastreabilidade para alterações) pode ser criado para melhor satisfazer uma prática pedida pelo CMMI. Na descrição do item SP 1.4 “Manutenção da Rastreabilidade Bidirecional de Requisitos” é dito que “a rastreablilidade é particularmente necessária na condução da análise de impacto das alterações de requisitos das atividades de projeto e produtos de trabalho” Chrissis, (2007), página 492. Ligações de rastreabilidade para alterações facilitam a análise e o histórico das alterações.
A figura 4 mostra as ligações de Rastreabilidade entre Alteração e Unidade Computacional. Uma alteração, quando realizada, é toda mapeada por essa ligação: a requisição que a originou, os requisitos alterados e as unidades computacionais incluídas, alteradas e excluídas.
Requisito Não Funcional Unidade Computacional Corte Funcional 1..* * 1..* * Requisito Requisito Funcional
Ligação de Rastreabilidade entre Requisito e Corte Funcional
1 1 +ICR 1 +satisfaz 1 * * +colaboradores * +realização * é realizado em 1 1 +base 1 +codigo da realização 1 define
Figura 3. Ligação de Rastreabilidade entre Requisitos e Corte Funcional.
Requisição de Alteração Requisito * * +candidatos a alteração * * impacta Unidade Computacional
Ligação de Rastreabilidade entre Alteração e Unidade Computacional 1 0..1 +gatilho 1 +realização 0..1 gera * +alterado * alteração de requisito * +adicionado * * +alterado * * +removido *
Figura 4. Ligação de Rastreabilidade entre Alteração e Unidade de Código É importante ressaltar que uma ligação de rastreabilidade entre requisitos e código pode ser indireta. Os requisitos podem ser refinados em diferentes artefatos antes de alcançar o código fonte. Antoniol et al. (2000) dizem que “Sistemas de software são desenvolvidos seguindo processos no qual a complexidade da engenharia de software é atacada por meio de subseqüentes atividades de refinamento. Analise de requisitos, projeto e codificação são fases que estão presentes em quase todos os processos de desenvolvimento de software”. Pode-se então pensar que os requisitos são sempre refinados em algum modelo de projeto, para então serem implementados. O próprio Antoniol deixa claro que a realidade não é essa: “entretanto, a manutenção da consistência entre os artefatos de software e uma atividade custosa e tediosa, que é freqüentemente sacrificada durante o desenvolvimento e manutenção devido às pressões do mercado”. Há requisitos que são implementados diretamente no código e há requisitos que passam por um projeto antes de serem implementados. Assim é necessário que as ligações entre requisitos e código possam ser indiretas ou não. A figura 5 mostra, dentre
outras ligações, a Ligação indireta, que é uma composição de outras Ligações de Rastreabilidade.
Ligação de Rastreabilidade entre Requisito e Código
Ligação de Rastreabilidade entre Alteração e Unidade Computacional
Ligação de Rastreabilidade entre Requisito e Corte Funcional
Ligação de Rastreabilidade entre Requisito e Unidade Computacional
Ligação de Rastreabilidade
Ligação de Rastreabilidade Indireta entre Requisito e Código
1..*
* 1..*
*
Figura 5. Meta-modelo dos tipos de Ligação de Rastreabilidade.
As ligações de rastreabilidade entre requisitos e código de software podem ser classificadas quanto ao âmbito ou quanto ao tipo de ligação.
Classificação quanto ao âmbito dos itens de código de rastreabilidade (ICR): As ligações de rastreabilidade podem ser classificadas em função da abrangência que a fundamentação exerce sob o ICR. Criamos esta classificação baseada naquela feita por Eisenbarth et al (2003), página 218:
Específica: o item de código existe somente por causa do requisito, que é satisfeito somente por este item de código. Em outras palavras, o ICR é fundamentado somente pelo requisito, que não é fundamento de nenhum outro item de código.
Relevante: o item de código é fundamentado pelo requisito, mas também é fundamentado por outros requisitos.
Específica com condição: o item de código existe somente por causa do requisito, que é satisfeito somente por este item de código em determinadas condições.
Compartilhada: o item de código existe somente por causa do requisito, mas outros itens de código também colaboram na sua implementação.
Irrelevante: O item de código é irrelevante para o requisito.
A classificação quanto ao âmbito depende exclusivamente das multiplicidades da relação da ligação com o requisito e com o ICR. A figura 2 mostra que, para ser específica, a ligação de rastreabilidade entre requisito e código deve se associar a apenas um ICR e a um Requisito. Assim temos que um único requisito fundamenta um único ICR.
Item de Código de Rastreabilidade (ICR) Requisito Ligação de Rastreabilidade entre Requisito e Código
1 +ICR 1 satisfaz 1 +IRR 1 fundamenta
Figura 6. Meta-modelo da ligação de rastreabilidade do tipo de Específica
O que é ligeiramente diferente da Ligação de Rastreabilidade Compartilhada, que permite a um requisito seja satisfeito por diversos ICR.
Item de Código de Rastreabilidade (ICR) Requisito Ligação de Rastreabilidade entre Requisito e Código
2..* +ICR 2..* satisfaz 1 +IRR 1 fundamenta
Figura 7. Meta-modelo da Ligação de Rastreabilidade Compartilhada.
Já no caso da Ligação de Rastreabilidade Relevante, mais de um requisito fundamenta o ICR.
Item de Código de Rastreabilidade (ICR) Requisito Ligação de Rastreabilidade entre Requisito e Código
1 +ICR 1 satisfaz 2..* +IRR 2..* fundamenta
3. Requisitos
Esta seção contém o catálogo de requisitos para métodos de rastreabilidade entre requisitos e código de software, do ponto de vista das partes interessadas.
3.1 Requisitos de Programadores
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre requisitos e código que cobrem as necessidades do ponto de vista dos programadores.
3.1.1 Indicação da fundamentação do código
O método tem de registrar as ligações de rastreabilidade entre código (ICR) e requisitos que servem de base, no código fonte, para a lógica desenvolvida, e assim fundamentam o código. - O método deve permitir que a ligação de rastreabilidade seja feita durante a atividade de codificação.
- O método deve informar quando novas Unidades Computacionais desenvolvidas podem interferir em ligações de rastreabilidade existentes. É o caso de alterações da classificação quanto ao âmbito de ligações já existentes. Por exemplo: um ICR que era originalmente Específico, com a nova Unidade Computacional, torna-se Compartilhado.
- O método deve ser o menos intrusivo possível na codificação. A codificação deve ser regida por padrões e normas que visam uma melhor estruturação e entendimento do código. Exigir uma forma de codificação para satisfazer um determinado método pode conflitar com padrões da organização e prejudicar a inteligibilidade do código. É um recurso que deve ser desencorajado nos métodos de rastreabilidade.
- O método tem de suportar Ligações de Rastreabilidade Indireta, principalmente a rastreabilidade entre código e requisitos através de modelos de desenho (design). Muitos requisitos são realizados nas atividades de analise e desenho do sistema. Ao ser implementado a partir de algum modelo, o código está indiretamente realizando os requisitos que motivaram o modelo. O método de rastreabilidade entre requisitos e código deve somar estes requisitos aos outros que são diretamente realizados no código.
- O método pode permitir que o programador indique os requisitos que fundamentam as Unidades Computacionais diretamente do ambiente de codificação, para não haver interrupção no trabalho de programação. Isso pode ocorrer através da implementação do método diretamente na ferramenta de codificação ou via alguma integração entre ferramentas. Fundamentação: Ramesh et al.(1997) dizem que a rastreabilidade facilita a compreensão dos processos por traz da criação dos artefatos. Durante a codificação, o programador utiliza os requisitos, direta ou indiretamente, como base lógica para o desenvolvimento das Unidades Computacionais. É importante que o método de rastreabilidade permita o registro dessa informação, já que, obtê-la mais tarde, pode ser uma tarefa árdua.
Também o modelo CMMI, na área chave Desenvolvimento de Requisitos (RD), a meta específica 2, “Desenvolver requisitos do produto”, pede o registro da rastreabilidade do requisito até funções e componentes do produto.
O método proposto por Zhao et al. (2004) baseado em recuperação de informação (IR) lembra-nos da importância da não interferência na forma de codificação adotado na organização.
3.1.2 Compreensão do código
O método deve ajudar o programador, durante uma manutenção, no entendimento de códigos que não foram escritos por eles. Deve permitir a análise de discrepâncias e buscar a clareza do código [Ramesh et al., 1997]. A compreensão do código, segundo alguns modelos cognitivos, pode ocorrer da forma ascendente (bottom-up), isto é, a partir de conceituação detalhes de Unidades Computacionais, que servirão de base para conceitos cada vez mais abstratos; da forma descendente (top-down), partindo de uma hipótese do funcionamento do código, que deve ser verificada junto aos Cortes Funcionais; ou alguma combinação das duas formas [Antoniol, 2002].
- O método deve permitir visualizar as Ligações de Rastreabilidade entre um determinado requisito funcional e os Cortes Funcionais de código que o resolve. Assim o programador que utiliza o modelo cognitivo descendente pode usar essa visualização para, uma vez que a hipótese da estrutura das unidades computacionais tenha sido formulada, procurar por sinais de sua confirmação ou negação nas ligações de rastreabilidade.
- O método deve permitir uma visualização das ligações de rastreabilidade entre uma determinada Unidade Computacional e os requisitos que a justifica. Assim, Na compreensão ascendente, os programadores têm subsídios para atribuir conceitos às unidades de código. - O método deve permitir uma visualização das ligações entre um determinado Corte Funcional e os requisitos funcionais. Essa visualização ajuda, quando da utilização da compreensão ascendente, nos grupamentos das unidades de código em conceitos mais abstratos.
- As visualizações podem mostrar a classificação quanto ao âmbito da ligação. Caso o ICR seja classificado como Compartilhado, as visualizações podem mostrar todos os ICR que juntos resolvem o requisito. Caso seja classificado como Relevante, podem mostrar todos os requisitos que fundamentam o ICR.
- O método pode capturar as ligações dinamicamente, permitindo que qualquer alteração no código reflita imediatamente na rastreabilidade.
Fundamentação: Os programadores usam diferentes tipos de conhecimento durante a compreensão do programa, variando do conhecimento específico do domínio do sistema até o conhecimento geral de programação. Ligações de rastreabilidade entre áreas específicas do código e sessões relacionadas em documentos de especificação de requisitos ajudam na compreensão tanto do modelo ascendente, como no descendente. Na compreensão descendente, uma vez que a hipótese tenha sido formulada, as ligações de rastreabilidade sugerem onde se deve procurar por sinais de sua confirmação ou negação. Na compreensão ascendente, o principal papel da rastreabilidade é ajudar os programadores na atribuição de conceitos a pedaços de código e no agrupamento desses pedaços em conceitos mais abstratos [Antoniol, 2002].
O método proposto por Murphy et al. (1995) mostra a importância da captura dinâmica das ligações de rastreabilidade a partir de um código de software legado.
3.1.3 Diagnóstico
O método deve fornecer as informações que minimizam o trabalho do programador no diagnóstico de uma questão técnica.
- A partir de uma questão técnica, o método deve mostrar os ICR vinculados aos requisitos que a questão afeta, ordenadas pela classificação quanto ao âmbito dos ICR, do mais forte ao mais fraco: Específica, Específica com condição, Relevante, Compartilhada. A ligação de rastreabilidade neste caso é indireta: questão se liga com requisito que se liga com código. Fundamentação: A norma NBR ISO/IEC 12207:1998, no item 5.5 Processo de manutenção, atividade 5.5.3 Implementação da modificação, indica que o programador deve conduzir a análise e determinar que [..] unidades de software e versões destas necessitam ser modificadas. O modelo CMMI, na área chave Desenvolvimento de Requisitos (RD), a meta específica 2, “Desenvolver requisitos do produto”, pede o registro da rastreabilidade do requisito entre componentes do produto e questões. Assim é possível que uma questão que reporta um mau funcionamento do software seja previamente analisada e rastreada até os requisitos que são afetados. Sendo, as ligações classificadas quanto sua força e rastreadas até as unidades computacionais, o programador tem condições de diminuir o escopo do código que deve ser verificado, tornando seu trabalho mais produtivo.
3.1.4 Alteração do código
O método tem de permitir o registro da rastreabilidade entre a alteração proposta e o código alterado.
- O método tem de fazer ligações de rastreabilidade entre Unidades computacionais incluídas, alteradas ou removidas e o registro da alteração proposta.
- O método pode ser integrado com a ferramenta de gestão de configuração utilizada na organização para não manter dois registros concorrentes das alterações dos artefatos de código.
- O método tem de identificar a versão alterada e a original dos artefatos que contêm as Unidades Computacionais alteradas. A Ligação de Rastreabilidade Entre Alteração e Unidade Computacional tem de se associar às versões originais e alteradas dos ICRs. - O método tem de identificar a versão alterada e a original dos requisitos envolvidos na alteração. A Ligação de Rastreabilidade Entre Alteração e Unidade Computacional tem de se associar às versões originais e alteradas dos Requisitos envolvidos na alteração.
Fundamentação: Uma sub-prática da gerência de alterações de requisitos proposta pelo CMMI é “documentar todo requisito e alterações de requisitos que são dados ou gerados
pelo projeto” [Chrissis, 2007, pág. 491]. Isto porque, como Chrissis explica, é essencial gerenciar as alterações no projeto eficientemente.
3.2 Requisitos para Gerentes de Configuração
Esta subseção descreve os critérios e seus requisitos que cobrem as necessidades do ponto de vista dos Gerentes de Configuração dos métodos de rastreabilidade entre requisitos e código.
3.2.1 Indexação
O método tem de identificar cada unidade computacional, cada corte funcional, cada requisito e as ligações de rastreabilidade entre eles.
- O método tem de identificar unicamente cada Item de Rastreabilidade durante seu ciclo de vida. Um item de rastreabilidade, especialmente o ICR, tem de receber uma identificação durante sua criação que deve ser única e não pode ser alterada durante as manutenções do código. A menos que a manutenção a descaracterize, e, portanto, a unidade deixa de existir, dando lugar a uma outra.
- O método tem de ser capaz de identificar Unidades Computacionais em diferentes níveis de detalhe. Uma ligação pode ser feita utilizando tanto linha de código, como métodos, como classes ou subsistemas.
- O método tem de ser capaz de identificar unicamente Cortes Funcionais. Uma possível forma é utilizar como identificadores as entidades externas que o Corte Funcional afeta diretamente. Não são as Unidades Computacionais que compõe um Corte Funcional que o identificam, pois, estas Unidades podem ser alteradas sem que a identidade do corte seja afetada.
- O método pode permitir que as Unidades Computacionais que compõe um Corte possam variar em níveis de detalhe, do mais detalhado para o menos detalhado, sem caracterizar uma alteração no corte. Um determinado método, que faz parte de um corte, pode ser substituído por sua classe sem que aja alguma alteração no corte.
- O método tem de identificar as Ligações de Rastreabilidade e classifica-las quanto ao seu tipo e âmbito.
- O método deve indexar ICR em linguagens de programação distintas, reconhecendo as Unidades Computacionais segundo os paradigmas de cada uma. Caso seja uma linguagem Procedural, Orientada a Objetos e até mesmo reconhecer mecanismos como Orientação a Aspectos.
- O método deve reconhecer constructos de linguagens mais sofisticados, como ponteiro e vínculos dinâmicos (dynamic binding).
Fundamentação: para haver gerência de configuração sobre as ligações de rastreabilidade, é importante que os componentes da rastreabilidade sejam identificados, só assim pode-se registrar suas histórias nas ligações. Pan et al. (2005) mostram esta necessidade.
O método proposto por Collard et al. (2002) lembra-nos da importância da identificação das unidades computacionais sem interferir na estrutura do código proposto pela organização.
3.2.2 Gestão de configuração da rastreabilidade
As ligações de rastreabilidade têm de ser controladas na mesma linha de base dos artefatos controlados.
- O método tem de garantir a integridade das Ligações de Rastreabilidade entre Alteração e Unidade Computacional. Sempre que uma alteração ocorrer num ICR, deve existir uma Ligação de Rastreabilidade entre Alteração e Unidade Computacional que fundamenta a alteração. O método pode garantir a integridade através de um relatório de itens de Rastreabilidade alterados que não possuem Ligação de Rastreabilidade entre Alteração e Unidade Computacional ou não permitir a alteração sem a indicação da Ligação.
- O método tem de permitir a utilização concorrente das Ligações de Rastreabilidade e de seus itens. Tem de ser possível o uso de trancas (lock), e outros mecanismos de controle, nas Ligações de Rastreabilidade e em seus itens durante edições para quando se estiver trabalhando num ambiente distribuído de uso concorrente.
- O método tem de permitir que Ligações de Rastreabilidade acompanhem as linhas de base dos itens de rastreabilidade que referenciam. Assim uma alteração num item de Rastreabilidade que afete Ligações de Rastreabilidade e a alteração Ligação de rastreabilidade, só pode ser percebida por quem estiver utilizando a linha de base que os itens e as ligações fazem parte.
- As Ligações de Rastreabilidade entre Alteração e Unidade Computacional devem poder referenciar Itens de Rastreabilidade entre linhas de base. Apesar de fazer parte da linha de base mais atualizada, este tipo de Ligação de Rastreabilidade deve referenciar a versão anterior tanto do ICR como do Requisito, que fazem parte de linhas de base mais antigas. - O método pode permitir que alterações concorrentes, mas complementares, em ligações de rastreabilidade devam ser percebidas por seus executores, se possível, durante sua elaboração. Essas alterações ocorrem em colaboração, e o seu resultado deve ser liberado em conjunto para integração numa linha de base.
- O método tem de reconhecer conflitos em Ligações de Rastreabilidade gerados por alterações em Itens de Rastreabilidade executadas concorrentemente. Duas alterações diferentes numa mesma Unidade Computacional (ou em Unidades Computacionais diferentes que fazem parte de uma única Unidade Computacional maior), que ocorreram concorrentemente e foram fundidas durante a liberação, podem gerar alterações nas suas fundamentações (rastreabilidade com requisitos) que são incompatíveis. Isto é, o resultado da fusão das alterações numa unidade computacional, não implica, necessariamente, na soma das ligações de rastreabilidade alteradas.
Fundamentação: As ligações rastreabilidade também são itens de configuração e precisam ser gerenciadas num ambiente de desenvolvimento distribuído e concorrente, assim como descrito no CMMI (2006), Gerência de Configuração, página 114.
3.3 Requisitos para Analistas de Sistema
Esta subseção descreve os critérios e seus requisitos que cobrem as necessidades do ponto de vista dos analistas de sistemas dos métodos de rastreabilidade entre requisitos e código. Segundo o Processo Unificado, o analista de sistemas é, dentre outras coisas, o responsável por desenvolver um plano de gerência de requisitos e depois gerenciar as dependências dos requisitos com outros itens de rastreabilidade.
3.3.1 Acompanhamento do estado dos requisitos
O método tem de permitir ao analista acompanhar a evolução dos requisitos durante o seu ciclo de vida, mostrando o estado de sua realização.
- O método tem de permitir a produção de relatórios de acompanhamento por requisito do produto que, inferindo as ligações de rastreabilidade entre requisitos e código, quantifique a completeza das realizações dos requisitos. O analista não precisa conhecer as ligações de rastreabilidade entre requisitos e código. As unidades computacionais e os cortes funcionais são detalhes desnecessários para suas atividades. Mas precisa destas informações para alimentar métricas que indicam o estado de implementação dos requisitos. Seria interessante que as medidas utilizadas nessas métricas fossem coletadas de forma automática, para poupar o custo de um trabalho de grandes proporções. O método deve permitir a geração de relatórios com essas medidas e se possível já com os cálculos das métricas.
- O método pode permitir, usando os ICR como base comum, a visualização de relações entre requisitos. Caso dois requisitos diferentes compartilhem sua realização numa mesma Unidade Computacional, há indícios de relação entre esses requisitos, que, a partir de uma análise, pode levar a uma reavaliação da definição dos mesmos.
- O método pode capturar as ligações dinamicamente, permitindo que qualquer alteração, criação ou remoção nos requisitos reflita imediatamente na rastreabilidade. Pode-se gerar novas ou alterar Ligações de Rastreabilidade a partir de criação e alteração em definições de requisitos.
- O método tem de garantir a integridade das ligações. Pode ser feito através de verificação, gerando relatório de inconsistências ou não permitindo que a inconsistência ocorra.
Fundamentação: [Chrissis, 2007, pág. 491] a área de processo gerencia de requisitos, prática específica 1.3 “gerência de alterações de requisitos” pede para que as alterações dos requisitos com as suas evoluções durante o projeto sejam acompanhadas. O resultado da analise da evolução de um requisito é insumo para verificação de sua consistência, precisão completeza e correção.
3.4 Projetistas de teste
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre requisitos e código que cobrem as necessidades do ponto de vista dos projetistas de teste.
3.4.1 Inferência da cobertura do teste
O método deve permitir ao projetista de teste obter informações da cobertura dos casos de teste.
- A partir de um relatório de execução do software, o método deve extrair os ICR e reportar todos os requisitos que se ligam a eles, classificados quanto ao âmbito. Estes requisitos devem satisfazer a necessidade do projetista de confirmar quais os requisitos estão sendo realmente testados na execução de cada caso de teste. Assim pode reavaliar o projeto dos testes para uma maior exatidão.
- O método pode permitir uma visualização do software com seus cortes funcionais e os requisitos ligados a eles, para auxiliar na elaboração de testes funcionais.
- O método pode permitir a elaboração de um relatório de referência cruzada entre os cortes funcionais e os requisitos não-funcionais, que ajudam na montagem de roteiros usados nos testes de requisitos não-funcionais.
- O método pode integrar com a ferramenta de automação de testes utilizada pela organização. As visualizações e relatórios descritos acima podem ser implementados na própria ferramenta de automação de testes ou permitir a integração com a mesma.
Fundamentação: Segundo o Processo Unificado, o projetista de teste é responsável pela integridade do modelo teste, garantindo que cumpra seu papel. Além disso, deve selecionar e descrever os casos de teste [Jacobson, 1998, pág. 303]. Para cumprir essas funções o projetista precisa examinar os motivadores e itens alvos dos testes. Em outras palavras, precisa conhecer as ligações de rastreabilidade entre código e os seus motivadores, os requisitos.
3.5 Revisores Técnicos
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre requisitos e código que cobrem as necessidades do ponto de vista dos Revisores Técnicos.
3.5.1 Inspeções técnicas
O método pode fornecer indicações de melhores candidatos à inspeção e a fundamentação de cada unidade computacional que é inspecionada.
- O método pode fornecer um relatório de ICR que se fundamentam em um número maior de requisitos. Estes itens tendem a ser mais complexas e críticos para o funcionamento do software, e devem ser vistos como candidatos a inspeção.
- O método deve permitir a compreensão do código pelo revisor [vide o critério compreensão do código pelos programadores].
Fundamentação: [Chrissis, 2007, pág. 580] mostra que a verificação é uma área chave do CMMI, e que a inspeção é uma forma de revisão por pares, que por sua vez é o mecanismo mais importante da verificação. Na página 583, [Chrissis, 2007] apresenta a sub-prática “identificar os requisitos satisfeitos por cada produto de trabalho selecionado.” Ele ainda
aponta para “a prática específica de Manter a Rastreabilidade bidirecional de requisitos na área chave de processo de gerencia de requisitos para ajudar a identificar os requisitos para cada produto de trabalho”. A inspeção de código normalmente ocorre por amostragem. A seleção do código a ser analisado deve seguir critérios objetivos e eficientes. Também é necessário que o revisor compreenda o código analisado sob o ponto de vista dos requisitos.
3.6 Gerentes de Projeto
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre requisitos e código que cobrem as necessidades do ponto de vista dos Gerentes de Projeto.
3.6.1 Análise de Impacto de alterações que afetam primeiramente os requisitos
O método tem de dar subsídios na análise de impacto de uma alteração no projeto.
- O método tem de, a partir de uma requisição de alteração, gerar um relatório com o resultado de alguma métrica que mostre a quantidade e a complexidade dos ICR envolvidos e o seu grau de envolvimento com a alteração. Observe que neste momento não há ainda uma Ligação de Rastreabilidade entre Alteração e Unidade Computacional, pois a alteração não foi realizada, é apenas uma requisição que precisa ser analisada. O relatório é possível através de um Ligação de Rastreabilidade Indireta: requisição de alteração que se liga com requisitos, que se ligam com ICR. O gerente do projeto precisa estimar custos e prazos para aprovar ou rejeitar a alteração proposta.
- O método tem de, a partir de uma requisição de alteração, relatar os artefatos de código que possuem as unidades computacionais envolvidas na alteração. O relatório é possível através de um Ligação de Rastreabilidade Indireta: requisição de alteração que se liga com requisitos, que se ligam com unidades computacionais que fazem parte de artefatos de código. Os artefatos de código são Unidades Computacionais tratados como unidades físicas pelo processo de desenvolvimento de software da corporação. O relatório deve ser usado para complementar a lista de artefatos candidatos a alteração.
Fundamentação: Alterações podem inicialmente afetar qualquer artefato do sistema e propagar-se por outros produtos de trabalho [Fyson, 1998 e Turver, 1994]. O caso aqui tratado é para toda alteração que diz respeito á alteração de requisitos. Como essa alteração deve ser propagada para outros artefatos do projeto, provavelmente deve afetar também o código. O método de rastreabilidade entre requisitos e código deve fornecer subsídios para ajudar na análise de impacto desse tipo de alteração.
3.6.2 Análise de Impacto de alterações que afetam primeiramente o código - O método tem de identificar os ICR envolvidos na alteração e gerar um relatório com os requisitos afetados, o que ajuda na análise de impacto da alteração.
- O método pode identificar e relatar os Cortes Funcionais que utilizam as Unidades Computacionais envolvidas na alteração, e assim, permitir uma análise de impacto horizontal no código afetado.
- O método pode, para os requisitos onde as Ligações de Rastreabilidade são classificadas quanto ao âmbito como Relevantes ou Compartilhadas, relatar os outros ICR que completam a realização do requisito.
Fundamentação: Gerentes de projetos precisam usar a rastreabilidade entre requisitos e código na análise de impacto de uma alteração no projeto. O CMMI prega que, “A rastreabilidade é particularmente necessária na condução da análise de impacto das alterações de requisitos” [Chrissis, 2007, pág. 492]. Alterações propostas no código devem ser rastreadas até os requisitos que o fundamentou, para que o gerente do projeto possa analisar o impacto da alteração nos requisitos.
Egyed et al. (2002), ao explicar o funcionamento de seu método, chama a atenção de como o código de software funciona como uma base para se localizar relação entre requisitos que fundamentam uma mesma unidade computacional. Sendo assim a alteração de um requisito pode impactar diretamente em outros que estão ligados a mesma unidade computacional.
3.6.3 Acompanhamento da alteração
O método tem de permitir o acompanhamento do estado da alteração.
- O método tem de relatar as diferenças entre os artefatos de código candidatos à alteração com os realmente alterados. Estas informações são extraídas das Ligações de Rastreabilidade entre Alteração e Unidades Computacionais e as ligações indiretas de rastreabilidade entre Requisição de Alteração e ICR.
Fundamentação: “Para uma análise de impacto da alteração eficiente é necessário que a fonte de cada alteração seja conhecida e a razão de qualquer alteração documentada” [Chrissis, 2007, pág. 491].
Uma sub-prática da gerência de alterações de requisitos proposta pelo CMMI é “Manter o histórico das alterações com suas fundamentações” [Chrissis, 2007, pág. 491].
Uma sub-prática da gerência de alterações de requisitos proposta pelo CMMI é “documentar todo requisito e alterações de requisitos que são dados ou gerados pelo projeto” [Chrissis, 2007, pág. 491]. Isto porque, como Chrissis explica, é essencial gerenciar as alterações no projeto eficientemente.
3.7 Arquitetos Corporativos
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre requisitos e código que cobrem as necessidades do ponto de vista dos Arquitetos de Software Corporativos. O Processo Unificado define como função do Arquiteto de Software, dentre outras, a definição de componentes reusáveis.
3.7.1 Localização de candidato ao reuso
O método pode fornecer informações de unidades computacionais candidatas a reuso.
- Para determinados requisitos, previamente selecionados pelo arquiteto, o método pode classificá-los segundo sua coesão nas unidades computacionais que os implementam. Primeiramente as que apresentam Ligações de Rastreabilidade classificadas quanto ao âmbito
como Específicas. Seguido das Específicas com Condição. Depois as Relevantes. E, por fim, as Compartilhadas. Os requisitos que são implementados em Unidades Computacionais específica são mais facilmente isolados do resto do código do que as outras, já que essas unidades são coesas do ponto de vista do requisito.
Fundamentação: A extração de ativos reusáveis a partir de um sistema de software é uma necessidade da indústria como descreve Caldiera e Basili (1991).Para se extrair ativos de reuso, a partir de software que não foram originalmente produzidos para o reuso de seus componentes, é necessário uma avaliação de quais unidades computacionais farão parte do componente de reuso e o quanto estas unidades estão dependentes do restante do código.
3.8 Gerente da Qualidade
Esta subseção descreve os critérios e seus requisitos dos métodos de rastreabilidade entre requisitos e código que cobrem as necessidades do ponto de vista dos Gerentes da Qualidade. Alguns processos, como o Rational Unified Process 2003, atribuem às atividades aqui tratadas como pertencentes ao gerente de projetos. Como a norma NBR ISO/IEC 12207:1998 pede que o processo de garantia da qualidade seja imparcial, e para isso, “a garantia da qualidade necessita ter autoridade e autonomia organizacional, independente das pessoas diretamente responsáveis pelo desenvolvimento do produto de software ou pela execução do processo no projeto”, por tudo isso, optamos por utilizar o papel de gerente da qualidade na execução destas tarefas.
3.8.1 Gestão de Processos
O método tem de conter a descrição das tarefas que compõe fluxo de trabalho para a sua utilização.
- O método tem de indicar atividades com suas dependências, trabalhadores, artefatos de insumo e resultantes. Deve-se descrever a forma de utilização do método, e, para cada usuário, descrever as atividades que resolvem os requisitos mostrados neste catálogo. Assim o gerente da qualidade tem como inserir estas atividades no processo de desenvolvimento de software da empresa para que a utilização do método seja integrado às outras tarefas do processo.
- O método tem de indicar, caso exista, novos papeis para a aplicação do método.
- O método tem de indicar, caso exista, dependências com atividades não definidas pelo método. Um apontamento para a definição da atividade deve ser feita. Por exemplo, caso o método exija a descrição e execução de casos de teste assim como definido pelo Processo Unificado, deve apontar para a descrição desta atividade no Processo Unificado.
- O método pode trazer guias de implantação e customização, para facilitar sua implantação numa empresa.
Fundamentação: Para se aplicar um método de rastreabilidade entre requisitos e código pode ser necessário a criação de novas atividades, artefatos e perfis no processo, o método apresentado por Eisenbarth e tal. (2003) é um exemplo. Caso isso ocorra, esses elementos devem estar bem articulados com o restante do processo da organização. O CMMI descrito por [Chrissis, 2007] na pág. 165, na prática genérica GP 3.1, estabelecer um processo
definido, pede para que seja mantido uma descrição de um processo definido com suas tarefas bem costuradas entre si.
3.8.2 Qualidade do método
O gestor da qualidade tem de garantir que o método utilizado segue normas de qualidade estipuladas para a organização. Estas normas normalmente baseiam-se na ISO/IEC 9126. O método tem de satisfazer os requisitos de funcionalidade:
- Adequação: O método tem de prover funcionalidades que satisfação os requisitos para cada uma das partes interessadas citadas neste artigo.
- Acurácia: O método tem de manter ligações de rastreabilidade que sejam fieis à fundamentação do código.
- Interoperabilidade: O método deve satisfazer os requisitos apresentados neste catálogo de integração com outras ferramentas.
- Segurança: O método deve permitir o controle de acesso às ligações de rastreabilidade. - Conformidade: O método deve ser aderente às normas e modelos utilizadas pela organização, como por exemplo CMMI.
O método tem de satisfazer os requisitos de confiabilidade:
- Maturidade: O método tem de evitar produzir resultados incorretos para qualquer conjunto de códigos e requisitos que façam parte do seu escopo.
- Tolerância à falha: O método deve permitir que sua implementação se mantenha funcional, mesmo com ocorrências de falhas.
- Recuperabilidade: O método tem de permitir a recuperação de informações, caso ocorram falhas.
- Robusteza: O método tem de suportar manter um grande número de ligações de rastreabilidade, assim como ser indiferente ao um grande volume de alterações no projeto. - Escalabilidade: O método tem de suportar o crescimento do número de ligações de rastreabilidade sem um aumento na dificuldade de sua manutenção.
- Precisão adequada: O método tem de alcançar o nível de detalhe necessário de acordo com a parte envolvida.
O método tem de satisfazer os requisitos de usabilidade:
- Inteligibilidade: O método tem de satisfazer os requisitos de usabilidade para cada parte interessada mostrados neste catálogo.
- Apreensibilidade: O método tem de ser permitir que as partes interessadas possam aprender a usá-lo.
- Operacionabilidade: O método tem de permitir que as partes interessadas possam operá-los segundo os requisitos apresentados neste catálogo.
- Relevância: O método tem de manter apenas as ligações de rastreabilidade de interesse das partes envolvidas.
O método tem de satisfazer os requisitos de eficiência:
- Comportamento Temporal: o método tem de, na sua utilização pelas partes interessadas, apresentar os resultados em tempos adequados. Estes tempos devem ser definidos pela equipe de qualidade de cada organização.
- Utilização de recursos: o método tem de, na sua utilização pelas partes interessadas, utilizar um número apropriado de recursos. Esses números devem ser definidos pela equipe de qualidade de cada organização.
O método tem de satisfazer os requisitos de manutenibilidade:
- Analisabilidade: As ligações de rastreabilidade resultantes das operações feitas pelo método têm de permitir uma análise para diagnosticar deficiências ou falhas nas operações.
- Modificabilidade: O método tem de permitir manutenções nas ligações de rastreabilidade para corrigir problemas nas operações, melhorias no resultado ou adaptações à alterações no ambiente.
- Estabilidade: As ligações de rastreabilidade têm de ser imunes a efeitos inesperados devido às modificações no método.
- Testabilidade: As ligações de rastreabilidade resultantes das operações do método têm de permitir sua validação.
O método tem de satisfazer os requisitos de portabilidade:
- Adaptabilidade: O método pode ser adaptável a diversas linguagens, ferramentas, e formas de armazenar requisitos.
- Instalabilidade: O método deve poder ser implementado no ambiente no qual ele se propõe a funcionar.
- Co-existência: o método tem de ser capaz de co-existir com outros métodos que o processo da organização adota e compartilhar artefatos com estes métodos.
- Repetibilidade: Dado uma linha de base dos requisitos e uma linha de base do produto o método tem de gerar sempre o mesmo conjunto de ligações de rastreabilidade entre os requisitos e o código.
Fundamentação: Como o método de rastreabilidade entre requisitos e código é um produto de software, os requisitos de qualidade que os gestores de qualidade devem observar são os listados na norma ISO 9126.
4. Aspectos práticos e operacionais
De acordo com os requisitos identificados para os métodos de rastreabilidade entre requisitos e código, os seguintes aspectos práticos e operacionais relacionados à sua definição e à sua utilização podem ser apontados e/ou sugeridos:
- Os métodos especializados em rastreabilidade com o código de software já existentes e que não cobrem todos os requisitos aqui mostrados podem e devem ser usados, em conjunto com outros métodos, numa composição articulada de um método mais abrangente.
- Os métodos que se propõe resolver a rastreabilidade entre requisitos e código devem mostrar como implementam cada um dos requisitos aqui mostrados.
- Diversos requisitos pedem formas diferentes de visualizações das rastreabilidade. Aconselhamos o uso de mecanismos de visualização gráfica, por permitirem inteligibilidade em uma consulta com um grande volume de informação. Um bom exemplo é o uso da grade de conceitos (Concept Lattice) proposto por Einsenbarth (2003).
- Mecanismos de gerência de configuração que reconhecem Unidades Computacionais e Cortes Funcionais ajudam bastante na implementação do método. Um exemplo é o método de gerência de configuração proposto por Nguyen et al. (2005).
- Uso de hipertextos são bem vindos nas integrações com ferramentas de trabalho, como o proposto por Munson (2005).
- O catálogo aqui apresentado cobre apenas uma parte do problema de rastreabilidade. Precisa ser complementado com requisitos para todos os outros tipos de rastreabilidade. A rastreabilidade horizontal entre Unidades Computacionais é especialmente importante. Também é necessário o vinculo do código com a rastreabilidade pré-especificação de requisitos.
- A importância dos requisitos pode variar de acordo com o tamanho da organização e do nível de maturidade do processo por ela utilizada.
- Confrontar este catálogo com os métodos de rastreabilidade entre requisitos e código, pode fornecer um índice de aderência dos métodos com as necessidades das partes interessadas,e funcionar como critério objetivo na escolha de um método.
5. Conclusão
Apresentamos o catálogo de requisitos para métodos de rastreabilidade entre requisitos e código de software, do ponto de vista das partes interessadas, com a finalidade de contribuir no desenvolvimento de métodos mais eficazes: que ocultem sua complexidade de usuários que não precisam conhecê-la; que sejam focadas no uso, não na tecnologia. Este catálogo não é para ser usado apenas por pesquisadores e desenvolvedores de métodos, mas também por aqueles que montam os processos de desenvolvimento de software numa organização. Estes podem usar o catálogo como critério objetivo na escolha do método mais adequado à suas necessidades.
O catálogo não tem a pretensão de ser uma visão encerrada sobre o assunto, mas de ser um ponto de partida para a discussão dos requisitos básicos que possam tornar a rastreabilidade viável nas organizações. Assim, deve sofrer revisões periódicas com o avanço da discussão e mudanças tecnológicas.
Os principais requisitos vieram de modelos e normas de qualidade (modelo CMMI, especificação ISO/IEC 12207), observados do ponto de vista das partes interessadas. Acreditamos assim ter construído um catálogo funcional e confiável.
Mesmo sabendo que o escopo desse trabalho é bastante limitado, esperamos ter contribuído para o efetivo uso da rastreabilidade no desenvolvimento de software.
Referências
Antoniol, G., Caprile, B., Potrich, A., Tonella, P. (2000) "Design-code traceability for object-oriented systems", Annals of Software Engineering 9, p. 35–58.
Antoniol, G., Canfora, G., Casazza, G., De Lucia, A. e Merlo, E. (2002) "Recovering Traceability Links between Code and Documentation", IEEE Transactions on Software Engineering, volume 28, número10.
Antoniol, G., Merlo, E., Guéhéneuc, Y., Sahraoui, H. (2005) “On Feature Traceability in Object Oriented Programs”, TEFSE’05 - Traceability in Emerging Forms of Software Engineering.
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 components” IEEE Computer, volume 24, número 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 Software Engineering, em conjunto com Automated Software Engineering ASE 2005.
CMMI Product Team (2006) “CMMI for Development, Version 1.2”, Software Engineering Institute 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, número 3, páginas 70-77.
Egyed, A., Grünbacher, 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", IEEE Transactions On Software Engineering, volume. 29, número 3.
Hoffmann, M., Kühn, N., Weber, M., Bitter, M. (2004) “Requirements for Requirements Management Tools”, 12o. IEEE International Requirements Engineering Conference. Fyson,, M. e Boldyreff, C. (1998) “Using Application Understanding to Support Impact
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 edição.
Jarke, M. (1998) “Requirements Tracing”, Communications of the ACM, volume 41, número 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 on Traceability in emerging forms of software engineering, pag. 62-66.
Murphy, G e Sullivan, D. (1995) “Software reflexion models: bridging the gap between source and high-level models”, Proceedings of the 3rd ACM SIGSOFT symposium on Foundations of software engineering.
Neumüller, C., Grünbacher, P. (2006) “Automating Software Traceability in Very Small Companies: A Case Study and Lessons Learned”, 21st IEEE International Conference on Automated 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 27th international conference on Software engineering.
Pan, Kai, Whitehead , E. James, Jr. e Ge, Guozheng (2005) “Textual and Behavioral Views of Function Changes”, Automated Software Engineering, Proceedings of the 3rd international workshop on Traceability in emerging forms of software engineering, Long Beach, California.
Pinheiro, F., Goguen, J. (1996) “An object-Oriented Tool for Tracing Requirements”, IEEE Software, vol. 13, no. 2, p. 52-64.
Pohl, k., (1996) “PRO- ART : Enabling Requirements Pre-Traceability”, IEEE International Requirements Engineering Conference.
Ramesh, B., Stubbs, C. e Powers, T. (1997) “Requirements traceability: Theory and practice”, In: Annals of Software Engineering 3, p. 397–415. J.C. Baltzer AG, Science Publishers.
Ramesh, B. e Dhar, V. (1992) “Supportin Systems Development Using Knowledge Captured During 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 Use Cases” http://www.uml.org.cn/RequirementProject/pdf/traceability.pdf
Turver, R. e Munro, M. (1994) “Na Early impact Analisys Techique for Software Maintenance”, Journal Software Maintenance – Research and Practice, volume 6, no. 1, p.35-52.
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 International Conference on Software Engineering (ICSE'04).
