Atividade 1.1 Desenvolver Modelo de Rastreabilidade

Para que o controle das alterações dos requisitos seja realizado de forma eciente, deve-se estabelecer, primeiramente, quais os itens que precisam ser controlados. O ponto chave desta atividade é a denição de um modelo de rastreabilidade e de uma política de rastreabilidade, onde a equipe do projeto irá determinar quais as informações, presentes nas leis, nos requisitos e em outros artefatos do sistema, que devem ser monitoradas (rastreadas). A Figura 13 apresenta um modelo de rastreabilidade elaborado com base na proposta de Dall'Oglio, Silva e Pinto (2010). Esse metamodelo é genérico, assim para cada situação os atributos devem contextualizados e preenchidos.

Esse modelo proposto pode ser considerado uma instância, para requisitos legais, do modelo de (DALL'OGLIO; SILVA; PINTO, 2010) ilustrado na Seção 2.5.3. A intenção é

permitir o monitoramento, ainda que simplicado, da legislação relacionada ao projeto considerando o seu tipo, situação e seus relacionamentos. O modelo permite o gerencia- mento de diversos tipos de rastreabilidade (pré, inter e pós-rastreabilidade) para os outros tipos de artefatos monitorados. Sendo também capaz de armazenar diferentes versões do projeto permitindo a criação de baselines, mantendo o histórico de todas as alterações que ocorreram nos artefatos dos sistema ao longo do tempo.

Figura 13: Modelo de rastreabilidade para requisitos legais

(LawType e LawStatus) foram os principais ajustes realizados para permitir a rastrea- bilidade de requisitos legais. As outras estruturas do modelo relacionadas à análise de impacto e controle de mudança podem ser mantidas como proposto na versão original, dependendo da necessidade do projeto. Essas estruturas não foram enfatizadas na Figura 13, que mantém o foco nas entidades pertinentes à pré e pós-rastreabilidade, ao controle de versão (baseline) e à legislação aplicada ao sistema que se quer desenvolver.

Uma baseline de software dene um conjunto de itens de conguração do sistema formalmente determinados e xos em um momento especíco do ciclo de vida do soft- ware. O termo também é usado para se referir a uma determinada versão de um item de conguração que foi acordado entre as partes interessadas. Em ambos os casos, a baseline só pode ser alterada por meio de procedimentos formais de controle de mudanças.

Considerando que o modelo de rastreabilidade proposto neste trabalho é um modelo genérico, que consolida as principais características de modelos desenvolvidos ao longo de vários anos de pesquisa realizadas por diversos autores, ele pode ser utilizado como base por equipes de desenvolvimento que ainda não possuem um modelo de rastreabilidade de requisitos legais denido.

Uma política de rastreabilidade também deve ser denida durante essa fase da abor- dagem; nessa política, os membros da equipe em colaboração com o cliente devem deter- minar o tipo e a quantidade de informação de rastreabilidade que pretendem controlar. Ribeiro (2008) descreve alguns fatores que inuenciam a elaboração de uma política de

rastreabilidade, como:

• Número de requisitos: quanto maior for o número de requisitos, maior será a ne- cessidade de gerir a informação de rastreabilidade. Se o número tornar essa gestão impraticável, será preferível isolar a informação de rastreabilidade crítica a manter. • Tempo de vida útil do sistema: só se justica um grande controle de rastreabilidade se o sistema tiver um tempo de vida útil longo, caso contrário, os benefícios alcançados não justicam o esforço na manutenção do controle.

• Nível de maturidade da organização: organizações nos níveis mais baixos de ma- turidade devem focar-se somente em manter informação de rastreabilidade entre requisitos. Organizações em níveis mais elevados, poderão ter políticas mais com- pletas.

• Dimensão da equipe: se a equipe for pequena, a necessidade de estruturação e for- malismo é menor do que para equipes grandes (mais de vinte elementos). Se as equipes não trabalharem no mesmo local é necessário trocarem entre si informação de rastreabilidade, sob risco de perderem controle das alterações e do impacto das mesmas.

• Tipo de sistema: os sistemas considerados críticos, de controle em tempo-real ne- cessitam de políticas mais completas.

• Requisitos especícos do cliente: alguns clientes podem desejar que lhes sejam en- tregues informações de rastreabilidade. Nesse caso, é necessário negociar com eles que informações devem ser incluídas.

Estes fatores podem ser utilizados como ponto de partida para denição de uma política de rastreabilidade preliminar para o projeto. Esta política deve apresentar ainda as seguintes informações, dentre outras:

• As técnicas e ferramentas, como a matriz de rastreabilidade, que serão utilizadas para manutenção dos elos de rastreabilidade entre os artefatos;

• Uma descrição dos pontos em que a informação de rastreabilidade deverá ser cole- tada ao longo do processo de desenvolvimento de software;

• A denição dos papéis das pessoas responsáveis pela manutenção das informações de rastreabilidade;

• O processo utilizado para garantir que a informação de rastreabilidade seja atuali- zada quando uma alteração for realizada.

A política deve inuenciar diretamente a construção do modelo de rastreabilidade e pode ser denida em paralelo com ele. Ela também deve ser aprimorada à medida em que os registros dos elos de rastreabilidade forem sendo realizados pela equipe.

Ao nal desta atividade, um Modelo de Rastreabilidade e uma versão inicial da Polí- tica de Rastreabilidade para requisitos legais devem ser disponibilizados e adotados pela equipe, como referência para construção dos elos de rastreabilidade entre os componentes do projeto. O modelo deve ser produzido com a coordenação do engenheiro de requisitos e pode utilizar o auxílio de ferramentas de modelagem ( ferramentas CASE ) que permitam a criação de diagramas UML, como o mostrado na Figura 13.

A operacionalização do modelo e da política de rastreabilidade deve ocorrer de forma integrada observando a escolha, ou mesmo a implementação, de ferramentas de gerenci- amento de requisitos, de gerenciamento de tarefas/bugs (bug tracking ou task manage- ment) e de codicação do software ( IDE ) que serão utilizadas pela equipe. A ferramenta escolhida pode implementar o modelo de rastreabilidade utilizando um Sistema de Ge- renciamento de Banco de Dados ( SGBD ) que possibilite o registro e a recuperação dos elos de rastreabilidade de forma conável, associada ao uso de boas práticas de controle de versão com uma ferramenta de versionamento de código fonte eciente.