Requisitos de Métodos de Rastreabilidade entre os
Requisitos e o Código de Software
Pedro L. R. Leal Jr1
1Departamento 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.. Resumo..
1. Introduçã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 (RR). Mas, ainda assim, apesar da RR já ser utilizada há alguns anos, códigos fonte freqüentemente evoluem sem a atualização da documentação [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, que, até então, 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. 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.
Torna-se então importante uma escolha adequada de métodos e ferramentas que resolvam à complexidade da RR para que sua adoção finalmente ocorra de forma generalizada. Não é uma questão de fácil solução, pois a rastreabilidade de requisitos não é uniforme. 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. Uma ligação de 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 ligação de rastreabilidade entre o mesmo requisito e uma associação em um diagrama UML. Um código Java é de natureza distinta de um modelo UML. Deve-se considerar a natureza de cada artefato para se escolher o melhor método de rastreabilidade entre eles.
No caso da rastreabilidade entre requisitos e códigos fonte, também há ligações de naturezas distintas. Uma ligação de rastreabilidade normalmente possui as características: unidades de origens, unidades de destinos e tipo da ligação. Mas no caso
da rastreabilidade entre requisitos e código é possível que os destinos não sejam unidades, 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. Assim, os métodos de rastreabilidade devem considerar a existência de diferentes formas de ligações para poderem cobrir todo seu escopo de rastreabilidade.
Para uma visão global do problema de rastreabilidade de requisitos, pode-se consultar o Gotel et al. (1994).
Nota-se, pelo que foi exposto até agora, que se pode buscar a solução da questão de que “a rastreabilidade de requisitos ainda não alcançou uma adoção generalizada” na composição de diferentes métodos especializados em categorias distintas de ligações e artefatos. Este artigo pretende colaborar na solução do problema, discutindo requisitos para os métodos de um dos tipos de ligação: rastreabilidade entre requisitos e código de software. Antoniol et al. (2002) mostra a importância dessas ligações, apesar de não abordar a rastreabilidade entre código e requisitos diretamente, mas entre código e qualquer documentação gerada no processo de ciclo de vida do software. Como um número significativo dos documentos ali tratados são requisitos de software, o seu artigo foi usado como base para o levantamento de interessados na rastreabilidade entre requisitos e código de software e a importância desses requisitos para cada um deles.
Começando com os programadores, percebe-se que muitas vezes precisam entender códigos que não foram escritos por eles. Existem modelos cognitivos que compartilham a idéia que a compreensão de programas ocorre da forma de baixo para cima (bottom-up), de cima para baixo (top-down), ou alguma combinação das duas formas. Eles também concordam que programadores usam diferentes tipos de conhecimento durante 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 sessões relacionadas em documentos de especificação de requisitos ajudam na compreensão tanto do modelo de baixo para cima, como no de cima para baixo. Na compreensão de cima para baixo, 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 de baixo para cima, o principal papel da rastreabilidade é ajudar aos programadores na atribuição de conceitos à pedaços de código e no agrupamento desses pedaços em conceitos mais abstratos.
Outra utilidade de ligações de rastreabilidade entre requisitos e código para o programador é a ajuda na identificação das áreas de código diretamente afetadas por uma requisição de manutenção como indicada pelo usuário final.
Gerentes de requisitos têm como principal instrumento de trabalho os requisitos e suas ligações. A utilidade para o gerente de requisitos das ligações de rastreabilidade do tipo aqui tratado é que ela é a chave para localizar áreas do código que contribuem na implementação de funcionalidades específicas [Pinheiro et al. (1996), Konclin et al., 1988 e Ramesh et al., 1992]. Isso ajuda garantir a completeza de uma implementação com respeito aos requisitos indicados.
Gerentes de testes também aproveitam dessas ligações para planejar casos de testes completos e inferir na cobertura dos testes sobre os requisitos.
As ligações são também de grande uso durante a inspeção de código, provendo aos inspetores as conexões entre o código e os seus objetivos e na garantia da qualidade, observando a completeza da implementaçã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 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. De fato, desde que software frequentemente 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 reuso 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.
Todos esses profissionais têm a necessidade da rastreabilidade entre os requisitos e o código, que, como já dito, ainda não é largamente utilizada, devido à complexidade de sua implantação e o alto custo da manutenção manual. Sendo assim, precisam de uma ferramenta para dar suporte à rastreabilidade. A escolha de uma boa ferramenta, que implemente métodos de rastreabilidade eficazes, nem sempre é fácil (por isso poucos utilizam com sucesso), devido a variedade e diferenças de características entre os métodos. Este artigo tem como objetivo apresentar um catálogo de requisitos de métodos de rastreabilidade entre os requisitos e o código de software, e assim, ajudar a esses 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.
Além desses profissionais já citados, 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.
A catalogação dos requisitos obedeceu a um critério bem definido: primeiramente a compilação dos requisitos extraídos de artigos que tratam da rastreabilidade de requisitos em geral. É o caso do artigo Ramesh et al (1997). Também se extraiu requisitos das normas e padrões relativos ao ciclo de vida do software. ISO/IEC 12207, MIL-STD-498, DOD-STD-2167A.
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].
Por fim, utilizou-se de artigos que tratam de métodos para rastreabilidade entre código fonte e outros artefatos. Fez-se 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, fez-se uma avaliação da universalidade da característica para descobrir se era ou não um novo requisito. Apresenta-se aqui os artigos utilizados neste critério organizados por método, que serão descritos na sessão 2 “Modelos e características da Rastreabilidade entre os Requisitos e o Código de Software”. Para métodos baseado em cenários, utilizou-se Egyed et al. (2002) e Eisenbarth et al. (2003). 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), usou-se Zhao et al. (2004) e Antoniol (2004). Já para os métodos baseados em semântica, uso-se o Collard (2002).
Para efeito deste documento, será utilizada a definição de rastreabilidade de requisitos proposta 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.
2. Modelos e características da Rastreabilidade entre os Requisitos e o Código de Software
3. Requisitos
5. Conclusão 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.
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. 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.
Fyson,, M. e Boldyreff, C. (1998) “Using Application Understanding to Support Impact Analysis”, Journal Software Maintenance – Research and Practice, volume 10, p.93-110.
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.
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. Marcus, A., Maletic, J. (2003) "Recovering Documentation-to-Source-Code
Traceability Links using Latent Semantic Indexing", 25th International Conference on Software Engineering (ICSE'03) p. 125.
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).
Pinheiro, F., Goguen, J. (1996) “An object-Oriented Tool for Tracing Requirements”, IEEE Software, vol. 13, no. 2, p. 52-64.
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., Stubbs, C., Powers, T. e Edwards, M. (1995) "Implementing Requirements Traceability: A Case Study", IEEE International Symposium on Requirements Engineering.
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.
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).
