Matriz de Rastreabilidade (Parte 1)

Motivação

"A Matriz de Rastreabilidade auxilia bastante na identificação de impactos." Muitos concordam com isso. Entretanto, basta o primeiro aperto durante o ciclo de desenvolvimento e esta frase parece ser esquecida.

Também pudera. Em muitos casos, a Matriz de Rastreabilidade é algo extremamente complicado de ser mantido. Não conheço nenhum software free acessível que mantenha esta matriz. O fato é que existem softwares bastante completos em que a Matriz, ou as associações entre artefatos, é apenas uma parte de todo um conjunto de funcionalidades.

Até para passar o tempo, há algum tempo atrás, comecei a desenvolver uma Matriz de Rastreabilidade em VS.NET 2005. O projeto parou. Quando surgiu a oportunidade em um trabalho de grupo, sugeri para outros três colegas que fizéssemos um software que gerenciasse impactos entre artefatos. A linguagem era Java. A idéia evoluiu e hoje estamos fazendo este trabalho.

Mas agora preciso voltar a estudar .NET. Pensei, então, em recomeçar o projeto para ser minha nova cobaia em C#.

Sem complicações e muita delonga, vamos lá!

Todos sabem o quanto é importante eliciar, encontrar, analisar, documentar e validar requisitos. Estas atividades são muito importantes porque blá blá blá blá blá... Não quero dizer que não seja importante. É sim! E muito. Só não quero fazer isso agora! Afinal, todo mundo sabe como funciona uma matriz de rastreabilidade.

Se temos N artefatos, teremos uma matriz NxN em que cada célula representa a relação entre dois artefatos. A relação pode ser do tipo "depende de", "impacta em", "não está relacionado diretamente". A legenda que cada um utiliza para representar é indiferente neste momento.

Ok, ok! Esta é para os mais conservadores (analistas de requisitos que ficam com medo de perder o emprego quando alguém põe a mão na massa sem falar com ele): suponhamos que eu levantei (já conhecia) e validei (comigo mesmo) os requisitos, e estão todos anotados (na minha cabeça). Tenho um pouco de tempo. Farei uma rápida repassada.

Então, vamos lá!

Um artefato de software possui uma descrição e um identificador numérico único. Um artefato pode ser do tipo "Especificação de Caso de Uso", "CONOPs - Conceitos de Operações", "Classe de Design", entre outros. Seria legal que tipo fosse uma classe. Código e descrição são suficientes?

Maravilha! Agora eu posso cadastrar todos os artefatos de software no meu sistema. Ótimo! Mas e aí? Cadê a tal matriz?

Agora vem, talvez, a parte mais complicada da história. Cada artefato pode impactar em zero ou mais artefatos (0..*). Da mesma forma, um artefato pode depender de zero ou mais artefatos. E agora? Lascou?

Começamos bem! Temos um auto-relacionamento.

Se minhas aulas de UML e Orientação a Objetos valeram de alguma coisa, acho que podemos representar isto de três maneiras.

Assim:
Associações com setas.

Ou talvez assim:
Associações como atributos.

Alguns até representam assim:
Associações como atributos e com setas.

Prefiro não querer acreditar que uma abordagem é certa ou melhor que a outra. Eu, particularmente, não gosto de redundância. Então, não utilizo a terceira (atributos e setas). Gosto mais da segunda (como atributos), pois deixa o modelo mais enxuto. Nada contra quem prefere usar muitas setas, gosto pessoal.

Temos nosso modelo de domínio. O problema parece bem simples e, aparentemente, este modelo permite que tenhamos as informações necessárias para nossa matriz:
- Quais são os artefatos?
- Qual o tipo de cada artefato?
- Quem depende de quem?
- Quem impacta em quem?

A seguir, tentarei esboçar a Arquitetura de Software que pretendo utilizar para resolver nosso problema.

- O quê!? Você vai projetar e documentar uma arquitetura para um sistema que tem apenas duas classes no modelo de domínio?

Sim, eu vou! É uma ótima oportunidade para experimentar e fazer testes. Não quero deixá-la passar.