01/06/08 Daniel Villela

Artigo: Rastreabilidade de Requisitos

INF2921

01/06/08 Daniel Villela

Apresentação do Artigo

A qualidade no desenvolvimento de software é baseada narastreabilidade de requisitos. Nesse artigo será mostrado como que asimplicações na rastreabilidade interferem na qualidade do produto a serdesenvolvido e associar os aspectos técnicos com os gerenciais, alémde apresentar dois modelos de referência para apoiar a equipe dedesenvolvimento na definição do modelo de rastreabilidade e comoesses modelos foram importantes para a identificação de problemasabertos nessa área.

01/06/08 Daniel Villela

Introdução

O principal propósito é apresentar ao leitor diferentes facetas desde tema, visando conscientizá-lo da importância dorastreamento no processo de desenvolvimento de software.

O artigo está dividido em 4 seções:

1ª Seção: Aborta o aumento com a preocupação na qualidade de software recorrente à crescente globalização do mercado, a terceirização no desenvolvimento de software e o desenvolvimento por equipes distribuídas que foram à peça chave nessa contribuição. Por causa dessa preocupação as empresas de desenvolvimento de software buscam modelos para a certificação da qualidade de software que será brevemente apresentado.

2ª Seção: Mostra que a validação do software junto ao cliente utilizam os rastros e elos de rastreabilidade para mostrar que todos os requisitos foram atendidos pelo software. Apresentaremos “métodos” no processo de desenvolvimento de software e modelos de rastreabilidade.

01/06/08 Daniel Villela

Introdução

3ª Seção: A efetiva aplicação da rastreabilidade no processo de desenvolvimento de software depende da definição de um modelo de rastreabialidade. Pontos a considerar na definição e na utilização desse modelo, descrições de algumas técnicas e ferramentas auxiliares para apoiar o processo de rastreamento serão apresentados.

4ª Seção: Apresenta conclusões e contribuições desse trabalho e problemas que ainda estão em aberto no tema de rastreabilidade.

01/06/08 Daniel Villela

Qualidade de Software

A preocupação com a qualidade de software levou à criação, no inícioda década de 90, de um conjunto de conceitos visando medir amaturidade das empresas criadoras de software. Diversos modelospara avaliar o processo de desenvolvimento de software foramdesenvolvidos, porém, o mais aplicados até hoje são CMM – CapabilityMaturity Model [Paulk95] [Paulk93] e ISO 9001 [Weber97].

CMMI - Capability Maturity Model Integration surgiu visando à integração de diversos modelos de qualidade e apresenta uma novaversão para o SW-CMM, que se propõe substituir.

A CMM e a CMMI são as mais populares para as empresas que visam o mercado Americano e a ISO 9001 visa o mercado Europeu.

01/06/08 Daniel Villela

Qualidade de Software

Modelo CMM

01/06/08 Daniel Villela

Qualidade de Software

Modelo CMMI

01/06/08 Daniel Villela

Qualidade de Software

Semelhança

Podemos observar que o nível 2 do CMM é equivalente ao do CMMI. Opropósito é a Gerência de Requisitos, identificação de inconsistênciasentre requisitos e os planos de artefatos.

Diferença

A diferença trazida pelo CMMI em relação a requisitos está no nível 3,denominado de Definido.

Esperamos que com os processos de qualidade mostrado acima, resulteem aumento de produtividade, redução de custo, maior qualidade ecompetitividade no produto final.

01/06/08 Daniel Villela

Gerência de RequisitosAtualmente tem-se a convicção que mudanças de requisitos ao longodo processo de desenvolvimento de software fazem parte do processo.Motivos que podem levar a alteração em requisitos não identificadosinicialmente:

- Mudança no contexto onde o sistema será inserido;- Correção de erros detectados por processos de qualidade ou novasPerspectivas.

Essas alterações podem implicar em mudanças em artefatos de desenho, de código e de casos de testes. Todas estas mudanças devemser acompanhadas, de forma a garantir que todos os artefatos afetadospor uma alteração sejam corrigidos. Essas mudanças no processo deacompanhamento são denominadas de Gerência de Requisitos. Paranão haver certa confusão de conceitos, faremos uma distinçãoimportante entre Gerência dos Requisitos e o que denominamos deGerência por Requisitos.

01/06/08 Daniel Villela

Gerência de Requisitos

A Gerência por Requisitos (ou Gerência de Requisitos) trata de um aspecto fundamental e crítico em qualquer processo de software: estabelecer uma visão comum entre o cliente e a equipe de projeto emrelação aos requisitos que serão atendidos pelo software . As metas aserem atingidas pela gerência por requisitos são:

(i) documentar e controlar os requisitos alocados para estabelecer umabaseline para uso gerencial e da engenharia de software.(ii) manter planos, artefatos e atividades de software consistentes comos requisitos alocados [Santander00]. Segundo Leite, deve-se incorporar descrições em linguagem natural. Uma possível estrutura écomposta de:

- Modelo de léxico- Modelo Básico- Modelo de Cenários- Modelo de Hipertexto- Modelo de Configuração

01/06/08 Daniel Villela

Gerência de Requisitos

As atividades ligadas ao Gerenciamento por Requisitos incluem ocontrole de mudanças, identificação de relacionamentos entre requisitos, suas origens e componentes que os implementam, análisesde impacto, controle de versões dos diferentes artefatos e acompanhamento do estado dos requisitos.

Indispensável à tarefa de Gerência por Requisitos é a disponibilidade defacilidades de rastreamento. Detalharemos o rastreamento de requisitos, que é vital ao gerenciamento do processo [Jarke98];requisitos não podem ser efetivamente gerenciados sem rastreabilidade. Um requisito é rastreável se é possível descobrir quemsugeriu o requisito (a fonte), por que o requisito existe (rationale), queoutros requisitos estão relacionados a ele (dependência entre requisitos) e como o requisito se relaciona com outras informações taiscomo desenho do sistema, implementação e documentação do usuário[Sommerville98].

01/06/08 Daniel Villela

Gerência de Requisitos

RastreabilidadeRastreabilidade

O rastreamento de requisitos é utilizado para prover relacionamentosentre requisitos, arquitetura e implementação final do sistema epossibilita uma adequada compreensão dos relacionamentos dedependência entre requisitos e através dos artefatos de requisitos, dearquitetura e de implementação. A rastreabilidade pode serimplementada por um conjunto de elos ou ligações (links) entrerequisitos inter-relacionados, entre requisitos e suas fontes, e entrerequisitos e os componentes que os implementam.

A rastreabilidade de requisitos tem sido identificada como fator de qualidade, característica que um sistema pode possuir e incluir como requisito não funcional, além de ser um dos mais importantes pré-requisitos para desenvolvimento de software com qualidade.

01/06/08 Daniel Villela

Gerência de Requisitos

- Pré-rastreabilidade documenta a o contexto a partir do qual emergem os requisitos; - Pós-rastreabilidade vincula os requisitos ao desenho do sistema e sua implementação

[Davis93].

Temos a rastreabilidade forward-to (para frente),que liga documentosobtidos no processo de elicitação a requisitos relevantes, e a rastreabilidade backward-from (para trás), que liga requisitos às suasfontes. No segundo tipo temos rastreabilidade forward-from, que ligarequisitos a artefatos de desenho e implementação e rastreabilidadebackward-to, que liga artefatos de desenho e implementação de volta arequisitos.

01/06/08 Daniel Villela

Gerância de Requisitos

Impactos da rastreabilidade num projeto de Impactos da rastreabilidade num projeto de desenvolvimento de softwaredesenvolvimento de software

O primeiro modelo a ser proposto, conhecido por cascata (waterfall), O primeiro modelo a ser proposto, conhecido por cascata (waterfall),

apresentava o problema de não prever tratamento para alterações nosapresentava o problema de não prever tratamento para alterações nos

requisitos durante o próprio processo de desenvolvimento.requisitos durante o próprio processo de desenvolvimento.

01/06/08 Daniel Villela

Gerência de Requisitos- Esse processo é dinâmico: segue-se o desenho do modelo;

- Existem relatos que projetos com estabilidades apresentam alterações da ordem de 1% ao mês de acordo com Hammer e para Kotonya esse percentual de alteração sobe para 50% dos requisitos antes que o sistema seja colocado em produção.

- Outra fonte de alterações são os problemas identificados quando tem início a fase de implementação, sendo que podem surgir problemas na arquitetura do sistema e o processo de desenho ser retomado.

- O modelo deve evoluir de acordo com o sistema e o Universo de informação ( UDI).

- Mostramos que uma baseline é contextualizada num eixo com duas dimensões: Eixo Horizontal mostra a evolução ao longo do processo de desenvolvimento, e o eixo longitudinal registra a evolução em cada etapa do processo.

01/06/08 Daniel Villela

Gerência de Requisitos

01/06/08 Daniel Villela

Gerência de Requisitos

A principal fonte geradora de alteração é o próprio conjunto deinteressados, que inicialmente não possuem muita clareza nos objetivosa alcançar, e a medida que o desenvolvimento evolui vai descobrindonovas funcionalidades ou possibilidades para incluir no projeto.

O gerenciamento de requisitos necessita da rastreabilidade dosrequisitos para controlar e documentar as modificações.

A rastreabilidade pode auxiliar em várias situações, como por exemplo:

- Verificação da alocação de requisitos a componentes do software;- Verificação;- Validação;- Previsão de custos e prazos;- entre outras.

01/06/08 Daniel Villela

Gerência de Requisitos

Meta-modelo proposto por Ramesh&JarkeMeta-modelo proposto por Ramesh&Jarke

Propõem um meta-modelo para a rastreabilidade que possibilita a captura de informações relacionadas a agentes, fontes e objetos – as

três dimensões dos modelos de rastreabilidade. Nesse meta-modelo os

interessados são ligados através de estruturas de contribuição[Gotel94]aos objetos conceituais que eles influenciam e a documentos onde taisobjetos são registrados.

01/06/08 Daniel Villela

Gerência de Requisitos

A figura abaixo apresenta a visão geral desse meta-modelo: note quesão apresentados objetos relacionados ao produto sendo elaborado eobjetos (ou artefatos) relacionados ou gerados pelo próprio processo dedesenvolvimento.

01/06/08 Daniel Villela

Gerência de Requisitos

Ramesh&Jarke ponderam que mesmo existindo uma grande variedadede elos de rastreabilidade, eles podem ser agrupados em duascategorias básicas:

- relacionados ao produto: elos que descrevem propriedades erelacionamentos dos objetos. Elos deste tipo são subdivididos em elosde satisfação e elos de dependência;

- relacionados ao processo: elos relacionados ao histórico de açõesexecutadas no próprio processo. Elos deste tipo são subdivididos emelos de evolução e elos de rationale.

Elos de Satisfação - é assegurar que os requisitos sejam atendidos pelosistema, ou seja, a cada requisito foi associado um componente quedeverá atendê-lo.

Elos de Evolução - é registrar relacionamentos que levam de objetosexistentes para objetos novos ou modificados.

01/06/08 Daniel Villela

Gerência de Requisitos

Elos de Rationale - é representar as motivações subjacentes aos objetos existentes ou documentar as razões para evolução. Elos de Dependência - têm por propósito apoiar o gerenciamentode dependências entre objetos, freqüentemente impostas por restrições de recurso, de competência ou de compatibilidade, sendoúteis para registrar a composição e hierarquia dos objetos e apoiar ogerenciamento do impacto das alterações num objeto sobre os objetosque dele dependem.

01/06/08 Daniel Villela

Gerência de Requisitos

Meta-modelo proposto por ToranzoMeta-modelo proposto por Toranzo

A proposta de Toranzo para a rastreabilidade utiliza quatro estratégiasde trabalho:

- Apresentar uma classificação das informações a serem rastreadas;- Um meta-modelo para a rastreabilidade- Um modelo intermediário para o rastreamento de requisitos - Um processo para guiar o engenheiro de requisitos na aplicação das

outras três estratégias.

01/06/08 Daniel Villela

Gerência de RequisitosAs informações a serem rastreadas seriam classificadas em quatro níveis:

- Ambiental - congrega informações oriundas do contexto ambientalonde a organização está inserida e que podem afetar o sistema sendodesenvolvido.

- Organizacional - reúne informações relacionadas à organização(missão, objetivos, metas e padrões) e que podem impactar osrequisitos do sistema.

- Gerencial - agrega informações que permitem associar tarefas a requisitos, e que podem auxiliar a gerência do projeto.

- Desenvolvimento - abarca informações relacionadas aos diversos artefatos gerados no processo de desenvolvimento (documento de requisitos, diagramas, programas, casos de testes, ...)

01/06/08 Daniel Villela

Gerência de Requisitos

01/06/08 Daniel Villela

Gerência de Requisitos

Neste meta-modelo, o suporte à rastreabilidade identifica os seguintes tipos de elos:

Satisfação: indica que a classe de origem tem dependência de satisfação com classe de destino; Recurso: indica que a classe de origem tem dependência derecurso com classe de destino; Responsabilidade: registra a participação, responsabilidade e ação de pessoas sobre artefatos; Representação: captura a representação ou modelagem dos requisitos em outras linguagens; Alocado: classe de origem está relacionada à classe de destino, que representa um subsistema; Agregação: indica composição de elementos.

01/06/08 Daniel Villela

Gerência de Requisitos

Toranzo ainda propõe um modelo intermediário de rastreamento, que consolida observações da prática, de estudo de caso e da aplicação das 2 estratégias.

Comparação das propostas de Ramesh&Jarke e ToranzoComparação das propostas de Ramesh&Jarke e Toranzo

Os modelos se coincidem em 2 elos:

Satisfação: Para Ramesh&Jarke indicam que requisitos são atendidos pelo sistema, correspondem ao que Toranzo denomina de alocado eque indica alocação de requisitos a sub-sistema, ou ainda à Representação do requisito em outras linguagens;

Dependência: Para Ramesh&Jarke, indicam que objetos dependem uns dos outros por restrições de recursos, competência ou compatibilidade, registrando a composição e hierarquia dos objetos.Toranzo denomina tais elos de recurso, satisfação ou de agregação.

01/06/08 Daniel Villela

Gerência de Requisitos

O mérito maior da proposta de Ramesh&Jarke está na simplicidade dometa-modelo e na atenção colocada nos aspectos de evolução, registrando alterações sofridas pelos objetos rastreados, e as motivações para tais mudanças. Já a atenção colocada por Toranzo nosaspectos gerenciais do projeto é uma de suas contribuições, dado que oGerenciamento de Requisitos está intimamente ligado à gerência doprojeto.

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitos

A rastreabilidade de requisitos permanece citada como problema-chave entre indústria e comunidade de engenharia de requisitos.

Foi verificado o uso inadequado da pré-rastreabilidade como razão para problemas de rastreabilidade a longo prazo.

O trabalho de Ramesh&Jarke apresenta o resultado de uma longa pesquisa de rastreabilidade como tema central e esse trabalho reforçoua divisão entre usuários (desenvolvedores) sofisticados e normais(high-end e low-end users).

Usuários normais utilizam esquemas simples de rastreabilidade: registro de dependências entre requisitos, ligações entre requisitos e componentes que os atendem e ligações entre requisitos eprocedimentos de verificação. Usuários deste tipo (low-end users)desconsideram importantes informações relacionadas ao processo deRastreabilidade. Estes usuários entendem a rastreabilidade como umaimposição dos responsáveis pelo projeto.

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitos

O modelo de referência de usuários sofisticados (high-end users) mostra que eles empregam esquemas de rastreabilidade mais ricos e que também utilizam as informações de rastreabilidade de formas maisenriquecedoras, enfatizando aspectos relacionados ao processo. Ometa-modelo destes usuários envolve atividades associadas aogerenciamento de requisitos, ao desenho e alocação, verificação evalidação e gerenciamento do rationale.

Em organizações onde a preocupação com a qualidade, há dificuldadesno registro e na manutenção dos elos de rastreabilidade.

Linscomb registra que nunca encontrou empresas certificadas ao nível 2do CMM onde fossem trabalhadas matrizes de rastreabilidade completas, indicando que cada requisito foi atendido por objetos dedesenho, implementação e testes.

Relatos que envolvem observações de uma década, relatam o uso inadequado da rastreabilidade por parte dos desenvolvedores.

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitos Técnicas e ferramentas: suporte à questão da Técnicas e ferramentas: suporte à questão da

rastreabilidaderastreabilidade

Técnicas de rastreabilidade mais comuns está relacionada ao foco principal: referência cruzada ou documentos. Técnicas centradas em referencias cruzadas são simples de entender e utilizar e podem sersuportadas pelo uso de hipertexto, esquemas de numeração, indexaçãoou uso de tags ou ainda por matrizes de rastreabilidade.

Uma das técnicas mais comuns, o uso de referências cruzadas, podeutilizar uma matriz de rastreabilidade, implementada com uso de umaferramenta de uso geral, como um editor de textos ou uma planilhaeletrônica.

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitosA mesma técnica de referências cruzadas com uso de matriz de rastreabilidade também pode indicar dependências entre requisitos; aapresenta a ferramenta RequisitePro® registrando, na matriz derastreabilidade, interdependências entre requisitos funcionais e nãofuncionais em um sistema de controle de imobiliárias [Felicissimo02].

A técnica de referências cruzadas pode ainda ser implementada com o uso de elos de hipertexto, mostrando relacionamentos entre artefatos.Este tipo de rastreabilidade é encontrado no software C&L - Cenários eLéxico. Esta ferramenta, destinada a apoiar o trabalho do engenheirode software nas atividades do processo de desenvolvimento, criaautomaticamente elos de rastreabilidade entre símbolos do léxico ecenários da aplicação.

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitos

RequisitePro®

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitosExistem outras ferramentas:

DOORS - facilita a manipulação de requisitos para diferentes versões de um mesmo produto.

IBM/Rational - Inclui o RequisitePro® para o Processo de Requisitos eoutras ferramentas como o AnalystStudio para o gerenciamento deRequisitos.

DOORS/ScenarioPlus - possibilita elos entre requisitos e casos de uso,em múltiplas versões, para diferentes configurações de um mesmosistema.

Informações atualizadas sobre ferramentas para apoio ao registro derastreabilidade pode ser encontrada no site do INCOSE(http://www.incose.org/ProductsPubs/products/SEtools/tooltax/reqtrace_tools.html ).

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitos Processo associado à rastreabilidade Processo associado à rastreabilidade

No desenvolvimento de um sistema de software encontramos atividadesassociadas à rastreabilidade em quatro momentos:

Definição dos objetos e artefatos a serem rastreados, e também dos tipos de elos que serão registrados.

Registro dos elos ocorre durante todo o processo de desenvolvimento, quando objetos e artefatos rastreáveis serão relacionados através deelos, conforme os tipos já definidos.

Recuperação das entidades ligadas por meio desses elos deverá serrealizada para atender necessidades dos interessados em diferentesatividades: resolução de requisitos em conflito, identificação da origem de requisitos, alocação de requisitos a componentes, entre outros.

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitosEvolução compõem o processo de atualização dos elos de rastreabilidade, e são necessárias conforme surjam modificações nas entidades relacionadas ou nos própriosrelacionamentos estabelecidos entre elas.

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitos Pontos a considerar na definição e aplicação de um modelo de Pontos a considerar na definição e aplicação de um modelo de

rastreabilidaderastreabilidade

Pontos que podem auxiliar o gerente de projeto e sua equipe na tarefade definir e utilizar um modelo de rastreabilidade para odesenvolvimento de um software específico. Estes pontos sãorelacionados e discutidos na seqüência:

Definir no início do projeto, considerando a aplicação a ser desenvolvida,os objetos e artefatos a serem objeto de registro da rastreabilidade.

Identificar as ferramentas que apoiarão o processo de rastreabilidade e verificar a necessidade de treinar a equipe no uso dessas ferramentas.

Conscientizar a equipe da importância do processo de rastreabilidade.A falta de interesse dos desenvolvedores pode ser resultado do baixocomprometimento da organização com a atividade de rastreabilidade.

01/06/08 Daniel Villela

Prática da rastreabilidade de requisitosEstabelecer os momentos de registro e de controle da rastreabilidade.

Utilizar e avaliar o mecanismo de extração de elos, em relação às expectativas realizadas.

Analisar criticamente com a equipe, após a liberação do software, aefetividade do modelo de rastreabilidade adotado, corrigindo possíveisdistorções e possibilitando melhores escolhas para os próximos projetos.

01/06/08 Daniel Villela

Problemas em abertoUm importante aspecto pouco trabalhado na literatura pesquisada e analisada é a ligação entre evolução dos requisitos e rastreabilidade:alguns poucos trabalhos, como os relatados em [Leite95] e[Ramesh01] endereçam especificamente tipos de ligações que sãodiretamente relacionados à evolução dos requisitos e dos artefatos. Também a maioria das ferramentas disponíveis comercialmente poucooferece em termos de apoio ao tratamento dos elos de evolução erationale, que são aqueles relacionados ao processo de desenvolvimento.

Mostra um novo caminho para a rastreabilidade com a criação e evoluçãoautomática de elos entre requisitos expressos em linguagem natural emodelos de objetos expressos em UML.

A baseline de requisitos em uso pelo projeto deve ter flexibilidade para propiciar não apenas o registro e evolução dos elos, mas também arecuperação ou extração das entidades associadas através de um dostipos de elos de rastreabilidade estabelecidos para o projeto.