O Capítulo 2 discute a questão da Rastreabilidade, “por que ainda é pouco e mal usada?”, e suas implicações. Os conceitos básicos que foram usados no desenvolvi- mento do trabalho são apresentados, contextualizando-os nas áreas de conhecimento onde foram moldados. Apresenta os métodos usados para manter a Rastreabilidade e os Modelos de Informação da Rastreabilidade propostos pelas comunidades. Os meta- modelos existentes são então apresentados e suas limitações discutidas.
No Capítulo 3 o metamodelo RAISE é apresentado. A abordagem utilizada para a concepção do modelo é mostrada. Alguns elementos dos metamodelos de processos que foram usados como base da criação do RAISE são apresentados. Por fim, faz-se algumas considerações sobre o metamodelo RAISE.
No Capítulo 4 o metamodelo RAISE é avaliado. Infelizmente não foi possível executar uma validação do metamodelo por haver restrição de recursos e tempo. Pri- meiramente, a metodologia utilizada na avaliação é apresentada. Então, mostra-se o resultado de cada subprocesso da metodologia usada: Definição, Planejamento, Coleta de Dados e Interpretação. É na Interpretação que os aspectos práticos e operacionais do Metamodelo RAISE são discutidos.
No Capítulo 5 a conclusão do trabalho é apresentada, os resultados, contribuições e algumas oportunidades para trabalhos futuros são discutidas.
Métodos e Metamodelos de
Rastreabilidade
Neste capítulo é apresentada a Rastreabilidade e as principais questões relaciona- das ao seu uso. Os conceitos importantes e utilizados neste trabalho são descritos aqui, explorando principalmente o contexto onde estão inseridos. As técnicas propostas e os metamodelos existentes para manter a rastreabilidade são discutidos. Pretende-se, desta forma, contextualizar o conhecimento necessário para o entendimento do atual estado de desenvolvimento da Rastreabilidade na Engenharia de Software.
2.1
A Questão da Rastreabilidade
A Rastreabilidade na Engenharia de Software é uma disciplina emergente e muitos de seus termos e definições ainda não estão inteiramente claros [Winkler & von Pilgrim, 2009]. Como já citado na Seção 1.1, a Rastreabilidade foi concebida como solução de um dos problemas fundamentais do processo de desenvolvimento de software: a ga- rantia da conformidade do software com os seus requisitos, ou, em outras palavras, a garantia de que o que está sendo desenvolvido é exatamente o que foi solicitado. A Rastreabilidade apresentou problemas desde cedo. Em 1994, Gotel e Finkelstein [Go- tel & Finkelstein, 1994] listaram uma série de questões que necessitavam ser resolvidas para que a Rastreabilidade pudesse ser largamente utilizada. Gotel, quinze anos de- pois, é coautor de Mader e outros em “Getting Back to Basics: Promoting the Use of a Traceability Information Model in Practice” [Mader et al., 2009], e afirma que a Ras- treabilidade ainda é pouco e mal usada. Nesta dissertação, o fato de Rastreabilidade ser pouco e mal usada é discutido e referenciado como a “Questão da Rastreabilidade”. A essência da Questão da Rastreabilidade permeia o fato que manter a informação necessária para a Rastreabilidade é trabalhoso e consome tempo [Antoniol et al., 2005]. Pohl [Pohl, 1996] detalha o problema do uso da Rastreabilidade em três principais aspectos, que são: primeiro aspecto, o uso da informação de Rastreabilidade depende das Partes Interessadas e das tarefas do processo de desenvolvimento de software, isto é, informação não é usada como é registrada e, consequentemente, recuperações seletivas, de acordo com necessidades atuais precisam ser suportadas. Por exemplo, na tarefa de Análise de Impacto de uma alteração de um requisito, as seguintes recuperações de informação da Rastreabilidade são necessárias: todos os elementos ligados ao requisito alterado, outros requisitos indiretamente afetados, elementos indiretamente afetados, Partes Interessadas nos elementos afetados. Essa informação recuperada é registrada em tarefas distintas de forma distinta. Segundo aspecto, devido ao grande volume de informação produzida durante o processo, apenas ligações orientadas ao conteúdo são base para o uso apropriado, isto é, o uso da informação registrada só é apropriado
se a informação de Rastreabilidade está encapsulada em seu contexto. Por exemplo, ao se recuperar uma ligação de contradição entre dois requisitos, deve-se entender: quando a contradição foi identificada? Quem são as Partes Interessadas para resolver a contradição? A contradição já foi resolvida? Como foi resolvida? Sem esse contexto a informação não é usada de forma apropriada. Terceiro aspecto, as pessoas envolvidas na captura de informação de Rastreabilidade são frequentemente diferentes dos usuários da informação. Como no caso da análise de impacto de uma alteração. A informação de Rastreabilidade utilizada foi registrada pelos desenvolvedores que frequentemente não participam da análise.
A busca para se resolver a Questão da Rastreabilidade e obter uma boa utilização está fragmentada em diferentes comunidades, o que prejudica a solução do problema. Isso ocorreu devido à forma como a disciplina foi inserida na Engenharia de Software. A Rastreabilidade surgiu na Engenharia de Requisitos, o que justifica o fato de até hoje se encontrar a expressão “Rastreabilidade de Requisitos” quando, em alguns casos, se quer falar de Rastreabilidade em geral. Essa diferenciação é discutida no artigo de Winkler e Pilgrim [Winkler & von Pilgrim, 2009]. Já está claro que a Rastreabilidade é uma área de pesquisa que transcende a Disciplina de Requisitos e alcança todo o ciclo de desenvolvimento de software, apesar de ainda ser muito comum encontrá-la vinculada à requisitos. As primeiras pesquisas feitas pela comunidade da Engenharia de Requisitos focaram principalmente nas áreas de processo de validação e verificação. Com o tempo, outras comunidades de pesquisadores também mostraram interesse na Rastreabilidade, em especial no campo de MDE (Model-Driven Engineering), onde as ligações de Rastreabilidade ganham uma atenção especial por indicarem as transfor- mações dos elementos. Como exemplo, uma classe de nome “ControladorDeEstoque” de um modelo independente de plataforma pode ser transformada nas classes “Con- troladorDeEstoqueAction” e “ControladorDeEstoqueForm” em um modelo dependente de plataforma. Informação de Rastreabilidade que vincula a classe de origem com as classes de destino devem ser mantidas para permitir as alterações nos modelos. O artigo “Model-driven engineering” de Douglas C. Schmidt [Schmidt, 2006] apresenta o campo de estudo MDE. Apesar de existirem algumas variações do MDE, como o MDD (Model-driven Development) e o MDA (Model-Driven Architecture), por simplificação, estas variações são tratadas neste trabalho como pertencentes à classe do MDE, já que não há diferenças significativas entre elas do ponto de vista da Rastreabilidade.
As pesquisas da Rastreabilidade na comunidade MDE foram desenvolvidas de forma independente das pesquisas de Rastreabilidade de Requisitos por terem focos distintos e não se mostrarem parte de um todo maior. A percepção de uma unificação do estudo da Rastreabilidade só ocorreu mais recentemente [Winkler & von Pilgrim,
2009] e ainda não é uma realidade.
Ainda há indefinições sobre alguns conceitos utilizados na Rastreabilidade, prin- cipalmente devido à fragmentação dos esforços das pesquisas. A seção 2.2 apresenta os conceitos básicos que são usados no restante deste trabalho contextualizados em suas áreas de pesquisas.