ANA MÁRCIA DEBIASI DUARTE
CORPO DE CONHECIMENTO PARA RASTREABILIDADE
NO DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE
Itajaí (SC), dezembro de 2014
UNIVERSIDADE DO VALE DO ITAJAÍ
CURSO DE MESTRADO ACADÊMICO EM
COMPUTAÇÃO APLICADA
CORPO DE CONHECIMENTO PARA RASTREABILIDADE
NO DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE
por
Ana Márcia Debiasi Duarte
Dissertação apresentada como requisito parcial à
obtenção do grau de Mestre em Computação Aplicada.
Orientador: Marcello Thiry Comicholi da Costa,
Dr.
Itajaí (SC), dezembro de 2014
FOLHA DE APROVAÇÃO
Esta página é reservada para inclusão da folha de assinaturas, a ser disponibilizada pela Secretaria do Curso para coleta de assinatura no ato da defesa.
Aos meus pais
Jair e Vilma
Não se pode escrever nada com indiferença.
(Simone de Beauvoir)
AGRADECIMENTOS
Agradeço ao meu orientador Marcello Thiry pela condução deste trabalho com leveza e sabedoria.
Aos membros da banca deste trabalho Gleison dos Santos Souza, Eros Comunello, Anita
Maria da Rocha Fernandes e Fabiane Barreto Vavassori Benitti agradeço pelas valiosas contribuições.
Agradeço a coordenação, todos os professores e a secretaria do curso.
Um especial agradecimento aos meus colegas pelos bons e divertidos momentos de convivência durante o período do curso.
Agradeço também minha família que amo muito e que permite que as conquistas tenham
importância.
CORPO DE CONHECIMENTO PARA RASTREABILIDADE NO
DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE
Ana Márcia Debiasi Duarte
Dezembro / 2014
Orientador: Marcello Thiry Comicholi da Costa, Dr.
Área de Concentração: Computação Aplicada
Linha de Pesquisa: Engenharia de Software
Palavras-chave: Rastreabilidade, Requisitos, Corpo de Conhecimento, Produto de Software.
Número de páginas: 275
RESUMO
A rastreabilidade é usada para garantir a consistência entre os artefatos criados durante o
desenvolvimento e a manutenção dos produtos de software. A definição de uma estrutura efetiva de
rastreabilidade depende de vários fatores, como arquitetura, técnica de modelagem, ferramentas, entre
outros. Embora muitos estudos sejam feitos nesta área, a aplicação da rastreabilidade nas organizações ainda representa um desafio. Os motivos que contribuem para o baixo uso da rastreabilidade
incluem as dificuldades de manter as informações atualizadas, de integrar todos os dados gerados
pelas equipes durante o processo de desenvolvimento e manutenção do software, além da falta de
ferramentas que implementem métodos e técnicas de rastreabilidade integradas com o processo de
desenvolvimento. No caso do desenvolvimento de software como produto, as manutenções evolutivas
representam grande parte do esforço no ciclo de vida e a dificuldade de manter a rastreabilidade ao
longo da vida do produto é potencializada. Este trabalho investigou diferentes formas de implementação da rastreabilidade na produção de software como produto, tanto na literatura através de uma
revisão sistemática, como através de um survey em organizações que desenvolvem software. Em seguida, as abordagens foram classificadas em categorias e um corpo de conhecimento foi construído
para fornecer informações para as organizações que desejam implementar a rastreabilidade na construção e manutenção de produtos de software. Este corpo de conhecimento foi denominado TraceBok
(Traceability Body of Knowledge) e foi avaliado por um conjunto de especialistas que permitiu identificar sua aplicabilidade. A avaliação evidenciou que alguns ajustes futuros devem ser realizados para
melhorar sua compreensão.
SOFTWARE PRODUCT TRACEABILITY BODY OF
KNOWLEDGE
Ana Márcia Debiasi Duarte
Dezembro / 2014
Advisor: Marcello Thiry Comicholi da Costa, Dr.
Area of Concentration: Applied Computer Science
Research Line: Software Engineering
Keywords: Traceability, Requirements, Body of Knowledge, Software Product.
Number of pages: 275
ABSTRACT
Requirement traceability is used to ensure consistency among the artifacts created during the
development and maintenance of software products. An effective traceability approach depends on
several factors such as architecture, technical modeling tools, among others. The implementation of
traceability in the organizations is still a challenge even many studies have been conducted on the
subject. We may point out some reasons for that: difficulties of maintaining updated information
about requirements and integrating all generated data from software development life-cycle, besides
the lack of commercial tools for implementing methods and techniques for integrated traceability to
the development process. Moreover, as requirements evolve, keeping tracking of the changes is also
difficult. The aim of this work is to evaluate traceability approaches focusing on software product traceability by a systematic review. We conduct a series of interviews with practitioners to complement
the evaluation. Based on this study, we categorize the approaches and we propose a body of knowledge (BoK). This BoK intends to assist software engineers to decide how to define implementation
of traceability in the development and maintenance of software products. Experts in traceability have
evaluated this BoK and we notice that it meets practitioners needs. However, some improvements
must be done in the future versions. We hope that the propose BoK helps practitioners to better apply
and understanding traceability in both academic and industry areas.
LISTA DE ILUSTRAÇÕES
Figura 1 – Estrutura de Produto e Projeto na Organização . . . . . . . . . .
23
Figura 2 – Etapas da Metodologia . . . . . . . . . . . . . . . . . . . . . . .
30
Figura 3 – Rastreabilidade para Frente e para Trás . . . . . . . . . . . . . .
35
Figura 4 – Rastreabilidade Pré e Pós Especificação de Requisitos . . . . . .
35
Figura 5 – Rastreabilidade Vertical e Horizontal . . . . . . . . . . . . . . .
37
Figura 6 – Rastreabilidade de Requisitos e SPL . . . . . . . . . . . . . . . .
38
Figura 7 – Modelo de Processo Genérico de Rastreabilidade . . . . . . . . .
40
Figura 8 – Ciclo de Vida da Rastreabilidade . . . . . . . . . . . . . . . . . .
41
Figura 9 – Fluxo das atividades de rastreabilidade . . . . . . . . . . . . . .
42
Figura 10 – Refinamento quantitativo da seleção dos trabalhos a partir dos estudos primários até a seleção final . . . . . . . . . . . . . . . . .
57
Figura 11 – Quantidade de estudos primários por ano de publicação . . . . . .
58
Figura 12 – Padrão de ciclo de vida adotado pelas abordagens . . . . . . . . .
59
Figura 13 – Padrão de modelagem adotado pelas abordagens . . . . . . . . .
60
Figura 14 – Artefatos obrigatórios nas abordagens analisadas . . . . . . . . .
62
Figura 15 – Artefatos rastreados nas abordagens analisadas . . . . . . . . . .
63
Figura 16 – Abrangência da rastreabilidade - Produto e Projeto . . . . . . . .
65
Figura 17 – Etapa do ciclo de vida do produto em que a rastreabilidade pode
ser aplicada . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
Figura 18 – Validação das abordagens analisadas . . . . . . . . . . . . . . . .
67
Figura 19 – Classificação dos trabalhos selecionados quanto a finalidade . . .
69
Figura 20 – Abrangência dos Trabalhos Selecionados . . . . . . . . . . . . .
72
Figura 21 – Parte do Ciclo de Vida para Uso da Rastreabilidade dos Trabalhos
Selecionados . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
Figura 22 – Fases para realização do Survey . . . . . . . . . . . . . . . . . .
76
Figura 23 – Estrutura do GQM . . . . . . . . . . . . . . . . . . . . . . . . .
79
Figura 24 – Estrutura do GQM do Survey . . . . . . . . . . . . . . . . . . .
80
Figura 25 – Quantidade de desenvolvedores nas organizações entrevistadas . .
89
Figura 26 – Áreas de atuação nas organizações entrevistadas . . . . . . . . .
90
Figura 27 – Idade dos produtos de software das organizações investigadas . .
90
Figura 28 – Modelos de qualidade adotados nas organizações investigadas . .
91
Figura 29 – Finalidade do uso da rastreabilidade em Ars e te . . . . . . . . . .
92
Figura 30 – Artefatos rastreados em Ars e te . . . . . . . . . . . . . . . . . .
93
Figura 31 – Padrões de modelagem compatíveis entre Ars e te . . . . . . . . .
93
Figura 32 – Ferramentas de rastreabilidade compatíveis entre Ars e te . . . . .
94
Figura 33 – Unidades organizacionais que usam rastreabilidade de software .
95
Figura 34 – Rastreabilidade em produtos de software . . . . . . . . . . . . .
96
Figura 35 – Unidades organizacionais que usam ferramentas automatizadas para
rastreabilidade de software . . . . . . . . . . . . . . . . . . . . .
96
Figura 36 – Fase do ciclo de vida do produto que pode ser usada a rastreabilidade 97
Figura 37 – Engenharia de sistemas e Engenharia de sistemas no contexto do
ciclo de vida de projeto . . . . . . . . . . . . . . . . . . . . . . . 104
Figura 38 – Relacionamento entre as áreas de conhecimento do BABOK . . . 105
Figura 39 – Grupo de processos de gerenciamento de projetos . . . . . . . . . 110
Figura 40 – Conteúdo das abordagens . . . . . . . . . . . . . . . . . . . . . 119
Figura 41 – Formação dos avaliadores do TraceBok . . . . . . . . . . . . . . 129
Figura 42 – Experiência dos avaliadores do TraceBok . . . . . . . . . . . . . 130
Figura 43 – Resultado de Q1.1 . . . . . . . . . . . . . . . . . . . . . . . . . 131
Figura 44 – Resultado de Q1.2 . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figura 45 – Resultado de Q1.3 . . . . . . . . . . . . . . . . . . . . . . . . . 132
Figura 46 – Resultado de Q1.4 . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figura 47 – Resultado de Q1.5 . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figura 48 – Resultado de Q1.6 . . . . . . . . . . . . . . . . . . . . . . . . . 133
Figura 49 – Resultado de Q1.7 . . . . . . . . . . . . . . . . . . . . . . . . . 134
Figura 50 – Resultado de Q1.8 . . . . . . . . . . . . . . . . . . . . . . . . . 134
Figura 51 – Resultado Geral de G1 . . . . . . . . . . . . . . . . . . . . . . . 135
LISTA DE QUADROS
Quadro 1 – String de Busca Genérica para a Revisão Sistemática . . . . . .
51
Quadro 2 – Codificação das ações de seleção dos trabalhos na 1a análise . . .
53
Quadro 3 – Codificação das ações de seleção dos trabalhos na 2a análise . . .
54
Quadro 4 – Extração dos dados na revisão sistemática . . . . . . . . . . . .
54
Quadro 5 – Identificação dos estudos primários . . . . . . . . . . . . . . . .
55
Quadro 6 – Resultados da Seleção dos trabalhos . . . . . . . . . . . . . . .
56
Quadro 7 – Trabalhos selecionados . . . . . . . . . . . . . . . . . . . . . .
57
Quadro 8 – Padrão de modelagem adotado pelos estudos analisados . . . . .
61
Quadro 9 – Ferramentas utilizadas pelas abordagens analisadas neste estudo
64
Quadro 10 – Classificação das abordagens selecionadas conforme sua finalidade 70
Quadro 11 – Abordagens para implantar rastreabilidade em produtos já construídos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
Quadro 12 – Classificação dos percentuais encontrados nas questões para interpretação . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
Quadro 13 – Cálculo para responder Q1.1 . . . . . . . . . . . . . . . . . . .
81
Quadro 14 – Cálculo para responder Q1.2 . . . . . . . . . . . . . . . . . . .
82
Quadro 15 – Cálculo para responder Q1.3 . . . . . . . . . . . . . . . . . . .
83
Quadro 16 – Cálculo para responder Q1.4 . . . . . . . . . . . . . . . . . . .
83
Quadro 17 – Cálculo para responder Q2.1 . . . . . . . . . . . . . . . . . . .
84
Quadro 18 – Cálculo para responder Q2.2 . . . . . . . . . . . . . . . . . . .
84
Quadro 19 – Cálculo para responder Q2.3 . . . . . . . . . . . . . . . . . . .
85
Quadro 20 – Cálculo para responder Q2.4 . . . . . . . . . . . . . . . . . . .
85
Quadro 21 – Resultado de G1 . . . . . . . . . . . . . . . . . . . . . . . . . .
95
Quadro 22 – Resultado de G2 . . . . . . . . . . . . . . . . . . . . . . . . . .
97
Quadro 23 – String de Busca para o Mapeamento Sistemático . . . . . . . . . 101
Quadro 24 – Extração dos dados no mapeamento sistemático . . . . . . . . . 102
Quadro 25 – Identificação dos estudos primários do mapeamento sistemático . 102
Quadro 26 – Áreas de conhecimento do SWEBOK . . . . . . . . . . . . . . . 104
Quadro 27 – Áreas de conhecimento do REBOK . . . . . . . . . . . . . . . . 106
Quadro 28 – Áreas de conhecimento extendidas do REBOK . . . . . . . . . . 106
Quadro 29 – Áreas de conhecimento do MCBOK . . . . . . . . . . . . . . . 107
Quadro 30 – Áreas de competência do TSPBOK . . . . . . . . . . . . . . . . 108
Quadro 31 – Competências do PSPBOK . . . . . . . . . . . . . . . . . . . . 109
Quadro 32 – Informações de Rastreabilidade de Requisitos . . . . . . . . . . 110
Quadro 33 – Áreas de conhecimento do PMBOK . . . . . . . . . . . . . . . 111
Quadro 34 – Identificação de estruturas dos corpos de conhecimento selecionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Quadro 35 – Identificação de estruturas de documento dos trabalhos selecionados117
Quadro 36 – Atributos para avaliação do corpo de conhecimento . . . . . . . 124
Quadro 37 – Métricas para avaliação da aplicabilidade do corpo de conhecimento125
Quadro 38 – Características dos entrevistados para avaliação do corpo de conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Quadro 39 – Resultado da avaliação TraceBok . . . . . . . . . . . . . . . . . 130
Quadro 40 – Resultado das questões aplicadas na avaliação do TraceBok . . . 131
Quadro 41 – Resultado apurado para a questão Q1.1 . . . . . . . . . . . . . . 131
Quadro 42 – Trabalhos - Fonte ACM . . . . . . . . . . . . . . . . . . . . . . 150
Quadro 43 – Trabalhos - Fonte IEEE . . . . . . . . . . . . . . . . . . . . . . 162
Quadro 44 – Trabalhos - Fonte Science Direct . . . . . . . . . . . . . . . . . 173
Quadro 45 – Trabalhos - Fonte Springer . . . . . . . . . . . . . . . . . . . . 176
LISTA DE ABREVIATURAS E SIGLAS
ACM
Association for Computing Machinery
AI
Estudos Primários não selecionados (trabalhos curtos)
AR
Estudos Primários não selecionados (trabalho não apresenta uma
abordagem de rastreabilidade)
AS
Estudos Primários Selecionados
AU
Estudos Primários não selecionados (trabalho não apresenta resultado da abordagem)
BABOK
Business Analysis Body of Knowledge
CMMI
Capability Maturity Model Integration
CPRE
Certified Professional for Requirements Engineering
DSM
Domain-Specific Domain
DSML
Domain-Specific Modeling Languages
EBT
Event-Based Traceability
ER
Especificação de requisitos
ES
Engenharia de Software
FCA
Formal Concept Analysis
FMBOK
Formal Methods Body of Knowledge
FMEA
Failure Mode and Effect Analysis
FTA
Fault Tree Analysis
GCT
Goal-Centric Traceability
GM
Goal Model
GQM
Goal Question Metrics
HAZOP
Hazard and Operability Analysis
IEC
International Electrotechnical Commission
IEEE
Institute of Electrical and Electronics Engineers
ISO
International Organization for Standardization
KA
Knowledge Area
MCBOK
Body of Knowledge on Model Checking for Software Development
MDD
Model Driven Development
MFMOD
Method Framework for Engineering Process Capability Models
MPS.BR
Melhoria de Processo de Software Brasileiro
OMG
Object Management Group
OSRMT
Open Source Requirements Management Tool
PMBOK
Project Management Body of Knowledge
PMI
Project Management Institute
PRO2PI
Process Capability Profile to drive Process Improvement
PSP
Personal Software Process
PSPBOK
Personal Software Process Body of Knowledge
QAM
Quality Adaptation Model
REBOK
Requirements Engineering Body of Knowledge
SEBOK
Systems Engineering Body of Knowledge
SPL
Software Product Line
SIG
Softgoal Interdependency Graphs
SMBOK
Software Measurement Body of Knowledge
SWEBOK
Software Engineering Body of Knowledge
TSPBOK
Team Software Process Body of Knowledge
TSP
Team Software Process
UML
Unified Modeling Language
XML
eXtensible Markup Language
SUMÁRIO
1
1.1
1.4
.
.
.
.
.
.
.
.
.
.
Procedimentos Metodológicos .
Estrutura da Dissertação
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2.1
2.2
2.3
2.4
2.5
FUNDAMENTAÇÃO TEÓRICA . . . . .
Requisitos de software . . . . . . . . . . .
Rastreabilidade . . . . . . . . . . . . . . .
Atividades relacionadas a rastreabilidade
A Importância da rastreabilidade . . . . .
Corpo de conhecimento . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3.1
ESTADO DA ARTE . . . . . . . . . . . . . . . .
Identificação de Abordagens de Rastreabilidade .
Método Utilizado . . . . . . . . . . . . . . . . . . . .
Protocolo de Pesquisa . . . . . . . . . . . . . . . . . .
Condução da Revisão . . . . . . . . . . . . . . . . . .
Resultados . . . . . . . . . . . . . . . . . . . . . . .
Classificação dos trabalhos . . . . . . . . . . . . . . .
Padrão de ciclo de vida . . . . . . . . . . . . . . . . .
Padrão de modelagem . . . . . . . . . . . . . . . . . .
Artefatos obrigatórios . . . . . . . . . . . . . . . . . .
Artefatos rastreados . . . . . . . . . . . . . . . . . . .
Ferramenta . . . . . . . . . . . . . . . . . . . . . . .
Abrangência . . . . . . . . . . . . . . . . . . . . . .
Etapa do ciclo de vida do produto . . . . . . . . . . . .
Contexto de validação . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1.1.1
1.1.2
1.1.3
1.2
1.2.1
1.2.2
1.3
1.3.1
1.3.2
3.1.1
3.1.1.1
3.1.1.2
3.1.2
3.1.2.1
3.1.2.2
3.1.2.3
3.1.2.4
3.1.2.5
3.1.2.6
3.1.2.7
3.1.2.8
3.1.2.9
INTRODUÇÃO . . . .
Problema de Pesquisa
Solução Proposta . . . . .
Delimitação do Escopo . .
Justificativa . . . . . . .
Objetivos . . . . . . .
Objetivo Geral . . . . . .
Objetivos Específicos . . .
Metodologia . . . . . .
Metodologia da Pesquisa .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
20
24
26
26
29
29
29
29
29
30
32
33
33
34
40
43
45
48
48
49
49
52
55
56
58
59
60
62
63
65
65
66
3.1.3
3.1.4
Ameaças a Validade . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Discussão e Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . .
67
68
3.2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
74
3.3.1
3.3.2
3.3.3
3.3.4
Survey . . . . . . . . . . . . . . . . . . . . . . . . . .
Metodologia . . . . . . . . . . . . . . . . . . . . . . . .
Planejamento do survey . . . . . . . . . . . . . . . . . . .
Execução do survey . . . . . . . . . . . . . . . . . . . . .
Resultados do survey . . . . . . . . . . . . . . . . . . . .
Contextualização . . . . . . . . . . . . . . . . . . . . . .
Resultado de G1 . . . . . . . . . . . . . . . . . . . . . .
Resultado de G2 . . . . . . . . . . . . . . . . . . . . . .
Análise dos resultados . . . . . . . . . . . . . . . . . . . .
Trabalhos Relacionados a Corpos de Conhecimento
Definição das questões de pesquisa . . . . . . . . . . . . . .
Condução da pesquisa . . . . . . . . . . . . . . . . . . . .
Seleção dos trabalhos . . . . . . . . . . . . . . . . . . . .
Descrição dos trabalhos . . . . . . . . . . . . . . . . . . .
4
4.1
4.2
4.3
CORPO DE CONHECIMENTO . . . . . . . . .
Método de construção do corpo de conhecimento
Projeto do modelo . . . . . . . . . . . . . . . . .
Versão preliminar do corpo de conhecimento . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
5.1
5.2
5.3
5.4.1
5.4.2
5.4.3
AVALIAÇÃO DO TRACEBOK
Planejamento . . . . . . . . . .
Execução . . . . . . . . . . . .
Ameaças à Validade . . . . . .
Validade Interna . . . . . . . . . .
Validade Externa . . . . . . . . . .
Resultados . . . . . . . . . . . .
Contextualização . . . . . . . . . .
Resultado de G1 . . . . . . . . . .
Análise dos resultados . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6.1
6.2
CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contribuições da Dissertação . . . . . . . . . . . . . . . . . . . .
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . .
138
139
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . .
141
3.2.1
3.2.2
3.2.3
3.2.4
3.2.4.1
3.2.4.2
3.2.4.3
3.2.4.4
3.3
5.3.1
5.3.2
5.4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75
76
88
89
89
91
94
97
99
100
100
103
103
114
114
116
120
122
123
127
128
128
128
129
129
130
135
137
SUMÁRIO
18
APÊNDICES
APÊNDICE A – TRABALHOS DA REVISÃO SISTEMÁTICA
149
150
APÊNDICE B – DETALHAMENTO DOS TRABALHOS SELECIONADOS NA 2A ANÁLISE - REVISÃO SISTEMÁTICA . . . . . . . . . . . . . . . . . . . 195
APÊNDICE C – QUESTIONÁRIO DO SURVEY DE RASTREABILIDADE NAS ORGANIZAÇÕES . . . . .
221
APÊNDICE D – QUESTIONÁRIO DO SURVEY PARA AVALIAÇÃO DO TRACEBOK . . . . . . . . . . . .
224
APÊNDICE E – TRACEBOK . . . . . . . . . . . . . . . . . . .
227
1 INTRODUÇÃO
O ciclo de vida de software é o conjunto de processos que descreve a ‘vida’ do produto de
software desde a concepção até a implementação, entrega, utilização e manutenção (PFLEEGER,
2004). A Engenharia de Software (ES) compreende métodos, técnicas e ferramentas para apoiar os
processos de desenvolvimento e manutenção de produtos de software (PRESSMAN, 2010). Cada
fase da produção de software é importante e cumpre um papel essencial para garantir a qualidade
do produto final. Durante o processo de produção são envolvidos profissionais com especialidades
distintas, métodos e técnicas que atendem necessidades particulares, além de técnicas específicas que
aplicam diferentes conceitos tecnológicos que evoluem constantemente. Durante o ciclo de vida do
software muitas informações são produzidas em forma de artefatos, iniciando pela identificação das
necessidades do produto e se estendendo até o fim da sua vida útil, que inclui manutenções corretivas, evolutivas e adaptativas destes produtos, que podem durar anos (KOTONYA; SOMMERVILLE,
1998), (KELLEHER; SIMONSSON, 2006). Um dos grandes desafios para manter a qualidade de
software é organizar e manter as informações dos artefatos produzidos. Neste aspecto, a localização
da informação tem um papel importante, pois indica os possíveis impactos das alterações ocorridas
tanto na fase de projeto quanto na fase de manutenção de software (PFLEEGER, 2004).
O tempo de vida de um produto de software pode variar muito. Por exemplo, um hotsite para
divulgar uma campanha publicitária pode ter sua vida útil estimada em um mês, já um software para
fazer o controle financeiro de uma empresa pode durar anos. Em todos os casos as modificações estão
presentes e podem acontecer durante a execução do projeto de construção. Sendo assim, existe uma
necessidade de adaptar requisitos por solicitação do cliente, ou por necessidade de adaptação no projeto do produto (design). A partir do momento em que o produto de software é colocado em produção,
mudanças oriundas de adaptações tanto de requisitos quando de projeto continuam acontecendo na
intensidade determinada pelas necessidades do ambiente onde o produto de software está inserido.
O registro das informações provenientes de necessidades e de decisões tomadas durante o
processo de construção possibilitam a compreensão de como o software foi construído (ASUNCION;
TAYLOR, 2007). A manutenção dos relacionamentos dos artefatos é crucial para a integridade das
informações e para avaliar os efeitos das mudanças que podem acontecer (PFLEEGER, 2004). A
20
habilidade de recuperar a relação existente entre os artefatos criados a partir dos requisitos e de suas
origens é definida como rastreabilidade (GOTEL; FINKELSTEIN, 1994) (IEEE, 2014) (ANQUETIL
et al., 2010).
Na engenharia de software, a rastreabilidade tem sido estudada principalmente sobre o tema
‘rastreabilidade de requisitos’. A rastreabilidade de requisitos é definida por Gotel e Finkelstein
(1994) como a habilidade de descrever e seguir a vida do requisito, nas duas direções para frente
(a partir do requisito) e para trás (até o requisito). O tema rastreabilidade gerou muitas publicações
sobre investigações e classificações em função de sua importância para a qualidade do produto ao
longo do seu desenvolvimento e principalmente da manutenção como em Rochimah et al. (2007),
Noll e Ribeiro (2007), Lago, Muccini e Vliet (2009),Winkler e Pilgrim (2010) e mais recentemente
em Rempel et al. (2013). Mesmo com todas as pesquisas, conceitos, ferramentas, o uso da rastreabilidade pelas organizações ainda é um desafio. Muitas organizações nem tentaram implementar
rastreabilidade, enquanto outras a fazem sem que seja sistemática (SAIEDIAN; KANNENBERG;
MOROZOV, 2013).
1.1
PROBLEMA DE PESQUISA
O estabelecimento da rastreabilidade como algo importante na engenharia de software não
é recente. Os estudos iniciaram na década de 1960 com Cleland-Huang, Gotel e Zisman (2012) e
se estenderam ao longo dos anos. Um dos desafios da engenharia de software, identificado desde a
criação do termo em 1968, é a aplicação de abordagens sistemáticas, disciplinadas e quantificáveis
para o desenvolvimento, operação e manutenção de software (IEEE-610.12, 1990). A rastreabilidade,
que aparece como um item importante para garantir a recuperação de informações geradas a partir do
processo de produção de software, atua principalmente na manutenção do software, facilitando a sua
evolução (ROCHIMAH et al., 2007).
Apesar dos benefícios que a rastreabilidade proporciona no desenvolvimento e manutenção
do software, não é fácil mantê-la. Características como a heterogeneidade dos artefatos, diferentes
ferramentas utilizadas e as mudanças rápidas, são desafios para manter a rastreabilidade atualizada
(ASUNCION; TAYLOR, 2007). Além desses fatores, Kannenberg e Saiedian (2009) ressaltam que
problemas com custos, mudanças organizacionais e a falta de suporte de ferramentas para rastreabilidade, também são desafios a serem vencidos.
21
Os artefatos possuem formatos e níveis de abstração diferentes, o que dificulta o estabelecimento das ligações entre eles. Como os artefatos podem ser produzidos e armazenados em diferentes
ferramentas ao longo do desenvolvimento, é um desafio estabelecer as ligações necessárias sem enfrentar dificuldades. Muitas organizações falham ao implementar a rastreabilidade de forma efetiva,
em função das dificuldades em usar e manter a ligação entre os artefatos (AZMI; IBRAHIM, 2011).
Além das dificuldades em definir e manter a rastreabilidade, outro aspecto chama a atenção.
A rastreabilidade é pouco utilizada nas organizações. Winkler e Pilgrim (2010) afirmam que os métodos de rastreabilidade não são usados como poderiam e que a falta de suporte de ferramentas é um
dos principais motivos. Apesar do reconhecimento da importância da rastreabilidade, Spanoudakis e
Zisman (2004) e Regan et al. (2012a) identificam que ela ainda é raramente criada nas organizações.
Alguns autores, como Anquetil et al. (2010), afirmam que as abordagens usadas na indústria
e que os protótipos acadêmicos não abordam a rastreabilidade no ciclo de vida completo da engenharia de software. Essa característica prejudica a prática da rastreabilidade nas organizações, pois
as soluções são descritas de forma parcial, contemplando parte do ciclo de vida ou em ambientes
muito específicos. Os softwares de rastreabilidade são criados, em geral, para apoiar as atividades de
análise de impacto, verificação de conformidade e validação de requisitos, no entanto, como afirma
Cleland-Huang et al. (2012), na prática, as ligações, traços, ou links são criados no final do projeto
especificamente para fins de homologação ou de certificação.
Os autores Gotel e Finkelstein (1994) fazem uma análise do problema da rastreabilidade de
requisitos e identificam fatores que contribuem para os problemas na rastreabilidade. O principal é
citado como a falta de padronização do entendimento do termo rastreabilidade de requisitos. Segundo
os autores, é difícil construir, por exemplo, ferramentas coerentes e consistentes se a compreensão
da concepção ou da cobertura da rastreabilidade não é formalizada na engenharia de software. Além
disso, não há um consenso sobre as causas dos problemas na rastreabilidade. Alguns motivos desses problemas são relacionados por Gotel e Finkelstein (1994) a partir de pesquisa na literatura: (i)
granularidade alta de entidades rastreadas; (ii) tecnologia de integração imatura; (iii) informações
escondidas e (iv) longevidade dos projetos.
A dificuldade de automatizar a geração das ligações entre os artefatos de forma clara e precisa
(do ponto de vista semântico) é apontada por Spanoudakis e Zisman (2004), além de afirmarem que na
maioria das abordagens, ambientes e ferramentas, assumem que as relações de rastreabilidade devem
22
ser identificadas manualmente, ou quando são feitas de forma automática, não conseguem atingir um
resultado semântico satisfatório. Desta forma, o custo de identificar as relações de rastreabilidade
fazem com que as organizações relutem em usar a rastreabilidade para tirar proveito dos benefícios
por ela oferecidos.
Outro ponto levantado por Winkler e Pilgrim (2010) é de, historicamente, a rastreabilidade ser
foco de pesquisa da comunidade de engenharia de requisitos. No entanto, a rastreabilidade é transversal no processo de desenvolvimento de software e abrange outras áreas de pesquisa como modelagem
e programação. Como as pesquisas nessas áreas acontecem por diferentes comunidades, na maioria das vezes, a comunicação entre elas é pequena, ocasionando a falta de integração dos resultados
colhidos nas pesquisas que atendem diferentes partes do ciclo de desenvolvimento do software.
Mais recentemente, Regan et al. (2012a) fizeram um estudo para identificar as barreiras para
se usar a rastreabilidade. Nesse estudo foram identificadas três categorias com as respectivas barreiras
associadas:
• Questões de medição: custo, falta de orientação, retorno de investimento, decadência da rastreabilidade e coleta de dados.
• Questões sociais: diferentes visões das partes interessadas, políticas internas e falta de comunicação/compreensão.
• Questões técnicas: questões de ferramentas, armazenamento e versionamento, e complexidade.
É possível observar nessa classificação que são muitas as barreiras e de diferentes naturezas.
Quando assume-se que a rastreabilidade deve ser considerada em todo o processo de desenvolvimento de software, assume-se também que ela deve ser gerenciada durante todo o ciclo de vida
do produto de software, e desta forma, deve ser planejada, construída e mantida durante todo o tempo
que o produto existir, pois é na evolução do software que os benefícios são potencializados. Esta
relação é ilustrada na Figura 1. A construção de um produto, assim como a sua evolução pode acontecer através de projetos. As informações armazenadas de projetos anteriores incluindo o seu histórico
de construção são usados na evolução do produto através de outros projetos. Expandir os limites da
rastreabilidade da unidade do projeto para a unidade do produto aumenta a complexidade do planejamento e também da gestão da rastreabilidade. Muitos produtos não possuem todas as estruturas
23
(partes de arquiteturas e design) quando iniciam a sua construção. Com o tempo crescem, aumentam
suas funcionalidades, adaptam-se às estruturas e ambientes.
Figura 1 – Estrutura de Produto e Projeto na Organização
Fonte: O Autor
Identificar todas as alternativas de rastreabilidade para aplicar em um determinado ambiente
pode significar um grande esforço em pesquisa e entendimento das diferentes possibilidades. A melhor escolha depende também da identificação das características da própria organização. Essa tarefa
não é simples e não conta com muitas fontes de pesquisa para os usuários finais.
As dificuldades relacionadas à rastreabilidade são muitas e dependem do contexto onde são
analisadas. No entanto, há um consenso com relação à dificuldade de aplicação nas organizações.
Azmi e Ibrahim (2011) afirma que existem dificuldades em usar e manter a rastreabilidade. A falta
de suporte de ferramentas é um dos pontos apontados por Winkler e Pilgrim (2010), além das organizações não explorarem os métodos disponíveis de rastreabilidade. O fato dos métodos atuais de
rastreabilidade serem parciais em relação ao ciclo de vida de software é um problema apontado por
Anquetil et al. (2010). Já Cleland-Huang et al. (2012) apontam o uso da rastreabilidade com o objetivo
de homologação e certificação e não pelos benefícios que podem trazer para a organização.
24
Os problemas não são localizados e podem ser identificados em organizações que trabalham
com diferentes dimensões na produção de software. Organizações que trabalham apenas com projetos
necessitam da rastreabilidade para controlar o impacto das mudanças em tempo de projeto. Organizações que produzem e mantêm um ou mais produtos de software usam a rastreabilidade como forma de
controle da evolução dos produtos. Organizações que trabalham com linhas de produtos de software,
além da complexidade de manter produtos, incluem a variabilidade que aumenta a complexidade do
controle, e por consequência, da estrutura da rastreabilidade.
Levando em conta a definição do problema apontada nesta seção, a pergunta de pesquisa a ser
respondida neste trabalho é: A criação de um conjunto de orientações e formas de implementação de
rastreabilidade pode ser usado forma efetiva na implantação da rastreabilidade em organizações de
produtos de software?
1.1.1
Solução Proposta
Como relatado pelos autores citados na problematização, são muitas as causas das dificuldades
encontradas no uso da rastreabilidade. Um desses itens é a dificuldade de aplicação da rastreabilidade
em função da heterogeneidade de artefatos a serem rastreados e dos ambientes onde os softwares
são desenvolvidos, além da falta de entendimento do que é rastreabilidade e do que ela representa
na produção do software. As organizações que possuem um ou mais produtos de software podem
se beneficiar da rastreabilidade para auxiliar na construção, mas principalmente na manutenção e
evolução destes produtos.
Como descrito no início da Seção 1.1, a rastreabilidade é considerada uma prática fundamental para a qualidade do software através do mapeamento das ligações entre as derivações dos
artefatos a partir dos requisitos. No entanto, a rastreabilidade ainda não é utilizada nas organizações com a frequência e da forma esperada para proporcionar benefícios na produção de software.
Existem pesquisas desenvolvidas com o intuito de melhorar o uso da rastreabilidade. Pode-se citar
Dubois, Peraldi-Frati e Lakhal (2010) que propõe um metamodelo, o DARWIN4REQ, capaz de rastrear requisitos em modelos heterogêneos nas fases de modelagem de requisitos, projeto e verificação
e validação. A STRADA, proposta por Egyed, Binder e Grunbacher (2007), é uma ferramenta para
auxiliar os engenheiros de software na exploração de traços (links) entre o código fonte e as funcionalidades do software através da execução de testes. Estes são exemplos de iniciativas para melhorar
o uso da rastreabilidade nas organizações.
25
Além do desenvolvimento de soluções específicas de rastreabilidade, é necessário que elas
estejam disponíveis em forma de abordagens que possam ser utilizadas pelas organizações. As abordagens de rastreabilidade são tratadas neste trabalho como um conjunto de práticas que podem ser
aplicadas em uma organização para tratar a rastreabilidade de requisitos no desenvolvimento de software. Algumas áreas de conhecimento contam com documentos de apoio que organizam e estruturam
as informações com o objetivo de ser referência para guiar a sua prática (OREN, 2005). Estes documentos são conhecidos como Body of Knowledge ou pela sigla BoK. O SWEBOK (IEEE, 2014) trata
da engenharia de software, o SEBOK (PYSTER; OLWELL, 2013) trata da engenharia de sistemas e o
PMBoK (PMI, 2013) trata da gerência de projetos. Estes são alguns exemplos de corpos de conhecimento que orientam as práticas nas respectivas áreas e permitem que os profissionais se orientem com
relação as boas práticas, processos e ferramentas disponíveis. Estes documentos foram publicados e
contêm o resultado de esforço de um conjunto de profissionais da academia e da indústria envolvidos
com a área de conhecimento.
Para contribuir com a criação de um corpo de conhecimento na área de rastreabilidade, este
trabalho propõe a elaboração de uma primeira versão de um documento para definir e orientar a adoção da rastreabilidade nas organizações que desenvolvem produtos de software. Essa iniciativa tem
por objetivo contribuir para esclarecer sobre os conceitos de rastreabilidade, suas diferentes classificações e possibilidades de uso em ambientes onde há a criação e evolução de produtos de software.
Em seguida, este documento poderá ser usado como base para evoluir o conhecimento de outros
profissionais, grupos de pesquisa, etc. A padronização dos termos e a organização das informações
relacionadas a rastreabilidade, considerando suas diferentes aplicações, ambientes e tecnologias no
contexto da construção e evolução de produtos de software pode contribuir na redução das dificuldades na elaboração de processos, técnicas e ferramentas de rastreabilidade. Neste contexto, assumem-se
como hipóteses que:
• A bibliografia atual fornece elementos suficientes para a elaboração de um corpo de conhecimento de rastreabilidade, com definições e classificações de conceitos considerando diferentes
ambientes e tecnologias de desenvolvimento de software.
• A elaboração de um corpo de conhecimento, relacionado à rastreabilidade de software para
organizações que produzem e mantêm produtos de software, pode contribuir para reduzir as
dificuldades na aplicação da rastreabilidade nas organizações.
26
Estas hipóteses são discutidas após a elaboração da estruturação do corpo de conhecimento que agrega
as informações necessárias para a rastreabilidade e a sua aplicação em organizações que produzem e
mantêm produtos de software.
1.1.2
Delimitação do Escopo
A proposta deste trabalho é criar um corpo de conhecimento que contemple os termos relaci-
onados à rastreabilidade de software em organizações que produzem e mantêm produtos de software.
Entende-se por corpo de conhecimento um guia com o agrupamento de conceitos, métodos e técnicas,
citando ferramentas identificadas ao longo da pesquisa, para a aplicação da rastreabilidade. São incluídos também os termos utilizados para a definição e elaboração da rastreabilidade nas organizações.
São consideradas ainda as classificações e agrupamentos relacionados às particularidades de modelos
e técnicas de desenvolvimento. O corpo de conhecimento proposto não inclui a proposição de novas
soluções de rastreabilidade, mas sim a seleção de abordagens existentes e organização na forma de
corpo de conhecimento. O principal objetivo é organizar as informações da área de conhecimento de
rastreabilidade de requisitos de software para facilitar o entendimento e por consequência a aplicação
da rastreabilidade nos diferentes ambientes de desenvolvimento de software como produto.
1.1.3
Justificativa
A norma ISO/IEC 12207 da ABNT (2009) estabelece uma arquitetura comum para o ciclo
de vida de processos de software e uma terminologia bem definida. Nessa norma a rastreabilidade é
contemplada e é considerada dentro do processo de desenvolvimento como um critério para a avaliação dos seguintes artefatos: (i) avaliação dos requisitos de sistema, (ii) arquitetura do sistema e dos
requisitos envolvidos, (iii) requisitos do software, (iv) arquitetura dos itens de software e os projetos
de interface e bases de dados, (v) projeto detalhado do software e requisitos de teste, (vi) código do
software e resultados do teste, (vii) plano de integração, projeto, código, testes, resultados dos testes e
documentação do usuário. O fato de a rastreabilidade ser um critério de avaliação em todo o conjunto
de etapas do desenvolvimento do software, dentro de seu ciclo de vida, denota a sua importância. É
através da rastreabilidade registrada que é possível manter as informações de relacionamento entre os
artefatos iniciais do software, identificados nos requisitos de sistema até os artefatos de codificação e
testes.
A rastreabilidade é uma prática, que quando bem aplicada em projetos, pode responder as
27
perguntas sobre a extensão do impacto causado nos artefatos do projeto. Esta prática é difundida
nos modelos de qualidade como CMMI1 e MPS.BR2 .Esses modelos consideram a demonstração da
rastreabilidade bidirecional como um resultado esperado desde os níveis mais iniciais de maturidade
nas empresas (ANQUETIL et al., 2010) (SOFTEX, 2011) (SEI, 2010). Isto mostra a importância
que a rastreabilidade possui em relação ao projeto, pois é nesta instância que os modelos tratam a
rastreabilidade. Para o gerenciamento dos requisitos, a rastreabilidade tem papel importante, pois
permite rastrear as informações desde as necessidades do cliente até os componentes do produto.
Além das definições presentes em diferentes referências teóricas para a produção de software,
vários autores citam a importância da rastreabilidade. Do ponto de vista da evolução do software, característica inerente aos produtos de software, a rastreabilidade tem um papel importante, facilitando a
evolução (ROCHIMAH et al., 2007). Os autores Anquetil et al. (2010) relacionam as principais vantagens do uso da rastreabilidade como: (i) relacionar artefatos com decisões de design correspondentes,
(ii) dar feedback para arquitetos e designers sobre o estado atual do desenvolvimento, permitindo que
reconsiderem decisões de design e rastreiem e compreendam defeitos, (iii) facilitar a comunicação
entre os stakeholders. Apesar das afirmativas na literatura de que a rastreabilidade é benéfica, existem
dificuldades associadas a sua implementação. A partir de um levantamento bibliográfico de estudos
de caso, Regan et al. (2012a) apresentam as principais barreiras na implementação da rastreabilidade.
A falta de orientação disponível para os profissionais estabelecerem a rastreabilidade em seus projetos e como escolher a melhor forma de fazê-lo é uma das dificuldades encontradas pelos autores
relacionada aos problemas de gestão da rastreabilidade. Os autores ainda afirmam a importância da
criação de um guia para orientar a definição do que rastrear e dos níveis de granularidade aplicados
na rastreabilidade.
Durante a realização de um mapeamento sistemático para identificar possíveis corpos de conhecimento relacionados ao tema principal dessa proposta, não foram identificadas publicações relacionadas diretamente a corpo de conhecimento ou guias para a o uso de rastreabilidade no contexto
de produto de software. Um trabalho que pode ser considerado relacionado diretamente a rastreabilidade e que propõe uma estrutura para auxiliar na implementação da rastreabilidade foi publicado por
1
2
CMMI foi criado pelo SEI - Software Engineering Institute na década de 80. É um modelo integrado de maturidade e
capacidade para a melhoria de processo, destinado ao desenvolvimento de produtos e serviços.
MPS.BR é um programa que tem como objetivo a melhoria de processo do software brasileiro. Criado em dezembro
de 2003, possui a Sociedade SOFTEX como coordenadora do programa. O MR-MPS - Modelo de Referência para
Melhoria do Processo de Software contém a documentação do modelo MPS em guias.
28
Ahmad e Ghazali (2007). Uma informação importante sobre a necessidade da criação de um corpo de
conhecimento encontrada durante a realização inicial dessa pesquisa foi a existência do grupo de pesquisa denominado CoEST3 (Center of Excellence for Software Traceability) que reúne um grupo de
pesquisadores sobre rastreabilidade de software de diferentes países. Encontra-se descrito na missão
do CoEST a criação de um corpo de conhecimento sobre rastreabilidade como forma de contribuir
para avançar na pesquisa sobre o tema. Muitos dos autores citados nesse trabalho e alguns dos mais
importantes, fazem parte do CoEST, como Jane Cleland-Huang, Olly Gotel, Andrea Zisman, Jane
Huffman Hayes, Giuliano Antoniol, Brian Berenbach e Alexander Egyed (COEST, 2014).
As práticas da rastreabilidade estão longe da maturidade e os benefícios não são aproveitados
pela indústria de software. Acompanhada dessa afirmação, Winkler e Pilgrim (2010) afirmam também
que a rastreabilidade é um instrumento que pode, além de rastrear artefatos de requisitos, servir como
suporte a todo o ciclo de desenvolvimento de software através da aplicação em outras áreas, como
por exemplo, gerenciamento de projetos e processos, engenharia de conhecimento e MDD (Model
Driven Development). Para isso, um corpo de conhecimento capaz de reunir os conceitos básicos
e que apoie os praticantes da disciplina de rastreabilidade, pode ser uma alternativa importante no
aumento da sua maturidade. A contribuição acontece através da disponibilização de uma primeira
versão de um corpo de conhecimento que serve de referência para a prática de uma especialidade,
como a de rastreabilidade de software.
Considera-se, na realização deste trabalho, a complexidade de definir um corpo de conhecimento sobre rastreabilidade no contexto de produtos de software. A falta de publicações específicas
que abordam o ciclo de vida da rastreabilidade e a grande variação das possibilidades de implementação, relacionadas aos diferentes métodos e técnicas de desenvolvimento tornam a tarefa mais
complexa. Espera-se que a contribuição da reunião dos diferentes conceitos relacionados à rastreabilidade, facilite a tarefa de definição e implementação da rastreabilidade nas organizações. A partir da
reunião dos conhecimentos sobre a rastreabilidade em produtos de software será possível estudar, avaliar, propor melhorias e conduzir trabalhos que agreguem mais conhecimento, facilitando a pesquisa
sobre o tema.
3
http://coest.org/
29
1.2
OBJETIVOS
Para a elaboração deste trabalho, são definidos objetivo geral e objetivos específicos, conforme
segue:
1.2.1
Objetivo Geral
Criar um instrumento, em forma de corpo de conhecimento sobre rastreabilidade de software
para organizações que produzem e mantêm produtos de software.
1.2.2
Objetivos Específicos
1. Identificar as abordagens de rastreabilidade de software existentes considerando as mais adequadas para aplicação nas organizações que mantêm produtos de software;
2. Identificar um padrão de utilização de rastreabilidade em organizações que produzem software
como produto através de um survey;
3. Definir a estrutura do corpo de conhecimento que deve ser produzido;
4. Elaborar uma versão do corpo de conhecimento;
5. Validar o corpo de conhecimento para avaliar a sua aplicabilidade em ambientes organizacionais.
1.3
METODOLOGIA
Esta seção apresenta os métodos utilizados e está dividida em metodologia da pesquisa e
procedimentos metodológicos.
1.3.1
Metodologia da Pesquisa
A pesquisa científica pode ser classificada de acordo com diferentes critérios de acordo com
sua natureza, objetivos ou procedimentos técnicos (WAZLAWICK, 2010). Neste trabalho o método
utilizado é o hipotético-dedutivo, pois estabelece um conjunto de hipóteses e pretende investigar as
suas confirmações. Para tanto será elaborado um corpo de conhecimento e disponibilizado para que
profissionais do desenvolvimento de software e da academia possam usufruir dessas informações. Isso
30
caracteriza a pesquisa do ponto de vista de sua natureza, como aplicada. Através da análise dos resultados da avaliação e validação das informações que compõem o corpo de conhecimento, o problema é
abordado de forma quantitativa e qualitativa. Os objetivos deste trabalho propõem uma pesquisa descritiva, pois estabelece o conjunto de conhecimento associado à rastreabilidade para uma população
constituída de organizações que desenvolvem e mantêm produtos de software. Esta pesquisa se aproxima da exploratória, pois permite, a partir do corpo de conhecimento, propor uma visão conjunta de
conhecimento de rastreabilidade aplicada às organizações que mantêm produtos de software.
1.3.2
Procedimentos Metodológicos
Para realização deste trabalho, uma sequência de passos foi determinada. A Figura 2 apresenta
as etapas que foram elaboradas. Cada etapa foi realizada para contribuir com o objetivo principal deste
trabalho.
Figura 2 – Etapas da Metodologia
Fonte: O Autor
A primeira parte do trabalho contém três etapas.
Inicialmente, é feita uma pesquisa exploratória na bibliografia, através de uma revisão sistemática baseada em Petersen et al. (2008). O objetivo desta revisão é fornecer elementos sobre as
31
abordagens de rastreabilidade propostas pela literatura. Essa etapa é importante no trabalho, pois
fornece os elementos básicos para a sequência do trabalho.
Na etapa seguinte, as abordagens identificados a partir dos resultados da revisão sistemática
são validados através da realização de um survey. O primeiro objetivo do survey consiste na avaliação
das informações colhidas durante a revisão sistemática. Essa avaliação é necessária para determinar a
quais informações e estruturas será dado prioridade ao construir o corpo de conhecimento. O segundo
o objetivo consiste em identificar quais características são comuns nas organizações que usam e que
não usam rastreabilidade. Dentre elas, também é identificado se existe um comportamento comum,
que permita selecionar quais as abordagens e para que universo deve ser estruturado o corpo de conhecimento. Essas informações são usadas na definição dos conceitos que farão parte do corpo do
conhecimento.
Outra etapa da primeira parte do trabalho é a identificação de trabalhos relacionados a corpos de conhecimento na área de engenharia de software já publicados. Esta identificação é realizada
através de um mapeamento sistemático na literatura. O mapeamento é mais aberto que a revisão sistemática, permitindo uma pesquisa mais genérica na literatura e a identificação dos trabalhos que
contribuem com o conhecimento já produzido para esta pesquisa.
Na segunda parte do trabalho, duas etapas são realizadas.
Primeiramente, a o corpo de conhecimento é proposto através dos resultados colhidos com o
auxílio da identificação de outros corpos de conhecimento. As atividades para a elaboração do corpo
de conhecimento são a classificação e definição das abordagens através da correlação entre elas, e de
sua definição, além da escrita e organização do corpo de conhecimento para posterior validação do
texto.
Finalmente, o corpo de conhecimento é avaliado por profissionais especialistas com condições
de analisar o documento e julgar sobre sua aplicabilidade. A avaliação se dá através da execução de
uma pesquisa que contém as seguintes fases: planejamento, execução e análise dos resultados. Essa
pesquisa também utiliza o conceito de survey e é realizada com profissionais que possuem conhecimento suficiente para emitir opinião sobre o conteúdo do corpo de conhecimento proposto.
32
1.4
ESTRUTURA DA DISSERTAÇÃO
Para atingir os objetivos definidos nesse trabalho, esse documento de dissertação é organizado
em 6 capítulos. O Capítulo 1 apresenta a introdução e esclarece o problema tratado, os objetivos gerais
e específicos, além de apresentar a metodologia utilizada para a realização da pesquisa. O Capítulo 2
apresenta a fundamentação teórica iniciando com uma visão de requisitos de software, aprofundando
os conceitos de rastreabilidade necessários para o entendimento da proposta aqui descrita e a importância que a rastreabilidade possui para o desenvolvimento de software como produto. Os conceitos
de corpo de conhecimento também são tratados neste capítulo. Grande parte do trabalho é descrito no
Capítulo 3 através da apresentação do estado da arte. Esse capítulo está organizado em 3 seções. A
primeira descreve os resultados da investigação responsável pela identificação de todos os conceitos e
abordagens de rastreabilidade relacionados a produção de software como produto, realizada através de
uma revisão sistemática, . A segunda seção descreve a realização do survey responsável pela validação
das informações colhidas na revisão sistemática para que sejam aplicadas no corpo de conhecimento.
Na terceira seção os corpos de conhecimento selecionados são relacionados, fruto de um mapeamento
sistemático realizado para a identificação de trabalhos já desenvolvidos e que possam contribuir com
esta pesquisa, através do conhecimento já produzido na área de corpo de conhecimento ou guia de
conhecimento em rastreabilidade de software como produto.
A proposta do corpo de conhecimento, contribuição maior deste trabalho, é descrito no Capítulo 4, onde a estrutura e os detalhes são exibidos e apresentados.
O Capítulo 5 apresenta a avaliação do corpo de conhecimento através da aplicação de um
survey com especialistas. Também são discutidos os detalhes da elaboração do corpo de conhecimento
e as dificuldades para a estruturação das informações.
Por último, no Capítulo 6, a conclusão do trabalho, as contribuições e os trabalhos futuros
para a evolução do conhecimento descrito nesta pesquisa são discutidos e apresentados.
Finalmente, as referências e os apêndices fecham a estrutura dessa dissertação.
2 FUNDAMENTAÇÃO TEÓRICA
Este capítulo apresenta os conceitos relacionados ao tema deste trabalho. São abordados os
conceitos de rastreabilidade, as suas classificações, as atividades envolvidas na rastreabilidade e a
importância do seu uso no processo de desenvolvimento de software. Em seguida são apresentados
os conceitos de corpo de conhecimento. A fundamentação teórica é complementada, neste trabalho,
pelo capítulo seguinte (Capítulo 3) que apresenta o Estado da Arte da rastreabilidade à partir de uma
revisão sistemática realizada sobre o tema.
2.1
REQUISITOS DE SOFTWARE
A engenharia de software é uma disciplina da engenharia relacionada a todos os aspectos da
produção de software (SOMMERVILLE, 2007). Logo nas primeiras fases do desenvolvimento de
software é necessário estabelecer os requisitos que determinam o comportamento através das funções
e restrições que o software deve ter (PFLEEGER, 2004), (SOMMERVILLE, 2007).
Um requisito de software é uma condição ou capacidade necessária de um usuário para resolver um problema ou atingir um objetivo (IEEE-610.12, 1990). Os requisitos de software podem ser
de dois tipos, funcionais e não-funcionais (IEEE, 2014), (BRAUDE; BERNSTEIN, 2010):
• funcional: Especifica um serviço provido pela aplicação, determina algo específico que pode
ser executado pelo usuário. “O sistema deve permitir a geração de uma matriz de rastreabilidade
a partir dos laços criados na aplicação”.
• não-funcional: Qualquer requisito que defina restrições de operação da aplicação. “O sistema
deve usar o padrão fornecido pelo cliente para criar as interfaces”.
Para identificar, documentar e gerenciar os requisitos durante a produção do software, um processo de gerência de requisitos é definido. As fases de elicitação dos requisitos, análise de requisitos,
especificação dos requisitos e validação dos requisitos são propostas no SWEBOK (IEEE, 2014). O
processo de gerência de requisitos possui um conjunto de atividades que compreende desde o início
34
do processo de identificação dos requisitos até a entrega do requisito completo. Análise do problema,
descrição do problema, prototipação e testes, e documentação e validação são fases propostas por
Pfleeger (2004) como um processo de requisitos. Já Sommerville (2007) propõe o conceito da engenharia de requisitos, que além de contar com as fases de estudo de viabilidade, elicitação e análise,
especificação e validação dos requisitos, apresenta uma fase de gerenciamento de requisitos. O gerenciamento se justifica, segundo o autor, pela característica de mudanças constantes nos software
desenvolvidos. Os requisitos devem ser atualizados para refletir as novas visões sobre os problemas
tratados pelos softwares. Nesse contexto de modificações dos requisitos, que podem acontecer por
solicitações dos usuários ou porque tecnicamente os ajustes são necessários, a rastreabilidade é fundamental, principalmente para medir o impacto das alterações (IEEE, 2014). Outras características,
classificações e a importância da rastreabilidade são apresentadas na próxima seção.
2.2
RASTREABILIDADE
Rastro é uma marca deixada por algo e rastrear é a capacidade de descobrir algo percorrendo
passo a passo as evidências (MERRIAM-WEBSTER, 1996). Na engenharia o termo rastro é composto de um artefato de origem, artefato alvo, e da relação entre eles (GOTEL et al., 2011 apud
REGAN et al., 2012a). Na engenharia de software, o termo rastreabilidade é encontrado acompanhado do termo “requisitos”, pois os requisitos expressam as necessidades e restrições de um produto
de software e a rastreabilidade permite descrever e seguir os passos de um requisito (KOTONYA;
SOMMERVILLE, 1998) (PFLEEGER, 2004), além de facilitar tarefas como a verificação e validação
dos requisitos. A rastreabilidade de requisitos pode acontecer em duas direções a partir do requisito
(GOTEL; FINKELSTEIN, 1994):
• para frente: do requisito para artefatos ou componentes criados à partir dele
• para trás: de um requisito para as fontes que o geraram
A Figura 3 representa esse conceito mostrando que a base para essa classificação é o requisito.
Outra forma de fazer esta classificação da rastreabilidade é dividi-la em dois tipos básicos,
conforme apresentado na Figura 4 (GOTEL; FINKELSTEIN, 1994).
35
Figura 3 – Rastreabilidade para Frente e para Trás
Fonte: Adaptado de Pinheiro (2004)
Figura 4 – Rastreabilidade Pré e Pós Especificação de Requisitos
Fonte: Gotel e Finkelstein (1994)
• Rastreabilidade pré especificação de requisitos (rastreabilidade pré-ER): que se preocupa
com os aspectos da vida do requisito antes de ser colocado em produção, ou seja, antes de
iniciar o seu processo de construção.
• Rastreabilidade pós especificação de requisitos (rastreabilidade pós-ER): que se preocupa
com os aspectos da vida do requisito após ser colocado em produção.
Esta distinção diz respeito a visão da rastreabilidade em relação ao ciclo de vida do desenvolvimento de software, levando em conta o início do processo de desenvolvimento com as necessidades
do usuário, até a criação de artefatos para atender os requisitos. Dessa forma, a rastreabilidade pré-ER
é usada para demonstrar que o produto atende aos requisitos dos interessados (stakeholders) através
da elicitação, discussão e acordo dos requisitos, até a sua inclusão no documento de requisitos. Já a
36
rastreabilidade pós-ER é usada para validar os requisitos e para estabelecer uma análise de impacto
através da criação de traços nas diversas etapas de transformação produzidas durante a construção do
software. (REGAN et al., 2012a) (WINKLER; PILGRIM, 2010).
A Figura 4 também representa e indica a complexidade oriunda das interações entre os elementos da rastreabilidade. Um relacionamento múltiplo entre os interessados nos requisitos e as suas
especificações na pré-ER, seguido dos relacionamentos múltiplos entre os artefatos criados no pós-ER
ressaltando que muitos níveis de especificações e representações são criados durante o desenvolvimento de um software, representado por (S1) e (Sn) na Figura 4.
Dependendo do contexto, ou de quais elementos são rastreados, uma outra classificação de
rastreabilidade pode ser feita, desta vez, considerando o nível de relacionamento entre os artefatos
rastreados. Segundo Lindvall e Sandahl (1996 apud SPANOUDAKIS; ZISMAN, 2004) e Regan et al.
(2012a), esta classificação é dividida em:
• Vertical: Cria a ligação entre artefatos no mesmo nível de abstração ou do mesmo modelo,
como entre requisitos ou versões de um determinado requisito em momentos diferentes do
desenvolvimento.
• Horizontal: Cria a ligação entre artefatos em diferentes níveis de abstração ou de modelos
diferentes, como entre requisitos e código.
A Figura 5 ilustra o conceito apresentado. No caso da rastreabilidade vertical, a relação pode
ser observada entre artefatos de requisitos que se encontram dentro do mesmo nível de abstração ou
modelo “Requirements”. Já a rastreabilidade horizontal é observada, por exemplo, entre os artefatos
“R1 e A1” do nível de abstração “Requirements” e “Analysis” respectivamente.
O conceito de rastreabilidade, a classificação como rastreabilidade para frente e para trás,
pré-ER e pós-ER e ainda a horizontal e vertical, formam a base conceitual da rastreabilidade.
A rastreabilidade ainda pode abranger os requisitos funcionais e os não funcionais. Como a
forma de especificação desses dois tipos de requisitos, normalmente a estratégia para a implementação
da rastreabilidade também é diferente (YRJÖNEN; MERILINNA, 2010). A rastreabilidade de requisitos funcionais está relacionada com o mapeamento entre objetos do sistema (PINHEIRO, 2004),
onde por exemplo um requisito funcional está relacionado a um modelo que está relacionado a um
37
Figura 5 – Rastreabilidade Vertical e Horizontal
Fonte: Lindvall e Sandahl (1996)
código fonte. Já a rastreabilidade de requisitos não funcionais está relacionada com aspectos de qualidade e restrições do sistema. O tratamento da rastreabilidade nesses requisitos pode ser mais difícil,
pois é difícil decidir quais os componentes devem ser levados em conta para realizar a rastreabilidade
(PINHEIRO, 2004). Segundo Kassab, Ormandjieva e Daneva (2009) a rastreabilidade em requisitos
não funcionais tem sido negligenciada, talvez pela maior complexidade e dificuldade de padronizar a
forma de rastreamento.
Outra aplicação da rastreabilidade de requisitos é feita em linhas de produto de software (Software Product Line - SPL). A SPL é uma abordagem recente de desenvolvimento de software e segundo Anquetil et al. (2010), um conjunto de produtos de software são derivados de um domínio. A
SPL representa uma abordagem estratégica que privilegia a reutilização (LAGO; MUCCINI; VLIET,
2009). A reutilização neste caso é baseada na criação de artefatos de domínio e não gerais como nas
abordagens de reutilização tradicionais. Essa abordagem promove a simplificação de alguns aspectos no desenvolvimento de software, principalmente o reuso, no entanto, aumenta a complexidade de
algumas áreas e a rastreabilidade é uma delas (ANQUETIL et al., 2010). A Figura 6 apresenta as
relações de dependência entre os artefatos de uma linha de produto.
É possível observar na Figura 6 os componentes reutilizáveis podem ser referenciados em
níveis diferentes, o que aumenta a complexidade da rastreabilidade.
Estudos de rastreabilidade identificam e descrevem os mecanismos e algoritmos que caracterizam grupos de abordagens de rastreabilidade. Rochimah et al. (2007) publicaram uma revisão com
esta caracterização que apresenta sete grupos que são brevemente descritos a seguir:
38
Figura 6 – Rastreabilidade de Requisitos e SPL
Fonte: Ajila e Kaba (2004)
• Information Retrieval Approach (IRA) - Abordagem de recuperação de informação: O foco
está na automatização da geração de traços por comparação de similaridade entre dois tipos
de artefatos. Os dois modelos mais usados são o probabilístico e o modelo de espaço de vetor. Os principais passos usados no IRA são: (i) preprocessamento, (ii) análise e indexação
dos artefatos, (ii) análise e representação dos artefatos correspondentes. Incluem no escopo da
rastreabilidade artefatos como requisitos, manuais, projetos, casos de teste e código fonte.
• Rule-Based Approach (RB) - Abordagem baseada em regras: Consiste em duas regras para
recuperar a rastreabilidade: (i) requisitos para modelo de objetos e (ii) requisitos entre requisi-
tos. Assume-se que os documentos estão em formato XML e as regras geradas também estarão
representadas no mesmo padrão de formato.
• Event-Based Approach (EB) - Abordagem baseada em eventos: São definidas as ligações entre
os artefatos e quando acontecem mudanças nos artefatos, alertas são emitidos para que ações
sejam to madas. O método envolve três componentes: (i) gestão dos requisitos, (ii) servidor de
eventos e (iii) gerência de assinantes. Esta técnica assume que a rastreabilidade foi estabelecida
anteriormente e que as mudanças são gerenciadas para que os rastros não se percam.
39
• Hypertext-Based Approach (HB) - Abordagem baseada em hipertexto: Baseado em modelo de
hipertexto que permite inclusive o versionamento dos links. Utiliza XML para representar o
modelo criado e aceita qualquer tipo de artefato para compor a rastreabilidade.
• Feature Model-Based Approach (FB) - Abordagem baseada em modelo de funcionalidades:
Parte do conceito da descrição da funcionalidade como um gráfico que é composto por todas
as variações dentro do conceito de linha de produto. Possui três categorias de funcionalidades:
funcional, interface e parâmetros. As funcionalidades são organizadas de forma hierárquica e
classificada da seguinte forma: (i) relações hierárquicas, onde as mais importantes estão mais
acima na hierarquia, (ii) relações de refinamento que descrevem relações de generalização e
especialização, além das agregações, e (iii) inclui ou exclui relacionamentos em função de decisões tomadas no produto. Inclui no escopo da rastreabilidade os requisitos e as funcionalidades
e os elementos de solução como modelos de objetos e código fonte.
• Value-Based Approach (VB) - Abordagem baseada em valor: É um framework para identificar
o valor que a rastreabilidade pode prover a organização. Provê um modelo técnico e econômico
para rastrear requisitos baseado em critérios. É composto por cinco processos: (i) definição dos
requisitos, (ii) priorização dos requisitos, (iii) empacotamento dos requisitos, (iv) ligação dos
requisitos e (v) avaliação, usada para gerar os traços. Esta técnica combina ações manuais e
semi automatizadas para obter a rastreabilidade.
• Scenario-Based Approach (SB) - Abordagem baseada em cenários: Esta abordagem usa informações de traços hipotéticos que devem ser confirmados manualmente. Ao executar casos
de teste, informações de execução são obtidas e combinadas com as hipotéticas para criar as
ligações e construir a rastreabilidade. Parte dos traços deve ser confirmado manualmente.
Este conjunto de técnicas usadas para criar a rastreabilidade em projetos de software foram
estudadas e avaliadas em vários aspectos por Rochimah et al. (2007) como propriedades temporais,
características do sistema, suporte a mudanças, entre outros. Todas as abordagens e técnicas apresentadas são conceitos, identificados em literatura, usados na implementação da rastreabilidade. Muitas
dessas abordagens são usadas em ferramentas prototipadas ou construídas para solucionar problemas
específicos de rastreabilidade.
40
2.3
ATIVIDADES RELACIONADAS A RASTREABILIDADE
Um dos resultados alcançados a partir de pesquisas na área de rastreabilidade de software
foi um modelo genérico de rastreabilidade de software, proposto por Cleland-Huang, Gotel e Zisman
(2012). Neste modelo são apresentadas as atividades essenciais para criar e utilizar a rastreabilidade de
software. As atividades de criação, uso, planejamento da gestão da estratégia da rastreabilidade e a sua
manutenção são apresentadas na Figura 7. Também é possível verificar a interação entre as diferentes
atividades. Todas interagem, definindo assim a importância da gestão integrada da rastreabilidade no
desenvolvimento de software.
Figura 7 – Modelo de Processo Genérico de Rastreabilidade
Fonte: Cleland-Huang, Gotel e Zisman (2012)
A rastreabilidade de requisitos pode ser utilizada em diferentes contextos no desenvolvimento
de software. Os autores Mäder e Gotel (2012) apresentam o ciclo de vida da rastreabilidade no contexto de uma proposta de abordagem que vem sendo desenvolvida há alguns anos. A Figura 8 mostra
as três grandes atividades que fazem parte do ciclo de vida proposto pelos autores.
É possível observar que antes do início do projeto existe a definição da rastreabilidade, a criação e manutenção da rastreabilidade acontece de acordo com a evolução do projeto. Na medida que
o projeto evolui as informações necessárias são consultadas através da atividade de uso da rastreabi-
41
Figura 8 – Ciclo de Vida da Rastreabilidade
Fonte: Mäder e Gotel (2012)
lidade.
O conceito do ciclo de vida apresentado na Figura 8, que inclui o planejamento da rastreabilidade, a manutenção dela durante a execução do projeto e depois o seu uso, é dominante nas abordagens propostas na literatura. Nos resultados apurados na revisão sistemática feita neste trabalho (ver
Figura 17), é possível identificar que a maioria das abordagens de rastreabilidade identificadas no
estudo tratam a rastreabilidade durante o processo de desenvolvimento do produto de software. Para
que a rastreabilidade seja tratada neste nível, é fundamental que siga o ciclo de vida apresentado na
Figura 8. Significa que para ser tratada durante o processo de desenvolvimento, um planejamento é
necessário, durante a construção do produto as ligações de rastreabilidade são mantidas e o seu uso é
permitido após a criação das ligações.
Em seu artigo Schwarz (2009) propõe a adaptação de um conjunto de atividades a partir dos
trabalhos de Pinheiro (1996) e Knethen e Paech (2002). As atividades propostas cobrem diferentes
aspectos da rastreabilidade e são definidas como: definição, identificação, registro, recuperação, utilização e manutenção. As atividades propostas, se executadas na ordem citada são compatíveis com
o ciclo de vida proposto por Mäder e Gotel (2012) e apresentado na Figura 8, pois a definição e a
identificação correspondem a fase de definição da rastreabilidade, o registro e a manutenção correspondem a fase de criação e manutenção e a recuperação e utilização correspondem a fase de uso da
rastreabilidade.
A Figura 9 é proposta como uma adaptação do ciclo proposto por Pinheiro (2004) para o MDD
(WINKLER; PILGRIM, 2010). O objetivo é apresentar um ciclo parar determinar as atividades neces-
42
sárias para construir a rastreabilidade quando a modelagem é feita usando a técnica Modeling Driven
Development. É possível observar em relação a Figura 8 que as atividades foram somente realocadas.
A correspondência é feita entre as quatro atividades da seguinte forma: “Planning and preparing”
correponde a “Defining traceability”; “Recording” corresponde a “Project with up-to-date traceabiity
according to definition”; “Using” corresponde a “Using traceability; e finalmente “Maintaining” corresponde a atividade “Creating and maintaining traceability”. O que é possível identificar na Figura 9
são dois fluxos de manutenção, um de conteúdo da rastreabilidade e outra da manutenção da estrutura
da rastreabilidade, que acompanha as mudanças no projeto que têm impacto na rastreabilidade.
Figura 9 – Fluxo das atividades de rastreabilidade
Fonte: Winkler e Pilgrim (2010)
No entanto, existem outras abordagens que propõem o uso da rastreabilidade após o produto
construído (total ou parcialmente). Neste caso o ciclo de vida da rastreabilidade pode ser diferente,
pois é possível fazer a ligação entre os artefatos em um segundo momento, depois do produto estar
construído total ou parcialmente. Isso significa que não há necessariamente um planejamento da rastreabilidade antes de iniciar o desenvolvimento do produto. Exemplos de abordagens que não seguem
o ciclo de vida proposto na Figura 8 são encontrados em Yu, Jurjens e Mylopoulos (2008) e Egyed,
Binder e Grunbacher (2007) que não incluem a definição e uso da rastreabilidade integrados com a
construção do projeto. Nestes casos, nos quais a rastreabilidade é aplicada após o produto construído,
são desenvolvidas técnicas que recuperam as informações necessárias para criar os traços e montar os
relacionamentos entre os artefatos depois de já existirem nos registros feitos durante a construção.
As atividades de prática da rastreabilidade relacionadas nesta seção possuem muito em co-
43
mum. Todas definem pelo menos quatro grupos de atividades que incluem a definição da rastreabilidade, a sua atualização, o seu uso ou recuperação das informações e a manutenção da rastreabilidade
no projeto. A exceção é quando a rastreabilidade não é planejada antes do projeto, e neste caso o
processo inclui definir as ligações da rastreabilidade, recuperá-las e usá-las.
2.4
A IMPORTÂNCIA DA RASTREABILIDADE
A rastreabilidade é considerada um dos meios pelos quais a gestão dos requisitos é realizada
(TORKAR et al., 2012). A gestão acontece através do acompanhamento do ciclo de vida dos artefatos
associados aos requisitos. A importância da rastreabilidade está associada a sua capacidade de manter
uma associação entre os artefatos realizados durante o processo de construção e manutenção de um
produto de software, permitindo assim o resgate destas informações para diferentes finalidades.
Juntamente com a importância da rastreabilidade estão os benefícios que o uso da rastreabilidade pode proporcionar. Esses benefícios são amplamente conhecidos atualmente e podem ser
observados nas áreas como gestão de projetos, visibilidade dos processos, verificação e validação,
além da manutenção (KANNENBERG; SAIEDIAN, 2009). Além destes benefícios, a melhora na
compreensão dos programas de computador, a identificação de componentes reusáveis e a análise de
impacto das mudanças, são apontados por Ferreira e Barros (2011). Muitas publicações apontam que
a rastreabilidade possui uma grande importância no processo de desenvolvimento de software, através da manutenção da consistência entre os artefatos produzidos (YRJÖNEN; MERILINNA, 2010),
(GOKNIL; KURTEV; BERG, 2010), (TORKAR et al., 2012), (REMPEL et al., 2013).
Após uma ampla pesquisa realizada por Regan et al. (2012b), alguns benefícios do uso da
rastreabilidade foram identificados e classificados em 10 itens, listados a seguir:
• Regulação: existem alguns modelos e normas que consideram rastreabilidade obrigatória
• Segurança: garantir a segurança em sistemas de missão crítica
• Competitividade: reduzir custo de produção e auxilia no reuso
• Produtividade e Qualidade: o reuso permite aumentar a produtividade e a qualidade se beneficia das informações geradas pela estrutura da rastreabilidade
• Validação: os requisitos podem ser mais facilmente validados
44
• Identificação dos interessados: auxilia na identificação através da associação com os requisitos
• Justificativa para decisões: auxilia associando as decisões aos artefatos que geraram as tomadas de decisões
• Gestão de mudança: auxilia tanto no rastreamento das solicitações e execução das mudanças,
como na análise de impacto para decidir se é viável
• Gestão de riscos e de projetos: a informação da rastreabilidade pode auxiliar nas atividades
de gestão do projeto e também na identificação e tratamento dos riscos
• Variabilidade na engenharia de linha de produto: auxilia na documentação das dependência
entre os diversos artefatos reutilizáveis.
Os modelos de qualidade como CMMI (SEI, 2010) e MPS.BR (SOFTEX, 2011) possuem
em seus níveis de maturidade primários, a identificação da rastreabilidade no processo de desenvolvimento das organizações. São destinados resultados esperados específicos para a avaliação da
rastreabilidade.
A rastreabilidade é tratada como área estratégica pelo CoEST1 (Center of Excellence for Software Traceability) que reune um grupo representativo da academia, indústria e governo para liderar as
pesquisas na área da rastreabilidade. Muitos dos pesquisadores são ativos na comunidade científica e
contribuem com publicações, resultado de suas pesquisas e experimentos. Alguns deles citados neste
trabalho, como: Jane Cleland-Huang, Olly Gotel, Andrea Zisman, Jane Huffman Hayes, Giuliano
Antoniol, Brian Berenbach e Alexander Egyed (COEST, 2014).
O CoEST possui um projeto chamado TraceLab2 que oferece uma base para experimentos
de rastreabilidade e para facilitar a comparação entre diferentes abordagens. TraceLab é similar a
outras ferramentas desenvolvidas como MatLab3 , Weka4 ou RapidMiner5 , com a característica de ser
totalmente voltada para a engenharia de software (TRACELAB, 2014).
1
2
3
4
5
http://coest.org
http://coest.org/index.php/tracelab/about-tracelab
http://www.mathworks.com/
http://www.cs.waikato.ac.nz/ml/index.html
http://rapidminer.com/
45
Uma das propostas feitas pelo CoEST é a construção de um Body of Knowledge de rastreabilidade6 . Durante a elaboração deste trabalho, o corpo de conhecimento ainda era inicial e demonstrava
a necessidade da existência na comunidade da engenharia de software de uma estrutura para permitir
a centralização dos conhecimentos adquiridos através dos trabalhos científicos e da indústria para o
bom uso da rastreabilidade.
2.5
CORPO DE CONHECIMENTO
Um corpo de conhecimento diz respeito à organização do conhecimento. Segundo Davis,
Shrobe e Szolovits (1993) o conhecimento pode ser entendido pelos cinco papéis que representa,
aqui resumidos: (i) primeiro, funciona como um substituto para a ação, determinando consequências
antes da ação; (ii) segundo, é um conjunto de compromissos ontológicos; (iii) terceiro, é uma teoria
fragmentada de raciocínio inteligente; (iv) quarto é um meio para a computação pragmaticamente
eficiente; (v) quinto, é um meio pelo qual dizemos coisas sobre tudo, ou seja um meio de expressão
humana.
De forma mais específica, um corpo de conhecimento é uma ontologia para um domínio profissional específico (BOWEN; REEVES, 2011). Desta forma, entende-se que um domínio de conhecimento pode ser organizado em forma de corpo de conhecimento.
Oren (2005) define corpo de conhecimento em dois conceitos, o primeiro como o conhecimento estruturado usado por membros de uma disciplina para guiar a sua prática, e o segundo como
agregação de conhecimento prescritiva em uma área particular e que uma pessoa para ser considerada
praticante ou dominadora do conhecimento deve conhecer este conjunto de prescrição.
Ao longo do tempo muitos corpos de conhecimentos foram formalizados e são utilizados
pelas comunidades de suas respectivas áreas. Neste trabalho é apresentado um levantamento das principais publicações relacionadas à área de software na Seção 3.3. Além de procurar por publicações
semelhantes àquela proposta neste trabalho, a seção também relatou o conjunto de corpos de conhecimentos relacionados a engenharia de software de alguma forma. É possível perceber que existem
publicações muito distintas em relação a abrangência do domínio. Algumas como o SWEBOK (IEEE,
2014) ou o SEBOK (PYSTER; OLWELL, 2013) tratam de domínios com uma grande abrangência,
a engenharia de software e engenharia de sistemas respectivamente, que possuem dentro delas uma
6
http://coest.org/bok/index.php/Main_Page
46
série de outros domínios tratados. Já outras publicações identificadas, como REBOK (AOYAMA et
al., 2010) que trata da engenharia de requisitos e que faz parte de um domínio maior do SWEBOK,
além do MCBOK (TAGUCHI et al., 2013) que trata de um domínio específico que é o modelo de
verificação no desenvolvimento de software.
O SWEBOK (Guia para o corpo de conhecimento de engenharia de software) (IEEE, 2014)
relata que todas as profissões são baseadas em corpos de conhecimentos e práticas recomendadas,
entretanto nem sempre são definidos. Em alguns casos são documentados em formas diversas como
por exemplo propósitos acadêmicos ou programas de certificação.
Alguns documentos trazem em si a definição do que é um corpo de conhecimento e o seu
propósito particular. O guia BABOK (IIBA, 2014) contém a descrição de práticas aceitas no campo
da análise de negócios. O documento evolui através da publicação de diferentes versões e conta com
a colaboração de pesquisas da comunidade acadêmica e de especialistas reconhecidos na área. Essa
é uma prática que acontece com a maioria dos documentos publicados pesquisados e encontrados
nessa pesquisa. A maioria possui uma instituição que apoia a manutenção e dá sustentação ao documento através da organização de pesquisadores e pesquisas que incrementam o conhecimento no
documento proposto. Além do BABOK, esse é o caso do EABOK (Guide to the (Evolving) Enterprise Architecture Body of Knowledge) (MITRE, 2004) que é um projeto do MITRE Corporation7 . A
associação GASQ8 (Global Association for Software Quality) é responsável pela publicação do REBOK (AOYAMA et al., 2010). O próprio SWEBOK (IEEE, 2014), uma referência que contém todas
as áreas de conhecimento que compõem a engenharia de software, é um projeto da IEEE Computer
Society9 .
Seguindo esta linha da criação de uma instituição para suportar o corpo de conhecimento
publicado, encontra-se o CoEST (Center of Excellence for Software Traceability) (COEST, 2014).
Esta instituição deseja liderar a pesquisa, educação e prática na área de rastreabilidade de software.
Este centro propõe a criação de um guia de corpo de conhecimento sobre rastreabilidade e o define
desta forma: Um recurso proposto pela comunidade de rastreabilidade, contendo referências, boas
práticas, relatos de experiência de rastreabilidade, entre outros. Até este momento, a criação do corpo
de conhecimento é uma proposta do CoEST e não foi implementado.
7
8
9
https://www.mitre.org/
http://en.gasq.org/
http://www.ieee.org/index.html
47
Outro aspecto importante observado nos corpos de conhecimento e evidenciado no Quadro
34 é a estrutura que estes documentos apresentam. Todos os selecionados a partir de um mapeamento
sistemático contém as áreas de conhecimento como elemento comum. Uma área de conhecimento
pode ser uma área mais específica de conhecimento, como é o caso de requisitos de software ou teste
de software no SWEBOK (IEEE, 2014). Nesse corpo de conhecimento cada área de conhecimento
(knowledge area) é tratada como um capítulo e possui um detalhamento grande de todo o seu conteúdo no documento. Também pode ser uma subdivisão das áreas de competências como é o caso do
TSPBOK (HUMPHREY et al., 2010) e do PSPBOK (POMEROY-HUFF et al., 2009), que para cada
área de conhecimento ainda possui uma especificação de conceitos e competências, pois nos seus contextos essas informações fazem sentido. Além destes, o PMBOK (PMI, 2013) apresenta as áreas de
conhecimento como sendo o conjunto de conhecimentos necessários para a execução de um projeto,
independente do seu processo. São exemplo de áreas de conhecimento do PMBOK, gerenciamento
de escopo do projeto, gerenciamento de tempo do projeto e gerenciamento de qualidade do projeto.
Cada área de processo é apresentada como um capítulo no documento e possui uma estrutura própria
com conteúdo relacionado ao conhecimento descrito.
Para o corpo de conhecimento proposto nessa dissertação, segue-se a tendência de reunir o
conhecimento de especialistas praticantes da área e da comunidade acadêmica na concepção do corpo
de conhecimento. A reunião destes conhecimentos e práticas vêm da revisão sistemática realizada e
as práticas organizacionais de um survey que confirma as práticas e identifica um padrão de uso da
rastreabilidade nas organizações, ambos apresentados no capítulo 3 deste trabalho.
3 ESTADO DA ARTE
A rastreabilidade é reconhecida como um tópico de interesse no desenvolvimento de software
desde 1968 e segundo Cleland-Huang, Gotel e Zisman (2012), Bohem apresentou o primeiro survey
sobre rastreabilidade em 1976. Desde então, muitos resultados de pesquisas e sugestões de processos
para melhorar o uso da rastreabilidade foram publicados, além da criação de ferramentas para suportar estes conceitos. Atualmente, a rastreabilidade é notadamente uma área da engenharia de software
que merece atenção pois é atribuída a ela a responsabilidade de facilitar a evolução do software (ROCHIMAH et al., 2007) e possibilitar a compreensão de como o software foi construído (ASUNCION;
TAYLOR, 2007).
Este trabalho tem o objetivo de elaborar um corpo de conhecimento para auxiliar na compreensão da rastreabilidade para aplicação em organizações de software. Houve aqui uma preocupação
inicial, descrita na primeira seção, de realizar uma pesquisa de modo sistemático para identificar as
abordagens e alguns detalhes que podem classificá-las, além das análise das características que envolvem a aplicação destas abordagens na prática. Com a finalidade de confirmar a prática das abordagens
e características da rastreabilidade identificadas na revisão sistemática, um survey foi planejado e executado e os resultados são apresentados da segunda seção desse capítulo. Para complementar o estado
da arte, um mapeamento sistemático foi utilizado para identificar os estudos já realizados na área de
rastreabilidade com finalidade de apresentar um corpo de conhecimento, guia, boas práticas para a implementação de rastreabilidade em organizações que produzem software como produto. O resultado
do mapeamento é apresentado na terceira seção desse capítulo.
3.1
IDENTIFICAÇÃO DE ABORDAGENS DE RASTREABILIDADE
A construção do corpo de conhecimento de rastreabilidade inicia, neste trabalho, pela identi-
ficação do conjunto de abordagens de rastreabilidade colhidas a partir de bibliografia analisada. Essas
abordagens consistem nas alternativas possíveis para implementação da rastreabilidade em organizações que mantêm produtos de software. Para a identificação das abordagens, neste trabalho, optou-se
pela realização de uma revisão sistemática pois assim, seria possível colher dados já publicados sobre
49
as abordagens disponíveis.
A revisão sistemática é um método que revisa estudos primários com o propósito de avaliar e interpretar todas as evidências relevantes de pesquisa disponíveis para uma pergunta específica
(NHMRC, 2000), (KITCHENHAM; CHARTERS, 2007). Segundo Brereton et al. (2007), a revisão
sistemática na engenharia de software é relevante em função do grande número de estudos realizados
nesta área. No contexto da pesquisa proposta neste trabalho, o objetivo da revisão sistemática é identificar, analisar e avaliar estudos sobre modelos (abordagens) de rastreabilidade propostos e/ou adotados
por organizações que trabalham com produtos de software. Na revisão sistemática a meta-análise é a
forma mais avançada de síntese dos dados. No entanto, para que seja aplicada a meta-análise é necessário que os dados sejam homogêneos (WOHLIN et al., 2012). Neste estudo, os dados colhidos não
são homogêneos e a análise aplicada foi selecionada entre as sugeridas por Wohlin et al. (2012), a
análise temática. O objetivo é identificar, organizar e apresentar padrões ou temas específicos a partir
dos estudos primários com riqueza de detalhes e interpretar diferentes aspectos do tópico estudado.
Nesta seção o método e os resultados da revisão sistemática são apresentados, em seguida
são identificadas as ameaças e validade do método e finalmente é conduzida uma discussão sobre os
resultados encontrados.
3.1.1
Método Utilizado
Para a realização da revisão sistemática, foi adotada a estrutura apresentada por Brereton et
al. (2007), que consiste de três fases: (i) planejamento da revisão, (ii) condução da revisão e (iii) documentação da revisão. Na fase de planejamento da revisão sistemática foram elaboradas as questões
de pesquisa e o protocolo de pesquisa. Também foram identificadas as fontes relevantes de pesquisa e
a efetividade do protocolo de pesquisa definido foi avaliada. Na fase de condução da revisão, os dados
foram extraídos e finalmente sintetizados à partir dos resultados obtidos. Na fase de documentação, a
escrita dos resultados foi realizada.
3.1.1.1
Protocolo de Pesquisa
Foram identificadas três perguntas de pesquisa. Uma principal PP e duas secundárias PS:
• PP 1 - Quais são as abordagens de rastreabilidade de requisitos de software propostas na literatura no contexto das organizações de desenvolvimento de software?
50
• PS 2 - As abordagens de rastreabilidade usadas no contexto de produto de software são as
mesmas usadas apenas no contexto de projetos de software?
• PS 3 - As abordagens de rastreabilidade propostas podem ser usadas depois da construção do
produto de software ter sido iniciado ou deve ser definida antes do início de sua construção?
A identificação das perguntas de pesquisa seguiram o método PICOC (KITCHENHAM et al.,
2008). Para todas as perguntas, a população, a intervenção e o contexto são os mesmos, conforme
segue:
• População: trabalhos publicados
• Intervenção: abordagens para rastreabilidade
• Contexto: indústria de qualquer porte e academia
Já para a comparação e os resultados são específicos para cada pergunta.
• Pergunta PP 1:
– Comparação: Diferentes tipos de abordagens utilizadas em organizações que desenvolvem produtos de software.
– Resultados: abordagens usadas nas organizações e sua classificação.
• Pergunta PS 2:
– Comparação: abordagens de rastreabilidade para organizações que desenvolvem produtos de software, considerando rastreabilidade apenas em projetos e considerando rastreabilidade na manutenção dos produtos de software.
– Resultados: abordagens de rastreabilidade usadas nas organizações e a cobertura da rastreabilidade.
• Pergunta PS 3:
– Comparação Aplicabilidade das abordagens de rastreabilidade em organizações que devem desenvolver produtos durante o processo de desenvolvimento e depois do produto já
estar desenvolvido.
51
– Resultados abordagens de rastreabilidade e sua aplicabilidade.
Depois do protocolo determinado foi definida a string de busca e identificadas as fontes de
pesquisa, a extração e sintetização dos dados foi realizada em seguida.
String de Busca
A partir dos termos identificados, uma string de busca genérica foi definida e é apresentada no Quadro
1.
Quadro 1 – String de Busca Genérica para a Revisão Sistemática
(traceability and requirement and software) and (tracing or product or approach or impact or
technique or tool or method or methodology or process or life cycle)
Fontes Relevantes de Pesquisa
A partir da definição dos termos de pesquisa, foram definidos os locais onde as pesquisas seriam realizadas. Foram identificadas quatro fontes de indexação de trabalhos relevantes para a área de pesquisa.
Para definir as fontes foi usado um trabalho semelhante de Torkar et al. (2012). Neste trabalho os
autores realizam uma revisão sistemática cobrindo o período de 1997 até 2007 sobre rastreabilidade
de requisitos com o objetivo de identificar os principais desafios do tema. Foram mantidas 3 das 5
fontes usadas por Torkar et al. (2012) (IEEE, ACM e Springer) e incluída a Science Direct. Desta
forma o conjunto de fontes indexadoras selecionadas são:
• ACM <dl.acm.org>
• IEEE <ieeexplore.ieee.org>
• ScienceDirect <sciencedirect.com>
• Springer <link.springer.com>
Para validar as fontes de pesquisa foi realizada uma pesquisa livre na internet usando o motor
de busca do google acadêmico1 . Nesta busca foram relacionados os principais trabalhos retornados e
comparados com àqueles retornados à partir da string de busca nas fontes indexadoras selecionadas.
1
http://scholar.google.com.br/
52
Os principais trabalhos estavam presentes e permitiram manter a string de busca e as fontes indexadoras selecionadas.
O período definido para a pesquisa compreende o período de 2007 a 2013.
A string de busca, apresentada no Quadro 1, foi adaptada conforme as necessidades de sintaxe
para cada uma das fontes de pesquisa utilizadas.
3.1.1.2
Condução da Revisão
A condução da revisão iniciou pela seleção dos estudos primários, conforme segue:
Seleção dos Estudos Primários
A seleção dos estudos primários que atenderam os critérios definidos de interesse deste trabalho foi
dividida em quatro etapas:
1. Seleção Inicial: Foram executadas as buscas a partir das strings definidas.
2. Exclusão das duplicações: Identificados e excluídos os trabalhos que foram recuperados em
mais de uma fonte de pesquisa ou que foram recuperados em duplicidade dentro das mesmas
fontes.
3. 1a análise: Seleção dos trabalhos a partir da leitura do título, palavras-chave e resumo.
4. 2a análise: Seleção dos trabalhos a partir da leitura completa dos trabalhos selecionados.
Ao final da quarta etapa (2a análise) os trabalhos que serviram para a extração dos dados
estava pronta.
A seguir as 4 etapas realizadas para a seleção dos estudos primários são detalhadas. Para a
realização da Etapa 1 (Seleção Inicial) os critérios usados são listados a seguir:
• O trabalho atende aos critérios definidos na string de busca executada nas fontes de pesquisa
definidas?
• O período de publicação do trabalho está compreendido entre janeiro de 2007 e setembro de
2013?
53
• O trabalho está disponível com texto completo?
Em seguida foi executada a Etapa 2 (Exclusão das duplicações) que manteve somente uma
ocorrência de cada trabalho selecionado, eliminando os trabalhos que foram recuperados em mais de
uma fonte indexadora.
O passo seguinte foi a execução da Etapa 3 (1a análise) que considerou os seguintes critérios
a partir da leitura do título, palavras-chave e resumo:
• O trabalho foi revisado por pares (árbitros) para publicação?
• Identifica pelo menos a proposta ou uso de uma abordagem de rastreabilidade de requisitos em
software no trabalho?
• O trabalho apresenta resultados do uso da abordagem proposta?
Para a classificação da 1a análise foi utilizada uma codificação que é apresentada no Quadro
2.
Quadro 2 – Codificação das ações de seleção dos trabalhos na 1a análise
Código
Descrição
AS
Trabalhos selecionados
AI
Trabalhos curtos, resumo expandido ou não possui texto completo
AR
Trabalho não identifica pelo menos uma proposta de abordagem
de rastreabilidade
AU
O Trabalho não apresenta o resultado da abordagem proposta
Ação
Selecionado
Não selecioando
Não selecionado
Não selecionado
Após a 1a análise, foi executada a Etapa 4 (2a análise) que selecionou os trabalhos finais
usados nesta dissertação. Todos os trabalhos selecionados na primeira análise foram lidos na íntegra.
Essa leitura, permitiu identificar com mais precisão os critérios usados na etapa 3, além de possibilitar
a coleta de todos os dados necessários. A classificação realizada nesta etapa seguiu a codificação
apresentada no Quadro 3.
Extração dos Dados
Após a Etapa 4 finalizada e o conjunto final dos trabalhos selecionado, os dados foram extraídos. O conjunto de dados extraídos é apresentado no Quadro 4. Também é apresentado neste quadro a
relação do dado extraído e da pergunta de pesquisa associada. Desta forma é possível identificar quais
54
Quadro 3 – Codificação das ações de seleção dos trabalhos na 2a análise
Código
Descrição
Selecionado Trabalhos selecionados
1
Trabalhos que apresentam revisões ou aprofundamentos em conceitos e classificações ou comparativos
2
Trabalhos que apresentam extensões de ferramentas para implementar conceitos já definidos ou são partes específicas de outras
abordagens
3
Trabalhos que usam a rastreabilidade como um recurso ou meio e
por isso não são especificados ou detalhados
Ação
Selecionado
Não selecionado
Não selecionado
Não selecionado
dados foram extraídos com o objetivo de responder quais questões de pesquisa definidas na revisão
sistemática.
Quadro 4 – Extração dos dados na revisão sistemática
Dados extraídos
Descrição
Referência bibliográfica
Padrão de ciclo de vida
Padrão de modelagem
Artefatos obrigatórios
Artefatos rastreados
Ferramenta
Abrangência
Etapa do ciclo de vida
do produto
Contexto de validação
Dados completos da referência bibliográfica do trabalho
Padrão de ciclo de vida identificado no trabalho, usado no
desenvolvimento do software. Ex.: Cascata, Iterativo
Padrão ou técnica de modelagem identificado no trabalho,
usado no desenvolvimento do software. Ex.: MDD (Model
Driven Development), UML (Unified Modeling Language)
Conjunto de artefatos que devem obrigatoriamente serem
desenvolvidos dentro da modelagem proposta para que a
abordagem funcione.
Conjunto de artefatos que a abordagem proposta rastreia
Ferramenta proposta na abordagem, seja de mercado, protótipos ou proposta pelos autores
Identifica se a abordagem é proposta no âmbito do projeto
ou considera o produto no contexto da rastreabilidade
Identifica se a abordagem proposta deve ser usada durante
a etapa de construção do produto (projeto de construção)
ou se pode ser aplicada a produtos de software já prontos
(manutenção)
Identifica em que contexto a abordagem foi validada. Ex.:
em projetos reais, estudos de caso, etc.
Questão de
pesquisa
PP 1
PP 1
PP 1
PS 2 e PS 3
PP 1
PP 1
PS 2
PS 3
PS 2 e PS 3
Sintetização dos Dados
Para realizar a síntese dos dados, as informações coletadas nas abordagens de rastreabilidade
selecionadas foram agrupadas e analisadas para identificar a relação entre si. Além disso, a relação
entre as abordagens também foi analisada, principalmente com o objetivo de responder as questões de
55
pesquisa, mas também de identificar pontos importantes para a elaboração da sequência dos estudos.
A sintetização aconteceu principalmente através do agrupamento e da sumarização das informações. Sempre que aplicável uma análise quantitativa foi apresentada através de gráficos e percentuais. Em todos os casos uma análise qualitativa descritiva foi apresentada. A Sintetização seguiu a
proposição de uma análise temática, conforme descrito na introdução da Seção 3.1 neste capítulo.
3.1.2
Resultados
A execução das pesquisas nas fontes selecionadas recuperou 641 trabalhos. No registro dos
trabalhos recuperados, observou-se que alguns trabalhos apareciam em duas fontes. Foi o caso da
ACM que apresentou trabalhos que foram publicados na IEEE. Nesta situação o trabalho foi considerado somente em sua fonte original de publicação e a duplicação foi identificada e desconsiderada.
Além disso, a fonte ACM apresentou 2 trabalhos que foram retornados com duplicidade na mesma
pesquisa. Depois da exclusão das duplicações, os números consolidados indicam 560 estudos identificados para análise e posterior seleção. O Quadro 5 apresenta os números separados por indexador.
Nessa mesmo Quadro 5 são apresentadas as classificações realizadas na primeira análise. Nesta classificação, AS representa os estudos primários selecionados e AI, AR e AU não foram selecionados
por motivos que são detalhados, juntamente com a identificação de todos os trabalhos retornados a
partir da string de busca aplicada, no Apêndice A.
Quadro 5 – Identificação dos estudos primários
Fonte
ACM
IEEE
AS
AI
AR
AU
Total
20
5
36
1
62
58
4
89
1
152
Science
rect
11
6
11
0
28
Di-
Springer
Total
13
15
290
0
318
102
30
426
2
560
A primeira análise realizada, que teve como objetivo a seleção ou não dos trabalhos, consistiu de uma leitura básica do título, palavras-chave, resumo para identificar se o trabalho atendia os
critérios para responder as perguntas de pesquisa. Feita esta primeira seleção, foi realizada a segunda
análise e neste caso, uma leitura completa do trabalho aconteceu para identificar se a abordagem proposta tinha relação com esta pesquisa. A definição dos critérios e os motivos de seleção na primeira e
segunda análise são detalhados no Apêndice A.
56
A primeira linha do Quadro 5 apresenta os trabalhos selecionados para a segunda análise. O
total de trabalhos selecionados foi 102. Todos esses trabalhos foram lidos na íntegra para que uma
seleção criteriosa pudesse ser feita. Este foi um trabalho fundamental para a realização da pesquisa,
pois os critérios aplicados na leitura dos trabalhos permitiram selecionar aqueles que contribuiriam
com as informações para a escrita do corpo de conhecimento de rastreabilidade, objetivo maior deste
trabalho.
Os números e os respectivos percentuais dos trabalhos recuperados e analisados na 1a e 2a
análises são apresentados no Quadro 6. A fonte de pesquisa com maior número de trabalhos recuperados foi a Springer, com 318 trabalhos. Já a IEEE obteve a maior contribuição em quantidade de
trabalhos selecionados, 13, que representa metade do total de 26 trabalhos selecionados na 2a análise. Por outro lado, Springer que na recuperação representou 56% acabou por representar 0,5% dos
selecionados para este estudo.
Quadro 6 – Resultados da Seleção dos trabalhos
Fonte
Recuperado
ACM
62 (11,1%)
IEEE
152 (27,1%)
Science Direct
28 (5%)
Springer
318 (56,8%)
1 a análise
20 (5,6%)
58 (10,4%)
11 (1,9%)
13 (2,3%)
2 a análise
8 (1,4%)
13 (2,3%)
2 (0,4%)
3 (0,5%)
A Figura 10 apresenta graficamente os resultados quantitativos do processo de refinamento
que aconteceu durante a revisão sistemática. Foram recuperados inicialmente 641 trabalhos, que após
a exclusão das duplicações resultaram em 560. Destes, após a 1a análise foram selecionados 102, que
após a 2a análise foram 26 selecionados para a síntese.
A lista completa dos 26 trabalhos selecionados é apresentada no Quadro 7. São identificadas
referências dos trabalhos selecionados e a seu respectivo indexador, de onde o trabalho foi recuperado.
3.1.2.1
Classificação dos trabalhos
A Figura 11 apresenta a quantidade de estudos primários recuperados por ano, no período
definido no protocolo. Nos anos entre 2007 e 2010, os números se mantiveram entre 55 e 82 trabalhos
57
Figura 10 – Refinamento quantitativo da seleção dos trabalhos a partir dos estudos primários até a
seleção final
Fonte: O Autor
Quadro 7 – Trabalhos selecionados
Referência
(DELATER; PAECH, 2013)
(FERREIRA; BARROS, 2011)
(ASUNCION; FRAN COIS; TAYLOR, 2007)
(MALAVOLTA; MUCCINI; REKHA, 2011)
(SOUSA et al., 2008)
(YRJÖNEN; MERILINNA, 2010)
(GOKNIL; KURTEV; BERG, 2010)
(LEVENDOVSZKY et al., 2010)
(CLELAND-HUANG; HAYES; DOMEL, 2009)
(DUBOIS; PERALDI-FRATI; LAKHAL, 2010)
(ZIFTCI; KRUEGER, 2011)
(HONG; KIM; LEE, 2010)
(CLELAND-HUANG et al., 2012)
(MOON et al., 2007)
(BUCHGEHER; WEINREICH, 2011)
(SATYANANDA et al., 2007)
(EGYED; BINDER; GRUNBACHER, 2007)
(MADER; GOTEL; PHILIPPOW, 2009)
(SANCHEZ et al., 2011)
(YU; JURJENS; MYLOPOULOS, 2008)
(CLELAND-HUANG; MARRERO; BERENBACH, 2008)
(NEJATI et al., 2012)
(LEE et al., 2010)
(JIRAPANTHONG; ZISMAN, 2009)
(MERILINNA; YRJÖNEN; RÄTY, 2012)
(SCHWARZ; EBERT; WINTER, 2010)
Fonte de Pesquisa
ACM
ACM
ACM
ACM
ACM
ACM
ACM
ACM
IEEE
IEEE
IEEE
IEEE
IEEE
IEEE
IEEE
IEEE
IEEE
IEEE
IEEE
IEEE
IEEE
Science Direct
Science Direct
Springer
Springer
Springer
58
publicados. Em 2011 este número subiu para 110 e até o mês de setembro de 2013, mês da realização
desta pesquisa, já havia 97 publicações que foram recuperadas por esta pesquisa.
110
110
97
88
79
66
44
82
75
62
55
22
0
2007
2008
2009
2010
2011
2012
2013
Figura 11 – Quantidade de estudos primários por ano de publicação
Fonte: O Autor
Cada trabalho selecionado foi detalhado em forma de quadro com o conteúdo colhido após
a leitura. O Apêndice B relaciona todos os quadros referentes aos trabalhos selecionados. A seguir
são apresentadas as análises realizadas com as informações colhidas de cada estudo selecionado. A
organização está feita por tópico analisado.
3.1.2.2
Padrão de ciclo de vida
O padrão de ciclo de vida foi investigado para identificar possíveis restrições das abordagens
de rastreabilidade selecionadas em relação ao uso de um ciclo de vida específico. Dos 26 trabalhos
selecionados, apenas 3 possuem restrições. A Figura 12 apresenta a distribuição dos padrões de ciclo
de vida adotados nos trabalhos selecionados. No trabalho de Delater e Paech (2013) fica explícito que
pode ser usado o modelo cascata ou iterativo incremental.
Quando as abordagens são mais específicas, como no caso de Cleland-Huang, Marrero e Berenbach (2008), que propõe o Goal-Centric-Traceability, mesmo que não seja especificado um padrão
conceitual de ciclo de vida, algumas fases aparecem como obrigatórias: Goal Model, QAMs, Produção de artefatos de design e codificação. Outro padrão identificado no estudo de Schwarz, Ebert e
Winter (2010) apresenta o ReDSeeDS project (Requirements Driven Software Development System),
proposto pelos autores e baseado no padrão cascata. Além desses, os outros 23 estudos não apresen-
59
tam restrições com relação ao padrão de ciclo de vida ou são indiferentes.
Figura 12 – Padrão de ciclo de vida adotado pelas abordagens
Fonte: O Autor
3.1.2.3
Padrão de modelagem
Com relação ao padrão de modelagem usado nos trabalhos selecionados, 8 deles (destacados
no gráfico apresentado na Figura 13) não definem um padrão a ser usado, quer dizer, podem ser usados
diferentes padrões de modelagem combinados com a abordagem de rastreabilidade proposta. Dentre
os citados, o padrão mais comum é o uso da UML (Unified Modeling Language) que aparece em
5 trabalhos, de Dubois, Peraldi-Frati e Lakhal (2010), Asuncion, Fran cois e Taylor (2007), Mader,
Gotel e Philippow (2009), Yu, Jurjens e Mylopoulos (2008) e Schwarz, Ebert e Winter (2010) .
Outro padrão de modelagem observado é o MDD (Model Driven Development) que aparece
como padrão em 3 trabalhos. Desses, Yrjönen e Merilinna (2010) e Levendovszky et al. (2010) propõe
diretamente o uso do padrão e Lee et al. (2010) apresenta uma adaptação do MDD.
A maior parte dos trabalhos analisados, no entanto, trata de aplicações mais específicas, como
para linhas de produto, aparecem também padrões de modelagem mais específicos, como é o caso
de Satyananda et al. (2007), que propõem uma combinação de padrões de modelagem para rastrear
modelo funcional e arquitetural, considerando variabilidade em linha de produtos de software. Assim,
são 10 abordagens que propõem padrões de modelagem específicas em suas propostas de abordagem
60
de rastreabilidade.
Figura 13 – Padrão de modelagem adotado pelas abordagens
Fonte: O Autor
A lista completa das abordagens e a referência do trabalho analisado é apresentada no Quadro
8.
3.1.2.4
Artefatos obrigatórios
A documentação de artefatos é uma característica da rastreabilidade. Essa documentação pode
ser definida como a identificação e o registro dos artefatos que se deseja rastrear. É impossível rastrear
artefatos dentro de um contexto sem que estes artefatos sejam conhecidos ou identificados. O que foi
observado nos trabalhos selecionados é que todos possuem orientações bem específicas quanto aos
artefatos que devem ser obrigatoriamente documentados. Outra observação é que diferentemente de
modelo de ciclo de vida ou de padrão de desenvolvimento específico, a documentação dos artefatos
a serem rastreados é obrigatória em todos os modelos apresentados. Em algumas abordagens propostas, não aparecem artefatos específicos como obrigatórios, mas, ainda assim, a abordagem obriga
que aqueles artefatos que desejam ser rastreados devem ser identificados antes da rastreabilidade ser
executada, como é o caso de Cleland-Huang, Hayes e Domel (2009), Cleland-Huang et al. (2012) e
Hong, Kim e Lee (2010).
61
Quadro 8 – Padrão de modelagem adotado pelos estudos analisados
Padrão de modelagem
Qtde
Referência da abordagem
(CLELAND-HUANG; HAYES; DOMEL, 2009)
(ZIFTCI; KRUEGER, 2011)
Não apresenta
restrição
8
(HONG; KIM; LEE, 2010)
(CLELAND-HUANG et al., 2012)
(MOON et al., 2007)
(BUCHGEHER; WEINREICH, 2011)
(EGYED; BINDER; GRUNBACHER, 2007)
(GOKNIL; KURTEV; BERG, 2010)
(DUBOIS; PERALDI-FRATI; LAKHAL, 2010)
UML
ou adaptação
5
(ASUNCION; FRAN COIS; TAYLOR, 2007)
(MADER; GOTEL; PHILIPPOW, 2009)
(YU; JURJENS; MYLOPOULOS, 2008)
(SCHWARZ; EBERT; WINTER, 2010)
(YRJÖNEN; MERILINNA, 2010)
MDD
3
(LEVENDOVSZKY et al., 2010)
(LEE et al., 2010)
MUSE
1
(DELATER; PAECH, 2013)
Relacional
1
(FERREIRA; BARROS, 2011)
FORFAMEL, ACME e FCA
1
(SATYANANDA et al., 2007)
MDE e V3CMM
1
(SANCHEZ et al., 2011)
Goal Model, QAM e GCT
1
(CLELAND-HUANG; MARRERO; BERENBACH, 2008)
ADD
1
(MALAVOLTA; MUCCINI; REKHA, 2011)
Processo de Negócio, Requisitos,
Tarefas e Interfaces de Usuário
1
(SOUSA et al., 2008)
SysML
1
(NEJATI et al., 2012)
FORM (extensão)
1
(JIRAPANTHONG; ZISMAN, 2009)
DSM
1
(MERILINNA; YRJÖNEN; RÄTY, 2012)
62
No restante dos trabalhos selecionados, o conjunto de artefatos obrigatórios a serem documentados não apresenta um padrão de comportamento. Mesmo aquelas abordagens que sugerem o
uso da UML possuem em sua proposta de implementação artefatos variados que necessitam ser documentados.
Figura 14 – Artefatos obrigatórios nas abordagens analisadas
Fonte: O Autor
3.1.2.5
Artefatos rastreados
Algumas abordagens selecionadas aceitam que os artefatos sejam genéricos, ou seja, podem
rastrear qualquer artefato desejado. Pode-se afirmar neste caso, que estas abordagens são mais flexíveis do ponto de vista do conjunto de artefatos a serem rastreados e o total está destacado na Figura
15. São estas abordagens: Hong, Kim e Lee (2010), Cleland-Huang et al. (2012) e Moon et al. (2007).
É possível observar na Figura 15 que em 17 trabalhos os requisitos estão presentes no conjunto de
artefatos rastreados. As abordagens que incluem os requisitos (RF) como artefatos rastreados são
Delater e Paech (2013), Dubois, Peraldi-Frati e Lakhal (2010), Ziftci e Krueger (2011), Asuncion,
Fran cois e Taylor (2007), Buchgeher e Weinreich (2011), Mader, Gotel e Philippow (2009), Sanchez
et al. (2011), Malavolta, Muccini e Rekha (2011), Sousa et al. (2008), Yrjönen e Merilinna (2010),
Goknil, Kurtev e Berg (2010) e Schwarz, Ebert e Winter (2010); requisitos de segurança (RS) em
Nejati et al. (2012) e Sanchez et al. (2011); requisitos não funcionais (RNF) em Merilinna, Yrjönen e
Räty (2012); funcionalidades ou features em Schwarz, Ebert e Winter (2010) e Egyed, Binder e Grunbacher (2007); Nas seis abordagens identificadas como específicos, possuem um conjunto particular
63
de artefatos que são rastreados e dentre eles não aparecem requisitos de nenhuma natureza (como
funcionais, não funcionais, de negócio, etc).
Figura 15 – Artefatos rastreados nas abordagens analisadas
Fonte: O Autor
Fica evidente na análise realizada que não é possível identificar um padrão no conjunto de
artefatos rastreados nas abordagens selecionadas, e que além de serem diferentes, atendem a necessidades muito específicas das abordagens propostas.
3.1.2.6
Ferramenta
Na análise das ferramentas associadas as abordagens selecionadas, foram identificados 3 trabalhos que não citam ferramentas e cujas abordagens não mencionam o uso de ferramenta. Não é
possível afirmar que as ferramentas são dispensáveis, somente que nos trabalhos elas não foram mencionadas Ferreira e Barros (2011), Cleland-Huang et al. (2012) e Moon et al. (2007), conforme apresentado no Quadro 9. Algumas abordagens apresentam o desenvolvimento de extensões realizadas no
ECLIPSE
2
(DELATER; PAECH, 2013), (BUCHGEHER; WEINREICH, 2011) e (MALAVOLTA;
MUCCINI; REKHA, 2011). Em Yu, Jurjens e Mylopoulos (2008) uma IDE do ECLIPSE é citada,
mas a ferramenta possui outros componentes. Dois trabalhos apresentam plugins para o Enterprise
Architect 3 , são eles Schwarz, Ebert e Winter (2010) e Nejati et al. (2012), no entanto, as ferramentas
são distintas.
2
3
http://www.eclipse.org/
ihttp://www.sparxsystems.com.au/products/ea/index.html
64
Quadro 9 – Ferramentas utilizadas pelas abordagens analisadas neste estudo
Ferramenta
Qtde
IDE ou plugin
do ECLIPSE
3
Referência do trabalho
(DELATER; PAECH, 2013)
(BUCHGEHER; WEINREICH, 2011)
(MALAVOLTA; MUCCINI; REKHA, 2011)
(FERREIRA; BARROS, 2011)
Não indica
3
(CLELAND-HUANG et al., 2012)
(MOON et al., 2007)
(YRJÖNEN; MERILINNA, 2010)
NFR Framework + MetaEdit
2
BASEX
1
(CLELAND-HUANG; HAYES; DOMEL, 2009)
DOORS
1
(DUBOIS; PERALDI-FRATI; LAKHAL, 2010)
FORTA
1
(ZIFTCI; KRUEGER, 2011)
MS SQL, MS Share Point e MS
Office
1
(ASUNCION; FRAN COIS; TAYLOR, 2007)
Nexcore Requirement Management
1
(HONG; KIM; LEE, 2010)
FCA Tool
1
(SATYANANDA et al., 2007)
STRADA
1
(EGYED; BINDER; GRUNBACHER, 2007)
TraceMaintainer
1
(MADER; GOTEL; PHILIPPOW, 2009)
Safety-Requirements-Trace-Tool
(SRTT)
1
(SANCHEZ et al., 2011)
UMLSec (IDE ECLIPLSE +
Cruise Control
1
(YU; JURJENS; MYLOPOULOS, 2008)
Poirot
1
(CLELAND-HUANG; MARRERO; BERENBACH, 2008)
UsiXML
1
(SOUSA et al., 2008)
Protótipo Ferramenta (não nomeada)
1
(GOKNIL; KURTEV; BERG, 2010)
SafeSlice (plugin EA)
1
(NEJATI et al., 2012)
GReAT
1
(LEVENDOVSZKY et al., 2010)
NuRS + TRACE
1
(LEE et al., 2010)
XTraQue
1
(JIRAPANTHONG; ZISMAN, 2009)
MOLA Tool + API EA
1
(SCHWARZ; EBERT; WINTER, 2010)
(MERILINNA; YRJÖNEN; RÄTY, 2012)
65
Também aparecem ferramentas como BASEX, FORTA, DOORS, STRADA, TRACE e XTraQue, além de outros protótipos e propostas que não são detalhadas nos trabalhos analisados.
3.1.2.7
Abrangência
A análise da abrangência tem especial importância para este trabalho, pois responde, das
abordagens selecionadas, quais se aplicam a manutenção dos produtos e quais são restritas ao período
da duração do projeto, desconsiderando a evolução do produto. A Figura 16 apresenta a distribuição
da quantidade de abordagens classificadas.
Figura 16 – Abrangência da rastreabilidade - Produto e Projeto
Fonte: O Autor
Os resultados da análise apontam que a maioria das abordagens, mais precisamente 17, atendem ambos os universos, de projeto e de produto. Outras seis abordagens consideram a evolução do
produto e não somente o projeto. Somente 3 das abordagens selecionadas são exclusivas para o âmbito do projeto e não contam em seu detalhamento, com a abrangência do produto em sua evolução.
Não é possível, no entanto, afirmar que estas abordagens não poderiam ser estendidas para o âmbito
do produto, pois os estudos analisados não tem esta preocupação.
3.1.2.8
Etapa do ciclo de vida do produto
A análise da etapa do ciclo de vida do produto investigou, dentro das abordagens selecionadas,
se para funcionar deveriam ser definidas já no projeto do produto ou se poderiam ser aplicadas após
66
o produto (ou parte dele) já ter sido construído. A distribuição é apresentada na Figura 17.
Figura 17 – Etapa do ciclo de vida do produto em que a rastreabilidade pode ser aplicada
Fonte: O Autor
Nesta análise, apenas 4 entre as 26 abordagens aceitam que a rastreabilidade seja feita após a
construção do produto, são Ziftci e Krueger (2011), Egyed, Binder e Grunbacher (2007), Yu, Jurjens e
Mylopoulos (2008) e Goknil, Kurtev e Berg (2010). Nessas abordagens a rastreabilidade é construída
partindo de informações (dos artefatos construídos) já armazenadas em um repositório.
Nas outras 22 abordagens é necessário que a rastreabilidade seja definida antes de iniciar a
construção do produto e que todas as fases da construção do produto considerem a manutenção da
rastreabilidade para que a abordagem seja concluída.
3.1.2.9
Contexto de validação
O foco deste estudo está relacionado a aplicação da rastreabilidade em organizações que constroem e mantém produtos de software. Neste contexto, algo importante de avaliar nas abordagens
selecionadas é o contexto em que aconteceu a validação. Para a análise, as validações foram separadas em aplicações de abordagens reais e de abordagens simuladas ou exemplos de aplicação da
abordagem. A Figura 18 apresenta a distribuição no gráfico das formas de validação das abordagens.
Os resultados apontam para 12 abordagens validadas em projetos reais, com software que
foram construídos usando a abordagem proposta ou em produtos já prontos. Outras 10 abordagens
foram validadas apenas em ambientes simulados ou então, usaram exemplos para experimentar e tirar
67
Figura 18 – Validação das abordagens analisadas
Fonte: O Autor
algumas conclusões sobre o seu uso. Além destas, outras 4 abordagens propostas planejaram validações, mas não executaram, ou não apresentam os resultados da validação, ou ainda, fizeram apenas
testes parciais sem um resultado consistente da abordagem proposta.
3.1.3
Ameaças a Validade
A realização de uma revisão sistemática possui elementos de subjetividade que devem ser
considerados em sua realização. Nesta pesquisa foram identificadas algumas ameaças e os tratamentos dados reduziram seu impacto na pesquisa. A qualidade dos estudos primárias é avaliada através
da validade interna e externa, como segue:
Validade Interna
O projeto e a condução do estudo são apresentados na Seção 3.1.1. Neste trabalho foi privilegiado
o desenho do método capaz de estruturar as necessidades de informações a partir das questões de
pesquisa da revisão sistemática. Algumas limitações foram percebidas durante o projeto e a condução
dos estudos. A escolha das fontes de pesquisa, mesmo que baseada em estudo anterior já realizado
nesta área (TORKAR et al., 2012), pode deixar de colher trabalhos importantes para a pesquisa.
68
Independente das fontes, esta é uma limitação que deve ser considerada. Para minimizar este fato,
uma pesquisa livre foi realizada no google acadêmico4 para verificar o retorno para a pesquisa com
a mesma string de busca usada nas fontes indexadoras utilizadas. O resultado nas duas fontes foram
muito semelhantes (retornaram os mesmos trabalhos) e por isso as fontes foram preservadas. Outro
aspecto a ser considerado é a seleção dos trabalhos a partir dos estudos primários. Houve uma leitura
dos trabalhos e por ser um trabalho de dissertação de mestrado, executado por um pesquisador, não
houve outra intervenção como orientado na prática da revisão sistemática. Para este fato, os critérios
objetivos definidos amenizam, mas não eliminam este viés.
Validade Externa
Neste estudo, os detalhes da execução que permitem a reprodução da revisão são descritos na Seção
3.1.1 e são complementados no Anexo A. A principal fragilidade identificada na validade externa é o
julgamente feito pelo pesquisador no momento de selecionar os trabalhos que atendem aos critérios
definidos durante o estudo. Este julgamento é feito a partir da interpretação do pesquisador e pode
haver diferenças se aplicada com outra interpretação. Para minimizar o grau de subjetividade desta atividade, foram selecionados critérios que permitiram identificar de forma mais clara as características
dos trabalhos selecionados no método do estudo.
3.1.4
Discussão e Conclusão
A realização da revisão sistemática permitiu identificar e extrair informações de um con-
junto de estudos primários relacionados às abordagens de rastreabilidade utilizadas na construção
de software no contexto de organizações que desenvolvem e mantêm produtos de software, além de
responder as três perguntas elaboradas para esta revisão sistemática.
A pergunta principal (PP 1) da revisão sistemática é respondida a partir da seleção das abordagens após a segunda análise realizada nos trabalhos identificados, usando os critérios já descritos
neste capítulo. O agrupamento permite identificar que as abordagens propostas na sua maioria, 15
entre as 26 selecionadas (57,7%), propõem abordagens cuja finalidade é identificada como rastreabilidade de requisitos. Outros 11 (42,3%) trabalhos apresentaram as abordagens de rastreabilidade com
finalidades específicas de forma variada. Os detalhes da distribuição podem ser verificados no Qua4
http://scholar.google.com.br/
69
dro 10 que apresenta os trabalhos classificados conforme a finalidade, acompanhada da ferramenta
utilizada na informatização.
A classificação das abordagens apresenta também outra informação importante, quando analisada sob o aspecto da abrangência. Três abordagens classificadas não apresentam descrição compatível para aplicação da rastreabilidade no nível do produto de software, ficam restritas somente a
duração de um projeto. As abordagens são representadas por um asterisco ao lado da referência do
trabalho no Quadro 10.
O gráfico com a distribuição dos trabalhos classificados por finalidade é apresentado na Figura
19. É importante observar que as soluções de rastreabilidade, após a identificação e classificação da
finalidade, indicam que uma solução genérica de rastreabilidade agrupa várias abordagens propostas.
No entanto, quando há finalidades específicas do uso da rastreabilidade nos softwares desenvolvidos,
ou finalidades particulares do desenvolvimento de software que devem ser cobertas pela rastreabilidade, são propostas abordagens particulares. Este resultado confirma a dificuldade de encontrar soluções de rastreabilidade genéricas, ou que se apliquem a diferentes necessidades dos desenvolvedores
de software.
Figura 19 – Classificação dos trabalhos selecionados quanto a finalidade
Fonte: O Autor
A primeira pergunta secundária (PS 2) tem o objetivo de analisar se as abordagens de rastreabilidade selecionadas podem ser usadas somente durante a existência do projeto de software ou se
podem também cobrir o ciclo de vida do produto. Quando a rastreabilidade cobre o ciclo de vida do
70
Quadro 10 – Classificação das abordagens selecionadas conforme sua finalidade
Finalidade da rastreabilidade
Rastreabilidade de
requisitos
Referência da abordagem
Ferramenta
(DELATER; PAECH, 2013)
UNICASE (IDE do Eclipse)
(CLELAND-HUANG;
DOMEL, 2009) *
BASEX
HAYES;
(DUBOIS;
PERALDI-FRATI;
LAKHAL, 2010)
DOORS
(ASUNCION; FRAN COIS; TAYLOR, 2007)
MS SQL, MS SharePoint e MS Office
(HONG; KIM; LEE, 2010) *
Nexcore Requirement Management
(CLELAND-HUANG et al., 2012)
Não indicada
(BUCHGEHER;
2011)
Conjunto de extensões de IDEs do Eclipse
WEINREICH,
(EGYED; BINDER;
CHER, 2007)
GRUNBA-
STRADA (Scenario-based TRAce Detection and
Analysis)
(MADER; GOTEL; PHILIPPOW,
2009)
traceMaintainer (protótipo)
(YU; JURJENS; MYLOPOULOS,
2008)
UMLsec (Combinada com IDE do Eclipse e Ferramenta de Integração Contínua CuiseControl)
(MALAVOLTA;
REKHA, 2011)
AMMA (Plugin do Eclipse)
MUCCINI;
(SOUSA et al., 2008)
UsiXML para mapear os modelos
(GOKNIL; KURTEV; BERG, 2010)
Protótipo proposto no trabalho
(JIRAPANTHONG;
2009)
XTraQue que é uma extensão do XQuery
ZISMAN,
(SCHWARZ; EBERT; WINTER,
2010)
MOLA-Tool - ferramenta para repositório e API do
Enterprise Architect - para extração
Pontos por Função
(FERREIRA; BARROS, 2011) *
Não indicada
Testes
(ZIFTCI; KRUEGER, 2011)
FORTA
(MOON et al., 2007)
Não indicada
(SATYANANDA et al., 2007)
FCA tool
(NEJATI et al., 2012)
SafeSlice (plugin do Enterprise Architect)
(SANCHEZ et al., 2011)
SRTT (Safety-Requirements-Trace-Tool)
(LEE et al., 2010)
NuSRS (Nuclear software requirements specification) e TRACE
(CLELAND-HUANG; MARRERO;
BERENBACH, 2008)
Poirot (que utiliza rede probabilística)
(YRJÖNEN; MERILINNA, 2010)
NFR + Framework (para armazenar os projetos e
MetaEdit + (ferramenta desenvolvida pelos autores)
como repositório
(MERILINNA; YRJÖNEN; RÄTY,
2012)
OSRMT (para requisitos), Framework NFR+ e MetaEdit+
(LEVENDOVSZKY et al., 2010)
GReAT (The Graph Rewriting and Transformation
Language)
Linha de Produto
de Software
Requisitos de Segurança
Goal-Centric Traceability
Requisitos Não Funcionais
Software para aviões
71
produto de software, é possível, por exemplo, identificar artefatos rastreados, que foram criados em
outros projetos para que forneçam informações para um novo projeto de evolução, manutenção ou
adaptação de um produto de software.
Apenas 4 das abordagens selecionadas tinham sua proposta explícita para o ciclo de vida do
projetos. Em Ferreira e Barros (2011) é possível verificar que a abordagem se refere somente ao projeto, pois o seu objetivo está na criação de elos entre os pontos por função medidos (através de suas
funcionalidades) e os códigos fontes gerados. Nessa abordagem não é possível reaproveitar as funcionalidades já desenvolvidas em um produto para criar uma nova estimativa para evolução do produto.
Já em Cleland-Huang, Hayes e Domel (2009) a proposta é uma abordagem em que os stakeholders
possam planejar, gerar e executar estratégias de rastreabilidade em um modelo de desenvolvimento.
Nesse trabalho, o escopo é um projeto de software e não inclui a preocupação com a manutenção do
produto após a sua construção. No trabalho de Hong, Kim e Lee (2010) a proposta é um modelo genérico para identificação de artefatos a serem rastreados de forma independente e paralela ao processo
de desenvolvimento. Nesse trabalho a abordagem é apresentada com abrangência somente no projeto.
Em todos os outros 22 trabalhos selecionados, a rastreabilidade pode ser aplicada em ambos
os cenários ou em produtos de software. O âmbito de projetos apresenta 11,54% das abordagens
selecionadas, os outros 88,46% das abordagens podem ser utilizadas no âmbito de produtos ou em
ambos produtos e projetos. A Figura 20 apresenta a distribuição dos trabalhos selecionados e o seu
percentual em relação ao total de abordagens selecionadas.
Retomando a pergunta de pesquisa, cujo objetivo é identificar se as abordagens propostas
podem ser utilizadas em organizações que desenvolvem e mantêm produtos de software, é possível
afirmar que a maiorias das abordagens analisadas podem ser usadas tanto para organizações que controlam a rastreabilidade apenas no âmbito do projeto como para organizações que desejam estender
o uso da rastreabilidade para os seus produtos. Além disso, não é possível afirmar que as abordagens
selecionadas que cobrem apenas projetos não possam ser estendidas para o produto, pois nos trabalhos isso não é discutido. A identificação das abordagens pode ser feita através do asterisco logo após
a referência do trabalho no Quadro 10. Foram apenas classificados de acordo com o detalhamento da
abordagem feito no trabalho.
A maioria das abordagens de rastreabilidade selecionadas propõe que a rastreabilidade seja
planejada e inicie a execução das atividades para implementá-la juntamente com a construção do soft-
72
65,38%
23,08%
11,54%
Ambos
Produto
Projetos
Figura 20 – Abrangência dos Trabalhos Selecionados
Fonte: O Autor
ware. A segunda pergunta secundária de pesquisa (PS 3) foi definida para identificar se as abordagens
propostas poderiam ser usadas após os produtos terem iniciado sua construção, ou mesmo após os
produtos estarem prontos. Nesses casos seria necessário identificar o mínimo necessário de documentação ou formalização dos artefatos para que a rastreabilidade pudesse ser aplicada. Após a análise
dos resultados colhidos, a percentagem é apresentada na Figura 21.
85%
15%
Antes da construção
Após produto construído
Figura 21 – Parte do Ciclo de Vida para Uso da Rastreabilidade dos Trabalhos Selecionados
Fonte: O Autor
A construção de um produto de software em uma organização pode variar muito de tamanho,
tempo de desenvolvimento e principalmente do escopo dos produtos. Um produto pode iniciar o
processo de construção ainda com um escopo reduzido e sofrer evolução durante muitos anos para
73
manter o atendimento às necessidades dos usuários. Essa é uma característica dos softwares, de ser
adaptável. Desta forma, pode ser que a estratégia de planejar e implementar a rastreabilidade de um
produto de software no início de sua construção não seja àquela necessária depois de um certo tempo
de evolução do produto. Por exemplo, se no início do processo de construção a equipe é pequena, o
escopo reduzido e a complexidade baixa, a gestão das informações de construção pode não ser crítica,
mas com o passar do tempo, com o aumento do escopo, da complexidade ou da equipe, a gestão das
informações pode ficar crítica sem o suporte da rastreabilidade neste ambiente.
A partir dos resultados observados na análise das abordagens selecionadas é possível afirmar
que se a definição da rastreabilidade não acontecer no início do processo de construção de software, a
probabilidade de realizar a rastreabilidade depois é bem menor, pois foram identificadas apenas 15%
das abordagens que permitem aplicar a rastreabilidade após o produto de software estar pronto (ver
Figura 21). Mesmo que uma organização deseje implementar a rastreabilidade depois do produto de
software construído, seria necessário identificar os artefatos que serão usados para montar a rastreabilidade depois do produto construído. Outra análise necessária no conjunto de abordagens no contexto
da cobertura do ciclo de vida de um produto de software são os artefatos necessários para que as
abordagens possam ser implementadas.
As quatro abordagens que podem ser implementadas com os produtos de já construídos estão
descritas no Quadro 11. Também são apresentados os artefatos necessários para que a abordagem
seja aplicada. É possível observar que existe uma grande variação dos artefatos necessários para implementar as diferentes abordagens. Não é possível estabelecer um padrão. Essa mesma conclusão é
observada quando são analisados os artefatos rastreados pelas abordagens em geral, como discutido
na Seção 3.1.2.5.
Quadro 11 – Abordagens para implantar rastreabilidade em produtos já construídos
Abordagem
Artefatos necessários
(ZIFTCI; KRUEGER, 2011)
Requisitos funcionais e cenários5
(EGYED; BINDER; GRUNBACHER, Features documentadas e testes associados6
2007)
(YU; JURJENS; MYLOPOULOS, Artefatos de desenvolvimento, como classes, métodos, packa2008)
ges7
(GOKNIL; KURTEV; BERG, 2010)
Requisitos e arquitetura precisa estar descrita8
74
3.2
SURVEY
Após a realização da revisão sistemática (conforme apresentado na Seção 3.1) que identificou
o conjunto de abordagens de rastreabilidade que podem ser utilizadas nas organizações que produzem
e mantêm produtos de software, ainda é necessário validar se essas abordagens fazem parte da realidade das organizações que possuem software como produto. O objetivo é identificar se as organizações usam alguma abordagem de rastreabilidade, se estas abordagens são semelhantes às identificadas
na revisão sistemática ou se as abordagens utilizadas pelas organizações não foram identificadas na
revisão sistemática.
Para atingir este objetivo, definiu-se a realização de um experimento do tipo survey como
forma de identificar e validar as abordagens de rastreabilidade nas organizações. Considerando que
os experimentos em Engenharia de Software servem para combinar ideias e realidade, Juristo e Moreno (2010) propõem três níveis diferentes para realizar um experimento. A primeira é a possibilidade
de verificar teorias contra fatos, onde as ideias são experimentadas; a segunda é o experimento de
inovações tecnológicas em projetos reais, onde os resultados da aplicação são descritos e os efeitos
observados; e a terceira é o uso das tecnologias em um ambiente produtivo real e neste caso a observação de todo o comportamento que as cercam são publicados. Estes três níveis de experimentos
podem ser chamados de experimentos laboratoriais, quasi experimentos e surveys, respectivamente.
Segundo Wohlin et al. (2012) e Travassos, Gurov e Amaral (2002) os surveys são usados
quando a técnica ou ferramenta que será avaliada já está em uso ou antes de colocá-la em uso. O
objetivo de um survey é compreender a população a partir da análise da amostra (WOHLIN et al.,
2012). Em função dessas características, o survey foi selecionado como forma de fazer a pesquisa das
informações sobre as abordagens de rastreabilidade usadas nas organizações na manutenção de seus
produtos de software.
As informações colhidas do survey são analisadas de duas formas: (i) analisar a similaridade
com as características das abordagens identificadas na revisão sistemática, e (ii) identificar características de uso de abordagens de rastreabilidade existentes nas organizações independente do encontrado
na revisão sistemática, para auxiliar na seleção do conteúdo para o corpo de conhecimento, proposto
5
6
7
8
Abordagem para rastreamento de requisitos para testes
Restrita a códigos em Java e ao uso do Eclipse
O uso do Eclipse é obrigatório para fazer a comparação entre o que foi recuperado e o que já estava documentado,
pois a abordagem serve para melhorar a confiança na rastreabilidade
A abordagem é relatada no trabalho como experimental para tratar elos entre requisitos e artefatos de arquitetura
75
neste trabalho.
É importante ressaltar que os resultados da revisão sistemática não permitem a identificação absoluta de uma abordagem. O que existe são características que quando usadas em conjunto,
identificam uma determinada abordagem de rastreabilidade. As características identificadas na revisão sistemática são apresentadas no Quadro 4, na Seção 3.1.1.2 deste texto. Essas características são
adaptadas para cada uso que é feito da rastreabilidade. Por exemplo, em duas organizações que usam
uma abordagem de rastreabilidade com a finalidade de rastrear requisitos de segurança, podem rastrear os mesmos artefatos, o mesmo ciclo de vida, tratar a rastreabilidade para o produto, no entanto,
usar ferramentas distintas. Neste caso, a abordagem não é totalmente a mesma, no entanto, permite
dizer que possuem características comuns, mesmo que não sejam na sua totalidade.
Ao final da realização do survey, pretende-se selecionar as características identificadas na revisão sistemática, validadas pela análise dos resultados e identificar características de uso das abordagens de rastreabilidade nas organização (neste caso independente das informações obtidas na revisão
sistemática) e incluí-las no corpo de conhecimento proposto neste trabalho.
Para a realização do experimento, uma metodologia é descrita como forma de apresentar e
justificar os passos dados e técnicas selecionadas para atingir os objetivos.
3.2.1
Metodologia
O propósito de um survey pode ser descritivo, explanatório ou exploratório (WOHLIN et
al., 2012). Neste estudo o propósito é descritivo, pois o objetivo é a identificação das abordagens
nas organizações. O formato é transversal, pois os dados são recolhidos em um momento único na
organização utilizando uma amostra determinada e justificada no trabalho.
As fases para a realização do survey usadas neste trabalho são baseadas em Travassos, Gurov
e Amaral (2002).
A execução do survey segue a ordem proposta na Figura 22. Na fase de planejamento, após
a definição dos objetivos, as informações necessárias são definidas. Neste momento, o método de
exploração e coleta dos dados é definido e o tamanho da amostra também é determinado. Em seguida,
o questionário é construído e um piloto é aplicado para garantir a sua validação. Uma adequação é
realizada se necessário. A partir deste momento, a fase de execução se inicia com a coleta, organização
e análise das informações. Ao final, os resultados são descritos através da interpretação dos dados.
76
Figura 22 – Fases para realização do Survey
Fonte: Adaptado de Bravo e Eisman (1998)
3.2.2
Planejamento do survey
O planejamento é a fase mais extensa da realização do survey. Nesta fase estão atividades
decisivas para o sucesso dos resultados, pois a decisão das informações necessárias que leva a construção do questionário precisa estar coerente com os objetivos e deve ser plenamente projetada para
que os resultados sejam alcançados. Esta fase é composta de 5 fases descritas a seguir.
a) Definir os objetivos da investigação
Um dos objetivos específicos desta dissertação é a classificação das abordagens de rastreabilidade existentes para que façam parte do corpo de conhecimento que é proposto como resultado
do estudo. Para isso, o primeiro passo foi a realização da revisão sistemática que identificou o
conjunto de abordagens relatadas em forma de trabalhos publicados pela comunidade científica.
A realização do survey tem como principal objetivo complementar a identificação e classificação das abordagens de rastreabilidade usadas em organizações de software como produto.
De forma mais específica, o survey proporcionará de um lado a validação das informações
selecionadas durante a realização da revisão sistemática, através do objetivo G1 e analisar as
informações colhidas e medir as práticas apresentadas nas organizações, através do objetivo G2.
Esta é uma forma de contribuir para o objetivo do trabalho, pois além de validar a interseção
77
das abordagens de rastreabilidade identificadas na revisão sistemática, é possível caracterizar
o uso das abordagens existentes nas organizações entrevistadas de forma mais ampla, além do
comparativo com as informações já colhidas. Um exemplo é a análise de qual o modelo de rastreabilidade mais usado nas organizações. O objetivo descrito como G2 foi definido com este
intuito.
A descrição dos objetivos seguiu o padrão sugerido por Basili V.R. Romback (1998) que propõe
a definição através de um template que contém 5 partes e que ao final permitem a identificação
do objetivo de forma clara.
G1
Analisar as abordagens de rastreabilidade
Com o propósito de caracterizar
Com respeito à interseção com as abordagens de rastreabilidade de produtos identificadas na
revisão sistemática deste estudo
Do ponto de vista do desenvolvedor de software
No contexto das organizações que desenvolvem software como produto.
G2
Analisar as abordagens de rastreabilidade
Com o propósito de identificar
Com respeito às práticas adotadas pela organização
Do ponto de vista do desenvolvedor de software
No contexto das organizações que desenvolvem software como produto.
Para facilitar a leitura das hipóteses e das análises dos resultados da pesquisa foram codificados
dois conjuntos de abordagens. As abordagens de rastreabilidade identificadas na revisão sistemática são identificadas como Ars e as abordagens identificadas nas organizações entrevistadas
através do survey é identificada como Aor .
Para o objetivo G1 foram identificadas duas hipóteses:
Hipótese nula: H0 = “As características das Ars não são utilizadas nas organizações que desen-
78
volvem software como produto”.
Hipótese alternativa: H1 = “As características das Ars são utilizadas parcialmente nas organizações que desenvolvem software como produto”.
Para o objetivo G2 foram identificadas duas hipóteses:
Hipótese nula: H2 = “As organizações que desenvolvem software como produto não apresentam um padrão de características associadas as Aor ”.
Hipótese alternativa: H3 = “As organizações que desenvolvem software como produto apresentam um padrão de características associadas as Aor ”.
b) Decidir a informação necessária
Nesta fase o método de exploração e coleta dos dados é definido, assim como o tamanho representativo da amostra. Ao final, o conjunto de informações necessárias para a realização do
survey é estabelecido.
As informações obtidas por este survey são utilizadas para compor o conteúdo do corpo de
conhecimento. As abordagens que são praticadas pelas organizações poderão, após analisadas,
fazer parte do corpo de conhecimento com os seus devidos contextos relacionados.
A definição das informações necessárias partiu daquelas já utilizadas na revisão sistemática
(ver Seção 3.1, página 48). Como o objetivo principal é validar se as organizações utilizam as
mesmas abordagens que as identificadas na revisão sistemática, são coletadas as informações
que permitam esta comparação, isso para atender o objetivo G1. Além disso, são coletadas informações de contextualização e também de práticas de rastreabilidade adotadas independente
das informações coletadas na revisão sistemática, para atender o objetivo G2.
Para responder o objetivo G1 deste survey , é utilizado o método para a exploração e coleta
dos dados GQM (Goal Question Metrics). Basili (1992) afirma que as medições e a coleta de
informações das partes envolvidas nos processos de software auxilia na compreensão e a tomar
decisões inteligentes, além de melhorar os processos. No entanto as medidas devem ter foco
e seguir um modelo. Ao usar o método GQM especifica-se um modelo de medição visando
79
um conjunto particular de questões e um conjunto de regras para a interpretação dos dados da
medição (WOHLIN et al., 2012).
Conceptual
Level
Operational
Level
Quantitative
Level
Goal
Question
Metric
Question
Metric
Goal
Question
Metric
Question
Metric
Metric
Question
Metric
Figura 23 – Estrutura do GQM
Fonte: Adaptado de Wohlin et al. (2012)
Conforme apresentado na Figura 23, o objetivo definido no nível conceitual dá origem as questões de pesquisa no nível conceitual que em seguida estarão ligadas a uma ou mais métricas no
nível quantitativo.
A partir da definição dos objetivos deste survey, apresentados no item Definir os objetivos da
investigação, as questões de pesquisa foram identificadas. Com as questões estabelecidas, as
métricas são definidas. A base para as comparações foram extraídas da revisão sistemática e a
classificação das abordagens de rastreabilidade não são necessariamente objetivas.
Conforme apresentado anteriormente, os objetivos são identificados pela letra G seguida de um
número sequencial. As questões associadas ao objetivo são identificadas pela letra Q seguida
do número da questão e de um número sequencial para identificar a questão dentro do objetivo.
A partir do objetivo, as métricas são identificadas e associadas a um objetivo através da letra
M e de um número sequencial. A associação da métrica com a questão é identificada no texto,
pois uma métrica pode estar associada a mais de uma questão.
As métricas estão relacionadas às questões de pesquisa, conforme apresenta a Figura 24. Cada
métrica é calculada conforme os resultados das questões aplicadas no questionário. As métricas
(de 1 a 15) são calculadas conforme o total de respostas colhidos no questionário. Para o cálculo
das métricas, as quantidades serão convertidas em percentuais e uma relação é criada com um
conceito estabelecido para a avaliação. O Quadro 12 apresenta a relação de valores com os
conceitos.
80
Quadro 12 – Classificação dos percentuais encontrados nas questões para interpretação
Conceito
Percentual
Nenhum
<1%
Parcialmente
>= 1% e < 45%
Largamente
>= 45% e < 90%
Totalmente
>= 90%
Para elaboração dos conceitos apresentados no Quadro 12 de avaliação das métricas foram utilizadas duas fontes. Em SEI (2010) e Softex (2011) a mesma escala é utilizada para fazer a
avaliação de resultados esperados de modelos de qualidade. Estes conceitos permitem avaliar
a aderência das práticas apresentadas pelas organizações aos modelos de qualidade avaliados.
Como neste trabalho o objetivo é avaliar a aderência das práticas das organizações àquelas identificadas na revisão sistemática (em G1) e avaliar as práticas comuns entre as organizações (em
G2) optou-se por utilizar os mesmos conceitos sugeridos nas duas fontes selecionadas. Quanto
aos valores percentuais, foram adaptados para ficar coerentes com o foco da pesquisa e das
perguntas, embora a base também seja das mesmas fontes. Foi definido que até 1% de valores
positivos consiste de nenhuma evidência da aplicação e que para sejam consideradas evidências
totais, os resultados devem ser a partir de 90% dos valores positivos. Estes valores também levam em consideração que os resultados das abordagens possuem detalhes e especificidades que
podem variar na sua aplicação.
A seguir a estrutura de objetivos (G), questões (Q) e métricas (M) é detalhada, primeiramente
através da Figura 24 e após com o detalhamento de cada objetivo, questão e métrica.:
Figura 24 – Estrutura do GQM do Survey
Fonte: O Autor
81
Questões de Contextualização
Estas questões, por serem de contextualização, não possuem um cálculo específico dos resultados. Os dados serão agrupados para a contextualização das informações colhidas no questionário.
Q0.1: Qual o estado (unidade da federação) onde está localizada a unidade organizacional pesquisada?
Q0.2: Qual a cidade onde está localizada a unidade organizacional pesquisada?
Q0.3: Quantos desenvolvedores fazem parte a unidade organizacional?
Q0.4: Qual a área de atuação do(s) produto(s) desenvolvido?
Q0.5: Quantos produtos são mantidos pela unidade organizacional?
Q0.6: Há quantos anos foi iniciada a construção do produto?
Q0.7: A unidade organizacional possui avaliação ou certificação da qualidade?
Q0.8: A organização aplica a rastreabilidade em algum nível na unidade organizacional?
Objetivo - G1
Dado um conjunto de organizacões entrevistadas (te), as perguntas a seguir devem responder se
existem características comuns entre as abordagens usadas pelas organizações e as identificadas
em Ars . Este objetivo inclui o uso do GQM para o cálculo e a análise dos dados.
Q1.1: A finalidade da rastreabilidade identificada na organização faz parte das finalidades identificadas em Ars ?
• M1: Quantidade finalidades identificada nas organizações que fazem parte das identificadas em Ars .
O Quadro 13 apresenta a fórmula usada para o cálculo da métrica e para o cálculo da Questão
Q1.1.
Quadro 13 – Cálculo para responder Q1.1
Objeto
Fórmula
M1
M1 ← total de f i ∈ FI,
onde: f i=finalidade usada na organização e FI= conjunto de finalidades
identificado em Ars
Q1.1
Q1.1=( M1∗100
te )
82
Após realizado o cálculo de Q1.1, o valores são classificado conforme o Quadro 12 para responder a questão Q1.1.
Q1.2: Os artefatos rastreados pela abordagem seguida pela organização são compatíveis com
os artefatos rastreados das abordagens identificadas em Ars ?
• M2: Relação de artefatos rastreados pelas organizações que fazem parte dos artefatos
rastreados identificados em Ars
• M3: Relação de artefatos obrigatórios para realizar a rastreabilidade identificados na organização que fazem parte da relação de artefatos obrigatórios identificados em Ars
O Quadro 14 apresenta as fórmulas usadas para o cálculo das métricas e para o cálculo da
Questão Q1.2
Quadro 14 – Cálculo para responder Q1.2
Objeto
Fórmula
M2
M2 ← total de ar ∈ AR,
onde: ar=artefatos rastreados na organização e AR = conjunto de artefatos rastreados identificados em Ars
M3
M3 ← total de ao ∈ AO,
onde: ao=artefatos obrigatórios necessários na organização e AO = conjunto de artefatos obrigatórios identificados em Ars
Q1.2
Q1.2=(
( M2+M3
)∗100
2
)
AR
Após realizado o cálculo de Q1.2, o valores são classificado conforme o Quadro 12 para responder a questão Q1.2.
Q1.3: Os padrões de modelagem dos dados usados pelas organizações são compatíveis com os
padrões identificados Ars ?
• M4: Relação de padrões de modelagem identificados nas organizações que fazem parte
dos padrões de modelagem identificados em Ars
O Quadro 15 apresenta a fórmula usada para o cálculo da métrica e para o cálculo da Questão
Q1.3
83
Quadro 15 – Cálculo para responder Q1.3
Objeto
Fórmula
M4
M4 ← total de pm ∈ PM,
onde: pm=padrão de modelagem usada na organização e PM= conjunto
de padrões de modelagem identificado em Ars
Q1.3
Q1.3=( M4∗100
AR )
Após realizado o cálculo de Q1.3, o valores são classificado conforme o Quadro 12 para responder a questão Q1.3.
Q1.4: As ferramentas utilizadas pelas organizações são compatíveis com as ferramentas identificados em Ars ?
• M5: Relação de ferramentas de rastreabilidade identificadas nas organizações que fazem
parte das ferramentas identificadas em Ars
O Quadro 16 apresenta a fórmula usada para o cálculo da métrica e para o cálculo da Questão
Q1.4
Quadro 16 – Cálculo para responder Q1.4
Objeto
Fórmula
M5
M5 ← total de f e ∈ FE,
onde: f e=ferramenta usada na organização e FE= conjunto de ferramentas identificado em (Ars )
Q1.4
Q1.4=( M5∗100
MP )
Após realizado o cálculo de Q1.4, o valores são classificado conforme o Quadro 12 para responder a questão Q1.4.
Objetivo - G2
Dado um conjunto de organizações entrevistadas (te), as perguntas a seguir devem responder
se existem características comuns entre elas. Para isso, serão colhidos e analisados os dados
através dos questionários aplicados. Este objetivo não inclui o uso completo do GQM, pois não
há base de comparação, no entanto, a estrutura para a especificação das métricas e questões
foi mantida. As perguntas relacionadas a este objetivo serão analisadas diretamente a partir dos
resultados quantitativos das medidas, não havendo fórmulas associadas as perguntas, apenas a
84
sua classificação conforma o Quadro 12.
Q2.1: As unidades organizacionais entrevistadas (te) usam rastreabilidade?
• M6: Percentual de unidades organizacionais que aplicam a rastreabilidade em relação a
te.
• M7: Percentual de unidades organizacionais que não aplicam a rastreabilidade em relação
a te.
O Quadro 17 apresenta a fórmula de cálculo das métricas usadas para responder a questão Q2.1
Quadro 17 – Cálculo para responder Q2.1
Métrica
Fórmula
M6
M6=( ar∗100
te ),
onde: ar=total de unidades organizacionais que aplicam rastreabilidade
M7
M7=( nr∗100
te ),
onde: nr=total de unidades organizacionais que não aplicam rastreabilidade
Após realizado o cálculo de M6 e M7, o valores são classificado conforme o Quadro 12 para
responder a questão Q2.1.
Q2.2: Dentre as unidades organizacionais que usam rastreabilidade (ra) quantas usam rastreabilidade em artefatos de produto de software?
• M8: Quantidade de unidades organizacionais que usam rastreabilidade em artefatos de
produto de software.
O Quadro 18 apresenta a fórmula de cálculo da métrica usada para responder a questão Q2.2
Quadro 18 – Cálculo para responder Q2.2
Métrica
Fórmula
M8
M8=( rp∗100
ra ),
onde: rp=total de unidades organizacionais que aplicam rastreabilidade
em artefatos de produto e ar=total de unidades organizacionais que aplicam rastreabilidade
Após o valor da métrica M8 ser calculado, é possível responder a questão Q2.2 analisando o
percentual das unidades organizacionais que utilizam a rastreabilidade em artefatos de produto
85
de software.
Após realizado o cálculo de M8, o valores são classificado conforme o Quadro 12 para responder a questão Q2.2.
Q2.3: As organizações entrevistadas que fazem rastreabilidade usam ferramentas automatizadas?
• M9: Quantidade de unidades organizacionais que usam ferramentas automatizadas para
fazer rastreabilidade.
O Quadro 19 apresenta a fórmula de cálculo da métrica usada para responder a questão Q2.3
Quadro 19 – Cálculo para responder Q2.3
Métrica
Fórmula
M9
M9=( f a∗100
ar ),
onde: f a=total de unidades organizacionais que usam ferramentas automatizadas para fazer rastreabilidade e ar=total de unidades organizacionais que aplicam rastreabilidade
Após realizado o cálculo de M9, o valores são classificado conforme o Quadro 12 para responder a questão Q2.3.
Q2.4: As unidades organizacionais que usam rastreabilidade (ar) podem aplicar a rastreabilidade após o produto pronto?
• M10: Quantidade de unidades organizacionais que usam abordagens de rastreabilidade
que podem ser aplicadas após o produto estar construído
O Quadro 20 apresenta a fórmula de cálculo da métrica usada para responder a questão Q2.4
Quadro 20 – Cálculo para responder Q2.4
Métrica
Fórmula
M10
M10 =( ap∗100
ar ),
onde: ap=total de unidades organizacionais que usam abordagem de rastreabilidade que pode ser aplicada após o produto estar construído e
ar=total de unidades organizacionais que aplicam rastreabilidade
86
Após realizado o cálculo de M10, o valores são classificado conforme o Quadro 12 para responder a questão Q2.4.
Ainda dentro do tópico definido para decidir as informações necessárias, duas informações
importantes apresentadas na Figura 22 proposta por Bravo e Eisman (1998), são o método de
exploração e coleta dos dados e o tamanho da amostra representativa da população.
O método definido para a realização deste survey é a aplicação de questionário assistido. Acompanhar a resposta de um questionário, seja face a face ou através de um meio eletrônico, oferece
vantagens como a melhora na taxa de respostas, redução de respostas nulas, em branco ou que o
entrevistado não saiba a resposta, além de proporcionar a observação e tirar dúvidas que possam
surgir no momento da resposta (WOHLIN et al., 2012).
Para a definir o tamanho da amostra é necessário retornar ao objetivo deste trabalho e mais
especificamente do survey. A proposta do trabalho é a construção da primeira versão de um
corpo de conhecimento em rastreabilidade de software. A principal fonte para a identificação
das abordagens que farão parte do corpo de conhecimento proposto é a revisão sistemática
apresentada na Seção 3.1.
O survey, por sua vez, deve servir de instrumento para identificar se as abordagens identificadas
na revisão sistemática são conhecidas e utilizadas nas organizações que produzem software
como produto. É importante esclarecer que o objetivo do survey não inclui a identificação das
abordagens. O propósito é obter a informação do uso das abordagens para validar a sua inclusão
no corpo de conhecimento proposto.
Após o esclarecimento dos objetivos do survey, o tamanho da amostra ficou definido em vinte
unidades organizacionais que mantêm produtos de software em suas operações. Estas organizações devem estar distribuídas na região sul do Brasil, incluindo organizações dos estados do
Paraná, Santa Catarina e Rio Grande do Sul. Outras duas características importantes devem
ser observadas na escolha da amostra. Serão identificadas como unidades organizacionais as
unidades de produção de organizações de software que sejam formadas por um grupo de desenvolvedores responsáveis pela construção e/ou manutenção de pelo menos um produto de
software. Desta forma será possível fazer a com que a verificação de aderência seja compatível com os ambientes propostos na literatura identificados na revisão sistemática. Outro ponto
87
importante é a identificação do tamanho das unidades organizacionais. Além da distribuição
geográfica devem fazer parte da amostra organizações que possuam no mínimo 2 e também
com mais de 30 profissionais. A definição do tamanho (quantidade de desenvolvedores envolvidos na produção do produto de software) da unidade organizacional é uma forma de mitigar
um possível risco de concentrar a amostra em unidades organizacionais de um tamanho único
o que poderia comprometer os resultados analisados.
c) Construir o questionário
O questionário foi construído a partir das questões identificadas para atender os objetivos.
Houve uma divisão do questionário em duas partes. A primeira parte, que conta com oito
questões, pretende contextualizar a organização. O objetivo é identificar as características da
organização entrevistada e permitir que a análise seja melhor compreendida a partir dos dados
coletados. A segunda parte pretende responder aos dois objetivos G1 e G2, através das questões
identificadas no GQM descritas no item b) desta seção. O gabarito das perguntas da segunda
parte do questionário foi elaborado baseado nos resultados identificados na revisão sistemática.
Isso porque as perguntas tem o objetivo de identificar a aderência às abordagens identificadas na revisão sistemática e também identificar características comuns entre as organizações
entrevistadas em relação ao uso de práticas de rastreabilidade.
O questionário completo é apresentado no Apêndice C.
O questionário foi publicado como um formulário no Google Docs9 . A elaboração das perguntas e formatos foram pensados para que a aplicação fosse realizada com a presença do
pesquisador.
d) Aplicar estudo piloto
Após a elaboração do questionário, é necessário que o seu conteúdo seja validado para garantir
que a forma seja compreendida pelo público que irá responder. Outro objetivo é identificar se
todas as questões foram bem elaboradas para responder as questões de pesquisa já definidas.
O estudo piloto deste questionário foi aplicado em 2 organizações que não foram consideradas
na fase de coleta das informações. O objetivo foi validar o questionário, avaliar a forma de
9
http://docs.google.com
88
tabulação das respostas e também validar as fórmulas elaboradas para cada questão. Durante a
aplicação do estudo piloto observou-se que o tempo médio de resposta foi de 15 minutos.
e) Adequar o questionário à amostra
O questionário (apresentado no Apêndice C) teve ajustes na formulação de 2 questões (questão
8 e 13), na parte textual, por não ter ficado claro o objetivo da pergunta. O ajuste aconteceu
após a avaliação realizada na aplicação do estudo piloto.
3.2.3
Execução do survey
A execução do survey contemplou as fases de coleta e organização antes das análises das
informações.
a) Coletar as informações
A coleta das informações aconteceu após o envio de solicitação de resposta ao questionário.
Para atingir o número mínimo de vinte organizações entrevistadas, foram enviados cinquenta e
três convites. Dentre estes convidados, vinte responderam. Após a organização mostrar disposição em responder o questionário, através da leitura da solicitação, feita em todos os casos por
e-mail, houve um contato pessoal com o responsável pela resposta. Neste contato foi explicado
com mais detalhes e sanadas dúvidas que o respondente teve em relação a forma de resposta.
Todos os questionários foram respondidos com um contato pessoal (face a face) ou através de
ferramenta de comunicação eletrônica. Os questionários respondidos mantiveram a média de
tempo de resposta em 15 minutos, como identificado no estudo piloto.
b) Organizar e analisar as informações
Todos os questionários respondidos foram automaticamente armazenados em planilha, conforme padrão de comportamento do Google Docs. As perguntas identificadas no questionário
eram respondidas pela organizações, que não foram identificadas, e que em seguida foram tabuladas para seguirem para a análise.
A análise das informações consistiu em um primeiro momento da tabulação e organização
dos dados. Em seguida, os cálculos de todas as métricas foram definidas. O uso das métricas
possibilitou responder as questões elaboradas e o conjunto dos resultados permitiu responder
aos dois objetivos do GQM definidos neste survey.
89
3.2.4
Resultados do survey
A apresentação dos resultados está organizada de acordo com a estrutura do GQM definida
na Figura 24. Primeiramente são apresentados os resultados da contextualização das organizações
pesquisadas. Em seguida são apresentados os resultados de G1 e G2 que determinam o escopo do
survey realizado.
3.2.4.1
Contextualização
Foram 20 organizações entrevistadas, sendo 12 delas em Santa Catarina, 4 no estado do Paraná
e 4 no Rio Grande do Sul.
A Figura 25 apresenta a distribuição da quantidade de desenvolvedores nas organizações entrevistadas e percebe-se que há uma distribuição igualitária entre as organizações com até 9 desenvolvedores e entre 10 e 29 desenvolvedores. Uma parte menor que possui mais de 30 desenvolvedores,
15%.
Figura 25 – Quantidade de desenvolvedores nas organizações entrevistadas
Fonte: o Autor
As organizações entrevistadas em sua maioria mantêm 1 produto na organização. Duas delas mantém 2 produtos e apenas uma possui uma quantidade maior e mantém 8 produtos no total.
Quanto a natureza dos produtos, fazem software para diferentes áreas. Estas áreas são apresentadas
na Figura 26. As organizações que fazem software para a área de comércio e indústria são a maioria
e representam a metade das organizações entrevistadas.
90
Figura 26 – Áreas de atuação nas organizações entrevistadas
Fonte: o Autor
Durante a entrevista foi investigada a idade dos produtos de software mantidos pelas organizações. A Figura 27 mostra que os produtos que possuem mais de 9 anos são a maioria e representam
37%. Produtos com idade entre 3 e 7 anos, somados representam 48% e de 0 a 3 anos representam
16%.
Figura 27 – Idade dos produtos de software das organizações investigadas
Fonte: o Autor
Outro aspecto investigado na contextualização das organizações foram as certificações ou ava-
91
liações da qualidade. A Figura 28 apresenta os percentuais relacionados aos resultados dos modelos
de qualidade adotados pelas organizações, onde 70% não possuem nenhuma avaliação ou certificação
de modelos de qualidade. 15% possuem avaliação MPS.BR e 15% certificação ISO 9000. O modelo
CMMI representou 5% das avaliações identificadas nas organizações entrevistadas.
Figura 28 – Modelos de qualidade adotados nas organizações investigadas
Fonte: o Autor
As organizações entrevistadas, depois de contextualizadas através das perguntas para identificar as características de seus ambientes de desenvolvimento, responderam se praticavam rastreabilidade em algum nível no seu processo de desenvolvimento. Uma entre as 20 organizações entrevistadas não praticava a rastreabilidade em nenhum nível. As questões elaboradas para responder G1 e G2
foram aplicadas somente as organizações que praticavam a rastreabilidade em algum nível.
3.2.4.2
Resultado de G1
O objetivo G1 foi criado para identificar se existem características comuns entre as abordagens usadas pelas organizações (te) e as identificadas na revisão sistemática (Ars ). Para isso, foram
elaboradas questões cujos resultados são apresentados a seguir.
Q1.1 - A finalidade da rastreabilidade identificada na organização faz parte das finalidades
identificadas em Ars ?
Das finalidades identificadas durante a revisão sistemática, 63% foram identificadas nas organizações o que permite afirmar que as finalidades da rastreabilidade de te e Ars são largamente
compatíveis. Destaca-se aqui que a finalidade de rastrear requisitos funcionais foi a única que compôs
92
os 63% pertencentes a te e Ars . A lista completa incluía além de rastrear requisitos funcionais, requisitos não funcionais, pontos por função, testes, artefatos de linha de produtos de software, requisitos
de segurança, baseados em objetivos (GCT) e construção de software para aviões. As organizações
citaram ainda finalidades não identificadas em Ars , que representam 37% das finalidades identificadas.
A Figura 29 apresenta a distribuição dos resultados que conta com 37% das finalidades apontadas nas
organizações que não apareceram nos trabalhos analisados.
Figura 29 – Finalidade do uso da rastreabilidade em Ars e te
Fonte: o Autor
Q1.2 - Os artefatos rastreados pela abordagem seguida pela organização são compatíveis com
os artefatos rastreados das abordagens identificadas em Ars ?
Os resultados desta pergunta apontam para um total de 86% de artefatos citados na Ars e que
são rastreados também pelas organizações (te ). A Figura 30 apresenta o resultado da aderência dos
artefatos rastreados em Ars aos artefatos identificados em te nas organizações. Os artefatos rastreados
são classificados como largamente compatíveis entre a revisão sistemática (Ars ) e o survey realizado
(te). Durante a pesquisa nas organizações foram identificados quatro artefatos que não estavam relacionados na Ars . Os artefatos são: tarefas de desenvolvimento, tarefas de teste, histórias (usadas em
métodos ágeis) e chamados (registrados pelos clientes).
Q1.3 - Os padrões de modelagem dos dados usados pelas organizações são compatíveis com
os padrões identificados em Ars ?
Os resultados colhidos de aderência dos padrões de modelagem praticados nas organizações
apontam para uma compatibilidade de 27%. Este resultado indica que apenas 27% dos padrões de modelagem são usados nas organizações e são classificados como parcialmente aderentes aos resultados
93
Figura 30 – Artefatos rastreados em Ars e te
Fonte: o Autor
encontrados na te. A Figura 31 apresenta os resultados da compatibilidade dos padrões de modelagem
identificados em Ars e entre te.
No entanto, é importante observar que 79% das empresas usa algum tipo de modelagem de
sistema compatível com pelo menos uma abordagem identificada em Ars . Destacam-se as abordagens
de modelagem relacional (banco de dados) UML e uma sequência praticada por 8 das organizações
entrevistadas que inclui a modelagem de processo de negócios, requisitos, tarefas de construção e
interface de usuário. A modelagem ágil e a prototipação de tela foram dois padrões de modelagem
citados pelas organizações que não faziam parte da Ars .
Figura 31 – Padrões de modelagem compatíveis entre Ars e te
Fonte: o Autor
94
Q1.4 - As ferramentas utilizadas nas organizações são compatíveis com as ferramentas identificadas em Ars ?
De todas as ferramentas identificadas em Ars , apenas 5% foram identificadas nas organizações
(em te). Este número classifica as ferramentas como parcialmente compatíveis entre Ars e te. A única
ferramenta que aparece tanto em Ars quanto em te é a IDE ou plugin do Eclipse. A Figura 32 apresenta
os resultados da compatibilidade das ferramentas identificadas em Ars e entre te.
A maioria (95%) das organizações usa ferramentas cuja finalidade não é específica para a rastreabilidade de software. As ferramentas possuem finalidades mais genéricas e são usadas também
para registrar a rastreabilidade. A lista de ferramentas que não foram identificadas na revisão sistemática (Ars ) e que são usadas pelas organizações são as seguintes: Jira e GitHub; Enterprise Architect
(com ou sem plugins específicos juntamente com ferramenta de gestão de tarefas; Jazz, Mantis, SVN
e OSTicket; Git; REM (ferramenta CASE); Rational RequisitePro e Rational Requirements Composer; Redmine; SVN; além de ferramentas próprias. Também aparece uma das organizações que faz
rastreabilidade mas que não usa nenhuma ferramenta automatizada.
Figura 32 – Ferramentas de rastreabilidade compatíveis entre Ars e te
Fonte: o Autor
Os resultados classificados do objetivo G1 é apresentado no Quadro 21
3.2.4.3
Resultado de G2
O objetivo G2 foi definido para identificar as características comuns entre as abordagens de
rastreabilidade usadas nas organizações entrevistadas. São quatro questões abordadas e os resultados
são apresentados a seguir.
95
Quadro 21 – Resultado de G1
ID
Questão
Q1.1
Finalidade do uso da rastreabilidade são comuns?
Q1.2
Artefatos rastreados são comuns?
Q1.3
Padrões de modelagem comuns usados na rastreabilidade?
Q1.4
Ferramentas usadas na prática da rastreabilidade são comuns?
Resultado
Largamente
Largamente
Parcialmente
Parcialmente
Q2.1 - As unidades organizacionais entrevistadas usam rastreabilidade?
Como apresenta a Figura 33, 95% das unidades organizacionais entrevistadas usa rastreabilidade em algum nível. Segundo classificação proposta neste trabalho, o uso da rastreabilidade acontece
totalmente nas unidades organizacionais entrevistadas.
Figura 33 – Unidades organizacionais que usam rastreabilidade de software
Fonte: o Autor
Q2.2 - Dentre as unidades organizacionais que usam rastreabilidade, quantas usam rastreabilidade em artefatos de produto de software?
Todas as unidades organizacionais entrevistadas mantinham pelo menos um produto de software. O objetivo desta pergunta é identificar se a rastreabilidade chegava a considerar informações
dos produtos na rastreabilidade definida na organização ou se tratava somente os artefatos produzidos
durante os projetos. Quando os artefatos de produto não são tratados na rastreabilidade os benefícios
também não podem ser aproveitados no nível do produto. Os resultados da pesquisa apontam que 53%
das unidades organizacionais entrevistadas tratam a rastreabilidade considerando artefatos de produto
de software, enquanto que 47% rastreia somente artefatos de projetos. Desta forma, classifica-se como
largamente adotada a rastreabilidade nos artefatos de produto de software nas unidades organizacio-
96
nais entrevistadas. A Figura 34 apresenta os resultados colhidos na pesquisa.
Figura 34 – Rastreabilidade em produtos de software
Fonte: o Autor
Q2.3 - As organizações entrevistadas que fazem rastreabilidade, usam ferramentas automatizadas?
Das unidades organizacionais entrevistadas somente uma não usa ferramenta automatizada
para controlar a rastreabilidade. artefatos de projetos. A Figura 35 apresenta os resultados colhidos na
pesquisa.
Figura 35 – Unidades organizacionais que usam ferramentas automatizadas para rastreabilidade de
software
Fonte: o Autor
Q2.4 - As unidades organizacionais que usam rastreabilidade podem aplicar a rastreabilidade
após o produto pronto? Um dos pontos investigados na pesquisa foi a possibilidade de realizar a
97
rastreabilidade após a construção do produto de software. Em todos os casos das unidades organizacionais entrevistadas não houve nenhuma que pudesse aplicar a rastreabilidade depois do produto de
software pronto. As abordagens utilizadas necessitam ser desenvolvidas em tempo de construção do
produto de software.
A Figura 36 apresenta os resultados colhidos na pesquisa.
Figura 36 – Fase do ciclo de vida do produto que pode ser usada a rastreabilidade
Fonte: o Autor
Os resultados classificados do objetivo G2 é apresentado no Quadro 22
Quadro 22 – Resultado de G2
ID
Questão
Q2.1
Usam rastreabilidade?
Q2.2
Rastreiam artefatos de produto de software?
Q2.3
Usam ferramentas automatizadas?
Q2.4
Pode aplicar rastreabilidade após o produto pronto?
3.2.4.4
Resultado
Totalmente
Largamente
Totalmente
Nenhuma
Análise dos resultados
O survey permitiu identificar pontos importantes para a seleção dos componentes de estrutura e para o conteúdo do corpo de conhecimento proposto na dissertação. Os aspectos relevantes
identificados na revisão sistemática (Ars ) foram validados através da pesquisa realizada em unidades
organizacionais (te). Após a apuração dos resultados, é possível identificar que a finalidade observada nas organizações é parcialmente compatível com as finalidades das abordagens selecionadas na
literatura. Destacou-se aqui a finalidade de rastrear requisitos funcionais como a principal finalidade
tanto na revisão sistemática quanto nas organizações.
98
Com relação aos artefatos rastreados, estes compõem um conjunto extenso de artefatos, no
entanto o conjunto de artefatos parece compatível uma vez que representa 87% de compatibilidade.
Neste item destaca-se a rastreabilidade de artefatos usados em abordagens ágeis de desenvolvimento
que apareceram nas organizações e que não forma identificadas na revisão sistemática.
O ponto mais dissonante entre a Ars e a te foi identificado nos padrões de modelagem. Na
revisão sistemática muitos padrões de modelagem foram identificados e que não aparecem nas organizações como práticas. Se analisadas do ponto de vista quantitativo, apenas 27% dos padrões são
identificados nas organizações. No entanto, outra forma de observar o resultado mostra que muitas
organizações usam os mesmos padrões de modelagem, ficando restritos a modelagem relacional, a
UML (Unified Modeling Language) e a uma sequência identificada por modelagem de negócio, requisitos, tarefas de construção e interface de usuário. Padrões mais específicos que são comumente
usados para tratar a rastreabilidade, como MDD (Model Driven Development), MDE (Model Driven Engineering), MUSE (Management-based Unified Software Engineering) ou ainda FCA (Formal
Concept Analysis) para ligar o modelo de funcionalidades ao modelos de arquitetura, entre outros.
É possível identificar a partir da análise dos resultados do survey que as ferramentas estão
presentes em praticamente todas as abordagens de rastreabilidade usadas. No entanto, as ferramentas
propostas na literatura (da revisão sistemática) não são compatíveis com as ferramentas adotadas
pelas organizações. As ferramentas propostas na literatura são, em geral, projetadas para suportar
a rastreabilidade e não contemplam necessariamente a informatização de outras etapas ou áreas do
desenvolvimento de software. Nas organizações as ferramentas usadas para a rastrear artefatos são
as usadas para outras finalidades, como por exemplo: Remine, Git, GitHub, Jira, SVN ou Mantis.
Estas ferramentas são usadas para controlar tarefas no gerenciamento de projetos e para o controle
de versão dos códigos fontes. O uso de ferramentas desenvolvidas internamente nas organizações
também aparecem como solução para a rastreabilidade.
Sobre o objetivo G1 pode-se afirmar que os pontos convergentes são a finalidade do uso da
rastreabilidade e os artefatos rastreados e que os ponto que apresentaram maior divergência são os
padrões de modelagem e as ferramentas usadas na rastreabilidade.
Quando investigadas as características comuns entre as unidades organizacionais, os resultados apontam para organizações que praticam a rastreabilidade em diferentes níveis. Apenas uma entre
as entrevistadas afirmou não fazer nenhum tipo de rastreamento durante o desenvolvimento do soft-
99
ware. O uso de ferramentas também é comum entre as organizações que praticam a rastreabilidade.
Quanto às hipóteses descritas em G1, ao verificar os resultados é possível refutar H0 pois as
questões Q1.1 e Q1.2 foram largamente aceitas e as questões Q1.3 e Q1.4 foram parcialmente aceitas.
Desta forma a hipótese H1 é aceita, pelos mesmos resultados das questões Q1.1, Q1.2, Q1.3 e Q1.4.
Os pontos relevantes na análise de G2 ficaram por conta da identificação da rastreabilidade
como uma prática que acontece durante o processo de desenvolvimento. Nenhuma das organizações
indicou usar abordagens de rastreabilidade capazes de serem aplicadas após o produto construído.
Isso reforça a prática da rastreabilidade inserida no processo de desenvolvimento do software. Outro
aspecto importante observado foi que embora todas as organizações entrevistadas mantenham pelo
menos um produto de software, a metade delas não inclui artefatos relacionados ao produto no escopo da rastreabilidade. Nessas organizações a rastreabilidade fica restrita a artefatos do projeto. Isso
impede de aproveitar totalmente os benefícios da rastreabilidade na evolução do produto, ficando
restrita somente ao ciclo de vida do projeto.
Com relação as hipóteses associadas a G2, H2 e H3 pode-se afirmar, observando os resultados,
que as organizações que desenvolvem software como produto apresentam um padrão de características comuns associadas às abordagens de rastreabilidade identificadas nas organizações. As questões
Q2.1, Q2.2, Q2.3 e Q2.4 apontam resumem o padrão de comportamento comum das organizações em
relação a rastreabilidade. Desta forma considera-se refutada H2 e aceita H3 .
3.3
TRABALHOS RELACIONADOS A CORPOS DE CONHECIMENTO
O objetivo desta seção é identificar corpos de conhecimento que já existem na literatura e que
são relacionados de alguma forma a rastreabilidade de software.
Para a identificação de trabalhos similares ao proposto na pesquisa relatada nesta dissertação,
foi elaborado um mapeamento sistemático, que é apresentado nessa seção. A técnica do mapeamento
sistemático é utilizada para proporcionar uma visão ampla dos estudos primários e pode ser classificada de natureza exploratória e descritiva (KITCHENHAM et al., 2008).
As fases do mapeamento sistemático definidas para a identificação dos trabalhos, foi baseada
na publicação de Petersen et al. (2008). As etapas foram adaptadas e executadas na seguinte ordem:
• Definição das questões de pesquisa
100
• Condução da pesquisa
• Seleção dos trabalho
• Descrição dos trabalhos
Foi adaptada principalmente a análise dos resultados, que para o contexto deste trabalho, é
apresentada como descrição dos trabalhos, pois apresenta a descrição dos trabalhos que foram selecionados e considerados neste estudo.
3.3.1
Definição das questões de pesquisa
A principal questão de pesquisa do mapeamento sistemático é a identificação de trabalhos
com foco na publicação de corpo de conhecimento, guias, boas práticas ou outros termos associados
relacionados a rastreabilidade de software como produto.
As perguntas de pesquisa identificadas são as seguintes:
• Pergunta PP 1: Quais trabalhos publicados tratam de corpo de conhecimento na área de rastreabilidade em software como produto?
• Pergunta PP 2: Quais trabalhos publicados tratam de corpo de conhecimento nas áreas correlatas da engenharia de software?
• Pergunta PP 3: Quais as áreas de engenharia de software possuem publicações relacionadas a
corpo de conhecimento?
3.3.2
Condução da pesquisa
A condução do mapeamento sistemático consiste em identificar os estudos que serão candida-
tos a uma análise mais detalhada que acontece na sequência, na Seção de Seleção dos trabalhos. Para
isso, o primeiro passo é a identificação da string de pesquisa, seguido da identificação das fontes de
pesquisa.
A string de busca foi definida considerando os termos necessários para que a busca seja a mais
completa possível, sem ser por demais genérica. O Quadro 23 apresenta a string de busca definida.
101
Quadro 23 – String de Busca para o Mapeamento Sistemático
traceability and (“body of knowledge” or guideline or “best practices” or standards or standardization) and (requirement or software)
As fontes de pesquisa selecionadas para este mapeamento sistemático são as mesmas utilizadas para a Revisão Sistemática, abordada na seção 3.1. Além dessas fontes, a mesma pesquisa foi
realizada usando o indexador Google acadêmico10 .
• ACM <dl.acm.org>
• IEEE <ieeexplore.ieee.org>
• ScienceDirect <sciencedirect.com>
• Springer <link.springer.com>
• Google Acadêmico <scholar.google.com>
Para selecionar os trabalhos, foram aplicados alguns critérios como segue:
• Deve atender a string de busca definida
• Deve ter um texto completo do trabalho disponível para análise
• Deve descrever resultados relacionados ao tema, no mínimo deve possuir uma descrição do
corpo de conhecimento ou equivalente, para ser analisado. A string de busca foi adaptada conforme as necessidades de sintaxe para cada uma das fontes de pesquisa utilizadas.
Para excluir os trabalhos que não contribuem com a pesquisa, foram aplicados os seguintes
critérios:
• Estudos publicados em editoriais, prefácios, trabalhos de resumo, entrevistas, notícias e revisões.
10
Segundo anunciado no site: scholar.google.com, o google acadêmico ajuda a identificar as pesquisas mais relevantes
do mundo acadêmico. Podem ser encontrados trabalhos revisados por especialistas (peer-rewiewed), teses, livros,
resumos e trabalhos de editoras acadêmicas, organizações profissionais, bibliotecas de pré-publicações, universidades
e outras entidades acadêmicas
102
• Estudos sem o registro de um corpo de conhecimento, que possuem somente revisão sobre o
tema ou que tratem somente de conceitos relacionados ao tema.
• Estudos que sejam similares (quando dois ou mais trabalhos apresentem conteúdos semelhantes, será considerado o estudo mais recente), (quando forem a mesma publicação será considerado o indexador fonte de publicação).
• Estudos que não façam parte da área de pesquisa.
Para responder as perguntas elaboradas neste mapeamento sistemático, foram identificados
dados que deveriam ser extraídos de cada estudo. Esses dados, uma descrição e a questão de pesquisa
relacionada são apresentados no Quadro 24
Quadro 24 – Extração dos dados no mapeamento sistemático
Dados extraídos
Descrição
Referência bibliográfica
Área de aplicação
Ano da Publicação
Dados completos da referência bibliográfica do trabalho
Área da engenharia de software, ou similar, na qual o
corpo de conhecimento foi elaborado
Ano em que a publicação do trabalho foi realizada
Questão de pesquisa
PP 1, PP 2 e PP 3
PP 1, PP 2 e PP 3
PP 1, PP 2 e PP 3
A partir da definição dos critérios, a pesquisa foi executada e o resumo dos resultados são
apresentados no Quadro 25.
Quadro 25 – Identificação dos estudos primários do mapeamento sistemático
Fonte
Trabalhos Extraídos
Trabalhos Selecionados
ACM
25
0 - 0,0%
IEEE
34
3 - 8,8%
Science Direct
90
0 - 0%
Springer
90
1 - 1,1 %
Google Acadêmico
56
16 - 28,6%
Total
295
20 - 6,8%
A extração dos trabalhos e a aplicação dos critérios retornou 20 candidatos que foram estudados na íntegra para a seleção dos classificados como trabalhos relacionados ao corpo de conhecimento
proposto neste estudo.
103
3.3.3
Seleção dos trabalhos
Após o estudo na íntegra dos 20 trabalhos extraídos, 8 foram selecionados e incluídos como
corpos de conhecimento considerados neste estudo. A seleção considerou que os trabalhos possuíam
a estrutura mínima necessária para ser analisado e classificado como pertinente. Foi considerado que
o trabalho deveria ter relação com a engenharia de software e ter pelo menos uma estrutura proposta
para organização de conhecimento em forma de um documento.
3.3.4
Descrição dos trabalhos
A partir do mapeamento sistemático foram identificados os trabalhos já realizados que pos-
suem relação com o corpo de conhecimento proposto nesta dissertação. Os nomes das áreas de conhecimento mapeadas foram mantidos na língua original dos documentos referenciados.
SWEBOK
A principal referência de corpo de conhecimento na área de engenharia de software é o SWEBOK11
(Software Engineering Body of Knowledge) mantido pela IEEE Computer Society12 . A estrutura do
SWEBOK já está consolidada por ser uma publicação referência da área de engenharia de software
que iniciou a sua escrita em 1998 (IEEE, 2014).
A publicação do SWEBOK representa um marco no reconhecimento da engenharia de software como uma disciplina da engenharia (IEEE, 2014). São relacionadas 15 áreas de conhecimento,
identificadas como KA (knowledge area) e apresentadas no Quadro 26. Segundo Apshvalka e Wendorff (2006), o SWEBOK é enorme e complexo, em função da extensão da própria área.
A cada uma das áreas de conhecimento é dedicado um capítulo com a apresentações dos conceitos relacionados e informações sobre o assunto.
SEBOK
O SEBOK13 (Systems Engineering Body of Knowledge) tem o objetivo de fornecer uma base conhecimento ampla e com atualizações regulares no desenvolvimento e operação de sistemas (PYSTER;
OLWELL, 2013). O SEBOK teve a primeira versão em 2010.
11
12
13
www.swebok.org
http://www.computer.org/
www.sebokwiki.org
104
Quadro 26 – Áreas de conhecimento do SWEBOK
Knowledge Area (KA)
Software Requirements
Software Design
Software construction
Software Testing
Software Maintenance
Software Configuration Management
Software Engineering Management
Software Engineering Process
Software Engineering Models and Methods
Software Quality
Software Engineering Professional Practice
Software Engineering Economics
Computing Foundations
Mathematical Foundations
Engineering Foundations
Figura 37 – Engenharia de sistemas e Engenharia de sistemas no contexto do ciclo de vida de projeto
Fonte: Pyster e Olwell (2013)
É possível perceber, na Figura 37 que o SEBOK abrange todas as fases desde a definição
até a evolução e refinamento dos sistemas de informação e que contempla o ambiente de projeto,
os engenheiros de sistemas, os desenvolvedores de sistemas e os produtos e serviços associados. A
abrangência é grande, pois, segundo Pyster e Olwel (2013) um dos principais objetivos da engenharia
de sistemas é a integração das diferentes especialidades de engenharia em um projeto ou programa.
Contempla todo o ciclo de vida da engenharia de sistemas. No contexto do SEBOK, a engenharia de
105
software é distribuída pelas diferentes fases do ciclo de vida apresentado pelo guida do SEBOK.
BABOK
O BABOK (Business Analysis Body of Knowledge) é uma publicação do International Institute of
Business Analysis14 . Conforme o próprio instituto responsável pela publicação do guia do BABOK
descreve em seu site IIBA (2014), o guia do BABOK contém a descrição de práticas geralmente aceitas no campo da análise de negócios. O propósito principal do guia é definir o conjunto de atividades
que devem ser desempenhadas pelo analista de negócios na sua atividade. A Figura 38 apresenta as
áreas de conhecimento ou KA’s tratadas pelo guida do BABOK.
Figura 38 – Relacionamento entre as áreas de conhecimento do BABOK
Fonte: IIBA (2009)
REBOK
O REBOK (Requirements Engineering Body of Knowledge) foi criado com o objetivo de fornecer
um guia para todos os envolvidos na engenharia de requisitos (AOYAMA et al., 2010). Um grande
desafio na criação do corpo de conhecimento da engenharia de requisitos foi integrar os trabalhos já
realizados como SWEBOK, BABOK e os conceitos de certificação como CPRE15 (Certified Professional for Requirements Engineering) que possui documentos com conteúdo referente ao exame de
certificação aplicado pelo CPRE. Esses documentos são os Syllabus (IREB, 2014). A estrutura hierárquica do REBOK é dividida em duas partes. A primeira, representada no Quadro 27 apresenta as
14
15
http://www.iiba.org/
http://www.ireb.org/
106
8 áreas do conhecimento do núcleo. A segunda, representada no Quadro 28 apresenta as 2 áreas do
conhecimento estendidas (AOYAMA et al., 2010).
Quadro 27 – Áreas de conhecimento do REBOK
KA
Type
Requirements Engineering Funda- Technical
mentals
Requirements Engineering Process Technical
Requirements Elicitation
Process
Requirements Analysis
Requirements Specification
Process
Process
Requirements Verification, Validation and Evaluation
Requirements Planning and Management
Practical Consideration
Process
Technical
Technical
Definition
Definition and essential properties on requirements
Concept and models of requirements engineering process
Sources and techniques for requirements elicitation
Techniques for analyzing requirements elicited
Specification techniques for requirements
analyzed
Techniques validating requirements specification
Properties, metrics and management techniques
of requirements
Patterns and best practices for practicing requirements engineering
Quadro 28 – Áreas de conhecimento extendidas do REBOK
KA
Type
Definition
Enterprise Analysis
Process
Definition and analysis of essential properties
of enterprise business
Product Analysis
Process
Definition and analysis of essential properties
of products for market
MCBOK
Em uma publicação mais recente, Taguchi et al. (2013) propõem a estrutura para a criação de um
corpo de conhecimento sobre modelo de verificação para o desenvolvimento de software - MCBOK
(Body of Knowledge on Model Checking for Software Development). Segundo os autores, o corpo
de conhecimento auxiliará na padronização dos conceitos em torno do modelo de verificação para o
desenvolvimento de software.
A estrutura do MCBOK é apresentada por Taguchi et al. (2013) e pode ser vista no Quadro
29.
O MCBOK é uma publicação que faz parte de um projeto maior chamado FMBOK (Formal
Methods Body of Knowledge). O FMBOK ainda é um projeto e pretende abranger todas as áreas re-
107
Quadro 29 – Áreas de conhecimento do MCBOK
KA
Areas
Adaptation Methods
KA 1 - Model Checking Process
Adaptation Steps
Cost Estimation
Team Organization
Computation Models
KA 2 - Model Checking Theory
Temporal Logics
Reduction Methods
Principles
KA 3 - Model Checking Tools
Various Model Checking Tools
Support Tools
Commercial Systems
KA 4 - Model Checking
Application Areas
Middlewares
Network Systems
Embedded Systems
lacionadas aos métodos formais.
TSP e PSP Body of Knowledge
O TSP16 (Team Software Process) e PSP17 (Personal Software Process), segundo Humphrey et al.
(2010) são baseados na premissa de que um processo definido e estruturado pode melhorar a qualidade
do desempenho individual. Dessa forma, o PSP oferece um conjunto de métodos que podem ser
aplicados aos processos individuais de trabalho dos profissionais envolvidos com o desenvolvimento
de software, enquanto o TSP oferece um conjunto de conhecimentos e habilidades que podem ser
aplicados pelos profissionais.
O TSPBOK(Team Software Process Body of Knowledge) define um conjunto de conhecimentos e habilidades que devem ter os membros de uma equipe de desenvolvimento de software
(HUMPHREY et al., 2010). A estrutura do documento TSPBOK é apresentada no Quadro 30.
O PSPBOK (Personal Software Process Body of Knowledge) tem o objetivo de fornecer orientações através de métodos disciplinados para profissionais de software. O documento descrito por
16
17
Team Software Process and TSP are service marks of Carnegie Mellon University
Personal Software Process and PSP are service marks of Carnegie Mellon University
108
Quadro 30 – Áreas de competência do TSPBOK
Competency Area 1:
TSP Foundations and
Fundamentals
Knowledge Work
TSP Prerequisite Knowledge
TSP Principles
TSP Process Elements and Measures
TSP Quality Practices
Teams and Teambuilding
Team Types, Styles, and Dynamics
Competency Area 2:
Team Foundations
Team Formation and Membership
Team Member Responsibilities
Team Member Roles
Team Leader Role
Coach Role
Change Management Fundamentals
Competency Area 3:
Project Planning with TSP
Piloting TSP in an Organization
Preparing Management and Teams for TSP Implementation
The TSP Launch Meetings
The TSP Relaunch
Competency Area 4:
Project Implementation and
Tracking with TSP
Weekly Meetings
Checkpoints
Communicating with Stakeholders
Replanning
Phase, Cycle, and Project Postmortems
Data Recording
Competency Area 5:
Gathering and Using TSP Data
Gathering and using Size Data
Gathering and Using Schedule Data
Gathering and Using Quality Data
Gathering and Analyzing Postmortem Data
Competency Area 6:
Scaling Up the TSP
Organizational Implementation
TSP Process V ariations
Large-scale TSP Teams
109
Pomeroy-Huff et al. (2009) apresenta os conceitos e os métodos que podem ser usados dentro de cada
área de competência, que são distribuídas em 7 capítulos. Conforme apresentado no Quadro 31 as
duas primeiras áreas (1 e 2) apresentam os conceitos relacionados ao PSPBOK. As áreas 3, 4, 5 e 6
tratam de temas mais específicos. A última área (7) discute as experiências avançadas de acordo com
quem pratica.
Quadro 31 – Competências do PSPBOK
Competency Area 1
Foundational Knowledge
Competency Area 2
Basic PSP Concepts
Competency Area 3
Size Measuring and Estimating
Competency Area 4
Making and Tracking Project Plans
Competency Area 5
Planning and Tracking Software Quality
Competency Area 6
Software Design
Competency Area 7
Process Extensions and Customizations
Guidelines for requirement traceability information
Um trabalho identificado durante a realização do mapeamento sistemático foi selecionado
por tratar da realidade de organizações pequenas, com poucos recursos e que desejam implementar
a rastreabilidade. Mesmo sem ser um corpo de conhecimento ou de estar organizado como tal, esse
trabalho propõe a classificação das informações relacionadas à rastreabilidade que contribuem para a
proposta do corpo de conhecimento. Em Ahmad e Ghazali (2007), é possível identificar o conjunto
de informações sugeridas para organizações com essas características. As informações sugeridas são
apresentadas no Quadro 32, onde em “Traceability Classes” são apresentadas as duas formas de classificação da rastreabilidade. Em seguida, em “Traceability Relations” são relacionadas as diferentes
formas de relacionar os artefatos na construção da rastreabilidade. Finalmente, são apresentadas as
boas práticas para a documentação das informações da rastreabilidade para pequenos projetos, que
se limitam a 3 selecionadas das anteriores, justificada a seleção por uma pesquisa relatada no próprio
trabalho de Ahmad e Ghazali (2007).
Outros trabalhos
Durante a realização do mapeamento sistemático, foram identificados outros trabalhos de
construção de corpo de conhecimento com características específicas, como o SMBOK (Software
Measurement Body of Knowledge) que não foi selecionado pois o seu objetivo é propor mais uma
110
Quadro 32 – Informações de Rastreabilidade de Requisitos
Traceability Classes
Pre-and Post-Traceability
Forwardand Backward Traceability
Requirement-Source Traceability
Requirement-RationaleTraceability
Traceability Relations
Requirement-People Traceability
Requirement-Requirement Traceability
Requirement-ComponentTraceability
Requirement-VerificationTraceability
Good Practices for Documenting
Traceability Information for
Small Projects
Requirement-Source/PeopleTraceability
Requirement-RationaleTraceability
Requirement-VerificationTraceability
área de conhecimento para o SWEBOK.
É importante citar também o PMBOK (Project Management Body of Knowledge) mantido
pelo PMI18 (Project Management Institute) que se autodenomina a maior associação sem fins lucrativos de profissionais de gerenciamento de projetos e gerenciamento de portfólio. A associação foi
fundada em 1969 e publica regularmente o PMBOK que contém um conjunto de boas práticas que
são aplicáveis na maioria dos projetos e que contém um vocabulário comum sobre a profissão de
gerenciamento de projetos. O PMBOK é divido em grupos de processo, conforme apresentado na
Figura 39 e em áreas de conhecimento, conforme o Quadro 33.
Figura 39 – Grupo de processos de gerenciamento de projetos
Fonte: PMI (2013)
18
http://www.pmi.org/
111
Quadro 33 – Áreas de conhecimento do PMBOK
Gerenciamento de integração de projeto
Gerenciamento do escopo do projeto
Gerenciamento do tempo do projeto
Gerenciamento dos custos do projeto
Gerenciamento da qualidade do projeto
Gerenciamento dos recursos humanos do projeto
Gerenciamento das comunicações do projeto
Gerenciamento dos riscos do projeto
Gerenciamento das aquisições do projeto
Gerenciamento das partes interessadas no projeto
Discussão sobre os trabalhos relacionados
A primeira observação é que não foi encontrado corpo de conhecimento de rastreabilidade
no mapeamento sistemático realizado. Também não foi encontrada nenhuma área de conhecimento
específica de rastreabilidade nos corpos de conhecimento selecionados. A rastreabilidade é mencionada no SWEBOK como um item nas áreas de conhecimento de considerações práticas de métodos e
modelos da engenharia de software. A rastreabilidade neste contexto serve como um suporte sempre
associada a gestão das mudanças e no apoio a qualidade de software. No REBOK a rastreabilidade é
apresentada de forma breve como um tópico que provê a solução para a gestão do desenvolvimento
dos requisitos e de outros artefatos relacionados aos requisitos. No SEBOK não há uma área dedicada
a rastreabilidade, no entanto, o termo aparece muitas vezes no texto associado a gestão dos requisitos,
sua modificação e análise de impacto. O BABOK apresenta a rastreabilidade com um item “gestão
da rastreabilidade de requisitos” e identifica o propósito, a descrição, as entradas, os elementos, as
técnicas e os stakeholders, e finalmente as saídas relacionadas a rastreabilidade. O BABOK apresentou a rastreabilidade de forma estruturada, embora as informações sobre o tema sejam básicas. Os
documentos MCBOK, TSP, PSP e PMBOK não trazem informações da rastreabilidade.
Em uma análise mais geral dos documentos selecionados, o SWEBOK apresenta um conjunto
de áreas de conhecimento que cobre a produção de software e é considerado um marco na engenharia
de software (IEEE, 2014). Usando o SWEBOK como referência, o SEBOK é mais genérico e a proposta está relacionada a integrar todas as engenharias na concepção e construção de sistemas, que por
sua vez, englobam os softwares. Um corpo de conhecimento mais específico é o BABOK que se dedica as práticas da análise de negócios, e que possui interseção com a área de conhecimento Software
Requirements do SWEBOK. O BABOK é um dos exemplos de corpo de conhecimento que tem como
112
objetivo detalhar uma das etapas do desenvolvimento de software. Assim, também o REBOK propõe
estruturar a disciplina de engenharia de requisitos considerando outros conjuntos de conhecimento
e padrões publicados. O MCBOK trata de um área específica e transversal ao desenvolvimento de
software que é a verificação. O TSP e PSP são corpos de conhecimento que abrangem as áreas de
conhecimento e habilidades aplicáveis aos profissionais da área de desenvolvimento, uma abordagem
particular em relação as relatadas anteriormente.
Todos os trabalhos relacionados e descritos nessa seção contribuem por apresentar uma estrutura de guia ou corpo de conhecimento em algum assunto relacionado a engenharia de software
diretamente ou à produção de software de forma mais ampla. O diferencial do proposto nessa dissertação é o uso desses formatos e estruturas na área específica de rastreabilidade de requisitos de
software como produto.
Um trabalho que pode ser considerado relevante pelo conteúdo e formato e por se aproximar
mais do objetivo deste trabalho de proposição de um corpo de conhecimento de rastreabilidade de requisitos para organizações que produzem software como produto é apresentado por Ahmad e Ghazali
(2007). O autor propõe um guia de informações para rastreabilidade de requisitos com uma estrutura
das informações categorizadas. Nesta dissertação, através da proposta de um corpo de conhecimento
de rastreabilidade, é sugerido um guia mais amplo do ponto de vista da rastreabilidade, relacionando
as abordagens e tecnologias. No entanto, do ponto de vista da aplicação da rastreabilidade nas organizações, é mais restrito, pois pretende cobrir as organizações que produzem software como produto.
Já com relação ao ciclo de vida de desenvolvimento de software, o corpo de conhecimento proposto
nesta dissertação se aproxima do MCBOK, que trata de uma área transversal, ou uma área que abrange
todo o ciclo de vida do software.
Para finalizar a discussão, um quadro é proposto com a organização de partes identificadas
na estrutura dos trabalhos selecionados. O objetivo dessa análise é verificar as partes estruturais dos
trabalhos mais comuns para orientar a estrutura do corpo de conhecimento proposto nesse trabalho.
É possível perceber pela organização das estruturas (divisões ou capítulos) existentes nos
trabalhos identificados que a introdução e as áreas de conhecimento (knowledge area) são constantes.
Quanto as outras estruturas, variam de acordo com a maturidade, grau de desenvolvimento e também
de necessidade de cada um. Fica evidente que existem diferenças de estrutura e de conteúdo nos
trabalhos analisados. Pelo grau de complexidade que envolve agrupar conhecimentos tão específicos
113
x
x
Glossário
x
x
Técnicas
Usuários e Uso
Área de Conhecimento
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Estrutura
Introdução
Trabalho
SWEBOK
SEBOK
BABOK
REBOK
MCBOK
TSP
PSP
PMBOK
Fundamento
Quadro 34 – Identificação de estruturas dos corpos de conhecimento selecionados
x
x
x
x
x
x
x
x
e por outro lado dispersos (em publicações, práticas ou conhecimentos tácitos) percebe-se que as
propostas mais maduras possuem informações e estruturas mais consolidadas. Essas características
foram observadas no SWEBOK e o PMBOK. Também pela abrangência, por serem agrupadores de
conhecimento com uma amplitude maior (ambos tratam de áreas de conhecimento amplas), uma em
engenharia de software e outras em gerenciamento de projetos, os documentos são extensos e com
muitos conceitos e informações em seus conteúdos. Outros documentos analisados como o REBOK
ou o MCBOK, a abrangência é menor do ponto de vista da área tratada. Além de mais específicos,
são mais recentes, o que os torna menos consolidados do ponto de vista de uso e aperfeiçoamento.
4 CORPO DE CONHECIMENTO
O corpo de conhecimento deve cobrir as áreas identificadas tanto na revisão sistemática quanto
o survey realizado neste estudo (ver as seções 3.1 e 3.2). Nesse sentido, a construção do corpo de conhecimento segue a proposição de um conjunto de conhecimentos identificados ao longo da execução
deste trabalho. Outra referência que norteia a construção do corpo de conhecimento é o conjunto de
trabalhos identificados na seção 3.3. Para a definição da estrutura do corpo de conhecimento este trabalho usa como guia as atividades propostas por Zoucas (2010) que orienta o desenvolvimento de
modelos de capacidade de processo com base no contexto e nas características de um segmento ou
domínio. Também reforçando a importância da estruturação do corpo de conhecimento, Henry et al.
(2013) cita em seu artigo que conta as experiências na criação de um corpo de conhecimento, duas
recomendações para fazê-lo: (i) identificar as fontes críticas e (ii) estabelecer um conteúdo inicial.
A construção do corpo de conhecimento inicia então pela definição do método de construção,
que apresenta todas as etapas seguidas para a elaboração do corpo de conhecimento proposto na seção
4.1. Na seção seguinte, 4.2 a estrutura básica é apresentada no projeto do modelo e por fim, a seção
4.3 descreve a versão preliminar do corpo de conhecimento proposto.
4.1
MÉTODO DE CONSTRUÇÃO DO CORPO DE CONHECIMENTO
O PRO2PI-MFMOD1 foi usado como base para definir a sequência das fases que são usadas
nesse trabalho. A estrutura geral do framework possui quatro partes: Práticas Sequenciais, Regras de
Customização, Exemplos de Utilização e Exemplos de Técnicas. As 7 práticas sequenciais propostas
no PRO2PI-MFMOD são:
P1 Decisões iniciais
P2 Análise de fontes
P3 Estratégia de desenvolvimento
P4 Projeto do modelo
1
Framework de métodos para a construção de Modelos de Referência de Processo
115
P5 Desenvolvimento da versão preliminar do modelo
P6 Validação da versão preliminar do modelo
P7 Consolidação do modelo
Para a definição das fases de construção do corpo de conhecimento proposto neste trabalho,
a estrutura do PRO2PI-MFMOD proposta por Zoucas (2010) foi adaptada. A seguir, a adaptação é
apresentada e justificada.
Em P1, as decisões iniciais do desenvolvimento do novo modelo são tomadas. Nesse trabalho,
a decisão foi tomada já na proposta do estudo. Os prazos e riscos envolvidos são o próprio planejamento da dissertação.
A análise das fontes, definida em P2 como o levantamento, estudo e aquisição do conhecimento das práticas de um determinado segmento ou domínio, foi realizado e está descrito no Capítulo
3 desse trabalho. Nele são descritas três seções, a primeira uma revisão sistemática da literatura, a
segunda um survey para validar as informações colhidas e identificar um padrão de prática nas organizações, relacionado a rastreabilidade, e na terceira um levantamento de trabalhos relacionados ao
tema proposto nessa dissertação.
A estratégia de desenvolvimento, correspondente ao P3, aponta para a estratégia a ser utilizada
para desenvolver o modelo. Nesse ponto, a seção 4.1 é dedicada para apresentar a estratégia definida
para elaboração do corpo de conhecimento. A estratégia aqui é o uso do próprio PRO2PI-MFMOD
como base e adaptá-lo para a construção do corpo de conhecimento.
A prática P4 que trata do projeto do modelo, aponta para a execução de um projeto antes
de construir. Neste trabalho, uma seção é dedicada para apresentar o projeto do modelo proposto. A
seção 4.2 descreve o projeto.
Após a elaboração do projeto do modelo, uma versão preliminar é desenvolvida. Isso diz
respeito à prática P5. A versão preliminar é apresentada na seção 4.3 e representa a primeira versão
do modelo que pode ser aplicada para validação.
A prática P6 trata da validação do modelo proposto. Nesse trabalho, o corpo de conhecimento
proposto é avaliado por um conjunto de especialistas na área de rastreabilidade. O Capítulo 5 apresenta o método de avaliação e os resultados alcançados.
116
A consolidação do modelo proposta no PRO2PI-MFMOD tem um papel importante quando
se trata de um corpo de conhecimento. No entanto, a consolidação deste documento deve acontecer
envolvendo os interessados no uso deste documento e também nos especialistas em rastreabilidade.
Pretende-se que a consolidação aconteça depois do lançamento do documento e com a discussão
em torno da sua organização e conteúdo, além da validação proposta pela prática 6. Um corpo de
conhecimento não se consolida sem o envolvimento da comunidade interessada no tema tratado.
Um dos efeitos esperados com a publicação de uma primeira versão do corpo de conhecimento em
rastreabilidade é que a comunidade envolvida discuta a sua aplicabilidade e colabore na sua evolução.
4.2
PROJETO DO MODELO
A primeira atividade do projeto do modelo foi nomear o documento de corpo de conhecimento
de rastreabilidade. O nome definido foi TraceBok Guide (Software Traceability Body of Knowledge
Guide) - Guia de Corpo de Conhecimento em Rastreabilidade de Software. Em seguida a estrutura
do TraceBok foi definida através da identificação dos capítulos e suas seções. Neste trabalho a decisão sobre a estrutura do corpo de conhecimento proposto foi baseada em um estudo dos corpos de
conhecimento existentes e relacionados de alguma forma com o tema (ver seção 3.3). Um resumo
das estruturas propostas pelos trabalhos analisados é apresentado no Quadro 34. A análise dessas
estruturas serviu de ponto de partida para a proposta de estrutura do corpo de conhecimento de rastreabilidade e é apresentada a seguir, juntamente com a justificativa da escolha.
Capa: Identificação formal do documento
1. Introdução: Presente em 7 de 8 trabalhos selecionados, a introdução descreve o propósito do
documento e introduz o leitor ao que é tratado no documento. A introdução é composta pela
estrutura do documento que apresenta como o TraceBok está organizado (é encontrada em 4 de
8 trabalhos selecionados), os usuários e o uso que permite a identificação dos interessados no
documento e como ele pode ser usado, as áreas de conhecimento que apresentam a organização
do conhecimento em áreas no texto, e finalmente a classificação das abordagens que mostra
como as abordagens selecionadas foram classificadas no TraceBok.
2. Áreas de conhecimento: Entradas em todos os trabalhos selecionados, as áreas de conhecimento caracterizam os documentos em formato de corpo de conhecimento. Nesta parte da estrutura são inseridas todas as áreas tratadas no documento.
117
3. Glossário: Apresenta os conceitos relacionados a rastreabilidade e pretende criar uma fonte de
pesquisa para os termos relacionados a rastreabilidade, além de auxiliar no entendimento do
próprio corpo de conhecimento.
O TraceBoK foi relacionado, juntamente com a sua estrutura no Quadro 35. Nesse quadro é
possível identificar a estrutura do TraceBoK em relação aos outros corpos de conhecimento estudados.
x
x
Glossário
x
x
Técnicas
x
x
x
x
x
x
x
x
x
Usuários e Uso
Área de Conhecimento
x
x
x
x
x
x
x
x
x
Estrutura
Introdução
Trabalho
SWEBOK
SEBOK
BABOK
REBOK
MCBOK
TSP
PSP
PMBOK
TRACEBOK
Fundamento
Quadro 35 – Identificação de estruturas de documento dos trabalhos selecionados
x
x
x
x
x
x
x
x
x
x
x
Após a identificação da estrutura, é necessário definir as áreas de conhecimento que fazem
parte do corpo de conhecimento. A identificação das áreas de conhecimento que devem ser incluídas no corpo de conhecimento não é uma tarefa trivial em função da própria dificuldade de realizar
a rastreabilidade nos projetos de software. São necessárias diferentes atividades para criar e manter
a rastreabilidade. Esta afirmação é feita por Aizenbud-Reshef et al. (2006), que complementam que
uma solução genérica ainda não está disponível. Essa constatação também foi percebida nos resultados da revisão sistemática executada neste trabalho para identificar e classificar as abordagens de
rastreabilidade. Dependendo do conjunto de características adotadas no desenvolvimento de software
(considerando ciclo de vida, modelagem, técnicas de desenvolvimento e ferramentas) as soluções
variam consideravelmente.
Considerada a dificuldade relatada, a identificação das áreas de conhecimento partiu dos resultados colhidos na revisão (ver seção 3.1.2). Foram desconsideradas as abordagens que não se mos-
118
traram aplicáveis, através de descrição no trabalho analisado, para software como produto. Esse conteúdo, validado pelo survey descrito na seção 3.2, foi usado para definir as áreas candidatas.
Tomando a definição do corpo de conhecimento como uma ontologia para um domínio profissional específico (BOWEN; REEVES, 2011), é possível afirmar que o corpo de conhecimento
proposto deverá atender as necessidades de conhecimento dos profissionais que trabalham ou tem
interesse na rastreabilidade de requisitos de software. Para facilitar o acesso à informação definida no
corpo de conhecimento, e considerando que ainda não existe uma solução genérica para a rastreabilidade (AIZENBUD-RESHEF et al., 2006), foi definido que as abordagens de rastreabilidade seriam
organizadas em áreas de conhecimento pela sua finalidade de uso. Desta forma, os interessados no
conhecimento disposto no documento, podem encontrar as informações conforme suas necessidades
de uso da rastreabilidade.
A primeira área de conhecimento proposta no TraceBok foi definida para agrupar e apresentar os conceitos básicos sobre a rastreabilidade e também descrever o conceito de ciclo de vida da
rastreabilidade que é definida como um padrão pelos autores desta área (MÄDER; GOTEL, 2012),
(CLELAND-HUANG; GOTEL; ZISMAN, 2012). Os conceitos apresentados neste trabalho nas seções 2.2 e 2.3 foram usados para estruturar esta área de conhecimento que ficou assim definida:
1 - Ciclo de Vida da Rastreabilidade
Para definição das áreas de conhecimento seguintes, recorreu-se a validação das abordagens
selecionadas nas organizações através do survey (ver seção 3.2.4). O resultado mostrou que a rastreabilidade de requisitos foi a única finalidade apontada pela organizações entrevistadas. Dessa forma,
esta foi definida como a primeira área de conhecimento, seguida daquelas finalidades que foram citadas mais de uma vez nos trabalhos selecionados na revisão sistemática. Aquelas abordagens, que
por serem muito específicas, foram citadas apenas uma vez nos resultados da revisão sistemática e
não apareceram nas organizações através do survey foram desconsideradas para a primeira versão do
corpo de conhecimento.
As áreas de conhecimento selecionadas, para agrupar as abordagens de requisitos, são as
seguintes:
2 - Rastreabilidade de Requisitos Funcionais
119
3 - Rastreabilidade de Requisitos Não Funcionais
4 - Rastreabilidade em Linha de Produto de Software
A rastreabilidade de requisitos de segurança, que foi tratada como uma classificação independente, na organização do corpo de conhecimento foi agrupada na área de conhecimento Rastreabilidade de Requisitos Não Funcionais.
Depois de definidas as áreas de conhecimento, foi necessária a definição do conjunto de informações que cada abordagem de rastreabilidade selecionada deveria fornecer. Esta padronização serve
para auxiliar na compreensão das abordagens, criando um padrão na apresentação do conhecimento.
Para a definição do conjunto de informações, foi tomado como base a proposta feita por
Schwarz (2009) que propõe a adaptação de um conjunto de atividades a partir dos trabalhos de
Pinheiro (1996) e Knethen e Paech (2002). As atividades propostas cobrem diferentes aspectos da
rastreabilidade: definição, identificação, registro, recuperação, utilização e manutenção. Outra fonte
para a definição do conteúdo das abordagens foi a própria definição do ciclo de vida apresentado por
Mäder e Gotel (2012), e Cleland-Huang, Gotel e Zisman (2012). O conjunto de tópicos para organizar
o conteúdo das abordagens foi definido a partir destas fontes e é apresentado na Figura 40.
Figura 40 – Conteúdo das abordagens
Fonte: O Autor
A descrição inicial apresenta a abordagem de forma geral e descreve os conceitos da abordagem. As restrições de uso permitem ao leitor identificar os pontos que restringem o uso da abordagem
e informar mas objetivamente se pode ser usada para a finalidade desejada. As ferramentas da abordagem indicam quando há ferramentas que suportam total ou parcialmente o processo descrito na
abordagem. A última informação descreve como aplicar a abordagem. Aqui é descrito como pode ser
usada a abordagem, além de como criar e usar a rastreabilidade.
120
4.3
VERSÃO PRELIMINAR DO CORPO DE CONHECIMENTO
Após o projeto do corpo de conhecimento, a primeira versão do TraceBok foi elaborada con-
siderando o conteúdo planejado na seção 4.2.
Os corpos de conhecimento são elaborados e crescem com o apoio de uma comunidade de
especialistas. Esta comunidade contribui com o aperfeiçoamento dos conteúdos apresentados e com
a proposição de novos conteúdos. O TraceBok, proposto nesta dissertação, foi planejado para ser a
primeira versão de um documento que deve evoluir com o apoio da comunidade. Com este objetivo,
foi tomada a decisão de escrever o TraceBok em inglês para aumentar a abrangência do documento.
A estrutura do TraceBok é apresentada a seguir. A versão 1.0 do TraceBok é apresentada como
um documento completo em função da sua característica de corpo de conhecimento (ver Apêndice
E).
1 Introduction Tracebok Guide
1.1 Document Structure
1.2 Users and Uses
1.3 Knowledge Areas
1.4 Classification Approaches
2 Traceability Life Cycle
2.1 Basic Concepts
2.2 Traceability Life Cycle
2.2.1 Traceability Strategy
2.2.2 Traceability Creation
2.2.3 Traceability Use
2.2.4 Traceability Maintenance
3 Functional Requirements Traceability
3.1 #FRT01 - Requirement and Source Code Traceability
3.2 #FRT02 - Requirements Traceability in an Heterogeneous Model-based Design Process
3.3 #FRT03 - End-to-end Software Traceability
121
3.4 #FRT04 - Pushing Timely Trace Recommendations to Project Stakeholders
3.5 #FRT05 - Capturing (semi)automatically traceability relationships from requirements and design
decisions to architecture and implementation
3.6 #FRT06 - Traceability in secure and dependable software development
3.7 #FRT07 - Exploring traces links to source code through testing
3.8 #FRT08 - Graph-based traceability
3.9 #FRT09 - Architectural Design Decisions Evolution through Model Driven Engineering
3.10 #FRT10 - Supporting Requirements in a Traceability Approach between Business Process and
User Interfaces
3.11 #FRT11 - Generation and Validation of Traces between Requirements and Architecture
3.12 #FRT12 - Semi-automated Traceability Maintenance - traceMaintainer
4 Non-Functional Requirements Traceability
4.1 #NFRT01 - Full Traceability of Non-Functional Requirements within Domain-Specific Modeling
4.2 #NFRT02 - Safety Requirements Traceability Support in MDD of Robotic Applications
4.3 #NFRT03 - Means-ends and whole-part traceability analysis of safety requirements
4.4 #NFRT04 - A SysML-based approach to traceability management and design slicing in support
of safety certification
5 Software Product Line Traceability
5.1 #SPLT01 - A Metamodeling Approach to Tracing Variability between Requirements and Architecture in SPL
5.2 #SPLT02 - Traceability in Software Product Line using Formal Concept Analysis
5.3 #SPLT03 - A rule-based traceability approach for product line systems
6 Glossary TraceBok Guide
7 References
5 AVALIAÇÃO DO TRACEBOK
Este capítulo apresenta os resultados dessa avaliação do documento do corpo de conhecimento
proposto.
Uma avaliação do corpo de conhecimento proposto com vistas a sua aplicabilidade é fundamental para validar os resultados atingidos até a proposta do documento elaborado para traduzir o
conhecimento identificado durante a realização desse trabalho. O objetivo mais específico, no entanto,
é identificar a opinião de especialistas em relação as qualidades da aplicação do corpo de conhecimento em ambientes reais. Neste momento, duas variáveis são importantes de serem definidas e que,
mais tarde nesse capítulo são detalhadas. A primeira diz respeito aos especialistas, que devem ser
profissionais conhecedores de processos de desenvolvimento de software, com experiência na aplicação de conceitos de rastreabilidade em projetos reais. A segunda definição importante de ser feita é
o que pode ser considerado um ambiente de desenvolvimento de produto de software para servir de
parâmetro para que os especialistas façam a avaliação.
Para realizar a avaliação foi definido uso da estrutura de pesquisa de um survey com a técnica
do GQM para orientar a estruturação e avaliação dos resultados.
Conforme já citado nesse trabalho, na seção 3.2, Wohlin et al. (2012) e Travassos, Gurov e
Amaral (2002) afirmam que os surveys são usados quando a técnica ou ferramenta que será avaliada já
está em uso ou antes de colocá-la em uso. Neste caso, da avaliação da aplicabilidade do TraceBok, o
objetivo é a realização de uma avaliação ates de publicá-lo. Mais detalhes sobre a definição e aplicação
de surveys pode ser consultada na seção 3.2 nesse trabalho.
As fases para a realização do survey usadas neste capítulo são baseadas em Travassos, Gurov
e Amaral (2002), assim como utilizada anteriormente na seção survey. A Figura 22 apresenta as fases
que são adotadas para a elaboração da validação do corpo de conhecimento.
A sequência de atividades para a execução do survey segue a seguinte ordem:
1. Planejamento: Nessa fase são definidos os objetivos da investigação, e quais as informações necessárias, além do tamanho da amostra. Em seguida o questionário é elaborado e uma validação
é realizada através de um estudo piloto. Adequações são realizadas se necessário.
123
2. Execução: Na execução a coleta é realizada e as informações são organizadas e analisadas.
3. Resultados: Na fase de resultados, a interpretação dos dados é feita e a redação é elaborada.
Nas seções seguintes, as fases da elaboração do survey são detalhadas.
5.1
PLANEJAMENTO
Na fase de planejamento o primeiro passo é a definição do objetivo da realização do survey.
a) Definir os objetivos da investigação Avaliar a aplicabilidade do corpo de conhecimento proposto
nesse trabalho é o objetivo principal da aplicação do survey. Este objetivo é traduzido na estrutura do GQM conforme segue:
G1
Analisar o corpo de conhecimento
Com o propósito de definir
Com respeito a aplicabilidade
Do ponto de vista de especialistas em implantação de processos de software com experiência
em rastreabilidade
No contexto da adoção de práticas de rastreabilidade em organizações de software como produto
A hipóteses definida a partir do objetivo (G1) é:
Hipótese nula: H0 = “O corpo de conhecimento elaborado neste estudo não é aplicável nas
organizações que desenvolvem software como produto”.
b) Decidir a informação necessária
Seguindo a hierarquia proposta na Figura 23, que apresenta as questões derivadas do objetivo,
a seguir são apresentadas as questões e as métricas associadas para atender o objetivo G1.
Q1.1 A forma de apresentação do corpo de conhecimento (organização dos capítulos e seções)
é compreensível?
Q1.2 É fácil encontrar as informações desejadas nas estrutura proposta pelo corpo de conhecimento?
124
Q1.3 O corpo de conhecimento contém abordagens de rastreabilidade conhecidas por você?
Q1.4 Você conhece alguma abordagem de rastreabilidade que não aparece no corpo de conhecimento?
Q1.5 O corpo de conhecimento apresenta pelo menos uma abordagem que pode ser aplicada
nas organizações que você tem ou teve contato?
Q1.6 O corpo de conhecimento pode ser usado para auxiliar os envolvidos no conhecimento
dos conceitos relacionados à rastreabilidade?
Q1.7 As abordagens apresentadas no corpo de conhecimento estão alinhadas aos modelos de
qualidade que você conhece?
Q1.8 Você usaria o corpo de conhecimento como apoio em atividades de implantação ou avaliação de práticas de rastreabilidade nas organizações?
A fim de avaliar a aplicabilidade do corpo de conhecimento proposto, foi projetada uma escala
de Likert (1932) com os valores apresentados no Quadro 36.
Quadro 36 – Atributos para avaliação do corpo de conhecimento
Atributo
Descrição
CT
Concordo totalmente
CP
Concordo parcialmente
N
Não tenho opinião
DP
Discordo parcialmente
DT
Discordo totalmente
Valor
5
4
3
2
1
Ao responder o questionário, os avaliadores podem escolher entre os atributos apresentados no
Quadro 36. Cada atributo possui um valor associado e apresentado na coluna Valor do Quadro.
Perguntas elaboradas para o questionário podem ser afirmações positivas, caso das questões
Q1.1, Q1.2, Q1.3, Q1.5, Q1.6, Q1.7 e Q1.8. A questão Q1.4 é caracterizada como uma afirmação negativa. Neste caso, os valores apontados no Quadro 36 foi invertido, o atributo CT passa
a ter o valor 1 e os outros seguem nesta ordem.
Esta classificação é apresentada por McClelland (1976) no contexto de uma proposta de análise
de dados para escalas de Likert com 5 valores.
Segundo McClelland (1976) analisar a simples média dos valores obtidos a partir da escala
estabelecida pode provocar distorções. Se por exemplo, existir uma distribuição semelhante
125
entre respostas que concordam totalmente e que discordam totalmente, a média pode conduzir
para a interpretação de que os respondentes não tem opinião. Isso se dá, pois o equilíbrio entre
a quantidade de respostas nos extremos da escala, conduz para o centro, onde está a área neutra.
A proposta nesta avaliação é identificar a soma dos valores correspondentes ao atributo escolhido pelo entrevistado (conforme apresentado no Quadro 36). A partir da soma é calculado
então o percentual correspondente daquele critério. Desta forma é possível apresentar o percentual, considerando o valor relativo do atributo.
As métricas usadas para avaliar o objetivo G1 são apresentadas no Quadro 37. Cada métrica
apresenta a mesma fórmula. Ao final do cálculo é possível calcular os valores de cada critério
para todas as perguntas. Desta forma, o resultado geral do objetivo G1 pode ser analisado.
Quadro 37 – Métricas para avaliação da aplicabilidade do corpo de conhecimento
Métrica
Descrição
M1 a M8
Soma de um atributo (CT, CP, N, DP, DT) / total de respostas
O grau de aplicabilidade do corpo de conhecimento é dado pelo resultado da avaliação dos
critérios para uma pergunta e de forma mais ampla analisando o resultado de um critério em
relação a todas as questões.
As questões definidas para a avaliação da aplicabilidade do corpo de conhecimento devem ser
respondidas por especialistas. Para que a avaliação possa ser realizada é necessário caracterizar
o perfil do especialista responsável por avaliar o corpo de conhecimento. As características
necessárias do especialista, para garantir a qualidade da avaliação, são descritas no Quadro 38:
Para ser selecionado como especialista habilitado a responder o questionário o profissional
deverá atender obrigatoriamente ao critério de formação mínima (conforme apresentado no
Quadro 38) e deverá obrigatoriamente atender um dos critérios de experiência definidos.
Foi considerado que para o especialista avaliar o TraceBok é necessário ter conhecimento prático do uso da rastreabilidade em organizações. Para isso foi definido que o especialista deve
ter uma formação sólida na área de computação, para garantir que conheça os conceitos de rastreabilidade e os seus benefícios. Além da formação, ficou definido que a experiência no uso
da rastreabilidade em organizações permitiria uma avaliação mais precisa do TraceBok. Neste
sentido foram determinados cinco critérios que podem atender a experiência mínima definida
para o especialista.
126
Para o item experiência, o avaliador do TraceBok deve preencher pelo menos uma das exigências definidas. Ter trabalhado como responsável por uma equipe de desenvolvimento de
software que use ou usou a rastreabilidade nos últimos três anos pode prover a experiência mínima desejada, ou, comprovar a experiência através da prática de implementação ou avaliação
dos modelos de qualidade MPS.BR (SOFTEX, 2011) ou CMMI (SEI, 2010). Nos dois modelos
a prática da rastreabilidade é cobrada já nos primeiros níveis (MPS.BR no nível G e CMMI no
nível 2). Foi considerado que 5 implementações ou avaliações são suficientes para confirmar a
prática do especialista.
Definido o perfil dos avaliadores, é necessário identificar a quantidade de avaliações necessárias
para validar as informações desejadas neste survey. Para tanto, foi estabelecido que no mínimo
teriam que ser feitas dez avaliações seguindo os critérios dos perfis definidos anteriormente.
Quadro 38 – Características dos entrevistados para avaliação do corpo de conhecimento
Característica
Critério
Formação
Ter uma formação na área de computação (em qualquer nível (graduação, especialização, mestrado, doutorado)
Ter trabalhado como responsável por uma equipe de desenvolvimento de software que use rastreabilidade nos últimos 3 anos
Implementador habilitado MPS.BR e ter participado de pelo menos 5 implementações em qualquer nível de maturidade
Avaliador habilitado MPS.BR e ter participado de pelo menos 5 avaliações em
Experiência
qualquer nível de maturidade
Implementador habilitado CMMI e ter participado de pelo menos 5 implementações em qualquer nível de maturidade
Avaliador habilitado CMMI e ter participado de pelo menos 5 avaliações em
qualquer nível de maturidade
c) Construir o questionário
O questionário foi construído em consonância com os objetivos definidos para a avaliação.
Foram definidas duas partes no questionário. A primeira com perguntas para caracterizar o
avaliador e possibilitar a contextualização dos resultados. A segunda parte pretende responder
o objetivo G1, através das questões identificadas no GQM descritas no item b) desta seção.
O questionário completo é apresentado no Apêndice D.
O questionário foi publicado como um formulário no Google Docs1 . A elaboração das perguntas e formatos foram pensados para que a aplicação fosse realizada com a presença do
1
http://docs.google.com
127
pesquisador.
d) Aplicar estudo piloto Para a aplicação do estudo piloto do questionário de avaliação do TraceBok, foi feito contato com um especialista que leu o TraceBok e respondeu o questionário. Em
seguida, foram levantadas as percepções do especialista sobre o conteúdo do questionário e as
dificuldades de resposta. Neste processo foi identificada uma dificuldade na interpretação da
pergunta 3 do questionário. A pergunta 3 está relacionada a Q1.1 do questionário de avaliação
do TraceBok (definida na seção 5.1). Foi necessário reformular o enunciado da questão para
que o entendimento dos entrevistados ficasse claro.
5.2
EXECUÇÃO
O survey foi executado para permitir colher e organizar as informações necessárias para avaliar
a percepção da aplicabilidade do TraceBok.
a) Coletar as informações
Durante o processo de avaliação a coleta das informações apresentou várias dificuldades. A
primeira delas foi a necessidade da leitura do documento para realizar a avaliação. O TraceBok possui mais de 40 páginas. O tamanho do documento e a necessidade de lê-lo antes de
realizar a avaliação fez com que muitos especialistas atrasassem ou desistissem da atividade. A
decisão de escrever o TraceBok em inglês, para aumentar sua abrangência, também se tornou
uma barreira. Alguns especialistas declinaram do convite por não se sentirem capazes de responder com qualidade sobre a aplicabilidade do TraceBok porque o documento é apresentado
na língua inglesa. Foram enviados 18 convites para especialistas, divididos em dois perfis. O
primeiro perfil é de especialistas que possuem experiência com rastreabilidade participando de
projetos de construção de produtos de software. O segundo perfil é definido por profissionais
que possuem contato com a rastreabilidade através da implementação ou avaliação de modelos
de qualidade. O questionário elaborado foi disponibilizado no Google Docs2 com o objetivo
de facilitar o acesso dos avaliadores. Foram coletadas 7 avaliações de especialistas. O planejado contava com 8 avaliações. Foi definido encerrar a avaliação em função da restrição do
cronograma da dissertação.
2
http://docs.google.com
128
b) Organizar e analisar as informações
As informações coletadas no questionário de avaliação foram registradas em uma planilha conforme padrão de comportamento do Google Docs. Os respondentes não foram identificados na
planilha. Após a finalização da coleta os resultados foram organizados para que a análise dos
resultados fosse possível. A organização a análise das informações são apresentadas na próxima
Seção 5.4.
5.3
AMEAÇAS À VALIDADE
Os estudos experimentais apresentam ameaças que podem comprometer os resultados. A se-
guir, são apresentadas as ameaças relacionadas a avaliação do TraceBok.
5.3.1
Validade Interna
A definição das questões que combinadas definem o que é a aplicabilidade do TraceBok foi
um desafio nesta avaliação. Uma ameaça identificada foi a apresentações de questões que não são
capazes de identificar a aplicação do corpo de conhecimento. Para mitigar este risco, as questões
foram elaboradas para avaliar tópicos genéricos de percepção de aplicabilidade mas também questões
mais específicas sobre as abordagens.
5.3.2
Validade Externa
A dificuldade de classificação de experiência de um especialista em rastreabilidade foi identi-
ficada como ameaça a avaliação. Como a rastreabilidade é uma área transversal no desenvolvimento
de software, não é possível afirmar que um especialista em engenharia de software é automaticamente um conhecedor de rastreabilidade ao ponto de avaliar o TraceBok com a qualidade esperada.
Para amenizar esta ameaça, foram identificados critérios para classificar os especialistas. Além disso,
foi definido que o perfil dos avaliadores deveriam incluir profissionais com prática nas empresas,
que possuem uma visão mais específica do uso da rastreabilidade e profissionais que trabalham com
modelos de qualidade que possuem uma visão mais ampla da rastreabilidade por trabalhar com o
processos de software de forma mais ampla. Além disso, os implementadores e avaliadores de modelos de qualidade (MPS.BR e CMMI) possuem experiências diversas do uso da rastreabilidade nas
empresas.
129
5.4
RESULTADOS
Esta seção apresenta os resultados da avaliação da aplicabilidade do TraceBok. Inicialmente
é apresentada a contextualização dos resultados com o perfil dos avaliadores. Em seguida são apresentados os resultados de G1, onde a hipótese nula é verificada. Finalmente a análise dos resultados é
discutida.
5.4.1
Contextualização
A seleção dos especialistas apresentou algumas dificuldades em função das características
do TraceBok, como citado anteriormente nessa seção. O conjunto de especialistas responsável pela
avaliação do TraceBok foi selecionado observando a formação e experiência dos profissionais. As
Figuras 41 e 42 apresentam as características dos avaliadores.
Figura 41 – Formação dos avaliadores do TraceBok
Fonte: O Autor
Quatro dos especialistas possuem especialização na área de computação e afins. Outros três
possuem mestrado em Ciência da Computação ou áreas afins. É considerada área afim quando relacionada a computação de forma indireta.
Com relação a experiência, os avaliadores do TraceBok são quatro a coordenar uma ou mais
uma equipes de desenvolvimento de software que usa rastreabilidade nos últimos três anos. Três
deles são implementadores MPS.BR e já participaram de pelo menos cinco implementações. Um dos
especialistas é implementador CMMI e já participou de pelo menos cinco implementações
130
Figura 42 – Experiência dos avaliadores do TraceBok
Fonte: O Autor
Não foi definido nenhum nível de maturidade para os implementadores, pois a rastreabilidade
está presente nos níveis mais básicos dos modelos (G no MPS.BR e 2 no CMMI).
5.4.2
Resultado de G1
O objetivo especificado para G1 é analisar o corpo de conhecimento com o propósito de
definir com respeito a aplicabilidade do ponto de vista de especialistas em implantação de processos
de software com experiência em rastreabilidade no contexto da adoção de práticas de rastreabilidade
em organizações de software como produto. Para atender este objetivo foi aplicado o questionário e
os resultados das respostas foram calculados conforme descrito anteriormente nesta seção.
A tabulação dos resultados das respostas é apresentada no Quadro 39. O passo seguinte a tabulação foi analisar por questão, quantas respostas correspondiam a cada critério usado nas respostas.
É possível observar o resultado no Quadro 40.
Quadro 39 – Resultado da avaliação TraceBok
Resposta
Q1.1
Q1.2
Q1.3
1
4
2
4
2
5
4
4
3
4
4
2
4
4
4
4
5
4
2
4
6
4
2
4
7
2
2
4
Q1.4
5
5
3
3
5
4
5
Q1.5
4
5
4
5
4
4
4
Q1.6
5
5
4
4
5
5
4
Q1.7
5
5
3
3
3
5
5
Q1.8
4
5
4
4
4
4
4
O passo seguinte para apurar os resultados foi elaborar para cada questão o cálculo que permite
encontrar o percentual que corresponde a cada critério de resposta.
131
Quadro 40 – Resultado das questões aplicadas na avaliação do TraceBok
Critério
Q1.1
Q1.2
Q1.3
Q1.4
Q1.5
Q1.6
CT
1
0
0
4
2
4
CP
5
3
6
1
5
3
N
0
0
0
2
0
0
DP
1
4
1
0
0
0
DT
0
0
0
0
0
0
Q1.7
4
0
3
0
0
Q1.8
1
6
0
0
0
Neste trabalho, um quadro (41) com os resultados da questão Q1.1 foi elaborado e é apresentado com o objetivo de mostrar o cálculo. Para as outras questões, somente o gráfico é apresentado.
Quadro 41 – Resultado apurado para a questão Q1.1
Critério
Qtde
CT
1
CP
5
N
0
DP
1
DT
0
%
14%
72%
0%
14%
0%
A Q1.1 possui a seguinte afirmação: “A forma de apresentação do corpo de conhecimento
(organização dos capítulos e seções) é compreensível”. O gráfico apresentado na Figura 43 mostra que
72% dos respondentes concordam parcialmente com a afirmação. 14% concorda totalmente e outros
14% discordam parcialmente de que a apresentação do corpo de conhecimento é compreensível.
Figura 43 – Resultado de Q1.1
Fonte: O Autor
Em Q1.2, a afirmação “É fácil encontrar as informações desejadas na estrutura proposta pelo
corpo de conhecimento” foi analisada e a Figura 44 apresenta os resultados.
Sobre essa afirmação é possível identificar que 43% concorda parcialmente e 57% discorda
parcialmente.
132
Figura 44 – Resultado de Q1.2
Fonte: O Autor
A afirmação Q1.3 é definida como: “O corpo de conhecimento contém abordagens de rastreabilidade conhecidas por você”. Para esta afirmação o gráfico (45) aponta que 86% concordam
parcialmente e que 14% discordam parcialmente.
Figura 45 – Resultado de Q1.3
Fonte: O Autor
“Você conhece alguma abordagem de rastreabilidade que não aparece no corpo de conhecimento”. Essa afirmação corresponde a questão Q1.4 e possui 14% que concorda parcialmente e 57%
que concorda totalmente. 29% permaneceu neutro em relação a esta afirmação. Os resultados são
apresentados no gráfico da Figura 46.
A afirmação “O corpo de conhecimento apresenta pelo menos uma abordagem que pode ser
aplicada nas organizações que você tem ou teve contato”, corresponde a questão Q1.5. Segundo a
Figura 47 é possível verificar que 71% concordam parcialmente e que 29% concordam totalmente.
A Figura 48 mostra que 43% concordam parcialmente e que 57% concordam totalmente com
a afirmação: “O corpo de conhecimento pode ser usado para auxiliar os envolvidos no conhecimento
133
Figura 46 – Resultado de Q1.4
Fonte: O Autor
Figura 47 – Resultado de Q1.5
Fonte: O Autor
dos conceitos relacionados à rastreabilidade.
Figura 48 – Resultado de Q1.6
Fonte: O Autor
Na questão Q1.7 possui a afirmação “As abordagens apresentadas no corpo de conhecimento
estão alinhadas aos modelos de qualidade que você conhece”. A Figura 49 mostra que 57% concorda
134
totalmente com a afirmação, outros 43% permaneceram neutros, afirmando não ter opinião sobre a
afirmação.
Figura 49 – Resultado de Q1.7
Fonte: O Autor
Com relação a última afirmação: “Você usaria o corpo de conhecimento como apoio em atividades de implantação ou avaliação de práticas de rastreabilidade nas organizações”, é possível identificar na Figura 50 que 86% concordam parcialmente e que 14% concordam totalmente.
Figura 50 – Resultado de Q1.8
Fonte: O Autor
Após juntar os resultados dos critérios para todas as questões, foi possível identificar na Figura 51 que 28% concorda totalmente com a aplicabilidade do TraceBok. Aqueles que concordam
parcialmente representam 52% e que 11% discorda parcialmente, enquanto 9% se manteve neutro na
avaliação da aplicabilidade do TraceBok.
135
Figura 51 – Resultado Geral de G1
Fonte: O Autor
5.4.3
Análise dos resultados
A análise dos resultados inicia pela visão geral da aplicabilidade do TraceBok após a avalia-
ção.
A partir da apuração dos resultados do questionário foi possível identificar que 28% das respostas estão concentradas no critério CT (Concordo Totalmente). Isso significa dizer que este foi o
percentual de concordância total com os pontos avaliados no questionário. Quanto as respostas que
foram classificadas no critério de CP (Concordo Parcialmente) este percentual sobe para 52%. A soma
do percentual destes dois critérios chega a 80%, indicando que a maioria das respostas considera totalmente aplicável ou aplicável com alguma restrição. Estes dois critérios são anteriores à zona de
neutralidade, considerando que a aplicação do Tracebok é possível, mas que são necessários ajustes.
O percentual de critérios apontados como N (Não tenho opinião) somam 9%. Este percentual
pode ser considerado como as respostas que não encontraram opinião específica e a interpretação é de
que o especialista não se sentiu em condições de avaliar. Este é um aspecto negativo pois é a expressão
do avaliador de que o Tracebok, em alguns momentos, não estava em acordo com o conhecimento do
especialista ou que fugia do seu entendimento.
Em outro sentido, analisando os critérios abaixo da linha de neutralidade, encontram-se as
136
respostas DP (Discordo Parcialmente) que somam 11%. Estas respostas apontam para características
do TraceBok que mesmo não sendo rejeitadas pelos avaliadores, precisam de uma reformulação ou
uma reestruturação da informação disponibilizada. Quando a discordância total, não houve resposta
para o critério DT (Discordo Totalmente). Isso é um ponto positivo, pois indica que em nenhum
momento e em nenhum aspecto, no entendimento dos avaliadores, o TraceBok não é aplicável nas
organizações. Somados os percentuais neutros e abaixo da linha de neutralidade, encontra-se 20% de
apontamento aos critérios.
A hipótese nula definida nesta avaliação é descrita como: “O corpo de conhecimento elaborado neste estudo não é aplicável nas organizações que desenvolvem software como produto”. Se
considerado o resultado geral da avaliação, é possível dizer que a hipótese pode ser refutada com
algumas ressalvas. Estes pontos foram percebidos em relação a compatibilidade do TraceBok com os
modelos de qualidade, onde os especialistas somaram 43% de respostas neutras. Ainda com critérios
apontados como neutros, aparece a questão Q1.4 que questiona sobre o conhecimento de abordagens
pelo especialista que não consta no TraceBok. Com relação a critérios apontados como discordância
parcial, aparecem as afirmações relacionadas a foram de apresentação (Q1.1) do TraceBok com 14%,
a facilidade de encontrar as informações no TraceBok (Q1.2) com 57% e abordagens de rastreabilidades apresentadas no TraceBok, conhecidas pelo especialista com 14%. O maior índice concentra-se na
questão relacionada a facilidade de encontrar as informações no TraceBok. É possível evidenciar que
existem melhorias a serem feitas em relação a estrutura para facilitar a identificação das informações
no TraceBok.
6 CONCLUSÃO
Este trabalho apresentou a primeira versão de um corpo de conhecimento para rastreabilidade
no desenvolvimento de produtos de software. A proposta deste corpo de conhecimento partiu da
identificação na literatura da importância da rastreabilidade e do seu baixo uso nas organizações em
função das dificuldades em aplicá-la.
Para a elaboração do corpo de conhecimento as abordagens de rastreabilidade de software
existentes foram classificadas. A classificação foi possível a partir da execução de uma revisão sistemática que selecionou na literatura abordagens de rastreabilidade que continham elementos suficientes para serem aplicadas nas organizações. A seleção das abordagens não foram suficientes para
a definição do corpo de conhecimento, pois se tratando de uma proposta de aplicação nas organizações, foi necessário realizar uma avaliação na visão de profissionais que pertencem a organizações
interessadas em aplicar rastreabilidade. A realização de um survey apontou quais das abordagens
selecionadas eram realmente relevantes no contexto das organizações. O resultado da avaliação das
abordagens e um levantamento de documentos similares, permitiu definir a estrutura do corpo de
conhecimento de rastreabilidade. Em seguida houve um trabalho de construção do corpo de conhecimento, chamado de TraceBok. O TraceBok foi escrito em inglês para proporcionar um acesso maior
a comunidade com potencial para contribuir com sua evolução. Finalmente, a avaliação do corpo de
conhecimento foi realizada com o intuito de identificar a sua aplicabilidade em ambientes organizacionais. Esta avaliação, realizada em forma de um survey com especialistas em rastreabilidade, permitiu
identificar pontos positivos do TraceBok e também pontos que podem ser melhorados na evolução do
documento.
Duas hipóteses foram levantadas durante a elaboração do trabalho.
A primeira assume que a bibliografia atual fornece elementos suficientes para a elaboração de
um corpo de conhecimento de rastreabilidade, com definições e classificações de conceitos considerando diferentes ambientes e tecnologias de desenvolvimento de software. Os resultados do trabalho
apontam que a bibliografia (dentro dos parâmetros do período da pesquisa) fornece os elementos mínimos necessários para a elaboração do corpo de conhecimento. Foi possível a partir dos trabalhos
selecionados na revisão sistemática, identificar e classificar as abordagens identificando os diferen-
138
tes ambientes e tecnologias de desenvolvimento de software. O corpo de conhecimento gerado foi
baseado nestes elementos identificados a partir da bibliografia analisada.
A segunda hipótese afirmou que a elaboração de um corpo de conhecimento, relacionado à
rastreabilidade de software para organizações que produzem e mantêm produtos de software, é aplicável nas organização que aplicam ou desejam aplicar a rastreabilidade de requisitos nas organizações.
Esta hipótese foi confirmada com restrições pela avaliação do corpo de conhecimento por um conjunto de especialistas. Os resultados da avaliação apontam que apesar do TraceBok ser aplicável nas
organizações, pontos precisam ser melhorados em sua estrutura para que realmente contribua na redução das dificuldades da aplicação da rastreabilidade. Deve aqui ser considerada a característica de
um corpo de conhecimento, constituído por um documento que evolui com a contribuição da comunidade envolvida. A evolução do corpo de conhecimento depende da sua apresentação inicial, mas
depende mais da contribuição feita a partir de visões diversas sobre o assunto e do apontamento das
necessidades dos profissionais e do mercado de produção de software.
A pergunta de pesquisa sobre o conjunto de orientações e a forma de implementação da rastreabilidade ser capaz de apoiar a implantação da rastreabilidade nas organizações, pode ser respondida
como afirmativa com restrições, pois a avaliação do TraceBok aponta 80% de escolha de critérios
que identificam uma concordância total ou parcial com a aplicabilidade do TraceBok. Embora 28%
dos critérios de avaliação estarem relacionados a concordância total, o que caracteriza a percepção de
que o corpo de conhecimento é totalmente aplicável, 52% dos critérios escolhidos aponta para uma
concordância parcial. Isso quer dizer que existem pontos a serem melhorados no TraceBok. Não é
possível, no entanto, identificar precisamente quais seriam estes pontos. Apenas há a indicação, pela
análise individualizada das respostas do survey, que alguns aspectos do documento foram percebidos como insatisfatórios pelos avaliadores. O alinhamento com os modelos de qualidade não estão
suficientemente claros e a organização das informações pode ser melhorada. Além disso, a correspondência entre as abordagens apresentadas no TraceBok e aquelas conhecidas pelos especialistas
também apresentou um ponto de melhoria.
6.1
CONTRIBUIÇÕES DA DISSERTAÇÃO
A produção do TraceBok é a principal contribuição da dissertação. A publicação da primeira
versão aconteceu a partir de um estudo bibliográfico, da avaliação nas organizações e do estudo de
139
uma estrutura para constituição do documento. Além da proposta do TraceBok, houve a avaliação da
aplicabilidade por um corpo de especialistas.
Para a elaboração deste trabalho foram realizadas etapas que podem ser consideradas como
contribuições complementares.
A revisão sistemática, seguida do survey produziu um conjunto de abordagens de rastreabilidade classificadas e que permitiu a seleção daquelas que fizeram parte do TraceBok. Além disso,
as abordagens foram descritas em um formato padrão que facilita a comparação entre os diferentes
aspectos que compõem as abordagens. Este conjunto de abordagens classificadas pode ser utilizada
para outros fins no estudo da rastreabilidade de software.
Este trabalho apresenta também a aplicação com sucesso do PRO2PI-MFMOD como método
para construir um corpo de conhecimento. As fases propostas pelo método foram utilizadas na íntegra
e atenderam as necessidades da construção do TraceBok.
6.2
TRABALHOS FUTUROS
Durante a pesquisa realizada para propor o TraceBok e durante a sua construção, foram per-
cebidas alternativas que podem ser estudadas para contribuir com a evolução do documento. Alguns
destes pontos são relacionados com a revisão da literatura que identificou o conjunto básico de abordagens para gerar o TraceBok.
• Realização de pesquisa sobre as abordagens de rastreabilidade utilizadas pelas organizações,
pois na avaliação realizada neste trabalho, observou-se que existe uma diferença entre as abordagens propostas na literatura e aquelas efetivamente utilizadas pelas organizações que produzem software.
• Estudos para propor uma formatação das abordagens, relacionadas com as etapas do ciclo de
vida da rastreabilidade também é uma sugestão de trabalho futuro. Para tanto, é necessário
realizar uma investigação mais profunda das técnicas e métodos usados nas diferentes fases do
ciclo de vida da rastreabilidade para possibilitar a construção de abordagens mais adaptadas
às necessidades das organizações. Isso permitirá que as organizações procurem por soluções
específicas que podem ser incorporadas a um ambiente já estruturado de rastreabilidade com o
objetivo de evoluí-lo.
140
Com relação a estrutura proposta do TraceBok, também foram identificadas oportunidades de
evoluções futuras. Entre elas:
• Evoluir a estrutura do documento para incluir diferentes modelos de ciclo de vida da rastreabili-
dade, adaptados aos padrões de desenvolvimento e necessidades específicas, como por exemplo,
rastreabilidade no desenvolvimento de software de missão crítica.
• Extrair da literatura as técnicas utilizadas para as diferentes fases do ciclo de vida da rastreabilidade e incluí-las no TraceBok. Por exemplo, técnicas para registro dos traços (links), técnicas
para recuperação de informação de rastreabilidade, entre outras.
• Incluir novas bases de pesquisa na revisão sistemática (como por exemplo: Compendex e Sco-
pus) com o intuito de identificar novas abordagens que podem fazer parte do corpo de conhecimento.
141
REFERÊNCIAS
ABNT. Engenharia de Software e Sistemas - Processos de Ciclo de Vida de Software. Rio de Janeiro
- Brasil, 2009.
AHMAD, A.; GHAZALI, M. Documenting requirements traceability information for small projects.
In: Multitopic Conference, 2007. INMIC 2007. IEEE International. [S.l.: s.n.], 2007. p. 1–5.
AIZENBUD-RESHEF, N. et al. Model traceability. IBM Systems Journal, v. 45, n. 3, p. 515–526,
2006. ISSN 0018-8670.
AJILA, S.; KABA, A. Using traceability mechanisms to support software product line evolution.
In: Information Reuse and Integration, 2004. IRI 2004. Proceedings of the 2004 IEEE International
Conference on. [S.l.: s.n.], 2004. p. 157–162.
ANQUETIL, N. et al. A model-driven traceability framework for software product lines. Software
and Systems Modeling, Springer-Verlag, v. 9, n. 4, p. 427–451, 2010. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-009-0120-9>.
AOYAMA, M. et al. A model and architecture of rebok (requirements engineering body of
knowledge) and its evaluation. In: Software Engineering Conference (APSEC), 2010 17th Asia
Pacific. [S.l.: s.n.], 2010. p. 50–59. ISSN 1530-1362.
APSHVALKA, D.; WENDORFF, P. Reflections on the body of knowledge in software engineering.
In: NILSSON, A. et al. (Ed.). Advances in Information Systems Development. Springer US,
2006. p. 995–1006. ISBN 978-0-387-30834-0. Disponível em: <http://dx.doi.org/10.1007/
978-0-387-36402-5_85>.
ASUNCION, H.; TAYLOR, R. Establishing the connection between software traceability and data
provenance. ISR Technical Report, Institute for Software Research, Irvine – Califórnia – USA, n.
UCI-ISR-07-9, 2007.
ASUNCION, H. U.; FRAN COIS, F.; TAYLOR, R. N. An end-to-end industrial software traceability
tool. In: Proceedings of the the 6th joint meeting of the European software engineering conference
and the ACM SIGSOFT symposium on The foundations of software engineering. New York, NY,
USA: ACM, 2007. (ESEC-FSE ’07), p. 115–124. ISBN 978-1-59593-811-4. Disponível em:
<http://doi.acm.org/10.1145/1287624.1287642>.
AZMI, A.; IBRAHIM, S. Formulating a software traceability model for integrated test
documentation: a case study. International Association of Computer Science and Information
Technology Press (IACSIT), International Journal of Information ands Electronics Engineering,
Universiti Teknologi Malaysia – Malaysia, p. 21–32, 2011.
BASILI, V. R. Software Modeling and Measurement: The Goal/Question/Metric Paradigm. College
Park, MD, USA, 1992.
BASILI V.R. ROMBACK, H. The tame project: towards improvement-oriented software
environments. In: IEEE Trans. Software Engineering. [S.l.: s.n.], 1998. p. 758–773.
142
BOWEN, J. P.; REEVES, S. From a community of practice to a body of knowledge: A case study of
the formal methods community. In: BUTLER, M.; SCHULTE, W. (Ed.). FM 2011: Formal Methods.
Springer Berlin Heidelberg, 2011, (Lecture Notes in Computer Science, v. 6664). p. 308–322. ISBN
978-3-642-21436-3. Disponível em: <http://dx.doi.org/10.1007/978-3-642-21437-0_24>.
BRAUDE, E.; BERNSTEIN, M. Software Engineering: Modern Approaches. [S.l.]: Wiley, 2010.
ISBN 9780471692089.
BRAVO, M. P. C.; EISMAN, L. B. Investigación Educativa. 3a. ed.. ed. [S.l.]: Ediciones Alfar, 1998.
BRERETON, P. et al. Lessons from applying the systematic literature review process within the
software engineering domain. Journal of Systems and Software, Institute for Software Research,
v. 80, n. 4, p. 571 – 583, 2007.
BUCHGEHER, G.; WEINREICH, R. Automatic tracing of decisions to architecture and
implementation. In: Software Architecture (WICSA), 2011 9th Working IEEE/IFIP Conference on.
[S.l.: s.n.], 2011. p. 46–55.
CLELAND-HUANG, J.; GOTEL, O.; ZISMAN, A. Software and Systems Traceability. Springer
London, 2012. ISBN 9781447122388. Disponível em: <http://link.springer.com/book/10.1007%
2F978-1-4471-2239-5>.
CLELAND-HUANG, J.; HAYES, J. H.; DOMEL, J. M. Model-based traceability. In: Proceedings of
the 2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering. Washington,
DC, USA: IEEE Computer Society, 2009. (TEFSE ’09), p. 6–10. ISBN 978-1-4244-3741-2.
Disponível em: <http://dx.doi.org/10.1109/TEFSE.2009.5069575>.
CLELAND-HUANG, J. et al. Breaking the big-bang practice of traceability: Pushing timely trace
recommendations to project stakeholders. In: Requirements Engineering Conference (RE), 2012 20th
IEEE International. [S.l.: s.n.], 2012. p. 231–240. ISSN 1090-750X.
CLELAND-HUANG, J.; MARRERO, W.; BERENBACH, B. Goal-centric traceability: Using
virtual plumblines to maintain critical systemic qualities. IEEE Trans. Softw. Eng., IEEE Press,
Piscataway, NJ, USA, v. 34, n. 5, p. 685–699, set. 2008. ISSN 0098-5589. Disponível em:
<http://dx.doi.org/10.1109/TSE.2008.45>.
COEST. CoEST - Center of Excellence for Software Traceability. 2014. Disponível em:
<http://coest.org/>.
DAVIS, R.; SHROBE, H.; SZOLOVITS, P. What Is a Knowledge What is a Knowledge
Representation? 1993. 17-33 p.
DELATER, A.; PAECH, B. Analyzing the tracing of requirements and source code during software
development. In: Proceedings of the 19th international conference on Requirements Engineering:
Foundation for Software Quality. Berlin, Heidelberg: Springer-Verlag, 2013. (REFSQ’13), p. 308–
314. ISBN 978-3-642-37421-0. Disponível em: <http://dx.doi.org/10.1007/978-3-642-37422-7_22>.
DUBOIS, H.; PERALDI-FRATI, M.-A.; LAKHAL, F. A model for requirements traceability in
a heterogeneous model-based design process: Application to automotive embedded systems. In:
Proceedings of the 2010 15th IEEE International Conference on Engineering of Complex Computer
Systems. Washington, DC, USA: IEEE Computer Society, 2010. (ICECCS ’10), p. 233–242. ISBN
978-0-7695-4015-3. Disponível em: <http://dx.doi.org/10.1109/ICECCS.2010.2>.
143
EGYED, A.; BINDER, G.; GRUNBACHER, P. Strada: A tool for scenario-based feature-to-code
trace detection and analysis. In: Companion to the proceedings of the 29th International
Conference on Software Engineering. Washington, DC, USA: IEEE Computer Society,
2007. (ICSE COMPANION ’07), p. 41–42. ISBN 0-7695-2892-9. Disponível em: <http:
//dx.doi.org/10.1109/ICSECOMPANION.2007.70>.
FERREIRA, P. J. A. V.; BARROS, M. d. O. Traceability between function point and source code.
In: Proceedings of the 6th International Workshop on Traceability in Emerging Forms of Software
Engineering. New York, NY, USA: ACM, 2011. (TEFSE ’11), p. 10–16. ISBN 978-1-4503-0589-1.
Disponível em: <http://doi.acm.org/10.1145/1987856.1987860>.
GOKNIL, A.; KURTEV, I.; BERG, K. van den. Tool support for generation and validation of traces
between requirements and architecture. In: Proceedings of the 6th ECMFA Traceability Workshop.
New York, NY, USA: ACM, 2010. (ECMFA-TW ’10), p. 39–46. ISBN 978-1-60558-993-0.
Disponível em: <http://doi.acm.org/10.1145/1814392.1814398>.
GOTEL, O. et al. The Grand Challenge of Traceability. http://www.coest.org, 2011.
GOTEL, O.; FINKELSTEIN, A. An analysis of the requirements traceability problem. In:
Requirements Engineering – 1994 – Proceedings of the First International Conference on. [S.l.: s.n.],
1994. p. 94–101.
HENRY, D. et al. Experiences from creating the guide to the systems engineering body
of knowledge (sebok) v. 1.0. Procedia Computer Science, v. 16, n. 0, p. 990 – 999, 2013.
ISSN 1877-0509. 2013 Conference on Systems Engineering Research. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S1877050913001051>.
HONG, Y.; KIM, M.; LEE, S.-W. Requirements management tool with evolving traceability for
heterogeneous artifacts in the entire life cycle. In: Proceedings of the 2010 Eighth ACIS International
Conference on Software Engineering Research, Management and Applications. Washington, DC,
USA: IEEE Computer Society, 2010. (SERA ’10), p. 248–255. ISBN 978-0-7695-4075-7. Disponível
em: <http://dx.doi.org/10.1109/SERA.2010.39>.
HUMPHREY, W. S. et al. Team Software Process (TSP) Body of Knowledge (BOK).
http://repository.cmu.edu/sei/12, 2010.
IEEE. Guide to the software engineering body of knowledge (swebok). In: The Institute of Electrical
and Electronics Engineers. [S.l.]: IEEE Computer Society – Los Alamitos – California – EUA, 2014.
IEEE-610.12. IEEE Standard Glossary of Software Engineering Terminology. [S.l.]: The Institute of
Electrical and Eletronics Engineers, 1990. (IEEE Std). ISBN 9781559370677.
IIBA, I. I. of B. A. A Guide to the Business Analysis Body of Knowledge. Version 2.0. [S.l.]:
International Institute of Business Analysis, Toronto, Ontario, Canada., 2009.
IIBA, I. I. of B. A. IIBA. 2014. Disponível em: <http://www.iiba.org/>.
IREB. CPRE - Certified Professional for Requirements Engineering. 2014. Disponível em:
<http://www.ireb.org>.
144
JIRAPANTHONG, W.; ZISMAN, A. Xtraque: traceability for product line systems. Software &
Systems Modeling, Springer-Verlag, v. 8, n. 1, p. 117–144, 2009. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-007-0066-8>.
JURISTO, N.; MORENO, A. M. Basics of Software Engineering Experimentatio. 1st. ed. [S.l.]:
Springer Publishing Company, Incorporated, 2010.
KANNENBERG, A.; SAIEDIAN, H. Why software requirements traceability remains a
challenge. CrossTalk The Journal of Defense Software Engineering, Justin T. Hill, 2009. ISSN
2160-1577. Disponível em: <http://www.crosstalkonline.org/storage/issue-archives/2009/200907/
200907-Kannenberg.pdf>.
KASSAB, M.; ORMANDJIEVA, O.; DANEVA, M. A metamodel for tracing non-functional
requirements. In: Proceedings of the 2009 WRI World Congress on Computer Science and Information
Engineering - Volume 07. Washington, DC, USA: IEEE Computer Society, 2009. (CSIE ’09), p.
687–694. ISBN 978-0-7695-3507-4. Disponível em: <http://dx.doi.org/10.1109/CSIE.2009.946>.
KELLEHER, J.; SIMONSSON, M. Utilizing use case classes for requirement and traceability
modeling. In: Proceedings of the 17th IASTED International Conference on Modelling and
Simulation. Anaheim, CA, USA: ACTA Press, 2006. (MS’06), p. 617–625. ISBN 0-88986-592-2.
Disponível em: <http://dl.acm.org/citation.cfm?id=1167113.1167222>.
KITCHENHAM, B. et al. Evaluating guidelines for reporting empirical software engineering studies.
Empirical Software Engineering, Springer US, v. 13, n. 1, p. 97–121, 2008. ISSN 1382-3256.
Disponível em: <http://dx.doi.org/10.1007/s10664-007-9053-5>.
KITCHENHAM, B. A.; CHARTERS, S. Guidelines for performing Systematic Literature Reviews in
Software Engineering. [S.l.], 2007.
KNETHEN, A. von; PAECH, B. A Survey on Tracing Approaches in Theory and Practice. [S.l.],
2002.
KOTONYA, G.; SOMMERVILLE, I. Requirements engineering: processes and techniques. [S.l.]: J.
Wiley, 1998. (Worldwide series in computer science). ISBN 9780471972082.
LAGO, P.; MUCCINI, H.; VLIET, H. van. A scoped approach to traceability management. Journal
of Systems and Software, v. 82, n. 1, p. 168 – 182, 2009. ISSN 0164-1212. <ce:title>Special
Issue: Software Performance - Modeling and Analysis</ce:title>. Disponível em: <http:
//www.sciencedirect.com/science/article/pii/S0164121208002033>.
LEE, J.-S. et al. Means-ends and whole-part traceability analysis of safety requirements. Journal
of Systems and Software, v. 83, n. 9, p. 1612–1621, 2010. ISSN 0164-1212. <ce:title>Software
Dependability</ce:title>. Disponível em: <http://www.sciencedirect.com/science/article/pii/
S0164121209002143>.
LEVENDOVSZKY, T. et al. A transformation instance-based approach to traceability. In:
Proceedings of the 6th ECMFA Traceability Workshop. New York, NY, USA: ACM, 2010.
(ECMFA-TW ’10), p. 55–60. ISBN 978-1-60558-993-0. Disponível em: <http://doi.acm.org/10.
1145/1814392.1814400>.
145
LIKERT, R. A. A technique for the measurement of attitudes. In: Archivés of Psychology. [S.l.: s.n.],
1932. v. 140, p. 1–55.
LINDVALL, M.; SANDAHL, K. Practical implications of traceability. Software Practice and
Experience, v. 26, n. 10, p. 1161–1180, 1996.
MÄDER, P.; GOTEL, O. Towards automated traceability maintenance. Journal of Systems
and Software, v. 85, n. 10, p. 2205–2227, 2012. ISSN 0164-1212. <ce:title>Automated
Software Evolution</ce:title>. Disponível em: <http://www.sciencedirect.com/science/article/pii/
S0164121211002779>.
MADER, P.; GOTEL, O.; PHILIPPOW, I. Semi-automated traceability maintenance: An architectural
overview of tracemaintainer. In: Software Engineering - Companion Volume, 2009. ICSE-Companion
2009. 31st International Conference on. [S.l.: s.n.], 2009. p. 425–426.
MALAVOLTA, I.; MUCCINI, H.; REKHA, V. S. Supporting architectural design decisions evolution
through model driven engineering. In: Proceedings of the Third international conference on Software
engineering for resilient systems. Berlin, Heidelberg: Springer-Verlag, 2011. (SERENE’11), p. 63–77.
ISBN 978-3-642-24123-9. Disponível em: <http://dl.acm.org/citation.cfm?id=2045537.2045546>.
MCCLELLAND, J. A. G. Técnica de questionário para física. In: FÍSICA, S. B. de (Ed.). Revista
Brasileira de Física. [S.l.], 1976. Especial, n. 1, p. 93–101.
MERILINNA, J.; YRJÖNEN, A.; RÄTY, T. Nfr+ framework method to support bi-directional
traceability of non-functional requirements. Computer Science - Research and Development,
Springer-Verlag, p. 1–15, 2012. ISSN 1865-2034. Disponível em: <http://dx.doi.org/10.1007/
s00450-012-0205-5>.
MERRIAM-WEBSTER. Merriam-Webster’s Collegiate Dictionary. 10th ed.. ed. [S.l.]: MerriamWebster, Incorporated, 1996.
MITRE. Guide to the (Evolving) Enterprise Architecture Body of Knowledge - Draft. McLean,
Virginia: The MITRE Corporation, 2004.
MOON, M. et al. A metamodeling approach to tracing variability between requirements and
architecture in software product lines. In: Proceedings of the 7th IEEE International Conference
on Computer and Information Technology. Washington, DC, USA: IEEE Computer Society, 2007.
(CIT ’07), p. 927–933. ISBN 0-7695-2983-6. Disponível em: <http://dl.acm.org/citation.cfm?id=
1317531.1317997>.
NEJATI, S. et al. A sysml-based approach to traceability management and design slicing
in support of safety certification: Framework, tool support, and case studies. Information
and Software Technology, v. 54, n. 6, p. 569–590, 2012. ISSN 0950-5849. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S095058491200016X>.
NHMRC. How to review the evidence: systematic identification and review of the scientific literature.
Canberra – Australia, 2000.
NOLL, R. P.; RIBEIRO, M. B. Ontological traceability over the unified process. In: Proceedings
of the 14th Annual IEEE International Conference and Workshops on the Engineering of
Computer-Based Systems. Washington, DC, USA: IEEE Computer Society, 2007. (ECBS ’07), p.
249–255. ISBN 0-7695-2772-8. Disponível em: <http://dx.doi.org/10.1109/ECBS.2007.58>.
146
OREN, T. I. Toward the body of knowledge of modeling and simulation toward the body of
knowledge of modeling and simulation toward the body of knowledge of modeling and simulation.
In: (I/ITSEC) (Ed.). Interservice/Industry Training, Simulation, and Education Conference. [S.l.:
s.n.], 2005.
PETERSEN, K. et al. Systematic mapping studies in software engineering. In: Proceedings
of the 12th international conference on Evaluation and Assessment in Software Engineering.
Swinton, UK, UK: British Computer Society, 2008. (EASE’08), p. 68–77. Disponível em:
<http://dl.acm.org/citation.cfm?id=2227115.2227123>.
PFLEEGER, S. Engenharia de Software - Teoria e Prática. 2nd. ed. [S.l.]: Prentice Hall - São Paulo,
2004.
PINHEIRO, F. A. C. Design of a Hyper-Environment for Tracing Object-Oriented Requirements.
Tese (Doutorado) — University of Oxford, 1996.
. [S.l.]: The Netherlands :
PINHEIRO, F. A. C. Perspectives on software requirements. In:
Kluwer Academic Publishers, 2004. cap. Requirements Traceability, p. 91–113.
PMI, P. M. I. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK) - Quinta
edição. Quinta edição. [S.l.]: Project Management Institute, Inc., 2013.
POMEROY-HUFF, M. et al. The Personal Software Process (PSP) Body of Knowledge (BOK).
http://www.sei.cmu.edu, 2009.
PRESSMAN, R. Software Engineering: A Practitioner’s Approach. 7th. ed. [S.l.]: McGraw Hill,
2010.
PYSTER, A.; OLWEL, D. Guide to the Systems Engineering Body of Knowledge SEBoK —
Guide to the Systems Engineering Body of Knowledge SEBoK, version 1.2. 2013. Online; accessed
22-february2014. Disponível em: <http://sebokwiki.org>.
PYSTER, A.; OLWELL, D. The Guide to the Systems Engineering Body of Knowledge (SEBoK).
The Trustees of the Stevens Institute of Technology, 2013. Disponível em: <www.sebokwiki.org/>.
REGAN, G. et al. The barriers to traceability and their potential solutions: Towards a reference
framework. In: Software Engineering and Advanced Applications (SEAA), 2012 38th EUROMICRO
Conference on. [S.l.: s.n.], 2012. p. 319–322.
REGAN, G. et al. Traceability-why do it? In: SPICE. [S.l.: s.n.], 2012. p. 161–172.
REMPEL, P. et al. Requirements traceability across organizational boundaries: a survey and
taxonomy. In: Proceedings of the 19th international conference on Requirements Engineering:
Foundation for Software Quality. Berlin, Heidelberg: Springer-Verlag, 2013. (REFSQ’13), p. 125–
140. ISBN 978-3-642-37421-0. Disponível em: <http://dx.doi.org/10.1007/978-3-642-37422-7_10>.
ROCHIMAH, S. et al. An evaluation of traceability approaches to support software evolution. In:
Proceedings of the International Conference on Software Engineering Advances. Washington, DC,
USA: IEEE Computer Society, 2007. (ICSEA ’07), p. 19–. ISBN 0-7695-2937-2. Disponível em:
<http://dx.doi.org/10.1109/ICSEA.2007.17>.
147
SAIEDIAN, H.; KANNENBERG, A.; MOROZOV, S. A streamlined, cost-effective database
approach to manage requirements traceability. Software Quality Journal, Springer US, v. 21, n. 1, p.
23–38, 2013. ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-011-9166-3>.
SANCHEZ, P. et al. Introducing safety requirements traceability support in model-driven
development of robotic applications. Computers, IEEE Transactions on, v. 60, n. 8, p. 1059–1071,
2011. ISSN 0018-9340.
SATYANANDA, T. K. et al. Identifying traceability between feature model and software
architecture in software product line using formal concept analysis. In: Proceedings of the The
2007 International Conference Computational Science and its Applications. Washington, DC, USA:
IEEE Computer Society, 2007. (ICCSA ’07), p. 380–388. ISBN 0-7695-2945-3. Disponível em:
<http://dx.doi.org/10.1109/ICCSA.2007.47>.
SCHWARZ, H. Towards a comprehensive traceability approach in the context of software
maintenance. In: Proceedings of the 2009 European Conference on Software Maintenance and
Reengineering. Washington, DC, USA: IEEE Computer Society, 2009. (CSMR ’09), p. 339–342.
ISBN 978-0-7695-3589-0. Disponível em: <http://dx.doi.org/10.1109/CSMR.2009.8>.
SCHWARZ, H.; EBERT, J.; WINTER, A. Graph-based traceability: a comprehensive approach.
Software & Systems Modeling, Springer-Verlag, v. 9, n. 4, p. 473–492, 2010. ISSN 1619-1366.
Disponível em: <http://dx.doi.org/10.1007/s10270-009-0141-4>.
SEI. CMMI for Development, Version 1.3 (CMU/SEI-2010-TR-033, ESC-TR-2010-033). [S.l.], 2010.
SOFTEX. MPS.BR – Guia Geral. [S.l.], 2011.
SOMMERVILLE, I. Engenharia de Software. 8th. ed. [S.l.]: Pearson Education Inc., 2007.
SOUSA, K. et al. Supporting requirements in a traceability approach between business process and
user interfaces. In: Proceedings of the VIII Brazilian Symposium on Human Factors in Computing
Systems. Porto Alegre, Brazil, Brazil: [s.n.], 2008. (IHC 08), p. 272–275. ISBN 978-85-7669-203-4.
Disponível em: <http://dl.acm.org/citation.cfm?id=1497470.1497505>.
SPANOUDAKIS, G.; ZISMAN, A. Software traceability: A roadmap. In: Handbook of Software
Engineering and Knowledge Engineering. [S.l.]: World Scientific Publishing, 2004. p. 395–428.
TAGUCHI, K. et al. Building a body of knowledge on model checking for software development. In:
Computer Software and Applications Conference (COMPSAC), 2013 IEEE 37th Annual. [S.l.: s.n.],
2013. p. 784–789.
TORKAR, R. et al. Requirements traceability: A systematic review and industry case study.
International Journal of Software Engineering and Knowledge Engineering, World Scientific, v. 22,
n. 3, p. 385–433, 2012. ISSN 0218-1940. Disponível em: <http://www.worldscientific.com/doi/abs/
10.1142/S021819401250009X>.
TRACELAB. TraceLab. 2014. Disponível em: <http://coest.org/index.php/tracelab/about-tracelab>.
TRAVASSOS, G.; GUROV, D.; AMARAL, E. A. G. do. Introdução à Engenharia de Software
Experimental. [S.l.], 2002.
148
WAZLAWICK, R. Uma reflexão sobre a pesquisa em ciência da computação à luz da classificação
das ciências e do método científico. Revista de Sistemas de Informação da FSMA n. 6, FSMA Faculdade Salesiana Maria Auxiliadora, p. 3–10, 2010.
WINKLER, S.; PILGRIM, J. A survey of traceability in requirements engineering and model-driven
development. Software and Systems Modeling, Springer-Verlag, v. 9, n. 4, p. 529–565, 2010. ISSN
1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-009-0145-0>.
WOHLIN, C. et al. Experimentation in Software Engineering. [S.l.]: Springer Publishing Company,
Incorporated, 2012. ISBN 3642290434, 9783642290435.
YRJÖNEN, A.; MERILINNA, J. Tooling for the full traceability of non-functional requirements
within model-driven development. In: Proceedings of the 6th ECMFA Traceability Workshop. New
York, NY, USA: ACM, 2010. (ECMFA-TW ’10), p. 15–22. ISBN 978-1-60558-993-0. Disponível
em: <http://doi.acm.org/10.1145/1814392.1814395>.
YU, Y.; JURJENS, J.; MYLOPOULOS, J. Traceability for the maintenance of secure software. In:
Software Maintenance, 2008. ICSM 2008. IEEE International Conference on. [S.l.: s.n.], 2008. p.
297–306. ISSN 1063-6773.
ZIFTCI, C.; KRUEGER, I. Tracing requirements to tests with high precision and recall. In:
Proceedings of the 2011 26th IEEE/ACM International Conference on Automated Software
Engineering. Washington, DC, USA: IEEE Computer Society, 2011. (ASE ’11), p. 472–475. ISBN
978-1-4577-1638-6. Disponível em: <http://dx.doi.org/10.1109/ASE.2011.6100102>.
ZOUCAS, A. C. Um framework de métodos para o desenvolvimento de modelos de capacidade de
processo. Dissertação (Dissertação) — Universidade do Vale do Itajaí, 2010.
Apêndices
150
APÊNDICE A – TRABALHOS DA REVISÃO SISTEMÁTICA
Os quadros a seguir apresentam os estudos primários, cotendo todos os trabalhos recuperados,
separados por fonte de pesquisa. Quadro 42 - ACM, Quadro 43 - IEEE, Quadro 44 - Science Direct e
Quadro 45 - Springer.
A análise dos trabalhos aconteceu em dois momentos. A primeira análise incluiu a leitura do
título, resumo, palavras-chave e, quando necessário, da introdução e conclusão. Para determinar a
inclusão do trabalho, foram seguidos os seguintes critérios:
• O trabalho foi revisado por pares (árbitros) para publicação?
• Identifica pelo menos a proposta ou uso de uma abordagem de rastreabilidade de requisitos em
software no trabalho?
• O trabalho apresenta resultados do uso da abordagem proposta?
Para a classificação da 1a análise foi utilizada uma codificação que é apresentada no Quadro
2.
Todos os trabalhos selecionados na primeira análise (indicados com AS na coluna 1a análise)
foram lidos na íntegra. Essa leitura, faz parte da segunda análise, cujo resultado segue os critérios
descritos no Quadro 3. A coluna 2a apresenta os resultados.
Quadro 42 – Trabalhos - Fonte ACM
Referência
1a análise
LEVINSON, J. Software Testing with Visual Studio 2010. 1st. ed. [S.l.]: Addison-Wesley Professional,
2011. ISBN 0321734483, 9780321734488.
AI
BROSGOL, B. Sa2: Languages for safety-critical software: issues and assessment. Ada
Lett., ACM, New York, NY, USA, XXVII, nov. 2007. issn 1094-3641. Disponível
em:<http://doi.acm.org/10.1145/1315607.1315583>.
AI
LúCIO, L. et al. MoDeVVa 2011 workshop summary. In: Proceedings of the 2011th international
conference on Models in Software Engineering. Berlin, Heidelberg: Springer-Verlag, 2012. (MODELS’11), p. 183–186. ISBN 978-3-642-29644-4. Disponível em: <http://dx.doi.org/10.1007/978-3642-29645-1 19>.
AI
BROSGOL, B. SA2: languages for safety-critical software: issues and assessment. Ada Lett.,
ACM, New York, NY, USA, XXVII, n. 3, p. 2–2, nov. 2007. ISSN 1094-3641. Disponível em:
<http://doi.acm.org/10.1145/1315607.1315583>.
AI
2a análise
Continua na próxima página
151
Referência
1a análise
DAUGHERTY, P. R. The future of software architectures for large-scalebusiness solutions: modularity,
scalability, andseparation of concerns. In: Proceedings of the 8th ACM international conference on
Aspect-oriented software development. New York, NY, USA: ACM, 2009. (AOSD ’09), p. 1–2. ISBN
978-1-60558-442-3. Disponível em: <http://doi.acm.org/10.1145/1509239.1509241>.
AI
MÄDER, P. et al. TraceMaintainer - Automated Traceability Maintenance. In: Proceedings of the 2008
16th IEEE International Requirements Engineering Conference. Washington, DC, USA: IEEE Computer Society, 2008. (RE ’08), p. 329–330. ISBN 978-0-7695-3309-4.
Duplicado
LU, C.-W. et al. A Model-based Object-oriented Approach to Requirement Engineering (MORE). In:
Proceedings of the 31st Annual International Computer Software and Applications Conference - Volume 01. Washington, DC, USA: IEEE Computer Society, 2007. (COMPSAC ’07), p. 153–156. ISBN
0-7695-2870-8. Disponível em: <http://dx.doi.org/10.1109/COMPSAC.2007.30>.
Duplicado
MARTINIE, C. et al. A development process for usable large scale interactive critical systems: application to satellite ground segments. In: Proceedings of the 4th international conference on HumanCentered Software Engineering. Berlin, Heidelberg: Springer-Verlag, 2012. (HCSE’12), p. 72–93.
ISBN 978-3-642-34346-9. Disponível em: <http://dx.doi.org/10.1007/978-3-642-34347-6 5>.
AR
SERGENT, T. L. SCADE: a comprehensive framework for critical system and software engineering.
In: Proceedings of the 15th international conference on Integrating System and Software Modeling.
Berlin, Heidelberg: Springer-Verlag, 2011. (SDL’11), p. 2–3. ISBN 978-3-642-25263-1. Disponível
em: <http://dx.doi.org/10.1007/978-3-642-25264-8 2>.
AR
ALJER, A.; DEVIENNE, P. Formal Fault Tolerant Architecture. In: Proceedings of the 2010 Third
International Conference on Communication Theory, Reliability, and Quality of Service. Washington,
DC, USA: IEEE Computer Society, 2010. (CTRQ ’10), p. 73–78. ISBN 978-0-7695-4070-2. Disponível em: <http://dx.doi.org/10.1109/CTRQ.2010.20>.
Duplicado
RÖDER, H. A pattern approach to specifying usability features in use cases. In:Proceedings of the
2nd International Workshop on Pattern-Driven Engineering of Interactive Computing Systems. New
York, NY, USA: ACM, 2011. (PEICS ’11), p. 12–15. ISBN 978-1-4503-0856-4. Disponível em:
<http://doi.acm.org/10.1145/2018431- .2018435>.
AR
KIM, J. A.; CHOI, S.-Y.; HWANG, S.-M. Architecture of software engineering guideline execution.
In: Proceedings of the 5th international conference on Convergence and hybrid information technology. Berlin, Heidelberg: Springer-Verlag, 2011. (ICHIT’11), p. 437–444. ISBN 978-3-642-24081-2.
Disponível em: <http://dl.acm.org/citation- .cfm?id=2045005.2045064>.
AR
DUAN, C.; CLELAND-HUANG, J. Clustering support for automated tracing. In:Proceedings of
the twenty-second IEEE/ACM international conference on Automated software engineering. New
York, NY, USA: ACM, 2007. (ASE ’07), p. 244–253. ISBN 978-1-59593-882-4. Disponível em:
<http://doi.acm.org/10.1145/1321631.1321668>.
AR
CLELAND-HUANG, J.; HABRAT, R. Visual support in automated tracing. In:Proceedings of
the Second International Workshop on Requirements Engineering Visualization. Washington, DC,
USA: IEEE Computer Society, 2007. (REV ’07), p. 4–. ISBN 0-7695-3248-9. Disponível em:
<http://dx.doi.org/10.1109/REV.2007.7>.
Duplicado
CHARRADA, E. B. et al. Towards a benchmark for traceability. In: Proceedings of the 12th International Workshop on Principles of Software Evolution and the 7th annual ERCIM Workshop on Software
Evolution. New York, NY, USA: ACM, 2011. (IWPSE-EVOL ’11), p. 21–30. ISBN 978-1-4503-08489. Disponível em: <http://doi.acm.org/10.1145/2024445.2024451>.
AR
ZIMMERMANN, O. et al. Combining pattern languages and reusable architectural decision models into a comprehensive and comprehensible design method. In: Proceedings of the Seventh Working IEEE/IFIP Conference on Software Architecture (WICSA 2008). Washington, DC, USA: IEEE
Computer Society, 2008. (WICSA ’08), p. 157–166. ISBN 978-0-7695-3092-5. Disponível em:
<http://dx.doi.org/10.1109/WICSA.2008.19>.
Duplicado
GONZÁLEZ-HUERTA, J. et al. Non-functional requirements in model-driven software product line
engineering. In: Proceedings of the Fourth International Workshop on Nonfunctional System Properties
in Domain Specific Modeling Languages. New York, NY, USA: ACM, 2012. (NFPinDSML ’12), p.
6:1–6:6. ISBN 978-1-4503-1807-5. Disponiível em: <http://doi.acm.org/10.1145/2420942.2420948>.
AR
2a análise
Continua na próxima página
152
Referência
1a análise
HELMING, J. et al. Integrating system modeling with project management - a case study. In: Proceedings of the 2009 33rd Annual IEEE International Computer Software and Applications Conference
- Volume 01. Washington, DC, USA: IEEE Computer Society, 2009. (COMPSAC ’09), p. 571–578.
ISBN 978-0-7695-3726-9. Disponível em: <http://dx.doi.org/10.1109/COMPSAC.2009.198>.
Duplicado
HAUSE, M. C.; THOM, F. An integrated mda approach with sysml and uml. In: Proceedings of the
13th IEEE International Conference on on Engineering of Complex Computer Systems. Washington,
DC, USA: IEEE Computer Society, 2008. (ICECCS ’08), p. 249–254. ISBN 978-0-7695-3139-7. Disponível em: <http://dx.doi.org/10.1109- /ICECCS.2008.21>.
Duplicado
FRASER, G.; AMMANN, P. Reachability and propagation for ltl requirements testing. In: Proceedings of the 2008 The Eighth International Conference on Quality Software. Washington, DC, USA:
IEEE Computer Society, 2008. (QSIC ’08), p. 189–198. ISBN 978-0-7695-3312-4. Disponível em:
<http://dx.doi.org/10.1109/QSIC.2008.21>.
Duplicado
SAFANA, A. I.; IBRAHIM, S. Implementing software test management using spirateam tool. In: Proceedings of the 2010 Fifth International Conference on Software Engineering Advances. Washington,
DC, USA: IEEE Computer Society, 2010. (ICSEA ’10), p. 447–452. ISBN 978-0-7695-4144-0. Disponível em: <http://dx.doi.org/10.1109/ICSEA- .2010.76>.
Duplicado
FARHAT, S.; SIMCO, G.; MITROPOULOS, F. J. Refining and reasoning about nonfunctional
requirements. In: Proceedings of the 47th Annual Southeast Regional Conference. New York,
NY, USA: ACM, 2009. (ACM-SE 47), p. 38:1–38:5. ISBN 978-1-60558-421-8. Disponível em:
<http://doi.acm.org/10.1145/1566445.1566497>.
AR
ABBORS, F.; TRUSCAN, D. Approaching performance testing from a model-based testing perspective. In: Proceedings of the 2010 Second International Conference on Advances in System Testing and
Validation Lifecycle. Washington, DC, USA: IEEE Computer Society, 2010. (VALID ’10), p. 125–128.
ISBN 978-0-7695-4146-4. Disponível em: <http://dx.doi.org/10.1109/VALID.2010.22>.
Duplicado
KHERRAF, S.; LEFEBVRE, E.; SURYN, W. Transformation from cim to pim using patterns and archetypes. In: Proceedings of the 19th Australian Conference on Software Engineering. Washington,
DC, USA: IEEE Computer Society, 2008. (ASWEC ’08), p. 338–346. ISBN 978-0-7695-3100-7. Disponível em: <http://dl.acm.org/citation- .cfm?id=1395083.1395684>.
Duplicado
ARAúJO, J. et al. Advanced modularity for building spl feature models: a model-driven approach. In: Proceedings of the 28th Annual ACM Symposium on Applied Computing. New York,
NY, USA: ACM, 2013. (SAC ’13), p. 1246–1253. ISBN 978-1-4503-1656-9. Disponível em:
<http://doi.acm.org/10.1145/2480362.2480596>.
AR
DALPIAZ, F.; GIORGINI, P.; MYLOPOULOS, J. Software self-reconfiguration: a bdi-based approach. In: Proceedings of The 8th International Conference on Autonomous Agents and Multiagent Systems - Volume 2. Richland, SC: International Foundation for Autonomous Agents and Multiagent Systems, 2009. (AAMAS ’09), p. 1159–1160. ISBN 978-0-9817381-7-8. Disponível em:
<http://dl.acm.org/citation.cfm?id=1558109- .1558189>.
AR
DENNEY, E.; FISCHER, B. A verification-driven approach to traceability and documentation for autogenerated mathematical software. In: Proceedings of the 2009 IEEE/ACM International Conference on
Automated Software Engineering. Washington, DC, USA: IEEE Computer Society, 2009. (ASE ’09),
p. 560–564. ISBN 978-0-7695-3891-4. Disponível em: <http://dx.doi.org/10.1109/ASE.2009.71>.
Duplicado
RASHWAN, A. Semantic analysis of functional and non-functional requirements in software requirements specifications. In: Proceedings of the 25th Canadian conference on Advances in Artificial
Intelligence. Berlin, Heidelberg: Springer-Verlag, 2012. (Canadian AI’12), p. 388–391. ISBN 978-3642-30352-4. Disponível em: <http://dx.doi.org/10- .1007/978-3-642-30353-1 42>.
AR
ZHU, L.; GORTON, I. Uml profiles for design decisions and non-functional requirements. In: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture,
Rationale, and Design Intent. Washington, DC, USA: IEEE Computer Society, 2007. (SHARK-ADI
’07), p. 8–. ISBN 0-7695-2951-8. Disponível em: <http://dx.doi.org/10.1109/SHARK-ADI.2007.14>.
Duplicado
CLELAND-HUANG, J. et al. A machine learning approach for tracing regulatory codes to product
specific requirements. In: Proceedings of the 32nd ACM/IEEE International Conference on Software
Engineering - Volume 1. New York, NY, USA: ACM, 2010. (ICSE ’10), p. 155–164. ISBN 978-160558-719-6. Disponível em: <http://doi.acm.org/10.1145/1806799.1806825>.
Duplicado
2a análise
Continua na próxima página
153
Referência
1a análise
YU, Y.; JURJENS, J.; SCHRECK, J. Tools for traceability in secure software development. In: Proceedings of the 2008 23rd IEEE/ACM International Conference on Automated Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2008. (ASE ’08), p. 503–504. ISBN 978-1-42442187-9. Disponível em: <http://dx.doi.org/10.1109/ASE.2008.92>.
Dupllicado
ROBBINS, W. Achieving dodaf-driven simulations through executable architectures. In: Proceedings of the 2009 Spring Simulation Multiconference. San Diego, CA, USA: Society
for Computer Simulation International, 2009. (SpringSim ’09), p. 57:1–57:8. Disponível em:
<http://dl.acm.org/citation.cfm?id=1639809.1639868>.
AR
CUDDEBACK, D.; DEKHTYAR, A.; HAYES, J. Automated requirements traceability: The study of
human analysts. In: Proceedings of the 2010 18th IEEE International Requirements Engineering Conference. Washington, DC, USA: IEEE Computer Society, 2010. (RE ’10), p. 231–240. ISBN 978-07695-4162-4. Disponível em: <http://dx.doi.org/10.1109/RE.2010.35>.
Duplicado
OMAR, F.; IBRAHIM, S. Designing test coverage for grey box analysis. In: Proceedings of
the 2010 10th International Conference on Quality Software. Washington, DC, USA: IEEE
Computer Society, 2010. (QSIC ’10), p. 353–356. ISBN 978-0-7695-4131-0. Disponível em:
<http://dx.doi.org/10.1109/QSIC.2010.44>.
Duplicado
REMPEL, P. et al. Requirements traceability across organizational boundaries: a survey and taxonomy.
In: Proceedings of the 19th international conference on Requirements Engineering: Foundation for
Software Quality. Berlin, Heidelberg: Springer-Verlag, 2013. (REFSQ’13), p. 125–140. ISBN 978-3642-37421-0. Disponível em: <http:/- /dx.doi.org/10.1007/978-3-642-37422-7 10>.
AR
STANBRIDGE, C. Retrospective requirement analysis using code coverage of gui driven system tests.
In: Proceedings of the 2010 18th IEEE International Requirements Engineering Conference. Washington, DC, USA: IEEE Computer Society, 2010. (RE ’10), p. 411–412. ISBN 978-0-7695-4162-4. Disponível em: <http://dx.doi.org/10.1109- /RE.2010.64>.
Duplicado
HIRSCHFELD, R.; PERSCHEID, M.; HAUPT, M. Explicit use-case representation in object-oriented
programming languages. SIGPLAN Not., ACM, New York, NY, USA, v. 47, n. 2, p. 51–60, out. 2011.
ISSN 0362-1340. Disponível em: <http://doi.acm.org- /10.1145/2168696.2047856>.
AR
ABUFARDEH, S.; MAGEL, K. Software internationalization: Crosscutting concerns across the development lifecycle. In: Proceedings of the 2009 International Conference on New Trends in Information
and Service Science. Washington, DC, USA: IEEE Computer Society, 2009. (NISS ’09), p. 447–450.
ISBN 978-0-7695-3687-3. Disponível em:<http://dx.doi.org/10.1109/NISS.2009.202>.
Duplicado
LU, C.-W. et al. A requirement tool to support model-based requirement engineering. In: Proceedings of the 2008 32nd Annual IEEE International Computer Software and Applications Conference.
Washington, DC, USA: IEEE Computer Society, 2008. (COMPSAC ’08), p. 712–717. ISBN 978-07695-3262-2. Disponível em: <http:- //dx.doi.org/10.1109/COMPSAC.2008.232>.
Duplicado
LONIEWSKI, G.; INSFRAN, E.; aO, S. A. A systematic review of the use of requirements engineering techniques in model-driven development. In: Proceedings of the 13th international conference on Model driven engineering languages and systems: Part II. Berlin, Heidelberg: SpringerVerlag, 2010. (MODELS’10), p. 213–227. ISBN 3-642-16128-6, 978-3-642-16128-5. Disponível em:
<http://dl.acm.org/citation- .cfm?id=1929101.1929123>..
AR
PARVEEN, T.; TILLEY, S.; GONZALEZ, G. A case study in test management. In: Proceedings of the
45th annual southeast regional conference. New York, NY, USA: ACM, 2007. (ACM-SE 45), p. 82–87.
ISBN 978-1-59593-629-5. Disponível em: <http://doi.acm.org/10.1145/1233341.1233357>.
AR
HAYES, J. H.; ANTONIOL, G.; GUÉHÉNEUC, Y.-G. Prereqir: Recovering pre- requirements via cluster analysis. In: Proceedings of the 2008 15th Working Conference on Reverse Engineering. Washington, DC, USA: IEEE Computer Society, 2008. (WCRE ’08), p. 165–174. ISBN 978-0-7695-3429-9.
Disponível em: <http://dx.doi.org/10.1109- /WCRE.2008.36>.
Duplicado
SOLMS, F. et al. A domain-specific language for urdad based requirements elicitation. In: Proceedings of the South African Institute of Computer Scientists and Information Technologists Conference on Knowledge, Innovation and Leadership in a Diverse, Multidisciplinary Environment. New
York, NY, USA: ACM, 2011. (SAICSIT ’11), p. 224–230. ISBN 978-1-4503-0878-6. Disponível em:
<http://doi.acm.org/10.1145- /2072221.2072247>.
AR
2a análise
Continua na próxima página
154
Referência
1a análise
FALESSI, D.; CANTONE, G.; CANFORA, G. A comprehensive characterization of nlp techniques for identifying equivalent requirements. In: Proceedings of the 2010 ACM-IEEE International Symposium on Empirical Software Engineering and Measurement. New York, NY,
USA: ACM, 2010. (ESEM ’10), p. 18:1–18:10. ISBN 978-1-4503-0039-1. Disponível em:
<http://doi.acm.org/10.1145/1852786.1852810>.
AR
BURGE, J. E.; BROWN, D. C. Seurat: integrated rationale management. In: Proceedings of the 30th
international conference on Software engineering. New York, NY, USA: ACM, 2008. (ICSE ’08), p.
835–838. ISBN 978-1-60558-079-1. Disponível em: <http://doi.acm.org/10.1145/1368088.1368215>.
Duplicado
BAI, X. et al. Gopomosa: a goal-oriented process modeling and simulation advisor. In: Proceedings of the 2011 International Conference on Software and Systems Process. New York,
NY, USA: ACM, 2011. (ICSSP ’11), p. 194–198. ISBN 978-1-4503-0730-7. Disponível em:
<http://doi.acm.org/10.1145/1987875.1987907>.
AR
FAILY, S. et al. Requirements sensemaking using concept maps. In: Proceedings of the 4th international conference on Human-Centered Software Engineering. Berlin, Heidelberg: Springer-Verlag, 2012.
(HCSE’12), p. 217–232. ISBN 978-3-642-34346-9. Disponível em: <http://dx.doi.org/10.1007/978-3642-34347-6 13>.
AR
JAFARINEZHAD, O.; RAMSIN, R. Towards a process factory for developing situational requirements
engineering processes. In: Proceedings of the 27th Annual ACM Symposium on Applied Computing.
New York, NY, USA: ACM, 2012. (SAC ’12), p. 1089–1090. ISBN 978-1-4503-0857-1. Disponível
em: <http://doi.acm.org/10.1145/2245276.2231946>.
AR
GUERROUJ, L. Normalizing source code vocabulary to support program comprehension and software
quality. In: Proceedings of the 2013 International Conference on Software Engineering. Piscataway,
NJ, USA: IEEE Press, 2013. (ICSE ’13), p. 1385–1388. ISBN 978-1-4673-3076-3. Disponível em:
<http://dl.acm.org/citation.cfm?id=2486788- .2487012>.
AR
JOUAULT, F. et al. Inter-dsl coordination support by combining megamodeling and model
weaving. In: Proceedings of the 2010 ACM Symposium on Applied Computing. New York,
NY, USA: ACM, 2010. (SAC ’10), p. 2011–2018. ISBN 978-1-60558-639-7. Disponível em:
<http://doi.acm.org/10.1145/1774088.1774511>.
AR
DAJSUREN, Y. et al. Automotive adls: a study on enforcing consistency through multiple architectural
levels. In: Proceedings of the 8th international ACM SIGSOFT conference on Quality of Software
Architectures. New York, NY, USA: ACM, 2012. (QoSA ’12), p. 71–80. ISBN 978-1-4503-1346-9.
Disponível em: <http://doi.acm.org/10- .1145/2304696.2304710>.
AR
STALLINGER, F. et al. Migrating towards evolving software product lines: challenges of an
sme in a core customer-driven industrial systems engineering context. In: Proceedings of the
2nd International Workshop on Product Line Approaches in Software Engineering. New York,
NY, USA: ACM, 2011. (PLEASE ’11), p. 20–24. ISBN 978-1-4503-0584-6. Disponível em:
<http://doi.acm.org/10.1145/1985484.1985490>.
AR
SANYAL, A.; SANYAL, S.; CHOUDHURY, S. Physical level implementation of a web data model.
In: Proceedings of the 2011 International Conference on Communication, Computing & #38; Security.
New York, NY, USA: ACM, 2011. (ICCCS ’11), p. 483–488. ISBN 978-1-4503-0464-1. Disponível
em: <http://doi.acm.org/10.1145/1947940- .1948040>.
AR
ARNOLD, D.; CORRIVEAU, J.-P.; SHI, W. Scenario-based validation: Beyond the user requirements
notation. In: Proceedings of the 2010 21st Australian Software Engineering Conference. Washington,
DC, USA: IEEE Computer Society, 2010. (ASWEC ’10), p. 75–84. ISBN 978-0-7695-4006-1. Disponível em: <http://dx.doi.org/10.1109/ASWEC- .2010.29>.
Duplicado
ALI, B. S.; KASIRUN, Z. M. 3ci: A tool for crosscutting concern identification. In Proceedings of
the 2008 International Conference on Computational Intelligence for Modelling Control and Automation. Washington, DC, USA: IEEE Computer Society, 2008. p. 351–355. ISBN 978-0-7695-3514-2.
Disponível em: <http://dx.doi.org/10.1109- /CIMCA.2008.77>.
Duplicado
SARABURA, M.; BOWDEN, P. Solving requirements management challenges in product line development. In: Proceedings of the 2008 12th International Software Product Line Conference. Washington, DC, USA: IEEE Computer Society, 2008. (SPLC ’08), p. 352–. ISBN 978-0-7695-3303-2. Disponível em: <http://dx.doi.org/10.1109/SPLC.2008.27>.
Duplicado
2a análise
Continua na próxima página
155
Referência
1a análise
CHANG, C.-H.; LU, C.-W.; CHU, W. C. Improving software integration from requirement process with a model-based object-oriented approach. In: Proceedings of the 2008 Second International Conference on Secure System Integration and Reliability Improvement. Washington, DC, USA:
IEEE Computer Society, 2008. (SSIRI ’08), p. 175–176. ISBN 978-0-7695-3266-0. Disponível em:
<http://dx.doi.org/10.1109/SSIRI.2008.39>.
Duplicado
RAZAVI, R. Capitalizing on uncertainty, diversity and change by online individualization of functionality. In: Proceedings of the 19th international conference on User modeling, adaption, and personalization. Berlin, Heidelberg: Springer-Verlag, 2011. (UMAP’11), p. 365–376. ISBN 978-3-642-22361-7.
Disponível em: <http://dl.acm.org/citation- .cfm?id=2021855.2021892>.
AR
DEEPTIMAHANTI, D. K.; SANYAL, R. Semi-automatic generation of uml models from natural
language requirements. In: Proceedings of the 4th India Software Engineering Conference. New
York, NY, USA: ACM, 2011. (ISEC ’11), p. 165–174. ISBN 978-1-4503-0559-4. Disponível em:
<http://doi.acm.org/10.1145/1953355.1953378>.
AR
HASSAN, R.; BOHNER, S.; EL-KASSAS, S. Formal derivation of security design specifications from
security requirements. In: Proceedings of the 4th annual workshop on Cyber security and information
intelligence research: developing strategies to meet the cyber security and information intelligence
challenges ahead. New York, NY, USA: ACM, 2008. (CSIIRW ’08), p. 10:1–10:3. ISBN 978-1-60558098-2. Disponível em: <http://doi.acm.org/10.1145/1413140.1413152>.
AR
YU, W.; SMITH, S. Reusability of fea software: A program family approach. In: Proceedings of the
2009 ICSE Workshop on Software Engineering for Computational Science and Engineering. Washington, DC, USA: IEEE Computer Society, 2009. (SECSE ’09), p. 43–50. ISBN 978-1-4244-3737-5.
Disponível em: <http://dx.doi.org/10.1109- /SECSE.2009.5069161>.
Duplicado
EGYED, A.; GRAF, F.; GRUNBACHER, P. Effort and quality of recovering requirements-to-code traces: Two exploratory experiments. In: Proceedings of the 2010 18th IEEE International Requirements
Engineering Conference. Washington, DC, USA: IEEE Computer Society, 2010. (RE ’10), p. 221–230.
ISBN 978-0-7695-4162-4. Disponível em: <http://dx.doi.org/10.1109/RE.2010.34>.
Duplicado
BECKERS, K. et al. Common criteria compliant software development (cc-casd). In: Proceedings of the 28th Annual ACM Symposium on Applied Computing. New York, NY,
USA: ACM, 2013. (SAC ’13), p. 1298–1304. ISBN 978-1-4503-1656-9. Disponível em:
<http://doi.acm.org/10.1145/2480486.2480604>.
AR
OH, Y. et al. Extended architecture analysis description language for software product line
approach in embedded systems. In: Proceedings of the 5th IEEE/ACM International Conference on Formal Methods and Models for Codesign. Washington, DC, USA: IEEE Computer Society, 2007. (MEMOCODE ’07), p. 87–88. ISBN 1-4244-1050-9. Disponível em:
<http://dx.doi.org/10.1109/MEMCOD.2007.371243>.
Duplicado
WEBER-JAHNKE, J. H.; ONABAJO, A. Finding defects in natural language confidentiality requirements. In: Proceedings of the 2009 17th IEEE International Requirements Engineering Conference,
RE. Washington, DC, USA: IEEE Computer Society, 2009. (RE ’09), p. 213–222. ISBN 978-0-76953761-0. Disponível em: <http://dx.doi.org/10.1109/RE.2009.41>.
Duplicado
BEHNAM, S. A.; AMYOT, D.; MUSSBACHER, G. Towards a pattern-based framework for goaldriven business process modeling. In: Proceedings of the 2010 Eighth ACIS International Conference on Software Engineering Research, Management and Applications. Washington, DC, USA:
IEEE Computer Society, 2010. (SERA ’10), p. 137–145. ISBN 978-0-7695-4075-7. Disponível em:
<http://dx.doi.org/10.1109/SERA- .2010.27>.
Duplicado
ZHU, Y. et al. An mde based approach for generating software architecture models from formal specifications. In: Proceedings of the 2010 10th International Conference on Quality Software. Washington,
DC, USA: IEEE Computer Society, 2010. (QSIC ’10), p. 373–376. ISBN 978-0-7695-4131-0. Disponível em: <http://dx.doi.org/10.1109/QSIC.2010.13>.
Duplicado
GAST, H. Patterns and traceability in teaching software architecture. In: Proceedings of the
6th international symposium on Principles and practice of programming in Java. New York,
NY, USA: ACM, 2008. (PPPJ ’08), p. 23–31. ISBN 978-1-60558-223-8. Disponível em:
<http://doi.acm.org/10.1145/1411732.1411736>.
AR
2a análise
Continua na próxima página
156
Referência
1a análise
HESS, S. et al. Standardizing model-based in-vehicle infotainment development in the german automotive industry. In: Proceedings of the 4th International Conference on Automotive User Interfaces and
Interactive Vehicular Applications. New York, NY, USA: ACM, 2012. (AutomotiveUI ’12), p. 59–66.
ISBN 978-1-4503-1751-1. Disponível em: <http://doi.acm.org/10.1145/2390256.2390265>.
AR
MONTI, S. et al. Configuration and change management of the outcomes of an automotive engine
control model based software design process. In: Proceedings of the 2008 32nd Annual IEEE International Computer Software and Applications Conference. Washington, DC, USA: IEEE Computer Society, 2008. (COMPSAC ’08), p. 1065–1069. ISBN 978-0-7695-3262-2. Disponível em:
<http://dx.doi.org/10.1109/COMPSAC.2008- .109>.
Duplicado
SULZMANN, M.; NICKLISCH-FRANKEN, J.; ZECHNER, A. Traceability and evidence of correctness of edsl abstractions. In: Proceedings of the ACM SIGPLAN 2013 workshop on Partial evaluation
and program manipulation. New York, NY, USA: ACM, 2013. (PEPM ’13), p. 71–74. ISBN 978-14503-1842-6. Disponível em: <http://doi.acm.org/10.1145/2426890.2426904>.
AR
PERSEIL, I.; PAUTET, L. Co-modeling methodology designed for rt architecture models integration.
In: Proceedings of the 12th IEEE International Conference on Engineering Complex Computer Systems. Washington, DC, USA: IEEE Computer Society, 2007. (ICECCS ’07), p. 371–376. ISBN 07695-2895-3. Disponível em: <http://dx.doi.org/10.1109/ICECCS.2007.19>.
Duplicado
HONG, W. Architecture-centric software process for pattern based software reuse. In: Proceedings
of the 2009 WRI World Congress on Software Engineering - Volume 04. Washington, DC, USA:
IEEE Computer Society, 2009. (WCSE ’09), p. 95–99. ISBN 978-0-7695-3570-8. Disponível em:
<http://dx.doi.org/10.1109/WCSE.2009.188>.
Duplicado
LAMSWEERDE, A. van. Requirements engineering: from craft to discipline. In: Proceedings of the
16th ACM SIGSOFT International Symposium on Foundations of software engineering. New York,
NY, USA: ACM, 2008. (SIGSOFT ’08/FSE-16), p. 238–249. ISBN 978-1-59593-995-1. Disponível
em: <http://doi.acm.org/10.1145- /1453101.1453133>.
AR
CHAKRABORTY, S.; DEHLINGER, J. Applying the grounded theory method to derive enterprise
system requirements. In: Proceedings of the 2009 10th ACIS nternational Conference on Software Engineering, Artificial Intelligences, Networking and Parallel/Distributed Computing. Washington, DC,
USA: IEEE Computer Society, 2009. (SNPD ’09), p. 333–338. ISBN 978-0-7695-3642-2. Disponível
em: <http://dx.doi.org/10.1109/SNPD.2009.102>.
Duplicado
ZHENG, X.; LIU, X.; LIU, S. Use case and non-functional scenario template-based approach to identify aspects. In: Proceedings of the 2010 Second International Conference on Computer Engineering
and Applications - Volume 02. Washington, DC, USA: IEEE Computer Society, 2010. (ICCEA ’10),
p. 89–93. ISBN 978-0-7695-3982-9. Disponível em: <http://dx.doi.org/10.1109/ICCEA.2010.174>.
Duplicado
ARAúJO, J. et al. Advanced modularity for building spl feature models: a model-driven approach. In: Proceedings of the 28th Annual ACM Symposium on Applied Computing. New York,
NY, USA: ACM, 2013. (SAC ’13), p. 1246–1253. ISBN 978-1-4503-1656-9. Disponível em:
<http://doi.acm.org/10.1145/2480362.2480596>.
Duplicado
MASHKOOR, A.; MATOUSSI, A. Towards validation of requirements models. In: Proceedings of
the Second international conference on Abstract State Machines, Alloy, B and Z. Berlin, Heidelberg:
Springer-Verlag, 2010. (ABZ’10), p. 404–404. ISBN 3-642-11810-0, 978-3-642-11810-4. Disponível
em: <http://dx.doi.org/10.1007/978-3- 642-11811-1 38>.
AR
ALI, B. S.; KASIRUN, Z. M. A review on approaches for identifying crosscutting concerns. In: Proceedings of the 2008 International Conference on Advanced Computer Theory and Engineering. Washington, DC, USA: IEEE Computer Society, 2008. p. 855–859. ISBN 978-0-7695-3489-3. Disponível em:
<http://dx.doi.org/10.1109/ICACTE.2008.13>.
Duplicado
UWANO, H.; MONDEN, A.; MATSUMOTO, K.-i. Dresrem 2: An analysis system for multidocument software review using reviewers’ eye movements. In: Proceedings of the 2008 The
Third International Conference on Software Engineering Advances. Washington, DC, USA: IEEE
Computer Society, 2008. (ICSEA ’08), p. 177–183. ISBN 978-0-7695-3372-8. Disponível em:
<http://dx.doi.org/10.1109/ICSEA.2008.49>.
Duplicado
2a análise
Continua na próxima página
157
Referência
1a análise
2a análise
FILHO, R. S. S. et al. Supporting concern-based regression testing and prioritization in
a model-driven environment. In: Proceedings of the 2010 IEEE 34th Annual Computer
Software and Applications Conference Workshops. Washington, DC, USA: IEEE Computer Society, 2010. (COMPSACW ’10), p. 323–328. ISBN 978-0-7695-4105-1. Disponível em:
<http://dx.doi.org/10.1109/COMPSACW.2010.63>.
Duplicado
HILL, J.; VICTOR, D. The product engineering class in the software safety risk taxonomy for building
safety-critical systems. In: Proceedings of the 19th Australian Conference on Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2008. (ASWEC ’08), p. 617–626. ISBN 978-0-76953100-7. Disponível em: <http://dl.acm.org/citation.cfm?id=1395083.1395715>.
Duplicado
WEBER-JAHNKE, J. H.; ONABAJO, A. Mining and analysing security goal models in health information systems. In: Proceedings of the 2009 ICSE Workshop on Software Engineering in Health Care.
Washington, DC, USA: IEEE Computer Society, 2009. (SEHC ’09), p. 42–52. ISBN 978-1-4244-37399. Disponível em: <http://dx.doi.org/10.1109/SEHC.2009.5069605>.
Duplicado
RODRIGUEZ, L. et al. Improving the quality of agent-based systems: Integration of requirements
modeling into gaia. In: Proceedings of the 2009 Ninth International Conference on Quality Software.
Washington, DC, USA: IEEE Computer Society, 2009. (QSIC ’09), p. 278–283. ISBN 978-0-76953828-0. Disponível em: <http://dx.doi.org/10- .1109/QSIC.2009.43>.
Duplicado
GOLDBERG, M.; WIENER, G. A declarative approach for software modeling. In: Proceedings
of the 14th international conference on Practical Aspects of Declarative Languages. Berlin, Heidelberg: Springer-Verlag, 2012. (PADL’12), p. 18–32. ISBN 978-3-642-27693-4. Disponível em:
<http://dx.doi.org/10.1007/978-3-642-27694-1 3>.
AR
ZHU, L.; GORTON, I. Uml profiles for design decisions and non-functional requirements. In: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture,
Rationale, and Design Intent. Washington, DC, USA: IEEE Computer Society, 2007. (SHARK-ADI
’07), p. 8–. ISBN 0-7695-2951-8. Disponível em: <http://dx.doi.org/10.1109/SHARK-ADI.2007.14>.
Duplicado
MATOUSSI, A.; PETIT, D. Improving traceability between kaos requirements models and b specifications. In: Proceedings of the Second international conference on Abstract State Machines, Alloy, B
and Z. Berlin, Heidelberg: Springer-Verlag, 2010. (ABZ’10), p. 401–402. ISBN 3-642-11810-0, 9783-642-11810-4. Disponível em: <http://dx.doi.org/10.1007/978-3-642-11811-1 36>.
Duplicado
DELATER, A.; PAECH, B. Analyzing the tracing of requirements and source code during software development. In: Proceedings of the 19th international conference on Requirements Engineering: Foundation for Software Quality. Berlin, Heidelberg: Springer-Verlag, 2013. (REFSQ’13), p. 308–314. ISBN
978-3-642-37421-0. Disponível em: <http://dx.doi.org/10.1007/978-3-642-37422-7 22>.
AS
Selecionado
SERRANO, M.; LEITE, J. C. S. do P. A rich traceability model for social interactions. In: Proceedings of the 6th International Workshop on Traceability in Emerging Forms of Software Engineering.
New York, NY, USA: ACM, 2011. (TEFSE ’11), p. 63–66. ISBN 978-1-4503-0589-1. Disponível em:
<http://doi.acm.org/10.1145/1987856.1987871>.
AS
1
FALESSI, D. et al. Safeslice: a model slicing and design safety inspection tool for sysml. In: Proceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of
software engineering. New York, NY, USA: ACM, 2011. (ESEC/FSE ’11), p. 460–463. ISBN 978-14503-0443-6. Disponível em: <http://doi.acm.org/10.1145/2025113.2025191>.
AS
2
FERREIRA, P. J. A. V.; BARROS, M. d. O. Traceability between function point and source code.
In: Proceedings of the 6th International Workshop on Traceability in Emerging Forms of Software
Engineering. New York, NY, USA: ACM, 2011. (TEFSE ’11), p. 10–16. ISBN 978-1-4503-0589-1.
Disponível em: <http://doi.acm.org/10.1145- /1987856.1987860>.
AS
Selecionado
CLELAND-HUANG, J.; HAYES, J. H.; DOMEL, J. M. Model-based traceability. In: Proceedings of
the 2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering. Washington,
DC, USA: IEEE Computer Society, 2009. (TEFSE ’09), p. 6–10. ISBN 978-1-4244-3741-2. Disponível
em: <http://dx.doi.org/10.1109/TEFSE- .2009.5069575>.
Duplicado
HONG, Y.; KIM, M.; LEE, S.-W. Requirements management tool with evolving traceability for heterogeneous artifacts in the entire life cycle. In: Proceedings of the 2010 Eighth ACIS International Conference on Software Engineering Research, Management and Applications. Washington, DC, USA:
IEEE Computer Society, 2010. (SERA ’10), p. 248–255. ISBN 978-0-7695-4075-7. Disponível em:
<http://dx.doi.org/10.1109/SERA- .2010.39>.
Duplicado
Continua na próxima página
158
Referência
1a análise
DEHLINGER, J. et al. Decimal and plfaultcat: From product-line requirements to productline member software fault trees. In: Companion to the proceedings of the 29th International Conference on Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007. (ICSE COMPANION ’07), p. 49–50. ISBN 0-7695-2892-9. Disponível em:
<http://dx.doi.org/10.1109/ICSECOMPANION.2007.29>.
Duplicado
SEIBEL, A. From software traceability to global model management and back again. In: Proceedings
of the 2011 15th European Conference on Software Maintenance and Reengineering. Washington, DC,
USA: IEEE Computer Society, 2011. (CSMR ’11), p. 381–384. ISBN 978-0-7695-4343-7. Disponível
em: <http://dx.doi.org/10.1109/CSMR- .2011.58>.
Duplicado
TUN, T. T. et al. A framework for developing feature-rich software systems. In:Proceedings of the 2009
16th Annual IEEE International Conference and Workshop on the Engineering of Computer Based
Systems. Washington, DC, USA: IEEE Computer Society, 2009. (ECBS ’09), p. 206–214. ISBN 9780-7695-3602-6. Disponível em: <http://dx.doi.org/10.1109/ECBS.2009.32>.
Duplicado
MALAVOLTA, I.; MUCCINI, H.; REKHA, V. S. Supporting architectural design decisions evolution
through model driven engineering. In: Proceedings of the Third international conference on Software
engineering for resilient systems. Berlin, Heidelberg: Springer-Verlag, 2011. (SERENE’11), p. 63–77.
ISBN 978-3-642-24123-9. Disponível em: <http://dl.acm.org/citation.cfm?id=2045537.2045546>.
AS
OMORONYIA, I. et al. Use case to source code traceability: The developer navigation view point. In:
Proceedings of the 2009 17th IEEE International Requirements Engineering Conference, RE. Washington, DC, USA: IEEE Computer Society, 2009. (RE ’09), p. 237– 242. ISBN 978-0-7695-3761-0. Disponível em: <http://dx.doi.org/10.1109/RE.2009.26>.
Duplicado
KASSAB, M.; ORMANDJIEVA, O.; DANEVA, M. A metamodel for tracing non- functional requirements. In: Proceedings of the 2009 WRI World Congress on Computer Science and Information Engineering - Volume 07. Washington, DC, USA: IEEE Computer Society, 2009. (CSIE ’09), p. 687–694.
ISBN 978-0-7695-3507-4. Disponível em:<http://dx.doi.org/10.1109/CSIE.2009.946>.
Duplicado
KASSAB, M.; ORMANDJIEVA, O.; DANEVA, M. A traceability metamodel for change management of non-functional requirements. In: Proceedings of the 2008 Sixth International Conference on Software Engineering Research, Management and Applications. Washington, DC, USA:
IEEE Computer Society, 2008. (SERA ’08), p. 245–254. ISBN 978-0-7695-3302-5. Disponível em:
<http://dx.doi.org/10.1109/SERA- .2008.37>.
Duplicado
ROCHIMAH, S. et al. An evaluation of traceability approaches to support software evolution. In:
Proceedings of the International Conference on Software Engineering Advances. Washington, DC,
USA: IEEE Computer Society, 2007. (ICSEA ’07), p. 19–. ISBN 0-7695-2937-2. Disponível em:
<http://dx.doi.org/10.1109/ICSEA.2007.17>.
Duplicado
MAHMOUD, A.; NIU, N. Source code indexing for automated tracing. In: Proceedings of the
6th International Workshop on Traceability in Emerging Forms of Software Engineering. New
York, NY, USA: ACM, 2011. (TEFSE ’11), p. 3–9. ISBN 978-1-4503- 0589-1. Disponível em:
<http://doi.acm.org/10.1145/1987856.1987859>.
AS
ESPINOZA, A.; GARBAJOSA, J. A proposal for defining a set of basic items for project-specific
traceability methodologies. In: Proceedings of the 2008 32nd Annual IEEE Software Engineering
Workshop. Washington, DC, USA: IEEE Computer Society, 2008. (SEW ’08), p. 175–184. ISBN 9780-7695-3617-0. Disponível em: <http://dx.doi.org/10.1109/SEW.2008.23>.
Duplicado
DUBOIS, H.; PERALDI-FRATI, M.-A.; LAKHAL, F. A model for requirements traceability in a heterogeneous model-based design process: Application to automotive embedded systems. In: Proceedings of the 2010 15th IEEE International Conference on Engineering of Complex Computer Systems.
Washington, DC, USA: IEEE Computer Society, 2010. (ICECCS ’10), p. 233–242. ISBN 978-0-76954015-3. Disponível em: <http://dx.doi.org/10.1109/ICECCS.2010.2>.
Duplicado
SOUSA, K. et al. Supporting requirements in a traceability approach between business process and
user interfaces. In: Proceedings of the VIII Brazilian Symposium on Human Factors in Computing
Systems. Porto Alegre, Brazil, Brazil: [s.n.], 2008. (IHC ’08), p. 272–275. ISBN 978-85-7669-203-4.
Disponível em: <http://dl.acm.org/citation- .cfm?id=1497470.1497505>.
AS
2a análise
Selecionado
1
Selecionado
Continua na próxima página
159
Referência
1a análise
2a análise
MÄDER, P.; GOTEL, O.; PHILIPPOW, I. Rule-based maintenance of post-requirements traceability
relations. In: Proceedings of the 2008 16th IEEE International Requirements Engineering Conference.
Washington, DC, USA: IEEE Computer Society, 2008. (RE ’08), p. 23–32. ISBN 978-0-7695-3309-4.
Disponível em: <http://dx.doi.org/10.1109/RE- .2008.24>.
Duplicado
GATTI, S.; BALLAND, E.; CONSEL, C. A step-wise approach for integrating qos throughout software development. In: Proceedings of the 14th international conference on Fundamental approaches to
software engineering: part of the joint European conferences on theory and practice of software. Berlin, Heidelberg: Springer-Verlag, 2011. (FASE’11/ETAPS’11), p. 217–231. ISBN 978-3-642-19810-6.
Disponível em: <http://dl.acm.org/citation.cfm?id=1987434.1987456>.
AS
SATYANANDA, T. K. et al. Identifying traceability between feature model and software architecture in software product line using formal concept analysis. In: Proceedings of the The
2007 International Conference Computational Science and its Applications. Washington, DC, USA:
IEEE Computer Society, 2007. (ICCSA ’07), p. 380–388. ISBN 0-7695-2945-3. Disponível em:
<http://dx.doi.org/10.1109/ICCSA.2007.47>.
Duplicado
GUO, Y. et al. An ontology based improved software requirement traceability matrix. In: Proceedings
of the 2009 Second International Symposium on Knowledge Acquisition and Modeling - Volume 01.
Washington, DC, USA: IEEE Computer Society, 2009. (KAM ’09), p. 160–163. ISBN 978-0-76953888-4. Disponível em: <http://dx.doi.org/10.1109/KAM.2009.63>.
Duplicado
GOKNIL, A.; KURTEV, I.; BERG, K. van den. Tool support for generation and validation of traces
between requirements and architecture. In: Proceedings of the 6th ECMFA Traceability Workshop.
New York, NY, USA: ACM, 2010. (ECMFA-TW ’10), p. 39–46. ISBN 978-1-60558-993-0. Disponível
em: <http://doi.acm.org/10.1145/1814392- .1814398>.
AS
MAHMOUD, A.; NIU, N. Using semantics-enabled information retrieval in requirements tracing: An ongoing experimental investigation. In: Proceedings of the 2010 IEEE 34th Annual Computer Software and Applications Conference. Washington, DC, USA: IEEE Computer Society, 2010. (COMPSAC ’10), p. 246–247. ISBN 978-0-7695-4085-6. Disponível em:
<http://dx.doi.org/10.1109/COMPSAC.2010.29>.
Duplicado
SENGUPTA, S.; KANJILAL, A.; BHATTACHARYA, S. Requirement traceability in software development process: An empirical approach. In: Proceedings of the 2008 The 19th
IEEE/IFIP International Symposium on Rapid System Prototyping. Washington, DC, USA: IEEE
Computer Society, 2008. (RSP ’08), p. 105–111. ISBN 978-0-7695-3180-9. Disponível em:
<http://dx.doi.org/10.1109/RSP.2008.14>.
Duplicado
KAMALRUDIN, M. Automated software tool support for checking the inconsistency of requirements.
In: Proceedings of the 2009 IEEE/ACM International Conference on Automated Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2009. (ASE ’09), p. 693–697. ISBN 978-0-76953891-4. Disponível em: <http://dx.doi.org/10.1109/ASE.2009.38>.
Duplicado
POOLEY, R.; WARREN, C. Reuse through requirements traceability. In: Proceedings of the 2008
The Third International Conference on Software Engineering Advances. Washington, DC, USA:
IEEE Computer Society, 2008. (ICSEA ’08), p. 65–70. ISBN 978-0-7695-3372-8. Disponível em:
<http://dx.doi.org/10.1109/ICSEA.2008.60>.
Duplicado
ASSAWAMEKIN, N.; SUNETNANTA, T.; PLUEMPITIWIRIYAWEJ, C. Resolving multiperspective requirements traceability through ontology integration. In: Proceedings of the 2008
IEEE International Conference on Semantic Computing. Washington, DC, USA: IEEE Computer Society, 2008. (ICSC ’08), p. 362–369. ISBN 978-0-7695-3279-0. Disponível em:
<http://dx.doi.org/10.1109/ICSC.2008.13>.
Duplicado
YRJÖNEN, A.; MERILINNA, J. Tooling for the full traceability of non-functional requirements
within model-driven development. In: Proceedings of the 6th ECMFA Traceability Workshop. New
York, NY, USA: ACM, 2010. (ECMFA-TW ’10), p. 15–22. ISBN 978-1-60558-993-0. Disponível em:
<http://doi.acm.org/10.1145/1814392- .1814395>.
AS
Selecionado
CLELAND-HUANG, J. et al. Trace queries for safety requirements in high assurance systems. In: Proceedings of the 18th international conference on Requirements Engineering: foundation for software
quality. Berlin, Heidelberg: Springer-Verlag, 2012. (REFSQ’12), p. 179–193. ISBN 978-3-642-287138. Disponível em: <http://dx.doi.org- /10.1007/978-3-642-28714-5 16>.
AS
2
3
Selecionado
Continua na próxima página
160
Referência
1a análise
2a análise
SARDINHA, A. et al. Ea-tracer: identifying traceability links between code aspects and early aspects. In: Proceedings of the 27th Annual ACM Symposium on Applied Computing. New York,
NY, USA: ACM, 2012. (SAC ’12), p. 1035–1042. ISBN 978-1-4503-0857-1. Disponível em:
<http://doi.acm.org/10.1145/2245276.2231938>.
AS
2
ZIFTCI, C.; KRUEGER, I. Tracing requirements to tests with high precision and recall. In: Proceedings of the 2011 26th IEEE/ACM International Conference on Automated Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2011. (ASE ’11), p. 472–475. ISBN 978-1-45771638-6. Disponível em: <http:/- /dx.doi.org/10.1109/ASE.2011.6100102>.
Duplicado
HILL, J.; TILLEY, S. Creating safety requirements traceability for assuring and recertifying legacy
safety-critical systems. In: Proceedings of the 2010 18th IEEE International Requirements Engineering
Conference. Washington, DC, USA: IEEE Computer Society, 2010. (RE ’10), p. 297–302. ISBN 9780-7695-4162-4. Disponível em: <http://dx.doi.org/10.1109/RE.2010.42>.
Duplicado
NOLL, R. P.; RIBEIRO, M. B. Ontological traceability over the unified process. In: Proceedings of the
14th Annual IEEE International Conference and Workshops on the Engineering of Computer-Based
Systems. Washington, DC, USA: IEEE Computer Society, 2007. (ECBS ’07), p. 249–255. ISBN 07695-2772-8. Disponível em: <http://dx.doi.org/10.1109/ECBS.2007.58>.
Duplicado
MCMILLAN, C.; POSHYVANYK, D.; REVELLE, M. Combining textual and structural analysis
of software artifacts for traceability link recovery. In: Proceedings of the 2009 ICSE Workshop
on Traceability in Emerging Forms of Software Engineering. Washington, DC, USA: IEEE
Computer Society, 2009. (TEFSE ’09), p. 41–48. ISBN 978-1-4244-3741-2. Disponível em:
<http://dx.doi.org/10.1109/TEFSE.2009.5069582>.
Duplicado
DÍAZ, J. et al. Change impact analysis in product-line architectures. In: Proceedings of the 5th European conference on Software architecture. Berlin, Heidelberg:
Springer- Verlag, 2011. (ECSA’11), p. 114–129. ISBN 978-3-642-23797-3. Disponível em:
<http://dl.acm.org/citation.cfm?id=2041790.2041806>.
AS
BORG, M. In vivo evaluation of large-scale ir-based traceability recovery. In: Proceedings of
the 2011 15th European Conference on Software Maintenance and Reengineering. Washington,
DC, USA: IEEE Computer Society, 2011. (CSMR ’11), p. 365–368. ISBN 978-0-7695-43437.Disponívelem:<http://dx.doi.org/10.1109/CSMR.2011.54>.
Duplicado
DELATER, A.; PAECH, B. Analyzing the tracing of requirements and source code during software development. In: Proceedings of the 19th international conference on Requirements Engineering: Foundation for Software Quality. Berlin, Heidelberg: Springer-Verlag, 2013. (REFSQ’13), p. 308–314. ISBN
978-3-642-37421-0. Disponível em: <http://dx.doi.org/10.1007/978-3-642-37422-7 22>.
Duplicado
LEVENDOVSZKY, T. et al. A transformation instance-based approach to traceability. In: Proceedings
of the 6th ECMFA Traceability Workshop. New York, NY, USA: ACM, 2010. (ECMFA-TW ’10), p.
55–60. ISBN 978-1-60558-993-0. Disponível em: <http://doi.acm.org/10.1145/1814392.1814400>.
AS
Selecionado
CAVALCANTI, Y. a. C. et al. Towards metamodel support for variability and traceability in software
product lines. In: Proceedings of the 5th Workshop on Variability Modeling of Software-Intensive Systems. New York, NY, USA: ACM, 2011. (VaMoS ’11), p. 49–57. ISBN 978-1-4503-0570-9. Disponível
em: <http://doi.acm.org/10.1145- /1944892.1944898>.
AS
3
NAVARRO, E.; LETELIER, P.; RAMOS, I. Requirements and scenarios: Running aspect-oriented software architectures. In: Proceedings of the Sixth Working IEEE/IFIP Conference on Software Architecture. Washington, DC, USA: IEEE Computer Society, 2007. (WICSA ’07), p. 23–. ISBN 0-7695-27442. Disponível em: <http://dx.doi.org/10- .1109/WICSA.2007.36>.
Duplicado
EGYED, A.; BINDER, G.; GRUNBACHER, P. Strada: A tool for scenario-based featureto-code trace detection and analysis. In: Companion to the proceedings of the 29th International Conference on Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007. (ICSE COMPANION ’07), p. 41–42. ISBN 0-7695-2892-9. Disponível em:
<http://dx.doi.org/10.1109/ICSECOMPANION.2007.70>.
Duplicado
ASSAWAMEKIN, N. An ontology-based approach for multiperspective requirements traceability
between analysis models. In: Proceedings of the 2010 IEEE/ACIS 9th International Conference on
Computer and Information Science. Washington, DC, USA: IEEE Computer Society, 2010. (ICIS ’10),
p. 673–678. ISBN 978-0-7695-4147-1. Disponível em: <http://dx.doi.org/10.1109/ICIS.2010.43>.
Duplicado
1
Continua na próxima página
161
Referência
1a análise
2a análise
SULTANOV, H. Requirements tracing: discovering related documents through artificial pheromones
and term proximity. In: Proceedings of the 33rd International Conference on Software Engineering.
New York, NY, USA: ACM, 2011. (ICSE ’11), p. 1173–1175. ISBN 978-1-4503-0445-0. Disponível
em: <http://doi.acm.org/10.1145/1985793.1986033>.
Duplicado
MOON, M. et al. A metamodeling approach to tracing variability between requirements
and architecture in software product lines. In: Proceedings of the 7th IEEE International Conference on Computer and Information Technology. Washington, DC, USA: IEEE
Computer Society, 2007. (CIT ’07), p. 927–933. ISBN 0-7695-2983-6. Disponível em:
<http://dl.acm.org/citation.cfm?id=1317531.1317997>.
Duplicado
HERZIG, K.; ZELLER, A. Mining the jazz repository: Challenges and opportunities. In: Proceedings
of the 2009 6th IEEE International Working Conference on Mining Software Repositories. Washington, DC, USA: IEEE Computer Society, 2009. (MSR ’09), p. 159–162. ISBN 978-1-4244-3493-0.
Disponível em: <http://dx.doi.org/10.1109/MSR- .2009.5069495>.
Duplicado
NOLL, R. P.; RIBEIRO, M. B. Enhancing traceability using ontologies. In: Proceedings of the 2007
ACM symposium on Applied computing. New York, NY, USA: ACM, 2007. (SAC ’07), p. 1496–1497.
ISBN 1-59593-480-4. Disponível em: <http://doi.acm.org/10.1145/1244002.1244322>.
AS
1
RUIZ, J. F.; COMAR, C.; MOY, Y. Source code as the key artifact in requirement- based development:
the case of ada 2012. In: Proceedings of the 17th Ada-Europe international conference on Reliable
Software Technologies. Berlin, Heidelberg: Springer-Verlag, 2012. (Ada-Europe’12), p. 49–59. ISBN
978-3-642-30597-9. Disponível em: <http://dx.doi.org/10.1007/978-3-642-30598-6 4>.
AS
3
SCHWARZ, H. Towards a comprehensive traceability approach in the context of software maintenance. In: Proceedings of the 2009 European Conference on Software Maintenance and Reengineering.
Washington, DC, USA: IEEE Computer Society, 2009. (CSMR ’09), p. 339–342. ISBN 978-0-76953589-0. Disponível em: <http://dx.doi.org/10.1109/CSMR.2009.8>.
Duplicado
CLELAND-HUANG, J.; MARRERO, W.; BERENBACH, B. Goal-centric traceability: Using virtual plumblines to maintain critical systemic qualities. IEEE Trans. Softw. Eng., IEEE Press,
Piscataway, NJ, USA, v. 34, n. 5, p. 685–699, set. 2008. ISSN 0098-5589. Disponível em:
<http://dx.doi.org/10.1109/TSE.2008.45>.
Duplicado
REMPEL, P. et al. Requirements traceability across organizational boundaries: a survey and taxonomy.
In: Proceedings of the 19th international conference on Requirements Engineering: Foundation for
Software Quality. Berlin, Heidelberg: Springer-Verlag, 2013. (REFSQ’13), p. 125–140. ISBN 978-3642-37421-0. Disponível em: <http://dx.doi.org/10.1007/978-3-642-37422-7 10>.
Duplicado
ASUNCION, H. U.; FRAN COIS, F.; TAYLOR, R. N. An end-to-end industrial software traceability tool. In: Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering. New York,
NY, USA: ACM, 2007. (ESEC-FSE ’07), p. 115–124. ISBN 978-1-59593-811-4. Disponível em:
<http://doi.acm.org/10.1145/1287624- .1287642>.
AS
Selecionado
GRECHANIK, M.; MCKINLEY, K. S.; PERRY, D. E. Recovering and using use-case-diagram-tosource-code traceability links. In: Proceedings of the the 6th joint meeting of the European software
engineering conference and the ACM SIGSOFT symposium on The foundations of software engineering. New York, NY, USA: ACM, 2007. (ESEC-FSE ’07), p. 95–104. ISBN 978-1-59593-811-4.
Disponível em: <http://doi.acm.org/10.1145/1287624.1287640>.
AS
2
GHANAM, Y.; MAURER, F. Extreme product line engineering: Managing variability and traceability
via executable specifications. In: Proceedings of the 2009 Agile Conference. Washington, DC, USA:
IEEE Computer Society, 2009. (AGILE ’09), p. 41–48. ISBN 978-0-7695-3768-9. Disponível em:
<http://dx.doi.org/10.1109/AGILE.2009.12>.
AS
3
ESPINOZA, A.; DÍAZ, J. A traceability semantics approach for supporting product value analysis. In: Proceedings of the 11th International Conference on Product Focused Software. New York,
NY, USA: ACM, 2010. (PROFES ’10), p. 102–104. ISBN 978-1-4503-0281-4. Disponível em:
<http://doi.acm.org/10.1145/1961258.1961282>.
AU
CHENGJUN, W. Architecture driven component development for top-down software reuse. In: Proceedings of the 2008 International Conference on Computer Science and Software Engineering - Volume
05. Washington, DC, USA: IEEE Computer Society, 2008. (CSSE ’08), p. 1349–1352. ISBN 978-07695-3336-0. Disponível em: <http://dx.doi.org/10.1109/CSSE.2008.87>.
Duplicado
162
Quadro 43 – Trabalhos - Fonte IEEE
Referência
1a análise
MÄDER, P. et al. tracemaintainer - automated traceability maintenance. In: Proceedings of the
2008 16th IEEE International Requirements Engineering Conference. Washington, DC, USA:
IEEE Computer Society, 2008. (RE ’08), p. 329–330. ISBN 978-0-7695-3309-4. Disponível em:
<http://dx.doi.org/10.1109/RE.2008.25>.
AI
conference (no reference) - Early Aspects at ICSE: Workshop in Aspect-Oriented Requirements Engineering and Architecture design - Cover
AI
conference (no reference) - Computer Software and Applications Conference, 2009. COMPSAC ’09.
33rd Annual IEEE International
AI
conference (no reference) - Requirements Engineering Conference (RE), 2011 19th IEEE International
AI
LUCIA, A. D.; FASANO, F.; OLIVETO, R. Traceability management for impact analysis. In: Frontiers
of Software Maintenance, 2008. FoSM 2008. [S.l.: s.n.], 2008. p. 21–30.
AR
BARMI, Z.; EBRAHIMI, A.; FELDT, R. Alignment of requirements specification and testing: A systematic mapping study. In: Software Testing, Verification and Validation Workshops (ICSTW), 2011
IEEE Fourth International Conference on. [S.l.: s.n.], 2011. p. 476–485.
AR
SOZEN, N.; MERLO, E. Adapting software product lines for complex certifiable avionics software.
In: Product Line Approaches in Software Engineering (PLEASE), 2012 3rd International Workshop
on. [S.l.: s.n.], 2012. p. 21–24.
AR
CUDDEBACK, D.; DEKHTYAR, A.; HAYES, J. Automated requirements traceability: The study of
human analysts. In: Proceedings of the 2010 18th IEEE International Requirements Engineering Conference. Washington, DC, USA: IEEE Computer Society, 2010. (RE ’10), p. 231–240. ISBN 978-07695-4162-4. Disponível em: <http://dx.doi.org/10.1109/RE.2010.35>.
AR
FARCAS, C. et al. Addressing the integration challenge for avionics and automotive systems;from
components to rich services. Proceedings of the IEEE, v. 98, n. 4, p. 562–583, 2010. ISSN 0018-9219.
AR
STALLBAUM, H.; RZEPKA, M. Toward do-178b-compliant test models. In: Model- Driven Engineering, Verification, and Validation (MoDeVVa), 2010 Workshop on. [S.l.: s.n.], 2010. p. 25–30.
AR
FALESSI, D.; CANTONE, G.; CANFORA, G. Empirical principles and an industrial case study in
retrieving equivalent requirements via natural language processing techniques. Software Engineering,
IEEE Transactions on, v. 39, n. 1, p. 18–44, 2013. ISSN 0098-5589.
AR
MARTINS, J.; MACHADO, R. Ontologies for product and process traceability at manufacturing organizations: A software requirements approach. In: Quality of Information and Communications Technology (QUATIC), 2012 Eighth International Conference on the. [S.l.: s.n.], 2012. p. 353–358.
AR
LU, C.-W. et al. A requirement tool to support model-based requirement engineering. In: Proceedings of the 2008 32nd Annual IEEE International Computer Software and Applications Conference.
Washington, DC, USA: IEEE Computer Society, 2008. (COMPSAC ’08), p. 712–717. ISBN 978-07695-3262-2. Disponível em: <http://dx.doi.org/10.1109/COMPSAC.2008.232>.
AR
LONIEWSKI, G.; ARMESTO, A.; INSFRAN, E. An architecture-oriented model-driven requirements
engineering approach. In: Model-Driven Requirements Engineering Workshop (MoDRE), 2011. [S.l.:
s.n.], 2011. p. 31–38.
AR
OWENS, B. et al. Application of a safety-driven design methodology to an outer planet exploration
mission. In: Aerospace Conference, 2008 IEEE. [S.l.: s.n.], 2008. p. 1–24. ISSN 1095-323X.
AR
OKUBO, T.; KAIYA, H.; YOSHIOKA, N. Effective security impact analysis with patterns for software
enhancement. In: Availability, Reliability and Security (ARES), 2011 Sixth International Conference
on. [S.l.: s.n.], 2011. p. 527–534.
AR
BURNEY, S. et al. Traceability management framework for patient data in healthcare environment. In:
Computer Science and Information Technology (ICCSIT), 2010 3rd IEEE International Conference on.
[S.l.: s.n.], 2010. v. 2, p. 264–268.
AR
NAVARRO, E.; LETELIER, P.; RAMOS, I. Requirements and scenarios: Running aspect-oriented software architectures. In: Proceedings of the Sixth Working IEEE/IFIP Conference on Software Architecture. Washington, DC, USA: IEEE Computer Society, 2007. (WICSA ’07), p. 23–. ISBN 0-7695-27442. Disponível em: <http://dx.doi.org/10- .1109/WICSA.2007.36>.
AR
LINIC, J. Information systems modeling with use cases. In: Information Technology Interfaces, 2007.
ITI 2007. 29th International Conference on. [S.l.: s.n.], 2007. p. 139–144.
AR
2a análise
Continua na próxima página
163
Referência
1a análise
HUSSAIN, T.; ESCHBACH, R. Automated fault tree generation and risk-based testing of networked
automation systems. In: Emerging Technologies and Factory Automation (ETFA), 2010 IEEE Conference on. [S.l.: s.n.], 2010. p. 1–8. ISSN 1946-0740.
AR
CLELAND-HUANG, J. et al. A machine learning approach for tracing regulatory codes to product
specific requirements. In: Proceedings of the 32nd ACM/IEEE International Conference on Software
Engineering - Volume 1. New York, NY, USA: ACM, 2010. (ICSE ’10), p. 155–164. ISBN 978-160558-719-6. Disponível em: <http://doi.acm.org/10.1145/1806799.1806825>.
AR
MENTEN, A.; SCHEIBMAYR, S.; KLIMPKE, L. Using audio and collaboration technologies for distributed requirements elicitation and documentation. In: Managing Requirements Knowledge (MARK),
2010 Third International Workshop on. [S.l.: s.n.], 2010. p. 51–59.
AR
MELLADO, D. et al. Automated support for security requirements engineering in software product
line domain engineering. In: Availability, Reliability and Security, 2009. ARES ’09. International Conference on. [S.l.: s.n.], 2009. p. 224–231.
AR
MONTI, S. et al. Configuration and change management of the outcomes of an automotive engine
control model based software design process. In: Proceedings of the 2008 32nd Annual IEEE International Computer Software and Applications Conference. Washington, DC, USA: IEEE Computer Society, 2008. (COMPSAC ’08), p. 1065–1069. ISBN 978-0-7695-3262-2. Disponível em:
<http://dx.doi.org/10.1109/COMPSAC.2008- .109>.
AR
FILHO, G. de C.; LENCASTRE, M. Towards a traceability visualisation tool. In: Quality of Information and Communications Technology (QUATIC), 2012 Eighth International Conference on the. [S.l.:
s.n.], 2012. p. 221–223.
AR
BOULANGER, J.-L.; DAO, V. Q. Requirements engineering in a model-based methodology for embedded automotive software. In: Research, Innovation and Vision for the Future, 2008. RIVF 2008.
IEEE International Conference on. [S.l.: s.n.], 2008. p. 263–268.
AR
YU, W.; SMITH, S. Reusability of fea software: A program family approach. In: Proceedings of the
2009 ICSE Workshop on Software Engineering for Computational Science and Engineering. Washington, DC, USA: IEEE Computer Society, 2009. (SECSE ’09), p. 43–50. ISBN 978-1-4244-3737-5.
Disponível em: <http://dx.doi.org/10.1109- /SECSE.2009.5069161>.
AR
HINDLE, A. et al. Relating requirements to implementation via topic analysis: Do topics extracted
from requirements make sense to managers and developers? In: Software Maintenance (ICSM), 2012
28th IEEE International Conference on. [S.l.: s.n.], 2012. p. 243–252. ISSN 1063-6773.
AR
PERSEIL, I.; PAUTET, L. Co-modeling methodology designed for rt architecture models integration.
In: Proceedings of the 12th IEEE International Conference on Engineering Complex Computer Systems. Washington, DC, USA: IEEE Computer Society, 2007. (ICECCS ’07), p. 371–376. ISBN 07695-2895-3. Disponível em: <http://dx.doi.org/10.1109/ICECCS.2007.19>.
AR
SCHAFER, H.; PROETZSCH, M.; BERNS, K. Action/perception-oriented robot software design: An
application in off-road terrain. In: Control, Automation, Robotics and Vision, 2008. ICARCV 2008.
10th International Conference on. [S.l.: s.n.], 2008. p. 223–228.
AR
BURGE, J. E.; BROWN, D. C. Seurat: integrated rationale management. In: Proceedings of the 30th
international conference on Software engineering. New York, NY, USA: ACM, 2008. (ICSE ’08), p.
835–838. ISBN 978-1-60558-079-1. Disponível em: <http://doi.acm.org/10.1145/1368088.1368215>.
AR
STIREWALT, R. E. K.; DILLON, L.; KRAEMER, E. The inference validity problem in legal discovery. In: Software Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International
Conference on. [S.l.: s.n.], 2009. p. 303–306.
AR
LUO, M. Common business components and services toward more agile and flexible industry solutions
and assets. In: Congress on Services Part II, 2008. SERVICES-2. IEEE. [S.l.: s.n.], 2008. p. 11–12.
AR
FILHO, R. S. S. et al. Supporting concern-based regression testing and prioritization in
a model-driven environment. In: Proceedings of the 2010 IEEE 34th Annual Computer
Software and Applications Conference Workshops. Washington, DC, USA: IEEE Computer Society, 2010. (COMPSACW ’10), p. 323–328. ISBN 978-0-7695-4105-1. Disponível em:
<http://dx.doi.org/10.1109/COMPSACW.2010.63>.
AR
KUANG, H. et al. Do data dependencies in source code complement call dependencies for understanding requirements traceability? In: Software Maintenance (ICSM), 2012 28th IEEE International
Conference on. [S.l.: s.n.], 2012. p. 181–190. ISSN 1063-6773. traceability?
AR
2a análise
Continua na próxima página
164
Referência
1a análise
HILL, J.; VICTOR, D. The product engineering class in the software safety risk taxonomy for building
safety-critical systems. In: Proceedings of the 19th Australian Conference on Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2008. (ASWEC ’08), p. 617–626. ISBN 978-0-76953100-7. Disponível em: <http://dl.acm.org/citation.cfm?id=1395083.1395715>.
AR
KAIYA, H. et al. Exploring how to support software revision in software non-intensive projects using
existing techniques. In: Computer Software and Applications Conference Workshops (COMPSACW),
2011 IEEE 35th Annual. [S.l.: s.n.], 2011. p. 327–334.
AR
HONG, W. Architecture-centric software process for pattern based software reuse. In: Proceedings
of the 2009 WRI World Congress on Software Engineering - Volume 04. Washington, DC, USA:
IEEE Computer Society, 2009. (WCSE ’09), p. 95–99. ISBN 978-0-7695-3570-8. Disponível em:
<http://dx.doi.org/10.1109/WCSE.2009.188>.
AR
BEHNAM, S. A.; AMYOT, D.; MUSSBACHER, G. Towards a pattern-based framework for goaldriven business process modeling. In: Proceedings of the 2010 Eighth ACIS International Conference on Software Engineering Research, Management and Applications. Washington, DC, USA:
IEEE Computer Society, 2010. (SERA ’10), p. 137–145. ISBN 978-0-7695-4075-7. Disponível em:
<http://dx.doi.org/10.1109/SERA- .2010.27>.
AR
EGYED, A.; GRAF, F.; GRUNBACHER, P. Effort and quality of recovering requirements-to-code traces: Two exploratory experiments. In: Proceedings of the 2010 18th IEEE International Requirements
Engineering Conference. Washington, DC, USA: IEEE Computer Society, 2010. (RE ’10), p. 221–230.
ISBN 978-0-7695-4162-4. Disponível em: <http://dx.doi.org/10.1109/RE.2010.34>.
AR
TAN, L.; LIN, Y.; YE, H. Modeling quality attributes in software product line architecture. In: Engineering and Technology (S-CET), 2012 Spring Congress on. [S.l.: s.n.], 2012. p. 1–5.
AR
GOTEL, O. C. Z.; MORRIS, S. J. Case-based stories for traceability education and training. In: Requirements Engineering Education and Training (REET), 2012 IEEE 7th International Workshop on. [S.l.:
s.n.], 2012. p. 1–8.
AR
ALI, B. S.; KASIRUN, Z. M. Developing tool for crosscutting concern identification using nlp. In:
Information Technology, 2008. ITSim 2008. International Symposium on. [S.l.: s.n.], 2008. v. 3, p.
1–8.
AR
GROHER, I.; WEINREICH, R. Integrating variability management and software architecture. In: Software Architecture (WICSA) and European Conference on Software Architecture (ECSA), 2012 Joint
Working IEEE/IFIP Conference on. [S.l.: s.n.], 2012. p. 262–266.
AR
POST, H. et al. Linking functional requirements and software verification. In: Requirements Engineering Conference, 2009. RE ’09. 17th IEEE International. [S.l.: s.n.], 2009. p. 295–302. ISSN 1090705X.
AR
BOULANGER, J.-L.; DAO, V. Q. Experiences from a model-based methodology for embedded electronic software in automobile. In: Information and Communication Technologies: From Theory to Applications, 2008. ICTTA 2008. 3rd International Conference on. [S.l.: s.n.], 2008. p. 1–6.
AR
ALI, B. S.; KASIRUN, Z. M. A review on approaches for identifying crosscutting concerns. In: Proceedings of the 2008 International Conference on Advanced Computer Theory and Engineering. Washington, DC, USA: IEEE Computer Society, 2008. p. 855–859. ISBN 978-0-7695-3489-3. Disponível em:
<http://dx.doi.org/10.1109/ICACTE.2008.13>.
AR
CHAKRABORTY, S.; DEHLINGER, J. Applying the grounded theory method to derive enterprise
system requirements. In: Proceedings of the 2009 10th ACIS International Conference on Software Engineering, Artificial Intelligences, Networking and Parallel/Distributed Computing. Washington, DC,
USA: IEEE Computer Society, 2009. (SNPD ’09), p. 333–338. ISBN 978-0-7695-3642-2. Disponível
em: <http://dx.doi.org/10.1109/SNPD.2009.102>.
AR
MERTEN, T.; SCHAFER, T.; BURSNER, S. Using re knowledge to assist automatically during requirement specification. In: Requirements Engineering Education and Training (REET), 2012 IEEE 7th
International Workshop on. [S.l.: s.n.], 2012. p. 9–13.
AR
HAGAL, M.; FAZZANI, F. A use case map as a visual approach to reduce the degree of inconsistency.
In: Computer Systems and Industrial Informatics (ICCSII), 2012 International Conference on. [S.l.:
s.n.], 2012. p. 1–4.
AR
2a análise
Continua na próxima página
165
Referência
1a análise
CLELAND-HUANG, J.; HABRAT, R. Visual support in automated tracing. In: Proceedings of
the Second International Workshop on Requirements Engineering Visualization. Washington, DC,
USA: IEEE Computer Society, 2007. (REV 07), p. 4-. ISBN 0-7695-3248-9. Disponível em:
<http://dx.doi.org/10.1109/REV.2007.7>.
AR
ZHU, L.; GORTON, I. Uml profiles for design decisions and non-functional requirements. In: Proceedings of the Second Workshop on SHAring and Reusing architectural Knowledge Architecture,
Rationale, and Design Intent. Washington, DC, USA: IEEE Computer Society, 2007. (SHARK-ADI
’07), p. 8–. ISBN 0-7695-2951-8. Disponível em: <http://dx.doi.org/10.1109/SHARK-ADI.2007.14>.
AR
ALJER, A.; DEVIENNE, P. Formal fault tolerant architecture. In: Proceedings of the 2010 Third International Conference on Communication Theory, Reliability, and Quality of Service. Washington, DC,
USA: IEEE Computer Society, 2010. (CTRQ 10), P. 73-78. ISBN 978-0-7695-4070-2. Disponível em
<http://dx.doi.org/10.1109/CTRQ.2010.20>.
AR
LU, C.-W. et al. A model-based object-oriented approach to requirement engineering (more). In: Proceedings of the 31st Annual International Computer Software and Applications Conference - Volume 01.
Washington, DC, USA: IEEE Computer Society, 2007. (COMPSAC 07), p. 153–156. ISBN 0-76952870-8. Disponível em: <http://dx.doi.org/10.1109/COMPSAC.2007.30>.
AR
SAFANA, A. I.; IBRAHIM, S. Implementing software test management using spirateam tool. In: Proceedings of the 2010 Fifth International Conference on Software Engineering Advances. Washington,
DC, USA: IEEE Computer Society, 2010. (ICSEA ’10), p. 447–452. ISBN 978-0-7695-4144-0. Disponível em: <http://dx.doi.org/10.1109/ICSEA- .2010.76>.
AR
HASSAN, R. et al. Goal-oriented, b-based formal derivation of security design specifications from
security requirements. In: Availability, Reliability and Security, 2008. ARES 08. Third International
Conference on. [S.l.: s.n.], 2008. p. 1443–1450.
AR
ZIMMERMANN, O. et al. Combining pattern languages and reusable architectural decision models into a comprehensive and comprehensible design method. In: Proceedings of the Seventh
Working IEEE/IFIP Conference on Software Architecture (WICSA 2008). Washington, DC, USA:
IEEE Computer Society, 2008. (WICSA ’08), p. 157-166. ISBN 978-0-7695-3092-5. Disponível em:
<http://dx.doi.org/10.1109/WICSA.2008.19>.
AR
CHANG, C.-H.; LU, C.-W.; CHU, W. C. Improving software integration from requirement process with a model-based object-oriented approach. In: Proceedings of the 2008 Second International Conference on Secure System Integration and Reliability Improvement. Washington, DC, USA:
IEEE Computer Society, 2008. (SSIRI ’08), p. 175–176. ISBN 978-0-7695-3266-0. Disponível em:
<http://dx.doi.org/10.1109/SSIRI.2008.39>.
AR
ALI, B. S.; KASIRUN, Z. M. 3ci: A tool for crosscutting concern identification. In Proceedings of
the 2008 International Conference on Computational Intelligence for Modelling Control and Automation. Washington, DC, USA: IEEE Computer Society, 2008. p. 351–355. ISBN 978-0-7695-3514-2.
Disponível em: <http://dx.doi.org/10.1109- /CIMCA.2008.77>.
AR
HAYES, J. H.; ANTONIOL, G.; GUÉHÉNEUC, Y.-G. Prereqir: Recovering pre- requirements via cluster analysis. In: Proceedings of the 2008 15th Working Conference on Reverse Engineering. Washington, DC, USA: IEEE Computer Society, 2008. (WCRE ’08), p. 165–174. ISBN 978-0-7695-3429-9.
Disponível em: <http://dx.doi.org/10.1109- /WCRE.2008.36>.
AR
WEBER-JAHNKE, J. H.; ONABAJO, A. Finding defects in natural language confidentiality requirements. In: Proceedings of the 2009 17th IEEE International Requirements Engineering Conference,
RE. Washington, DC, USA: IEEE Computer Society, 2009. (RE ’09), p. 213–222. ISBN 978-0-76953761-0. Disponível em: <http://dx.doi.org/10.1109/RE.2009.41>.
AR
SALEM, Y.; HASSAN, R. Requirement-based test case generation and prioritization. In: Computer
Engineering Conference (ICENCO), 2010 International. [S.l.: s.n.], 2010. p. 152–157.
AR
MELLADO, D.; FERNANDEZ-MEDINA, E.; PIATTINI, M. IDEAS09: Applying a security domain
requirements engineering process for software product lines. Latin America Transactions, IEEE (Revista IEEE America Latina), v. 6, n. 3, p. 298–305, 2008. ISSN 1548-0992.
AR
FRASER, G.; AMMANN, P. Reachability and propagation for LTL requirements testing. In: Proceedings of the 2008 The Eighth International Conference on Quality Software. Washington, DC, USA:
IEEE Computer Society, 2008. (QSIC ’08), p. 189–198. ISBN 978-0-7695-3312-4. Disponível em:
<http://dx.doi.org/10.1109/QSIC.2008.21>.
AR
2a análise
Continua na próxima página
166
Referência
1a análise
ASUNDI, S.; FITZ-COY, N. Cubesat mission design based on a systems engineering approach. In:
Aerospace Conference, 2013 IEEE. [S.l.: s.n.], 2013. p. 1–9. ISSN 1095-323X.
AR
ARNOLD, D.; CORRIVEAU, J.-P.; SHI, W. Scenario-based validation: Beyond the user requirements
notation. In: Proceedings of the 2010 21st Australian Software Engineering Conference. Washington,
DC, USA: IEEE Computer Society, 2010. (ASWEC ’10), p. 75–84. ISBN 978-0-7695-4006-1. Disponível em: <http://dx.doi.org/10.1109/ASWEC- .2010.29>.
AR
ZHENG, X.; LIU, X.; LIU, S. Use case and non-functional scenario template-based approach to identify aspects. In: Proceedings of the 2010 Second International Conference on Computer Engineering
and Applications - Volume 02. Washington, DC, USA: IEEE Computer Society, 2010. (ICCEA ’10),
p. 89–93. ISBN 978-0-7695-3982-9. Disponível em: <http://dx.doi.org/10.1109/ICCEA.2010.174>.
AR
HELMING, J. et al. Towards a unified requirements modeling language. In: Requirements Engineering
Visualization (REV), 2010 Fifth International Workshop on. [S.l.: s.n.], 2010. p. 53–57. ISSN 21570256.
AR
ABUFARDEH, S.; MAGEL, K. Software internationalization: Crosscutting concerns across the development lifecycle. In: Proceedings of the 2009 International Conference on New Trends in Information
and Service Science. Washington, DC, USA: IEEE Computer Society, 2009. (NISS ’09), p. 447–450.
ISBN 978-0-7695-3687-3. Disponível em: <http://dx.doi.org/10.1109/NISS.2009.202>.
AR
RAUF, R.; ANTKIEWICZ, M.; CZARNECKI, K. Logical structure extraction from software requirements documents. In: Requirements Engineering Conference (RE), 2011 19th IEEE International. [S.l.:
s.n.], 2011. p. 101–110. ISSN 1090-705X.
AR
HAUSE, M. C.; THOM, F. An integrated mda approach with sysml and uml. In Proceedings of the
13th IEEE International Conference on on Engineering of Complex Computer Systems. Washington,
DC, USA: IEEE Computer Society, 2008. (ICECCS ’08), p. 249–254. ISBN 978-0-7695-3139-7. Disponível em: <http://dx.doi.org/10.1109- /ICECCS.2008.21>.
AR
ABBORS, F.; TRUSCAN, D. Approaching performance testing from a model-based testing perspective. In: Proceedings of the 2010 Second International Conference on Advances in System Testing and
Validation Lifecycle. Washington, DC, USA: IEEE Computer Society, 2010. (VALID ’10), p. 125–128.
ISBN 978-0-7695-4146-4. Disponível em: <http://dx.doi.org/10.1109/VALID.2010.22>.
AR
STANBRIDGE, C. Retrospective requirement analysis using code coverage of gui driven system tests.
In: Proceedings of the 2010 18th IEEE International Requirements Engineering Conference. Washington, DC, USA: IEEE Computer Society, 2010. (RE ’10), p. 411–412. ISBN 978-0-7695-4162-4. Disponível em: <http://dx.doi.org/10.1109- /RE.2010.64>.
AR
HELMING, J. et al. Integrating system modeling with project management - a case study. In: Proceedings of the 2009 33rd Annual IEEE International Computer Software and Applications Conference
- Volume 01. Washington, DC, USA: IEEE Computer Society, 2009. (COMPSAC ’09), p. 571–578.
ISBN 978-0-7695-3726-9. Disponível em: <http://dx.doi.org/10.1109/COMPSAC.2009.198>.
AR
BOILY, P.; HARRISON, N. A simulation system of systems to assess military aircraft protection. In:
Systems Conference (SysCon), 2012 IEEE International. [S.l.: s.n.], 2012. p. 1–6.
AR
WEBER-JAHNKE, J. H.; ONABAJO, A. Mining and analysing security goal models in health information systems. In: Proceedings of the 2009 ICSE Workshop on Software Engineering in Health Care.
Washington, DC, USA: IEEE Computer Society, 2009. (SEHC ’09), p. 42–52. ISBN 978-1-4244-37399. Disponível em: <http://dx.doi.org/10.1109/SEHC.2009.5069605>.
AR
KHERRAF, S.; LEFEBVRE, E.; SURYN, W. Transformation from cim to pim using patterns and archetypes. In: Proceedings of the 19th Australian Conference on Software Engineering. Washington,
DC, USA: IEEE Computer Society, 2008. (ASWEC ’08), p. 338–346. ISBN 978-0-7695-3100-7. Disponível em: <http://dl.acm.org/citation- .cfm?id=1395083.1395684>.
AR
BEN-EL-KEZADRI, R.; KAMOUN, F. A flexible channel access model for wireless network interface
cards. In: Communication Systems Software and Middleware and Workshops, 2008. COMSWARE
2008. 3rd International Conference on. [S.l.: s.n.], 2008. p. 650–656.
AR
DENNEY, E.; FISCHER, B. A verification-driven approach to traceability and documentation for autogenerated mathematical software. In: Proceedings of the 2009 IEEE/ACM International Conference on
Automated Software Engineering. Washington, DC, USA: IEEE Computer Society, 2009. (ASE ’09),
p. 560–564. ISBN 978-0-7695-3891-4. Disponível em: <http://dx.doi.org/10.1109/ASE.2009.71>.
AR
2a análise
Continua na próxima página
167
Referência
1a análise
ZHU, Y. et al. An MDE based approach for generating software architecture models from formal specifications. In: Proceedings of the 2010 10th International Conference on Quality Software. Washington,
DC, USA: IEEE Computer Society, 2010. (QSIC ’10), p. 373–376. ISBN 978-0-7695-4131-0. Disponível em: <http://dx.doi.org/10.1109/QSIC.2010.13>.
AR
RODRIGUEZ, L. et al. Improving the quality of agent-based systems: Integration of requirements
modeling into gaia. In: Proceedings of the 2009 Ninth International Conference on Quality Software.
Washington, DC, USA: IEEE Computer Society, 2009. (QSIC ’09), p. 278–283. ISBN 978-0-76953828-0. Disponível em: <http://dx.doi.org/10- .1109/QSIC.2009.43>.
AR
KHATCHADOURIAN, R.; RASHID, A. Rejuvenate pointcut: A tool for pointcut expression recovery
in evolving aspect-oriented software. In: Source Code Analysis and Manipulation, 2008 Eighth IEEE
International Working Conference on. [S.l.: s.n.], 2008. p. 261–262.
AR
SARABURA, M.; BOWDEN, P. Solving requirements management challenges in product line development. In: Proceedings of the 2008 12th International Software Product Line Conference. Washington, DC, USA: IEEE Computer Society, 2008. (SPLC ’08), p. 352–. ISBN 978-0-7695-3303-2. Disponível em: <http://dx.doi.org/10.1109/SPLC.2008.27>.
AR
HAINAUT, J.-L. Legacy and future of data reverse engineering. In: Reverse Engineering, 2009. 16th
Working Conference on. [S.l.: s.n.], 2009. p. 4–4. ISSN 1095-1350.
AR
ISLAM, M. et al. MOTCP: A tool for the prioritization of test cases based on a sorting genetic algorithm and latent semantic indexing. In: Software Maintenance (ICSM), 2012 28th IEEE International
Conference on. [S.l.: s.n.], 2012. p. 654–657. ISSN 1063-6773. Indexing
AR
OH, Y. et al. Extended architecture analysis description language for software product line
approach in embedded systems. In: Proceedings of the 5th IEEE/ACM International Conference on Formal Methods and Models for Codesign. Washington, DC, USA: IEEE Computer Society, 2007. (MEMOCODE ’07), p. 87–88. ISBN 1-4244-1050-9. Disponível em:
<http://dx.doi.org/10.1109/MEMCOD.2007.371243>. Systems
AR
CUI-YE, S.; CHENG-LIE, D.; GANG, L. Formal interface-component based software analysis and design. In: Computational Intelligence and Software Engineering (CiSE), 2010 International Conference
on. [S.l.: s.n.], 2010. p. 1–4.
AR
TOWHIDNEJAD, M. Software Configuration Management for the Certified Software Development
Associate (CSDA) - Developed exclusively for IEEE Elearning Library. In: Early Aspects at ICSE:
Workshops in Aspect-Oriented Requirements Engineering and Architecture Design - Cover. [S.l.: s.n.],
2012.
AR
OMAR, F.; IBRAHIM, S. Designing Test Coverage for Grey Box Analysis. In: Proceedings
of the 2010 10th International Conference on Quality Software. Washington, DC, USA: IEEE
Computer Society, 2010. (QSIC ’10), p. 353–356. ISBN 978-0-7695-4131-0. Disponível em:
<http://dx.doi.org/10.1109/QSIC.2010.44>.
AR
NEWGARD, B.; HOFFMAN, C. Using multiple processors in a single reconfigurable fabric for highassurance applications. In: Hardware-Oriented Security and Trust (HOST), 2010 IEEE International
Symposium on. [S.l.: s.n.], 2010. p. 25–29.
AR
UWANO, H.; MONDEN, A.; MATSUMOTO, K.-i. Dresrem 2: An Analysis System for MultiDocument Software Review Using Reviewers’Eye Movements. In: Proceedings of the 2008 The
Third International Conference on Software Engineering Advances. Washington, DC, USA: IEEE
Computer Society, 2008. (ICSEA ’08), p. 177–183. ISBN 978-0-7695-3372-8. Disponível em:
<http://dx.doi.org/10.1109/ICSEA.2008.49>.
AR
YU, Y.; JURJENS, J.; SCHRECK, J. Tools for traceability in secure software development. In: Proceedings of the 2008 23rd IEEE/ACM International Conference on Automated Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2008. (ASE ’08), p. 503–504. ISBN 978-1-42442187-9. Disponível em: <http://dx.doi.org/10.1109/ASE.2008.92>.
AR
TRAULSEN, C.; AMENDE, T.; HANXLEDEN, R. von. Compiling synccharts to synchronous c. In:
Design, Automation Test in Europe Conference Exhibition (DATE), 2011. [S.l.: s.n.], 2011. p. 1–4.
ISSN 1530-1591.
AR
2a análise
Continua na próxima página
168
Referência
1a análise
2a análise
HONG, Y.; KIM, M.; LEE, S.-W. Requirements Management Tool with Evolving Traceability for
Heterogeneous Artifacts in the Entire Life Cycle. In: Proceedings of the 2010 Eighth ACIS International Conference on Software Engineering Research, Management and Applications. Washington, DC,
USA: IEEE Computer Society, 2010. (SERA ’10), p. 248–255. ISBN 978-0-7695-4075-7. Disponível
em: <http://dx.doi.org/10.1109/SERA- .2010.39>.
AS
Selecionado
MÄDER, P.; GOTEL, O.; PHILIPPOW, I. Rule-Based Maintenance of Post-Requirements Traceability
Relations. In: Proceedings of the 2008 16th IEEE International Requirements Engineering Conference.
Washington, DC, USA: IEEE Computer Society, 2008. (RE ’08), p. 23–32. ISBN 978-0-7695-3309-4.
Disponível em: <http://dx.doi.org/10.1109/RE- .2008.24>.
AS
2
SHUKLA, V.; AURIOL, G.; BARON, C. Integrated requirement traceability, multiview modeling, and
decision-making: A systems engineering approach for integrating processes and product. In: Systems
Conference (SysCon), 2012 IEEE International. [S.l.: s.n.], 2012. p. 1–5.
AS
3
SALAY, R.; CHECHIK, M.; HORKOFF, J. Managing Requirements Uncertainty with Partial Models.
In: Requirements Engineering Conference (RE), 2012 20th IEEE International. [S.l.: s.n.], 2012. p.
1–10. ISSN 1090-750X.
AS
3
ROCHIMAH, S. et al. An Evaluation of Traceability Approaches to Support Software Evolution. In:
Proceedings of the International Conference on Software Engineering Advances. Washington, DC,
USA: IEEE Computer Society, 2007. (ICSEA ’07), p. 19–. ISBN 0-7695-2937-2. Disponível em:
<http://dx.doi.org/10.1109/ICSEA.2007.17>.
AS
1
DUBOIS, H.; PERALDI-FRATI, M.-A.; LAKHAL, F. A Model for Requirements Traceability in a Heterogeneous Model-Based Design Process: Application to Automotive Embedded Systems. In: Proceedings of the 2010 15th IEEE International Conference on Engineering of Complex Computer Systems.
Washington, DC, USA: IEEE Computer Society, 2010. (ICECCS ’10), p. 233–242. ISBN 978-0-76954015-3. Disponível em: <http://dx.doi.org/10.1109/ICECCS.2010.2>.
AS
Selecionado
ESPINOZA, A.; DÍAZ, J. A Traceability Semantics Approach for Supporting Product Value Analysis. In: Proceedings of the 11th International Conference on Product Focused Software. New York,
NY, USA: ACM, 2010. (PROFES ’10), p. 102–104. ISBN 978-1-4503-0281-4. Disponível em:
<http://doi.acm.org/10.1145/1961258.1961282>.
AS
1
WIEDERSEINER, C.; GAROUSI, V.; SMITH, M. Tool Support for Automated Traceability of
Test/Code Artifacts in Embedded Software Systems. In: Trust, Security and Privacy in Computing
and Communications (TrustCom), 2011 IEEE 10th International Conference on. [S.l.: s.n.], 2011. p.
1109–1117.
AS
3
DI, F.; ZHANG, M. An Improving Approach for Recovering Requirements-to-Design Traceability
Links. In: Computational Intelligence and Software Engineering, 2009. CiSE 2009. International Conference on. [S.l.: s.n.], 2009. p. 1–6.
AS
2
KASSAB, M.; ORMANDJIEVA, O.; DANEVA, M. Relational-model based change management for
non-functional requirements: Approach and experiment. In: Research Challenges in Information Science (RCIS), 2011 Fifth International Conference on. [S.l.: s.n.], 2011. p. 1–9. ISSN 2151-1349.
AS
3
REGAN, G. et al. The Barriers to Traceability and their Potential Solutions: Towards a Reference
Framework. In: Software Engineering and Advanced Applications (SEAA), 2012 38th EUROMICRO
Conference on. [S.l.: s.n.], 2012. p. 319–322.
AS
1
NOLL, R. P.; RIBEIRO, M. B. Ontological Traceability over the Unified Process. In: Proceedings
of the 14th Annual IEEE International Conference and Workshops on the Engineering of ComputerBased Systems. Washington, DC, USA: IEEE Computer Society, 2007. (ECBS ’07), p. 249–255. ISBN
0-7695-2772-8. Disponível em: <http://dx.doi.org/10.1109/ECBS.2007.58>.
AS
1
SENGUPTA, S.; KANJILAL, A.; BHATTACHARYA, S. Requirement Traceability in Software Development Process: An Empirical Approach. In: Proceedings of the 2008 The 19th
IEEE/IFIP International Symposium on Rapid System Prototyping. Washington, DC, USA: IEEE
Computer Society, 2008. (RSP ’08), p. 105–111. ISBN 978-0-7695-3180-9. Disponível em:
<http://dx.doi.org/10.1109/RSP.2008.14>.
AS
1
ZIFTCI, C.; KRUEGER, I. Tracing requirements to tests with high precision and recall. In: Proceedings of the 2011 26th IEEE/ACM International Conference on Automated Software Engineering.
Washington, DC, USA: IEEE Computer Society, 2011. (ASE ’11), p. 472–475. ISBN 978-1-45771638-6. Disponível em: <http://dx.doi.org/10.1109/ASE- .2011.6100102>.
AS
Selecionado
Continua na próxima página
169
Referência
1a análise
2a análise
DEKHTYAR, A. et al. Technique integration for requirements assessment. In: Requirements Engineering Conference, 2007. RE ’07. 15th IEEE International. [S.l.: s.n.], 2007. p. 141–150. ISSN 1090705X.
AS
1
KARNAVEL, K.; SANTHOSHKUMAR, J. Automated software testing for application maintenance
by using bee colony optimization algorithms (BCO). In: Information Communication and Embedded
Systems (ICICES), 2013 International Conference on. [S.l.: s.n.], 2013. p. 327–330.
AS
3
MAHMOUD, A.; NIU, N. Using Semantics-Enabled Information Retrieval in Requirements Tracing: An Ongoing Experimental Investigation. In: Proceedings of the 2010 IEEE 34th Annual Computer Software and Applications Conference. Washington, DC, USA: IEEE Computer Society, 2010. (COMPSAC ’10), p. 246–247. ISBN 978-0-7695-4085-6. Disponível em:
<http://dx.doi.org/10.1109/COMPSAC.2010.29>.
AS
1
SULTANOV, H. Requirements tracing: discovering related documents through artificial pheromones
and term proximity. In: Proceedings of the 33rd International Conference on Software Engineering.
New York, NY, USA: ACM, 2011. (ICSE ’11), p. 1173–1175. ISBN 978-1-4503-0445-0. Disponível
em: <http://doi.acm.org/10.1145/1985793.1986033>.
AS
1
KONG, L.; YUAN, T. Extension Features-Driven Use Case Model for Requirement Traceability. In:
Computer Science Education, 2009. ICCSE ’09. 4th International Conference on. [S.l.: s.n.], 2009. p.
866–870.
AS
2
CLELAND-HUANG, J. et al. Breaking the big-bang practice of traceability: Pushing timely trace recommendations to project stakeholders. In: Requirements Engineering Conference (RE), 2012 20th
IEEE International. [S.l.: s.n.], 2012. p. 231–240. ISSN 1090-750X.
AS
Selecionado
KASSAB, M.; ORMANDJIEVA, O.; DANEVA, M. A Traceability Metamodel for Change Management of Non-functional Requirements. In: Proceedings of the 2008 Sixth International Conference on Software Engineering Research, Management and Applications. Washington, DC, USA:
IEEE Computer Society, 2008. (SERA ’08), p. 245–254. ISBN 978-0-7695-3302-5. Disponível em:
<http://dx.doi.org/10.1109/SERA- .2008.37>.
AS
1
CZAUDERNA, A. et al. Just-in-time traceability for mechatronics systems. In:Requirements Engineering for Systems, Services and Systems-of-Systems (RES4), 2012 IEEE Second Workshop on. [S.l.:
s.n.], 2012. p. 1–9.
AS
2
GUO, Y. et al. An Ontology Based Improved Software Requirement Traceability Matrix. In: Proceedings of the 2009 Second International Symposium on Knowledge Acquisition and Modeling - Volume
01. Washington, DC, USA: IEEE Computer Society, 2009. (KAM ’09), p. 160–163. ISBN 978-0-76953888-4. Disponível em: <http://dx.doi.org/10.1109/KAM.2009.63>.
AS
1
ASSAWAMEKIN, N. An Ontology-Based Approach for Multiperspective Requirements Traceability
between Analysis Models. In: Proceedings of the 2010 IEEE/ACIS 9th International Conference on
Computer and Information Science. Washington, DC, USA: IEEE Computer Society, 2010. (ICIS ’10),
p. 673–678. ISBN 978-0-7695-4147-1. Disponível em: <http://dx.doi.org/10.1109/ICIS.2010.43>.
AS
1
TUN, T. T. et al. A Framework for Developing Feature-Rich Software Systems. In:Proceedings of
the 2009 16th Annual IEEE International Conference and Workshop on the Engineering of Computer
Based Systems. Washington, DC, USA: IEEE Computer Society, 2009. (ECBS ’09), p. 206–214. ISBN
978-0-7695-3602-6. Disponível em: <http://dx.doi.org/10.1109/ECBS.2009.32>.
AS
3
BORG, M. In Vivo Evaluation of Large-Scale IR-Based Traceability Recovery. In: Proceedings of the
2011 15th European Conference on Software Maintenance and Reengineering. Washington, DC, USA:
IEEE Computer Society, 2011. (CSMR ’11), p. 365–368. ISBN 978-0-7695-4343-7. Disponível em:
<http://dx.doi.org/10.1109/CSMR.2011.54>.
AS
2
KASSAB, M.; ORMANDJIEVA, O.; DANEVA, M. A Metamodel for Tracing Non- Functional Requirements. In: Proceedings of the 2009 WRI World Congress on Computer Science and Information Engineering - Volume 07. Washington, DC, USA: IEEE Computer Society, 2009. (CSIE ’09), p. 687–694.
ISBN 978-0-7695-3507-4. Disponível em: <http://dx.doi.org/10.1109/CSIE.2009.946>.
AS
1
MOON, M. et al. A Metamodeling Approach to Tracing Variability between Requirements and Architecture in Software Product Lines. In: Proceedings of the 7th IEEE International Conference on Computer and Information Technology. Washington, DC, USA:
IEEE Computer Society, 2007. (CIT ’07), p. 927–933. ISBN 0-7695-2983-6. Disponível em:
<http://dl.acm.org/citation.cfm?id=1317531.1317997>.
AS
Selecionado
Continua na próxima página
170
Referência
1a análise
2a análise
CLELAND-HUANG, J.; HAYES, J. H.; DOMEL, J. M. Model-based traceability. In: Proceedings of
the 2009 ICSE Workshop on Traceability in Emerging Forms of Software Engineering. Washington,
DC, USA: IEEE Computer Society, 2009. (TEFSE ’09), p. 6–10. ISBN 978-1-4244-3741-2. Disponível
em: <http://dx.doi.org/10.1109/TEFSE- .2009.5069575>.
AS
Selecionado
GE, Y.; BAI, L. Probability-based safety related requirements change impact analysis. In: Computer
Science and Information Technology (ICCSIT), 2010 3rd IEEE International Conference on. [S.l.: s.n.],
2010. v. 1, p. 719–722.
AS
1
KAMALRUDIN, M. Automated Software Tool Support for Checking the Inconsistency of Requirements. In: Proceedings of the 2009 IEEE/ACM International Conference on Automated Software
Engineering. Washington, DC, USA: IEEE Computer Society, 2009. (ASE ’09), p. 693–697. ISBN
978-0-7695-3891-4. Disponível em: <http://dx.doi.org/10.1109/ASE.2009.38>.
AS
3
ASSAWAMEKIN, N.; SUNETNANTA, T.; PLUEMPITIWIRIYAWEJ, C. Resolving Multiperspective Requirements Traceability through Ontology Integration. In: Proceedings of the 2008
IEEE International Conference on Semantic Computing. Washington, DC, USA: IEEE Computer Society, 2008. (ICSC ’08), p. 362–369. ISBN 978-0-7695-3279-0. Disponível em:
<http://dx.doi.org/10.1109/ICSC.2008.13>.
AS
1
POOLEY, R.; WARREN, C. Reuse through requirements traceability. In: Proceedings of the 2008
The Third International Conference on Software Engineering Advances. Washington, DC, USA:
IEEE Computer Society, 2008. (ICSEA ’08), p. 65–70. ISBN 978-0-7695-3372-8. Disponível em:
<http://dx.doi.org/10.1109/ICSEA.2008.60>.
AS
3
CHARRADA, E. B.; KOZIOLEK, A.; GLINZ, M. Identifying outdated requirements based on source
code changes. In: Requirements Engineering Conference (RE), 2012 20th IEEE International. [S.l.:
s.n.], 2012. p. 61–70. ISSN 1090-750X.
AS
3
SEIBEL, A. From Software Traceability to Global Model Management and Back Again. In: Proceedings of the 2011 15th European Conference on Software Maintenance and Reengineering. Washington, DC, USA: IEEE Computer Society, 2011. (CSMR ’11), p. 381–384. ISBN 978-0-7695-4343-7.
Disponível em: <http://dx.doi.org/10.1109/CSMR- .2011.58>.
AS
1
BUCHGEHER, G.; WEINREICH, R. Automatic Tracing of Decisions to Architecture and Implementation. In: Software Architecture (WICSA), 2011 9th Working IEEE/IFIP Conference on. [S.l.: s.n.],
2011. p. 46–55.
AS
Selecionado
MCMILLAN, C.; POSHYVANYK, D.; REVELLE, M. Combining textual and structural analysis
of software artifacts for traceability link recovery. In: Proceedings of the 2009 ICSE Workshop
on Traceability in Emerging Forms of Software Engineering. Washington, DC, USA: IEEE
Computer Society, 2009. (TEFSE ’09), p. 41–48. ISBN 978-1-4244-3741-2. Disponível em:
<http://dx.doi.org/10.1109/TEFSE.2009.5069582>.
AS
2
FOCKEL, M.; HOLTMANN, J.; MEYER, J. Semi-automatic establishment and maintenance of valid
traceability in automotive development processes. In: Software Engineering for Embedded Systems
(SEES), 2012 2nd International Workshop on. [S.l.: s.n.], 2012. p. 37–43.
AS
3
TANG, A.; LIANG, P.; VLIET, H. van. Software Architecture Documentation: The Road Ahead. In:
Software Architecture (WICSA), 2011 9th Working IEEE/IFIP Conference on. [S.l.: s.n.], 2011. p.
252–255.
AS
1
GHANAM, Y.; MAURER, F. Extreme Product Line Engineering: Managing Variability and Traceability via Executable Specifications. In: Proceedings of the 2009 Agile Conference. Washington, DC,
USA: IEEE Computer Society, 2009. (AGILE ’09), p. 41–48. ISBN 978-0-7695-3768-9. Disponível
em: <http://dx.doi.org/10.1109/AGILE.2009.12>.
AS
3
SATYANANDA, T. K. et al. Identifying Traceability between Feature Model and Software Architecture in Software Product Line using Formal Concept Analysis. In: Proceedings of the The
2007 International Conference Computational Science and its Applications. Washington, DC, USA:
IEEE Computer Society, 2007. (ICCSA ’07), p. 380–388. ISBN 0-7695-2945-3. Disponível em:
<http://dx.doi.org/10.1109/ICCSA.2007.47>.
AS
Selecionado
HILL, J.; TILLEY, S. Creating Safety Requirements Traceability for Assuring and Recertifying Legacy
Safety-Critical Systems. In: Proceedings of the 2010 18th IEEE International Requirements Engineering Conference. Washington, DC, USA: IEEE Computer Society, 2010. (RE ’10), p. 297–302. ISBN
978-0-7695-4162-4. Disponível em: <http://dx.doi.org/10.1109/RE.2010.42>.
AS
3
Continua na próxima página
171
Referência
1a análise
2a análise
PIERCE, R.; JOHNSTON, M.; CLAUSS, R. Reverse engineering the software design of a safety related
atm system. In: System Safety, 2011 6th IET International Conference on. [S.l.: s.n.], 2011. p. 1–6.
AS
3
MERTEN, T.; JUPPNER, D.; DELATER, A. Improved representation of traceability links in requirements engineering knowledge using sunburst and netmap visualizations. In: Managing Requirements
Knowledge (MARK), 2011 Fourth International Workshop on. [S.l.: s.n.], 2011. p. 17–21.
AS
2
OMORONYIA, I. et al. Use Case to Source Code Traceability: The Developer Navigation View
Point. In: Proceedings of the 2009 17th IEEE International Requirements Engineering Conference,
RE. Washington, DC, USA: IEEE Computer Society, 2009. (RE ’09), p. 237–242. ISBN 978-0-76953761-0. Disponível em: <http://dx.doi.org/10- .1109/RE.2009.26>.
AS
3
EGYED, A.; BINDER, G.; GRUNBACHER, P. STRADA: A Tool for Scenario-Based Featureto-Code Trace Detection and Analysis. In: Companion to the proceedings of the 29th International Conference on Software Engineering. Washington, DC, USA: IEEE Computer Society, 2007. (ICSE COMPANION ’07), p. 41–42. ISBN 0-7695-2892-9. Disponível em:
<http://dx.doi.org/10.1109/ICSECOMPANION.2007.70>.
AS
Selecionado
ASGHAR, M. et al. Maintainability-Based Requirements Prioritization by Using Artifacts Traceability and Code Metrics. In: Software Maintenance and Reengineering (CSMR), 2013 17th European
Conference on. [S.l.: s.n.], 2013. p. 417–420. ISSN 1534-5351.
AS
3
CLELAND-HUANG, J.; MARRERO, W.; BERENBACH, B. Goal-Centric Traceability: Using Virtual Plumblines to Maintain Critical Systemic Qualities. IEEE Trans. Softw. Eng., IEEE Press,
Piscataway, NJ, USA, v. 34, n. 5, p. 685–699, set. 2008. ISSN 0098-5589. Disponível em:
<http://dx.doi.org/10.1109/TSE.2008.45>.
AS
Selecionado
HERZIG, K.; ZELLER, A. Mining the Jazz Repository: Challenges and Opportunities. In: Proceedings
of the 2009 6th IEEE International Working Conference on Mining Software Repositories. Washington, DC, USA: IEEE Computer Society, 2009. (MSR ’09), p. 159–162. ISBN 978-1-4244-3493-0.
Disponível em: <http://dx.doi.org/10.1109/MSR- .2009.5069495>.
AS
2
DEHLINGER, J. et al. DECIMAL and PLFaultCAT: From Product-Line Requirements to
Product-Line Member Software Fault Trees. In: Companion to the proceedings of the 29th
International Conference on Software Engineering. Washington, DC, USA: IEEE Computer
Society, 2007. (ICSE COMPANION ’07), p. 49–50. ISBN 0-7695-2892-9. Disponível em:
<http://dx.doi.org/10.1109/ICSECOMPANION.2007.29>.
AS
2
MADER, P.; GOTEL, O.; PHILIPPOW, I. Semi-automated Traceability Maintenance: An Architectural
Overview of Tracemaintainer. In: Software Engineering - Companion Volume, 2009. ICSE-Companion
2009. 31st International Conference on. [S.l.: s.n.], 2009. p. 425–426.
AS
Selecionado
ALI, N.; GUENEUC, Y.; ANTONIOL, G. Trustrace: Mining Software Repositories to Improve the
Accuracy of Requirement Traceability Links. Software Engineering, IEEE Transactions on, v. 39, n. 5,
p. 725–741, 2013. ISSN 0098-5589.
AS
1
SANCHEZ, P. et al. Introducing Safety Requirements Traceability Support in Model-Driven Development of Robotic Applications. Computers, IEEE Transactions on, v. 60, n. 8, p. 1059–1071, 2011. ISSN
0018-9340.
AS
Selecionado
TAUSCH, N.; PHILIPPSEN, M.; ADERSBERGER, J. TracQL: A Domain-Specific Language for Traceability Analysis. In: Software Architecture (WICSA) and European Conference on Software Architecture (ECSA), 2012 Joint Working IEEE/IFIP Conference on. [S.l.: s.n.], 2012. p. 320–324.
AS
1
PACI, F. et al. Managing Evolution by Orchestrating Requirements and Testing Engineering Processes.
In: Software Testing, Verification and Validation (ICST), 2012 IEEE Fifth International Conference on.
[S.l.: s.n.], 2012. p. 834–841.
AS
1
FILHO, A.; MENDONCA, M. de; CHAVEZ, C. von F. IDEAS06: Em Busca de Agilidade na Análise
de Impacto: O Artefato FIR. Latin America Transactions, IEEE (Revista IEEE America Latina), v. 6,
n. 3, p. 275–281, 2008. ISSN 1548-0992.
AS
1
YU, Y.; JURJENS, J.; MYLOPOULOS, J. Traceability for the maintenance of secure software. In: Software Maintenance, 2008. ICSM 2008. IEEE International Conference on. [S.l.: s.n.], 2008. p. 297–306.
ISSN 1063-6773.
AS
Selecionado
Continua na próxima página
172
Referência
1a análise
CHENGJUN, W. Architecture Driven Component Development for Top-Down Software Reuse. In:
Proceedings of the 2008 International Conference on Computer Science and Software Engineering Volume 05. Washington, DC, USA: IEEE Computer Society, 2008. (CSSE ’08), p. 1349–1352. ISBN
978-0-7695-3336-0. Disponível em: <http://dx.doi.org/10.1109/CSSE.2008.87>.
AU
2a análise
173
Quadro 44 – Trabalhos - Fonte Science Direct
Referência
1a análise
SCHMIDT, R. F. Chapter 9 - Software Requirements Management. In: Software Engineering. Boston: Morgan Kaufmann, 2013. p. 159-172. ISBN 978-0-12-407768-3. Disponível em:
<http://www.sciencedirect.com/science/article/pii/B9780124077683000094>.
AI
KRISHNAMOORTHI, R.; MARY, S. S. A. Factor oriented requirement coverage based system test case prioritization of new and regression test cases. Information and
Software Technology, v. 51, n. 4, p. 799–808, 2009. ISSN 0950-5849. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0950584908001286>.
AI
SCHMIDT, R. F. Chapter 3 - Software Architecture. In: Software Engineering. Boston: Morgan Kaufmann, 2013. p. 43-54. ISBN 978-0-12-407768-3. Disponível em:
<http://www.sciencedirect.com/science/article/pii/B9780124077683000033>.
AI
BAILEY, B.; MARTIN, G.; PIZIALI, A. Chapter 3 - evolution of ESL Development. In: ESL Design
and Verification. Burlington: Morgan Kaufmann, 2007. p. 35–80. ISBN 978-0-12-373551-5. Disponível em: <http://www.sciencedirect.com/science/article/pii/B9780123735515500666>.
AI
FRIEDENTHAL, S.; MOORE, A.; STEINER, R. Chapter 16 – Residential Security System
Example Using the Object-Oriented Systems Engineering Method. In: Practical Guide to SysML.
Burlington: Morgan Kaufmann, 2008. p. 397–486. ISBN 978-0-12-374379-4. Disponível em:
<http://www.sciencedirect.com/science/article/pii/B9780123743794000163>.
AI
FRIEDENTHAL, S.; MOORE, A.; STEINER, R. Chapter 17 – Residential Security System Example
Using the Object-Oriented Systems Engineering Method. In: A Practical Guide to SysML (Second
Edition). Second edition. Boston: Morgan Kaufmann, 2012. p. 431 – 519. ISBN 978-0-12-385206-9.
Disponível em: <http://www.sciencedirect.com/science/article/pii/B978012385206900017X>.
AI
MOROS, B. et al. Transforming and tracing reused requirements models to home automation models.
Information and Software Technology, v. 55, n. 6, p. 941–965, 2013. ISSN 0950-5849. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0950584912002388>.
AR
NIEMELÄ, E.; IMMONEN, A. Capturing Quality Requirements of Product Family Architecture. Information and Software Technology, v. 49, n. 11–12, p. 1107 – 1120, 2007. ISSN 0950-5849. Disponível em: <http://www.sciencedirect.com/science/article- /pii/S095058490600190X>.
AR
MELLADO, D.; FERNÁNDEZ-MEDINA, E.; PIATTINI, M. Towards security requirements management for software product lines: A security domain requirements engineering process. Computer Standards & Interfaces, v. 30, n. 6, p. 361–371, 2008. ISSN 0920-5489. <ce:title>Special
Issue: State of standards in the information systems security area</ce:title>. Disponível em:
<http://www.sciencedirect.com/science/article- /pii/S092054890800024X>.
AR
NICOLÁS, J.; TOVAL, A. On the Generation of Requirements Specifications from
Software Engineering Models: A Systematic Literature Review. Information and Software Technology, v. 51, n. 9, p. 1291–1307, 2009. ISSN 0950-5849. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0950584909000378>.
AR
STRASUNSKAS, D.; HAKKARAINEN, S. E. Domain Model-Driven Software Engineering: A Method for Discovery of Dependency Links. Information and Software Technology, v. 54, n. 11, p. 1239–1249, 2012. ISSN 0950-5849. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0950584912001073>.
AR
NISTALA, P.; KUMMAMURU, S.; NARAYANA, M. An Approach to Understand and Elicit Requirements using Systemic Models: Ensuring a Connect from Problem Context to Requirements. v. 16, n. 0, p. 786–795, 2013. ISSN 1877-0509.
<ce:title>2013 Conference on Systems Engineering Research</ce:title>. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S1877050913000835>.
AR
MCCLATCHEY, R. et al. Providing traceability for neuroimaging analyses. International Journal of Medical Informatics, v. 82, n. 9, p. 882–894, 2013. ISSN 1386-5056. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S1386505613001111>.
AR
CHOI, S.; PARK, S.; SUGUMARAN, V. A rule-based approach for estimating software development cost using function point and goal and scenario based requirements. Expert Systems with Applications, v. 39, n. 1, p. 406–418, 2012. ISSN 0957-4174. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0957417411009912>.
AR
2a análise
Continua na próxima página
174
Referência
1a análise
2a análise
ROSADO, D. G.; FERNÁNDEZ-MEDINA, E.; LÓPEZ, J. Security services architecture for secure
mobile grid systems. Journal of Systems Architecture, v. 57, n. 3, p. 240–258, 2011. ISSN 1383-7621.
<ce:title>Special Issue on Security and Dependability Assurance of Software Architectures</ce:title>.
Disponível em: <http://www.sciencedirect.com/science/article/pii/S1383762110000457>.
AR
BREAUX, T. D.; ANTÓN, A. I.; SPAFFORD, E. H. A distributed requirements management framework for legal compliance and accountability. Computers & Security, v. 28, n. 1–2, p. 8–17, 2009. ISSN 0167-4048. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0167404808000679>.
AR
XIAO, L. An adaptive security model using agent-oriented MDA. Information and Software Technology, v. 51, n. 5, p. 933–955, 2009. ISSN 0950-5849. <ce:title>SPECIAL ISSUE: Model-Driven Development for Secure Information Systems</ce:title>. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0950584908000748>.
AR
LAGO, P.; MUCCINI, H.; VLIET, H. van. A scoped approach to traceability management.
Journal of Systems and Software, v. 82, n. 1, p. 168 – 182, 2009. ISSN 0164-1212.
<ce:title>Special Issue: Software Performance - Modeling and Analysis</ce:title>. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0164121208002033>.
AS
1
VALDERAS, P.; PELECHANO, V. Introducing requirements traceability support
in model-driven development of web applications. Information and Software Technology, v. 51, n. 4, p. 749 – 768, 2009. ISSN 0950-5849. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0950584908001316>.
AS
3
NEJATI, S. et al. A sysml-based approach to traceability management and design slicing in support of
safety certification: Framework, tool support, and case studies. Information and Software Technology,
v. 54, n. 6, p. 569–590, 2012. ISSN 0950-5849. <ce:title>Special Section: Engineering Complex Software Systems through Multi-Agent Systems and Simulation</ce:title> <ce:subtitle>Special Section:
Engineering Complex Software Systems through Multi-Agent Systems and Simulation</ce:subtitle>.
Disponível em: <http://www.sciencedirect.com/science/article/pii/S095058491200016X>.
AS
Selecionado
DELGOSHAEI, P.; AUSTIN, M. Software Patterns for Traceability of Requirements to Finite State Machine Behavior. Procedia Computer Science, v. 8, n. 0, p. 214–219, 2012. ISSN
1877-0509. <ce:title>Conference on Systems Engineering Research</ce:title>. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S1877050912000464>.
AS
1
OMORONYIA, I.; SINDRE, G.; STALHANE, T. Exploring a bayesian and linear approach to requirements traceability. Information and Software Technology, v. 53, n.
8, p. 851–871, 2011. ISSN 0950-5849. <ce:title>Advances in functional size measurement and effort estimation - Extended best papers</ce:title>. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0950584911000590>.
AS
1
MÄDER,
P.;
GOTEL,
O.
Towards
automated
traceability
maintenance.
nal of Systems and Software, v. 85, n. 10, p. 2205–2227, 2012.
0164-1212.
<ce:title>Automated
Software
Evolution</ce:title>.
Disponível
<http://www.sciencedirect.com/science/article/pii/S0164121211002779>.
JourISSN
em:
AS
2
KIM, J.; PARK, S.; SUGUMARAN, V. DRAMA: A framework for domain requirements analysis and modeling architectures in software product lines. Journal of Systems and Software, v. 81, n. 1, p. 37–55, 2008. ISSN 0164-1212. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S016412120700088X>.
AS
3
LEE, J.-S. et al. Means-ends and whole-part traceability analysis of safety requirements. Journal of Systems and Software, v. 83, n. 9, p. 1612–1621, 2010.
ISSN
0164-1212.
<ce:title>Software
Dependability</ce:title>.
Disponível
em:
<http://www.sciencedirect.com/science/article/pii/S0164121209002143>.
AS
Selecionado
SMITH, S.; YU, W. A document driven methodology for developing a high quality parallel mesh
generation toolbox. Advances in Engineering Software, v. 40, n. 11, p. 1155–1167, 2009. ISSN 09659978. Disponível em: <http:/www.sciencedirect.com- /science/article/pii/S0965997809001306>.
AS
3
Continua na próxima página
175
Referência
1a análise
2a análise
WANG, X.; LAI, G.; LIU, C. Recovering Relationships between Documentation and Source Code
based on the Characteristics of Software Engineering. Electronic Notes in Theoretical Computer Science, v. 243, n. 0, p. 121–137, 2009. ISSN 1571-0661. <ce:title>Proceedings of the 2nd International
Workshop on Harnessing Theories for Tool Support in Software (TTSS 2008)</ce:title>. Disponível
em: <http://www.sciencedirect.com/science/article/pii/S157106610900231X>.
AS
1
ZHANG, H. et al. Investigating Dependencies in Software Requirements for Change Propagation Analysis. Information and Software Technology, n. 0, 2013. ISSN 0950-5849. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S095058491300147X>.
AS
3
176
Quadro 45 – Trabalhos - Fonte Springer
Referência
1a análise
conference (no reference) DropsBox: the Dresden Open Software Toolbox
AI
ETZKORN, L.; MENZIES, T. Special issue on information retrieval for program comprehension. Empirical Software Engineering, Springer US, v. 14, n. 1, p. 1–4, 2009. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-008-9097-1>.
AI
CLELAND-HUANG, J. Introduction to the RE’10 special issue Requirements Engineering in a multifaceted World. Requirements Engineering, Springer-Verlag, v. 16, n. 3, p. 161–162, 2011. ISSN 09473602. Disponível em: <http://dx.doi.org/10.1007/s00766-011-0130-3>.
AI
GRUNDY, J.; HOSKING, J. Guest editors introduction: special issue on innovative automated software
engineering tools. Automated Software Engineering, Springer US, v. 20, n. 2, p. 137–139, 2013. ISSN
0928-8910. Disponível em: <http://dx.doi.org/10.1007/s10515-013-0121-3>.
AI
FERNANDES, J. M.; DORI, D. Model-based approaches and frameworks for embedded software systems. Innovations in Systems and Software Engineering, Springer-Verlag, v. 8, n. 1, p. 1–2, 2012. ISSN
1614-5046. Disponível em: <http://dx.doi.org/10.1007- /s11334-011-0176-x>.
AI
SIM, S.; PENTA, M. Guest editors’ introduction: special issue from the 13th working conference on reverse engineering (WCRE2006). Empirical Software Engineering, Springer US, v. 13, n. 6, p. 597–600,
2008. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-008-9098-0>.
AI
PETRIU, D. Guest editorial to the special issue on MODELS 2010. Software & Systems Modeling, Springer Berlin Heidelberg, v. 12, n. 3, p. 451–452, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-013-0324-x>.
AI
HALL, R. Editorial: analysis in software engineering. Automated Software Engineering, Springer US,
v. 19, n. 3, p. 231–232, 2012. ISSN 0928-8910. Disponível em: <http://dx.doi.org/10.1007/s10515012-0101-z>.
AI
conference (no reference) The 9th annual state of SoSyM report
AI
HARRISON, R. In this issue. Software Quality Journal, Springer US, v. 21, n. 1, p. 1–2, 2013. ISSN
0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-012-9194-7>.
AI
FRANCE, R.; RUMPE, B.; SCHINDLER, M. SoSyM at 7 years. Software and Systems
Modeling, Springer-Verlag, v. 8, n. 1, p. 1-3, 2009. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-008-0107-y>.
AI
BOŠKOVI’Ć, M. et al. Guest editorial to the theme issue on non-functional system properties in domain
specific modeling languages. Software & Systems Modeling, Springer-Verlag, v. 10, n. 3, p. 283–286,
2011. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-010-0171-y>.
AI
TAMZALIT, D. et al. Introduction to the sosym theme issue on models and evolution. Software & Systems Modeling, Springer-Verlag, p. 1–3, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-013-0338-4>.
AI
UCHITEL, S.; EASTERBROOK, S. Guest editors’ introduction. Automated Software Engineering, Springer US, v. 15, n. 1, p. 1–2, 2008. ISSN 0928-8910. Disponível em:
<http://dx.doi.org/10.1007/s10515-007-0024-2>.
AI
RYAN, K. Introduction to the RE’09 special issue. Requirements Engineering, Springer-Verlag, v. 15,
n. 2, p. 139–140, 2010. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-010-01068>.
AI
BJARNASON, E. et al. Challenges and practices in aligning requirements with verification and validation: a case study of six companies. Empirical Software Engineering, Springer US, p. 1–47, 2013.
ISSN 1382-3256. Disponível em: <http://dx- .doi.org/10.1007/s10664-013-9263-y>.
AR
BORG, M.; RUNESON, P.; ARDÖ, A. Recovering from a decade: a systematic mapping of information
retrieval approaches to software traceability. Empirical Software Engineering, Springer US, p. 1–52,
2013. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-013-9255-y>.
AR
HOUMB, S. et al. Eliciting security requirements and tracing them to design: an integration of common
criteria, heuristics, and UMLsec. Requirements Engineering, Springer-Verlag, v. 15, n. 1, p. 63–93,
2010. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-009-0093-9>.
AR
LUCIA, A. D.; OLIVETO, R.; TORTORA, G. Assessing ir-based traceability recovery tools through
controlled experiments. Empirical Software Engineering, Springer US, v. 14, n. 1, p. 57–92, 2009.
ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-008-9090-8>.
AR
2a análise
Continua na próxima página
177
Referência
1a análise
SAIEDIAN, H.; KANNENBERG, A.; MOROZOV, S. A streamlined, cost-effective database approach
to manage requirements traceability. Software Quality Journal, Springer US, v. 21, n. 1, p. 23–38, 2013.
ISSN 0963-9314. Disponível em: <http://dx.doi- .org/10.1007/s11219-011-9166-3>.
AR
ZOU, X.; SETTIMI, R.; CLELAND-HUANG, J. Improving automated requirements trace retrieval: a
study of term-based enhancement methods. Empirical Software Engineering, Springer US, v. 15, n. 2,
p. 119–146, 2010. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-009-9114-z>.
AR
WENZEL, S. Unique identification of elements in evolving software models. Software
& Systems Modeling, Springer-Verlag, p. 1–33, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-012-0311-7>.
AR
WALDERHAUG, S. Design and Evaluation of the Modelhealth Toolchain for Continuity of Care Web
Services. Automated Software Engineering, Springer US, v. 20, n. 2, p. 185–235, 2013. ISSN 09288910. Disponível em: <http://dx.doi.org/10.1007/s10515-012-0115-6>.
AR
HAMMAD, M.; COLLARD, M.; MALETIC, J. Automatically identifying changes that impact codeto-design traceability during evolution. Software Quality Journal, Springer US, v. 19, n. 1, p. 35–64,
2011. ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-010-9103-x>.
AR
AGOURIDAS, V. et al. Advanced product planning: a comprehensive process for systemic definition
of new product requirements. Requirements Engineering, Springer-Verlag, v. 13, n. 1, p. 19–48, 2008.
ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-007-0055-z>.
AR
BRACE, W.; EKMAN, K. CORAMOD: a checklist-oriented model-based requirements analysis approach. Requirements Engineering, Springer-Verlag, p. 1–26, 2012. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-012-0154-3>.
AR
HOLBROOK, E. A. et al. A study of methods for textual satisfaction assessment. Empirical Software Engineering, Springer US, v. 18, n. 1, p. 139–176, 2013. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-012-9198-8>.
AR
PIRES, P. et al. Integrating ontologies, model driven, and CNL in a multi-viewed approach for requirements engineering. Requirements Engineering, Springer-Verlag, v. 16, n. 2, p. 133–160, 2011. ISSN
0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-011- 0116-1>.
AR
BERKOVICH, M. et al. A requirements data model for product service systems. Requirements Engineering, Springer-Verlag, p. 1–26, 2012. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-012-0164-1>.
AR
MOHAGHEGHI, P. et al. Where does model-driven engineering help? experiences from three industrial cases. Software & Systems Modeling, Springer Berlin Heidelberg, v. 12, n. 3, p. 619–639, 2013.
ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-011-0219-7>.
AR
JIANG, L. et al. A methodology for the selection of requirements engineering techniques. Software
& Systems Modeling, Springer-Verlag, v. 7, n. 3, p. 303–328, 2008. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-007-0055-y>.
AR
ZHANG, Z.; KAIPALA, J. A conceptual framework for component context specification and representation in a metacase environment. Software Quality Journal, Springer US, v. 17, n. 2, p. 151–175, 2009.
ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-008-9069-0>.
AR
WNUK, K.; HÖST, M.; REGNELL, B. Replication of an experiment on linguistic tool support for
consolidation of requirements from multiple sources. Empirical Software Engineering, Springer US, v.
17, n. 3, p. 305–344, 2012. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-0119174-8>. sources
AR
BAGHERI, E.; ENSAN, F.; GASEVIC, D. Decision support for the software product line domain
engineering lifecycle. Automated Software Engineering, Springer US, v. 19, n. 3, p. 335–377, 2012.
ISSN 0928-8910. Disponível em: <http://dx.doi.org/10.1007- /s10515-011-0099-7>.
AR
MASSEY, A. et al. Evaluating existing security and privacy requirements for legal compliance. Requirements Engineering, Springer-Verlag, v. 15, n. 1, p. 119–137, 2010. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-009-0089-5>.
AR
VIVAS, J.; AGUDO, I.; LÓPEZ, J. A methodology for security assurance-driven system development.
Requirements Engineering, Springer-Verlag, v. 16, n. 1, p. 55–73, 2011. ISSN 0947-3602. Disponível
em: <http://dx.doi.org/10.1007/s00766-010-0114-8>.>.
AR
2a análise
Continua na próxima página
178
Referência
1a análise
ZOUGHBI, G.; BRIAND, L.; LABICHE, Y. Modeling safety and airworthiness (RTCA DO-178B)
information: conceptual model and UML profile. Software & Systems Modeling, Springer-Verlag, v.
10, n. 3, p. 337–367, 2011. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-0100164-x>.
AR
LISBOA, L. et al. ToolDay: a tool for domain analysis. International Journal on Software Tools for
Technology Transfer, Springer-Verlag, v. 13, n. 4, p. 337–353, 2011. ISSN 1433-2779. Disponível em:
<http://dx.doi.org/10.1007/s10009-010-0174-6>
AR
METSÄ, J. et al. Using aspects for testing of embedded software: experiences from two industrial
case studies. Software Quality Journal, Springer US, p. 1–29, 2013. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-012-9193-8>.
AR
BATINI, C. et al. The UM-MAIS Methodology for Multi-channel Adaptive Web Information Systems. World Wide Web, Springer US, v. 10, n. 4, p. 349–385, 2007. ISSN 1386-145X. Disponível em:
<http://dx.doi.org/10.1007/s11280-007-0025-x>.
AR
DAM, H.; WINIKOFF, M. An agent-oriented approach to change propagation in software maintenance.
Autonomous Agents and Multi-Agent Systems, Springer US, v. 23, n. 3, p. 384–452, 2011. ISSN 13872532. Disponível em: <http://dx.doi.org/10.1007- /s10458-010-9163-0>.
AR
PONTES, R. P. et al. Contributions of model checking and CoFI methodology to the development of
space embedded software. Empirical Software Engineering, Springer US, p. 1–30, 2012. ISSN 13823256. Disponível em: <http://dx.doi.org/10.1007/s10664-012- 9215-y>.
AR
YUE, T.; BRIAND, L.; LABICHE, Y. A systematic review of transformation approaches between user
requirements and analysis models. Requirements Engineering, Springer-Verlag, v. 16, n. 2, p. 75–99,
2011. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-010-0111-y>.
AR
SALAY, R. et al. Managing requirements uncertainty with partial models. Requirements Engineering, Springer-Verlag, v. 18, n. 2, p. 107–128, 2013. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-013-0170-y>.
AR
FUNKHOUSER, O.; ETZKORN, L.; HUGHES WILLIAME., J. A lightweight approach to software
validation by comparing UML use cases with internal program documentation selected via call graphs.
Software Quality Journal, Springer US, v. 16, n. 1, p. 131–156, 2008. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-007-9034-3>.
AR
LANE, S. et al. Towards a framework for the development of adaptable service-based applications.
Service Oriented Computing and Applications, Springer London, p. 1–19, 2013. ISSN 1863-2386.
Disponível em: <http://dx.doi.org/10.1007/s11761-013-0136-4>.
AR
GUERRA, E. et al. Engineering model transformations with transML. Software & Systems Modeling, Springer Berlin Heidelberg, v. 12, n. 3, p. 555–577, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-011-0211-2>.
AR
CARRERA, A.; IGLESIAS, C. A.; GARIJO, M. Beast methodology: An agile testing methodology for
multi-agent systems based on behaviour driven development. Information Systems Frontiers, Springer
US, p. 1–14, 2013. ISSN 1387-3326. Disponível em: <http://dx.doi.org/10.1007/s10796-013-9438-5>.
AR
ISLAM, S.; MOURATIDIS, H.; JORJENS, J. A framework to support alignment of secure software
engineering with legal regulations. Software and Systems Modeling, Springer-Verlag, v. 10, n. 3, p.
369–394, 2011. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-010-0154-z>.
AR
IMMONEN, A.; NIEMELÄ, E. Survey of reliability and availability prediction methods from the viewpoint of software architecture. Software & Systems Modeling, Springer-Verlag, v. 7, n. 1, p. 49–65,
2008. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-006-0040-x>.
AR
NKWOCHA, A.; HALL, J.; RAPANOTTI, L. Design rationale capture for process improvement in
the globalised enterprise: an industrial study. Software & Systems Modeling, Springer-Verlag, p. 1–21,
2011. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-011-0223-y>.
AR
KORNECKI, A.; ZALEWSKI, J. Certification of software for real-time safety- critical systems: state
of the art. Innovations in Systems and Software Engineering, Springer-Verlag, v. 5, n. 2, p. 149–161,
2009. ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-009-0088-1>.
AR
KOSIUCZENKO, P. Redesign of UML class diagrams: a formal approach. Software & Systems Modeling, Springer-Verlag, v. 8, n. 2, p. 165–183, 2009. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-007-0068-6>.
AR
2a análise
Continua na próxima página
179
Referência
1a análise
CHAN, B. et al. An approach for estimating the time needed to perform code changes in business
applications. International Journal on Software Tools for Technology Transfer, Springer-Verlag, v. 11,
n. 6, p. 503–515, 2009. ISSN 1433-2779. Disponível em: <http://dx.doi.org/10.1007/s10009-009-01225>.
AR
MUSSBACHER, G. et al. AoURN-based modeling and analysis of software product lines. Software
Quality Journal, Springer US, v. 20, n. 3-4, p. 645–687, 2012. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-011-9153-8>.
AR
HEYMANS, P. et al. A code tagging approach to software product line development. International
Journal on Software Tools for Technology Transfer, Springer-Verlag, v. 14, n. 5, p. 553–566, 2012.
ISSN 1433-2779. Disponível em: <http://dx.doi.org/10.1007/s10009-012-0242-1>.
AR
VOELTER, M. et al. MBEDDR: instantiating a language workbench in the embedded software domain. Automated Software Engineering, Springer US, v. 20, n. 3, p. 339–390, 2013. ISSN 0928-8910.
Disponível em: <http://dx.doi.org/10.1007/s10515-013-0120-4>.
AR
ELLIS, K.; BERRY, D. Quantifying the impact of requirements definition and management process
maturity on project outcome in large business application development. Requirements Engineering,
Springer-Verlag, p. 1–27, 2012. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766012-0146-3>.
AR
GRIESSNIG, G. et al. Improving automotive embedded systems engineering at european level. e & i
Elektrotechnik und Informationstechnik, Springer-Verlag, v. 128, n. 6, p. 209–214, 2011. ISSN 0932383X. Disponível em: <http://dx.doi.org/10.1007/s00502-011- 0003-y>.
AR
MONPERRUS, M. et al. Automated measurement of models of requirements. Software Quality Journal, Springer US, v. 21, n. 1, p. 3–22, 2013. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-011-9163-6>.
AR
FERRARI, R.; MILLER, J.; MADHAVJI, N. A controlled experiment to assess the impact of system
architectures on new system requirements. Requirements Engineering, Springer-Verlag, v. 15, n. 2, p.
215–233, 2010. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-010-0099-3>.
AR
BERGMANN, G. et al. Change-driven model transformations. Software & Systems Modeling, Springer-Verlag, v. 11, n. 3, p. 431–461, 2012. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-011-0197-9>.
AR
CHATTERJEE, K.; GUPTA, D.; DE, A. A framework for development of secure software. CSI Transactions on ICT, Springer-Verlag, v. 1, n. 2, p. 143–157, 2013. ISSN 2277-9078. Disponível em:
<http://dx.doi.org/10.1007/s40012-013-0010-8>.
AR
SIKORA, E.; TENBERGEN, B.; POHL, K. Industry needs and research directions in requirements
engineering for embedded systems. Requirements Engineering, Springer-Verlag, v. 17, n. 1, p. 57–78,
2012. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-011-0144-x>.
AR
IHME, T. et al. Challenges and industry practices for managing software variability in small and medium sized enterprises. Empirical Software Engineering, Springer US, p. 1–25, 2013. ISSN 1382-3256.
Disponível em: <http://dx.doi.org/10.1007/s10664-013- 9253-0>.
AR
PITULA, K.; RADHAKRISHNAN, T. On eliciting requirements from end-users in the ICT4D domain.
Requirements Engineering, Springer-Verlag, v. 16, n. 4, p. 323–351, 2011. ISSN 0947-3602. Disponível
em: <http://dx.doi.org/10.1007/s00766-011-0127-y>.
AR
BRANCO, M. et al. A case study on consistency management of business and IT process models in
banking. Software & Systems Modeling, Springer-Verlag, p. 1–28, 2013. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-013-0318-8>.
AR
ARIAS, T. C.; SPEK, P.; AVGERIOU, P. A practice-driven systematic review of dependency analysis
solutions. Empirical Software Engineering, Springer US, v. 16, n. 5, p. 544–586, 2011. ISSN 13823256. Disponível em: <http://dx.doi.org/10.1007/s10664- 011-9158-8>.
AR
GARCÍA, J. Q. A study on PDAS for onboard applications and technologies and methodologies. Personal and Ubiquitous Computing, Springer-Verlag, v. 15, n. 5, p. 457–478, 2011. ISSN 1617-4909.
Disponível em: <http://dx.doi.org/10.1007/s00779-010- 0318-4>.
AR
POLZER, A. et al. Managing complexity and variability of a model-based embedded software product
line. Innovations in Systems and Software Engineering, Springer-Verlag, v. 8, n. 1, p. 35–49, 2012.
ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007- /s11334-011-0174-z>.
AR
2a análise
Continua na próxima página
180
Referência
1a análise
MOHAGHEGHI, P. et al. An empirical study of the state of the practice and acceptance of modeldriven engineering in four industrial cases. Empirical Software Engineering, Springer US, v. 18, n. 1,
p. 89–116, 2013. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-012-9196-x>.
AR
GORSCHEK, T. et al. Industry evaluation of the Requirements Abstraction Model. Requirements
Engineering, Springer-Verlag, v. 12, n. 3, p. 163–190, 2007. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-007-0047-z>.
AR
PETERSEN, K.; WOHLIN, C. The effect of moving from a plan-driven to an incremental software
development approach with agile practices. Empirical Software Engineering, Springer US, v. 15, n. 6,
p. 654–693, 2010. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-010-9136-6>.
AR
YSKOUT, K.; SCANDARIATO, R.; JOOSEN, W. Change Patterns. Software & Systems Modeling,
Springer-Verlag, p. 1–24, 2012. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270012-0276-6>.
AR
KAGDI, H.; GETHERS, M.; POSHYVANYK, D. Integrating conceptual and logical couplings for
change impact analysis in software. Empirical Software Engineering, Springer US, v. 18, n. 5, p.
933–969, 2013. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-012-9233-9>.
AR
SULEIMAN, H.; SVETINOVIC, D. Evaluating the effectiveness of the security quality requirements engineering (SQUARE) method: a case study using smart grid advanced metering infrastructure. Requirements Engineering, Springer-Verlag, p. 1–29, 2012. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-012-0153-4>.
AR
SITNIKOVA, E.; KROEGER, T.; COOK, S. Software and systems engineering process capability in the
south australian defence industry. Innovations in Systems and Software Engineering, Springer-Verlag,
v. 3, n. 2, p. 129–139, 2007. ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-0070020-5>.
AR
PAKULIN, N.; KHOROSHILOV, A. Development of formal models and conformance testing for
systems with asynchronous interfaces and telecommunications protocols. Programming and Computer Software, Nauka/Interperiodica, v. 33, n. 6, p. 316–335, 2007. ISSN 0361-7688. Disponível em:
<http://dx.doi.org/10.1134/S0361768807060035>.
AR
GÉNOVA, G. et al. A framework to measure and improve the quality of textual requirements. Requirements Engineering, Springer-Verlag, v. 18, n. 1, p. 25–41, 2013. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-011-0134-z>
AR
PERSEIL, I.; PAUTET, L. Foundations of a new software engineering method for real-time systems.
Innovations in Systems and Software Engineering, Springer-Verlag, v. 4, n. 3, p. 195–202, 2008. ISSN
1614-5046. Disponível em: <http://dx.doi.org/10- .1007/s11334-008-0067-y>.
AR
LOCHAU, M. et al. Model-based pairwise testing for feature interaction coverage in software product
line engineering. Software Quality Journal, Springer US, v. 20, n. 3-4, p. 567–604, 2012. ISSN 09639314. Disponível em: <http://dx.doi.org/10.1007/s11219- 011-9165-4>.
AR
GÜRSES, S.; SEGURAN, M.; ZANNONE, N. Requirements engineering within a large-scale securityoriented research project: lessons learned. Requirements Engineering, Springer-Verlag, v. 18, n. 1, p.
43–66, 2013. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-011-0139-7>.
AR
CHAIKALIS, T.; CHATZIGEORGIOU, A.; EXAMILIOTOU, G. Investigating the effect of evolution
and refactorings on feature scattering. Software Quality Journal, Springer US, p. 1–27, 2013. ISSN
0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219- 013-9204-4>.
AR
CHAIKALIS, T.; CHATZIGEORGIOU, A.; EXAMILIOTOU, G. Investigating the effect of evolution
and refactorings on feature scattering. Software Quality Journal, Springer US, p. 1–27, 2013. ISSN
0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219- 013-9204-4>.
AR
ERAMO, R. et al. A model-driven approach to automate the propagation of changes among architecture
description languages. Software & Systems Modeling, Springer-Verlag, v. 11, n. 1, p. 29–53, 2012.
ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-010-0170-z>.
AR
IVARSSON, M.; GORSCHEK, T. Tool support for disseminating and improving development practices. Software Quality Journal, Springer US, v. 20, n. 1, p. 173–199, 2012. ISSN 0963-9314. Disponível
em: <http://dx.doi.org/10.1007/s11219-011-9139-6>.
AR
NICOLÁS, J. et al. An integrated domain analysis approach for teleoperated systems. Requirements Engineering, Springer-Verlag, v. 14, n. 1, p. 27–46, 2009. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-008-0072-6>.
AR
2a análise
Continua na próxima página
181
Referência
1a análise
HUMAYOUN, S. Incorporating Usability Evaluation in Software Development Environments. KI Künstliche Intelligenz, Springer-Verlag, v. 26, n. 2, p. 197–200, 2012. ISSN 0933-1875. Disponível
em: <http://dx.doi.org/10.1007/s13218-012-0184-5>.
AR
ALENLJUNG, B.; PERSSON, A. Portraying the practice of decision-making in requirements engineering: a case of large scale bespoke development. Requirements Engineering, Springer-Verlag, v. 13, n.
4, p. 257–279, 2008. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-008-00682>.
AR
CAFFERY, F. M.; BURTON, J.; RICHARDSON, I. Risk management capability model for the development of medical device software. Software Quality Journal, Springer US, v. 18, n. 1, p. 81–107,
2010. ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-009-9086-7>.
AR
R
O’HALLORAN, C. Automated verification of code automatically generated from simulink . Automated Software Engineering, Springer US, v. 20, n. 2, p. 237–264, 2013. ISSN 0928-8910. Disponível
em: <http://dx.doi.org/10.1007/s10515-012-0116-5>.
AR
ZAMBON, E. et al. Model-based qualitative risk assessment for availability of IT infrastructures. Software & Systems Modeling, Springer-Verlag, v. 10, n. 4, p. 553–580, 2011. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-010-0166-8>.
AR
KOZIOLEK, H. et al. Performance and reliability prediction for evolving service-oriented software
systems. Empirical Software Engineering, Springer US, v. 18, n. 4, p. 746–790, 2013. ISSN 13823256. Disponível em: <http://dx.doi.org/10.1007/s10664-012-9213-0>.
AR
REVELLE, M.; GETHERS, M.; POSHYVANYK, D. Using structural and textual information to capture feature coupling in object-oriented software. Empirical Software Engineering, Springer US, v. 16,
n. 6, p. 773–811, 2011. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-011-91597>.
AR
SHAH, H. et al. Requirements for guidelines systems: implementation challenges and lessons from
existing software-engineering efforts. BMC Medical Informatics and Decision Making, BioMed Central, v. 12, n. 1, p. 1–10, 2012. Disponível em: <http://dx.doi.org/10.1186/1472-6947-12-16>.
AR
ZHAO, L.; HAYES, J. Rank-based refactoring decision support: two studies. Innovations in Systems
and Software Engineering, Springer-Verlag, v. 7, n. 3, p. 171–189, 2011. ISSN 1614-5046. Disponível
em: <http://dx.doi.org/10.1007/s11334-011-0154-3>.
AR
PARETO, L.; ERIKSSON, P.; EHNEBOM, S. Concern coverage in base station development: an empirical investigation. Software & Systems Modeling, Springer-Verlag, v. 11, n. 3, p. 409–429, 2012.
ISSN 1619-1366. Disponível em: <http://dx.doi.org/10- .1007/s10270-010-0188-2>.
AR
BARESI, L. et al. Formal verification and validation of embedded systems: the UML-based MADES
approach. Software & Systems Modeling, Springer-Verlag, p. 1–21, 2013. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-013-0330-z>.
AR
MANNADIAR, R.; VANGHELUWE, H. Modular artifact synthesis from domain-specific models. Innovations in Systems and Software Engineering, Springer-Verlag, v. 8, n. 1, p. 65–77, 2012. ISSN
1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-011- 0157-0>.
AR
YIE, A. et al. Realizing Model Transformation Chain interoperability. Software & Systems
Modeling, Springer-Verlag, v. 11, n. 1, p. 55–75, 2012. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-010-0179-3>.
AR
CHEN, D. et al. An architectural approach to the analysis, verification and validation of software intensive embedded systems. Computing, Springer Vienna, v. 95, n. 8, p. 649–688, 2013. ISSN 0010-485X.
Disponível em: <http://dx.doi.org/10.1007/s00607-013-0314-4>.
AR
BECKER, S. et al. A graph-based algorithm for consistency maintenance in incremental and interactive
integration tools. Software & Systems Modeling, Springer-Verlag, v. 6, n. 3, p. 287–315, 2007. ISSN
1619-1366. Disponível em: <http://dx.doi.org/10.1007- /s10270-006-0045-5>.
AR
FILHO, R. S. S. et al. Experiences using Tedeso: an extensible and interoperable model-based testing
platform. Automated Software Engineering, Springer US, v. 20, n. 3, p. 299–337, 2013. ISSN 09288910. Disponível em: <http://dx.doi.org/10.1007/s10515- 012-0118-3>.
AR
KEARNEY, P.; BRÜGGER, L. A risk-driven security analysis method and modelling language. BT
Technology Journal, Kluwer Academic Publishers-Consultants Bureau, v. 25, n. 1, p. 141–153, 2007.
ISSN 1358-3948. Disponível em: <http://dx.doi.org/10- .1007/s10550-007-0016-6>.
AR
2a análise
Continua na próxima página
182
Referência
1a análise
GORDON, D. G.; BREAUX, T. D. A cross-domain empirical study and legal evaluation of the requirements water marking method. Requirements Engineering, Springer-Verlag, v. 18, n. 2, p. 147–173,
2013. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-013-0167-6>.
AR
FLURI, B. et al. Analyzing the co-evolution of comments and source code. Software Quality Journal, Springer US, v. 17, n. 4, p. 367–394, 2009. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-009-9075-x>.
AR
BUCHMANN, T.; WESTFECHTEL, B. Mapping feature models onto domain models: ensuring consistency of configured domain models. Software & Systems Modeling, Springer-Verlag, p. 1–33, 2012.
ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-012-0305-5>.
AR
PERSEIL, I.; PAUTET, L. Formal methods integration in software engineering. Innovations in Systems
and Software Engineering, Springer-Verlag, v. 6, n. 1-2, p. 5–11, 2010. ISSN 1614-5046. Disponível
em: <http://dx.doi.org/10.1007/s11334-009-0115-2>.
AR
TAMBOURIS, E. et al. A reference requirements set for public service provision enterprise architectures. Software & Systems Modeling, Springer-Verlag, p. 1–23, 2012. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-012-0303-7>.
AR
KATINA, P. F.; KEATING, C. B.; JARADAT, R. M. System requirements engineering in complex
situations. Requirements Engineering, Springer-Verlag, p. 1–18, 2012. ISSN 0947-3602. Disponível
em: <http://dx.doi.org/10.1007/s00766-012-0157-0>.
AR
ALBERTI, A. M. A conceptual-driven survey on future internet requirements, technologies, and challenges. Journal of the Brazilian Computer Society, Springer-Verlag, p. 1–21, 2013. ISSN 0104-6500.
Disponível em: <http://dx.doi.org/10.1007/s13173-013- 0101-2>
AR
MAXWELL, J. C. et al. A legal cross-references taxonomy for reasoning about compliance requirements. Requirements Engineering, Springer-Verlag, v. 17, n. 2, p. 99–115, 2012. ISSN 0947-3602.
Disponível em: <http://dx.doi.org/10.1007/s00766-012-0152-5>.
AR
SELLIER, D.; MANNION, M.; MANSELL, J. X. Managing requirements inter- dependency for software product line derivation. Requirements Engineering, Springer-Verlag, v. 13, n. 4, p. 299–313, 2008.
ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-008-0066-4>.
AR
TONELLA, P. et al. Empirical studies in reverse engineering: state of the art and future trends. Empirical Software Engineering, Springer US, v. 12, n. 5, p. 551–571, 2007. ISSN 1382-3256. Disponível
em: <http://dx.doi.org/10.1007/s10664-007-9037-5>.
AR
SINGH, S.; WOO, C. Investigating business-it alignment through multi-disciplinary goal concepts.
Requirements Engineering, Springer-Verlag, v. 14, n. 3, p. 177–207, 2009. ISSN 0947-3602. Disponível
em: <http://dx.doi.org/10.1007/s00766-009-0081-0>.
AR
POSHYVANYK, D. et al. Using information retrieval based coupling measures for impact analysis.
Empirical Software Engineering, Springer US, v. 14, n. 1, p. 5–32, 2009. ISSN 1382-3256. Disponível
em: <http://dx.doi.org/10.1007/s10664-008-9088-2>.
AR
BAVOTA, G. et al. Using structural and semantic measures to improve software modularization. Empirical Software Engineering, Springer US, v. 18, n. 5, p. 901–932, 2013. ISSN 1382-3256. Disponível
em: <http://dx.doi.org/10.1007/s10664-012-9226-8>.
AR
CABRAL, G.; SAMPAIO, A. Automated formal specification generation and refinement from requirement documents. Journal of the Brazilian Computer Society, Springer-Verlag, v. 14, n. 1, p. 87-106,
2008. ISSN 0104-6500. Disponível em: <http://dx.doi.org/10.1007/BF03192554>.
AR
FLURI, B. et al. Analyzing the co-evolution of comments and source code. Software Quality Journal, Springer US, v. 17, n. 4, p. 367–394, 2009. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-009-9075-x>.
AR
EBERT, C. Improving engineering efficiency with PLM/ALM. Software & Systems Modeling,
Springer Berlin Heidelberg, v. 12, n. 3, p. 443–449, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-013-0347-3>.
AR
CLEARY, B. et al. An empirical analysis of information retrieval based concept location techniques in
software comprehension. Empirical Software Engineering, Springer US, v. 14, n. 1, p. 93–130, 2009.
ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-008-9095-3>.
AR
PIMENTEL, J. et al. Deriving software architectural models from requirements models for adaptive
systems: the stream-a approach. Requirements Engineering, Springer-Verlag, v. 17, n. 4, p. 259–281,
2012. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-011-0126-z>.
AR
2a análise
Continua na próxima página
183
Referência
1a análise
DUAN, C. et al. Towards automated requirements prioritization and triage. Requirements Engineering, Springer-Verlag, v. 14, n. 2, p. 73–89, 2009. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-009-0079-7>.
AR
OFFUTT, J.; ALLURI, C. An industrial study of applying input space partitioning to test financial
calculation engines. Empirical Software Engineering, Springer US, p. 1–24, 2012. ISSN 1382-3256.
Disponível em: <http://dx.doi.org/10.1007/s10664-012-9229-5>
AR
PEÑA, J. et al. Building and implementing policies in autonomous and autonomic systems using MaCMAS. Innovations in Systems and Software Engineering, Springer-Verlag, v. 3, n. 1, p. 17–31, 2007.
ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-006-0017-5>.
AR
NUGROHO, A.; CHAUDRON, M. The impact of UML modeling on defect density and defect resolution time in a proprietary system. Empirical Software Engineering, Springer US, p. 1–29, 2013. ISSN
1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664- 013-9243-2>.
AR
GIESE, H.; WAGNER, R. From model transformation to incremental bidirectional model synchronization. Software & Systems Modeling, Springer-Verlag, v. 8, n. 1, p. 21–43, 2009. ISSN 1619-1366.
Disponível em: <http://dx.doi.org/10.1007/s10270-008-0089-9>.
AR
WANG, Y. et al. Monitoring and diagnosing software requirements. Automated Software Engineering, Springer US, v. 16, n. 1, p. 3–35, 2009. ISSN 0928-8910. Disponível em:
<http://dx.doi.org/10.1007/s10515-008-0042-8>.
AR
KAPSER, C.; GODFREY, M. Cloning Considered Harmful considered Harmful: patterns of cloning
in software. Empirical Software Engineering, Springer US, v. 13, n. 6, p. 645–692, 2008. ISSN 13823256. Disponível em: <http://dx.doi.org/10.1007/s10664- 008-9076-6>.
AR
PENG, X.; LEE, S.-W.; ZHAO, W.-Y. Feature-Oriented Nonfunctional Requirement Analysis for Software Product Line. Journal of Computer Science and Technology, Springer US, v. 24, n. 2, p. 319–338,
2009. ISSN 1000-9000. Disponível em: <http://dx.doi.org/10.1007/s11390-009-9227-2>.
AR
SCHULZ, T. et al. Predicting the Flow of Defect Correction Effort using a Bayesian Network Model. Empirical Software Engineering, Springer US, v. 18, n. 3, p. 435–477, 2013. ISSN 1382-3256.
Disponível em: <http://dx.doi.org/10.1007/s10664-011-9175-7>.
AR
ZEISS, B. et al. A conformance test suite for TTCN-3 tools. International Journal on Software
Tools for Technology Transfer, Springer-Verlag, p. 1–10, 2013. ISSN 1433-2779. Disponível em:
<http://dx.doi.org/10.1007/s10009-013-0285-y>.
AR
GACITUA, R.; SAWYER, P.; GERVASI, V. Relevance-based abstraction identification: technique and
evaluation. Requirements Engineering, Springer-Verlag, v. 16, n. 3, p. 251–265, 2011. ISSN 0947-3602.
Disponível em: <http://dx.doi.org/10.1007/s00766-011- 0122-3>.
AR
LANDHÄUSSER, M.; KÖRNER, S.; TICHY, W. From requirements to UML models and back: how
automatic processing of text can support requirements engineering. Software Quality Journal, Springer
US, p. 1–29, 2013. ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-013-9210-6>.
AR
FOUAD, A. et al. Embedding requirements within Model-Driven Architecture. Software Quality Journal, Springer US, v. 19, n. 2, p. 411–430, 2011. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-010-9122-7>.
AR
ACHER, M. et al. Composing multiple variability artifacts to assemble coherent workflows. Software Quality Journal, Springer US, v. 20, n. 3-4, p. 689–734, 2012. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-011-9170-7>.
AR
KRITIKOS, K.; KUBICKI, S.; DUBOIS, E. Goal-based business service composition. Service Oriented Computing and Applications, Springer-Verlag, p. 1–27, 2013. ISSN 1863-2386. Disponível em:
<http://dx.doi.org/10.1007/s11761-012-0126-y>.
AR
EL-RAWAS, O.; MENZIES, T. A second look at faster, better, cheaper. Innovations in Systems and
Software Engineering, Springer-Verlag, v. 6, n. 4, p. 319–335, 2010. ISSN 1614-5046. Disponível em:
<http://dx.doi.org/10.1007/s11334-010-0137-9>.
AR
AMALFITANO, D. et al. The DynaRIA tool for the comprehension of Ajax web applications by dynamic analysis. Innovations in Systems and Software Engineering, Springer-Verlag, p. 1–17, 2013. ISSN
1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-013-0207-x>.
AR
YOUNG, J. Commitment analysis to operationalize software requirements from privacy policies. Requirements Engineering, Springer-Verlag, v. 16, n. 1, p. 33–46, 2011. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-010-0108-6>.
AR
2a análise
Continua na próxima página
184
Referência
1a análise
LAGERSTRÖM, R.; JOHNSON, P.; EKSTEDT, M. Architecture analysis of enterprise systems modifiability: a metamodel for software change cost estimation. Software Quality Journal, Springer US, v.
18, n. 4, p. 437–468, 2010. ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-0109100-0>.
AR
ANASTASAKIS, K. et al. On challenges of model transformation from uml to alloy. Software &
Systems Modeling, Springer-Verlag, v. 9, n. 1, p. 69–86, 2010. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-008-0110-3>.
AR
WEBER, B.; SADIQ, S.; REICHERT, M. Beyond rigidity – dynamic process lifecycle support. Computer Science - Research and Development, Springer-Verlag, v. 23, n. 2, p. 47–65, 2009. ISSN 1865-2034.
Disponível em: <http://dx.doi.org/10.1007/s00450-009- 0069-5>.
AR
STRECKER, S.; HEISE, D.; FRANK, U. RiskM: A multi-perspective modeling method for it risk
assessment. Information Systems Frontiers, Springer US, v. 13, n. 4, p. 595–611, 2011. ISSN 13873326. Disponível em: <http://dx.doi.org/10.1007/s10796-010-9235-3>.
AR
HINDLE, A. et al. Automated topic naming. Empirical Software Engineering, Springer US, p. 1–31,
2012. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664- 012-9209-9>.
AR
LINDVALL, M. et al. Experimenting with software testbeds for evaluating new technologies. Empirical
Software Engineering, Kluwer Academic Publishers-Plenum Publishers, v. 12, n. 4, p. 417–444, 2007.
ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-006-9034-0>.
AR
LI, Z.; HALL, J.; RAPANOTTI, L. On the systematic transformation of requirements to specifications. Requirements Engineering, Springer-Verlag, p. 1–23, 2013. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-013-0173-8>.
AR
DALPIAZ, F.; GIORGINI, P.; MYLOPOULOS, J. Adaptive socio-technical systems: a requirementsbased approach. Requirements Engineering, Springer-Verlag, v. 18, n. 1, p. 1–24, 2013. ISSN 09473602. Disponível em: <http://dx.doi.org/10.1007/s00766-0110132-1>.
AR
KIENLE, H.; KRAFT, J.; NOLTE, T. System-specific static code analyses: a case study in the complex
embedded systems domain. Software Quality Journal, Springer US, v. 20, n. 2, p. 337–367, 2012. ISSN
0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-011-9138-7>.
AR
WARKEN, M. From testing to anti-product development. International Journal on Software Tools for
Technology Transfer, Springer-Verlag, v. 10, n. 4, p. 297–307, 2008. ISSN 1433-2779. Disponível em:
<http://dx.doi.org/10.1007/s10009-008-0074-1>.
AR
CAPILLA, R.; BABAR, M. A.; PASTOR, O. Quality requirements engineering for systems and software architecting: methods, approaches, and tools. Requirements Engineering, Springer-Verlag, v. 17,
n. 4, p. 255–258, 2012. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-011-01379>.
AR
NGUYEN, T. et al. KBRE: a framework for knowledge-based requirements engineering.
Software Quality Journal, Springer US, p. 1–33, 2013. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-013-9202-6>
AR
ELLIOTT, M.; DAWSON, R.; EDWARDS, J. An analysis of software quality management at AWE
plc. Software Quality Journal, Springer US, v. 15, n. 4, p. 347–363, 2007. ISSN 0963-9314. Disponível
em: <http://dx.doi.org/10.1007/s11219-007-9027-2>.
AR
CHU, P.-H. et al. A test case refactoring approach for pattern-based software development. Software Quality Journal, Springer US, v. 20, n. 1, p. 43–75, 2012. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-011-9143-x>.
AR
TRIENEKENS, J.; KUSTERS, R.; BRUSSEL, D. Quality specification and metrication, results from a
case-study in a mission-critical software domain. Software Quality Journal, Springer US, v. 18, n. 4, p.
469–490, 2010. ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-010-9101-z>.
AR
KINDEREN, S.; GAALOUL, K.; PROPER, H. Bridging value modelling to archimate via transaction
modelling. Software & Systems Modeling, Springer-Verlag, p. 1–15, 2012. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-012-0299-z>.
AR
THAKURTA, R. A framework for prioritization of quality requirements for inclusion in a software
project. Software Quality Journal, Springer US, p. 1–25, 2012. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-012-9188-5>.
AR
2a análise
Continua na próxima página
185
Referência
1a análise
AHMAD, N.; LAPLANTE, P. Reasoning about software using metrics and expert opinion. Innovations
in Systems and Software Engineering, Springer-Verlag, v. 3, n. 4, p. 229–235, 2007. ISSN 1614-5046.
Disponível em: <http://dx.doi.org/10.1007/s11334-007-0036-x>.
AR
EVANS, N. et al. Applying CSP || B to information systems. Software & Systems Modeling, Springer-Verlag, v. 7, n. 1, p. 85–102, 2008. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-007-0048-x>.
AR
AHMAD, N.; LAPLANTE, P. Reasoning about software using metrics and expert opinion. Innovations
in Systems and Software Engineering, Springer-Verlag, v. 3, n. 4, p. 229–235, 2007. ISSN 1614-5046.
Disponível em: <http://dx.doi.org/10.1007/s11334-007-0036-x>.
AR
BAGGEN, R. et al. Standardized code quality benchmarking for improving software maintainability.
Software Quality Journal, Springer US, v. 20, n. 2, p. 287–307, 2012. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-011-9144-9>.
AR
ZHENG, Y.; TAYLOR, R. A classification and rationalization of model-based software development.
Software & Systems Modeling, Springer-Verlag, p. 1–10, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-013-0355-3>.
AR
CHEN, D. et al. Integrated safety and architecture modeling for automotive embedded systems*. e
& i Elektrotechnik und Informationstechnik, Springer-Verlag, v. 128, n. 6, p. 196–202, 2011. ISSN
0932-383X. Disponível em: <http://dx.doi.org/10.1007/s00502-0110007-7>.
AR
CÔTÉ, M. A.; SURYN, W.; GEORGIADOU, E. In search for a widely applicable and accepted software quality model for software quality engineering. Software Quality Journal, Springer US, v. 15, n. 4,
p. 401–416, 2007. ISSN 0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-007-9029-0>.
AR
GARCÉS, K. et al. Adapting transformations to metamodel changes via external transformation composition. Software & Systems Modeling, Springer-Verlag, p. 1–18, 2013. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-012-0297-1>.
AR
WALIA, G.; CARVER, J. Using error abstraction and classification to improve requirement quality:
conclusions from a family of four empirical studies. Empirical Software Engineering, Springer US, v.
18, n. 4, p. 625–658, 2013. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-0129202-3>.
AR
ESCHBACH, R.; LIN, L.; POORE, J. Applying string-rewriting to sequence-based specification.
Formal Methods in System Design, Springer US, p. 1–36, 2013. ISSN 0925-9856. Disponível em:
<http://dx.doi.org/10.1007/s10703-013-0185-5>.
AR
ZAIDMAN, A. et al. Studying the co-evolution of production and test code in open source and industrial developer test processes through repository mining. Empirical Software Engineering, Springer
US, v. 16, n. 3, p. 325–364, 2011. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664010-9143-7>.
AR
RAGO, A.; MARCOS, C.; DIAZ-PACE, J. Uncovering quality-attribute concerns in use case specifications via early aspect mining. Requirements Engineering, Springer-Verlag, v. 18, n. 1, p. 67–84, 2013.
ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-011-0142-z>.
AR
GUERRA-GARCIA, C.; CABALLERO, I.; PIATTINI, M. Capturing data quality requirements for
web applications by means of DQ WebRE. Information Systems Frontiers, Springer US, v. 15, n. 3, p.
433–445, 2013. ISSN 1387-3326. Disponível em: <http://dx.doi.org/10.1007/s10796-012-9401-x>.
AR
STEFANESCU, A.; WIECZOREK, S.; SCHUR, M. Message choreography modeling. Software & Systems Modeling, Springer-Verlag, p. 1–25, 2012. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-012-0272-x>.
AR
CANSELL, D.; MÉRY, D.; PROCH, C. System-on-chip design by proof-based refinement. International Journal on Software Tools for Technology Transfer, Springer-Verlag, v. 11, n. 3, p. 217–238, 2009.
ISSN 1433-2779. Disponível em: <http://dx.doi.org/10.1007/s10009-009-0104-7>.
AR
LARA, J.; GUERRA, E.; CUADRADO, J. Model-driven engineering with domain- specific metamodelling languages. Software & Systems Modeling, Springer Berlin Heidelberg, p. 1–31, 2013. ISSN
1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-013-0367-z>.
AR
HEMEL, Z. et al. Code generation by model transformation: a case study in transformation modularity. Software & Systems Modeling, Springer-Verlag, v. 9, n. 3, p. 375–402, 2010. ISSN 1619-1366.
Disponível em: <http://dx.doi.org/10.1007/s10270-009- 0136-1>.
AR
2a análise
Continua na próxima página
186
Referência
1a análise
PATRÍCIO, L.; CUNHA, J. Falcão e; FISK, R. Requirements engineering for multi-channel
services: the seb method and its application to a multi-channel bank. Requirements Engineering, Springer-Verlag, v. 14, n. 3, p. 209–227, 2009. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-009-0082-z>.
AR
LÓPEZ, T. et al. Taxonomy, technology and applications of smart objects. Information Systems Frontiers, Springer US, v. 13, n. 2, p. 281–300, 2011. ISSN 1387-3326. Disponível em:
<http://dx.doi.org/10.1007/s10796-009-9218-4>.
AR
PANG, Z. et al. Value-centric design of the internet-of-things solution for food supply chain: Value
creation, sensor portfolio and information fusion. Information Systems Frontiers, Springer US, p. 1–31,
2012. ISSN 1387-3326. Disponível em: <http://dx.doi.org/10.1007/s10796-012-9374-9>.
AR
ABRIAL, J.-R. et al. Rodin: an open toolset for modelling and reasoning in event-b. International
Journal on Software Tools for Technology Transfer, Springer-Verlag, v. 12, n. 6, p. 447–466, 2010.
ISSN 1433-2779. Disponível em: <http://dx.doi.org/10.1007/s10009-010-0145-y>.
AR
ICCOBENE, E.; SCANDURRA, P. Model transformations in the UPES/UPSoC development process
for embedded systems. Innovations in Systems and Software Engineering, Springer-Verlag, v. 5, n. 1,
p. 35–47, 2009. ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-009-0080-9>.
AR
RRUSU, V. Embedding domain-specific modelling languages in maude specifications. Software & Systems Modeling, Springer-Verlag, p. 1–23, 2012. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-012-0232-s
AR
GÜLEŞIR, G. et al. Experimental evaluation of a tool for the verification and transformation of source
code in event-driven systems. Empirical Software Engineering, Springer US, v. 14, n. 6, p. 720–777,
2009. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-009-9107-y>.
AR
NASCIMENTO, F. A. M.; OLIVEIRA, M. F. S.; WAGNER, F. R. A model-driven engineering framework for embedded systems design. Innovations in Systems and Software Engineering, SpringerVerlag, v. 8, n. 1, p. 19–33, 2012. ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334011-0175-y>.
AR
KITCHENHAM, B. et al. Evaluating guidelines for reporting empirical software engineering studies.
Empirical Software Engineering, Springer US, v. 13, n. 1, p. 97–121, 2008. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-007-9053-5>.
AR
ANTKIEWICZ, M.; BARTOLOMEI, T. T.; CZARNECKI, K. Fast extraction of high-quality
framework-specific models from application code. Automated Software Engineering, Springer US, v.
16, n. 1, p. 101–144, 2009. ISSN 0928-8910. Disponível em: <http://dx.doi.org/10.1007/s10515-0080040-x>.
AR
JURETA, I.; FAULKNER, S.; SCHOBBENS, P.-Y. Clear justification of modeling decisions for goaloriented requirements engineering. Requirements Engineering, Springer-Verlag, v. 13, n. 2, p. 87–115,
2008. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-007-0056-y>.
AR
BENESTAD, H.; ANDA, B.; ARISHOLM, E. Understanding cost drivers of software evolution: a
quantitative and qualitative investigation of change effort in two evolving software systems. Empirical
Software Engineering, Springer US, v. 15, n. 2, p. 166–203, 2010. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-009-9118-8>.
AR
KATARA, M.; KATZ, S. A concern architecture view for aspect-oriented software design. Software
& Systems Modeling, Springer-Verlag, v. 6, n. 3, p. 247–265, 2007. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-006-0032-x>.
AR
KUSEL, A. et al. Reuse in model-to-model transformation languages: are we there yet? Software & Systems Modeling, Springer-Verlag, p. 1–36, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-013-0343-7>.
AR
HALL, J.; RAPANOTTI, L. Software engineering as the design theoretic transformation of software
problems. Innovations in Systems and Software Engineering, Springer-Verlag, v. 8, n. 3, p. 175–193,
2012. ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-011-0171-2>.
AR
MA, Q.; KELSEN, P.; GLODT, C. A generic model decomposition technique and its application to the
eclipse modeling framework. Software & Systems Modeling, Springer-Verlag, p. 1–32, 2013. ISSN
1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-013-0348-2>.
AR
2a análise
Continua na próxima página
187
Referência
1a análise
GUMZEJ, R.; HALANG, W. QoS-oriented design of embedded systems with specification PEARL.
Innovations in Systems and Software Engineering, Springer-Verlag, v. 3, n. 4, p. 269–279, 2007. ISSN
1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-0070033-0>.
AR
PIJPERS, V. et al. Using conceptual models to explore business-ICT alignment in networked value
constellations. Requirements Engineering, Springer-Verlag, v. 17, n. 3, p. 203–226, 2012. ISSN 09473602. Disponível em: <http://dx.doi.org/10.1007/s00766011-0136-x>.
AR
WINKLER, S.; PILGRIM, J. A survey of traceability in requirements engineering and model-driven
development. Software and Systems Modeling, Springer-Verlag, v. 9, n. 4, p. 529–565, 2010. ISSN
1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270009-0145-0>.
AR
BRITO, P. et al. Architecting Fault Tolerance with Exception Handling: Verification and Validation.
Journal of Computer Science and Technology, Springer US, v. 24, n. 2, p. 212–237, 2009. ISSN 10009000. Disponível em: <http://dx.doi.org/10.1007/s11390-0099219-2>.
AR
KURTEV, I. Application of reflection in a model transformation language. Software & Systems Modeling, Springer-Verlag, v. 9, n. 3, p. 311–333, 2010. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-009-0138-z>.
AR
PRECHELT, L.; OEZBEK, C. The search for a research method for studying OSS process innovation. Empirical Software Engineering, Springer US, v. 16, n. 4, p. 514–537, 2011. ISSN 1382-3256.
Disponível em: <http://dx.doi.org/10.1007/s10664-0119160-1>.
AR
ALLEN, E.; GOTTIPATI, S.; GOVINDARAJAN, R. Measuring size, complexity, and coupling of hypergraph abstractions of software: An information-theory approach. Software Quality Journal, Kluwer
Academic Publishers-Plenum Publishers, v. 15, n. 2, p. 179–212, 2007. ISSN 0963-9314. Disponível
em: <http://dx.doi.org/10.1007/s11219006-9010-3>.
AR
FEIGENSPAN, J. et al. Do background colors improve program comprehension in the #ifdef hell? Empirical Software Engineering, Springer US, v. 18, n. 4, p. 699–745, 2013. ISSN 1382-3256. Disponível
em: <http://dx.doi.org/10.1007/s10664-012-9208-x>.
AR
RUBENS, J. Business analysis and requirements engineering: the same, only different? Requirements Engineering, Springer-Verlag, v. 12, n. 2, p. 121–123, 2007. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-007-0043-3>.
AR
AZEVEDO, S. et al. On the refinement of use case models with variability support. Innovations in
Systems and Software Engineering, Springer-Verlag, v. 8, n. 1, p. 51–64, 2012. ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-011-0177-9>.
AR
EL-ATTAR, M.; MILLER, J. Developing comprehensive acceptance tests from use cases and robustness diagrams. Requirements Engineering, Springer-Verlag, v. 15, n. 3, p. 285–306, 2010. ISSN 09473602. Disponível em: <http://dx.doi.org/10.1007/s00766-0090088-6>.
AR
BIGGERS, L. et al. Configuring latent dirichlet allocation based feature location. Empirical Software Engineering, Springer US, p. 1–36, 2012. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-012-9224-x>.
AR
HILL, E. et al. An empirical study of identifier splitting techniques. Empirical Software Engineering,
Springer US, p. 1–27, 2013. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-0139261-0>.
AR
DEOKAR, A.; EL-GAYAR, O. Decision-enabled dynamic process management for networked enterprises. Information Systems Frontiers, Springer US, v. 13, n. 5, p. 655–668, 2011. ISSN 1387-3326.
Disponível em: <http://dx.doi.org/10.1007/s10796-010-9243-3>.
AR
MEI, H.; LIU, X.-Z. Internetware: An emerging software paradigm for internet computing. Journal
of Computer Science and Technology, Springer US, v. 26, n. 4, p. 588–599, 2011. ISSN 1000-9000.
Disponível em: <http://dx.doi.org/10.1007/s11390-011-1159-y>.
AR
PAGANO, D.; MAALEJ, W. How do open source communities blog? Empirical Software Engineering,
Springer US, p. 1–35, 2012. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-0129211-2>.
AR
ARMENGAUD, E. Systematic test of time-triggered communication architectures using a componentbased approach. e & i Elektrotechnik und Informationstechnik, Springer-Verlag, v. 128, n. 6, p.
190–195, 2011. ISSN 0932-383X. Disponível em: <http://dx.doi.org/10.1007/s00502-011-0010-z>.
AR
2a análise
Continua na próxima página
188
Referência
1a análise
CHECHIK, M.; NEJATI, S.; SABETZADEH, M. A relationship-based approach to model integration.
Innovations in Systems and Software Engineering, Springer-Verlag, v. 8, n. 1, p. 3–18, 2012. ISSN
1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-011-0155-2>.
AR
SEATER, R.; JACKSON, D.; GHEYI, R. Requirement progression in problem frames: deriving specifications from requirements. Requirements Engineering, Springer-Verlag, v. 12, n. 2, p. 77–102, 2007.
ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-007-0048-y>.
AR
EVERMANN, J. A cognitive semantics for the association construct. Requirements Engineering, Springer-Verlag, v. 13, n. 3, p. 167–186, 2008. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-008-0065-5>.
AR
NIAZI, M.; COX, K.; VERNER, J. A measurement framework for assessing the maturity of requirements engineering process. Software Quality Journal, Springer US, v. 16, n. 2, p. 213–235, 2008. ISSN
0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219007-9033-4>.
AR
ŠMITE, D. et al. Empirical evidence in global software engineering: a systematic review. Empirical
Software Engineering, Springer US, v. 15, n. 1, p. 91–118, 2010. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-009-9123-y>.
AR
SVAHNBERG, M. et al. Uni-REPM: validated and improved. Requirements Engineering, Springer-Verlag, v. 18, n. 1, p. 85–103, 2013. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-012-0148-1>.
AR
BRUEL, J.-M. et al. Introduction to special issue: papers fromUML&FM. Innovations in Systems and
Software Engineering, Springer-Verlag, v. 4, n. 3, p. 185–187, 2008. ISSN 1614-5046. Disponível em:
<http://dx.doi.org/10.1007/s11334-008-0061-4>.
AR
GHATTAS, J.; SOFFER, P. Evaluation of inter-organizational business process solutions: A conceptual
model-based approach. Information Systems Frontiers, Springer US, v. 11, n. 3, p. 273–291, 2009.
ISSN 1387-3326. Disponível em: <http://dx.doi.org/10.1007- /s10796-008-9090-7>.
AR
UCHITEL, S. et al. Supporting incremental behaviour model elaboration. Computer Science Research and Development, Springer-Verlag, p. 1–15, 2012. ISSN 1865-2034. Disponível em:
<http://dx.doi.org/10.1007/s00450-012-0233-1>.
AR
WOITSCH, R. et al. Business and IT alignment: the IT-Socket. E& I Elektrotechnik und informationstechnik, Springer-Verlag, v.126, n. 7-8, p. 308-321, 2009. ISSN 0932-383X. Disponível em:
<http://dx.doi.org/10.1007/s00502-009-0660-2>.
AR
SOJER, D.; BUCKL, C.; KNOLL, A. Deriving fault-detection mechanisms from safety requirements.
Computer Science - Research and Development, Springer-Verlag, p. 1–14, 2011. ISSN 1865-2034.
Disponível em: <http://dx.doi.org/10.1007/s00450-011-0203-z>.
AR
SCHNEIDEWIND, N. Analysis of object-oriented software reliability model development. Innovations
in Systems and Software Engineering, Springer-Verlag, v. 5, n. 4, p. 243–253, 2009. ISSN 1614-5046.
Disponível em: <http://dx.doi.org/10.1007/s11334-009-0097-0>.
AR
MOSINCAT, A.; BINDER, W. Automated maintenance of service compositions with sla violation detection and dynamic binding. International Journal on Software Tools for Technology Transfer, Springer-Verlag, v. 13, n. 2, p. 167–179, 2011. ISSN 1433-2779. Disponível em:
<http://dx.doi.org/10.1007/s10009-010-0181-7>.
AR
MARIN, M. et al. An integrated crosscutting concern migration strategy and its semi-automated application to jhotdraw. Automated Software Engineering, Springer US, v. 16, n. 2, p. 323–356, 2009. ISSN
0928-8910. Disponível em: <http://dx.doi.org/10.1007/s10515-009-0051-2>.
AR
DOLADO, J. J.; OTERO, M.; HARMAN, M. Equivalence hypothesis testing in experimental software
engineering. Software Quality Journal, Springer US, p. 1–24, 2013. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-013-9196-0>.
AR
MALÝ J.; NEČASKÝ, M.; MLÝKOVÁ. Efficient adaptation of XML data using a conceptual model. Information Systems Frontiers, Springer US, p. 1–34, 2012. ISSN 1387-3326. Disponível em:
<http://dx.doi.org/10.1007/s10796-012-9375-8>.
AR
LEDRU, Y. et al. Prioritizing test cases with string distances. Automated Software Engineering, Springer US, v. 19, n. 1, p. 65–95, 2012. ISSN 0928-8910. Disponível em:
<http://dx.doi.org/10.1007/s10515-011-0093-0>.
AR
2a análise
Continua na próxima página
189
Referência
1a análise
TOPÇU, O.; ADAK, M.; OĞUZTÜZÜN, H. Metamodeling live sequence charts for code generation.
Software & Systems Modeling, Springer-Verlag, v. 8, n. 4, p. 567–583, 2009. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-009-0113-8>.
AR
SYRIANI, E.; VANGHELUWE, H.; LASHOMB, B. T-Core: a framework for custom-built model
transformation engines. Software & Systems Modeling, Springer Berlin Heidelberg, p. 1–29, 2013.
ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-0130370-4>.
AR
LUTZ, R. et al. Using obstacle analysis to identify contingency requirements on an unpiloted aerial
vehicle. Requirements Engineering, Springer-Verlag, v. 12, n. 1, p. 41–54, 2007. ISSN 0947-3602.
Disponível em: <http://dx.doi.org/10.1007/s00766-006-0039-4>.
AR
MISBHAUDDIN, M.; ALSHAYEB, M. Extending the uml use case metamodel with behavioral information to facilitate model analysis and interchange. Software & Systems Modeling, Springer-Verlag,
p. 1–26, 2013. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-013-0333-9>.
AR
SOUSA, T.; SNOOK, C.; SILVA, P. A proposal for extending UML-B to support a conceptual model.
Innovations in Systems and Software Engineering, Springer-Verlag, v. 7, n. 4, p. 293–301, 2011. ISSN
1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-011-0169-9>.
AR
BALLEJOS, L.; MONTAGNA, J. Method for stakeholder identification in interorganizational environments. Requirements Engineering, Springer-Verlag, v. 13, n. 4, p. 281–297, 2008. ISSN 0947-3602.
Disponível em: <http://dx.doi.org/10.1007/s00766008-0069-1>.
AR
BALLEJOS, L.; MONTAGNA, J. Method for stakeholder identification in interorganizational environments. Requirements Engineering, Springer-Verlag, v. 13, n. 4, p. 281–297, 2008. ISSN 0947-3602.
Disponível em: <http://dx.doi.org/10.1007/s00766008-0069-1>.
AR
PETRIU, D. B.; WOODSIDE, M. An intermediate metamodel with scenarios and resources for generating performance models from UML designs. Software & Systems Modeling, Springer-Verlag, v.
6, n. 2, p. 163–184, 2007. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-0060026-8>.
AR
HATTORI, L.; LANZA, M.; ROBBES, R. Refining code ownership with synchronous changes. Empirical Software Engineering, Springer US, v. 17, n. 4-5, p. 467–499, 2012. ISSN 1382-3256. Disponível
em: <http://dx.doi.org/10.1007/s10664-010-9145-5>.
AR
FRASER, G.; WOTAWA, F. Using model-checkers to generate and analyze property relevant test-cases.
Software Quality Journal, Springer US, v. 16, n. 2, p. 161–183, 2008. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-007-9031-6>.
AR
KALLONIATIS, C.; MOURATIDIS, H.; ISLAM, S. Evaluating cloud deployment scenarios based on
security and privacy requirements. Requirements Engineering, Springer-Verlag, p. 1–21, 2013. ISSN
0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-013-0166-7>.
AR
THANH, T.; IWAKIRI, M. A proposal of digital rights management based on incomplete cryptography
using invariant huffman code length feature. Multimedia Systems, Springer-Verlag, p. 1–16, 2013.
ISSN 0942-4962. Disponível em: <http://dx.doi.org/10.1007/s00530-013-0327-z>.
AR
LÓPEZ, T. S. et al. Adding sense to the internet of things. Personal and Ubiquitous Computing, Springer-Verlag, v. 16, n. 3, p. 291–308, 2012. ISSN 1617-4909. Disponível em:
<http://dx.doi.org/10.1007/s00779-011-0399-8>.
AR
LAWRIE, D.; FEILD, H.; BINKLEY, D. Quantifying identifier quality: an analysis of trends. Empirical
Software Engineering, Kluwer Academic Publishers-Plenum Publishers, v. 12, n. 4, p. 359–388, 2007.
ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-006-9032-2>.
AR
HORVÁTH, A.; VARRÓ, D. Dynamic constraint satisfaction problems over models. Software & Systems Modeling, Springer-Verlag, v. 11, n. 3, p. 385–408, 2012. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-010-0185-5>.
AR
RAO, L.; OSEI-BRYSON, K.-M. An approach for incorporating quality-based cost–benefit analysis
in data warehouse design. Information Systems Frontiers, Springer US, v. 10, n. 3, p. 361–373, 2008.
ISSN 1387-3326. Disponível em: <http://dx.doi.org/10.1007/s10796-008-9077-4>.
AR
RALPH, P. The illusion of requirements in software development. Requirements Engineering, Springer London, v. 18, n. 3, p. 293–296, 2013. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-012-0161-4>.
AR
2a análise
Continua na próxima página
190
Referência
1a análise
OLSSON, T. et al. Expected user experience of mobile augmented reality services: a user study in
the context of shopping centres. Personal and Ubiquitous Computing, Springer-Verlag, v. 17, n. 2, p.
287–304, 2013. ISSN 1617-4909. Disponível em: <http://dx.doi.org/10.1007/s00779-011-0494-x>.
AR
CHOI, Y. From NuSMV to SPIN: Experiences with model checking flight guidance systems. Formal
Methods in System Design, Springer US, v. 30, n. 3, p. 199–216, 2007. ISSN 0925-9856. Disponível
em: <http://dx.doi.org/10.1007/s10703-006-0027-9>.
AR
VITVAR, T. et al. Semantically-enabled service oriented architecture : concepts, technology and application. Service Oriented Computing and Applications, Springer- Verlag, v. 1, n. 2, p. 129–154, 2007.
ISSN 1863-2386. Disponível em: <http://dx.doi.org/10.1007/s11761-007-0009-9>.
AR
CHAUDRON, M.; HEIJSTEK, W.; NUGROHO, A. How effective is UML modeling? Software &
Systems Modeling, Springer-Verlag, v. 11, n. 4, p. 571–580, 2012. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-012-0278-4>.
AR
JÉZÉQUEL, J.-M. et al. Bridging the chasm between MDE and the world of compilation. Software &
Systems Modeling, Springer-Verlag, v. 11, n. 4, p. 581–597, 2012. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-012-0266-8>.
AR
GIBSON, J.; RAFFY, J.-L.; LALLET, E. Formal object-oriented development of a voting system test
oracle. Innovations in Systems and Software Engineering, Springer-Verlag, v. 7, n. 4, p. 237–245, 2011.
ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-011-0167-y>.
AR
PETRENKO, A.; SIMAO, A.; MALDONADO, J. Model-based testing of software and systems: recent advances and challenges. International Journal on Software Tools for Technology
Transfer, Springer-Verlag, v. 14, n. 4, p. 383–386, 2012. ISSN 1433-2779. Disponível em:
<http://dx.doi.org/10.1007/s10009-012-0240-3>.
AR
OLMOS, K.; RODAS, J. KMoS-RE: knowledge management on a strategy to requirements engineering. Requirements Engineering, Springer London, p. 1–20, 2013. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-013-0178-3>.
AR
JONES, A. A framework for the management of information security risks. BT Technology Journal,
Kluwer Academic Publishers-Consultants Bureau, v. 25, n. 1, p. 30–36, 2007. ISSN 1358-3948. Disponível em: <http://dx.doi.org/10.1007/s10550-007-0005-9>.
AR
WERMELINGER, M. et al. Assessing architectural evolution: a case study. Empirical Software
Engineering, Springer US, v. 16, n. 5, p. 623–666, 2011. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-011-9164-x>.
AR
HAMID, I. et al. Automatic framework generation for hard real-time applications. Innovations in Systems and Software Engineering, Springer-Verlag, v. 4, n. 1, p. 107–122, 2008. ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-008-0044-5>.
AR
SIMMONDS, J.; BEN-DAVID, S.; CHECHIK, M. Monitoring and recovery for web service applications. Computing, Springer Vienna, v. 95, n. 3, p. 223–267, 2013. ISSN 0010-485X. Disponível em:
<http://dx.doi.org/10.1007/s00607-012-0215-y>.
AR
GOMES, A. et al. Constructive model-based analysis for safety assessment. International Journal on
Software Tools for Technology Transfer, Springer-Verlag, v. 14, n. 6, p. 673–702, 2012. ISSN 14332779. Disponível em: <http://dx.doi.org/10.1007/s10009-012- 0238-x>.
AR
KHOMH, F. et al. An exploratory study of the impact of antipatterns on class change- and faultproneness. Empirical Software Engineering, Springer US, v. 17, n. 3, p. 243–275, 2012. ISSN 13823256. Disponível em: <http://dx.doi.org/10.1007/s10664-011-9171-y>.
AR
IDANI, A.; LEDRU, Y. Object oriented concepts identification from formal b specifications. Formal
Methods in System Design, Springer US, v. 30, n. 3, p. 217–232, 2007. ISSN 0925-9856. Disponível
em: <http://dx.doi.org/10.1007/s10703-006-0030-1>.
AR
automatically generated model-based tests. Automated Software Engineering, Kluwer Academic
Publishers-Plenum Publishers, v. 14, n. 1, p. 37–57, 2007. ISSN 0928-8910. Disponível em:
<http://dx.doi.org/10.1007/s10515-006-0004-y>.
AR
SILVA, F. et al. Replication of empirical studies in software engineering research: a systematic mapping
study. Empirical Software Engineering, Springer US, p. 1–57, 2012. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-012-9227-7>.
AR
2a análise
Continua na próxima página
191
Referência
1a análise
JACQUEL, M. et al. Verifying B proof rules using deep embedding and automated theorem proving. Software & Systems Modeling, Springer-Verlag, p. 1–19, 2013. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-013-0322-z>.
AR
BRICKELL, E.; CHEN, L.; LI, J. Simplified security notions of direct anonymous attestation and a
concrete scheme from pairings. International Journal of Information Security, Springer-Verlag, v. 8, n.
5, p. 315–330, 2009. ISSN 1615-5262. Disponível em: <http://dx.doi.org/10.1007/s10207-009-00763>.
AR
CALERO, C.; CARO, A.; PIATTINI, M. An applicable data quality model for web portal data consumers. World Wide Web, Springer US, v. 11, n. 4, p. 465–484, 2008. ISSN 1386-145X. Disponível em:
<http://dx.doi.org/10.1007/s11280-008-0048-y>.
AR
BORGIDA, A. How knowledge representation meets software engineering (and often databases). Automated Software Engineering, Springer US, v. 14, n. 4, p. 443–464, 2007. ISSN 0928-8910. Disponível
em: <http://dx.doi.org/10.1007/s10515-007-0018-0>.
AR
SHIN, Y.; WILLIAMS, L. Can traditional fault prediction models be used for vulnerability prediction?
Empirical Software Engineering, Springer US, v. 18, n. 1, p. 25–59, 2013. ISSN 1382-3256. Disponível
em: <http://dx.doi.org/10.1007/s10664-011-9190-8>.
AR
BECK, R. et al. Network effects as drivers of individual technology adoption: Analyzing adoption and
diffusion of mobile communication services. Information Systems Frontiers, Springer US, v. 10, n. 4,
p. 415–429, 2008. ISSN 1387-3326. Disponível em: <http://dx.doi.org/10.1007/s10796-008-9100-9>.
AR
SVETINOVIC, D. et al. Unified use case statecharts: case studies. Requirements Engineering, Springer-Verlag, v. 12, n. 4, p. 245–264, 2007. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-007-0053-1>.
AR
LUCIA, A. D. et al. An experimental comparison of ER and UML class diagrams for data modelling. Empirical Software Engineering, Springer US, v. 15, n. 5, p. 455–492, 2010. ISSN 1382-3256.
Disponível em: <http://dx.doi.org/10.1007/s10664-009-9127-7>.
AR
HASSINE, J.; RILLING, J.; DSSOULI, R. Use case maps as a property specification language. Software & Systems Modeling, Springer-Verlag, v. 8, n. 2, p. 205–220, 2009. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-007-0076-6>.
AR
PHALP, K.; VINCENT, J.; COX, K. Assessing the quality of use case descriptions. Software Quality
Journal, Kluwer Academic Publishers-Plenum Publishers, v. 15, n. 1, p. 69–97, 2007. ISSN 0963-9314.
Disponível em: <http://dx.doi.org/10.1007/s11219-006- 9006-z>.
AR
BINKLEY, D. et al. The impact of identifier style on effort and comprehension. Empirical Software Engineering, Springer US, v. 18, n. 2, p. 219–276, 2013. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-012-9201-4>.
AR
NELSON, E. et al. Ancillary study management systems: a review of needs. BMC Medical Informatics and Decision Making, BioMed Central, v. 13, n. 1, p. 1–17, 2013. Disponível em:
<http://dx.doi.org/10.1186/1472-6947-13-5>.
AR
DERBEK, V. et al. A UHF RFID measurement and evaluation test system. E & I Elektrotechnik und
Informationstechnik, Springer-Verlag, v. 124, n. 11, p. 384–390, 2007. ISSN 0932-383X. Disponível
em: <http://dx.doi.org/10.1007/s00502-007-0482-z>.
AR
ABDELHALIM, I.; SCHNEIDER, S.; TREHARNE, H. An integrated framework for checking the
behaviour of FMUL models using CSP. International Journal on Software Tools for Technology Transfer, Springer Berlin Heidelberg, v. 15, n. 4, p. 375–396, 2013. ISSN 1433-2779. Disponível em:
<http://dx.doi.org/10.1007/s10009-012-0243-0>.
AR
THOMAS, S. et al. Static test case prioritization using topic models. Empirical Software Engineering,
Springer US, p. 1–31, 2012. ISSN 1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-0129219-7>.
AR
RASHVAND, H.; HSIAO, K.-F. Smartphone intelligent applications: a brief review. Multimedia Systems, Springer Berlin Heidelberg, p. 1–17, 2013. ISSN 0942-4962. Disponível em:
<http://dx.doi.org/10.1007/s00530-013-0335-z>.
AR
LAI, W.; CHIU, D.; FENG, Z. A collaborative food safety service agent architecture with alerts and
trust. Information Systems Frontiers, Springer US, v. 15, n. 4, p. 599–612, 2013. ISSN 1387-3326.
Disponível em: <http://dx.doi.org/10.1007/s10796-012-9382-9>.
AR
2a análise
Continua na próxima página
192
Referência
1a análise
CHIPRIANOV, V. et al. Extending enterprise architecture modeling languages for domain specificity
and collaboration: application to telecommunication service design. Software & Systems Modeling,
Springer-Verlag, p. 1–12, 2012. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270012-0298-0>.
AR
ESMAEILSABZALI, S. et al. Deconstructing the semantics of big-step modelling languages. Requirements Engineering, Springer-Verlag, v. 15, n. 2, p. 235–265, 2010. ISSN 0947-3602. Disponível em:
<http://dx.doi.org/10.1007/s00766-010-0102-z>.
AR
FRANCE, R. Fair treatment of evaluations in reviews. Software & Systems Modeling, Springer-Verlag,
v. 7, n. 3, p. 253–254, 2008. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-0080096-x>.
AR
GEORGE, V.; SEBASTIAN, M. Remote internet voting: developing a secure and efficient frontend. CSI Transactions on ICT, Springer India, p. 1–11, 2013. ISSN 2277-9078. Disponível em:
<http://dx.doi.org/10.1007/s40012-013-0021-5>.
AR
KOEBERL, P. et al. A practical device authentication scheme using SRAM PUFs. Journal of Cryptographic Engineering, Springer-Verlag, v. 2, n. 4, p. 255–269, 2012. ISSN 2190-8508. Disponível em:
<http://dx.doi.org/10.1007/s13389-012-0043-1>.
AR
SANTOS, R.; OLIVEIRA, K.; SILVA, W. Evaluating the service quality of software providers appraised in CMM/CMMI. Software Quality Journal, Springer US, v. 17, n. 3, p. 283–301, 2009. ISSN
0963-9314. Disponível em: <http://dx.doi.org/10.1007/s11219-008- 9065-4>.
AR
STRASSNER, J. et al. The design of a novel context-aware policy model to support machine-based
learning and reasoning. Cluster Computing, Springer US, v. 12, n. 1, p.17–43, 2009. ISSN 1386-7857.
Disponível em: <http://dx.doi.org/10.1007/s10586-008- 0069-4>.
AR
VALKENHOEF, G. et al. Deficiencies in the transfer and availability of clinical trials evidence: a review
of existing systems and standards. BMC Medical Informatics and Decision Making, BioMed Central,
v. 12, n. 1, p. 1–11, 2012. Disponível em: <http://dx.doi.org/10.1186/1472-6947-12-95>.
AR
CARRÉ, B.; VANWORMHOUDT, G.; CARON, O. From subsets of model elements to submodels.
Software & Systems Modeling, Springer-Verlag, p. 1–27, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-013-0340-x>.
AR
PHALP, K. et al. The role of comprehension in requirements and implications for use case descriptions.
Software Quality Journal, Springer US, v. 19, n. 2, p. 461–486, 2011. ISSN 0963-9314. Disponível em:
<http://dx.doi.org/10.1007/s11219-010-9123-6>.
AR
KLOUKINAS, C.; YOVINE, S. A model-based approach for multiple QoS in scheduling: from models
to implementation. Automated Software Engineering, Springer US, v. 18, n. 1, p. 5–38, 2011. ISSN
0928-8910. Disponível em: <http://dx.doi.org/10.1007/s10515- 010-0074-8>.
AR
SHIN, Y. et al. On the use of calling structure information to improve fault prediction. Empirical Software Engineering, Springer US, v. 17, n. 4-5, p. 390–423, 2012. ISSN 1382-3256. Disponível em:
<http://dx.doi.org/10.1007/s10664-011-9165-9>.
AR
GUAJARDO, J. et al. Anti-counterfeiting, key distribution, and key storage in an ambient world via
physical unclonable functions. Information Systems Frontiers, Springer US, v. 11, n. 1, p. 19–41, 2009.
ISSN 1387-3326. Disponível em: <http://dx.doi- .org/10.1007/s10796-008-9142-z>.
AR
GERMAIN-RENAUD, C. et al. Scheduling for responsive grids. Journal of Grid Computing, Springer Netherlands, v. 6, n. 1, p. 15–27, 2008. ISSN 1570-7873. Disponível em:
<http://dx.doi.org/10.1007/s10723-007-9086-4>.
AR
DELAHAYE, D.; ÉTIENNE, J.-F.; DONZEAU-GOUGE, V. V. A formal and sound transformation
from focal to uml: an application to airport security regulations. Innovations in Systems and Software Engineering, Springer-Verlag, v. 4, n. 3, p. 267–274, 2008. ISSN 1614-5046. Disponível em:
<http://dx.doi.org/10.1007/s11334-008-0060-5>.
AR
SINNREICH, H.; WIMMREUTER, W. Communications on the web. E & I Elektrotechnik und Informationstechnik, Springer-Verlag, v. 127, n. 6, p. 187–194, 2010. ISSN 0932-383X. Disponível em:
<http://dx.doi.org/10.1007/s00502-010-0742-l>.
AR
BAVOTA, G. et al. A fine-grained analysis of the support provided by UML class diagrams and ER
diagrams during data model maintenance. Software & Systems Modeling, Springer-Verlag, p. 1–20,
2013. ISSN 1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-012-0312-6>.
AR
2a análise
Continua na próxima página
193
Referência
1a análise
2a análise
WIMMREUTER, W. Regulatory challenges for the transition of public telephony to the internet. E
& I Elektrotechnik und Informationstechnik, Springer Vienna, v. 129, n. 6, p. 407–412, 2012. ISSN
0932-383X. Disponível em: <http://dx.doi.org/10.1007/s00502-012- 0054-8>.
AR
URBAH, E. et al. EDGeS: Bridging EGEE to BOINC and XtremWeb. Journal of Grid Computing, Springer Netherlands, v. 7, n. 3, p. 335–354, 2009. ISSN 1570-7873. Disponível em:
<http://dx.doi.org/10.1007/s10723-009-9137-0>.
AR
CHU, C.-H. et al. Stabilization and extraction of 2d barcodes for camera phones. Multimedia Systems, Springer-Verlag, v. 17, n. 2, p. 113–133, 2011. ISSN 0942-4962. Disponível em:
<http://dx.doi.org/10.1007/s00530-010-0206-9>.
AR
CHOI, J.-W.; OH, D.-I. Tag-only aging-counter localization for the R-LIM2 system. Information
Systems Frontiers, Springer US, v. 13, n. 1, p. 127–137, 2011. ISSN 1387-3326. Disponível em:
<http://dx.doi.org/10.1007/s10796-009-9161-4>.
AR
MOHAUPT, P.; BERGMAN, A. A new concept for test equipment for testing large HV and UHV cables on-site. E & I Elektrotechnik und Informationstechnik, Springer-Verlag, v. 127, n. 12, p. 350–353,
2010. ISSN 0932-383X. Disponível em: <http://dx.doi.org/10.1007/s00502-010-0790-6>.
AR
WU, C.-C.; CHANG, C.-C.; LIN, I.-C. New Sealed-Bid Electronic Auction with Fairness, Security and
Efficiency. Journal of Computer Science and Technology, Springer US, v. 23, n. 2, p. 253–264, 2008.
ISSN 1000-9000. Disponível em: <http://dx.doi.org/10.1007/s11390-008-9127-x>.
AR
THIERRY-MIEG, Y.; HILLAH, L.-M. UML behavioral consistency checking using instantiable Petri
nets. Innovations in Systems and Software Engineering, Springer-Verlag, v. 4, n. 3, p. 293–300, 2008.
ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-008-0065-0>.
AR
ZHU, H. et al. PPAS: privacy protection authentication scheme for VANET. Cluster Computing, Springer US, p. 1–14, 2013. ISSN 1386-7857. Disponível em: <http://dx.doi- .org/10.1007/s10586-0130260-0>.
AR
JARA, A.; ZAMORA, M.; SKARMETA, A. Drug identification and interaction checker based on IoT
to minimize adverse drug reactions and improve drug compliance. Personal and Ubiquitous Computing,
Springer-Verlag, p. 1–13, 2012. ISSN 1617-4909. Disponível em: <http://dx.doi.org/10.1007/s00779012-0622-2>.
AR
ROSE, L. et al. Genericity for model management operations. Software & Systems Modeling, Springer-Verlag, v. 12, n. 1, p. 201–219, 2013. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-011-0203-2>.
AR
ALMEIDA, J. P. A.; IACOB, M.-E.; ECK, P. Requirements traceability in model-driven development:
Applying model and transformation conformance. Information Systems Frontiers, Springer US, v. 9, n.
4, p. 327–342, 2007. ISSN 1387-3326. Disponível em: <http://dx.doi.org/10.1007/s10796-007-90383>.
AR
MEIJLER, T. et al. Supporting fine-grained generative model-driven evolution. Software & Systems Modeling, Springer-Verlag, v. 9, n. 3, p. 403–424, 2010. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-009-0144-1>.
AR
MAYR, C.; ZDUN, U.; DUSTDAR, S. Enhancing traceability of persistent data access flows in
process-driven SOAs. Distributed and Parallel Databases, Springer US, v. 31, n. 1, p. 1–45, 2013.
ISSN 0926-8782. Disponível em: <http://dx.doi.org/10.1007/s10619-012- 7102-6>.
AR
WINKLER, S.; PILGRIM, J. A survey of traceability in requirements engineering and model-driven
development. Software and Systems Modeling, Springer-Verlag, v. 9, n. 4, p. 529–565, 2010. ISSN
1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270009-0145-0>.
AS
1
HAYES, J. et al. REquirements TRacing On target (RETRO): improving software maintenance through
traceability recovery. Innovations in Systems and Software Engineering, Springer-Verlag, v. 3, n. 3, p.
193–202, 2007. ISSN 1614-5046. Disponível em: <http://dx.doi.org/10.1007/s11334-007-0024-1>.
AS
1
JIRAPANTHONG, W.; ZISMAN, A. XTraQue: traceability for product line systems. Software &
Systems Modeling, Springer-Verlag, v. 8, n. 1, p. 117–144, 2009. ISSN 1619-1366. Disponível em:
<http://dx.doi.org/10.1007/s10270-007-0066-8>.
AS
Selecionado
LORMANS, M.; DEURSEN, A.; GROSS, H.-G. An industrial case study in reconstructing requirements views. Empirical Software Engineering, Springer US, v. 13, n. 6, p. 727–760, 2008. ISSN
1382-3256. Disponível em: <http://dx.doi.org/10.1007/s10664-008-9078-4>.
AS
3
Continua na próxima página
194
Referência
1a análise
2a análise
MERILINNA, J.; YRJÖNEN, A.; RÄTY, T. NFR+ framework method to support bi-directional traceability of non-functional requirements. Computer Science - Research and Development, SpringerVerlag, p. 1–15, 2012. ISSN 1865-2034. Disponível em: <http://dx.doi.org/10.1007/s00450-012-02055>.
AS
Selecionado
SULTANOV, H.; HAYES, J.; KONG, W. K. Application of Swarm Techniques to Requirements Tracing. Requirements Engineering, Springer-Verlag, v. 16, n.3, p. 209-226, 2011. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-011-0121-4>.
AS
1
MURTA, L.; HOEK, A.; WERNER, C. Continuous and automated evolution of architecture-toimplementation traceability links. Automated Software Engineering, Springer US, v. 15, n. 1, p.
75–107, 2008. ISSN 0928-8910. Disponível em: <http://dx.doi.org/10.1007/s10515-007-0020-6>.
AS
Selecionado
PAIGE, R. et al. Rigorous identification and encoding of trace-links in model-driven engineering. Software & Systems Modeling, Springer-Verlag, v. 10, n. 4, p. 469–487, 2011. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-010-0158-8>.
AS
1
LOCKERBIE, J. et al. Exploring the impact of software requirements on system-wide goals: a method
using satisfaction arguments and i* goal modelling. Requirements Engineering, Springer-Verlag, v. 17,
n. 3, p. 227–254, 2012. ISSN 0947-3602. Disponível em: <http://dx.doi.org/10.1007/s00766-011-01388>.
AS
1
DANG, H. L.; DUBOIS, H.; GÉRARD, S. Towards a traceability model in a MARTEbased methodology for real-time embedded systems. Innovations in Systems and Software Engineering, Springer-Verlag, v. 4, n. 3, p. 189–193, 2008. ISSN 1614-5046. Disponível em:
<http://dx.doi.org/10.1007/s11334-008-0053-4
AS
2
SCHWARZ, H.; EBERT, J.; WINTER, A. Graph-based traceability: a comprehensive approach. Software & Systems Modeling, Springer-Verlag, v. 9, n. 4, p. 473–492, 2010. ISSN 1619-1366. Disponível
em: <http://dx.doi.org/10.1007/s10270-009-0141-4>.
AS
Selecionado
MÄDER, P.; CLELAND-HUANG, J. A visual language for modeling and executing traceability queries. Software & Systems Modeling, Springer Berlin Heidelberg, v. 12, n. 3, p. 537–553, 2013. ISSN
1619-1366. Disponível em: <http://dx.doi.org/10.1007/s10270-012-0237-0>.
AS
2
GOKNIL, A. et al. Semantics of trace relations in requirements models for consistency checking and
inferencing. Software & Systems Modeling, Springer-Verlag, v. 10, n. 1, p. 31–54, 2011. ISSN 16191366. Disponível em: <http://dx.doi.org/10.1007/s10270-009- 0142-3>.
AS
1
195
APÊNDICE B – DETALHAMENTO DOS TRABALHOS
SELECIONADOS NA 2A ANÁLISE - REVISÃO SISTEMÁTICA
Referência
Título
(DELATER; PAECH, 2013)
Analyzing the tracing of requirements and source code during
software development
Author(es)
Delater, Alexander and Paech, Barbara
Resumo da abordagem de rastreabilidade utilizada
Parte da implementação do modelo MUSE usado na UNICASE (ide do Eclipse) que rastreia requisitos e artefatos de projeto.
Neste trabalho os autores incluem a rastreabilidade até o código fonte. Faz este rastreamento de forma semi-automática. Captura vínculos de rastreabilidade entre os requisitos
e código na medida que o desenvolvimento avança, usando artefatos de gerenciamento de
projetos chamados de itens de trabalho (work items). Define três processos de criação de
vínculos de rastreabilidade.
Neste trabalho, os autores relatam os resultados da aplicação desta abordagem em projetos
realizados por alunos da graduação
Padrão de Ciclo de Vida
Cascata e Iterativo Incremental
Padrão de Modelagem
MUSE (Management-based Unified Software Engineering) - não inclui nenhum modelo
de Engenharia
Artefatos Obrigatórios
Requisito funcional - Feature - Sprint - Work Item - Developer - Revision - Code File
Artefatos Rastreados
Requisitos funcionais, artefatos de projeto e código fonte
Ferramenta Utilizada
Obrigatória na abordagem - UNICASE (ide do Eclipse)
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Validado em um exemplo fictício
196
Referência
Título
Author(es)
(FERREIRA; BARROS, 2011)
Traceability between function point and source code
Vianna Ferreira, Paulo José Azevedo and Barros, Márcio de Oliveira
Resumo da abordagem de rastreabilidade utilizada
Abordagem para gerar elos de rastreabilidade entre pontos por função e código fonte.
Neste trabalho os autores propõem uma abordagem de rastreabilidade capaz de corar uma
ponte (elo) entre os pontos por função definidos e os códigos fonte construídos.
O objetivo é ter uma visão clara do esforço gasto no desenvolvimento e manutenção dos
códigos fonte relacionado a cada ponto por função para extrair o esforço que cada um
gerou. Os autores propõem que esta técnica pode apoiar negociações entre organizações
de desenvolvimento e seus clientes sobre alterações feitas nos sistemas de informação.
Padrão de Ciclo de Vida
Não especifica, no entanto, para medir pontos por função, com é necessária a modelagem
dos dados antes do desenvolvimento, é sugerido que se use o modelo cascata.
Padrão de Modelagem
Estimativa por ponto por função e modelagem relacional
Artefatos Obrigatórios
Funcionalidades - Modelo Físico de Dados - Casos de Teste - Funções Transacionais
(packages, arquivos, classes ou linhas de código)
Artefatos Rastreados
Modelo de pontos por função, esquema de dados e módulos de código
Ferramenta Utilizada
Não indica
Abrangência
( ) Produto
(x) Projeto
( ) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Validado em três exemplos de aplicações
197
Referência
Título
Author(es)
(CLELAND-HUANG; HAYES; DOMEL, 2009)
Model-based traceability
Cleland-Huang, Jane and Hayes, Jane Huffman and Domel, J.
M.
Resumo da abordagem de rastreabilidade utilizada
Abordagem para gerenciar estratégias de rastreabilidade e pesquisas em que os stakeholders possam planejar, gerar e executar estratégias de rastreabilidade em um modelo de
desenvolvimento.
Neste trabalho, os autores apresentam uma abordagem baseada em modelo projetado para
ajudar as organizações a obter o benefício a partir dos registros que eles desenvolvem e
para permitir que os participantes do projeto possam planejar, criar e executar estratégias
de rastreamento em um ambiente de modelagem gráfica. A abordagem inclui uma notação
padrão para a captura de decisões estratégicas de rastreabilidade na forma de um gráfico,
e também a notação para a modelagem de consultas de rastreamento reutilizáveis usando
diagramas de sequência aumentada.
Todos os elementos do modelo, incluindo dados específicos do projeto, são representados
usando XML. A abordagem é demonstrada através de exemplos de um projeto de simulador de tráfego composta de requisitos, diagramas de classe UML, código, casos de teste
e resultados de casos de teste.
Padrão de Ciclo de Vida
Não especifica
Padrão de Modelagem
Não determina um padrão no trabalho. No entanto, sugere pelo menos três camadas de
decomposição dos requisitos para aplicar seus conceitos
Artefatos Obrigatórios
Precisa documentar todos os artefatos que se deseja rastrear. O formato é livre, pois o
modelo considera as camadas. As camadas obrigatórias são: Strategic, Document Mangement, Stored Query, Executable Layer.
Artefatos Rastreados
Primitive Traces, Composite traceability paths, Composite trace queries
Ferramenta Utilizada
BASEX
Abrangência
( ) Produto
(x) Projeto
( ) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Validado em um aplicativo real
198
Referência
Título
(DUBOIS; PERALDI-FRATI; LAKHAL, 2010)
A Model for Requirements Traceability in a Heterogeneous
Model-Based Design Process: Application to Automotive Embedded Systems
Author(es)
Dubois, H. and Peraldi-Frati, M. and Lakhal, F.
Resumo da abordagem de rastreabilidade utilizada
O trabalho propõe o metamodelo DARWIN4Req para os requisitos de rastreabilidade,
com base em três fluxos independentes (Modelo de requisitos, modelo de solução e modelo de verificação e validação para projeto (design) de sistemas embarcados).
O metamodelo estabelece uma ligação entre esses fluxos e oferece total rastreabilidade de
requisitos, incluindo os estabelecidos para os modelos heterogêneos. O objetivo é resolver
o problema de heterogeneidade de especificação para diferentes partes de um sistema.
Uma aplicação automotiva ilustra a abordagem proposta baseada em UML-perfis de tal
forma que SysML, EAST-ADL2 e MARTE para o projeto e em SIMULINK, SyNDEx e
Timesquare para atividades de V & V.
Padrão de Ciclo de Vida
Não especifica, pelas características observadas no texto, sugere cascata
Padrão de Modelagem
Determina que sejam elaborados requisitos, e artefatos do projeto Orientado a Objetos
modelados por padrões UML, como classes.
Artefatos Obrigatórios
Exige que os requisitos sejam identificados e que os artefatos de projeto e de verificação
e validação do produto existam para rastrear
Artefatos Rastreados
Requisitos com requisitos e Requisitos com modelo do projeto (design) e classes de validação
Ferramenta Utilizada
DOORS
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Validado em uma aplicação real
199
Referência
(ZIFTCI; KRUEGER, 2011)
Título
Tracing requirements to tests with high precision and recall
Author(es)
Ziftci, Celal and Krueger, Ingolf
Resumo da abordagem de rastreabilidade utilizada
O trabalho propõe uma abordagem para criar automaticamente links de rastreabilidade de
requisitos entre os requisitos e os casos de teste.
A abordagem possui duas fases: 1- Preparação da entrada dos dados (Identificar requisitos
ou features, rodar cenários e reunir os links gerados para cada feature e rodar testes e
reunir os links gerados para cada teste). 2 - Encontrar os marcadores de cada feature,
reunir cada teste com a feature executada e criar a matrix de rastreabilidade. Estas duas
fases formam a estrutura da ferramenta FORTA que é utilizada pelos autores do trabalho.
Além de apresentar a abordagem, o trabalho reserva parte para apresentar os resultados
da avaliação em projetos reais. A abordagem foi avaliada em um sistema de bate papo
(Apache Pool e Apache Log4j. O trabalho relata que os níveis de precisão/recuperação
superiores a de outras abordagens quando testadas no mesmo sistema.
Padrão de Ciclo de Vida
Não influencia, pois é executado depois do software estar concluído
Padrão de Modelagem
Não é restrito a nenhum padrão, no entanto, é necessário ter os requisitos e os casos de
teste identificados
Artefatos Obrigatórios
Identificar requisitos funcionais, criar cenários e executá-los.
Artefatos Rastreados
Requisitos e testes
Ferramenta Utilizada
FORTA - Feature Oriented Requirements Traceability Analysis
Abrangência
(x) Produto
( )Projeto
( ) Ambos
Etapa do Ciclo de Vida (x) Produto Pronto
( ) Construção do Projeto
Contexto de Validação
Validado em um exemplo real (com algumas limitações explicadas no trabalho)
200
Referência
Título
Author(es)
(ASUNCION; FRAN COIS; TAYLOR, 2007)
An end-to-end industrial software traceability tool
Asuncion, Hazeline U. and François, Frédéric and Taylor, Richard N.
Resumo da abordagem de rastreabilidade utilizada
A abordagem proposta pelos autores define o conceito de abordagem textitend-to-end
como sendo uma rastreabilidade global que se estende por todo o ciclo de vida do projeto
de desenvolvimento, deste os requisitos até os testes. A abordagem se dedica a recuperar
traços de rastreabilidade baseados em texto. O objetivo do trabalho é integrar a abordagem
end-to-end com o processo de rastreabilidade. Juntamente com a abordagem, uma ferramenta é proposta e construída no contexto de uma empresa de médio porte que produz
software para automação industrial.
A abordagem proposta foi elaborada e conduzida para resolver o problema de rastreabilidade em um contexto estrito usando conceitos genéricos de rastreabilidade. Para que
funcione, é necessário que o conjunto de condições sejam próximas as da empresa onde
a abordagem foi aplicada, considerando ferramentas de desenvolvimento, processo, etc.
Abordagem de rastreabilidade para uma empresa específica que produz um software para
a área industrial.
Padrão de Ciclo de Vida
Não especifica
Padrão de Modelagem
Usar os artefatos propostos na abordagem que incluem requisitos funcionais e artefatos
da UML como casos de uso e casos de teste.
Artefatos Obrigatórios
Identificar Produto, o Projeto e Funcionalidades. Além disso, requisitos de marketing,
Casos de Uso, Requisitos Funcionais e Casos de Teste.
Artefatos Rastreados
Produto, projeto, requisitos, casos de uso e casos de teste
Ferramenta Utilizada
Obrigatória na abordagem - MS SQL, MS SharePoint e MS Office.
Abrangência
(x) Produto
( )Projeto
( ) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Validado em um exemplo real de um projeto da empresa em que o produto foi construído
201
Referência
Título
(HONG; KIM; LEE, 2010)
Requirements Management Tool with Evolving Traceability for
Heterogeneous Artifacts in the Entire Life Cycle
Author(es)
Hong, Youngki and Kim, Minho and Lee, Sang-Woong
Resumo da abordagem de rastreabilidade utilizada
O objetivo do trabalho é apresentar a ferramenta de rastreabilidade criada para atender
uma abordagem de apoiar a evolução no desenvolvimento de software através da especificação de requisitos e estabelecimento de vínculos iniciais de rastreabilidade para posterior
acompanhamento e pesquisa para encontrar os melhores candidatos para atualização de
links de rastreabilidade e suas evoluções.
A ferramenta, resultante da implementação da abordagem proposta, apresenta os resultados de forma gráfica a partir de passos que são executados ao longo do processo de
desenvolvimento do software. Primeiro, os links iniciais são criados, no entanto, com o
passar do tempo, modificações vão sendo criadas e a ferramenta apresenta (através de
um algoritmo) os artefatos candidatos para atualização desses links. O usuário decide a
atualização dos links para que o sistema fique atualizado.
A abordagem, juntamente com a ferramenta, estão sofrendo evoluções e testes mais apurados em ambientes maiores, segundo relatado pelos autores.
Padrão de Ciclo de Vida
Não especifica, e não há restrição
Padrão de Modelagem
Não é restrito a nenhum padrão, pois é um modelo genérico. Basta identificar os artefatos
a serem rastreados
Artefatos Obrigatórios
Identificar os artefatos em tempo de desenvolvimento do software. Não é integrada as
ferramentas de desenvolvimento. Funciona de forma paralela.
Artefatos Rastreados
Não há artefatos específicos, usa a estrutura: Artefato: Link: Histórico do Link e Arquivo
do artefato
Ferramenta Utilizada
Nexcore Requirement Management. Só aparece um print da tela no trabalho. Visitei o site
e não há registro da ferramenta pelo fabricante.
Abrangência
( ) Produto
(x)Projeto
( ) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Cita que a validação mostrou que abordagem proposta é melhor, mas não apresenta como
foi realizado o estudo de caso
202
Referência
Título
(MOON et al., 2007)
A Metamodeling Approach to Tracing Variability between Requirements and Architecture in Software Product Lines
Author(es)
Moon, Mikyeong and Chae, Heung Seok and Nam, Taewoo and
Yeom, Keunhyuk
Resumo da abordagem de rastreabilidade utilizada
O trabalho apresenta uma abordagem de rastreabilidade aplicada a linha de produtos.
Segundo os autores, a rastreabilidade em ambiente de linha de produtos é mais complexa
e exige mais recursos para controlá-la.
Neste trabalho, é proposto um metamodelo para apoiar as ligações da variabilidade em
requisitos e arquitetura. Dois metamodelos que representam os requisitos de domínio e
arquitetura de domínio com variabilidade são propostos. Em primeiro lugar, dois metamodelos que representam os requisitos de domínio e arquitetura de domínio com variabilidade são propostos ao estender a especificação de ativos reutilizáveis (RAS), que foi
aprovado pelo OMG (Object Management Group) para descrever os artefatos de software
reutilizáveis. Em seguida, uma abordagem para o rastreamento entre estes é apresentado
ao definir os relacionamentos de rastreabilidade entre os metamodelos desses artefatos.
Com base nos metamodelos propostos, são descritas as relações ou links entre os requisitos e arquitetura em relação à variabilidade.
Metamodelo (baseado no padrão RAS) para estruturar e manter a rastreabilidade em linhas de produtos de software entre requisitos e arquitetura de produto repeitando a variabilidade
Padrão de Ciclo de Vida
Não especifica
Padrão de Modelagem
Não é restrito a nenhum padrão.
Artefatos Obrigatórios
Artefatos de requisitos e artefatos de arquitetura, incluindo toda documentação de variabilidade (contexto, variação) que uma linha de produtos pede.
Artefatos Rastreados
artefatos (genéricos) entre os requisitos e a arquitetura, incluindo as variações (variabilidades)
Ferramenta Utilizada
Não indicada
Abrangência
(x) Produto
( )Projeto
( ) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Usa apenas exemplos através de partes de sistemas para apresentar resultados parciais da
abordagem
203
Referência
Título
(BUCHGEHER; WEINREICH, 2011)
Automatic Tracing of Decisions to Architecture and Implementation
Author(es)
Buchgeher, G. and Weinreich, R.
Resumo da abordagem de rastreabilidade utilizada
Abordagem para rastrear artefatos de requisitos e de arquitetura através de registros de
decisões na elaboração ou alteração da arquitetura ou de programação. O rastreamento é
feito através de tarefas (tasks). A rastreabilidade é definida através da análise das tarefas
que fazem as manipulações no projeto de arquitetura ou no desenvolvimento do software
Padrão de Ciclo de Vida
Em trabalhos referenciados afirma que serve bem a projetos construídos de forma incremental, no entanto, não restringe.
Padrão de Modelagem
Não é restrito a nenhum padrão.
Artefatos Obrigatórios
Requisitos, artefatos de arquitetura e atividades para elaboração do projeto com registro
de decisão sobre a arquitetura e construção do software
Artefatos Rastreados
Artefatos de requisitos e de projeto de arquitetura.
Ferramenta Utilizada
Conjunto de extensões de IDEs do Eclipse
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Em um projeto médico e na construção da ferramenta proposta pela abordagem, além de
testes internos da equipe.
204
Referência
Título
(CLELAND-HUANG et al., 2012)
Breaking the big-bang practice of traceability: Pushing timely
trace recommendations to project stakeholders
Author(es)
Cleland-Huang, J. and Mader, P. and Mirakhorli, M. and Amornborvornwong, S.
Resumo da abordagem de rastreabilidade utilizada
Propõe a evolução de uma arquitetura de rastreabilidade (proposta pelo projeto TraceLab).
A evolução inclui a identificação de candidatos (recomendação) de novas ligações de
rastreabilidade a partir do que já está mapeado no modelo ou da inclusão de novas ligações
a partir de novos artefatos incluídos.
A abordagem proposta pelos autores inclui o novo conceitos de uma obrigação de rastreamento que é usada para controlar as relações de satisfação de ligação entre um artefato
alvo e outro conjunto de artefatos. Para a implementação é usado o padrão BPMN (Business Process Model Notation).
A ferramenta apresenta um conceito de 5 camadas onde cada uma é responsável por uma
parte do processo e do armazenamento das informações da rastreabilidade. São usados
conceitos de workflow para determinar ações a partir de eventos que acontecem durante o
desenvolvimento do software para garantir a rastreabilidade.
A validação da abordagem e da ferramenta aconteceu em um exemplo ilustrativo e através de uma simulação realizada em artefatos de engenharia de software de um sistema robótico para apoiar um braço de reabilitação. A abordagem utilizou o Tracelab
(http://www.coest.org/index.php/tracelab/about-tracelab) , um ambiente avaliar soluções
de rastreabilidade.
Padrão de Ciclo de Vida
Não há relação com o modelo de desenvolvimento, pois trata os artefatos de forma separada do modelo de desenvolvimento
Padrão de Modelagem
Não é restrito a nenhum padrão.
Artefatos Obrigatórios
Os artefatos que quiser rastrear.
Artefatos Rastreados
É um modelo genérico que aceita diferentes tipos de artefatos que podem ser mapeados
Ferramenta Utilizada
Não indicada
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Em um projeto simulado. Não é um modelo operacional ainda. Não houve validação na
prática
205
Referência
Título
(SATYANANDA et al., 2007)
Identifying Traceability between Feature Model and Software
Architecture in Software Product Line using Formal Concept
Analysis
Author(es)
Satyananda, Tonny Kurniadi and Lee, Danhyung and Kang,
Sungwon and Hashmi, Sajid Ibrahim
Resumo da abordagem de rastreabilidade utilizada
Propõe rastreabilidade entre o modelo funcional (features) e o modelo de arquitetura,
considerando a variabilidade de Linha de Produto.
O trabalho propõe uma técnica de com o conceito de estrutura de treliça. São vários critérios analisados para o conceito de estrutura de treliça para identificar a rastreabilidade
entre os dois modelos (de funcionalidades e de estrutura). A técnica de decomposição
funcional é usada para identificar a rastreabilidade entre os modelos. A abordagem trabalha com três modelos: modelo de funcionalidade, modelo de arquitetura e modelo de
funcionalidades.
A abordagem tem as seguintes etapas: Descrição da funcional, Decomposição funcional
(usando a descrição da arquitetura), Criação do conceito de entrelaçamento e Análise do
entrelaçamento (gerando o mapeamento).
Padrão de Ciclo de Vida
Não especifica, pois a rastreabilidade é proposta somente entre funcionalidades e arquitetura da aplicação.
Padrão de Modelagem
Forfamel, uma base conceitual e linguagem para descrever o modelo de funcionalidades.
ACME (framework para descrever o modelo de arquitetura), Formal Concept Analysis
(FCA) para identificar os laços entre os dois modelos.
Artefatos Obrigatórios
Features (funcionalidades) considerando a variabilidade no conceito de linha de produto.
Arquitetura da aplicação no padrão ACME.
Artefatos Rastreados
Funcionalidades (features) e elementos de arquitetura da aplicação de linha de produtos
Ferramenta Utilizada
FCA tool - no entanto, não discute o uso da ferramenta neste trabalho, somente cita. Esta
ferramenta é para o framework ACME.
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Validade em um estudo de caso de um relógio digital
206
Referência
Título
(EGYED; BINDER; GRUNBACHER, 2007)
STRADA: A Tool for Scenario-Based Feature-to-Code Trace
Detection and Analysis
Author(es)
Egyed, A. and Binder, G. and Grunbacher, P.
Resumo da abordagem de rastreabilidade utilizada
STRADA, a tool for Scenario-based TRAce Detection and Analysis. Este trabalho apresenta STRADA (detecção de vestígios baseada Cenário e Análise) - uma ferramenta que
ajuda os engenheiros de software explorar traços links para o código-fonte por meio de
testes. Embora o teste é predominantemente feito para garantir a correção de um sistema
de software, STRADA demonstra um benefício secundário vital: por meio da execução
de código-fonte durante o teste que pode ser ligado a requisitos e funcionalidades, assim,
estabelece a rastreabilidade automaticamente.
A abordagem possui dois grandes capacidades:
1 - Captura de links baseado em cenários: a ferramenta observa quais os códigos fontes
são executados a partir de um teste, desta forma criando os links.
2 - Análise da rastreabilidade: como a sugestão de link não é exata, a análise da rastreabilidade auxilia os engenheiros a resolverem os problemas de links incertos.
Padrão de Ciclo de Vida
Não há relação com o modelo de desenvolvimento, pois trata os artefatos depois do software construído.
Padrão de Modelagem
Não interfere pois identifica os traços após o software implementado.
Artefatos Obrigatórios
Precisa das features documentadas para associar aos testes que são executados. Restrita a
códigos em Java e ao uso do Eclipse.
Artefatos Rastreados
Funcionalidades (features) e código fonte
Ferramenta Utilizada
STRADA (Scenario-based TRAce Detection and Analysis)
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida (x) Produto Pronto
( ) Construção do Projeto
Contexto de Validação
Vários software construídos que usaram a abordagem, como: ArgoUML, GanttProject,
Siemens Route Planner, and Video-on-Demand Player
207
Referência
Título
(MADER; GOTEL; PHILIPPOW, 2009)
Semi-automated traceability maintenance: An architectural
overview of traceMaintainer
Author(es)
Mader, P. and Gotel, O. and Philippow, I.
Resumo da abordagem de rastreabilidade utilizada
Apresenta uma revisão arquitetural da ferramenta traceMaintainer. Esta ferramenta é independente de outras ferramentas de modelagem, mas ainda está em estado inicial de
construção.
A ferramenta traceMaintainer apoia uma abordagem para a manutenção de relações pósrequisitos de rastreabilidade após as alterações feitas nos elementos do modelo rastreado.
As atualizações das relações de rastreabilidade são baseadas em regras pré-definidas, onde
cada regra se destina a reconhecer a atividade de desenvolvimento aplicada a um elemento
do modelo. É necessário esforço manual de interação do desenvolvedor. traceMaintainer
atualmente pode ser usado com uma série de ferramentas de desenvolvimento de software
comerciais e permite a atualização de rastreabilidade relações armazenados dentro dessas
ferramentas. O trabalho fornece uma visão geral da arquitetura de traceMaintainer e os
principais componentes.
Padrão de Ciclo de Vida
Não ha relação com o modelo de desenvolvimento, pois trata os artefatos independentes
do processo de construção
Padrão de Modelagem
Uso do padrão UML para expressar requisitos e modelagem
Artefatos Obrigatórios
Artefatos UML, uma base de regras que será consultada para identificar as mudanças na
rastreabilidade.
Artefatos Rastreados
Requisitos, modelos de análise e projeto (design) no padrão UML.
Ferramenta Utilizada
traceMaintainer (protótipo) - ferramenta para manutenção de rastreabilidade após alterações nos elementos do modelo rastreados.
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Não houve validação, está planejada, segundo o trabalho
208
Referência
Título
(SANCHEZ et al., 2011)
Introducing Safety Requirements Traceability Support in ModelDriven Development of Robotic Applications
Author(es)
Sanchez, P. and Alonso, D. and Rosique, F. and Alvarez, B. and
Pastor, J.A.
Resumo da abordagem de rastreabilidade utilizada
O trabalho apresenta uma abordagem que considera a rastreabilidade de requisitos de
segurança no contexto de model-driven development de serviços de robôs teleoperados.
Este trabalho apresenta uma abordagem que considera a rastreabilidade de requisitos de
segurança no contexto do desenvolvimento orientado a modelos de robôs de serviços tele
operados. A combinação da abordagem orientada para o modelo com os requisitos de segurança a rastreabilidade torna possível a construção de sistemas utilizando técnicas para
identificar automaticamente, gerenciamento e mitigação de riscos de modo a que estes sistemas sejam seguros o suficiente para trabalhar em um ambiente particular. Para garantir
as vantagens desses mecanismos, foi desenvolvido uma ferramenta que fornece aos usuários relatórios de rastreabilidade após a aplicação de transformações do modelo. Estes
relatórios permitem que os desenvolvedores determinem se todos os requisitos de segurança foram considerados ou não, o impacto da mudança de um requisito de segurança, e
como eles são considerados tanto em decisões de arquitetura quanto em implementações
de código.
Padrão de Ciclo de Vida
Deve ser seguido o padrão cascata que inclui: Identificar os perigos, riscos, especificar
requisitos de segurança, projetar arquitetura
Padrão de Modelagem
MDE (Model Driven Engineering) para modelagem. V3CMM - padrão usado para trabalhar com serviços de robôs. Específico para este contexto. O trabalho afirma que pode ser
adaptado para outros padrões.
Artefatos Obrigatórios
Requisitos (principalmente os de segurança) e outros elementos que desejam ser rastreados.
Artefatos Rastreados
Requisitos de segurança e artefatos de modelagem usando padrão UML.
Ferramenta Utilizada
Safety-Requirements-Trace-Tool (SRTT) - Ferramenta desenvolvida para rastreabilidade
de requisitos de segurança
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Exemplo ilustrativo foi usado para validar a proposta
209
Referência
(YU; JURJENS; MYLOPOULOS, 2008)
Título
Traceability for the maintenance of secure software
Author(es)
Yijun Yu and Jurjens, Jan and Mylopoulos, J.
Resumo da abordagem de rastreabilidade utilizada
O trabalho apresenta uma solução para rastreabilidade em sistemas seguros, pois justifica que as abordagens de rastreabilidade tradicionais não são suficientes para atender as
necessidades de precisão exigidas por sistemas desta natureza.
Para resolver este problema, uma técnica de rastreabilidade é proposta baseada na refatoração, que é então integrada continuamente com outras atividades de manutenção de
software.
Os autores relatam que aplicando a técnica proposta em seu trabalho, foi possível identificar falhas que geravam vulnerabilidade no sistema analisado.
Padrão de Ciclo de Vida
Não há relação com o modelo de ciclo de vida, pois é executado depois do produto pronto.
Padrão de Modelagem
Usa o padrão UML
Artefatos Obrigatórios
Precisa ter documentado os artefatos de desenvolvimento, como classes, métodos, packages no Eclipse para fazer a comparação entre o que foi recuperado e o que já estava
documentado para aumentar a confiabilidade.
Artefatos Rastreados
Objetos de construção, como classes, métodos, packages e o relacionamento entre eles.
Ferramenta Utilizada
UMLsec, combinada com IDE do Eclipse e ferramenta de integração contínua CuiseControl
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida (x) Produto Pronto
( ) Construção do Projeto
Contexto de Validação
Foi usado o protocolo de segurança da Internet SSL como estudo de caso para validar.
210
Referência
Título
(CLELAND-HUANG; MARRERO; BERENBACH, 2008)
Goal-Centric Traceability: Using Virtual Plumblines to Maintain
Critical Systemic Qualities
Author(es)
Cleland-Huang, Jane and Marrero, Will and Berenbach, Brian
Resumo da abordagem de rastreabilidade utilizada
Aborda a rastreabilidade centrada em objetivo (goal-centric traceability) onde os objetivos são mapeados e em seguida os modelos de avaliação da qualidade da aplicação são
definidos para controlar as mudanças na aplicação.
A abordagem GCT funciona como um agente que monitora se a aplicação está sendo
modificada e se as metas que anteriormente foram definidas estão sendo feridas. O GGT
possui as seguintes funcionalidades:
1-Modelo de Objetivos
2 - Conjunto de Modelos de Avaliação da Qualidade
3 - Infra-estrutura de rastreabilidade automatizada ou Rastreabilidade centrada em Meta
(Goal Centric Traceability)
4 - Algoritmo que controla a propagação de mudanças
5 - Relatório de Impacto
Padrão de Ciclo de Vida
Usa o padrão GCT que possui fases e artefatos específicos, como Goal Model, QAMs,
Artefatos de design e código.
Padrão de Modelagem
Usa o padrão de modelagem para sistemas críticos Goal-Centric Traceability que é composto por: 1 - Goal Model, 2 - Conjunto de QAMs, 3 - GCT (automated traceability
infrastructure), 4 - Algoritmo para controlar a propagação, 5 - Relatório de impacto.
Artefatos Obrigatórios
Artefatos do padrão GCT, como objetivos, modelos de avaliação da qualidade QAMs,
testes e artefatos de construção para medir o impacto de uma alteração
Artefatos Rastreados
Artefatos do padrão GCT, como objetivos, modelos de avaliação da qualidade QAMs,
testes e artefatos de construção para medir o impacto de uma alteração
Ferramenta Utilizada
Poirot (que utiliza rede probabilística), Ferramenta gráfica (desenvolvida por alunos) para
SIG (softgoal interdependency graphs, Um utilitário EBT (event-based traceability) para
ligar QAMs aos objetivos (desenvolvido em academia) e Um utilitário baseado em XML
para reavaliar os QAMs através dos gráficos.
Abrangência
(x) Produto
( )Projeto
( ) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Foram usados dois estudos de casos para validar a abordagem, ambos aplicações reais
211
Referência
Título
(MALAVOLTA; MUCCINI; REKHA, 2011)
Supporting architectural design decisions evolution through model driven engineering
Author(es)
Malavolta, Ivano and Muccini, Henry and Rekha, V. Smrithi
Resumo da abordagem de rastreabilidade utilizada
O trabalho afirma que as decisões de evolução dos modelos de desenvolvimento de software possuem uma grande importância.
O trabalho descreve a proposta de um meta modelo que serve para todas as notações usadas na modelagem. Propõe a realização de uma análise da evolução do desenvolvimento
dos modelos, capaz de identificar inconsistências que podem ocorrer durante a evolução.
A implementação é feita através de um plugin do Eclipse.
Padrão de Ciclo de Vida
Não especifica, no entanto, deve documentar o modelo de decisão de arquitetura.
Padrão de Modelagem
Modelo arquitetural de decisões de projeto (design) ou ADD. Este padrão foi adaptado
pela proposta do trabalho.
Artefatos Obrigatórios
Artefatos do padrão GCT, como objetivos, modelos de avaliação da qualidade QAMs,
testes e artefatos de construção para medir o impacto de uma alteração
Artefatos Rastreados
Requisitos, decisões de arquitetura e artefatos de arquitetura.
Ferramenta Utilizada
Cria um plugin do Eclipse, o AMMA.
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Não houve validação, está planejada, segundo o trabalho
212
Referência
Título
(SOUSA et al., 2008)
Supporting requirements in a traceability approach between business process and user interfaces
Author(es)
Sousa, Kênia and Mendonça, Hildeberto and Vanderdonckt, Jean
and Pimenta, Marcelo S.
Resumo da abordagem de rastreabilidade utilizada
O trabalho apresenta o impacto das mudanças em Processos de Negócios (BP) e interfaces
de usuário (UI) em requisitos de software através da rastreabilidade. A aplicação das alterações feitas na BP ou em sistema de interfaces de usuário podem ter um impacto sobre
os requisitos de software, que então exige atualização dos modelos relacionados, a fim de
permitir mudanças de forma coerente. O objetivo do mapeamento de requisitos de software com modelos de tarefas, como uma extensão de uma abordagem de rastreabilidade
existente, é garantir que UIs estejam alinhados com os requisitos. O trabalho propõe uma
estrutura de rastreabilidade para mapear requisitos com modelos de interface do usuário
e analisa o impacto das mudanças nos modelos de aplicações da empresa orientada para
negócios.
Padrão de Ciclo de Vida
Não especifica.
Padrão de Modelagem
Deve considerar uma modelagem que inclua a identificação de processo de negócio, requisitos, tarefas e interfaces de usuário.
Artefatos Obrigatórios
Precisa documentar os processos de negócio, os requisitos, e o modelo de tarefas que faz
a integração entre os artefatos de interface de usuário.
Artefatos Rastreados
Processo de negócio, requisitos, modelo de tarefas, interface de usuário
Ferramenta Utilizada
UsiXML para mapear os modelos
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Foi usado um exemplo para demonstrar a abordagem
213
Referência
Título
(YRJÖNEN; MERILINNA, 2010)
Tooling for the full traceability of non-functional requirements
within model-driven development
Author(es)
Yrjönen, Anton and Merilinna, Janne
Resumo da abordagem de rastreabilidade utilizada
De forma geral, a solução é uma abordagem para gerenciar os requisitos não funcionais
com MDD (Model Driven Development) usando SIG (Softgoal Interdependency Graphs).
O trabalho relata que os requisitos precisam ser garantidos ao longo do processo de desenvolvimento. Para os autores, a rastreabilidade é um recurso que deve ser usado. A
abordagem propõe uma solução integrada de ferramentas para modelagem específica de
domínio que permite e orienta para a definição de requisitos precisos e não conflitantes.
Além disso, a solução permite a rastreabilidade bidirecional completa dos requisitos para
os modelos para a implementação e, oferece uma visão global atualizada do estado dos
requisitos do produto.
Padrão de Ciclo de Vida
Não especifica.
Padrão de Modelagem
MDD (Model Driven Development)
Artefatos Obrigatórios
Requisitos não funcionais, SIGs, decisões de arquitetura, artefatos de arquitetura
Artefatos Rastreados
Requisitos dos stakeholders, requisitos não funcionais, artefatos de design
Ferramenta Utilizada
NFR+Framework (para armazenar os projetos e MetaEdit+ (ferramenta desenvolvida pelos autores) como repositório
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Foi feito um exemplo fictício para apresentar a validação
214
Referência
Título
(GOKNIL; KURTEV; BERG, 2010)
Tool support for generation and validation of traces between requirements and architecture
Author(es)
Goknil, Arda and Kurtev, Ivan and van den Berg, Klaas
Resumo da abordagem de rastreabilidade utilizada
Segundo os autores tem sido dada menos atenção aos requisitos com arquitetura usando
semântica bem definidas de traços (links).
O trabalho apresenta uma ferramenta que fornece rastreabilidade usando semântica de
traços entre R & A (Requisitos e Arquitetura). A ferramenta fornece:
(1) geração / validação de traços usando requisitos relações e / ou verificação de arquitetura,
(2) geração / validação das relações de requisitos usando traços.
A ferramenta usa a semântica de traços juntamente com resultado de verificação e relacionamento de requisitos para gerar traços validados. É baseado em transformações de
modelo transformações no ATL e lógica de reescrever prazo em Maude.
Ferramenta para gerar e validar ligações entre requisitos e arquitetura. A ferramenta ainda
é experimental e a abordagem possui pontos (como a manutenção das ligações) que precisam ser evoluídos, pois não são contemplados.
Padrão de Ciclo de Vida
Não influencia, pois é executado depois dos artefatos (requisitos e arquitetura) estarem
prontos
Padrão de Modelagem
Não determina, pois importa os artefatos depois de construídos para que a ferramenta faça
a geração dos links e a validação
Artefatos Obrigatórios
Requisitos e arquitetura precisa estar descrita.
Artefatos Rastreados
Requisitos e solução de arquitetura
Ferramenta Utilizada
Prototipada uma ferramenta (não possui nome no trabalho).
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida (x) Produto Pronto
( ) Construção do Projeto
Contexto de Validação
Foram feitos testes de escalabilidade e performance na ferramenta. Não houve validação
da ferramenta
215
Referência
Título
(NEJATI et al., 2012)
A SysML-based approach to traceability management and design slicing in support of safety certification: Framework, tool
support, and case studies
Author(es)
Shiva Nejati and Mehrdad Sabetzadeh and Davide Falessi and
Lionel Briand and Thierry Coq
Resumo da abordagem de rastreabilidade utilizada
O trabalho propõe uma estrutura para especificar e extrair automaticamente requisitos
de segurança que sejam relevantes para o sistema. Para isso oa abordagem propõe dois
componentes:
1 - Uma metodologia para estabelecer a rastreabilidade entre requisitos de segurança e o
projeto
2 - Um algoritmo que pode extrair um fragmento de projeto de um requisito de segurança.
A modelagem é feita usando SysML. A estrutura inclui um modelo de rastreabilidade de
informações, uma metodologia para estabelecer a rastreabilidade e mecanismos de um
modelo de cortes dos modelos. A ferramenta implementada se chama SafeSlice.
No trabalho é relatado que o algoritmo de corte teve bons resultados nas propriedades de
segurança temporais. Outro ponto relatado é que a abordagem proposta reduz consideravelmente a quantidade de informações que devem ser inspecionadas para garantir que um
requisito de segurança seja atendido pelo projeto.
Padrão de Ciclo de Vida
Não especifica, e como propõe a metodologia, o padrão de ciclo de vida, não deve influenciar desde que respeitados os passos propostos pela metodologia
Padrão de Modelagem
Propõe uma metodologia usando SysML com os seguintes passos:
Fase 1 - Especificação de requisitos com os passos: 1 Diagrama de Contexto, 2 - Diagrama
de Requisitos de Sistema, 3 - Diagrama de Casos de Uso
Fase 2 - Projeto do Sistema com os passos: 4 e 5 - Diagramas Estruturais, 6 e 7 - Diagramas de Comportamento, 8 e 9 - Estabelece rastreabilidade
Artefatos Obrigatórios
Requisitos e arquitetura precisa estar descrita.
Artefatos Rastreados
Requisitos de segurança e artefatos de projeto (design).
Ferramenta Utilizada
SafeSlice (http://modelme.simula.no/pub/pub.html#ToolSlice) É um plugin do EnterpriseArchitect
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Duas validações, uma parcial e uma em um sistema completo da indústria de energia e
marítima.
216
Referência
Título
Author(es)
(LEVENDOVSZKY et al., 2010)
A transformation instance-based approach to traceability
Levendovszky, Tihamer and Balasubramanian, Daniel and
Smyth, Kevin and Shi, Feng and Karsai, Gabor
Resumo da abordagem de rastreabilidade utilizada
Este trabalho descreve uma ferramenta formada por um conjunto de módulos que é capaz
de gerar e seguir links de rastreabilidade em toda a transformações dos modelos entre
modelos e de modelos para para código, e capazes de dar apoio a navegabilidade ao
longo destas ligações de rastreabilidade. Esta abordagem se aplica ao desenvolvimento
de software para aviões.
Foi elaborado o projeto conceitual da ferramentas e definidos os detalhes sobre a sua
realização em um ambiente DSML (Domain-Specific Modeling Languages) sustentada
por gráfico baseado em reescrita transformação do modelo.
A ferramenta possui um módulo de transformação que gera o Model-Model traceability
data e o módulo gerador do código que gera o Model-Code traceability. Estes módulos
interagem com o repositório da ferramenta de rastreabilidade.
Padrão de Ciclo de Vida
Não especifica
Padrão de Modelagem
MDD (Model Driven Development)
Artefatos Obrigatórios
Requisitos e arquitetura precisa estar descrita.
Artefatos Rastreados
A relação entre artefatos de modelos e artefatos de modelos e código fonte
Ferramenta Utilizada
The Graph Rewriting and Transformation Language: GReAT Desenvolvida pelos autores
e relatada em outro trabalho.
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Usa um exemplo ilustrativo para a validação
217
Referência
Título
(LEE et al., 2010)
Means-ends and whole-part traceability analysis of safety requirements
Author(es)
Jang-Soo Lee and Vikash Katta and Eun-Kyoung Jee and Christian Raspotnig
Resumo da abordagem de rastreabilidade utilizada
Neste trabalho, os autores propõem um método de análise de rastreabilidade otimizado
que se baseia nos meios-fins e conceito todo-parte para rastrear esses requisitos de segurança.
Segundo os autores, de acordo com a decomposição todo-parte, um sistema é composto
por hardware , software, e os seres humanos. Os requisitos de segurança de um sistema e
seus componentes são aplicados ou implementada através de um ciclo de vida de meiosfins . Para comprovar a segurança de um sistema, o método de análise de rastreabilidade
meios-fins e todo-parte método irá otimizar a criação de evidência de segurança a partir
dos requisitos de segurança, os resultados da análise de segurança, e outros artefatos produzidos através do ciclo de vida de um sistema. Estas fontes de evidência de segurança
têm uma relação causal (causa - consequência) entre si. O FMEA (failure mode and effect analysis), o HAZOP (hazard and operability analysis), e FTA (fault tree analysis) são
métodos geralmente utilizados para análise de segurança de sistemas e seus componentes.
Estas técnicas abrangem as relações causais em uma análise de segurança . Através das
relações causais no método proposto é possível traçar os requisitos de segurança através
dos resultados da análise de segurança e artefatos do sistema.
A abordagem proposta é apresentada com um exemplo e descreve o uso da ferramentas
TRACE (Traceability of Requirements for Analysable Computerised Environments) e
NuSRS (Nuclear software requirements specification) que é parte do NuSEE (Nuclear
Software Engineering Environment) para aplicar a abordagem.
Propõe um método de análise de rastreabilidade otimizado que se baseia nos meios-fins e
conceito todo-parte da abordagem para os sistemas cognitivos de engenharia para rastrear
requisitos de segurança. A abordagem é específica para sistemas de controle de segurança
crítica.
Padrão de Ciclo de Vida
Não especifica, no entanto, é possível identificar o uso do cascata no trabalho.
Padrão de Modelagem
Padrão de modelagem baseado em MDD usando abstração e decomposição por meio-fim
e todo-parte
Artefatos Obrigatórios
Artefatos bem específicos da metodologia proposta. São vários níveis de artefatos de sistema e de segurança.
Artefatos Rastreados
Todo-parte: entre artefato de sistema e resultados de análises de segurança pertencentes a
diferentes abstrações (por exemplo: entre os requisitos de sistema e requisitos de software)
Meios-Fins: entre artefato de sistema e resultados de análises de segurança pertencentes
a diferentes fases (por exemplo: entre os requisitos e modelos de design)
Rastreabilidade Vertical: entre artefato de sistema e resultados de análises de segurança
que pertencem à mesma fase
Ferramenta Utilizada
NuSRS (Nuclear software requirements specification) e TRACE, ferramentas desenvolvidas no contexto de especificação e validação de requisitos de sistemas de proteção de
plantas digitais em usinas nucleares
Abrangência
( ) Produto
( )Projeto
(x) Ambos
218
Referência
(JIRAPANTHONG; ZISMAN, 2009)
Título
XTraQue: traceability for product line systems
Author(es)
Waraporn Jirapanthong, Andrea Zisman
Resumo da abordagem de rastreabilidade utilizada
Neste trabalho os autores apresentam uma abordagem de rastreabilidade para sistemas de
linha de produto. Segundo os autores, relações de rastreabilidade pode melhorar a qualidade do produto a ser desenvolvido e reduzir o tempo de desenvolvimento e custo. A
abordagem é baseada em regras para apoiar a geração automática das relações de rastreabilidade entre os documentos de orientação a objetos baseada em recursos. É definido
um modelos de referência de com nove tipos diferentes de relações de rastreabilidade
para oito tipos de documentos. As regras de rastreabilidade utilizados no trabalho são
classificadas em dois grupos a saber:
(a) regras diretas, que suportam a criação de relações de rastreabilidade que não dependem
da existência de outras relações, e
(b) as regras indiretas, que exigem a existência de relações gerado anteriormente .
Os documentos são representados em XML e as regras são representados numa extensão
de XQuery . Uma ferramenta protótipo chamado XTraQue foi implementado. Esta ferramenta, juntamente com o estudo de caso em uma linha de produto de telefone celular
foram utilizados para avaliar o trabalho em vários experimentos. Os resultados destes experimentos são positivos e comparáveis com outras abordagens que suportam a geração
automática das relações de rastreabilidade.
Padrão de Ciclo de Vida
Não especifica.
Padrão de Modelagem
Usa uma extensão da metodologia FORM
Artefatos Obrigatórios
Artefatos bem específicos da metodologia proposta. São vários níveis de artefatos de sistema e de segurança.
Artefatos Rastreados
Modelos que representam a linha de produtos: funcionalidade, subsistema, processo, e
módulo e Diagramas de casos de uso, classe, estado, and sequencia que representam as
informações dos produtos
Ferramenta Utilizada
XTraQue que é uma extensão do XQuery
Abrangência
(x) Produto
( )Projeto
( ) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Validado em um estudo de caso de uma linha de produto para telefone móvel
219
Referência
Título
(MERILINNA; YRJÖNEN; RÄTY, 2012)
NFR+ framework method to support bi-directional traceability
of non-functional requirements
Author(es)
Janne Merilinna, Anton Yrjönen, Tomi Räty
Resumo da abordagem de rastreabilidade utilizada
No contexto dos requisitos não funcionais, propõe um método para aplicação de um framework apoiado por uma ferramenta para permitir a manutenção de vínculos de rastreabilidade bidirecional entre nas fases do processo de desenvolvimento, com atenção especial
na manutenção de rastreabilidade ao longo de diferentes limites típicos de ferramentas
existentes no contexto do DSM (Domain-Specific Domain).
O método do framework possui algumas fases:
Importação dos Requisitos
Elaboração de Requisitos
Especificação
Projeto e Implementação
Teste
A ferramenta implementa as 5 fases citadas anteriormente.
O trabalho apresenta uma estudo de caso exemplo e os resultados da aplicação do framework.
Padrão de Ciclo de Vida
Não especifica, mas o processo apresentado indica o modelo cascata.
Padrão de Modelagem
Propõe o padrão DSM (Domain-Specific Modeling) um conjunto de fases que contempla:
elaboração de requisitos, especificação, projeto e implementação, teste e manutenção.
Artefatos Obrigatórios
Artefatos bem específicos da metodologia proposta. São vários níveis de artefatos de sistema e de segurança.
Artefatos Rastreados
Requisito não funcional, prioridade, objetivo de medida, métrica aplicável para a rastreabilidade, valor da medida. Estes valores rastreados são preenchidos ao longo do processo
de desenvolvimento e verficados depois de implementado
Ferramenta Utilizada
OSRMT (para requisitos), Framework NFR+ e MetaEdit+.
Abrangência
(x) Produto
( )Projeto
( ) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Não houve validação com um software real, apenas exemplo mostrado no trabalho.
220
Referência
(SCHWARZ; EBERT; WINTER, 2010)
Título
Graph-based traceability: a comprehensive approach
Author(es)
Hannes Schwarz, Jürgen Ebert, Andreas Winter
Resumo da abordagem de rastreabilidade utilizada
Este trabalho apresenta uma visão abrangente sobre a rastreabilidade, que pertence a todo
o processo de desenvolvimento de software . Com base no estado da arte , o campo é
estruturado de acordo com seis atividades específicas relacionadas à rastreabilidade da
seguinte forma: definição, gravação, identificação, manutenção , recuperação e utilização.
Usando a tecnologia de gráfico, uma abordagem abrangente e transparente para apoiar
estas atividades é derivado , combinando-os em uma única estrutura conceitual . Esta
abordagem apoia a definição de metamodelos de informação de rastreabilidade, a gravação de informações de rastreabilidade em repositórios baseados em grafos, identificação e
manutenção de relacionamentos de rastreabilidade utilizando transformações, bem como
a recuperação e utilização de informações de rastreabilidade utilizando uma linguagem de
consulta gráfica. A abordagem apresentada é aplicada no contexto do projeto ReDSeeDS
(Requirements Driven Software Development System ), que visa a reutilização de software baseado em requisitos . ReDSeeDS faz uso de informações de rastreabilidade para
determinar arquiteturas potencialmente reutilizáveis, design, ou artefatos de código com
base em um determinado conjunto de requisitos reutilizáveis. O projeto prevê estudos de
caso de diferentes domínios para a validação da abordagem.
É usado o TGraph para compreender e integrar as atividadades de rastreabilidade durante
o processo de desenvolvimento e MOLA como repositório de rastreabilidade e The graph
query language GReQL usado para recuperar e utilizar a rastreabilidade.
Padrão de Ciclo de Vida
Não especifica, no entanto, no trabalho é usado como exemplo o cilco de vida clássico ou
cascata.
Padrão de Modelagem
ReDSeeDS project (Requirements Driven Software Development System). Este padrão é
proposto pelos autores como processo de desenvolvimento e padrão de modelagem que
usa como base a UML
Artefatos Obrigatórios
Precisa documentar, dentre estes elementos, aqueles que deseja documentar: Stakeholder,
Requisito (funcional e não funcional, Elemento de arquitetura, Elemento de design, Caso
de Teste, Elemento de código (classe, campo e método) e elemento de documentação de
código.
Artefatos Rastreados
Stakeholder, Requisito (funcional e não funcional, Elemento de arquitetura, Elemento
de design, Caso de Teste, Elemento de código (classe, campo e método) e elemento de
documentação de código.
Ferramenta Utilizada
"MOLA-Tool - ferramenta para repositório, API do Enterprise Architect - para extração.
A abordagem é um meta modelo, então não possui ferramenta para todas as fases.
Abrangência
( ) Produto
( )Projeto
(x) Ambos
Etapa do Ciclo de Vida ( ) Produto Pronto
(x) Construção do Projeto
Contexto de Validação
Validado no projeto ReDSeeDS. Desenvolvido com participação da equipe de pesquisa
221
APÊNDICE C – QUESTIONÁRIO DO SURVEY DE
RASTREABILIDADE NAS ORGANIZAÇÕES
Rastreabilidade nas Organizações
Esta pesquisa é realizada no contexto da proposta de um Corpo de Conhecimento em Rastreabilidade de Software para Organizações de Produto de
Software. O questionário possui 14 perguntas e deve ser respondido com o acompanhamento do pesquisador. O tempos médio de resposta é de 15
minutos. As organizações não serão identificadas na pesquisa. Somente as características colhidas durante a aplicação do questionário serão utilizadas e
analisadas e os resultados farão parte da dissertação de mestrado de autoria da pesquisadora.
Perguntas de Contextualização
(8 perguntas)
1 - Qual o estado (unidade da federação) onde está localizada a unidade organizacional pesquisada?
(Unidade Organizacional é a unidade que produz um produto de software)
2 - Qual a cidade onde está localizada a unidade organizacional pesquisada?
3 - Quantos desenvolvedores fazem parte a unidade organizacional?
(Desenvolvedores são todos os envolvidos no processo de análise, projeto e construção do produto)
4 - Qual a área de atuação do(s) produto(s) desenvolvido?
(Comércio, Indústria, Governo, Hospitalar, etc.)
5 - Quantos produtos são mantidos pela unidade organizacional?
(Produtos comercializados de forma independente )
6 - Há quantos anos foi iniciada a construção do(s) produto(s)?
(Escolha apenas uma resposta)
(
(
(
(
(
(
) Menos de 1 ano
) De 1 a 3 anos
) De 3 a 5 anos
) De 5 a 7 anos
) De 7 a 9 anos
) Mais de 9 anos
7 - A unidade organizacional possui avaliação ou certificação da qualidade?
(Escolha entre as normas e modelos sugeridos e especifique se houver outra resposta.)
(
(
(
(
(
(
(
) Nenhuma
) CMMI
) MPS.BR
) ISO 29110
) ISO 9000
) Certics
) Outro:
8 - A organização aplica a rastreabilidade em algum nível na unidade organizacional?
(Se responder Não, o questionário será encerrado)
(
) Sim
(
) Não
222
Adequação em relação a Revisão Sistemática
(6 perguntas)
Identificar se existe aderência com relação as informações identificadas na revisão sistemática de rastreabilidade em produtos de software
9 - A rastreabilidade acontece em que contexto na Unidade Organizacional?
(A rastreabilidade de produto inclui a de projetos.)
(
(
) Projeto - Rastreabilidade é registrada somente no contexto do projeto
) Produto - A rastreabilidade acontece além do projeto e chega a ser implementada no nível do produto de sofware
10 - Qual a principal finalidade para o uso da rastreabilidade na Unidade Organizacional?
(Indique somente a principal finalidade.)
(
(
(
(
(
(
(
(
(
) Rastrear Requisitos Funcionais
) Rastrear Requisitos Não Funcionais
) Rastrear Pontos por Função
) Rastrear Testes
) Rastrear artefatos de Linha de Produtos de Software
) Rastrear Requisitos de Segurança
) Rastreabilidade Baseada em Objetivos (Goal Centric Traceability)
) Construção de Software para Aviões
) Outro:
11 - Quais são os artefatos rastreados pela abordagem adotada na Unidade Organizacional?
(Assinale todos os artefatos que são rastreados.)
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
(
) Stakeholder (interessado)
) Processos de Negócio
) Funcionalidades (Features)
) Requisitos Funcionais
) Requisitos Não Funcionais
) Requisitos de Segurança
) Artefatos de Projeto (Design)
) Objetos de Interface
) Casos de Uso
) Diagrama de Sequência
) Diagrama de Estado
) Classes
) Métodos
) Código Fonte
) Casos de Teste
) Outro:
12 - Qual o padrão de modelagem utilizado na Unidade Organizacional onde a rastreabilidade é aplicada?
(Escolha um dos modelos apresentados ou especifique se for outro.)
(
(
(
(
(
) Modelagem Relacional (Banco de Dados)
) Modelagem Orientada a Objetos usando UML
) MDD (Model Driven Development)
) MDE (Model Driven Engineering)
) ADD (Architectural Design Decisions)
223
(
(
(
(
(
(
(
(
(
(
(
) DSM (Domain-Specific Modeling) para requisitos não funcionais
) ReDSeeDS project (Requirements Driven Software Development System)
) MUSE (Management-based Unified Software Engineering)
) Forfamel - modelo de funcionalidades
) ACME (framework para descrever o modelo de arquitetura)
) Formal Concept Analysis (FCA) para ligar o modelo de funcionalidades ao modelos de arquitetura
) Goal Model (Modelo Orientado a Objetivos)
) Modelagem de processo de negócio, requisitos, tarefas e interface de usuário
) SysML (com especificação de requisitos e projeto de sistemas)
) FORM (funcionalidade, subsistema, processo, e módulo + diagramas UML)
) Outro:
13 - Qual ferramenta ou conjunto de ferramentas usadas para gerenciar a rastreabilidade?
(Assinale todas as ferramentas envolvidas no processo de registro e consulta da rastreabilidade na Unidade Organizacional. Se a ferramenta usada não estiver contemplada, descreva em outro.)
(
(
(
(
(
(
(
(
(
(
) Não usa ferramenta automatizada
) Plugins do Eclipse
) Enterprise Architect (com ou sem plugins específicos)
) BASEX
) FORTA
) DOORS
) STRADA
) TRACE
) XTraQue
) Outro:
14 - A abordagem de rastreabilidade utilizada pode ser usada no ciclo de vida:
(Escolha uma das alternativas.)
(
(
) Durante o processo de desenvolvimento do produto
) Após o produto de software pronto
Sua resposta foi registrada. Agradecemos a sua participação.
224
APÊNDICE D – QUESTIONÁRIO DO SURVEY PARA
AVALIAÇÃO DO TRACEBOK
Avaliação TraceBok
O objetivo desta pesquisa é avaliar a primeira versão do TraceBok (Corpo de Conhecimento para Rastreabilidade no Desenvolvimento de Produtos de
Software).
O TraceBok foi desenvolvido a partir de uma dissertação que identificou abordagens de rastreabilidade na literatura e confirmou seu uso nas organizações.
O objetivo desta pesquisa é avaliar a aplicabilidade do TraceBok do ponto de vista de especialistas.
Contextualização
1 - Qual a sua formação acadêmica?
(Escolha apenas uma resposta)
(
(
(
(
(
) Graduação em Ciência da Computação ou áreas afins
) Especialização na área da Computação e afins
) Mestrado em Ciência da Computação ou áreas afins
) Doutorado em Ciência da Computação ou áreas afins
) Graduação, especialização, mestrado ou doutorado em outras áreas
2 - Você possui alguma formação nos modelos MPS.BR ou CMMI?
(É possível escolher mais do que uma resposta)
(
(
(
(
(
) Implementador MPS.BR e já realizou pelo menos 5 implementações
) Avaliador MPS.BR e participou de pelo menos 5 avaliações
) Implementador CMMI e já realizou pelo menos 5 implementações
) Avaliador CMMI e já participou de pelo menos 5 avaliações
) Trabalha como responsável por uma ou mais equipes de desenvolvimento de software nos últimos 3 anos que usa rastreabilidade
Avaliação
(Estas perguntas devem ser respondidas após a leitura do TraceBok.)
3 - A forma de apresentação do TraceBok (organização dos capítulos e seções) é compreensível.
(Escolha apenas uma resposta.)
(
(
(
(
(
) Concordo totalmente
) Concordo parcialmente
) Discordo parcialmente
) Discordo totalmente
) Não tenho opinião
4 - É fácil encontrar as informações desejadas nas estrutura proposta pelo corpo de conhecimento.
(Escolha apenas uma resposta.)
(
(
(
(
(
) Concordo totalmente
) Concordo parcialmente
) Discordo parcialmente
) Discordo totalmente
) Não tenho opinião
225
5 - O TraceBok contém abordagens de rastreabilidade conhecidas por você.
(Escolha apenas uma resposta.)
(
(
(
(
(
) Concordo totalmente
) Concordo parcialmente
) Discordo parcialmente
) Discordo totalmente
) Não tenho opinião
6 - Você conhece alguma abordagem de rastreabilidade que não aparece no corpo de conhecimento.
(Escolha apenas uma resposta.)
(
(
(
(
(
) Concordo totalmente
) Concordo parcialmente
) Discordo parcialmente
) Discordo totalmente
) Não tenho opinião
7 - O TraceBok apresenta pelo menos uma abordagem que pode ser aplicada nas organizações que você tem ou teve contato.
(Escolha apenas uma resposta.)
(
(
(
(
(
) Concordo totalmente
) Concordo parcialmente
) Discordo parcialmente
) Discordo totalmente
) Não tenho opinião
8 - O TraceBok pode ser usado para auxiliar os envolvidos no conhecimento dos conceitos relacionados à rastreabilidade.
(Escolha apenas uma resposta.)
(
(
(
(
(
) Concordo totalmente
) Concordo parcialmente
) Discordo parcialmente
) Discordo totalmente
) Não tenho opinião
9 - As abordagens apresentadas no TraceBok estão alinhadas aos modelos de qualidade que você conhece.
(Escolha apenas uma resposta.)
(
(
(
(
(
) Concordo totalmente
) Concordo parcialmente
) Discordo parcialmente
) Discordo totalmente
) Não tenho opinião
10 - Você usaria o TraceBok como apoio em atividades de implantação ou avaliação de práticas de rastreabilidade nas organizações.
(Escolha apenas uma resposta.)
(
(
(
(
(
) Concordo totalmente
) Concordo parcialmente
) Discordo parcialmente
) Discordo totalmente
) Não tenho opinião
11 - Você pode fazer observações sobre suas impressões do Tracebok.
(Esta resposta é livre.)
226
Sua resposta foi registrada. Agradecemos a sua participação.
227
APÊNDICE E – TRACEBOK
TraceBok versão 1.0
TRACEBOK
Software Traceability Body of Knowledge
Ana Márcia Debiasi Duarte
Version 1.0
CONTENTS
1
2
3
Introduction
1
1.1
1.2
1.3
1.4
1
2
2
3
Document Structure
Users and Uses
Knowledge Areas
Classification Approaches
Traceability Life Cycle
5
2.1
2.2
5
6
7
7
8
8
Basic Concepts
Traceability Life Cycle
2.2.1
Traceability Strategy
2.2.2
Traceability Creation
2.2.3
Traceability Use
2.2.4
Traceability Maintenance
Functional Requirements Traceability
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
#FRT01 - Requirement and Source Code Traceability
#FRT02 - Requirements Traceability in an Heterogeneous Model-based Design Process
#FRT03 - End-to-end Software Traceability
#FRT04 - Pushing Timely Trace Recommendations to Project Stakeholders
#FRT05 - Capturing (semi)automatically traceability relationships from requirements and
design decisions to architecture and implementation
#FRT06 - Traceability in secure and dependable software development
#FRT07 - Exploring traces links to source code through testing
#FRT08 - Graph-based traceability
9
10
11
12
13
15
16
17
18
iii
iv
CONTENTS
3.9
3.10
3.11
3.12
4
5
19
21
22
23
Non-Functional Requirements Traceability
25
4.1
4.2
4.3
4.4
26
27
29
#NFRT01 - Full Traceability of Non-Functional Requirements within Domain-Specific Modeling
#NFRT02 - Safety Requirements Traceability Support in MDD of Robotic Applications
#NFRT03 - Means-ends and whole-part traceability analysis of safety requirements
#NFRT04 - A SysML-based approach to traceability management and design slicing in
support of safety certification
Software Product Line Traceability
5.1
5.2
5.3
6
#FRT09 - Architectural Design Decisions Evolution through Model Driven Engineering
#FRT10 - Supporting Requirements in a Traceability Approach between Business Process and
User Interfaces
#FRT11 - Generation and Validation of Traces between Requirements and Architecture
#FRT12 - Semi-automated Traceability Maintenance - traceMaintainer
#SPLT01 - A Metamodeling Approach to Tracing Variability between Requirements and
Architecture in SPL
#SPLT02 - Traceability in Software Product Line using Formal Concept Analysis
#SPLT03 - A rule-based traceability approach for product line systems
Glossary
References
31
33
34
36
37
39
43
CHAPTER 1
INTRODUCTION
TRACEBOK GUIDE
Traceability supports software management, software evolution and validation. When changes are made in a
software product, traceability is fundamental to analyze changes impact, besides, it helps on the understanding,
capturing, tracking and verification of software artifacts and their relationships and dependencies with other artefacts during the software life-cycle [10]. With this in mind, a guide has an important role to help practitioners to
understand and apply traceability in their daily software development tasks.
The Guide of Software Traceability Body of Knowledge (TraceBok Guide) is established with the following
objectives:
1. To provide a comprehensive and integrative view of the software traceability for professionals and organizations; and
2. To present and to explain software traceability approaches to support software development cycle.
This guide is developed to gather concepts and approaches of software traceability.
This release was proposed based on systematic review about software traceability concepts approaches. As a
result, knowledge areas are proposed to serve as guide to professionals and organizations. This guide is validated
by a community of domain experts.
1.1
Document Structure
This document is structured as follows: this chapter introduces TraceBok presenting the knowledge areas (KA) and
the approaches associated to each KA. Chapter 2 presents the first KA, called Traceability Life Cycle. This KA
represents the base for traceability concepts and for the other KA. In Chapter 3, it is presented Functional Requirement Traceability knowledge area that groups functional requirement traceability approaches. Chapter 4 presents
Non-Functional Requirements Traceability knowledge area that groups non-functional requirements traceability
approaches. The following chapter (Chapter 5) presents Software Product Line Traceability that groups software
1
2
INTRODUCTION
product line traceability approaches. Finally, Glossary is organized in a chapter to present the most frequent traceability term used during the software process development life cycle.
1.2
Users and Uses
This guide was organized to improve the software traceability comprehension. Different groups of users may
benefit from this guide. Table 1.1 shows the potential users and common uses of this guide.
Table 1.1
User
Software developer
Users and Uses
Uses
A source for software development traceability approaches study.
A guide for helping to choose approaches that fit their
needs.
Projetc manager
Academic people
A guide for helping managers establish strategies for the
use of traceability in organizations.
The guide is useful to organize concepts and contents.
A source for traceability researches.
1.3
Knowledge Areas
TraceBok is organized in Knowledge Areas (KA). Knowledge areas provide a guide to some of the major traceability purpose and practices. The proposed knowledge areas were defined from reviews of the most using traceability
approaches found in the literature and organizations. Figure 1.1 depicts the organization of TraceBok KA.
Figure 1.1
TraceBok - Knowlegde Areas Organization
The first knowledge area - Traceability Life Cycle - intends to support the other KA. It is defined to present
the basic concepts and the traceability life cycle. Furthermore, this KA aims to elucidate (i) the main traceability
concepts, and (ii) the organization of the process and its part of traceability life cycle. All approaches presented in
this BoK follow the concepts in Traceability Life Cycle knowledge area.
The other proposed KA aim to gather the traceability approaches in categories oriented to user needs. Therefore,
approaches found for traceability are grouped in three KAs: Functional Requirements, Non-Functional Require-
3
ments and Product Line Traceability. Each approach is described in such way that practitioners can evaluate
whether or not the approach fits traceability requirements for their application.
Notice that knowledge areas are not intended to represent phases in traceability. The objective is to organize
available literature approaches according common characteristics. Thus, this BoK gather approaches by traceability
uses and objectives.
1.4
Classification Approaches
The Tracebok objective is to bring the concepts and the possibilities of traceability use for the product software
developers. Thus, approaches were selected from the literature and validate to justify the selection. Validation was
conducted by interviewing traceability practitioners. To simplify the use of the content in this BoK, approaches
were organized in knowledge areas with the distinct objectives. Some approaches attend more than one knowledge
area. In this case, they are presented in one of the knowledge area and they are referenced in the others.
Approaches are organized as follows:
Functional requirements since most traceability approaches deal with this kind of requirements.
Non-functional requirements since they have specific characteristics for traceability, such that: non-functional
requirements come in many different shapes and sizes, and there is therefore no single traceability technique
that can be applied in every case [5].
Software product line since traceability for this area is more complex encompassing several development
layers.
Approaches are presented in such way that it is possible to identify its applicability in traceability tasks. They
are described as follows: description, process support tool, restriction of using and how to apply this approach that
is divided into create and use. Figure 1.2 shows the content of each approach.
Figure 1.2
Approaches content
The Bok is not conceived as a methodology for the traceability implementation. Instead, it allows to identify
how to use traceability with relation to the practitioners specific needs.
Table 1.2 presents the proposed classification of the selected approaches.
4
INTRODUCTION
Table 1.2
Approaches classification
ID
Description
Source
Classification
#FRT01
Requirement and Source Code Traceability
[7]
Functional
#FRT02
Requirements Traceability in an Heterogeneous
Model-based Design Process
[8]
Functional and Non-Functional
#FRT03
End-to-end Software Traceability
[1]
Functional
#FRT04
Pushing Timely Trace Recommendations to
Project Stakeholders
[4]
Functional
#FRT05
Capturing (semi)automatically traceability relationship from requirements and design decision
to architecture and implementation
[2]
Functional
#FRT06
Traceability in secure and dependable software
development
[30]
Functional
#FRT07
A Tool for Scenario-based Feature-to-Code
Trace Detection and Analysis
[9]
Functional
#FRT08
Graph-based traceability
[26]
Functional
#FRT09
Architectural Design Decisions Evolution
through Model Driven Engineering
[19]
Functional
#FRT10
Supporting Requirements in a Traceability Approach between Business Process and User Interfaces
[27]
Functional
#FRT11
Generation and Validation of Traces between
Requirements and Architecture
[11]
Functional
#FRT12
Semi-automated Traceability Maintenance traceMaintainer
[17]
Functional
#NFRT01 Full Traceability of Non-Functional Requirements within Model-Driven Development
[29]
Non Functional
#NFRT02 Introducing Safety Requirements Traceability
Support in MDD of Robotic Applications
[24]
Non Functional
#NFRT03 Means-ends and whole-part traceability analysis of safety requirements
[16]
Non Functional
#NFRT04 A SysML-based approach to traceability management and design slicing in support of safety
certification
[21]
Non Functional
#SPLT01 A Metamodeling Approach to Tracing Variability between Requirements and Architecture in
SPL
[20]
Software Product Line Traceability
#SPLT02 Traceability in Software Product Line using
Formal Concept Analysis
[25]
Software Product Line Traceability
#SPLT03 XTraQue: traceability for product line systems
[14]
Software Product Line Traceability
CHAPTER 2
TRACEABILITY LIFE CYCLE
2.1
Basic Concepts
In software engeneering, traceability describes always requirements links. Requirements express needs and constraints of a software product and traceability allows to describe and to follow requiremens steps[15, 22]. As side
effect, traceability makes easier to verify and to validate requirements.
Requirements traceability may have two directions from requirement [13]:
forward: from a requirement to its artefacts or elements (built from it).
backward: from a requirement to its sources.
Figure 2.1 presents requirements tracing directions. Remark, from the figure, that backward direction answers
the question Which source? and forward one answers Which component?
Figure 2.1
Forward and backward traceability.
Traceability may also be divided into two basic types (see Figure 2.2):
5
6
TRACEABILITY LIFE CYCLE
Pre-requirements specification traceability (pre-RS traceability): refers to those requirements life cycle
aspects before it is designed.
Pos-requirements specification traceability (pos-RS traceability): refers to those requirements life cycle
aspects from the beginning of its specification.
Pre-RS and pos-RS traceabilities allow to have a traceability view based on software development life cycle,
considering the beginning of development process with the users needs up to the artifacts creation from the requirements. Thus, pre-RS is used to show that a product meets stakeholder requirements from initial discussion
and elucidation to the inclusion into the requirement document. On the other hand, pos-RS is used to requirement
validation and to establish the impact analysis recovering traces from different development phases [23] [28].
Figure 2.2
Pre and pos-requirements specification traceability [13]
Figure 2.2 also shows the complexity from several iterations among traceability artifacts. Frequently, relationship between elements are many-to-many. From the users to RS and from RS to artifacts (see S0 and S1).
Another classification for traceability is with relation to context or elements to be traced. This classication
consider the relationship level among the traced artifacts. It is called two dimensional traceability.
Horizontal (or inter traceability): refers to relationship between different levels (or models) of abstraction:
from requirements to implementation going through design. In this classification, for example, trace links are
created between requirements and source codes.
Vertical (or intra traceability): refers to relationship between the same levels (or model) of abstraction:
between software components, related requirements, among others.
Two dimensional traceability is depicted in Figure 2.3 with the following models: requirements, analysis, design
and code. Each model has a set of objects. For example, Design model has four objects: D1, D2, D3 and D4.
Horizontal traceability is represented, in the figure, from R1 to A1 (Requirements and Analysis models), for
example. In the other hand, trace between C1 and C2 in the Code model shows, in the figure, a vertical traceability.
The definition of traceability, traceability directions and dimensionality underline the basis of traceability.
2.2 Traceability Life Cycle
Requeriment traceability may be applied in different tasks of software development. To apply traceability, Mader,
in [18], proposed a life cycle. It is composed by three generic process: (i) defining traceability, (ii) create and
maintaining traceability and (iii) using traceability. A generic traceability process model shows the essential activities used in the software traceability. This model is essential to guide the organizational traceability strategy.
Figure 2.4 describes the four key activities of the generic traceability process model: traceability strategy , traceability creation, traceability maintenance, traceability use. This model was proposed by [6]. Next sections present,
briefly, the activities present in Figure 2.4.
7
2.2.1
Figure 2.3
Rastreabilidade Vertical e Horizontal
Figure 2.4
Generic Traceability Process Model
Traceability Strategy
The most important activity in traceability is to plan a strategy. Traceability must be planned by establishing requirements such as granularity, categorization and storage artifacts. The strategy of linkages among artifacts is also
important. A planning must have the approaches chosen for generating, classifying, representing and maintaining
inter and intra-artifact. Good plannings are strategic for the traceability’s quality.
2.2.2
Traceability Creation
Based on the traceability planning, traceability elements have to be created, represented and stored. When the
traces already exists they have to be captured. After that, the validation against the planning is used to guarantee
trace accuracy of the links.
8
2.2.3
TRACEABILITY LIFE CYCLE
Traceability Use
Trace links are created or captured to help developers to manage software maintenance to avoid losing information
and to measure changes impacts. During a trace link using changes in the trace may happen and this change must
be managed to keep trace link accuracy.
2.2.4
Traceability Maintenance
Traceability maintenance can result from a strategic requirement change or a trace maintenance. To guarantee the
right results pointed by the traceability planning, the impact analysis have to be considered when the requirements
changing. The changes have to be accommodated considering all trace structure. During the trace insertions or
updating, the nature of the change must be analyzed to determine what updates are necessary. Traces can be
maintained continuously or on-demand. When the trace links can be updated manually, the on-demand option is
preferred since it is easier to perform. A trace is retired when it is no more necessary in software development.
CHAPTER 3
FUNCIONAL REQUIREMENTS TRACEABILITY
Functional requirements (FR) are the most common type of requirement in a software product. Traceability of FR
plays a crucial role in software development since they make software products easier to maintain and easier to
understand the built components. Functional requirements knowledge area intends to help practitioners to manager
trace links for functional requirements. Several approaches for FR are presented. All approaches are presented
following the structure presented in Figure 1.2.
9
10
3.1
FUNCTIONAL REQUIREMENTS TRACEABILITY
#FRT01 - Requirement and Source Code Traceability
Description This approach proposes the creation of traceability links between requirements and source code as
the development progresses by incorporating artifacts from project management. The proposed approach is
compatible with a iterative product software development (e.g. SCRUM), composed by sprints. The central
artifact is the work item, as it connects the artifacts from the system model to artifacts from the code model.
Developers create the links during the development phase, selecting a work item from his/her list of assigned
work items and tell the system that starts the source code implementation. Other features or functional requirements are automatic captured by the system.
Restriction of using This approach is based on MUSE (Management-based Unified Software Engineering). Source
codes must be implemented in Eclipse IDE since it uses UNICASE tool to create automatically traceability
links.
Process support tools This approach works with UNICASE tool (Eclipse plugin).
How to apply this approach This approach is divided in four steps. The first one, developers select the assigned
work item and start its implementation. During the implementation, the system captures the changes in source
code, the feature and the functional requirement that developers look at during the implementation. After
that, the developer finishes the implementation. The second one, the system presents the lists of changed code
files and captured features and functional requirements. Developers validate and, if is necessary, additional
features and functional requirements are added. In the third one, processes are documented using the commit
message of new versions of the work item. The last one, traceability links are created by a new revision of
CVS containing the selected code files and links to work item. Traceability system links selected features and
functional requirements to work item.
Figure 3.1
Process of Capturing, Validating and Creating Traceability Links
Creation To create traceability links, this approach define three model levels (like a class model): (i) system
model, contains features and functional requirements; (ii) project model, contains sprints, work items, and
developer; and (iii) code model, contains source code file and revision.
Use The use of the links are supposed to answer some questions like: What is the program supposed to do?
Why was this code implemented this way? What have my co-workers been doing? Which code is involved
in the implementation of this feature? To move this feature into this code, what else needs to be moved?
What will be the impact of this change? Links can be retrieved through the search from any artifact.
11
3.2
#FRT02 - Requirements Traceability in an Heterogeneous Model-based Design Process
Description In automotive and avionics software development the criticism of application imposes for safety
critical applications, full traceability and verification and validation of requirements. This approach integrates
multiple tools and heterogeneous models that capture either functional or non functional requirements. This
approach is based in a three dimensional methodology triptych composed of three activities: (i) requirement
management, (ii) solution definition, and (iii) V&V (verification and validation) usage. This approach is
justified by the necessary separation of concerns that is required when a certifying process has to be used to
certify a product. Each vertex is a multi level model-based flow. The DARWIN4Req traceability model is the
central part of this architecture by interconnecting these three independent flows.
Restriction of using This approach works only with DARWIN4Req metamodel.
Process support tools There is no one solution tool for this approach. Initial requirements can be obtained from
requirement tools such that DOORS.
How to apply this approach This approach defines two steps to create the traceability: (i) requirement definition
and (ii) traceability where the requirements are linked with the model elements including the V&V.
Creation Traceability requires to establish clear relationships between the requirements themselves to handle
refinement and decomposition aspects at the different levels of the requirement modeling flow. A second
kind of relation must be expressed between requirements and the other artifacts from the solution and
V&V models.
Use By using the above mentioned relationships (derive, decompose, satisfy or verify), traceability helps to
guarantee that the solution models cover all the requirements; and that the model at the different steps of
the design process and the final product correctly fulfill these requirements. The correctness is established
by applying the V&V methods and by reporting these results on verify and satisfy links.
12
3.3
FUNCTIONAL REQUIREMENTS TRACEABILITY
#FRT03 - End-to-end Software Traceability
Description This process-oriented approach achieves comprehensive traceability and supports the entire software
development life cycle by focusing on both requirements traceability and process traceability. One tool was
developed to achieve three main goals: (i) minimize overhead in trace definition and maintenance, (ii) preserve document integrity, and (iii) support SDLC (software development life cycle) activities.
Restriction of using This approach is proposed in the end-to-end software traceability tool. The approach is
limited to post-requirement specification traceability and mainly applies to tracing text-based artifacts.
Process support tools Traceability tool (is not a commercial tool).
How to apply this approach The Figure 3.2 shows the end-to-end software traceability model. The following
global artifacts types to trace: Marketing Requirements (MRQs), Use Cases (UCs), Functional Requirements
(FRs), and Test Cases (TCs). MRQs are organized by Projects and UCs are organized by Features. Several
Projects roll up to one Product. Each of the artifact types (MRQ, UC, FR, TC) links to a phase in the software
development life cycle (indicated by dotted lines). The users of the system, shown at the bottom of the diagram, are distinguished by whether they produce trace information or not. Producers, i.e. groups responsible
for entering trace information, are the Marketing Group, Architect Group, Project Managers, and Test Group.
All users are consumers of trace information.
Figure 3.2
End-To-End Software Traceability Model
Creation The users have to register all artifacts traces.
Use As users perform their tasks, they access globally traced artifacts via the workflow. This allows a close
proximity between tasks and related artifacts. Users may also directly access the artifacts outside the
workflow.
13
3.4
#FRT04 - Pushing Timely Trace Recommendations to Project Stakeholders
Description This is an approach for generating trace recommendations, and make them available to knowledgeable project stakeholders within the context of their daily work. The idea is to avoid searching missing
trace links in the end of project by eliciting traceability decisions from informed stakeholders throughout the
project. Trace recommendations allow to construct traceability links earlier in the project. The approach extends state-of-the art traceability practices for managing trace strategies and queries, and utilizes the Business
Process Modeling Notation (BPMN) to model critical software engineering workflows that drive and control
the proposed trace recommendations. Traceability environment is described in terms of five-layered model
depicted in Figure 3.3.
Figure 3.3
Five-Layered Trace Recommendation Architecture
The approach works as follows (see Figure 3.3 ):
The first 3 layers are based on existing technologies for traceability.
– Layer 1 stores conceptual artifacts, such as requirements, design, and code, as well as traceability
links.
– Layer 2 represents a Traceability Information Model (TIM) and is modeled as a UML class
diagram.
– Layer 3 provides facilities for modeling and executing trace queries. In this layer, several traceability query languages can be used: Trace Query Language (TQL), Visual Trace Modeling
Language (VTML), among others.
Layers 4 and 5 embody algorithms, workflows, and processes to the model. These elements utilize the
services provided by lower-level layers to push timely trace recommendations to project stakeholders.
Restriction of using The approach is partially supported by tools. Traceability links are recommended following
the layers presented above. The main restriction of this approach is the difficulty to set the working environment (i.e., all five layers). Different approaches and concepts should be grouped to construct the base of the
traceability. After that, it is possible to implement workflows and triggers that enable trace link recommendations.
14
FUNCTIONAL REQUIREMENTS TRACEABILITY
Process support tools This approach can use different tools (like Poirot, RETRO and ADAMS) to input a source
artifacts, such as requirement, and perform a search to identify a set of potentially related target artifacts.
Although, there is no tool to support the entire approach.
How to apply this approach To apply the trace recommendation is necessary to follow the concepts presented in
Figure 3.3. The objective is to generate and to push timely trace recommendations to developers in order to
construct traceability links earlier in the project.
Creation To create links is necessary to configure all three layers to build the working model. After that,
the two top layers must be built to allow the workflows to generate the recommendations from the implemented triggers.
Use The use is possible from the recommendations proposed by the traceability structure. Each artifacts
creation, deletion or modification triggers the generation of trace recommendations. During the generation
process, it is possible to identify and correct traceability problems.
15
3.5
#FRT05 - Capturing (semi)automatically traceability relationships from requirements and
design decisions to architecture and implementation
Description This approach allows to capture traces in a non-intrusive way from decisions to architecture design
and implementation. Tracing links are built during architecture design and implementation process based on
analysis of artifact modifications. These traces are added to a semi-formally proposed architecture model.
This approach works from fine-grained tracing to single elements of an architecture model and it has been
integrated to LISA toolkit. It basically works as follows: (i) user sets the context of his/her work by selecting
decisions made during his/her working (these decisions are named active decisions), (ii) user starts performing
his/her daily work, during this phase modification events are created and logged, i.e., short descriptions of the
elements that are manipulated during this phase, and (iii) when user finishes working on a decision, he/she
needs to review the captured tracing sets.
Process support tools This approach is integrated with LISA toolkit that is based on LISA Model: an architecture
description meta-model. The integration is made by constructing a listener in Eclipse Java Development Tools.
In this case, this approach works only on Java based solution.
Restriction of using This approach can be used only with Java-based applications, review process must be part of
design and implementation process and not all capturing can be performed automatically.
How to apply this approach Initially, developers decide the context of work by selecting the decisions to work
on with. In this moment, new decisions my be also created. After setting the context and one or more
active decisions, developers begin with architecture design and implementation activities, i.e., design decisions
are made. In next step, developers implement classes and interface for decisions made. During this step,
modification events are created and logged in background. All architecture and elements affected by an event
are shown as child elements of the event. After developers finish working on an active decision, the captured
tracing targets must be reviewed. Developers can remove incorrect or unnecessary tracing targets. Finally,
traces are created and added as part of the architecture model.
Creation The developer must register all active decisions and how they are implemented.
Use During the process of implement an active decision, developer must verify whether all modification
events logged are correct and necessary. As a result, the traces are visualized in architecture diagrams and
in source code editors as well.
16
3.6
FUNCTIONAL REQUIREMENTS TRACEABILITY
#FRT06 - Traceability in secure and dependable software development
Description This approach aims to maintain truly traceability links i.e., the high level of accuracy and change resilience of the links. Secure and dependable software development needs high accurancy and, thus, inaccurate
traceability links may be transformed by developers into a point to be explored by malicious attackers. Most
of traceability techniques may not recover accurate requirements traceability links that preserve the semantics
of traced elements (design to element implementation and vice-versa). Therefore, rediscovering traceability
links whenever changes happen must be accurate. To avoid inaccurate links after refactoring a program, the
proposed tool is implemented on top of Language Toolkit (LTK) refactoring plugin. LTK is used with Java
Development Toolkit (JDT) in Eclipse IDE. The tool, during the refactoring steps, logs all changes made in
the program through a declarative specification language. Indeed, LTK writes a XML document that is transformed into the proposed specification language. There is a deamon that monitors whether there is any change
to the traceability repository: when changes in artifacts are committed, a run of the tool is triggered to update
the traceability links, if it is necessary.
Process support tools The proposed tool must be run on top of LTK refactoring plugin. Although, LTK supports
language beyond Java, this tools is integrated with JDT to work properly. The plugin CruiseControl orchestrate
the integration of the proposed tool and Eclipse IDE. A secure extension of UML (called, U M Lsec) is used
to design the application and establish traceability links among design and element implementations.
Restriction of using The tool works on top of LTK plugin under JDT using Eclipse IDE. Thus, the application
must be developed in JAVA in Eclipse IDE configured with LTK. CruiseControl must be installed as well.
UMLSec must be used in design phase and the proposed approach works with refactoring tasks.
How to apply this approach This approach is applied, mainly, in secure and dependable software development
since it keeps high accuracy among traceability links. To apply it, users must configure Eclipse IDE to run
JDT, LTK and CruiseControl.
Creation Functional and Security requeriments must be linked with the source code and security aspects of
the application. This linking is done through UML Design and UMLsec, respectively. Eclipse IDE must
be configured to support the proposed tool (i.e., Eclipse refactoring engine).
Use The developer must have Eclipse configured to work with the proposed tool and all steps are automated.
There exist two command buttons to the Eclipse GUI, one of them performs all refactoring steps automatically, while the other brings up a dialogue for each step to preview the effects of refactoring.
17
3.7
#FRT07 - Exploring traces links to source code through testing
Description This approach propose the use of STRADA (Scenario-based TRAce Detection and Analysis) tool
that helps software engineers explore traces links to source code through testing. Two capabilities are listed:
(i) Scenario-based Trace Capture, a tool that observes what code is being accessed during testing and creates a
trace dependency, and (ii) Trace Analysis, a tool that helps the engineers to identify and resolve uncertainties
Process support tools The approach is supported by STRADA.
Restriction of using The tool is currently restricted to Java-based systems because the Trace Capture component
uses a Java profiler included in Eclipse. However, the approach is not restricted to this language and would
also work if integrated with profilers for other languages.
How to apply this approach To apply this approach is necessary to run tests in a target application. The result is
the trace dependency generated by the link between the code accessed during the testing of a feature. After
that, it is necessary to identify and resolve uncertainties. The traces created by testing needs to pass by a
review. The trace analysis component allows to visualize the current knowledge on feature-to-code mapping
in form of a trace matrix.
Creation The links creations depends on the test realization. Then it is necessary an analysis to guarantee
the quality of the traces.
Use The use of the links is possible visualizing the knowledge on feature-to-code mapping in form of a trace
matrix.
18
3.8
FUNCTIONAL REQUIREMENTS TRACEABILITY
#FRT08 - Graph-based traceability
Description This approach implements traceability based on graph theory: components are nodes of the graph
and their relationships are arcs. So, all artifacts are stored as nodes and the trace links as arcs. Developers
build software products using UML methodology and there is an API of a UML Tool (e.g., Enterprise Architect) to convert UML models into TGraphs. TGraphs are graphs that describe components of UML models
and their relationship. To construct TGraphs, this approach proposes the traceability reference schema (TRS).
TRS is construct using an extension of UML: grUML. Figure 3.4 depicts how the graph are built. There is an
entity (class) that represents traceable components: Stakeholder, Requirement (specialized in FunctionalRequirement and NonFunctionalRequirement), ArchitectureElement, DesignElement, TestCase, CodeElement
and DocumentionElement. These entities describe all traceable elements of this approach. On other hand,
relationships can be: isResponsibleFor, ConflictsWith, Refines, DependsOn, Fulfills, Realizes, Implements,
Tests and Documents. A grUML model is stored as a TGraph. Objects stored in TGraphs are queried using
GReQL. Therefore, the suite proposed in this approach allows to extract automatically components and their
trace links from UML models and to query stored objects.
Figure 3.4
Traceability Reference Schema Model
Process support tools This approach is based on MOLA Tool (MOdel transformation LAnguage). MOLA is a
graphic tool based on UML. The graphs environment in implement with JGraLab graph repository. Graphs
are queried using GReQL graph query engine.
Restriction of using MOLA cannot deal with graph edges as first-class citizens It means that developers must
model binary traceability relationships as vertex classes. The traceability graph repository is very simple,
relying on complete reexecution of transformations and demanding manual work from the developers, consequently hurting scalability.
How to apply this approach Developers must use UML to model the software product. All tools proposed by
the approach must be installed and configured: MOLA, tools for UML and grUML, the proposed API for
extraction entities and relationship from UML diagrams and JGraLab graph repository.
Creation Trace links are created form UML diagrams by executing the proposed API.
Use After entities and relationship extraction from UML diagrams are stored in the graph repository, all
traceability information can be retrieved for visualization and other utilizations. Developers, using graph
query language, may find three pattern problems: existence (there must exist a path between two entities
so the query cannot return null), reachable entities (given a trace link, the query must return all reachable
entities in that trace) and slice (given two entities, queries must return subsets of trace links belonging to
the main trace link). These patterns help practitioner to find and to solve traceability problems.
19
3.9
#FRT09 - Architectural Design Decisions Evolution through Model Driven Engineering
Description This is an approach to support architectural design decisions (ADD) evolution. It provides a generic,
ADD notation-independent approach that starting from a model based specification of ADDs, enables to
identify the impact of a changing design decision on other ADDs and the impact of the same on requirements
and architectural descriptions. The approach proposes a metamodel for evolving ADDs. The metamodel is
generic and flexible enough to manage requirements and architectures described in any notation. The proposed metamodel enables explicit representation of relationship among ADDs. The metamodel also enables
bidirectional traceability links between ADDs, requirements and architectural elements which will help in
analyzing the impact of evolution on the corresponding artifacts. Finally, the approach enables inter-decision
and extra-decision validation to check the presence of inconsistencies that may occur during evolution.
Figure 3.5 gives an overview of the approach to support architectural design decisions evolution. The ADD
model represents all the design decisions identified during the design process. Decisions are linked to requirements specification and a set of software architecture (SA) descriptions.
Figure 3.5
Overview of the proposed approach
Traceability is realized as a set of tracing links from requirements to ADDs and from ADDs to SA descriptions
(see the dotted lines in Figure 3.5). Tracing links are contained into special models (wmreq and wmSA in
shown in Figure 3.5).
Process support tools The process is supported by a prototype. It was conceived to realize the approach as an
Eclipse1 plugin that relies on the Atlas Model Management Architecture (AMMA).
Restriction of using This is an approach to support the architectural design decisions evolutions. The main restriction is to create and use the Requirements, SA and ADD models during the software conception phase.
How to apply this approach Design decisions must be considered first-class elements when architecting software systems, and they have to be explicitly documented and supported. The strong relationship that design
decisions share with requirements and other artifacts needs to be taken into consideration while supporting
evolution. Applying this approach, decisions and evolutions are registered, evolutions impact are analyzed
and decisions are taken about the software evolution.
Creation Traceability is realized as a set of tracing links from requirements to ADDs and from ADDs to
SA descriptions. Decisions are registered and the trace links are created. The decisions evolutions are
analyzed and are presented to the designer that make decisions about the changes.
20
FUNCTIONAL REQUIREMENTS TRACEABILITY
Use The impact of such an evolution can be divided into three main steps (show in Figure 3.5). (1) Evolution
identification: all the evolved ADD elements must be timely identified and must be presented to the designer; (2) Inter-decisions analysis: the portion of ADD model which depends on the initial evolved ADD
elements identified and their consistency must be checked; (3) Extra-decisions analysis: all requirements
and architectural elements depending on the evolved ADD elements are identified and checked against
consistency. The changes are checked by the tool and solved by the designer.
21
3.10
#FRT10 - Supporting Requirements in a Traceability Approach between Business Process
and User Interfaces
Description This approach is used as an extension to an existing traceability approach. It is presented like a framework model-driven approach to link business processes (BP), user interfaces (UI) models and requirements.
The application of changes made on BP or on system UIs may have an impact on software requirements,
which then requires updating related models in order to coherently enable changes. The goal of mapping
software requirements with task models, as an extension to an existing traceability approach, is to guarantee
that UIs are aligned with requirements. The approach enables mapping requirements with UI models and
analyzes the impact of changes on models of business-driven enterprise applications. For large organizations,
like industries and banks, that have complex business processes, which must be supported by thousands of
user interfaces in their applications, is primordial the alignment of task models with requirements and the
relation with the user interaction.
Figure 3.6
Requirements traceability with models
In this solution (Figure 3.6), when changes are made on BP models, they may impact on requirements or on
task models, or even in both simultaneously. Whenever there are impacts in one of them, the other one is
alerted with a warning of possible needs for update. In addition, changes on task models have impacts on UIs.
On another scenario, when changes are made first on UIs, the impact is on task models, which in their turn
impact BP models and also alerts requirements for possible updates.
Process support tools This framework has no support tool.
Restriction of using This approach is proposed as a complement to other approaches for traceability requirements.
How to apply this approach Developers set the approach elements organizing the traceability rules. Reviews in
the business processes resulting from new policies impacts in new UIs for the newly created tasks.
Creation To define the user interaction, a task model is used to describe how tasks can be performed to
reach the users’ goals when interacting with the system. These activities contain essential information to
conceive all UIs, a means by which users interact with the system.
Use Business process and user interfaces changes start the analysis of traceability impact. After that, settings
are made to keep the updated model. The change in the business process would generate changes on the
UIs related solely to the creation of new screens.
22
FUNCTIONAL REQUIREMENTS TRACEABILITY
3.11
#FRT11 - Generation and Validation of Traces between Requirements and Architecture
Description This approach provides traces establishment by using semantics of traces between requirements and
architecture (R&A). The tool provides the following: (i) generation/validation of traces by using requirements
relations and/or verification of architecture, and (ii) generation/validation of requirements relations by using
traces. The tool uses the semantics of traces together with requirements relations and verification results for
generating and validating traces. Generating traces is the activity of deducing traces between requirements and
architecture based solely on verification of architecture and/or the requirements relations. Alternatively, the
software architect can provide an initial set of traces as input. Validating traces is the activity of identifying the
traces which do not obey trace semantics. This approach is supported by a tool where the main feature is trace
generation and validation. The Figure 3.7 presents the tool structure with the inputs and outputs elements.
Figure 3.7
Overview of the tool
The tool checks if the requirements are satisfied by the architecture. This is done by reformulating the requirements in terms of logical formulas over the architecture.
Process support tools A tool was developed with the following features: (i) Verification of Architecture for Functional Requirements, (ii) Generation of Traces and (iii) Validation of Traces. The tool uses Maude, a formal
language based on equational and rewriting logic, and MDE technologies such as Eclipse EMF and ATL.
Restriction of using Maintenance of traces is not covered in this approach. In case of changes in the requirements
or in the architecture, some of the traces will be invalid and incomplete.
How to apply this approach This approach is supported by a tool. The tool uses the semantics of traces together
with requirements relations and verification results for generating and validating traces.
Creation The first step is to verify the architecture to identify the links to functional requirements. After
that, generating traces aims at deducing traces between requirements and architecture based solely on
verification of architecture and/or the requirements relations in the requirements model. The verification
result, and therefore the traces, depends on the reformulation of the requirement to be checked. Finally,
validation aims at identifying the traces which do not obey the trace semantics. The tool uses the semantics
of requirements relations together with the trace semantics to validate traces which are already generated or
assigned by the architect. Checking is performed according to the constraints derived from the semantics
of traces and requirements relations.
Use This approach generates a set of informations composed by a model of requirements (produces the reformulated requirements as output), model of traces (using model transformations) and error model (produces the invalid assigned traces). After Identify the output models, eventually mistakes can be manually
corrected.
23
3.12
#FRT12 - Semi-automated Traceability Maintenance - traceMaintainer
Description traceMaintainer is a tool that supports an approach for maintaining post-requirements traceability
relations after changes made to traced model elements. This tool supports the (semi-)automated update of
traceability relations between requirements, analysis and design models of software systems expressed in
UML.
Process support tools The approach is supported by a tool (traceMaintainer) for maintenance of post-requirements
traceability relations after changes made to traced model elements.
Restriction of using Software documentation should be expressed in UML to use the approach and traceMaintainer. Another restriction is the use of a CASE to model a software product. Figure 3.8 shows how models
are connected with the tool solution through Event Generator and traceSTORE.
How to apply this approach This approach works with associated CASE tools. The Figure 3.8 shows the add-in
event generator and traceSTORE responsible for listening the model changes and for communicating with the
Rule Engine. The next step to use the approach is to analyze the rules and make the eventual interferences to
keep integrity updated.
Figure 3.8
Overview of traceMaintainer components
Creation traceMaintainer create traces by analyzing elementary change events that have been captured while
working within a third-party UML modeling tool. Within the captured flow of events, development activities comprised of several events are recognized. These development activities are expressed as predefined
rules. Once recognized, the corresponding rule gives a directive to update impacted traceability relations
to restore consistency.
Use There are two information generated by the traceMaintainer that separate the incoming and outgoing
traceability relations involved in the update context. Existing or potential new traceability relation, where
the user can decide to keep or delete existing relations on the source elements. For the evolved elements,
the user can decide to create or discard the relation. A decision on the proposed relations without preselected determined actions is required to be able to complete the update, while a change of a preselected
action is made possible in other cases but not required.
CHAPTER 4
NON-FUNCIONAL REQUIREMENTS TRACEABILITY
Non-functional requirements (NFR - also called quality requirements) are generally more difficult to express in
a quantifiable manner and they are hard to be verified for individuals components. Create tracing links for nonfunctional requirements is also a challenger since tracing requirement specifications toward the designing and
vice-versa requires a lot of attention of developers. The Non-Functional Requirements Traceability knowledge area
intends to help practitioners to manage NFR trace links. Here, approaches are presented (following the structure
from Figure 1.2) in a such way that practitioners can find alternatives for traceability of non-functional requirements.
25
26
4.1
NON-FUNCTIONAL REQUIREMENTS TRACEABILITY
#NFRT01 - Full Traceability of Non-Functional Requirements within Domain-Specific Modeling
Description This approach intends to manager trace links among non-functional requirements. It is based on NFR
framework that tackles the difficult to manage non-functional requirements by decomposing them into sets of
smaller subgoals. NFR+ Framework extends NFR framework by adding traceability management. MetaEdit+
is a implementation of NFR+ Framework. The idea in this approach is from non-functional requirements
create smaller and quantifiable requirements (called softgoals) that are linked by softgoal interdependency
graphs (SIG). Quantifiable requirements are non-functional requirements that can be evaluate. For example,
instead of a requirement be The user cannot wait long for his/her request, it should be The user must wait
at most 5 seconds for his/her request. In the SIG, developers have to inform, among others, values for every
decomposed requirement. Thus, non-functional requirements are decomposed and SIGs are built from this
decomposition. SIG may have connection to other SIGs and trace links are created from the SIGs and the interconnection of the SIGs. MetaEdit+ may work with Open Source Requirement Management Tool (OSRMT)
by exchanging XML documents. Individual model types are proposed to make easier to manage to softgoals.
These models are called catalogs and there exists four of them: (i) type catalog that stores knowledge of a
softgoal, (ii) method catalog that shows the possible operationalizations for softgoals (e.g., programs), (iii)
correlation catalog that contains information on the implicit interdependencies among softgoals (e.g., a softgoal can hurt another one, it means, the way a non-functional requirement is implemented may harm another
non-functional requirement), and (iv) contribution catalog that is a special SIG graph defining the outcome
of pairs of child labels and contributions. The three first catalogs are proposed in the original framework
(NFR) and the last one is part of the proposed extension. Contribution catalog allows developers to identify
the contribution symbols for each part of a softgoal. Notice that a softgoal and its parts are represented by
nodes in SIG and arcs that connect these nodes may be labeled with the kind of contribution connected nodes
have to each other. This approach provides the traceability of non-functional requirements from early user
requirements to implementation and testing, and backwards.
Restriction of using This approach must be used within domain-specific modelling since it needs an initial project
model to set MetaEdit+.
Supported tool MetaEdit+ is implemented in Java and the graphs are implemented in Python. The user may
configure MetaEdit+ to work with OSRMT.
How to apply this approach The product must be designed using Domain-Specific Modeling and non-functional
requirements must be decomposed into quantifiable softgoals.
Creation All functional requirements may be managed by OSRMT and MetaEdit+ manages only nonfunctional ones. Both tools are integrated by XML documents. Developers import and export requirements from and to both tools.
Use Non-functional requirements may be managed automatically: when the tool find an inconsistency in the
graphs, it requires developers to fix the problem. The approach is a bridge between requirements and
meta-case tools, thus, developers must use both technologies with MetaEdit+.
27
4.2
#NFRT02 - Safety Requirements Traceability Support in MDD of Robotic Applications
Description This approach considers traceability of safety requirements in the context of model-driven development of teleoperated services robots. The combination of the software development approaches make it
possible to construct systems using techniques for automatically identifying, managing, and mitigating risks.
This traceability approach was proposed to guarantee the interaction between the teleoperated services robots
and both the human and the environment. The methodology presented in this approach proposes the fusion of
different standards. The four steps are summarized as follows:
Step 1 - Identify hazards: includes identification of the possible causes of the failure (hardware, software, or
human), the tasks in which it can happen, and the reaction to the occurrence of the hazard.
Step 2 - Identify risks: Identify the possible risks of the system, classify them according to the impact they
have on the system and the environment, and link them to the hazards identified in the first step.
Step 3 - Specify safety requirements: extract the system safety requirements from the results of the previous
steps.
Step 4 - Make safe designs: the design of the systems software architecture must consider the safety requirements, avoid failures that spread through the whole system, and be periodically reviewed when new hazards
are identified.
Restriction of using The use is restrict for software development using MDD (Model Driven Development).
Supported tool There is an implemented tool responsible for the traceability report. For the other steps of the
approach, there is no supported tools.
How to apply this approach A general schematic of the artifacts and tools is used in the proposed process. There
are two clearly differentiated parts: 1) the part relating to management of safety requirements (Traceability
Management) and 2) the part integrated in the application software modeling process and code generation
(V3 CMM Framework). The process works as follows: first, user starts modeling the safety requirements or
reusing requirements that have been defined previously. After, user must then develop an architecture solution
(a V3 CMM model) that meets the safety requirements. The traceability matches between safety requirements
and the elements of architecture design that satisfy them must be noted in the model called “Traceability
Model #1” following the metamodel proposed in this approach. These annotations are created manually and
are used as inputs for the tool created to support this approach.
Creation To create traces, it is necessary to follow the proposed metamodel structure as shown in Figure 4.1.
The Link element of the metamodel is defined by: (i) An Element Model (source), which references an
element of the safety-based requirements metamodel and (ii) An Element Model (target), which references
an element of the V3 CMM.
Figure 4.1
Traceability metamodel
Use Once the traceability is generated, a report with the traced elements can be obtained using the SafetyRequirements-Trace-Tool (SRTT). This report analyzes the different models level to generate the informations and it was developed whit the tool that support the approach. With this report, designers can examine
28
NON-FUNCTIONAL REQUIREMENTS TRACEABILITY
the way in which a requirement has been taken into account in the automatic code generation process and
receive information on the solution adopted, which in some cases will be a design pattern.
29
4.3
#NFRT03 - Means-ends and whole-part traceability analysis of safety requirements
Description This approach propose an optimized traceability analysis method which is based on the means-ends
and whole-part concept of the approach for cognitive systems engineering to trace these safety requirements.
The safety requirements of a system and its components ( hardware, software, and humans) are enforced or
implemented through a means-ends life cycle. The approach works with a concept presented in Figure 4.2,
where a whole-part relation presents a hierarchical decomposition of a physical system. In a means-ends
abstraction, each level represents a different model of the same system (aggregation of components). At any
point in the hierarchy, the information at one level acts as the goals (the ends) with respect to the model at
the next lower level (the means). Thus, in a means-ends abstraction, the current level specifies what (to do),
the level below describes how (to do), and the level above why (to do). Any information (what) can also be
considered as a goal (why) for information at a lower level, as well as a means (how) for other information at
a higher level.
Figure 4.2
Approach concepts
In the proposed approach, during the development, the why information such as the system goals, constraints,
and safety requirements are incorporated into the next level of means-ends hierarchy with the whywhathow
relationships in order to develop the system artifacts until the physical products have been developed. In the
safety analysis part, the traditional cause-event techniques like FMEA, HAZOP, and FTA are also conducted
with the same why-what-how relationships through out a lifecycle. The approach also acknowledges the
complementary relation between a system development and a safety analysis.
Restriction of using Approach restrictions are the nature of the traceability aim. In this case, traceability analysis
of safety requirements. Also the tools are restricted since they are constructed specially for this approach.
Supported tool The approach is supported by two tools: TRACE (Traceability of Requirements for Analysable
Computerised Environments) and NuSRS (Nuclear software requirements specification). NuSRS is a tool for
supporting a specification and verification of software requirements for a digital plant protection system in
nuclear power plants.
How to apply this approach This approach is conceived to use TRACE and NuSCR tools. To apply this approach
is necessary to use TRACE to link all the nodes in the NuSCR requirement specification with other information
like the design specification and safety analysis result. The traceability analysis tool, TRACE, can be used to
link the artifacts from the system development and the safety analysis. And also the requirements specification
tool, NuSRS, can be used to elicit, spedify, and enforce the requirements including the safety constraints.
Creation TRACE can be used to link all the nodes in the NuSCR requirement specification with other information like the design specification and safety analysis results. The link between TRACE and NuSCR
enables the traceability in two dimensions, means-end (goal and system safety objectives, system requirements, components requirements, component design and component product) and whole-part (system,
30
NON-FUNCTIONAL REQUIREMENTS TRACEABILITY
human, software and hardware). To create the links, during the system specification, the engineers make
the links between the objects in two dimensions.
Use Results can be obtained by reading the tools registered links. The safety analysis is the main result given
by the tools.
31
4.4
#NFRT04 - A SysML-based approach to traceability management and design slicing in support of safety certification
Description This approach includes a traceability information model, a methodology to establish traceability, and
mechanisms to use traceability for extracting slices of models relevant to a particular (behavioral) safety requirement. Safety critical systems in domains such as avionics, automotive, maritime and energy, the software
control modules, integrated with hardware devices and continuously interact with the environment are candidates to use this approach. There are difficulties in the software safety certification process that arise from
poor traceability. The focus has been on ensuring that both the design and the links between the requirements
and the design are “precise” enough to allow for systematic design inspections.
Restriction of using In this approach, requirements are expressed as (unrestricted) natural language statements
and the design is expressed using the Systems Modeling Language (SysML). Moreover, the slicing technique
is used to facilitate design safety inspection by enabling engineers to focus on the aspects of the design that
are relevant to safety. This approach does not consider other categories of requirements, such as performance,
availability, and security, which can have safety implications.
Supported tool The SafeSlice tool was developed to support the approach. SafeSlice has been implemented as a
plugin for Enterprise Architect.
How to apply this approach To apply this approach, there are two phases.
Phase I is composed by three steps: (i) system context diagram: to specify the boundary between the system
and its context, (ii) system-level requirement diagram: address the entire system, and can relate to both hardware and software, and (iii) use case diagram capturing system top-level functions: represent the functionality
of the software part of a system from an external point of view.
Phase II is composed by six steps: (iv) and (v) Structural diagrams: composed by a system decomposition and
communication interfaces, describe the structure of a system using SysML Block Definition Diagrams (BDDs)
and Internal Block Diagrams (IBDs). (vi) and (vii) Behavioral diagrams: use sequence/activity diagrams to
represent inter-block scenarios, and state machine diagrams to represent intra-block state-based specifications.
(viii) and (ix) Establish traceability: establish traceability links from the system-level requirements down to
the design diagrams adapting and using the SysML traceability links. The traceability links specify which
parts of the design contribute to the satisfaction of each requirement. The methodology sequence of steps can
be seen in Figure 4.3.
Figure 4.3
Methodology for model-driven development of control systems
Creation The links creation are taken by the tool.
32
NON-FUNCTIONAL REQUIREMENTS TRACEABILITY
Use This approach has the intention to help the safety certifications. In this way, the use of the traces generated during the system conception will happen during the inspections.
CHAPTER 5
SOFTWARE PRODUCT LINE TRACEABILITY
The large number and heterogeneity of documents generated during the development of product line systems
may cause difficulties to identify common and variable aspects among applications, and to reuse core assets that
are available under the product line. The commonalities and variabilities in software product line increases the
traceability difficulty. Approaches related in this knowledge area present alternative solutions for traceability in
software product line development. The presentation is organized following the structure from Figure 1.2.
33
34
5.1
SOFTWARE PRODUCT LINE TRACEABILITY
#SPLT01 - A Metamodeling Approach to Tracing Variability between Requirements and Architecture in SPL
Description This approach focuses on tracing variability between a requirement and architecture in a product line.
The approach affirms that variability is done in all generic artifacts as variation points and variation points
may consequently appear in various generic artifacts and at any level of abstraction. The proposed metamodel
makes an explicit capture and appropriate manage traceability between variation points at different level of
abstraction. This approach proposes tracing variability between requirement and architecture in a product line.
The OMG (Object Management Group) adopted Reusable Asset Specification (RAS), an open standard that
can be used to manage any set of development artifacts. This approach is defined in two domains. Domain
Requirement Metamodel: the primary responsibility is to define artifact constituents to specify the domain
requirements models in a specific domain. The Figure 5.1 presents the objects Asset, Solution and Artifact
inherited from RAS. The other objects are proposed to create the traceability environment.
Figure 5.1
Metamodel of domain requirement
At the same way, Figure 5.2 shows the same objects from Figure 5.1 as RAS objects. Others are proposed
to create the traceability environment. Primary responsibility of domain architecture metamodel is to define
artifact constituents for specifying domain architecture models in a specific domain.
Figure 5.2
Metamodel of domain architecture
Figure 5.3 shows a variability trace metamodel where trace relationships between domain requirements and
domain architecture are defined. The trace relationships from the domain requirements to the domain architecture are divided into the following two types: (i) trace for variations in artifact constituents and (ii)
trace for variations in artifact models. The variations of domain models depend on the variations of artifact
constituents.
Restriction of using To use this approach is necessary to create an environment with the presented descriptions.
Supported tool There is no supported tool for this approach.
35
Figure 5.3
Variability trace metamodel
How to apply this approach To apply this concepts is necessary to create an environment to apply the proposed
variability trace metamodel. Actually, there is no support tool. Create a tool to support the metamodel in an
alternative.
Creation To create the traces is necessary to identify and register the objects used to construct the product
in product line context. Every relation between different artifacts should be registered. After that, the
informations are ready to be used.
Use The use of the traces in this approach is realized by the trace matrix. The matrix are conceived from the
metamodels informations (artifacts constituents and model).
36
5.2
SOFTWARE PRODUCT LINE TRACEABILITY
#SPLT02 - Traceability in Software Product Line using Formal Concept Analysis
Description The main goal of this approach is to establish a framework for automated formal identification of
the traceability between feature model and architecture model. Feature modeling is a method for describing
commonalities and variabilities in software product line. Software architecture of a program or computing
system is the structure or structures of the system. This approach uses the technique Formal Concept Analysis
(FCA) to identify feature and architecture model. FCA is a theory of data analysis which identifies conceptual
structures among data sets. The approach consists of three steps (as shown in Figure 5.4):
Figure 5.4
Traceability Identification Approach
The first step consist of extracting functional decomposition from feature description and architecture description. The second step is building concept lattice using FCA tool. The final step is analyzing concept lattice to
identify mapping elements.
Restriction of using This approach is applicable for software development based on functional decomposition.
Also is necessary to develop feature model and architecture model. Another restriction is a missing tool for
automate this approach.
Supported tool There is no related tool that work with this approach.
How to apply this approach This approach is a concept proposed to create a lattice to identify the traces between
feature model and architecture model in product line. To apply this approach is necessary to support the
concepts by a tool or tools.
Creation The creation of the traces is presented in Figure 5.4. To create traces is necessary to identify
the relations between feature and architecture models. This step can be automated using the extraction
algorithms, however, the approach does not present these algorithms. The traces are derived from the first
step information. To finalize the creation of traces is still necessary to analyze the lattice concepts. This
step answers some questions about feature and architecture elements identified: (i) They exactly have
same functional decomposition? (ii) the feature element is implemented by the architecture element?, and
(iii) the feature element is implemented by several architecture elements?
Use To identify mapping relationship, the meaning of concept lattice representation have to be interpreted. A
mechanism for retrieving the traceability is not available in this approach.
37
5.3
#SPLT03 - A rule-based traceability approach for product line systems
Description This approach proposes a tool called XTraQue that implements an automatic generation of traceability relations between elements of documents created during the development of product line systems.
Documents are generated within domain analysis and design (feature-based) and object-oriented methodologies. Feature-based and objetc-oriented are inplemented using an extension of FORM methodology. The
proposed reference model contains nine different types of traceability relations: satisfiability, dependency,
overlaps, evolution, implements, refinement, containment, similar, and different. Those relations are applied
in for eight types of documents divided into two groups: product line information and product member information. The first group is composed by feature, subsystem, process, and module models. The second one
is composed by use cases, class, statechart, and sequence diagrams. Documents are represented by XML
documents and rules are represented by XQuery definitions. XTraQue supports five functionalities: (i) specification of the documents to be traced, (ii) specification of the types of relations to be created, (iii) generation
of direct and indirect traceability relations based on the input given in (i) and (ii), (iv) visualisation of the
documents containing traceability relations generated in (iii), and (v) testing of new traceability rules. The
functionality (i) allows users to select and to establish traceability relations between documents of two specific
product members, documents at the level of product line and one specific product member, and documents at
the level of product line and two specific product members. XTraQue also intends that traceability relations
have semantic meanings and directions instead of being simple links between different elements. The extension proposed in XQuery allows to represent traceability rules and the use of rules that take into consideration
(i) semantic of the documents being compared, (ii) various types of traceability relations in the product line
domain, (iii) grammatical roles of the words in the textual parts of the documents, and (iv) synonyms and
distance of words being compared in a text.
Restriction of using The approach assumes that for each line of software system being developed, there is a single
instance of feature and subsystem models, but there may exist various instances of process and module models
and various instances of documents in the product member level (i.e. use cases, class, statechart, and sequence
diagrams). Moreover, product line systems have to be developed using a proposed extension of FORM and
feature-based and object-oriented methodologies.
Supported tool XTraQue is based on documents generated by an extension of FORM methodology.
How to apply this approach Users must use FORM methodology altogether with feature-based and object-oriented
methodology. Trace links are built automatically from documents generated by these methodology
Creation The users choose documents to be traced: all the documents related to the product line and product
members, or specific documents to be traced based on type of documents, particular document names, or
types of traceability relations.
Use The XML documents containing traceability information are visualized by XTraQue. XTraQue still
allows creation of new traceability rules and the execution of these rules in order to verify their correctness.
When a new corrected rule is created, user can insert it in the document containing all the traceability rules.
CHAPTER 6
GLOSSARY
TRACEBOK GUIDE
This glossary is proposed to support the use of this body of knowledge. The selected terms contribute with the
comprehension of the traceability concepts and with the presented approaches in this document. Gotel et al. [12]
propose a glossary with terms and concepts used in traceability. The terms presented in this document is an
adaptation of the concerned terms for the selected approaches.
39
40
GLOSSARY
Automated traceability:The potential for automated tracing.
Automated tracing: When traceability is established via automated techniques, methods and tools.
Backward tracing: Tracing follows antecedent steps in a developmental path, which is not necessarily a
chronological path, such as backward from code through design to requirements.
Bidirectional tracing: When tracing can be undertaken in both forward and backward direction.
Candidate trace link: A potential, as yet unverified, trace link.
Forward tracing: The tracing follows subsequent steps in a developmental path, which is not necessarily a
chronological path, such as forward from requirements through design to code.
Horizontal tracing: Tracing artifacts at the same level of abstraction. Horizontal tracing employs both forward tracing and backward tracing.
Manual tracing: When traceability is established manually.
Post-requirements (specification) traceability: Comprises those traces derived from or grounded in the
requirements, and hence the traceability describes the requirements deployment process.
Pre-requirements (specification) traceability: Comprises all those traces that show the derivation of the
requirements from their original sources, and hence the traceability describes the requirements production
process.
Requirements management: The activity concerned with the effective control of documenting, analyzing,
tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant
stakeholders
Requirements traceability: process that allows to ensure the continuous concordance between stakeholders
requirements and the artifacts produced along software development process.
Software traceability: extends the definition of requirements traceability to encompass and interrelate any
uniquely identifiable software engineering artifact to any other.
Systems traceability: extends the definition of requirements traceability to encompass and interrelate any
uniquely identifiable systems engineering artifact to a broad range of systems-level components, such as
people, processes and hardware models.
Target artifact: The artifact at the destination of a trace.
Trace (Noun): A specified triplet of elements comprising: a source artifact, a target artifact and a trace
link associating the two artifacts. Where more than two artifacts are associated by a trace link, such as the
aggregation of two artifacts linked to a third artifact, the aggregated artifacts are treated as a single artifact.
Trace (Verb): The act of following a trace link from a source artifact to a target artifact (primary trace link
direction) or vice-versa (reverse trace link direction).
Trace artifact: A traceable unit (e.g., a single requirement, a cluster of requirements, a UML class, a UML
class operation, a Java class or even a person). A trace artifact is one of the trace elements and is qualified
as either a source artifact or as a target artifact when it participates in a trace. The size of the traceable unit
defines the granularity of the related trace.
Trace creation: The activity of creating a single trace, associating two artifacts via a trace link. The trace link
may be created manually, automatically using tools or semi-automatically using some combination of tool
and manual input.
Trace element: Used to refer to one of the trace triplet: source artifact, target artifact or trace link.
41
Trace generation: A particular approach to trace creation that implies trace links are created automatically
or semi-automatically using tools.
Trace granularity: The level of detail at which a trace is recorded and performed. The granularity of a trace
is defined by the granularity of the source artifact and the target artifact.
Trace life cycle: A conceptual model that describes the series of activities involved in the life of a single trace,
from initial conception, through creation, maintenance and use, through to eventual retirement.
Trace link: A specified association between a pair of artifacts, one comprising the source artifact and one
comprising the target artifact.
Trace maintenance: activities associated with updating a single pre-existing trace.
Trace query: A term often used in the process of generating or vetting trace links, where one high level element is regarded as the trace query for searching into an artifact collection to find trace links (as distinguished
from traceability-related queries).
Trace recall: A commonly used metric in automated tracing that applies to rep- resent the fraction of relevant trace links that are retrieved. It is computed as: Recall = (RelevantLinks ∩ RetrievedLinks) \
RelevantLinks.
Trace relation: All the trace links created between two sets of specified trace artifact types. The trace relation
is the instantiation of the trace relationship and hence is a collection of traces. For example, the trace relation
would be the actual trace links that associate the instances of requirements artifacts with the instances of test
case artifacts on a project. The trace relation is commonly recorded within a traceability matrix.
Trace relationship: An abstract definition of a permissible trace relation on a project (i.e., source artifact
type, target artifact type and trace link types), as typically expressed within a traceability information model
(TIM). Note that the trace links of the instances of the two artifact types may not necessarily have the same
trace link type.
Trace retrieval: A particular approach to trace creation where information retrieval methods are used to
dynamically create a trace link. This approach can be used for both trace capture and trace recovery.
Trace precision: A commonly used metric in automated tracing that applies to represent the fraction of
retrieved trace links that are relevant. It is computed as: P recision = (RelevantLinks∩RetrievedLinks)\
RetrievedLinks.
Traceability: Ability to track software artifacts from its creation to its retirement.
Traceability information model (TIM): A graph defining the permissible trace artifact types, the permissible trace link types and the permissible trace relationships on a project, in order to address the anticipated
traceability-related queries and traceability-enabled activities and tasks. The TIM is an abstract expression of
the intended traceability for a project.
Traceability lifecycle: A conceptual model that describes the series of activities associated with a full endto-end traceability process.
Traceability link: A term often used in place of trace link. Arguably, while traceability link captures the
enabling role of the link for traceability purposes, trace link emphasizes the fact that the link is a primary
element of a trace.
Traceability maintenance: Those activities associated with updating preexisting traces in the face of trace
evolution, and establishing new traces where needed, to keep the traceability relevant and up to date.
Traceability management: Those activities associated with providing the control necessary to keep the stakeholder and system requirements for traceability and the traceability solution up to date during the life of a
project. Traceability management is a fundamental part of traceability strategy.
42
GLOSSARY
Traceability matrix: A matrix recording the traces comprising a trace relation, showing which pairs of trace
artifacts are associated via trace links.
Traceability method: A prescription of how to perform a collection of traceability practices, integrating
traceability techniques with guidance as to their application and sequencing.
Traceability network: A traceability graph in which the directionality of the trace links is expressed (i.e., the
artifacts are depicted as ordered pairs) and where the trace links are potentially weighted in some manner.
Traceability planning: Those activities associated with determining the stakeholder and system requirements
for traceability and designing a suitable traceability solution. Traceability planning is a fundamental part of
traceability strategy.
Traceability policy: Agreed principles and guidelines for establishing and using traceability in practice.
Traceability practices: Those actions and activities associated with planning, managing, creating, maintaining and using traceability.
Traceability process: The particular series of activities to be employed to establish traceability and render
it usable for a particular project, along with a description of the responsibilities and resourcing required
to undertake them, as well as their inputs and outputs. The traceability process defines how to undertake
traceability strategy, traceability creation, traceability maintenance and traceability use.
Traceability strategy: Those decisions made in order to determine the stakeholder and system requirements
for traceability and to design a suitable traceability solution, and for providing the control necessary to keep
these requirements and solutions relevant and effective during the life of a project. Traceability strategy
comprises traceability planning and traceability management activities.
Traceability technique: A prescription of how to perform a single traceability practice, such as traceability
creation, along with a description of how to represent its traceability work products.
Traceability tool:Any instrument or device that serves to assist or automate any part of the traceability process.
Traceable:The potential for artifacts to be accessed and retrieved by following trace links.
Tracking: The term commonly applies to the act or process of following requirements and depends upon
requirements traceability.
Traced: The artifacts that have been accessed by tracing, and so by having followed trace links.
Tracing: The activity of either establishing or using traces.
Tracking: The act or process of following requirements and depends upon requirements traceability.
Vertical tracing: Tracing artifacts at differing levels of abstraction so as to accommodate lifecycle-wide or
end-to-end traceability, such as from requirements to code. Vertical tracing employs both forward tracing and
backward tracing.
REFERENCES
1. Hazeline U. Asuncion, Frédéric Fran cois, and Richard N. Taylor. An end-to-end industrial software traceability tool.
In Proceedings of the the 6th joint meeting of the European software engineering conference and the ACM SIGSOFT
symposium on The foundations of software engineering, ESEC-FSE ’07, pages 115–124, New York, NY, USA, 2007.
ACM.
2. G. Buchgeher and R. Weinreich. Automatic tracing of decisions to architecture and implementation. In Software Architecture (WICSA), 2011 9th Working IEEE/IFIP Conference on, pages 46–55, 2011.
3. Lawrence Chung, B Nixon, E Yu, and J Mylopoulos. Non-functional requirements in software engineering. Kluwer
Academic Publishing, 2000.
4. J. Cleland-Huang, P. Mader, M. Mirakhorli, and S. Amornborvornwong. Breaking the big-bang practice of traceability:
Pushing timely trace recommendations to project stakeholders. In Requirements Engineering Conference (RE), 2012 20th
IEEE International, pages 231–240, 2012.
5. J. Cleland-Huang and D. Schmelzer. Dynamically tracing non-functional requirements through design pattern invariants.
In Workshop on Traceability in Emerging Forms of Software Engineering, October 2003.
6. Jane Cleland-Huang, Orlena Gotel, and Andrea Zisman. Software and Systems Traceability. Springer London, 2012.
7. Alexander Delater and Barbara Paech. Analyzing the tracing of requirements and source code during software development. In Proceedings of the 19th international conference on Requirements Engineering: Foundation for Software
Quality, REFSQ’13, pages 308–314, Berlin, Heidelberg, 2013. Springer-Verlag.
8. Hubert Dubois, Marie-Agnes Peraldi-Frati, and Fadoi Lakhal. A model for requirements traceability in a heterogeneous
model-based design process: Application to automotive embedded systems. In Proceedings of the 2010 15th IEEE
International Conference on Engineering of Complex Computer Systems, ICECCS ’10, pages 233–242, Washington, DC,
USA, 2010. IEEE Computer Society.
9. Alexander Egyed, Gernot Binder, and Paul Grunbacher. Strada: A tool for scenario-based feature-to-code trace detection
and analysis. In Companion to the proceedings of the 29th International Conference on Software Engineering, ICSE
COMPANION ’07, pages 41–42, Washington, DC, USA, 2007. IEEE Computer Society.
10. I. Galvao and A. Goknil. Survey of traceability approaches in model-driven engineering. In Enterprise Distributed Object
Computing Conference, 2007. EDOC 2007. 11th IEEE International, pages 313–313, 2007.
11. Arda Goknil, Ivan Kurtev, and Klaas van den Berg. Tool support for generation and validation of traces between requirements and architecture. In Proceedings of the 6th ECMFA Traceability Workshop, ECMFA-TW ’10, pages 39–46, New
York, NY, USA, 2010. ACM.
43
44
REFERENCES
12. O. Gotel, J. Cleland-Huangand A. Zisman, J. Huffman Hayes, A. Dekhtyar, P. Mäder, A. Egyed, P. Grünbacher, G. Antoniol, and J. Maletic. Glossary of traceability terms (v1.0). In Software and Systems Traceability, pages 413—424.
Springer, 2012.
13. O.C.Z. Gotel and A.C.W. Finkelstein. An analysis of the requirements traceability problem. In Requirements Engineering
– 1994 – Proceedings of the First International Conference on, pages 94–101, 1994.
14. Waraporn Jirapanthong and Andrea Zisman. Xtraque: traceability for product line systems. Software & Systems Modeling,
8(1):117–144, 2009.
15. Gerald Kotonya and I. Sommerville. Requirements engineering: processes and techniques. Worldwide series in computer
science. J. Wiley, 1998.
16. Jang-Soo Lee, Vikash Katta, Eun-Kyoung Jee, and Christian Raspotnig. Means-ends and whole-part traceability analysis of safety requirements. Journal of Systems and Software, 83(9):1612–1621, 2010. ¡ce:title¿Software Dependability¡/ce:title¿.
17. P. Mader, O. Gotel, and I. Philippow. Semi-automated traceability maintenance: An architectural overview of tracemaintainer. In Software Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International Conference on,
pages 425–426, 2009.
18. Patrick Mäder and Orlena Gotel. Towards automated traceability maintenance. Journal of Systems and Software,
85(10):2205–2227, 2012. ¡ce:title¿Automated Software Evolution¡/ce:title¿.
19. Ivano Malavolta, Henry Muccini, and V. Smrithi Rekha. Supporting architectural design decisions evolution through
model driven engineering. In Proceedings of the Third international conference on Software engineering for resilient
systems, SERENE’11, pages 63–77, Berlin, Heidelberg, 2011. Springer-Verlag.
20. Mikyeong Moon, Heung Seok Chae, Taewoo Nam, and Keunhyuk Yeom. A metamodeling approach to tracing variability
between requirements and architecture in software product lines. In Proceedings of the 7th IEEE International Conference on Computer and Information Technology, CIT ’07, pages 927–933, Washington, DC, USA, 2007. IEEE Computer
Society.
21. Shiva Nejati, Mehrdad Sabetzadeh, Davide Falessi, Lionel Briand, and Thierry Coq. A sysml-based approach to traceability management and design slicing in support of safety certification: Framework, tool support, and case studies.
Information and Software Technology, 54(6):569–590, 2012.
22. S.L. Pfleeger. Engenharia de Software - Teoria e Prática. Prentice Hall - São Paulo, 2nd edition, 2004.
23. G. Regan, F. McCaffery, K. McDaid, and D. Flood. The barriers to traceability and their potential solutions: Towards a
reference framework. In Software Engineering and Advanced Applications (SEAA), 2012 38th EUROMICRO Conference
on, pages 319–322, 2012.
24. P. Sanchez, D. Alonso, F. Rosique, B. Alvarez, and J.A. Pastor. Introducing safety requirements traceability support in
model-driven development of robotic applications. Computers, IEEE Transactions on, 60(8):1059–1071, 2011.
25. Tonny Kurniadi Satyananda, Danhyung Lee, Sungwon Kang, and Sajid Ibrahim Hashmi. Identifying traceability between
feature model and software architecture in software product line using formal concept analysis. In Proceedings of the The
2007 International Conference Computational Science and its Applications, ICCSA ’07, pages 380–388, Washington,
DC, USA, 2007. IEEE Computer Society.
26. Hannes Schwarz, Jürgen Ebert, and Andreas Winter. Graph-based traceability: a comprehensive approach. Software &
Systems Modeling, 9(4):473–492, 2010.
27. Kênia Sousa, Hildeberto Mendonça, Jean Vanderdonckt, and Marcelo S. Pimenta. Supporting requirements in a traceability approach between business process and user interfaces. In Proceedings of the VIII Brazilian Symposium on Human
Factors in Computing Systems, IHC 08, pages 272–275, Porto Alegre, Brazil, Brazil, 2008.
28. Stefan Winkler and Jens Pilgrim. A survey of traceability in requirements engineering and model-driven development.
Software and Systems Modeling, 9(4):529–565, 2010.
29. Anton Yrjönen and Janne Merilinna. Tooling for the full traceability of non-functional requirements within model-driven
development. In Proceedings of the 6th ECMFA Traceability Workshop, ECMFA-TW ’10, pages 15–22, New York, NY,
USA, 2010. ACM.
30. Yijun Yu, Jan Jurjens, and J. Mylopoulos. Traceability for the maintenance of secure software. In Software Maintenance,
2008. ICSM 2008. IEEE International Conference on, pages 297–306, 2008.