Anais Do SBQS 2017 - Rio de Janeiro PDF

XVI SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE – SBQS 2017
28 a 30 de agosto de 2017
Rio de Janeiro/RJ – Brasil
ANAIS
Realização
SBC – Sociedade Brasileira de Computação
UNIRIO – Universidade Federal do Estado do Rio de Janeiro
Apoio
Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES)
Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq)
Edição
Andreia Malucelli (PUCPR)
Sheila Reinehr (PUCPR)
Organização
Gleison Santos (UNIRIO)
i
CIP – CATALOGAÇÃO DA PUBLICAÇÃO
Simpósio Brasileiro de Qualidade de Software (16.:2017 ago.28-30: Rio de Janeiro)
Anais / Edição Sheila Reinehr – Pontifícia Universidade Católica do Paraná, PUCPR, Andreia
Malucelli – Pontifícia Universidade Católica do Paraná, PUCPR, 2017.
416p.: il.
ISSN 2177-6369
Conhecido também como SBQS 2017
1. Engenharia de Software. 2. Qualidade de Software. I. Reinehr, Sheila. II. Malucelli,

Andreia. III. SBQS (16.:2017: Rio de Janeiro)
Esta obra foi impressa a partir de originais entregues, já compostos pelos autores.
Capa: Leonardo Mendes Cabral
Editoração:
Sheila Reinehr (Pontifícia Universidade Católica do Paraná – PUCPR)
Andreia Malucelli (Pontifícia Universidade Católica do Paraná – PUCPR)
ii
Apresentação
É com grande satisfação que, em nome do Comitê de Programa e do Comitê Organizador,

saudamos os participantes do XVI Simpósio Brasileiro de Qualidade de Software - SBQS 2017!
Este é um evento promovido anualmente pela Sociedade Brasileira de Computação (SBC). O

SBQS que representa um fórum em que a comunidade científica e a indústria da área de
software se encontram para compartilhar experiências, discutir problemas e soluções da área
de qualidade de software e estabelecer novas parcerias.
O SBQS foi iniciado em 2002, com o reconhecimento da SBC do crescimento contínuo, em

termos de participação de público e apresentação de trabalhos, do Workshop de Qualidade de
Software (WQS), evento realizado, durante oito anos, desde 1994. O evento se consolidou como
um evento de qualidade que integra as comunidades acadêmicas e empresariais em Qualidade
de Software, por meio de várias atividades, tais como a apresentação de artigos técnicos e
relatos de experiência, convidados internacionais, workshops e mini-cursos.
Em 2017, a cidade do Rio de Janeiro está sediando o SBQS. A Coordenação do Programa ficou a
cargo da Pontifícia Universidade Católica do Paraná (PUCPR), a Coordenação da Organização
está sob a responsabilidade da Universidade Federal do Rio de Janeiro (COPPE-UFRJ) e da
Universidade Federal do Estado do Rio de Janeiro (UNIRIO). Foram aceitos este ano 17 trabalhos
técnicos e 5 relatos de experiência para apresentação e publicação nos anais. Cada artigo foi
avaliado por, pelo menos, três membros dos respectivos Comitês de Programa, segundo
critérios pré-estabelecidos para cada trilha (trabalho técnico ou relato de experiência).
O SBQS 2017 conta com as palestras co vidadas: Garantia da Qualidade no Brasil – proferida
por Carlos Henrique Cabral Duarte e Qualidade de Software e Interação Universidade-Empresa:
Impacto e Relevância – proferida por Rafael Prikladnicki.
Paralelamente ao SBQS 2017, têm-se os seguintes eventos: XVI Concurso de Teses e

Dissertações em Qualidade de Software (CTDQS), XV Workshop de Teses e Dissertações em
Qualidade de Software (WTDQS), I Workshop de Engenharia e Qualidade do Software (WEQS) e
II Workshop de Qualidade de Produto de Software (WQPS).
Um evento deste porte não é possível sem o envolvimento de toda a comunidade de Qualidade
de Software. A qualidade deste programa é fruto da dedicação dos membros do Comitê Diretivo,
de Programa, de Concurso, Workshops e revisores. Somos imensamente gratos aos palestrantes
convidados, aos professores de minicursos e todos os autores que submeteram trabalhos. Todo
o nosso reconhecimento vai também para os membros do Comitê Organizador, em especial a
Gleison Santos (UNIRIO) e sua equipe.
Finalmente, desejamos a todos um ótimo simpósio e uma excelente semana no Rio de Janeiro!
Rio de Janeiro, Agosto de 2017.
Sheila Reinehr
Andreia Malucelli
Chair do Comitê de Programa do SBQS 2017
Gleison Santos
Chair do Comitê Organizador do SBQS 2017
iii
XVI Simpósio Brasileiro de Qualidade de Software – SBQS 2017
Coordenação do Comitê Organizador
Coordenação do Comitê de Programa
Trilha de Trabalhos Técnicos
Trilha de Relatos de Experiência
Comitê Diretivo
Adriano Bessa Albuquerque (UNIFOR)
Ana Regina Cavalcanti da Rocha (COPPE/UFRJ)
Marcello Thiry (UNIVALI)
Monalessa Perini Barcellos (UFES)
Tayana Conte (UFAM)
Comitê Organizador
Ana Regina Rocha (COPPE-UFRJ)
Cristina Cerdeiral (UNIRIO)
iv
Comitê de Programa - Trilha de Trabalhos Técnicos
Adenilso Simão - ICMC-USP
Adriano Albuquerque - UNIFOR
Alexandre Vasconcelos - UFPE
Alfredo Goldman - IME/USP
Aline Vasconcelos - IFFluminense
Ana Liddy Magalhães - UFMG/FUMEC
Ana Paula Bacelo - PUCRS
Ana Regina Rocha - COPPE/UFRJ
André Menolli - UENP
Andreia Malucelli - PUCPR
Auri Marcelo Rizzo Vincenzi - UFG
Breno França - COPPE/UFRJ
Carla Lima Reis - UFPA
Christiane Gresse von Wangenheim - UFSC
Cláudio SantÀnna - UFBA
Cristina Cerdeiral - UNIRIO
Daniel Lucrédio - UFSCar
Davi Viana - UFMA
Débora Paiva - UFMS
Edson Oliveira Jr - UEM
Fernanda Campos - UFJF
Glauco Carneiro – UNIFACS
Gleison Santos - Unirio
Guilherme Travassos - COPPE/UFRJ
Heitor Costa – UFLA
Igor Steinmacher - UTFPR
José Maldonado - SSC/ICMC-USP/São Carlos
Kathia Marçal de Oliveira - Université de Valenciennes et du Hainaut-Cambrésis
Leonardo Medeiros – IFAlagoas
Luanna Lopes Lobato - UFG
v
Marcello Thiry - UNIVALI
Marcelo Fantinato - USP
Marcelo Schots - UERJ
Marcelo Yamaguti - PUCRS
Marco Paludo - PUCPR
Monalessa Perini Barcellos - UFES
Natália Chaves Lessa Schots - IM/UFRJ
Patrícia Vilain - UFSC
Paulo Parreira Júnior - UFLA
Paulo Sérgio Santos - COPPE/UFRJ
Rafael Prikladnicki - PUCRS
Raul Wazlawick - UFSC
Regina Braga - UFJF
Reinaldo Cabral - UFAL
Ricardo Falbo - UFES
Rodrigo Spínola - UFBA
Rodrigo Santos - UNIRIO
Sandro Ronaldo Bezerra Oliveira - UFPA
Sérgio T. Carvalho - UFG
Sheila Reinehr - PUCPR
Suzana Sampaio - UFRPE
Tayana Conte - UFAM
Toacy Oliveira - COPPE/UFRJ
Uirá Kulesza - UFRN
Vinícius Garcia - UFPE
vi
Comitê de Programa - Trilha de Relatos de Experiência
Adenilso Simão - ICMC-USP
Ahilton Barreto - BNDES
Alfredo Goldman - IME - USP
Aline Vasconcelos – IF-Fluminense
Ana Liddy Magalhaes - UFMG / QualityFocus
Ana Paula Bacelo - PUCRS
Andre Menolli - UENP
Andrea Barreto - BNDES
Auri Marcelo Rizzo Vincenzi - UFSCAR
Breno de França - COPPE - UFRJ
Cláudio SantÀnna - UFBA
Cristina Cerdeiral - UNIRIO
Daniel Lucrédio - UFSCAR
Davi Viana - UFMA
Debora Paiva - UFMS
Edmeia Leonor Pereira Andrade - EMBRAPA
Edson OliveiraJr - UEM
Fernanda Campos - UFJF
Fernando Trinta - UFC
Glauco Carneiro - UNIFACS
Gleison Santos, UNIRIO
Heitor Costa - UFLA

vii
Igor Steinmacher - UTFPR
Jean Hauck - UFSC
Jobson Massollar - COPPE/UFRJ
José David - UFJF
Joselaine Valaski - PUCPR
Leonardo Medeiros – IF-Alagoas
Luanna Lopes Lobato - UFG
Marcelo Fantinato - USP
Marcelo Yamaguti - PUCRS
Marco Paludo - PUCPR
Maria Augusta Vieira Nelson - PUCMG
Maria Istela Cagnin - UFMS
Michel Soares - UFSE
Monalessa Perini Barcellos - UFES
Natasha Valentim - UFAM
Natália Chaves Lessa Schots - IM/UFRRJ
Nilson Salvetti - Uninove
Patricia Vilain, Universidade Federal de Santa Catarina
Paulo Parreira Júnior, Universidade Federal de Lavras
Paulo Sérgio Santos - UFRJ
Pedro Santos Neto - UFPI
Rafael Prikladnicki - PUCRS
Raquel Stasiu – PUCPR / UTFPR
Raul Wazlawick - UFSC
viii
Regina Braga - UFJF
Reinaldo Cabral - UFAL
Rejane Maria Figueiredo - UNB
Renata Teles Moreira - UFLA
Rodrigo Santos - UNIRIO
Rossana Andrade - UFC
Sandro Ronaldo Bezerra Oliveira - UFPA
Sarah Kohan - Fundação Carlos Alberto Vanzolini
Sergio T. Carvalho - UFG
Suzana Sampaio - UFRPE
Uirá Kulesza - UFRN
Vinicius Garcia - UFPE
Coordenação do Concurso de Teses e Dissertações em Qualidade de Software
Marcello Thiry (UNIVALI) - Doutorado
Rossana Andrade (UFC) - Mestrado
Comitê do Concurso de Teses em Qualidade de Software
Comitê do Concurso de Dissertações em Qualidade de Software
Carla Ilane Moreira Bezerra - UFC
Fabiana Marinho - IFCE
Glauco Carneiro - UNIFACS
Heitor Costa - UFLA
ix
José Maria Monteiro - UFC
Maria Souza - UFC
Rodrigo Reis - UFPA
Valéria Lelli - UFC
Vinicius Garcia - UFPE
Coordenação do XII Workshop de Teses e Dissertações em Qualidade de Software
Heitor Costa (UFLA)
Comitê do XII Workshop de Teses e Dissertações em Qualidade de Software
Gleison Santos – UNIRIO
Humberto Marques - PUCMG
Juliano Lopes de Oliveira - UFG
Raul Wazlawick – UFSC
Rodrigo Reis – UFPA
Uirá Kulesza – UFRN
Coordenação do II Workshop de Qualidade de Produto de Software
Guilherme Horta Travassos - COPPE/UFRJ
Sheila Reinehr – PUCPR
x
Comitê de Programa do II Workshop de Qualidade de Produto de Software
Guilherme Horta Travassos - COPPE/UFRJ
Sheila Reinehr – PUCPR
Coordenação do I Workshop de Engenharia e Qualidade do Software

para Internet das Coisas (QualityIot)
Guilherme Travassos - COPPE/UFRJ
Kathia Marçal de Oliveira - LAMIH/UVHC
Marcio Espíndola Freire Maia - GREAT/UFC
Rossana Maria de Costa Andrade - GREAT/UFC
Comitê de Programa do I Workshop de Engenharia e Qualidade do Software
para Internet das Coisas (QualityIot)
Atslands Rocha – UFC
Danielo G. Gomes - UFC
Flavia Delicato - UFRJ
Kiev Gama - UFPE
Márcio Maia - UFC
Paulo Pires - UFRJ
xi
SOCIEDADE BRASILEIRA DE COMPUTAÇÃO (SBC)
Presidência
Presidente: Lisandro Zambenedetti Granville - UFRGS
Vice-Presidente: Thais Vasconcelos Batista - UFRN
Diretorias
Diretora Administrativa - Renata de Matos Galante - UFGRS
Diretor de Finanças - Carlos André Guimarães Ferraz – UFPE
Diretor de Eventos e Comissões Especiais - Antônio Jorge Gomes Abelém – UFPA
Diretor de Educação - Avelino Francisco Zorzo – PUCRS
Diretor de Publicações - José Viterbo Filho – UFF
Diretora de Planejamento e Programas Especiais - Claudia Lage Rebello da Motta - UFRJ
Diretor de Secretarias Regionais - Marcelo Duduchi Feitosa – CEETEPS
Diretora de Divulgação e Marketing - Eliana Almeida – UFAL
Diretorias Extraordinárias
Diretor de Relações Profissionais - Ricardo de Oliveira Anido – UNICAMP
Diretora de Competições Científicas - Esther Colombini - UNICAMP
Diretor de Cooperação com Sociedades Científicas - Raimundo José de Araújo Macêdo - UFBA
Diretora de Articulação com Empresas - Cláudia Cappelli – UNIRIO
xii
SUMÁRIO
- RELATOS DE EXPERIÊNCIA –
QPS - Modelo para Avaliação de Produtos de Software: 1 ... 15

Resultados Iniciais
Ana Regina Rocha, Guilherme Travassos, Gleison Santos, Sheila
Reinehr
A álise da Relação e tre Cha ados e Modificações o Código- 16 ... 30

Fonte de um Sistema de Acompanhamento de Obras
Luciano Souza, Bruno Santana
Integração Contínua no Desenvolvimento de Software com a 31 ... 45

Linguagem ABAP
Leonardo Pletsch, Josiane Porto
Comparando Quantitativamente Processos de Software - 46 ... 59

Experiências com Práticas Ágeis
Igor Pereira, Vicente Amorim, Lucas Lima
Utilização da Ferramenta Redmine para Auxiliar na Obtenção da 60 ... 73

Certificação MPS-BR Nível F
Thiago Detomi, Paulo Parreira Júnior, Heitor Costa
- TRABALHOS TÉCNICOS -
MoLEva: Um Método de Avaliação de Qualidade para Aplicativos 74 ... 88

Educacionais Móveis
Gustavo Soad, Ellen Francine Barbosa
Mineração de Textos para Apoiar a Predição de Severidade de 89 ... 103

Bug Reports: um Estudo de Viabilidade
Jacson Rodrigues Barbosa, Ivone Matsuno, Eduardo Guimarães,
Solange Rezende, Auri Marcelo Rizzo Vincenzi, Marcio Delamaro
Inferência da Familiaridade de Código por Meio da Mineração de 104 ... 118

Repositórios de Software
Irvayne Ibiapina, Vanderson Moura, Werney Ayala Luz Lira,
Gleison Silva, Pedro Santos Neto
xiii
Alinhamento estratégico de melhoria de processos de software: 119 ... 133
percepções de um processo de apoio à decisão
Francisco Vasconcellos, Jucele Vasconcellos, José Adson Cunha,
Auri Marcelo Rizzo Vincenzi, Caíque Minhare Minhare, Leonardo
Fuchs
Mudança Organizacional dirigida à Melhoria de Processos de 134 ... 148

Software: Um Mapeamento Sistemático
Monica Anastassiu, Gleison Santos, Flavia Santoro
Catálogo de Benefícios Relatados por Organizações que 149 ... 163

Implementaram Melhoria de Processos de Software
Diego Cruz, Gleison Santos
Dinâmica das práticas da liderança em iniciativa de melhoria de 164 ... 175

processos de software
Alessandra Zoucas, Marcello Thiry, Cristiano Almeida Cunha
Práticas para Tratamento de Fatores Críticos de Sucesso 176 ... 190

Raphael Freire, Davi Viana, Gleison Santos
A Software Measurement Pattern Language for Measurement 191 ... 205

Planning aiming at SPC
Daisy Brito, Monalessa Perini Barcellos, Gleison Santos
Estimativa de Projetos de Aplicativos Móveis: Um Mapeamento 206 ... 220

Sistemático da Literatura
Ervili Tarsila de Souza, Tayana Conte
Capacidade do Cliente na Solicitação de Requisitos Não- 221 ... 235

Funcionais
Andreia Silva, Plácido Rogério Pinheiro, Adriano Albuquerque,
Jonatas Barroso
Avaliação por experiência de usuário de ferramentas que apoiam 236 ... 250
a engenharia de requisitos no contexto de Micro e Pequenas
Empresas
Adailton Araújo, Juliano Lopes de Oliveira, Almir Silva, Bruno
Machado, Jailton Louzada, Paulo Soares
Como desenvolvedor quero utilizar user story para representar 251 ... 265
os requisitos que levam à definição do MVP e criação de
Mockups
Taynah Almeida, Ana Oran, Gleison Santos, Tayana Conte
Uma Abordagem para Caracterização dos Aspectos Não- 266 ... 280
Funcionais e Classificação do Nível de Exigência em Editais de
Licitação de Software no Setor Público Brasileiro
Bruno Barros, Reinaldo Cabral, Allan Araújo
xiv
Uma Proposta de Boas Práticas Para Aplicação de Testes 281 ... 295
Baseados em Modelos em Métodos Ágeis
Aline Zanin, Avelino Zorzo
Software Testing Processes in ISO Standards: How to Harmonize 296 ... 310
them?
Fabiano Ruy, Ricardo Falbo, Érica Souza, Monalessa Perini
Barcellos
QoS-TI: Um Framework Adaptável para Qualidade do Serviço de 311 ... 325

Suporte de TI nos Institutos Federais
Cristiano Domingues da Silva, Alexandre Vasconcelos
- CONCURSO DE TESES E DISSERTAÇÕES (DISSERTAÇÕES) –
MSECO-CERT: uma abordagem baseada em processo para apoiar 326 ... 339
a certificação de apps em Ecossistema de Software Móvel
Awdren Fontão, Arilo Dias Neto e Rodrigo Santos
Organização do Corpo de Conhecimento sobre Dívida Técnica: 340 ... 354

Tipos, Indicadores, Estratégias de Gerenciamento e Causas
Nicolli Alves, Rodrigo Spínola
Infraestrutura para um Corpo de Conhecimento em Melhoria de 355 ... 369

Processos de Software Baseado no MR-MPS-SW
Peter Lupo, Marcos Kalinowski, Ana Regina Rocha
SINIS - A Method to Select Indicators for IT Services 370 ... 384

Bianca Trinkenreich, Gleison Santos, Monalessa Perini Barcellos
- CONCURSO DE TESES E DISSERTAÇÕES (TESES) –
Medidas para Avaliação da Manutenibilidade do Modelo de 385 ... 399

Features de Linhas de Produto de Software Tradicionais e
Dinâmicas
Carla Ilane Moreira Bezerra, Rossana Andrade, José Maria
Monteiro Filho
Canopus: A Domain-Specific Language for Modeling Performance 400 ... 414

Testing
Maicon Bernardino da Silveira, Avelino Zorzo
xv
- PALESTRAS CONVIDADAS –
Qualidade de Software no Brasil 415 ... 415

Carlos Henrique Duarte
Qualidade de Software e Interação Universidade-Empresa: 416 .. 416

Impacto e Relevância
Rafael Prikladnicki
xvi
QPS - Modelo para Avaliação da Qualidade de Produtos
de Software: Resultados Iniciais
Ana Regina da Rocha1, Guilherme Horta Travassos1,
Gleison Santos2, Sheila Reinehr3
1
COPPE/UFRJ – Universidade Federal do Rio de Janeiro – Caixa Postal 68511 –
CEP 21.941-972 – Rio de Janeiro, RJ
2
Programa de Pós-Graduação em Informática - Universidade Federal do Estado do Rio
de Janeiro (UNIRIO) - Av. Pasteur, 458, Urca, CEP 22290-240 - Rio de Janeiro, RJ
3
Programa de Pós-Graduação em Informática - Pontifícia Universidade Católica do
Paraná (PUC-PR), R. Imaculada Conceição, 1155 - CEP 80215-901 – Curitiba, PR
{darocha, ght}@cos.ufrj.br, gleison.santos@uniriotec.br,
sheila.reinehr@pucpr.br
Abstract. The quality of a software product should be seen in a broader

manner and take into account four important dimensions: Software
Engineering, Service, Product Quality and Organizational. Standards and
maturity models address elements of these dimensions but none of them
consider all of them to evaluate software products in a broad and holistic way.
That leads organizations to use different models to evaluate their procedural
and organizational diversity. In this paper, we present the QPS model, which
allows the evaluation of software products quality, and the first results of its
implementation and assessments in Brazilian organizations.
Resumo. A qualidade de um produto de software deve ser vista de forma
ampla, considerando-se quatro dimensões importantes: Engenharia de
Software, Serviço, Qualidade do Produto e Organizacional. Apesar de
existirem normas e modelos que tratem elementos destas dimensões, não há
nenhum modelo que avalie produtos de software considerando estas quatro
dimensões de uma forma ampla e holística, levando as organizações a
lançarem mão de diferentes modelos para garantirem a avaliação de sua
diversidade procedimental e organizacional. Este artigo apresenta o modelo
QPS, um modelo para avaliação da qualidade de produtos de software, e os
primeiros resultados de sua implementação e avaliação em organizações
brasileiras.
1. Introdução
A qualidade de um produto de software deve ser vista de forma ampla, levando-se em
consideração as dimensões: organizacional, engenharia de software, serviço e produto.
Estas dimensões se justificam considerando, por exemplo, os seguintes cenários: (1)
Dimensão Organizacional - uma empresa com um produto no mercado precisa ter uma
documentação do produto, processos organizacionais e atributos de processo que
garantam a implementação desta dimensão e das dimensões de Engenharia de Software
e de Serviços; (2) Dimensão de Engenharia de Software - uma empresa com um
produto no mercado precisa ter processos de manutenção corretiva, evolutiva e
1
adaptativa (quando pertinente); (3) Dimensão de Serviço - uma empresa com um
produto no mercado precisa ter um serviço de atendimento ao cliente; e, (4) Dimensão
de Qualidade do Produto - um produto de software deve possuir uma descrição do
produto, uma documentação para o usuário e características de qualidade que podem
ser: (i) características essenciais a qualquer produto; (ii) características que devem estar
presentes em determinados produtos para atender às suas especificidades; e, (iii)
características de qualidade do produto em uso.
Existem, atualmente, normas e modelos para a definição e avaliação de
processos de Engenharia de Software, tais como: a norma internacional ISO/IEC 12207
[ISO/IEC, 2008a] - que define os processos do ciclo de vida de software; a série de
normas internacionais ISO/IEC 33000 [ISO/IEC, 2015] - que define níveis de
capacidade e forma de avaliá-los; o modelo de maturidade internacional CMMI-DEV
[CMMI Product Team, 2010a] - que define processos de software, níveis de maturidade,
níveis de capacidade e forma de avaliá-los; e, o modelo de maturidade nacional MR-
MPS-SW [SOFTEX, 2016] - que define processos de software, níveis de maturidade e
forma de avaliá-los.
Existem, também, normas e modelos para avaliação de processos de serviços,
tais como: a norma internacional ISO/IEC 20000 [ISO/IEC, 2011] - que define
processos de serviços; o modelo de maturidade internacional CMMI-SVC [CMMI
Product Team, 2010] - que define processos de serviços, níveis de maturidade, níveis de
capacidade e forma de avaliá-los; e, o modelo de maturidade nacional MR-MPS-SV
[SOFTEX, 2015] - que define processos de serviços, níveis de maturidade, níveis de
capacidade e forma de avaliá-los.
No que se refere à dimensão de qualidade do produto, existe a série de normas
internacionais ISO/IEC 25000 [ISO/IEC 2014].
Não existe modelo algum que avalie produtos de software, considerando as
quatro dimensões citadas, de uma forma ampla e holística, o que leva as organizações a
lançarem mão de diferentes frentes de trabalho, iniciativas e investimentos para garantir
a avaliação de sua diversidade procedimental e organizacional. O Modelo para
Avaliação da Qualidade de Produtos de Software (QPS) tem o objetivo de suprir esta
carência. Este artigo apresenta o modelo QPS e os primeiros resultados de sua
implementação e avaliação em organizações brasileiras.
Além desta seção introdutória, o artigo está organizado da seguinte forma: Seção
2 apresenta uma breve revisão da literatura; Seção 3 descreve a visão geral do modelo;
Seção 4 apresenta os resultados iniciais das avaliações piloto do QPS; por fim, a Seção
5 apresenta as considerações finais.
2. Referencial Teórico
2.1 Modelos e Normas de Processo de Software
Ao longo dos anos, desde a década de 80, diversas normas e modelos de referência têm
sido desenvolvidos para apoiar a melhoria dos processos de software nas organizações.
Dentre as normas, a que mais se destaca é a ISO/IEC 12207 [ISO/IEC, 2008a] que
descreve os processos do ciclo de vida de software, de acordo com o relacionamento
entre eles e com a responsabilidade pela execução de cada um. Estes processos estão
divididos em duas categorias: os processos relacionados ao contexto de sistema e os
2
processos relacionados especificamente ao software. Na primeira categoria se
encontram: Processo de Acordo; Processos de Capacitação de Projetos Organizacionais;
Processos de Projeto e Processos Técnicos. Na segunda categoria, por sua vez, se
encontram: Processos de Implementação de Software; Processos de Apoio de Software;
e, Processos de Reúso de Software.
O conjunto de normas da ISO/IEC que se relaciona com a avaliação destes
processos é denominado Série ISO/IEC 33000 [ISO/IEC, 2015]. Esta série de normas
definem níveis de capacidade que são utilizados na avalição dos processos que estão
definidos na ISO/IEC 12207. Basicamente a Norma define os seguintes níveis de
capacidade: (0) incompleto; (1) executado; (2) gerenciado; (3) estabelecido; (4)
previsível; e, (5) em otimização.
Ainda na década de 80 surgiu um modelo para melhoria de processos que prevê
níveis de maturidade, que podem ser compreendidos como degraus na evolução da
qualidade no desenvolvimento de software. O principal representante desta abordagem é
o CMMI-DEV (Capability Maturity Model Integration – for Development) [CMMI
Product Team, 2010]. Ele foi desenvolvido pelo SEI (Software Engineering Institute) e
agora está sob a gestão do CMMI Institute (atualmente associado à ISACA). O modelo
prevê 5 níveis de maturidade que vão desde o nível 1 (menos maduro) até o nível 5
(mais maduro). Prevê áreas de processo que podem ser agrupadas em 4 categorias:
Gerência de Projetos, Gerência de Processos, Engenharia e Apoio. Estas Áreas de
Processo são definidas e agrupadas nos níveis de maturidade [CMMI Product Team,
2010].
No Brasil, o programa iniciado pela SOFTEX em 2003, denominado MPS.BR
(Melhoria de Processo do Software Brasileiro), introduziu modelos de maturidade para
a melhoria de processos em diversas áreas, entre elas, a área de software, com o modelo
MR-MPS-SW [SOFTEX, 2016]. Este modelo de referência foi também concebido
utilizando o conceito de níveis de maturidade. Sua estrutura prevê 7 níveis evolutivos de
maturidade que têm início no Nível G (Parcialmente Gerenciado) e culminam no Nível
A (Em otimização). O modelo guarda certa compatibilidade com o modelo CMMI-
DEV, exceto pela presença de alguns processos adicionais que são provenientes da
Norma ISO/IEC 12207 (Gerência de Portfólio de Projetos, Gerência de Reutilização e
Desenvolvimento para Reutilização).
2.2 Modelos e Normas de Gerenciamento de Serviços de TI

Paralelamente às preocupações com a qualidade dos processos de software, nasceram e
se proliferaram também os modelos para o gerenciamento de serviços de TI. Nesta
linha, o mais conhecido e utilizado internacionalmente é o ITIL (Information
Technology Infrastructure Library). De acordo com a OGC (2011), o modelo provê
“um guia para os provedores de serviços para a provisão de serviços de TI de qualidade
e para os processos, funções e outras capacidades necessárias para suportá-los.”. Os
processos que o compõem estão divididos em 5 categorias: Estratégia do Serviço;
Projeto do Serviço; Transição do Serviço; Operação do Serviço; e, Melhoria Contínua
do Serviço.
Na esteira dos modelos de serviços, o SEI lançou também um modelo de
maturidade para a área de serviços: CMMI-SVC [CMMI Product Team, 2010b]. Este
modelo, originalmente baseado no SW-CMM, também foi estruturado em 5 níveis
3
evolutivos de maturidade, iniciando no Nível 1 e culminando no Nível 5. Comparado à
utilização do CMMI-DEV, este ainda é um modelo jovem e em fase de consolidação,
com um número muito menor de avaliações realizadas.
No Brasil, o programa MPS.BR também introduziu um modelo na área de
gerenciamento de serviços de TI, o modelo MR-MPS-SV [SOFTEX, 2015]. Este
modelo de referência foi também concebido utilizando o conceito de níveis de
maturidade, só que desta vez aplicado a serviços. Sua estrutura prevê 7 níveis evolutivos
de maturidade, assim como o seu antecessor da área de software (MR-MPS-SW). Seu
início também se dá no Nível G (Parcialmente Gerenciado) e culmina no Nível A (Em
otimização). O modelo guarda certa compatibilidade com o modelo CMMI-SVC, porém
com interpretações mais claras sobre alguns dos conceitos de serviços.
A Norma Internacional que trata do gerenciamento de serviços de TI é a
ISO/IEC 20.000 [ISO/IEC, 2011; 2012]. Esta Norma possui uma correlação íntima com
o modelo de referência ITIL. Seu foco é a melhoria dos processos para a área de
serviços de TI. Trata-se, na realidade, de uma família de normas, composta por diversas
partes. Na parte principal está definida a estrutura da Norma que foca grupos de
processos que estão relacionados a Entrega de Serviços, Controle, Liberação, Resolução
e Relacionamento.
2.3 Norma para a Qualidade de Produto de Software

A principal Norma Internacional que trata da Qualidade do Produto de Software é a
ISO/IEC 25000 [ISO/IEC, 2014]. A série, também conhecida como SQuaRE, possui
três modelos de qualidade: qualidade em uso, qualidade de produto e qualidade de
dados. Cada um destes modelos é composto por características e sub-características de
qualidade que podem ser usadas em todo ou em parte, e acordo com a visão de cada
stakeholder. O modelo de Qualidade em Uso possui 5 características: Efetividade,
Eficiência, Satisfação, Liberdade de Risco e Cobertura de Contexto. O modelo de
qualidade de produto possui 8 características: Adequação Funcional, Eficiência de
Desempenho, Compatibilidade, Usabilidade, Confiabilidade, Segurança,
Manutenibilidade e Portabilidade. O modelo de Qualidade de Dados possui 15
características que podem ser encontradas em ISO/IEC 25012 [ISO/IEC, 2008b].
3. Visão Geral do Modelo QPS

Tendo em vista a amplitude da avaliação e a necessidade de se manter em conformidade
com as perspectivas atuais da qualidade, a dimensão de Engenharia de Software e a
Dimensão Organizacional têm por base as Normas Internacionais ISO/IEC 12207
[ISO/IEC, 2008a] e ISO/IEC 33020 [ISO/IEC, 2015]. A dimensão de Serviços tem por
base as Normas Internacionais ISO/IEC 20000 [ISO/IEC, 2011] e ISO/IEC 33000
[ISO/IEC, 2015]. A dimensão de características de qualidade do produto tem por base a
série de Normas Internacionais ISO/IEC 25000 [ISO/IEC 2014]. O processo de
avaliação está baseado nas séries de Normas Internacionais ISO/IEC 33000 [ISO/IEC,
2015] e ISO/IEC 25000 [ISO/IEC 2014]. A Figura 1 apresenta as dimensões do modelo
QPS.
4
ISO/IEC 12207 e ISO/IEC 33020
Dimensão
Organizacional
ISO/IEC
ISO/IEC 25010
20000-1 Modelo de ISO/IEC DIS
Referência 25022.2
ISO/IEC Dimensão Dimensão
de Serviços
para Avaliação de Produto
20000-4 de Produto de ISO/IEC DIS
Software 25023.2
ISO/IEC
33000 ISO/IEC
21051
Dimensão
de
Engenharia
de Software
ISO/IEC 12207 e ISO/IEC 33020
Fig ura 1 - Vis ão do Mo de lo QPS para Avaliaç ão de Pro duto s de S o ftware e s ua

re laç ão c o m No rmas Inte rnac io nais .
O modelo QPS (QPS, 2016) aplica-se a qualquer tipo de produto de software e

tem por base os princípios de avaliação contínua, apresentando os resultados em três
níveis de atendimento da qualidade: Bronze, Prata e Ouro. Os níveis são acumulativos e,
desta forma, o nível Prata inclui todos os requisitos do nível Bronze e o nível Ouro
todos os requisitos dos níveis Bronze e Prata.
Durante uma avaliação do modelo QPS são consideradas, de forma diferenciada,
duas situações:
1. Avaliação de um produto já disponível e em uso pelo mercado.
2. Avaliação de um produto no seu lançamento, visando a que seja lançado com
uma avaliação.
As subseções a seguir descrevem as duas formas de avaliação do modelo QPS
além do seu processo de avaliação.
3.1. Avaliação de um produto já disponível e em uso pelo mercado

A avaliação de um produto já disponível e em uso no mercado considera:
i. Na Dimensão Organizacional, a documentação existente do produto e a
definição e execução de processos relacionados à gestão do produto;
5
ii. Na Dimensão de Engenharia de Software, os processos definidos e executados
para manutenções corretivas, evolutivas e adaptativas (customizações para
diferentes clientes, se pertinente)
iii. Na Dimensão de Serviços, os processos definidos e executados para o
fornecimento do produto e o atendimento ao cliente;
iv. Na Dimensão de Qualidade do Produto, a descrição do produto, a
documentação do usuário, as características de qualidade gerais e específicas
pertinentes ao produto e a qualidade em uso observada pelos usuários.
A avaliação de um produto já disponível no mercado avalia, portanto, a
qualidade do produto e como a empresa fornecedora do produto faz a gestão do produto
e vem realizando as manutenções, o fornecimento do produto e o atendimento ao
cliente. Esta avaliação tem validade de três anos.
Na dimensão Organizacional são considerados, na avaliação, os documentos
relativos a requisitos do produto, rastreabilidade dos requisitos, objetivos de negócio
para o produto, descrição da estrutura para fornecimento do produto e atendimento ao
cliente, riscos identificados para o produto, melhorias identificadas para o produto,
arquitetura do produto e casos de teste para o produto. São também avaliadas: a
descrição e implementação dos processos aquisição (quando pertinente), a gerência de
configuração do produto e a medição. Para produtos já disponíveis no mercado, é
possível avaliar a execução dos processos, portanto, são avaliados atributos de processo
de acordo com a ISO/IEC 33.020 [ISO/IEC, 2015]. O Quadro 1 mostra as exigências da
dimensão organizacional para cada um dos níveis do modelo QPS.
Quadro 1 – Re quis ito s da dime ns ão Org anizac io nal do Mo de lo QPS .
Nível
DIMENSÃO ORGANIZACIONAL
Bronze Prata Ouro
Requisitos do Produto X X X
Rastreabilidade Requisitos X Requisitos X X X
Rastreabilidade Requisitos X Código X X X
Rastreabilidade Requisitos X Casos de Teste X X
Objetivos de negócio para o produto X X X
Estrutura para fornecimento do produto e atendimento ao cliente X X X
Riscos do produto X X
Oportunidades de melhoria identificadas para o produto X X X
Arquitetura do Produto X X
Casos de Teste do Produto X X
Definição e execução do processo Aquisição (se pertinente) X X X
Definição e execução do processo Gerência de Configuração do X X
Produto
Definição e execução do processo Medição X
Atributo de processo 1.1: O processo é executado X X X
Atributo de processo 2.1: A execução do processo é gerenciada X X X
Atributo de processo 2.2: Os produtos de trabalho do processo são X X
gerenciados
Atributo de processo 3.1: O processo é definido X
Atributo de processo 3.2: O processo está implementado X
Na dimensão Engenharia de Software são avaliados os processos definidos e
executados para manutenções corretivas, evolutivas e adaptativas (customizações para
diferentes clientes, se pertinente). Nestes processos devem estar integrados os processos
6
Gerência de Projetos, Desenvolvimento e Gerência de Requisitos do Projeto,
Arquitetura e Projeto, Construção, Validação, Integração do Produto e Liberação do
Produto. O Quadro 2 mostra as exigências da dimensão Engenharia de Software para
cada um dos níveis do modelo QPS.
Quadro 2 – Re quis ito s da dime ns ão Eng e nharia de S o ftware do Mo de lo QPS .
DIMENSÃO ENGENHARIA DE SOFTWARE Nível
Definição e execução do processo de manutenção que atenda
Bronze Prata Ouro
aos processos:
Gerência de Projetos X X X
Desenvolvimento e Gerência de Requisitos do Projeto X X X
Arquitetura e Projeto X X
Construção X X
Validação X X
Integração do Produto X X
Liberação do Produto X X X
gerenciados
Na dimensão de Serviços são avaliados os processos definidos e executados
para Planejamento e Monitoração do Serviço, Gerência de Incidentes e de Solicitações
de Serviço, Gerência do Nível de Serviço, Gerência de Segurança da Informação (se
pertinente), Gerência de Problemas, Orçamento e Contabilização do Serviço, Gerência
da Capacidade, Gerência de Mudanças, Gerência de Continuidade e Disponibilidade e
Relato de serviços (se pertinente). O Quadro 3 mostra as exigências da dimensão de
serviços para cada um dos níveis do modelo QPS.
Quadro 3 – Re quis ito s da dime ns ão de S e rviç o s do Mo de lo QPS .
DIMENSÃO DE SERVIÇOS Nível
Definição e execução de processos que atendam: Bronze Prata Ouro
Planejamento e Monitoração do Serviço X X X
Gerência de Incidentes e de Solicitações de Serviço X X X
Gerência do Nível de Serviço X X X
Gerência de Segurança da Informação (se pertinente) X X X
Gerência de Problemas X X
Orçamento e Contabilização do Serviço X X
Gerência da Capacidade X
Gerência de Mudanças X
Gerência de Continuidade e Disponibilidade X
Relato de serviços (se pertinente)
gerenciados
Na dimensão de Qualidade do Produto são considerados, na avaliação, os
documentos relativos à descrição do produto e à documentação do usuário. O produto é
também avaliado com relação às seguintes características de qualidade: consistência
7
operacional, clareza das mensagens, existência de undo, aparência da interface, controle
de acesso, apoio da documentação para análise, integridade dos dados, apoio da
documentação para testes e disponibilidade de casos de teste.
No nível Prata deve ser evidenciado que foi realizada uma pesquisa de satisfação
dos usuários do produto quanto ao grau de atendimento das características de Qualidade
em Uso. Deve ser, portanto, evidenciado:
• Que foi realizada a pesquisa de opinião com as empresas usuárias do produto no
período máximo de 12 meses antes da data da avaliação;
• Os resultados da pesquisa;
• Que foi realizada a análise dos resultados e foram tomadas decisões para
melhoria do produto onde pertinente.
No nível Ouro deve ser evidenciado que foram identificados requisitos de
qualidade do produto (específicos de sua natureza), que existem procedimentos para
avaliação do grau de atendimento do produto a estes requisitos e que a avaliação foi
realizada. Estes requisitos devem ser identificados considerando as características
específicas do produto e as necessidades dos diferentes tipos de usuários (por exemplo,
usuários finais, usuários indiretos, mantenedores, responsáveis por adicionar conteúdo
etc.). Exemplos de características específicas podem ser vistas em Mota e Oliveira
(2017) e Silveira e Souza (2017).
O Quadro 4 mostra as exigências da dimensão de qualidade do produto para
cada um dos níveis do Modelo QPS.
Quadro 4 – Re quis ito s da dime ns ão de Qualidade do Pro duto do Mo de lo QPS .
Nível
DIMENSÃO DE QUALIDADE DO PRODUTO
Bronze Prata Ouro
Descrição do Produto X X X
Documentação do Usuário X X X
Medida: Consistência Operacional X X X
Medida: Clareza das Mensagens X X X
Medida: Existência de undo X X X
Medida: Aparência da Interface X X X
Medida: Controle de Acesso X X X
Medida: Apoio da Documentação para Análise X X X
Medida: Integridade dos Dados X X
Medida: Apoio da Documentação para Testes X X
Medida: Disponibilidade de Casos de Teste X X
Avaliação da qualidade em uso X X
Definição e avaliação de requisitos de qualidade específicos do produto X
3.2. Avaliação de um produto no seu lançamento

A avaliação de um produto no seu lançamento no mercado considera os mesmos
documentos e processos avaliados para produtos já disponíveis no mercado. Entretanto,
não se considera a implementação dos processos na organização, por não ser pertinente
nesta situação. O que se avalia, neste caso, é a qualidade do produto e se a empresa
fornecedora do produto está apta a realizar manutenções, atendimento ao cliente e
gestão do produto de forma adequada. Não é, também, avaliada a qualidade em uso por
não ser pertinente a um produto no momento de seu lançamento.
8
Esta avaliação pode ser realizada antes do lançamento do produto no mercado ou
no máximo até 3 meses após o lançamento. Tem validade de um ano, contado a partir da
data prevista para o lançamento do produto e informada na data da avaliação. A
validade de um ano é motivada por não se considerar, neste caso, a implementação dos
processos, apenas a definição deles. Após esta data o produto deve ter nova avaliação
como produto disponível e em uso pelo mercado, evidenciando de fato a implementação
dos processos.
3.3. Processo de Avaliação

A avaliação de um produto, segundo o Modelo QPS, é aderente à ISO/IEC 33.000. É
uma avaliação contínua com resultado em níveis (Ouro, Prata e Bronze).
A avaliação tem início com um Diagnóstico Inicial onde se avalia o produto de
forma completa considerando os requisitos do nível Ouro, ou seja, o nível máximo. Ao
final do diagnóstico inicial e considerando seus resultados, a empresa responsável pelo
produto escolhe em que nível deseja realizar a avaliação final. Acredita-se que esta
abordagem, considerando de início todas as exigências do modelo no Nível Ouro, é
adequada porque o diagnóstico inicial fornece um relatório abrangente e de grande valor
para a empresa fornecedora do produto, capaz de orientar a melhoria contínua do
produto e dos processos.
Participam da equipe de avaliação ao menos dois avaliadores, sendo que um
deles desempenha o papel de líder. Não são previstos avaliadores da própria
organização, mas a participação de membros da organização é incentivada no
diagnóstico inicial.
A avaliação é realizada por uma Entidade Avaliadora credenciada pela Fundação
COPPETEC (unidade da COPPE/UFRJ responsável pela interface com empresas). Em
uma avaliação, a Entidade Avaliadora e toda a equipe de avaliação devem ser
totalmente independentes da organização e do produto avaliado, fornecendo um serviço
totalmente independente de 3ª parte. Todas as avaliações QPS são auditadas pelo
Comitê Diretivo do Modelo QPS que, após aprovação do resultado, emite declaração da
avaliação para o produto com o nível obtido.
O modelo QPS tem prevista, em sua estrutura, a existência de Entidades
Avaliadoras credenciadas, que devem contar, pelo menos, com uma equipe de dois
avaliadores sendo que um deles deve ser avaliador líder. De forma semelhante ao
modelo CMMI não estão previstas Entidades Implementadoras e nem implementadores
credenciados.
4. Resultados Iniciais da Implantação e Avaliação do Modelo QPS

Até o momento foram realizadas três avaliações utilizando o Modelo QPS, sendo que
dois produtos já estavam disponíveis no mercado e um estava sendo avaliado no seu
lançamento. As três empresas avaliadas possuíam características bem diferentes e foram
bem-sucedidas em suas avaliações.
4.1. WTS Corporate

Trata-se de um software para gestão de viagens da empresa Monteiro e Gutierrez
Sistemas Ltda., do Rio de Janeiro. O produto já se encontra em uso no mercado e foi
avaliado com sucesso para o Nível Ouro.
9
A empresa responsável pelo produto WTS Corporate já tinha processos
modelados e já havia obtido a certificação ISO 9000. Esta empresa contou com uma
breve consultoria antes da avaliação QPS em um total de aproximadamente 20 horas.
Esta consultoria realizou um gap analysis e orientou a empresa nos ajustes necessários
para a realização do Diagnóstico Inicial (1ª fase da avaliação QPS). O consultor
participou do diagnóstico inicial, apoiando a empresa na resposta aos questionamentos
dos avaliadores. Entre o Diagnóstico Inicial e a Avaliação, ele também apoiou a
empresa na resolução dos ajustes. O Diagnóstico Inicial foi realizado em setembro de
2016 com duração de 2 dias e a avaliação final um mês após com duração de um dia e
meio. A equipe de avaliação foi formada por um avaliador líder e dois avaliadores.
4.2. Pirâmide
Trata-se de um software do tipo ERP da empresa PCC Engenharia de Sistemas Ltda.
(PROCENGE), de Recife. O produto já se encontra em uso no mercado e foi avaliado
com sucesso para o Nível Ouro.
A empresa responsável pelo produto Pirâmide é uma empresa com tradição em
melhoria contínua de seus processos. Realizou ao longo dos anos avaliações MPS-SW
níveis G, F e C, além de uma avaliação CMMI-DEV Nível 2. Entretanto, nunca havia
implementado modelo de serviços, nem CMMI-SVC nem MPS-SV. Neste caso, a
equipe de avaliação realizou o Diagnóstico Inicial imediatamente após a conclusão de
uma avaliação oficial MPS-SW onde a empresa renovou o nível C. Sendo assim, a
dimensão de Engenharia de Software e parte da Dimensão Organizacional não foram
consideradas na avaliação QPS, por já terem sido avaliadas na avaliação MPS-SW pela
mesma equipe. Foi considerado, portanto, neste caso, a avaliação QPS como uma
avaliação complementar à avaliação MPS-SW e foram avaliadas apenas as dimensões
de Serviços e Qualidade de Produto bem como aspectos da dimensão organizacional
não considerados pelo MR-MPS-SW. Esta empresa não teve apoio de consultoria por
ter um grupo de processos experiente. O Diagnóstico Inicial foi realizado em dezembro
2016 com duração de 1 dia e a avaliação final em março de 2017 com duração de um
dia e meio. A equipe de avaliação foi formada por um avaliador líder e dois avaliadores.
4.3. RSI
Trata-se de uma ferramenta de gestão de serviços institucionais da Fundação Oswaldo
Cruz (Fiocruz), do Rio de Janeiro, que estava em fase de lançamento para o mercado.
Neste caso, após a avaliação de Diagnóstico Inicial a Fiocruz optou por realizar a
avaliação final para o nível Bronze e foi bem-sucedida.
A terceira avaliação, realizada na Fiocruz para o produto RSI, foi uma avaliação
mais curta por ser um produto novo e avaliado no momento de seu lançamento. Neste
caso, se avalia a documentação existente sobre o produto, a definição dos processos das
dimensões Organizacional, Engenharia de Software e Serviços e as características de
Qualidade do Produto. Após o Diagnóstico Inicial, a empresa decidiu realizar os ajustes
necessários apenas para o nível Bronze, que foi o nível considerado para a avaliação
final. Neste caso, também, não houve apoio de consultoria. A Fiocruz já tinha processos
definidos e modelados e profissionais com conhecimento de modelagem de processos.
O Diagnóstico Inicial foi realizado em novembro de 2016 com duração de 2 dias e a
avaliação final em abril 2017 com duração de um dia e meio. A equipe de avaliação foi
10
formada no diagnóstico inicial por um avaliador líder e dois avaliadores e na avaliação
final por um avaliador líder e um avaliador.
4.4. Feedback após as avaliações

Após a finalização das avaliações, foi solicitado às empresas e aos
implementadores e avaliadores do QPS que fornecessem um feedback sobre o modelo e
as avaliações realizadas, por meio de um questionário. A seguir, estão listados alguns
dos feedbacks recebidos.
▪ “O método de avaliação foi muito bom, com melhorias sensíveis com
relação a outros modelos”.
▪ “Percebemos uma preocupação muito forte de que o modelo seja flexível
para todos os tipos de empresa que trabalham com produto de software.
Essa capacidade de se ajustar aos diferentes modelos de negócio é muito
importante para que as empresas consigam extrair o máximo de
benefícios e resultados através do modelo”.
▪ “Recebemos com muito entusiasmo esse modelo, que agrega todos os
processos que fazem diferença para nós que trabalhamos com produto”.
▪ “Método de avaliação excelente”.
Dois implementadores do modelo QPS em empresas com produtos já
avaliados observaram:
▪ "O modelo QPS pode ser visto como um guia para apoiar definição ou
melhoria na execução das atividades relacionadas à elaboração e
manutenção do produto de software e serviço. Fornece subsídios para
apoiar a padronização de atividades, não com sentido “burocrático”,
mas em facilitar a sua execução. Relativamente fácil de ser
implementado, pois contempla e foca nas atividades essenciais à
realização e manutenção do produto e do serviço, incluindo aspectos da
qualidade e usabilidade do produto. Em função disto, melhora o
desempenho do time, facilita a comunicação entre seus componentes e
fornece subsídios para a otimização e melhoria dos processos definidos.
Pode ser implementado em organização de software, de qualquer
tamanho (pequena, média ou grande), que tenha um produto de software
disponibilizado ou que venha a ser disponibilizado para clientes. Sendo
implementado adequadamente na organização de software, transmite
confiança ao implementador na submissão ao Método de Avaliação. As
informações contidas no relatório do resultado da avaliação inicial
foram de grande valia para conduzir as correções e adequações aos
requisitos do modelo”.
▪ “A Avaliação do QPS é singular em relação às demais avaliações de
modelos e normas de qualidade disseminadas na indústria. Apesar deste
modelo considerar normas como a Série ISO/IEC 33000 em seu
processo de avaliação, o fato do QPS possuir uma arquitetura focada em
quatro dimensões, amplia-se a percepção do avaliador em relação ao
software avaliado. Além disso, seu diferencial destaca-se pelas
dimensões focadas na qualidade do produto e não na qualidade do
processo. Com isso, as dimensões Organizacional, Engenharia de
11
Software, Serviços e Qualidade do Produto descrevem os processos
relevantes para a avaliação da qualidade de um produto de software”.
A seguir, apresenta-se as observações de avaliadores que participaram das
avaliações piloto do QPS:
▪ “Na avaliação QPS que participei a empresa, entre o diagnóstico inicial
e a avaliação final, teve uma melhora enorme em seus processos, o que
demostra a assertividade do modelo e do método de avaliação. Achei
bom para a empresa ter uma avaliação completa para depois pensar em
que nível se adequa”.
▪ “Minha percepção foi de que a implementação do modelo em empresas
que já tem um produto no mercado é bastante simples e rápida. Essas
empresas já realizam praticamente todas as atividades previstas no
modelo no que se refere à manutenção do produto e ao serviço de
atendimento ao cliente.
▪ Empresas que estejam lançando um produto no mercado pela primeira
vez, por não ter experiência podem não ter previsto todos os processos
necessários para manutenção do produto e atendimento ao cliente. Neste
caso, torna-se necessário um apoio de consultoria na definição de
processos. Entretanto, pode estar aí o maior benefício e um elemento
diferencial com relação a produtos concorrentes.
▪ Um aspecto bastante valorizado pelas empresas que tiveram seus
produtos avaliados foi o fato de no diagnóstico inicial se fornecer um
relatório com todas as questões que precisam ser ajustadas
considerando todos os níveis do modelo (Ouro, Prata e Bronze). Isto é
possível pela avaliação QPS ser uma avaliação contínua com resultado
em estágios, o que é considerado importante por fornecer um caminho
consistente para a melhoria do produto”.
▪ “A empresa, mesmo sem acompanhamento de consultores especializados
no modelo QPS, conseguiu compreender e apresentar todas as
evidências sem dificuldades. Embora o QPS tenha foco no produto e
possua dimensões que o diferenciam dos demais modelos de qualidade
com foco em processo, a experiência da equipe da empresa com outros
modelos da qualidade auxiliou no entendimento do modelo.
▪ O feedback que a avaliação QPS é capaz de prover pode contribuir com
a reorientação ou confirmação da estratégia geral da empresa, visto que
a perspectiva do cliente também é considerada na avaliação.
▪ O QPS não dissocia a qualidade do produto e a forma como o produto é
entregue e percebido pelo cliente. Esta conexão estimula a organização
a desenvolver uma visão holística com alinhamento da evolução do
produto e serviços associados aos objetivos estratégicos da organização.
▪ Sob o ponto de vista do avaliador, é necessário quebrar o paradigma dos
modelos de qualidade com foco em processos. Nestes modelos cada
processo é avaliado de forma isolada, com foco nos seus resultados
esperados. No QPS as dimensões se complementam e contribuem para o
desenvolvimento do negócio como um todo, com foco no produto“.
▪ “A dimensão Organizacional proporciona um enfoque no produto que
nem sempre encontramos quando as empresas implantam mais de um
12
modelo. Pude perceber um feedback positivo deste enfoque e acredito
que seja de suma importância para empresas de produto. O modelo está
mais leve em alguns aspectos de engenharia de software, o que o torna
adequado para manutenções de produto, onde o processo precisa ser
ágil e leve. A dimensão de Qualidade do Produto possui potencial para
evolução e acredito que traz uma atenção especial à qualidade que é
muito bem recebida pelas empresas e pode auxiliar no que elas podem
buscar para melhorar a qualidade do seu produto. De forma geral, pude
notar uma boa recepção do modelo e confio que trará benefícios para as
empresas de produto ao orientar seus programas de melhoria”.
5. Considerações Finais
Este artigo apresentou o modelo QPS para avaliação da qualidade de produtos de
software e o resultado de três avaliações já realizadas. Estas três avaliações foram
realizadas como avaliações piloto com o objetivo de avaliar e realizar melhorias no
modelo QPS e no método de avaliação.
O feedback recebido das empresas avaliadas e dos implementadores e
avaliadores do modelo foi bastante positivo. Dentre as observações pode-se sumarizar:
▪ O modelo foi considerado fácil de ser implementado, influenciou na
melhoria dos processos da organização e o diagnóstico inicial foi bem
visto pelas organizações avaliadas. Além disso, a representação contínua
do modelo foi considerada adequada.
▪ A experiência em outros modelos auxilia no entendimento do QPS.
▪ Em relação à manutenção de produtos, foi percebido que o modelo é
aderente às atividades já realizadas por organizações de manutenção e é
adequado para este tipo de organização. Além disso, foi destacado que o
fato de o modelo prever processos de manutenção e atendimento ao
cliente pode representar um diferencial para as organizações.
▪ O modelo foi considerado flexível para ser utilizado por diferentes
empresas que desenvolvem produtos de software e isso possibilita às
organizações extrair mais benefícios e resultados de sua implementação.
▪ O modelo estimula o desenvolvimento de uma visão holística com
alinhamento da evolução do produto e serviços associados aos objetivos
estratégicos da organização, além disso, considerar a perspectiva do
cliente na avaliação pode contribuir para a definição da estratégia geral
da empresa.
▪ Foi reportado que as quatro dimensões do QPS são um diferencial do
modelo, por focarem na qualidade do produto e não apenas do processo.
Também foi destacado que a forma como as dimensões se relacionam
contribui para o desenvolvimento do negócio, com foco no produto.
Além disso, foi reforçado que a dimensão Organizacional proporciona
um enfoque no produto que não há em outros modelos e que a dimensão
de Qualidade de Produto pode auxiliar na busca da melhoria da qualidade
do produto pelas organizações.
As três avaliações, realizadas como avaliações piloto, tinham como um de seus
objetivos evidenciar a necessidade de realizar melhorias no Modelo QPS e no processo
13
e método de avaliação. No momento em que as três avaliações foram realizadas o
modelo QPS já estava totalmente definido e o texto descrevendo o modelo foi entregue
às empresas. Entretanto, foi sentida a necessidade de se ter uma versão comentada do
modelo com explicação dos resultados esperados. O processo de avaliação se mostrou
totalmente adequado e não foram apontadas necessidades de ajustes. Para o método de
avaliação foram apontadas questões relacionadas à caracterização dos resultados na
avaliação final. Por ser uma avaliação de produto foi considerado mais importante
caracterizar a situação final do produto, sem valorizar o estágio observado durante o
diagnóstico inicial.
Neste momento outras empresas estão se preparando para avaliação de seus
produtos no modelo QPS. Foram, também, realizados cursos para formação de
implementadores e avaliadores do modelo QPS no Rio de Janeiro, Maceió e Recife que
credenciaram avaliadores situados em diversos estados do país. Novos cursos estão
planejados para serem realizados ainda em 2017.
O Modelo QPS compõe o conjunto de tecnologias de software oferecidas pelo
DELFOS (Observatório da Engenharia do Software Contemporâneo) da COPPE/UFRJ.
O modelo QPS para avaliação de produtos de software é o primeiro modelo da família
de modelos de qualidade DELFOS. Outros modelos estão sendo definidos para atender
a outras situações específicas.
Agradecimentos
Os autores agradecem a todos que colaboraram na definição e aprimoramento do
modelo QPS: Cristina Cerdeiral (UNIRIO), Tayana Conte (UFAM), Reinaldo Cabral
(UFAL), Bruno Santana (PROCENGE), Eduardo Cavalcante (PROCENGE), Rafael
Figueiredo (Monteiro e Gutierrez Sistemas), Andre Campos (Fiocruz), Pedro Erthal
Soares (Fiocruz), Luiz Sergio Plácido da Silva (Softex Recife), Benno Eduardo Albert
(Petrobras), Carlos Alberto Simões (Makalu Consultoria Empresarial), Denize Pimenta
(UNIRIO), João Alexandre Sartorelli (Petrobras), Peter Peret Lupo (Implementum),
Elaine Duarte Nunes (Implementum) e Rachel Vital (COPPE/UFRJ).
Referências
CMMI Product Team (2010a). CMMI for Development - Version 1.3, Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania,
Technical Report CMU/SEI-2010-TR-033.
CMMI Product Team (2010b). CMMI for Services - Version 1.3, Software Engineering
Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania, Technical Report
CMU/SEI-2010-TR-034.
ISO/IEC (2008a). ISO/IEC 12207 Systems and software engineering– Software life
cycle processes, Geneve: ISO.
ISO/IEC (2008b). ISO/IEC 25012:2008 – Software engineering — Software Product
Quality Requirements and Evaluation (SQuaRE) — Data Quality Model. Geneve:
ISO, 2008.
ISO/IEC (2011). ISO/IEC 20000-1:2011 Information Technology – Service
Management. Part 1: Service Management Systems Requirements, Geneve: ISO.
14
ISO/IEC (2012). ISO/IEC 20000-2:2012 Information Technology – Service
Management. Part 2: Guidance on the application of service management
systems, Geneve: ISO.
ISO/IEC (2014). ISO/IEC 25000:2014 – Systems and software engineering — Systems
and software Quality Requirements and Evaluation (SQuaRE) — Guide to
SQuaRE. Geneve: ISO, 2014.
ISO/IEC (2015). ISO/IEC 33020 – Information Technology – Process Assessment –
Process Measurement Framework for Assessment of Process Capability. Geneve:
ISO, 2015.
Mota, R., Oliveira, K,M. Uma proposta para apoio à identificação de características de
qualidade de produtos de software no contexto do modelo QPS, II Workshop de
Qualidade de Produto de Software, 2017.
OGC (2011). “ITIL Service Operations” The Stationary Office – TSO. London, UK.
Silveira, B.C.A., Souza, T. S. Atributos e Medidas de Acessibilidade de Software:
Reflexões sobre a ISO/IEC 25000, II Workshop de Qualidade de Produto de
Software, 2017.
SOFTEX (2015) MPS.BR – Guia Geral MPS de Serviços:2015, outubro 2015.
Disponível em www.softex.br/mpsbr, consultado em 29/05/2017.
SOFTEX (2016) MPS.BR – Guia Geral MPS de Software:2016, janeiro 2016.
Disponível em www.softex.br/mpsbr, consultado em 29/05/2017.
QPS (2016) Modelo de Referência para Avaliação de Produtos de Software, versão 1.0,
outubro 2016.
15
Análise da Relação entre Chamados e Modificações no
Código-Fonte de um Sistema de Acompanhamento de Obras
Luciano Antônio Cordeiro de Sousa, Bruno Santana da Silva
Instituto Metrópole Digital

Universidade Federal do Rio Grande do Norte
Av. Senador Salgado Filho, 3000 – 59078-970 – Natal – RN – Brasil
lacsousa@gmail.com, bruno@imd.ufrn.br
Abstract. Some systems have a long maintenance period, being modified for
functionality adequacy and bugs fix. After some time, it is dificult to answer:
Did bugs arise during system development or maintenance? What modification
in the system could have caused a certain bug? Questions like these had
already some answers in academy, but not always professionals understand
how these questions may affect their work in industry. This paper presents a
case study about relations between bug reports and modifications in source-
code over 2 years of a construction monitoring system of an energy company.
Understanding these relations contributes to professionals’ awareness about
opportunities for improvement in their practice during development and
maintenance process of systems.
Resumo. Alguns sistemas passam por um longo período de manutenção,

sendo modificados para adequação de funcionalidades e correção de falhas.
Depois de algum tempo, pode ser difícil responder: As falhas surgiram
durante o desenvolvimento ou durante a manutenção do sistema? Que
modificação no sistema poderia ter causado determinada falha? Perguntas
assim já encontram respostas na academia, mas nem sempre profissionais
compreendem com elas podem afetar seu trabalho na indústria. Este artigo
apresenta um estudo de caso sobre relações entre chamados e modificações no
código-fonte ao longo de 2 anos de um sistema de controle de obras de uma
empresa de energia. A compreensão dessas relações contribui para
conscientização de profissionais sobre oportunidades de melhoria na sua
prática durante o processo de desenvolvimento e manutenção de sistemas.
1. Introdução
Muitos fatores influenciam a qualidade de um sistema, como processo, tecnologias,
condições de desenvolvimento (custos, prazos, etc.) e as pessoas envolvidas [Bourque e
Fairley, 2014]. Depois que um sistema é implantado, ele entra na fase de manutenção
[Grubb e Takang, 2003] onde ocorrem correções de falhas, bem como inclusões,
remoções ou modificações de funcionalidades. A manutenção de alguns sistemas pode
durar por anos. Nesse período, as modificações no código podem afetar a qualidade do
sistema, positiva ou negativamente.
16
Apesar de a academia considerar fundamental manter uma preocupação com a
qualidade durante todo desenvolvimento e manutenção do sistema [Bourque e Fairley,
2014], alguns profissionais na indústria ainda não consideram isso fundamental e
negligenciam práticas que garantam a qualidade, como testes [Craig e Jaskiel, 2002;
Delamaro et al., 2007], por exemplo. Não é raro encontrar profissionais que tratam
testes de software com pouco cuidado, argumentando ser assunto apenas acadêmico ou
não condizente com a agilidade do projeto. Esses profissionais ainda desconhecem os
benefícios de realizar testes adequadamente, e os malefícios de ignorá-los, durante sua
prática profissional. A compreensão do que acontece em casos reais poderia contribuir
para uma conscientização desses profissionais.
Este trabalho apresenta os resultados de uma pesquisa exploratória [White e
Roth, 2009] que realizou um estudo de caso [Stake, 1995] sobre o Sistema de
Acompanhamento de Obras (SAO) para identificar relações entre chamados de correção
e modificações no código-fonte, no período de dezembro de 2012 a março de 2015.
Essas relações (ou ausência delas) contribuem para compreender algumas consequências
de decisões tomadas e identificar oportunidades de melhorias no processo de
desenvolvimento e manutenção do sistema de informação analisado.
Uma empresa de energia presente em vários estados no Brasil desenvolveu o
SAO para auxiliar a gestão de informações sobre suas obras de engenharia. Quando
algum problema for encontrado, ela deve tomar ações corretivas para dar andamento às
obras; evitando atrasos, retrabalho e desperdícios desnecessários. O SAO foi implantado
com grande expectativa. Logo no início, os usuários foram expostos a muitas falhas no
sistema, algumas em funcionalidades fundamentais para o negócio. As dificuldades
foram tão significativas que eles cogitaram abandonar o uso do sistema. A reputação da
equipe de TI também foi afetada negativamente, pois deixaram a impressão de que o
investimento na construção do SAO não resultou em um produto relevante.
2. Estudo de Caso
O estudo de caso foi realizado em quatro etapas sequenciais que investigaram o SAO no
período de dezembro de 2012 a março de 2015 [Sousa, 2016]. Na primeira etapa,
investigamos funcionalidades e aspectos técnicos do SAO para definir um contexto de
análise. Na segunda, analisamos o histórico de ocorrência dos chamados de correção e o
histórico de criação de testes automatizados (código-fonte de teste). Na terceira,
investigamos a influência da ocorrência dos chamados sobre a criação dos testes
automatizados, e vice-versa. Até este ponto, foi possível identificar oportunidades de
melhoria no processo de desenvolvimento do SAO, mas não explicar por que tantas
falhas chegaram os usuários. Este artigo apresenta a quarta etapa deste estudo de caso,
que aprofundou a investigação analisando as modificações no código-fonte do sistema.
3. Objetivo
Poucas macrofuncionalidades foram referenciadas de forma recorrente em vários
chamados. As macrofuncionalidades "Manter RDF", "Manter QCO" e "Gerar RDO"
concentraram o maior número de chamados (61% do total) no período. O objetivo da
quarta etapa do estudo foi identificar oportunidades de melhoria no processo de
desenvolvimento e manutenção do SÃO através da análise das relações entre chamados
17
de correção e modificações no código-fonte para estas três funcionalidades: Quais
problemas relatados nos chamados podem ter surgido durante o desenvolvimento
do SAO? Quais podem ter surgido durante sua manutenção? Se um chamado puder
ser relacionado a modificações no código-fonte realizadas durante a manutenção, a falha
relatada pode ter origem na correção de outras falhas ou na evolução das
macrofuncionalidades. Por outro lado, se não houverem modificações no código-fonte
relacionadas com um chamado durante a manutenção, provavelmente a falha nele
relatada teve origem ainda durante o desenvolvimento.
4. Metodologia
A identificação das macrofuncionalidades foi realizada com a leitura do documento de
visão e de especificação de requisitos do SAO. Elas puderam ser detalhadas em
funcionalidades mais específicas para facilitar a identificação das relações entre
chamados e modificações no código-fonte (Tabela 1).
Tabela 1. Detalhamento das macrofuncionalidades com mais chamados.
Gerar Relatório
Manter RDF Manter QCO
Detalhado do RDO
Incluir RDF, Copiar RDF, Incluir QCO, Consultar QCO, Comentar Gerar relatório
Consultar RDF, Alterar RDF, QCO, Validar QCO, Alterar QCO,
Excluir RDF, Concluir RDF, Excluir QCO, Responder QCO, Avaliar
Reabrir RDF e Buscar RDF Resposta do QCO e Buscar QCO
Os chamados coletados na segunda etapa do estudo de caso foram o ponto de

partida nesta quarta etapa. Dos chamados que apontam para correções no SAO, apenas
59 estão relacionados com as três macrofuncionalidades de interesse. Dois destes
chamados foram desconsiderados por se tratarem de problemas de conexão e problemas
de layout, difíceis de relacionar com modificações no código-fonte. Deste modo, nesta
etapa consideramos 57 chamados, cada um com identificação, data, descrição do
problema feita pelo usuário e observações do desenvolvedor sobre sua resolução. Com
base nesses dados originais dos chamados, estruturamos manualmente outros dados que
permitem relacionar o chamado com mudanças no código-fonte através das
funcionalidades. Para cada chamado definimos:
▪ parte_sistema: indica a parte do sistema que sofreu alteração com o atendimento
do chamado, por exemplo: código-fonte, banco de dados ou perfil de acesso;
▪ ações_funcionalidades: indica as ações das funcionalidades referenciadas no
chamado, por exemplo: buscar, consultar, incluir, etc.;
▪ objeto_funcionalidades: representa o objeto manipulado pelas funcionalidades,
por exemplo: RDF, QCO e RDO; e
▪ partes_afetadas_objeto: como muitos dos objetos do domínio são composição de
outros, este campo descreve as partes do objeto referenciadas no chamado, por
exemplo: paralisação, mão de obra e permissão de trabalho são partes do RDF.
As modificações no código-fonte do SAO têm sido controladas por um servidor
Apache Subversion. Para cada mês analisado, todo código-fonte da aplicação foi
copiado (checkout) e armazenado num diretório diferente. Depois, as mudanças mensais
18
no código foram identificadas através de uma comparação automática de arquivos feita
pelo WinMerge. Todo o código fonte de cada mês foi comparado com o do mês
anterior. Sempre que o WinMerge encontrou alguma diferença entre arquivos, a
comparação das versões do código-fonte foi salva em um arquivo PDF que destacou em
amarelo as linhas modificadas, conforme ilustrado na Figura 1. À esquerda encontra-se
o código de um mês, à direita o código do próximo mês.
Figura 1. Comparação de código feita pelo WinMerge.
Foram identificadas 426 modificações no total. Cada modificação foi registrada

manualmente com os seguintes dados, além de um identificador:
▪ tipo_modificação: indica o tipo da modificação que ocorreu no código-fonte; por
exemplo: incluir, editar e excluir linhas de código;
▪ parte_código: indica a parte do código-fonte que sofreu a modificação; por
exemplo: variável, método, classe ou interface com usuário;
▪ ações_funcionalidades_afetadas: representa as ações das funcionalidades
afetadas pela modificação do código-fonte, por exemplo: buscar, consultar, etc.;
▪ parte_afetada_objeto: representa a parte do objeto afetada pela modificação no
código-fonte. Por exemplo, se uma modificação afetou mão de obra de um RDF,
este campo indicaria apenas mão de obra;
▪ pacote: indica o pacote que o código-fonte faz parte, por exemplo: domínio,
apresentação, serviço, visão; e
▪ data: a data do último dia do segundo mês da comparação, no formato YYYY-
MM-DD. Por exemplo, na comparação de maio com junho de 2014, a data foi
2014-06-30.
As funcionalidades representadas pelos atributos ações_funcionalidades_afetadas e
parte_afetada_objeto permitem identificar relações entre modificações no código-fonte e
chamados. Determinada modificação em uma funcionalidade pode afetar indiretamente
outras funcionalidades, inclusive causando falhas. Deste modo, é importante investigar
as relações diretas e indiretas entre chamados e modificações no código-fonte. As
relações diretas são percebidas pela mesma funcionalidade (ação+objeto) que o
chamado e a modificação no código-fonte referenciam. Boa parte das relações indiretas
entre funcionalidades podem ser identificadas através das relações entre objetos do
domínio. Por exemplo, considerando-se que um RDF contenha uma paralisação, uma
falha no incluir RDF pode estar relacionado com modificações na consulta, inclusão,
edição e exclusão de paralização. Para viabilizar a análise de relações indiretas entre
funcionalidades, os principais objetos e relacionamentos do SAO foram identificados
com base nas suas regras de negócio e no seu modelo de dados. Os dados coletados
foram armazenados em um banco de dados MySQL para facilitar análise.
19
A análise dos dados seguiu o algoritmo apresentado na Figura 2. Sua execução
foi parte automática e parte manual, pois o conjunto de verificações que precisavam ser
realizadas era enorme: 66 chamados x 426 modificações = 28.116 comparações.
Primeiro executou-se uma análise automática, de acordo com o algoritmo da Figura 3,
para identificar modificações de código relacionadas, direta ou indiretamente, com
objetos manipulados nas funcionalidades de interesse no estudo (Tabela 1). Isso
permitiu reduzir o espoco da análise manual feita em seguida, conforme o algoritmo da
Figura 3. A análise manual considerou não apenas os objetos manipulados, mas também
as ações realizadas sobre eles para realizar um filtro nas modificações de código que
precisavam ser verificadas. A última verificação manual teve por objetivo verificar se a
modificação no código-fonte pode ou não ter causado a falha relatada no chamado.
Escolha uma funcionalidade de interesse

Obtenha as modificações relacionadas direta e indiretamente
pelo objeto da funcionalidade de interesse
(executar o algoritmo que identifica modificações de código por objetos)
Filtrar as modificações encontradas pelas ações das funcionalidades relacionadas
(executar o algoritmo que identifica modificações pelas ações das funcionalidades)
Leia cada modificação restante
Verifique no arquivo PDF que compara os códigos se a modificação tem
relação com o chamado
Se houver relação confirmada, escreva o código da modificação, a parte do código-
fonte modificada e o nome do arquivo do código-fonte
Fim do Leia
Figura 2. Algoritmo para identificar modificações de código-fonte relacionadas
com chamados.
Para cada chamado da macrofuncionalidade de interesse faça

Imprima o número do chamado, sua descrição, data e objeto da funcionalidade
Para cada modificação no código-fonte faça
// identifique as modificações diretas
Se a data de modificação do código for menor que a data do chamado e o
objeto afetado no código for igual ao objeto referenciado no chamado
Então escreva o número da modificação, seu tipo, a parte do código
afetada, a ação da funcionalidade, a parte do objeto afetada, o pacote e
a data da modificação
// Identifique as modificações indiretas
Se a data de modificação do código for menor que a data do chamado e o
objeto afetado no código for igual a qualquer objeto relacionado ao objeto
referenciado no chamado
Então escreva o número da modificação, o tipo da modificação, a parte
do código afetada, a ação da funcionalidade, a parte do objeto afetada,
o pacote e a data da modificação
Fim do para
Fim do para
Figura 3. Algoritmo para identificar modificações de código por objetos.
20
Para cada chamado da funcionalidade de interesse faça
Imprima o número do chamado, sua descrição, data e objeto da funcionalidade
Para cada modificação no código-fonte faça
// modificações diretas
Leia cada modificação direta no resultado (arquivo) anterior e faça
Para cada ação da funcionalidade afetada na modificação lida que estiver
relacionada com a ação da funcionalidade do chamado faça
Escreva o número da modificação, seu tipo, a parte do código
afetada, a ação da funcionalidade, a parte do objeto afetada,
Fim do para
Fim do leia
// modificações indiretas
Leia cada modificação indireta no resultado (arquivo) anterior e faça
Para cada ação da funcionalidade afetada na modificação lida que estiver
relacionada com a ação da funcionalidade do chamado faça
Escreva o número da modificação, seu tipo, a parte do código
afetada, a ação da funcionalidade, a parte do objeto afetada,
Fim do para
Fim do leia
Fim do para
Figura 4. Algoritmo para identificar modificações de código por ações.
Para cada uma das 18 funcionalidades de interesse nesta etapa do estudo (Tabela
1), a análise automática obteve as modificações relacionadas direta e indiretamente
através do objeto da funcionalidade, conforme algoritmo na Figura 3. Ela foi realizada
pela store procedure do MySQL descrita em [Souza, 2016]. Este resultado foi salvo em
dois arquivos texto com conteúdo semelhante ao da Figura 5, um para as modificações
relacionadas diretamente e outro para as modificações relacionadas indiretamente.
Figura 5. Modificações relacionadas por objetos.
Em seguida, a análise manual reduziu o conjunto de modificações a ser

verificado, restringindo-o apenas a modificações com ações de funcionalidades
relacionadas, conforme algoritmo na Figura 4. Esta análise das ações precisou ser
manual, pois era difícil perceber a priori quais ações referenciadas nos chamados
21
estariam relacionadas a quais outras. Este resultado foi salvo em três arquivos texto, um
para cada macrofuncionalidade de interesse nesta etapa do estudo de caso (Tabela 1),
com conteúdo semelhante ao da Figura 6.
Figura 6. Modificações relacionadas por objetos e por ações.
Por fim, com um número ainda mais reduzido de modificações a serem

verificadas, a análise manual passou a analisar as comparações do código fonte nos
arquivos PDFs com os chamados, conforme o último bloco do algoritmo na Figura 2.
Para cada chamado, inspecionou-se a comparação do código-fonte em PDF de cada
modificação que ainda poderia estar relacionada a ele. O objetivo desta análise manual
qualitativa foi verificar se o significado das alterações no código-fonte poderia ter
relação conceitual direta ou indireta com os problemas relatados nos chamados. O
conhecimento do domínio e a experiência de um dos pesquisadores no processo de
desenvolvimento do SAO contribuíram bastante para esta análise. Quando se
confirmava uma possível relação entre uma modificação no código-fonte e um
chamado, os pesquisadores escreveram num arquivo texto o código da modificação
relacionada, a parte do código-fonte afetada (geralmente um método) e o nome do
arquivo fonte, com resultado similar à Figura 7 para o chamado 214.
Figura 7. Modificações com código relacionado ao chamado 214.
5. Resultados
Na investigação por relações entre modificações no código-fonte e chamados, dois
grupos disjuntos de modificações foram identificados: modificações confirmadas e não
confirmadas pela inspeção do código-fonte. As primeiras representam (resultados
positivos) possíveis origens das falhas referenciadas nos chamados (resultado final do
algoritmo na Figura 2). As segundas representam (resultados falso-positivos)
modificações no código-fonte relacionadas com as funcionalidades dos chamados que
não geraram as falhas reportadas (resultado parcial do algoritmo na primeira parte da
Figura 2, resultante da execução dos algoritmos da Figura 3 e Figura 4). Além disso,
essas modificações também foram classificadas pelo relacionamento direto ou indireto
com as funcionalidades referenciadas. Modificações diretas afetam a própria
funcionalidade referenciada no chamado. Já as indiretas afetam outras funcionalidades
22
relacionadas pelos objetos e ações do domínio. A Tabela 2 apresenta a quantidade
mensal de modificações relacionadas com chamados das macrofuncionalidades "Manter
RDF" (esq), "Manter QCO" (centro) e "Gerar Relatório Detalhado do RDO" (dir.). As
quantidades estão estratificadas pela confirmação no código-fonte, e pela relação direta
ou indireta com a funcionalidade.
Tabela 2. Quantidade de modificações no código relacionadas com os chamados.
Gerar Relatório
Manter RDF Manter QCO Detalhado do RDO
relacio. pela relacio. pela relacio. pela
confirmadas confirmadas confirmadas
funciona- funciona- funciona-
pelo código pelo código pelo código
lidade lidade lidade
dir. ind. dir. ind. dir. ind. dir. ind. dir. ind. dir. ind.
dez/13 6 4 29 15 11 21 2 18 70
jan/14 11 1 14 12 7 11 101
fev/14 3 15 87 127 3 18 8 65
mar/14 3 7 4 4 26
abr/14 5 15 14 111 1 9 7 41
mai/14 4 2 1 17 12 6 1 43
jun/14 1 1 3 6 2 34
jul/14 8 33 3
ago/14 9 8 20 8 3
set/14 7 4 41 8 10 2 6
out/14 4 5 14
nov/14 1
dez/14 1 1 1
jan/15
fev/15 1
mar/15
total 50 62 212 343 62 0 66 2 53 0 387 0
O código-fonte do SAO sofreu 50 modificações diretamente relacionadas com
"Manter RDF" ao longo do período analisado, bem como 62 modificações indiretas em
outras funcionalidades que afetam "Manter RDF". Além dessas modificações
confirmadas na inspeção do código-fonte, outras 212 modificações diretas e 343
indiretas estão relacionadas com "Manter RDF", mas não se confirmaram como
possíveis origens de falhas. Em todos os casos, as modificações ocorreram durante pelo
menos 9 meses. O código-fonte do SAO sofreu 62 modificações diretamente
relacionadas com falhas reportadas para "Manter QCO" ao longo de 10 meses durante o
período analisado, mas nenhuma modificação indireta em outras funcionalidades que a
afetam. Também ocorreram outras 66 modificações diretas e 2 indiretas relacionadas
com "Manter QCO", que não se confirmaram como possíveis origens de falhas. Estas
foram dispersas em até 9 meses. O código-fonte do SAO sofreu 53 modificações
diretamente relacionadas com falhas reportadas sobre "Gerar Relatório Detalhado do
RDO" ao longo de 8 meses, mas nenhuma modificação indireta em outras
funcionalidades que a afetam. Ocorreram ainda 387 modificações diretas e nenhuma
indireta que não geraram as falhas reportadas para esta funcionalidade.
23
Cada chamado está relacionado com quantas dessas modificações? As Figuras 8,
9 e 10 indicam a quantidade mensal de modificações relacionadas com "Manter RDF",
"Manter QCO" e "Relatório Detalhado do RDO", respectivamente.
Figura 8. Modificações relacionadas por código ou por funcionalidade para

cada chamado de “Manter RDF”.
A quantidade de modificações foi representada por número dentro de um

triângulo. Um triângulo marrom apontado para cima representa as modificações que
foram confirmadas como possíveis origens das falhas reportadas nos chamados
(resultado positivo). O triângulo branco apontado para baixo representa modificações
relacionadas com a funcionalidade do chamado, mas que não representam origem da
falha reportada (resultado falso-positivo). Os chamados estão representados por um
24
círculo laranja. Os chamados que não tiveram origem identificada nas modificações no
código-fonte foram representados com um tom de laranja mais claro.
Figura 9 - Modificações relacionadas por código ou por funcionalidade para

cada chamado de “Manter QCO”.
Figura 10. Modificações relacionadas por código ou por funcionalidade para

cada chamado de “Relatório Detalhado do RDO”.
25
Observamos que 21% dos chamados não possuem modificações confirmadas no
código: 7 em "Manter RDF", 3 em "Manter QCO" e 2 em "Relatório Detalhado do
RDO". As falhas reportadas em muitos chamados podem ter origem nas modificações
de código que ocorreram em vários meses, chegando a 9 meses de modificações
recorrentes. Algumas das modificações inclusive estão relacionadas com chamados que
ocorreram muitos meses depois, chegando a mais de um ano de intervalo entre a
modificação (possível origem da falha) e a ocorrência do chamado (descoberta da falha).
Figura 11. Modificações relacionadas por código para cada chamado de

“Manter RDF”.
26
Será que uma modificação pode ter causado falhas em mais de um chamado? As
Figuras 11, 12 e 13 apresentam as relações de cada modificação que pode ter sido a
origem de falhas reportadas em cada chamado de "Manter RDF", "Manter QCO" e
"Relatório Detalhado do RDO", respectivamente. Nestas figuras a modificação que pode
ter gerado a falha foi representada por um hexágono marrom. Os chamados continuam
representados por círculos laranja; mais escuro para chamados com modificações que
podem ter gerado a falha reportada e mais claro para chamados sem modificações que
geraram a falha reportada. Os relacionamentos estão representados por linhas marrons
que ligam modificações e chamados. Nessas figuras é possível perceber que boa parte
das modificações afeta mais de um chamado.
Figura 12 - Modificações relacionadas por código para cada chamado de

“Manter QCO”.
Em média, uma modificação está relacionada com 2,13 chamados, com desvio padrão
de 1,55 chamados. Dezessete modificações (16%) têm relação com de 4 até 7 chamados.
Trinta e quatro modificações (33%) se relacionam com 2 ou 3 chamados. Cinquenta e
três modificações (51%) se relacionam com apenas um chamado.
27
Figura 13. Modificações relacionadas por código para cada chamado de
“Relatório Detalhado do RDO”.
6. Discussão
Doze chamados (21%) associados às três macrofuncionalidades analisadas não puderam
ser relacionados com nenhuma modificação do código-fonte após o lançamento do
SAO. Estes problemas podem ser de infraestrutura (banco de dados, permissão de
acesso, etc.) ou tiveram origem no código-fonte da primeira versão. Os outros 45
chamados podem ter sido causados por falhas durante desenvolvimento ou manutenção,
já que existem modificações relacionadas e boa parte delas é recorrente. Mesmo depois
de quase um ano, surgiram chamados associados a modificações de código realizadas na
manutenção. Quase metade das modificações se relaciona com mais de um chamado.
O que poderia ter sido feito durante o processo de desenvolvimento do SAO para
evitar que o usuário passasse por tantos problemas? Certamente a atividade de teste
[Bourque e Fairley, 2014] poderia ter contribuído bastante para a qualidade do SAO
antes dele ser disponibilizado em produção. Vários tipos de teste poderiam ser
melhorados e realizados durante o processo de desenvolvimento do SAO: testes
unitários, de integração, de sistema, de aceitação e de regressão [Delamaro et al., 2007].
Testes unitários e de integração provavelmente identificariam falhas causadas
por modificações diretas no código-fonte, como as 165 indicadas na Tabela 2. Testes de
integração e de sistema provavelmente identificariam falhas causadas por modificações
indiretas no código, como as 62 modificações encontradas. O que o desenvolvedor faria
diante das mudanças no código-fonte que não geraram falhas reportadas nos chamados?
Como o desenvolvedor poderia diferenciá-las daquelas que realmente geraram falhas?
28
Sem um minucioso trabalho de inspeção manual de código, o desenvolvedor pode ter
dificuldade de diferenciar possíveis modificações que afetam ou não as funcionalidades.
Nestes casos, ou se faz uma boa rastreabilidade e bom controle de modificações para
análise de impacto, ou se realiza um volume maior de testes de regressão para cobrir
funcionalidades relacionadas.
A equipe de desenvolvimento do SAO priorizou testes manuais em detrimento
de testes automatizados, mesmo durante a manutenção do sistema. Todavia, é
impraticável executar muitos testes de regressão manualmente com regularidade, pelo
tempo e esforço necessários. A opção viável seria aumentar a cobertura e melhorar os
testes automatizados para execução regular de testes de regressão. Estes testes
provavelmente encontrariam boa parte das falhas que surgiram durante modificações de
código. Se as falhas fossem identificadas e corrigidas rapidamente, não teríamos uma
quantidade e recorrência tão grande de chamados de correção no SAO. Sem execução
sistemática de testes de regressão durante a manutenção, é grande o risco de entregar
correções de falhas que geram outras falhas inadvertidamente.
O Sistema de Acompanhamento de Obras (SAO) tem sido desenvolvido em uma
empresa de energia no Brasil. Como os usuários enfrentaram muitos problemas após o
lançamento, o sistema, que poderia representar uma vantagem para a empresa, tornou-se
desvantagem por falta de qualidade, principalmente para reputação da equipe de TI.
Este artigo apresentou a última etapa de um estudo de caso do SAO que
investigou as relações entre chamados de correção e modificações do código-fonte
durante a manutenção do sistema, entre dezembro de 2012 até março de 2015. O estudo
concentrou-se nas três macrofuncionalidade que receberam maior número de chamados
neste período, pois foi analisar manualmente todas as macrofuncionalidades era
inviável. Percebemos uma boa quantidade de modificações no código relacionada a
chamados. A maioria dos chamados (79%) pode ser relacionada com modificações no
código-fonte após o lançamento do sistema, com uma média de quase 4 modificações
por chamado. Isso reforça a necessidade de manter ativa a preocupação com a qualidade
durante a manutenção do sistema, ainda que as modificações sejam para correção de
falhas como no caso do SAO. As modificações que afetaram diretamente as
funcionalidades referenciadas nos chamados ressaltaram a importância de realizar testes
unitários e de integração. As modificações que afetaram indiretamente as
funcionalidades referenciadas nos chamados destacaram a relevância de testes de
integração, de sistema e, principalmente, os de regressão. Como o volume de testes
necessários costuma ser grande, é fortemente recomendado realizar testes automatizados
para viabilizar uma boa cobertura e frequência de execução ao longo de todo o
desenvolvimento e manutenção do sistema.
A equipe responsável pelo desenvolvimento do SAO ainda não compreendia
muito bem as consequências de não cuidar adequadamente dos testes durante a
manutenção do sistema, além de verificar se as correções funcionam. A credibilidade
perante os usuários e empresa, bem como a indisponibilidade da equipe para realizar
atividades diferentes de correção de falhas foi um custo alto para este descuido. Apesar
de a atividade de testes estar bem estabelecida e divulgada na academia [Craig e Jaskiel,
29
2002; Delamaro et al., 2007], ela ainda precisa ser melhorada na prática de
desenvolvedores na indústria de software brasileira.
A literatura relata várias pesquisas sobre fatores que influenciam a qualidade de
sistemas. Geralmente as pesquisas se concentram em aspectos mais técnicos, como a
identificação de falhas comuns durante a codificação [Lu et al., 2008], a predição de
falhas [D’ambros et al., 2010] e a eficácia do desenvolvimento dirigido por testes [Filho
et al., 2012]. O propósito desta pesquisa é ligeiramente diferente, pois endereça fatores
humanos fornecendo subsídios para conscientizar profissionais da indústria.
Esperamos que a experiência negativa do SAO no período analisado possa contribuir
para os profissionais compreenderem a importância de cuidar adequadamente da
atividade de testes durante todo o processo de desenvolvimento e manutenção de um
sistema. Os dados reais aqui apresentados podem auxiliar desenvolvedores a refletirem
sobre sua prática profissional e identificar possíveis descuidos, de modo a motivar seu
aprimoramento. A atividade de testes precisa deixar de ser considerada como apenas um
assunto acadêmico para ser incluída também como prática cotidiana na indústria.
Referências
Grubb, P; Takang, A.A. (2003) Software Maintenance: Concepts and Practice. 2nd
ed., World Scientific Publishing, 2003.
Bourque, P.; Fairley, R.E. (2014) Guide to the Software Engineering Body of
Knowledge (SWEBOK). IEEE Computer Society Press.
Craig, R. D.; Jaskiel, S. P. (2002) Systematic Software Testing. Artech House
Publishers.
Delamaro, M.E.; Maldonado, J.C.; Jino, M. (2007) Introdução ao Teste de Software,
Elsevier.
White, R.W. e Roth, R.A. (2009) Exploratory Search: Beyond the Query-Response
Paradigm, Morgan and Claypool.
Stake, R.E. (1995) The Art of Case Study Research. Sage Publications.
Sousa, L.A.C. (2016) Estudo Exploratório da Atividade de Testes num Sistema de
Acompanhamento de Obras. Dissertação de Mestrado Profissional em Engenharia
de Software. Universidade Federal do Rio Grande do Norte.
Lu, S.; Park, S.; Seo, E.; Zhou, Y. (2008) Learning from mistakes: a comprehensive
study on real world concurrency bug characteristics. In Proceedings of the 13th
international conference on Architectural support for programming languages
and operating systems (ASPLOS XIII).
D'Ambros, M.; Lanza, M.; Robbes, R. (2010) An Extensive Comparison of Bug
Prediction Approaches. In Proceedings of 7th IEEE Working Conference on
Mining Software Repositories (MSR 2010).
Filho, M.C.; Vasconcelo, J.L.; Santos, W.B.; Silva, I.F. (2012) Um Estudo de Caso
sobre o Aumento de Qualidade de Software em Projetos de Sistemas de Informação
que Utilizam Test Driven Development. Anais do VIII Simpósio Brasileiro de
Sistemas de Informação (SBSI 2012).
30
Integração Contínua no Desenvolvimento de Software com
a Linguagem ABAP
Leonardo Alexandre Pletsch1, Josiane Brietzke Porto1
1
Unidade Acadêmica de Pesquisa e Pós-Graduação – Universidade do Vale do Rio dos
Sinos (UNISINOS) - Av. Unisinos, 950 – 93.022-750 – São Leopoldo – RS – Brasil
leonardoalexandrep@yahoo.com, josibrietzke@unisinos.br
Resumo. O processo de Integração Contínua (IC) permite avanços nos

produtos de software no que tange à qualidade, disponibilidade e entrega. A
IC é normalmente associada às linguagens mais comuns de mercado como
Java e C#, porém seus benefícios não estão necessariamente restritos à estas
linguagens. Esta pesquisa-ação mostra a implantação de IC num contexto de
desenvolvimento de software na linguagem de programação Advanced
Business Application Program (ABAP), num produto desenvolvido para o
mercado brasileiro por uma empresa de Enterprise Resource Planning (ERP).
Os resultados mostraram que mesmo com a IC não implementada em sua
totalidade, resultados positivos consistentes puderam ser alcançados, tais
como sistema de feedback mais eficiente e uma redução no percentual de
chamados de clientes causados por bugs.
Abstract. The Continuous Integration (CI) process allows advances to

software products towards quality, availability and delivery. The CI is
normally associated to the most commons programming languages in the
market like Java and C#, however its benefits are not restricted to these
languages. This research-action shows a CI process implementation in
Advanced Business Application Program (ABAP) programming language, in a
product developed for the Brazilian market by an Enterprise Resource
Planning (ERP) company. Despite the fact of process could not be
implemented completely, consistent benefits were achieved, such a most
efficient feedback system and a decrease in rate of customer incidents caused
by bugs.
1. Introdução
Considerando que qualidade interna de um produto de software influencia a sua
qualidade externa e a sua qualidade em uso, uma maneira de ajudar na qualidade interna
de um software consiste na implementação de um processo de Integração Contínua (IC),
dado que é possível acrescentar várias medições de qualidade interna do software neste
processo, como mostrado em estudo anterior de Moreira (2010).
Segundo Fowler (2006), a IC é uma prática de desenvolvimento de software em
que membros de uma equipe integram seu trabalho frequentemente ou pelo menos
múltiplas integrações ao dia. Cada integração é verificada por um build automático, para
detectar erros de integração o mais rápido possível. Esta abordagem pode levar a uma
31
significativa redução de problemas de integração e um desenvolvimento coeso de
software mais rápido [Fowler 2006].
A automação e o feedback rápido permitem que os problemas sejam
identificados rapidamente. Nesse contexto, Jenkins [ISOTOPE11 2017] corresponde a
uma reconhecida aplicação de IC e Entrega Contínua. Uma das vantagens na sua
utilização consiste na quantidade de plug-ins disponíveis, que englobam várias
linguagens de programação e tecnologias [Mota 2015].
A Advanced Business Application Program (ABAP), originalmente Allgemeiner
Berichts-Aufbereitungs-Prozessor, em alemão ou em português, Processador Genérico
de Criação de Relatórios é uma linguagem de programação de alto nível, criada pela
companhia de software alemã SAP [SAP 2017].
Nesse contexto, o produto UEG (nome fictício) foi desenvolvido com a
linguagem ABAP desde o seu início, em 2013. O uso de testes automáticos,
especialmente testes unitários esteve sempre presente na rotina da equipe de
desenvolvimento. Todavia, com o aumento do número de funcionalidades e
consequentemente, o aumento no tamanho do código fonte, o escopo de monitoramento
destes testes aumentou na mesma proporção. Dado que as ferramentas de feedback de
sistema para a linguagem ABAP atuais não agregam o resultado de um landscape, o
feedback do sistema é pouco eficiente e os desenvolvedores deixam de agir em função
dos resultados dos testes.
Nesse cenário de desenvolvimento, com o advento de plugins do Jenkins para a
linguagem ABAP, a centralização dos resultados dos testes automáticos se tornou
possível. Dado que a IC é a melhor ferramenta para prover feedback automático,
direcionado e em tempo real [Duvall, Matyas and Glover 2007], a utilização desta
técnica se tornou evidente para o desenvolvimento do produto UEG. Uma vez
endereçado o problema inicial de feedback, um grande número de possibilidades de
melhorias no desenvolvimento do produto se abriu. Um exemplo disso é a coleta de
métricas específicas, aliada ao processo de IC, garantindo a qualidade dos produtos
técnicos e auxiliando em decisões táticas durante o projeto [Pressmann 2016].
Este trabalho propõe a implementação de um processo eficiente de IC em
desenvolvimentos na linguagem ABAP, levando em consideração o contexto do produto
UEG. Pode ser representado pela seguinte questão de pesquisa: Como implementar IC
no desenvolvimento de software com a linguagem ABAP?
Cabe ressaltar que uma das práticas da IC é a coleta de métricas a cada build,
entretanto, neste trabalho a única métrica coletada corresponde a de cobertura de linhas
de comando por testes unitários. Outras métricas, tais como complexidade ciclomática
[McCabe 1994], aderência à naming convention [Smit, Gergel, Hoover and Stroulia
2011] e estabilidade [Martin 2002] não são abordadas no escopo desse trabalho, dado
que no momento o único plugin disponível para ABAP é o Sonar e seu custo por ano é
de £9.500,00, por instância [ABAP Sonar 2017].
Esse trabalho pode contribuir para aumentar a qualidade do produto UEG da
organização objeto desse estudo, permitindo um ciclo de feedback, baseado em testes
automáticos aos desenvolvedores a cada entrega de código novo. Desta maneira,
32
entende-se que a utilização da IC pode diminuir o número de chamados de clientes
relacionados aos bugs no produto.
A contribuição principal deste artigo pode servir de referência para a
implementação de um processo de IC em outras aplicações e ambientes de
desenvolvimento com a linguagem ABAP, tendo em vista que até o momento existe
somente breves esboços sobre o tema [Held 2015][Krawczyk 2013]. Dado que este
trabalho é o primeiro que traça um paralelo utilizando dados quantitativos sobre os
ganhos na utilização de IC na linguagem ABAP, em um produto real pode-se derivar o
caráter inovador da solução. Seus resultados tornam-se relevantes por verificar e
demonstrar na prática, os benefícios teóricos propostos pela IC, num contexto prático e
real, que adota essa abordagem de desenvolvimento de software.
Além dessa introdução, o artigo está organizado em mais quatro seções. Na
seção 2, o referencial teórico aborda a linguagem ABAP, os principais termos da IC e
ferramentas, que suportam esta metodologia. Na seção 3, os aspectos metodológicos
adotados são apresentados e, na seção 4, o desenvolvimento da solução é descrito em
detalhes, além dos resultados obtidos. Por fim, a seção 5 aponta considerações finais.
2.1. Integração Contínua (IC)

Neste trabalho acredita-se que a IC é uma maneira de aumentar a qualidade do processo,
que resulta imediatamente nos atributos de qualidade interna. Esta afirmação se baseia
no fato da IC executar regularmente todos os testes automáticos do produto em
desenvolvimento, evidenciando problemas de qualidade interna (via testes unitários),
qualidade externa (via testes funcionais). Desta forma, eventuais problemas de
qualidade em uso podem ser evitados, proporcionando um ganho na qualidade em uso
do software produzido.
No que tange características de IC, cabe uma descrição de termos relacionados:
• Build: consiste em um ou múltiplos scripts usados, para compilar, testar, inspecionar
e distribuir software [Duvall, Matyas and Glover 2007]. Gerar um build é um
procedimento de construir uma aplicação;
• Job: refere-se as tarefas executáveis, monitoradas e/ou controladas pelo Jenkins, por
exemplo. Um build pode ser o produto da execução de um ou vários jobs [Jenkins
2017];
• Commit: ação de gravar alterações em um repositório [Git-scm 2017];
• Deploy: obter software funcional, pronto para implantação (deployment) a qualquer
momento [Sepalla 2010], inclusive, com instalação de software automaticamente, a
partir da IC, por meio de alguns passos específicos [Duvall 2007];
• Máquina ou Servidor de IC: uma máquina separada, que reproduz o ambiente
produtivo. Se possível, exatamente o sistema operacional, banco de dados e versões
de bibliotecas como planejado em ambiente de produção [Sepalla 2010].
De acordo com Fowler (2006), as práticas que compõe a IC são: (i) manter uma
fonte única de repositório de código fonte; (ii) Automatizar o build; (iii) Fazer com que
33
o build seja auto-testável; (iv) Todos da equipe devem fazer commit no repositório
principal todos os dias; (v) Todo o commit deve iniciar um build repositório principal na
máquina de integração; (vi) Corrigir builds quebrados imediatamente; (vii) Manter o
build rápido; (viii) Testar em um clone de um ambiente produtivo; (ix) Fazer com que
qualquer pessoa possa ter o último executável facilmente; (x) Todos possam ver o que
está acontecendo; (xi) Automatizar o deploy.
Como se pode ver a partir dessas práticas, os benefícios da IC são consideráveis
num ambiente de desenvolvimento de software. Jenkins é uma ferramenta de código
aberto para IC e entrega contínua [Jenkins 2017], sendo considerada uma das principais
ferramentas, que apoiam a execução deste processo. Baseia-se num servidor Apache
Tomcat e pode rodar projetos do Apache Maven, assim como Shell Scripts e comandos
de Batch do Windows. Além de possuir diversos plug-ins, que permitem integração com
diversas ferramentas de gerenciamento de código fonte. Possui também a possibilidade
de integração com várias linguagens de programação.
2.2. NetWeaver Application Server ABAP

Desde de 2004, a linguagem ABAP integra a plataforma SAP NetWeaver [NetWeaver
2004]. Como pode ser visto na Figura 1, adaptada de SAP Help (2017), uma aplicação
ABAP roda em um servidor de aplicação específico, dentro desta plataforma.
Figura 1. Visão lógica dos componentes da plataforma NetWeaver
Conforme a Figura 1, o Kernel e os Administration Services são o ambiente de

runtime para todas as aplicações ABAP. Os mesmos são independentes de hardware,
sistema operacional e banco de dados. O runtime ABAP é escrito, principalmente, em C
e em C++. Entretanto, algumas partes de baixo nível também são escritas em ABAP.
Diferentemente de outras linguagens de programação, no ABAP o código fonte
das aplicações é armazenado no banco de dados. Desta forma, o banco de dados de um
sistema NW AS ABAP divide-se em dois grandes componentes lógicos primordiais, os
dados gerados relativos à aplicação e o repositório [SAP Help 2017].
A parte central do repositório é o ABAP Dictionary, que contém descrições das
estruturas e das relações entre os dados. Estas descrições são usadas pelo NW AS ABAP
para interpretar e gerar objetos de aplicação no ambiente de runtime, tais como
34
programas e telas [SAP Help 2017]. Estes objetos são denominados objetos de
repositório.
O componente ABAP Workbench é um ambiente de desenvolvimento completo
para aplicações na linguagem ABAP. Com ela é possível criar, editar, testar e organizar
aplicativos. O ABAP Workbench está totalmente integrado com o NW AS ABAP e, como
as outras aplicações em ABAP, também é escrito nesta linguagem [ABAP 2017] [SAP
Help 2017].
No que tange ao landscape dos sistemas NW AS, para proteger os sistemas
produtivos de alterações não desejadas ou com falhas é recomendado que o sistema de
desenvolvimento seja separado do sistema de produção. Em sistemas NW AS, é
recomendado definir políticas e procedimentos para mudanças e transportes para o
sistema de produção.
Neste contexto é recomendado a utilização do tipo three-tier. Isto significa ter
um sistema separado para desenvolvimento, um sistema separado para qualidade (testes)
e outro para a produção. Estes três sistemas compartilham um diretório comum de
transporte. Com esta configuração de ambiente é possível fazer mudanças e testá-las,
sem interferir nas operações produtivas [SAP Landscape 2017].
Nos sistemas ABAP, change requests e seus tasks constituintes provêm o
mecanismo necessário para gravar os objetos que tenham sido alterados. Quando as
mudanças de customizing objects ou development objects são realizadas, os objetos
alterados são gravados em um task. Cada usuário do sistema é associado a uma task, que
é uma simples lista de objetos alterados por aquele usuário. Tasks são agrupadas em
change requests correspondentes a objetivos de um projeto específico.
Além de listar os objetos alterados, em cada task é documentado quem alterou
cada customização ou objeto de desenvolvimento, bem como o propósito de cada
alteração. Change requests e tasks proporcionam um histórico completo de todas as
mudanças ocorridas durante um projeto na linguagem ABAP. Dado que as mudanças no
software criadas durante uma implementação de um projeto na linguagem ABAP são
resultado de configurações (customizing) ou desenvolvimento, havendo dois tipos de
change requests, customizing change requests e workbench change requests. As
alterações de código fonte são salvas em workbench change requests. Por fim, a
liberação das tasks, e consequentemente da request, é o primeiro passo para o transporte
destas alterações dentro do landscape.
2.3. Automação de Testes

Um software é tão confiável quanto a sua cobertura de testes, e os testes tão valiosos
quanto a sua frequência de execução [Duvall, Matyas and Glover 2007]. Desta forma, a
automação dos diferentes tipos de testes e sua execução frequente são o caminho para a
elevação de qualidade de um software.
A seguir são listadas técnicas e tecnologias envolvidas em automação de testes e
usadas na composição do ambiente de desenvolvimento deste estudo:
• Testes Unitários: adota-se a definição de Cunningham (2013), que se trata de um
tipo de teste automatizado ou teste de desenvolvedor, para outros autores. Unitário,
neste contexto refere-se aos testes de baixo nível, escritos na mesma linguagem do
35
código produtivo, que acessa diretamente seus objetos e membros. Para fins de
qualidade, a falha de um teste unitário implica em somente uma unidade e desta
forma, saber exatamente onde achar o bug [Cunningham 2013];
• ABAP Unit: uma ferramenta do tipo xUnit para a linguagem ABAP. É diretamente
incluída dentro do ambiente de desenvolvimento ABAP e do ambiente runtime
ABAP [ABAP Unit 2017];
• ABAP Test Cockpit (ATC): conjunto de ferramentas que permite executar testes
estáticos em aplicações ABAP. É diretamente integrado aos ambientes de
desenvolvimento ABAP, permitindo ao desenvolvedor verificar seu código dentro
do contexto em que está acostumado [SAP Community 2016];
• JUnit: framework aberto para escrever e executar testes unitários na linguagem
Java. Desta forma, consiste numa instância de uma arquitetura xUnit para
framework de testes unitários [JUnit 2017];
• Axis Apache WSDL2Code: plug-in que através de um WSDL gera stubs de cliente e
servidor para a chamada ou a implementação de web service, conforme WSDL
utilizado [Apache 2016];
• Apache Olingo: biblioteca Java que implementa Open Data Protocol (OData).
Atende aspectos de cliente e servidor do protocolo OData [Apache Olingo 2017],
que é a melhor forma de consumir e prover web services REST [OData 2015];
• Raspberry PI: computador de tamanho reduzido, originalmente projetado para
educação, inspirado no 1981 BBC Micro [CCH 2017] [OPENSOURCE 2017];
• Bootstrap: framework para HTML, CSS e Java Script para desenvolvimento de
projetos mobile first responsivos. É open source, hospedado, desenvolvido e
mantido no GitHub [Bootstrap 2017];
• Selenium: framework de teste para aplicações web, que provê uma ferramenta de
gravação/playback, sem a necessidade de aprender linguagem de script. É provido
de linguagem de domínio específico para desenvolvimento de testes em várias
linguagens como Java, C#, PHP, entre outras [Selenium 2017].
3. Método de Pesquisa
Esta pesquisa caracteriza-se pela natureza aplicada, qualitativa e exploratória, com
coleta de dados longitudinal. Adota-se pesquisa-ação como método de pesquisa,
consistindo em modificações no ambiente foco do estudo através da ação do
pesquisador, evidenciada pela implementação de diferentes ferramentas relacionadas ao
processo de IC.
A pesquisa foi realizada no contexto de uma equipe de desenvolvimento de um
setor, pertencente a uma multinacional do ramo de Enterprise Resource Planning
(ERP), com atuação em mais de 190 países, tendo até o presente momento mais de
320.000 clientes. Conforme estrutura organizacional, essa equipe se encontra cinco
níveis abaixo do diretor responsável, no Conselho de Administração.
O setor no qual essa equipe pertence é responsável pela adaptação do software
padrão da empresa para especificidades de cada país, sendo essa equipe de
36
desenvolvimento responsável pelo produto UEG da organização. Este produto consiste
num framework para o tratamento de dados transacionais provenientes de sistemas de
ERP, com base em um banco de dados in-memory. O UEG foi lançado ao final de 2013
e desde então vem sendo atualizado e tem ganhado novas funcionalidades. Atualmente,
o UEG já vendeu mais de 70 licenças, com aproximadamente 17 clientes em produção.
Quanto à coleta de dados, a técnica análise documental foi adotada, a partir de
registros das ferramentas internas da empresa, por meio de dados do servidor de IC
Jenkins, além de observação direta, tendo em vista que um dos pesquisadores atua na
equipe do estudo [Azevedo e Machado 2011].
A principal métrica selecionada para verificação dos resultados e benefícios foi o
número de chamados de clientes por support package (SP), porque permite inferir a
eficiência do processo de teste do produto UEG como um todo, visto que em cada SP
são realizadas várias etapas de testes, para fins de identificação e correção do máximo
de defeitos possível, além de estar em uso há algum tempo na organização.
Para a análise dos dados quantitativos foram gerados gráficos da quantidade de
chamados de clientes, após cada SP, de forma a aferir a eficiência no desenvolvimento.
Idealmente, antes do lançamento de um SP todos defeitos deste software seriam
detectados e nenhum chamado de cliente existiria. Estes chamados forma classificados
de acordo com a suas causas. As causas que foram utilizadas neste trabalho foram:
dúvida, erro de cliente, novo requisito e bug. Esta forma de analisar os incidentes foi
definida numa reunião dos conceitos de Deffect Removal Effectiveness, citados por Kan
(2002) com uma forma de classificação das ferramentas internas da empresa.
Entre as limitações, o processo de Continuous Inspection [Duvall, Matyas and
Glover 2007] não foi considerado, dado as limitações técnicas existentes no ambiente de
desenvolvimento objeto desse estudo, que não permitem a coleta unificada das métricas
de análise estática de código. O foco deste estudo é o subprocesso de Continuous
Testing [Duvall, Matyas and Glover 2007].
Outra limitação relaciona-se com o fato de alguns autores incluírem o deploy do
código, como uma etapa de IC [Ståhl, Bosch 2014]. Neste trabalho, o deploy de código
não está incorporado no processo de IC. Ainda, cabe ressaltar que os achados do estudo
se limitam à análise dos dados quantitativos obtidos, a partir da métrica supracitada.
Portanto, os autores reconhecem outras análises e considerações possíveis, através da
implementação futura de mais métricas relacionadas ao processo, na organização.
4. Desenvolvimento da Solução Técnica

Nesta seção são descritas as ações implementadas de IC na linguagem ABAP, na
unidade de análise, bem como os resultados da adoção deste processo no
desenvolvimento do produto UEG. Antes, o processo de desenvolvimento do UEG é
mostrado brevemente.
4.1. Processo de Desenvolvimento do Produto UEG

A seguir contextualize-se o processo de desenvolvimento do produto UEG. Esse
processo é formado pelas seguintes etapas:
37
1. Support Package Planning: a partir de support packages (SPs), o produto UEG é
entregue. Esta entrega contém correções de bugs, mudanças legais e novas
funcionalidades. As mudanças legais e novas funcionalidades são planejadas e
priorizadas, para serem desenvolvidas durantes os sprints;
2. Sprints: Um sprint no desenvolvimento do UEG possui duas semanas de duração.
São desenvolvidas partes das novas funcionalidades e mudanças legais, sob forma
de backlog items. Além de designs de desenvolvimentos complexos e testes
funcionais dos backlogs finalizados, no sprint anterior. Testes unitários são
considerados parte do desenvolvimento. O sprint só será aceito se todos os testes
unitários estiverem “OK”;
3. Solution Acceptance Test (SAT): duas semanas antes do fechamento do sistema
para o processo de Assembly é executada uma bateria de testes, envolvendo
especialistas de negócio e desenvolvedores. Funcionalidades desenvolvidas são
retestadas pelos especialistas de negócio e os desenvolvedores focam em correções
de bugs encontrados e na criação e execução de testes adicionais. Para o SP ser
aprovado para o Assembly, o SAT precisa ter os seguintes critérios de saída
atendidos: (i) 100% dos testes executados; (ii) 90% dos testes com status OK; (iii)
todos bugs com prioridade 1 e 2 fechados; (iv) todos bugs com prioridade 3 e 4,
acompanhados de definições de como serão tratados (assinalados em backlogs ou
não serão corrigidos);
4. Assembly: consiste em consolidar todas as requests de desenvolvimento num
formato em que os clientes possam fazer download do site da empresa e instalar em
seus servidores. Porém, além desta consolidação são realizados testes de instalação
e de segurança. O processo de Assembly é finalizado, quando os testes de instalação
e segurança são finalizados e os eventuais erros encontrados corrigidos. Uma vez
que esse processo é finalizado, passa-se para a etapa Release to Customer;
5. Release to Customer: consiste na publicação do link para download do SP no
website da empresa e a notificação dos clientes, posteriormente.
4.2. Implementação de IC para a Linguagem ABAP

Esta pesquisa adapta os conceitos de IC para a linguagem ABAP. A primeira diferença
substancial da linguagem ABAP em comparação com outras linguagens é que não há
desenvolvimento na máquina local do desenvolvedor. Todo desenvolvimento é
centralizado no sistema de desenvolvimento, instalado num servidor remoto. Desta
maneira, o commit no repositório central é substituído por um test transport para o
sistema de qualidade. Dada esta restrição, a seguinte abordagem de adaptação foi feita
nesse contexto, baseada em Duvall, Matyas e Glover (2007) e conforme Tabela 1.
A partir desta adaptação foi montada uma estratégia de consolidação para a
agregação de todos os resultados em uma fonte de dados única, utilizando o servidor de
IC Jenkins. Como o UEG possui diferentes tecnologias integradas, uma infraestrutura de
testes precisou ser criada, conforme mostrado na Figura 2.
Já, a infraestrutura de desenvolvimento do sistema UEG é composta por quatro
sistemas diferentes organizadas da maneira ilustrada na Figura 3. Nessa figura, os dois
landscapes são necessários devido ao mecanismo de entrega de SPs do NetWeaver. O
38
processo de Assembly [Merrian-Webster 2017] de um SP toma o tempo de três semanas
e é executado por um departamento externo. Durante o processo de Assembly, o sistema
de desenvolvimento precisa ficar fechado, fazendo com que a equipe fique bloqueada.
Com este setup, a equipe pode continuar desenvolvendo no landscape Infinity, enquanto
o landscape de entrega fica fechado para o Assembly do SP.
Tabela 1. Adaptação dos passos fundamentais de IC para a Linguagem ABAP
Prática Implementação na Linguagem ABAP
1. Executar o commit de código frequentemente Executar test transports frequentemente
Não transportar código que possuam testes com falha
2. Não executar o commit de código quebrado
ou erros de ATC.
Corrigir o mais rápido possível, erros de testes e
3. Corrigir builds quebrados imediatamente
ATCs nos sistemas de qualidade.
4. Escrever testes de desenvolvimento Criar testes automatizados para tudo o que possa
automatizados ajudar o time
O status dos sistemas de qualidade devem ser sempre
5. Todos os testes e inspeções devem passar
OK
Rodas os builds nos sistemas de desenvolvimento
6. Rodar builds Privados
frequentemente
Corrigir o quanto antes erros de testes e ATCs nos
7. Evitar ficar mantendo código quebrado
sistemas de qualidade.
Figura 2. Infraestrutura de testes automáticos no desenvolvimento do UEG
Figura 3. Landscapes de desenvolvimento do produto UEG
39
Outro motivo importante para a utilização deste setup é o fato do landscape de
entrega ter como objetivo se assemelhar o mais próximo possível aos sistemas dos
clientes. A partir deste landscape são geradas as code patches de correção de bugs
reportados pelos clientes. Estes code patches são internamente chamados de notas. Já o
landscape Infinity é dedicado ao desenvolvimento de funcionalidades maiores que só
são entregues via SP.
Anteriormente, o feedback do sistema se dava somente através de oito e-mails
diários, provenientes das ferramentas atuais do framework ABAP. Com o passar do
tempo, estes e-mails foram sendo ignorados pelos desenvolvedores. Tendo isso em
vista, os resultados foram integrados no Jenkins, sendo uma forma única de visualização
para os testes unitários. Porém, devido à grande quantidade de testes automáticos, houve
uma grande economia de tempo para se observar os resultados, conforme mostra a
Figura 4(a), retirada do servidor Jenkins do time UEG.
(a) (b)
Figura 4. Monitoramento dos ambientes de desenvolvimento do produto UEG
Para melhorar ainda mais a visualização do status dos testes foi criado um monitor
de IC, usando uma TV 42”, junto de um mini PC Raspberry PI, conforme Figura 4(b).
Inicialmente foi colocado uma view do próprio Jenkins para o monitoramento. Porém, o
feedback inicial dos desenvolvedores foi que os resultados apresentados eram de difícil
visualização. Diante disso foi desenvolvida uma nova interface para visualização, com o
framework web Bootstrap. Dada a diretriz estabelecida na Tabela 1 foi colocado nessa
TV somente os status dos sistemas de qualidade. O desenvolvimento da solução
completa foi executado nessa pesquisa-ação, conforme linha do tempo da Tabela 2.
Tabela 2. Implantação de IC nos support packages do produto UEG
Support Package Etapa do processo
Setup do Jenkins; Monitoramento dos testes unitários;
SP04 (de 13/02/2015 até 24/08/2015)
Instalação de monitor de 24".
SP05 (de 25/08/2015 até 11/12/2015) Desenvolvimento dos testes de Web Services SOAP.
Desenvolvimento dos testes em Selenium; Desenvolvimento
SP06 (de 12/12/2015 até 04/04/2016)
dos testes de Web Services REST.
Instalação de TV de 42"; Nova interface em Bootstrap;
SP07 (de 05/04/2016 até 08/08/2016) Inclusão das medições de cobertura de comandos dos
desenvolvimentos em ABAP.
40
4.3. Medição e Análise dos Resultados Obtidos
Ressalta-se que o processo de IC implantado até o fim deste trabalho não incorpora a
totalidade das práticas que o compõe (por exemplo, a automação de testes de cenário, o
processo de inspeção contínua, dentre outros). Na Figura 5, o número de chamados de
clientes, com as respectivas causas após cada SP é apresentado. Retrata-se a quantidade
de incidentes, após cada SP como uma forma de medir a eficiência da etapa de SAT,
visto que idealmente, esta etapa deveria encontrar todos os bugs do produto.
Figura 5. Evolução dos chamados em função dos support packages do UEG
Na Figura 5, avaliando-se os últimos dois SPs verifica-se um aumento de 23% na

quantidade de chamados de clientes (de 275 para 340), bem como um aumento de
aproximadamente 6% do número de chamados causados por bugs (de 156 para 165).
Numa primeira análise pode-se imaginar que IC não proporcionou uma diminuição na
quantidade de chamados e consequentemente, não adicionou qualidade ao produto
UEG. Porém, há um fato que indica uma melhoria consistente: o fato do aumento do
número de incidentes causados por bugs (6%) ser uma ordem de grandeza
significativamente menor, do que o aumento do número de incidentes total (23%).
Na Figura 6 tem-se o percentual dos chamados de clientes gerados por bugs na
quantidade geral de incidentes de cada SP. Esta análise é importante para compreender o
impacto do desenvolvimento no total dos chamados. Como pode ser observado, há uma
redução significativa no percentual dos bugs nos últimos SPs (de 56,97% para 48,68%),
o que indica uma tendência de melhoria no processo de desenvolvimento. A expectativa
era que esta tendência se confirmasse a cada SP, entretanto, é possível perceber que
outros benefícios foram alcançados com a adoção de práticas de IC.
Figura 6. Distribuição das causas dos chamados dos support packages do UEG
41
Nota-se uma quantidade de chamados causados por bugs um tanto desproporcional
no SP05. Um fato que pode justificar esta situação refere-se a entrada em produção de
grandes clientes. Isto levou a um estresse da solução significativo, fazendo com que
muitos bugs fossem identificados no mesmo período de tempo.
A partir do início do SP07 foi iniciado a medida da cobertura de linhas de comando
em ABAP. Com base neste monitoramento, a equipe de desenvolvimento percebeu que
haviam uma quantidade grande de código relativo às funcionalidades obsoletas ou
ferramentas internas que continuavam sendo entregues para os clientes sem necessidade.
Estas linhas de códigos eram um verdadeiro passivo tecnológico para o produto UEG,
que eventualmente causavam problemas de instalação.
Conforme a Figura 7, extraída de ferramenta interna (ABAP Unit Framework) pode-
se ver redução de mais de 60.000 linhas de código, que eram entregues sem necessidade
para os clientes, tornando o produto muito mais enxuto e muito mais manutenível.
Percebe-se uma clara tendência de crescimento nos chamados de clientes, o que pode
ser interpretado como falta de qualidade no produto. Porém, verificando-se a Figura 6 e
avaliando a tendência de crescimento do número total de chamados clientes, em
comparação com a tendência de crescimento de chamados de clientes causados por bugs
é possível considerar que estas duas tendências não tem o mesmo comportamento,
principalmente, na comparação entre os dois últimos SPs.
Figura 7. Evolução da cobertura de linhas de código no produto UEG
Neste caso, o número total de chamados aumentou 23% (de 275 para 340) e o
número de chamados causados por bugs aumentou 6% (de 156 para 165). Vale ressaltar
que o produto UEG é dedicado ao tratamento de dados tributários de empresas no
Brasil. De acordo com Forbes (2013), o Brasil detém a maior complexidade tributária
do mundo. Considerando este fato e somando-se à realidade de que cada cliente
adquirente do produto UEG pode possuir as suas próprias especificidades tributárias, é
esperado que o número de chamados aumente até atingir um ponto de equilíbrio.
O grande mote deste trabalho, a partir da orquestração dos testes automáticos via IC
é evitar que regressões sejam incluídas no código, e consequentemente, bugs corrigidos
voltarem. Se por um lado não foi percebida uma redução no número de incidentes, após
esta implementação parcial do processo de IC é válido afirmar que sem o processo de
IC, provavelmente, o número de chamados cresceria de uma forma muito mais agressiva
do que a verificada neste trabalho.
42
Dado o objetivo geral estabelecido nesse estudo foi implantado um processo de IC no
desenvolvimento ABAP, como forma de aumentar a qualidade do produto UEG e
melhorar o feedback dos testes automáticos para os desenvolvedores. Como
consequência desta implantação, esperava-se uma diminuição nos chamados de cliente.
Mesmo que este benefício não tenha sido diretamente alcançado foi possível determinar
uma melhora na qualidade do produto UEG, seja pela diminuição do percentual de bugs
no último SP, seja pela percepção coletada da equipe envolvida, via reuniões de projeto.
Os motivos que limitaram o alcance dos benefícios podem estar associados ao
fato de que o processo de IC não estar implementado em sua totalidade no contexto em
estudo e ao produto ainda estar em fase de amadurecimento, tendo em vista muitos
chamados estarem relacionados a dúvidas e erros feitos pelos clientes, bem como a
adição de novos requisitos, dada a complexidade do domínio e uma variação de cliente
para cliente. Cabe observar que somente melhorando o sistema de feedback dos testes
automáticos foi possível notar uma melhora na qualidade do produto. Com isto, é
possível atestar o atendimento dos objetivos de pesquisa.
Uma observação sobre o método de avaliação dos resultados se faz importante.
Ele é fortemente baseado na métrica Deffect Removal Effectiveness, postulada por Kan
(2002). Nos resultados foi verificado a eficiência de todo o processo de
desenvolvimento da seguinte forma: idealmente, o processo de teste do produto UEG
(incluindo a IC) detectaria todos os bugs do produto. Assim sendo, cada chamado de
cliente pode ser interpretado como uma perda de eficiência no processo de teste. Esta
visão garantiu uma maneira consistente de medir progresso, fato que permitiu atestar
que a proposta deste artigo foi atingida de forma quantitativa.
Vale ressaltar que este trabalho não possui precedente na literatura. Sugestões de
como implantar um processo de IC em linguagens de uso amplo (como Java, por
exemplo) são relativamente comuns dentro e fora do meio acadêmico. Porém, ao tratar
uma linguagem que não possui desenvolvimento local, tão específica como o ABAP foi
preciso uma carga autoral considerável, para viabilizar a proposta de solução técnica e
sua conseguente implantação, na organização objeto do estudo.
Como sugestão de futura pesquisa pode-se conduzir uma implementação técnica
do processo, consistindo em um guia a ser utilizado para implementar IC em
desenvolvimentos ABAP em âmbito global, tanto dentro da empresa SAP como em
empresas parceiras. Um ganho extremamente interessante com a adoção deste processo,
em outros contextos de desenvolvimento seria o feedback prático, que a solução
proposta neste artigo teria, contribuindo para o aperfeiçoamento do mesmo. Além disso,
sugere-se dar continuidade na implementação de todo o escopo teórico de IC
(continuous inspection, deploy, etc.) para a linguagem ABAP.
References
ABAP. (2017) “ABAP SAP Documentation”,
https://help.sap.com/saphelp_nw70/helpdata/en/fc/eb2e97358411d1829f0000e829f
bfe/frameset.htm. Acesso em: 29 abr. 2017.
ABAP Sonar. (2017) “SonarABAP“, https://www.sonarsource.com/why-
43
us/products/codeanalyzers/sonarabap.html. Acesso em: 24 abr. 2017.
ABAP Unit. (2017) “ABAP Unit”,
https://help.sap.com/saphelp_nw74/helpdata/en/49/18061c005338a1e10000000a42
1937/content.htm. Acesso em: 29 maio 2017.
Apache. (2016) “WSDL2Code”, https://axis.apache.org/axis2/java/core/tools/maven-
plugins/axis2-wsdl2code-maven-plugin/. Acesso em: 16 abr. 2017.
Apache Olingo. (2017) “Apache Olingo™”, https://olingo.apache.org/. Acesso em: 16
abr. 2017.
Azevedo, D. and Machado, L. (2011) “Métodos e Procedimentos de Pesquisa: do
Projeto ao Relatório Final”, Editora Unisinos.
Bootstrap. (2017) “Bootstrap”, http://getbootstrap.com. Acesso em: 16 abr. 2017.
Centre for Computing History (CCH). (2017) “Eben Upton - Life Before Raspberry Pi”,
http://www.computinghistory.org.uk/det/42103/Eben%20Upton%20-
%20Life%20Before%20Raspberry%20Pi. Acesso em: 07 abr. 2017.
Cunningham (2013). “Unit Test”, http://c2.com/cgi/wiki?UnitTest. Acesso em: 29 mar.
2017.
Duvall, P.; Matyas, S.; Glover, A. (2007) “Continuous Integration: Improving Software
Quality and Reducing Risk“, Addison-Wesley.
Forbes. (2013) “Brazil Ranked Most Time-Consuming Tax Regime In The World”,
http://www.forbes.com/sites/joeharpaz/2013/12/17/brazil-ranked-most-time-
consuming-tax-regime-in-the-world/#5719a8622fdf. Acesso em: 14 mar. 2017.
Fowler, M. (2006) “Continuous Integration”,
https://martinfowler.com/articles/continuousIntegration.html. Acesso em: 15 mar.
2017.
Git-scm. (2017) “Git-commit”, https://git-scm.com/docs/git-commit. Acesso em: 11 abr.
2017.
Held, M. (2015) “Journey to setup best possible Continuous Integration with ABAP
Project”, goo.gl/TGjhnP. Acesso em: 26 jul. 2017.
ISOTOPE11. (2017) “Jenkins blog”, https://isotope11.com/blog/styling-your-jenkins-
continuous-integration-server. Acesso em: 25 abr. 2017.
Jenkins. (2017) “Jenkins”, https://jenkins-ci.org/. Acesso em: 05 abr. 2017.
JUnit. (2017) “Frequently Asked Questions”,
http://junit.org/junit4/faq.html#overview_1. Acesso em: 29 abr. 2017.
Kan, S. H. (2002) “Metrics and Models in Software Quality Engineering”, Addison-
Wesley, 2th edition.
Krawczyk, A. (2013) “Continuous Integration – Automated ABAP Unit Tests in
Hudson”, goo.gl/mdkPTy. Acesso em: 26 jul. 2017.
Martin, R. C. (2002) “Agile Software Development: Principles, Patterns, and Practices”,
Prentice Hall.
44
McCabe, T. and Watson A. (1994) “Software Complexity”, CrossTalk: The Journal of
Defense Software Engineering.
Merrian-Webster. (2017) “Assembly Language”, http://www.merriam-
webster.com/dictionary/assembly%20language. Acesso em: 25 mar. 2017.
Moreira, G. de S. P. et al. (2010) “Software product measurement and analysis in a
continuous integration environment”, Information Technology: New Generations,
Third International Conference on, p. 1177–1182.
Mota, G. M. (2015) “Implantando uma Etapa de Análise Estática para Revisão de
Código em uma Infra de Integração Contínua”, Trabalho de Conclusão do Curso de
Especialização em Qualidade de Software – Unidade Acadêmica de Pesquisa e Pós-
Graduação, Unisinos, São Leopoldo.
Netweaver. (2004) “Overview of NetWeaver AS ABAP”,
https://help.sap.com/saphelp_nw70/helpdata/en/fc/eb2e97358411d1829f0000e829f
bfe/frameset.htm. Acesso em: 07 maio 2017.
OData (2015). “OData - the best way to REST”, http://www.odata.org/. Acesso em: 16
abr. 2017.
Pressmann, R. S. and Maxim, B. R. (2016) “Engenharia de Software: uma abordagem
professional”. 8. ed. AMGH. ISBN 978–85–8055–533-2.
OPENSOURCE. (2017) “What is a Raspberry Pi?”,
https://opensource.com/resources/what-raspberry-pi. Acesso em: 16 abr. 2017.
SAP. (2017) “About SAP SE”, http://go.sap.com/corporate/en.html. Acesso em: 04 abr.
2017.
SAP Community. (2017) “ABAP Test Cockpit”,
https://wiki.scn.sap.com/wiki/display/ABAP/ABAP+Test+Cockpit. Acesso em: 16
abr. 2017.
SAP Landscape. (2017) “The SAP System Landscape”, http://goo.gl/G79IQG. Acesso
em: 27 mar. 2017.
SAP Help. (2017) “Overview of NetWeaver AS ABAP”,
http://help.sap.com/saphelp_nw70/helpdata/en/fc/eb2e97358411d1829f0000e829fb
fe/content.htm. Acesso em: 15 mar. 2017.
Sepalla, A. (2010) “Improving software quality with Continuous Integration”,
Dissertação de Mestrado, Alto University, Esbo.
Ståhla, D. and Bosch, J. (2014) “Modeling continuous integration practice differences in
industry software development”, The J. of Systems and Software, 87, pp 48-59.
Selenium. (2017) “What is Selenium?”, http://docs.seleniumhq.org/. Acesso em: 22 abr.
2017.
Smit, M., Gergel B., Hoover H. J. and Stroulia E. (2011) "Code convention adherence in
evolving software", In: 27th IEEE International Conference on Software
Maintenance (ICSM), Williamsburg, VI, 2011, pp. 504-507.
45
Comparando Quantitativamente Processos de Software -
Experiências com Práticas Ágeis
Igor M. Pereira, Vicente J. P. Amorim, Lucas C. Lima
Departamento de Computação e Sistemas (DECSI) - Universidade Federal de Ouro

Preto (UFOP)
Caixa Postal 24 – 35.931-008 – Minas Gerais – MG – Brasil
{igormuzetti, vjpamorim, lucaslima2004}@gmail.com

Resumo. A adaptação de processos de software em projetos reais é
comumente reportada através de dados qualitativos. Contudo, dados
quantitativos podem ser usados para auxiliar a tomada de decisão e a
comparação de alternativas. Este trabalho tem o objetivo de verificar a
melhoria de um processo de software utilizando técnicas de processos
experimentais sistemáticos. As práticas de engenharia de software utilizadas
no processo de software observado são oriundas de métodos ágeis. Os
resultados indicam que as práticas ágeis de construção e testes influenciam
significativamente na melhoria de processos e este controle pode ser realizado
com um baixo custo em pequenas organizações.
Abstract. An adaptation of software processes to real projects is commonly
communicated through qualitative data. However, quantitative data can be
used to aid decision making and a set of alternatives. This work aims to verify
an improvement of a software process using techniques of systematic
experimental processes. Software engineering practices used in the observed
software process come from agile methods. Results indicate that the
construction and testing practices significantly influence process improvement
and this control can be carried out at a low cost in small organizations.
1. Introdução
Melhorar a qualidade do produto pode ser o objetivo principal de uma iniciativa de
melhoria de processo de software. Diversas organizações alcançam melhorias na
qualidade de seus produtos controlando diversos atributos de qualidade através da
adaptação de seus processos. Tais adaptações podem ser realizadas através do
seguimento de modelos e normas para melhoria de processos, como o uso do CMMI, da
SPICE, entre outros [García-Mireles et al., 2015]. Estudos apontam que o uso do
MPS.BR, Modelo para Melhoria do Processo de Software Brasileiro, também impacta
positivamente na qualidade dos produtos desenvolvidos em organizações hospedadas no
setor público e privado e em ambientes de pesquisa e desenvolvimento. As organizações
compreendem que para gerenciar a qualidade de seus produtos, seus processos precisam
ser definidos, seguidos e avaliados sistematicamente [Weber et al., 2015].
A adaptação de processos de software para projetos reais é usualmente realizada.
Essa personalização busca atender as características específicas dos diversos tipos de
projetos de software e é conhecida pela comunidade de engenharia de software seja na
academia ou em entidades desenvolvedoras [Kalus, 2013]. É comum encontrar relatos
46
de experiência e estudos de caso que reportam lições aprendidas, positivas e negativas,
ou discutem as diversas adaptações das práticas, técnicas e métodos que compõem os
processos de software [Turk, 2005; Fuggetta, 2014]. Entretanto, a comparação de
processos pode ser realizada também através de uso de técnicas de processos
experimentais sistemáticos que auxiliam a tomada de decisão e a comparação de
alternativas através da sumarização de dados e outras técnicas estatísticas [Jain, 1991].
Entidades desenvolvedoras de software sabem que para gerenciar a qualidade
dos seus produtos, elas precisam definir processos, segui-los a avaliá-los
sistematicamente [Svensson et al., 2012]. Este trabalho compara a evolução de um
processo de software formado por práticas ágeis de desenvolvimento durante um ano
em um projeto real. O projeto foi executado no laboratório de pesquisa em computação,
denominado iMobilis, que fica hospedado no Instituto de Ciências Exatas e Aplicadas
(ICEA) da Universidade Federal de Ouro Preto (UFOP). O projeto é caracterizado como
inovador e surgiu de uma parceria entre a UFOP e uma grande empresa privada atuante
na região que incentiva a pesquisa. Participam do projeto cinco alunos dos últimos
períodos dos cursos de Engenharia da Computação e Sistemas de Informação, três
professores destes cursos e um especialista em Engenharia da Computação (aluno
formado). Como é uma equipe constituída por dez pessoas que já se conhecem a algum
tempo, a comunicação face a face e a auto-organização são muito realizadas. Tal fato
incentivou o uso de práticas ágeis na composição do processo a ser seguido no projeto.
Práticas ágeis tentam resolver diversas dificuldades enfrentadas por equipes de
desenvolvimento, como entregar um produto final que realmente gere valor ao cliente e
adaptar um processo às mudanças que ocorrem em um projeto que o cliente participa
ativamente do seu desenvolvimento [Jalali et al., 2012]. De acordo Gomes (2014) o
conjunto de práticas ágeis existente pode ser comparado com uma caixa de ferramentas,
na qual, para cada projeto, um subconjunto de práticas pode ser mais eficiente. O autor
também as classificou em seis grandes grupos: requisitos, projeto, construção, testes,
processo, organização, aprendizado e gestão ágil. O processo observado neste trabalho
evoluiu de práticas de requisitos, processo e organização para em um segundo momento
além desses grupos, de construção e testes. Ou seja, no primeiro momento o foco do
processo era mais voltado para o controle e monitoramento do projeto e o segundo
momento o foco foi em técnicas essenciais de desenvolvimento em equipe para entregar
software em funcionamento.
A inserção e adaptação de práticas de engenharia de software em um processo
acontecem pela busca da melhor qualidade dos produtos almejada pelas entidades
desenvolvedoras. O alcance de uma melhor qualidade dos produtos concede melhor
posição no mercado e fidelidade de clientes e usuários, o que pode ser muito vantajoso,
seja para projetos desenvolvidos por entidades privadas ou públicas [Weber et al.,
2015]. Projetos desenvolvidos por equipes ágeis, muitas vezes encontradas em pequenas
empresas, startups e laboratórios de tecnologia e inovação, não possuem uma equipe
específica para o acompanhamento rotineiro da melhoria de qualidade de seus processos
e produtos. Contudo, essas informações são muito úteis para auxiliar essas entidades a
tomar decisões e decidir sobre alternativas. Este trabalho apresenta uma análise de
métricas coletadas pela própria equipe empiricamente em um projeto durante um ano. A
análise feita conta com técnicas de estatística descritiva e indicaram que o segundo
momento do processo se apresentou significativamente melhor do que o primeiro
momento.
47
De acordo com o problema e o contexto especificado, esta pesquisa responde à
seguinte questão: Como comparar estatisticamente processos de software seguidos por
pequenas equipes? Por isso, o objetivo geral desta pesquisa foi analisar as médias das
métricas de processo coletadas durante um ano com o propósito de caracterizar as
práticas ágeis que influenciam na melhoria do processo de software seguido do ponto de
vista de desenvolvedores de software no contexto de projetos reais desenvolvidos por
equipes pequenas.
O restante deste relato está organizado conforme proposto para estudos de caso
conforme sugere Runeson et al., (2012). Inicialmente, é discutida uma revisão da
literatura na Seção 2. A seguir, na Seção 3, o estudo de caso é descrito. Na Seção 4 os
resultados obtidos são apresentados e discutidos. Por fim, na Seção 5 são apresentadas
as considerações finais, as possibilidades de trabalhos futuros e as limitações do estudo.
2. Revisão da Literatura
Unterkalmsteiner et al., (2012) realizaram uma revisão sistemática na literatura sobre
medições e avaliações de iniciativas de melhoria de processos de software. Eles
identificaram os tipos de métricas de software mais utilizadas nas iniciativas de
melhoria e descobriram que as do tipo processo, como produtividade durante o
desenvolvimento e taxa de defeitos por fase de desenvolvimento são as mais utilizadas.
Eles também relataram que o uso do CMMI (Capability Maturity Model Institute) é o
mais abordado nessas iniciativas. Entretanto este tipo de controle é usado por empresas
já certificadas em altos níveis do CMMI, sendo elas de médio ou grande porte. Esta
pesquisa analisa sistematicamente métricas do tipo processo coletadas com um baixo
custo por uma equipe pequena que deseja manter a melhoria contínua de seu processo.
Kalus e Kuhrmann (2013) fizeram uma revisão sisteet al.mática e identificaram
e discutiram quarenta e nove critérios comumente utilizados na adaptação de práticas de
engenharia de software em processos seguidos por projetos reais. Eles concluíram que
as práticas precisam sim ser adaptadas aos diferentes tipos de projetos, mas não existe
uma definição de quais critérios básicos precisam ser considerados em uma adaptação.
Este trabalho também usou a adaptação de práticas descritas na literatura para as
particularidades do processo observado. Os critérios que envolvem o ambiente externo,
como participação dos usuários e clientes e objetivos como integração contínua e testes,
levantadas pelos autores representam as práticas que caracterizam a melhoria do
processo obtida nesta pesquisa.
Magalhães et al., (2015) apresentam resultados preliminares referentes às linhas
de processo de software do processo de análise de desempenho e uma ferramenta para
instanciar e executar o processo de análise de desempenho. Segundo os autores este tipo
de atividade deve ser realizada com o auxílio de técnicas e ferramentas estatísticas.
Contudo, o estudo de Magalhães e colaboradores não apresenta resultados de projetos
reais. Este trabalho não utiliza um software para o controle estatístico do processo, mas
usa técnicas estatísticas que podem ser aplicadas às métricas de software coletadas
durante a execução de projetos reais.
Equipes ágeis são normalmente formadas por times pequenos que dão maior
importância às pessoas e interações do que para processos e ferramentas. Por este
motivo, elas não costumam seguir um processo padrão completo, elas costumam
adaptar as práticas de engenharia de software conforme as particularidades de seus
48
projetos. Fontana et al., (2015) discutem como a melhoria de processos para estes tipos
de equipes pode ser medido. As autoras concluíram que as equipes de desenvolvimento
de software ágeis evoluem naturalmente. Elas analisaram a evolução das práticas de
nove equipes e descobriam que o processo era, como esperado, peculiar. Cada equipe
observada adotou práticas baseadas em suas circunstâncias e melhorou as práticas com
base nos desafios que enfrentaram. Desta maneira, este trabalho não foca em apresentar
como o time observado adaptou as novas práticas inseridas no processo para melhorá-
lo. Foi considerado que outros times podem adaptar as mesmas práticas de maneira
diferente, o que se quis demonstrar neste trabalho foi que elas realmente impactaram
significativamente na melhoria do processo.
Reconhece-se a relevância e a importância que a melhoria de processos de
software e o desenvolvimento ágil ganharam no campo da engenharia de software.
Ambas são abordagens que aumentam a eficiência e a eficácia de uma organização de
desenvolvimento de software e aprimoram seus produtos. Santana et al., (2015)
apresentam em seu trabalho a identificação e caracterização de melhoria de processos
em ambientes ágeis através de uma revisão sistemática da literatura, incluindo 423
trabalhos publicados entre 2001 e Março/2013. Os autores concluíram que conduzir
iniciativas de melhoria em ambientes ágeis é diferente do tradicional, tornando-se
necessário adaptar as abordagens de melhorias existentes ou criar novos métodos. Neste
trabalho foi adaptado um método de comparação quantitativa de processos sistemáticos
em um processo de software que utiliza práticas ágeis, cujo intuito foi descobrir se o
desempenho havia melhorado com a inserção de novas práticas orientadas mais ao
desenvolvimento e testes enquanto que anteriormente as práticas utilizadas eram mais
voltadas à gestão.
É comum ao implantar um processo de software em um projeto real, no primeiro
momento, escolher práticas de engenharia de software mais voltadas para o
gerenciamento de projetos e no segundo momento incorporar o processo com técnicas
mais focadas ao desenvolvimento de engenharia de software. Por exemplo, muitas
organizações implantam primeiramente o Scrum em seus projetos, que é uma
metodologia focada na gestão ágil. Depois de implantado é que se elas aplicam práticas
da Programação Extrema para dar maior valor à qualidade dos produtos entregues
[Chaves, 2011]. Porém, estudos empíricos que comprovem estatisticamente estas
evoluções de processos, não são fáceis de encontrar.
3. Metodologia
Esta seção apresenta a metodologia seguida para alcançar o objetivo deste trabalho. O
laboratório de computação móvel e sistemas embarcados, iMobilis1, fica hospedado no
campus da Universidade Federal de Ouro Preto (UFOP) em João Monlevade. O
iMobilis desenvolve projetos de pesquisa em computação que estão relacionados à
construção de soluções para plataformas móveis e sistemas embarcados com o auxílio
de práticas de engenharia de software. É neste ambiente que foi realizado o projeto real
do estudo de caso desta pesquisa, conhecido como quasi-experimento, segundo Wolhin
et al., (2012). Os projetos do iMobilis são atrelados à programas de incentivo à pesquisa
fomentados pelo governo federal e pela própria UFOP e com parcerias público-privadas
que a UFOP possui com empresas do setor privado que atuam na região.
1
www.imobilis.ufop.br
49
As ferramentas de apoio utilizadas para coleta de métricas foram: a Dokuwiki2
para gestão da documentação dos projetos, o GitLab3 é utilizado para o gerenciamento
de configuração e mudança e o uma própria para gestão dos projetos em geral. Todas as
ferramentas utilizadas foram dadas prioridades para projetos open-source, apenas a
ferramenta de gerenciamento de projetos ainda não possui licença, pois está sendo
finalizada como outro projeto do iMobilis. Acredita-se que outras ferramentas correlatas
a estas podem ser utilizadas em replicações deste estudo.
O método deste estudo contou com um processo experimental sistemático
realizado para comparar dois momentos de um processo de software durante um ano de
execução de um projeto real executado por uma mesma equipe de dez colaboradores. O
intuito foi avaliar se a inserção de práticas ágeis focadas no desenvolvimento e testes
impacta significativamente na melhoria do processo anteriormente composto por
práticas de gestão. O processo experimental sistemático foi seguido pelos seguintes
passos:
i. Entendimento do problema e identificação da questão que se desejava responder
e definição dos objetivos.
 O problema que se desejava resolver foi como verificar que ao longo de
projetos reais se a inserção de práticas ágeis de desenvolvimento de
software influencia a melhoria do processo.
 A questão que necessitava de uma resposta era: Como comparar
momentos de um processo ou processos diferentes, executados por
pequenas organizações que não possuem muitos recursos para aplicarem
técnicas dos mais altos níveis dos modelos de maturidade seguidos no
mercado, com dados quantitativos?
 O principal objetivo da pesquisa foi verificar se as médias das métricas
de dedicação e velocidade coletadas durante quinze meses em projetos
que seguem ritmo correlato a este são úteis para demonstrar o quão
significante um processo é do outro.
ii. Seleção de métricas. As métricas selecionadas foram de dedicação e velocidade
relativas.
 Elas indicam o quanto os colaboradores trabalharam no projeto em razão
do que eles deveriam trabalhar e o quanto eles entregavam de valor ao
cliente em razão do que eles negociavam que iriam entregar,
respectivamente [Pereira et al., 2013]. Todas as métricas foram coletadas
semanalmente pelo scrum master acessando as ferramentas de apoio ao
processo.
iii. Identificação dos parâmetros.
 Os parâmetros considerados foram todas as práticas ágeis presentes nos
dois momentos do processo e mais as novas práticas inseridas somente
no segundo momento. São elas: Reuniões diárias, de demonstração, de
2
www.dokuwiki.org
3
https://gitlab.com
50
retrospectivas, iterações, sprint backlog, burdown chart, product
backlog, planning poker, times pequenos, ambientes de trabalho
compartilhado, cliente interno e scrum master, essas são práticas mais
voltadas para o gerenciamento de projetos. E as práticas focadas no
desenvolvimento que foram inseridas no segundo momento foram:
desenvolvimento dirigido por comportamento, entregas frequentes, testes
automatizados de aceitação e exploratórios.
iv. Decidir quais os parâmetros seriam estudados.
 Os parâmetros escolhidos foram as quatro práticas focadas no
desenvolvimento presentes no segundo momento do processo:
desenvolvimento dirigido por comportamento, entregas frequentes, testes
automatizados de aceitação e exploratórios.
v. Seleção das técnicas.
 Sumarização de dados, verificação que os dados seguem uma
distribuição normal e comparação de observações não pareadas.
vi. Seleção da carga de trabalho.
 A carga de trabalho escolhida foi a média das duas métricas de todos os
colaboradores durante os seis primeiros meses que representam o
primeiro momento do processo e projeto e os outros nove meses
posteriores que correspondem ao segundo momento do processo e
projeto. Esses dados foram coletados nas ferramentas de gerencia de
configuração e de projetos utilizadas pela equipe e não dependem de
ferramentas específicas.
vii. Execução dos experimentos.
 Os experimentos foram executados durante quinze meses.
viii. Análise, interpretação e apresentação dos resultados e da conclusão.
 Esses últimos passos foram realizados no final dos quinze meses de
processo.
4. Resultados
Os dados considerados nesta comparação de experimentos não pareados foram as
médias das métricas de dedicação e velocidade relativas coletadas durante os quinze
meses de projeto. Eles podem ser visualizados nas Tabelas 1 e 2.
Tabela 1. Média da dedicação e velocidade relativa da equipe durante os sprints do
Processo A
Processo A
Dedicação Velocidade
Sprint 1 105% 69%

Sprint 2 112% 48%
Sprint 3 99% 69%
51
Sprint 4 99% 48%
Sprint 5 113% 61%
Sprint 6 100% 67%
Tabela 2. Média da dedicação e velocidade relativa da equipe durante os sprints do
Processo B
Processo B
Dedicação Velocidade
Sprint 7 102% 84%
Sprint 8 115% 62%
Sprint 9 100% 85%
Sprint 10 95% 41%
Sprint 11 112% 52%
Sprint 12 123% 69%
Sprint 13 114% 53%
Sprint 14 105% 85%
Sprint 15 98% 87%
Estes dados também estão apresentados na Figura 1. Para a métrica de dedicação
relativa, a média simples da amostra dos seis sprints iniciais (Processo A) foi de
104,67% com desvio padrão (𝑆 ) 0.064. Para a métrica de velocidade relativa, a média
simples da amostra do Processo A foi de 60.33% com desvio padrão (𝑆 ) 0.099. Para os
outros nove sprints (Processo B), a média simples da amostra de dedicação relativa foi
108.22% com desvio padrão (𝑆 ) de 0.092. A velocidade relativa para o Processo B
ficou na média de 68.67% com desvio padrão (𝑆 ) 0.174.
Figura 1. Gráfico das médias das métricas de dedicação e velocidade relativa ao longo
dos sprints
52
A Figura 2 ilustra a simulação de uma clusterização que destaca cada
componente e outlier:
Figura 2. Componentes e outliers dos parâmetros estudados

Cada componente, pontos dentro da linha pontilhada, corresponde a fatos
corriqueiros em projetos reais desenvolvidos em laboratórios de pesquisa em
computação inseridos em universidades. É de se esperar que os colaboradores (alunos)
dediquem próximo àquilo que foi acordado e que terminem atividades que eles disseram
que iriam terminar em um determinado período de tempo. O fato de dedicarem muito
mais que o esperado, não faz com que as atividades sejam terminadas da maneira
correta. Não é intuito do processo, exigir uma dedicação além da aceitável para
finalização das atividades. Então, quando existe uma dedicação próxima aos 100%, a
velocidade da equipe costuma ser satisfatória e acima da média. Quando a dedicação é
muito superior aos 100%, a velocidade relativa tende a cair, ou seja, pode estar
ocorrendo um mal entendido de como resolver as atividades ou as mesmas estão em
uma granularidade maior que deveriam ser.
Cada semestre possui quatro sprints e normalmente as avaliações das disciplinas
que os alunos cursam acontecem após o primeiro mês de aula e no último mês do
semestre. Por isso, é esperado que nestes momentos a dedicação ou a velocidade caiam.
Normalmente, para equipes maduras em seguir um tipo de processo em projetos
anteriores, o primeiro e terceiro sprints de um semestre tendem a ser mais produtivos
[Pereira et al., 2013]. Isto explica os outliers encontrados.
Para seguir com o protocolo da técnica de comparação de sistemas com
observações não pareadas, a diferença entre as médias simples foi calculada,
𝑥 - ̅̅̅
̅̅̅ 𝑥 , obtendo-se -3.55 para a dedicação e -8.34 para a velocidade. O desvio padrão
das diferenças também foi calculado:
53
2 2
𝑆 𝑆
𝑆=√ + →𝑆= . 9 𝑖 çã . 69 𝑣 𝑖
Após isto, os graus efetivos de liberdade foram calculados:

2 2 2
+
𝑉= − 2 → 𝑉 = 13 𝑖 çã 11 (𝑣 𝑖 )
1 2 2 1 2 2
−1∗ + −1∗
Verificamos através dos gráficos quantil-quantil que ambas as distribuições,

dedicação e velocidade relativas, são linearmente relacionadas, ou seja, os dados
seguem uma distribuição normal. A Tabela 2 e as Figuras 3 e 4 apresentam os dados e
os gráficos usados para verificar as distribuições normais.
Tabela 3. Dados das métricas de dedicação e velocidade relativas
Quantil-Quantil Dedicação Relativa Quanti-Quantil Velocidade Relativa

i fi Dedicação i fi Velocidade
1 0.040983607 0.95 1 0.040983607 0.41
2 0.106557377 0.98 2 0.106557377 0.48
3 0.172131148 0.99 3 0.172131148 0.48
4 0.237704918 0.99 4 0.237704918 0.52
5 0.303278689 1.00 5 0.303278689 0.53
6 0.368852459 1.00 6 0.368852459 0.61
7 0.43442623 1.05 7 0.43442623 0.62
8 0.5 1.05 8 0.5 0.67
9 0.56557377 1.12 9 0.56557377 0.69
10 0.631147541 1.12 10 0.631147541 0.69
11 0.696721311 1.12 11 0.696721311 0.69
12 0.762295082 1.13 12 0.762295082 0.84
13 0.827868852 1.14 13 0.827868852 0.85
14 0.893442623 1.15 14 0.893442623 0.85
15 0.959016393 1.23 15 0.959016393 0.87
54
Figura 3. Gráfico Quantil-Quantil para os dados de dedicação relativa
Figura 4. Gráfico Quantil-Quantil para os dados de velocidade relativa
55
Por isso, utilizamos o teste-t para calcular o intervalo de confiança:
̅̅̅ 𝑥 ∓
𝑥 − ̅̅̅ 𝛼 𝑆
[ − ;𝑣]
Considerando 90% de confiança o intervalo para a dedicação fica [-3.48; -3.62].

Para 90% de confiança o intervalo para a velocidade fica [-8.21; -8.46]. Como ambos os
intervalos não incluem zero, o sinal da diferença das médias indica que o Processo B, é
melhor significativamente que o Processo A em ambas as métricas. Ou seja, as práticas
envolvidas no Processo B que não estão presentes em A, favoreceram a melhoria do
processo seguido.
O objetivo de replicar um estudo de caso em engenharia de software ainda carece de um
conjunto de conceitos padronizados, terminologias, métodos adequados e em como
essas informações são compartilhadas. Magalhães et al., (2014) considera que esses
fatos podem ser considerados como impactos negativos sobre replicações de estudos em
nossa área. Para tratar esta situação, este estudo envolveu um esforço que apoiou a
observação de processos não pareada que pode ser replicada em outros projetos reais
executados por pequenas organizações que não possuem ainda um controle estatístico
de seus processos.
Observou-se que quando foca-se em práticas de gestão de projetos e depois em
práticas mais técnicas de engenharia de software, para adaptar à realidade de uma
organização, o direcionamento da adaptação quando guiado pelas métricas
organizacionais que os envolvidos querem atingir, influencia positivamente na
caminhada aos objetivos organizacionais. Embora o processo utilizado tenha seguido a
implantação de práticas de gerenciamento de projetos em primeiro lugar e em segundo
as práticas mais técnicas, os autores sugerem que esta mesma abordagem pode ser
utilizada com outros subconjuntos de práticas.
Percebeu-se que a adaptação das práticas cujo foco é o gerenciamento de
projetos, que foram aplicadas no primeiro momento do processo, também alcançou
resultados positivos. Conclui-se que subconjuntos dessas práticas podem sim ajudar na
organização geral de um projeto e na obtenção de uma garantia que uma determinada
ordem é seguida pela equipe. Ou seja, adaptar primeiramente práticas dessa natureza ou
garantir que elas sejam seguidas podem favorecer o início de uma melhoria de processo.
Considerando as práticas ágeis utilizadas no Processo A desta pesquisa, destaca-se as
seguintes características percebidas pelos membros da equipe: As reuniões diárias, de
demonstração e restrospectivas promovem a comunicação informal e constante entre a
equipe. O seguimento do burndown chart e a realização do poker do planejamento
deixam o planejamento e o controle das atividades e entregáveis do projeto transparente
para toda equipe. Usufluir de um scrum master, cliente interno, ambiente compartilhado
e um time pequeno, favorece a coesão da equipe durante a execução do projeto
deixando claro as diferentes responsabilidades.
Os resultados estatísticos obtidos validam a premissa que a inserção de práticas
de engenharia de software mais técnicas em um processo conhecido e bem seguido
pelos envolvidos induz a resultados melhores considerando o comprometimento e o
amadurecimento da equipe. Quando a equipe já estava acostumada com o Processo A e
gerando bons resultados de dedicação e velocidade relativas, as práticas focadas no
56
desenvolvimento e entrega serviram para elevar o nível da maturidade dela. O
desenvolvimento dirigido por comportamento promoveu melhor concepção do que
deveria ser feito pelos desenvolvedores e testadores, deixando o cliente mais confortável
na ideia que a equipe realmente havia entendido o que era para ser feito em um sprint.
Isso ocasionou mais assertividade nas validações feitas pelo cliente. Com isso, as
entregas foram mais frequentes, pois novas versões realmente eram desenvolvidas para
atender os valores esperados pelo cliente. Os testes automatizados de aceitação e
exploratórios auxiliaram na documentação do processo de desenvolvimento e em uma
melhor qualidade das versões entregues.
Entretanto, acredita-se que o momento do Processo B foi significativamente
melhor que o momento do Processo A, porém não seria possível aplicar as práticas do
Processo B sem antes ter aplicado e a equipe dominado as práticas do Processo A.
Conclui-se que houve da fato uma melhoria do processo de software. Isso foi validado
estatisticamente nesta pesquisa a medida que o processo, após maduro em práticas de
gerência de projetos, incorporou práticas técnicas de desenvolvimento. A observação
das métricas de dedicação e velocidade relativa mostraram isso.
É interessante considerar como limitação desta pesquisa a falta de mais
resultados entre métricas o que poderia viabilizar uma observação considerando a
distribuição z, o que poderia oferecer um grau maior de confiança. É possível realizar
como trabalho futuro a execução de diferentes cenários variando em cada um, práticas
ágeis diferentes. Com isso, seria possível através de um projeto , obter quais práticas
ágeis mais influenciam nas métricas coletadas e quais interações entre elas poderiam ser
mais incentivadas. Apesar de parecer pouco seis amostras de um momento do processo
e nove do segundo momento, cada uma é uma média de dez colaboradores geradas em
sprints de quatro ou cinco semanas. Ou seja, esses dados são referentes a quinze meses
de execução de projeto. Eles podem servir para a continuação do mesmo, indicando que
novas práticas técnicas podem ainda ser inseridas assim como novas métricas também
podem ser monitoradas. Também é possível utilizá-los como referências para projetos
futuros.
Referências
Chaves, N.L.S, Santos, G., Cerdeiral, C., Cabral M.L., Cabral, R., Schots, M., Nunew,
E., Rocha, A.R. (2011) “Lições Aprendidas em Implementações de Melhoria de
Processos em Organizações com Diferentes Características”. In: Workshop Anual do
MPS - WAMPS.
Fontana, R. M., Meyer Jr, V., Reinehra, S., Malucellia A. (2015). “Progressive
Outcomes: A Framework for Maturing in Agile Software Development”. The Journal
of Systems and Software pages 88–108.
Fuggetta, A. and Nitto, E. I. (2014). “Software Process”. In: Future of Software
Engineering (FOSE). Pages 1-12. Hyderabad, India — May 31 – June.
57
García-Mireles, Gabriel Alberto, et al. (2015) "Approaches to promote product quality
within software process improvement initiatives: a mapping study." Journal of
Systems and Software 103. p.150-166.
Gomes, A. F. (2014) “Agile – Desenvolvimento de Software com Entregas Frequentes e
Foco no Valor de Negócio”. Casa do Código.
Jain, R. (1991). “The Art of computer Systems Performance Analysis – Techniques for
Experimental Design, Measurement, Simulation and Modeling”. Wiley Professional
Computing.
Jalali, S. and Wholin, C. (2012) “Global Software Engineering and Agile Practices: A
Systematic Review”. Journal Software Evolution and Process. Vol.24. Pages 643–
659.
Kalus, G. and Khurmann, M. (2013) “Criteria for Software Process Tailoring: A
Systematic Review”. In: International Conference on Software and System Process
(ICSSP). Pages 171-180.
Magalhães, C. V. C., Silva, F. Q. B., Santos, R. E. S., Suassuna, M. (2014)
“Investigations about replication of empirical studies in software engineering: A
systematic mapping study” Information and Software Technology.
Magalhães, R. F., Gonçalves, T. G., Rocha, A. R., Santos, G., Oliveira, K. M. (2015).
“Instanciação e Execução das Atividades do Processo de Análise de Desempenho de
Processos de Software”. In: XIV Simpósio Brasileiro de Qualidade de Software
(SBQS).
Pereira, I. M., Tiago, G. S. C., Pereira, R. R. (2013) “Developing Innovative Software in
Brazilian Public Universities: Tailoring Agile Processes to the Reality of Research
and Development Laboratories”. In: 4th Annual International Conference on
Software Engineering & Applications (SEA).
Runeson, P., Host, M., Rainer, A., Regnell B. (2012) “Case Study Research in Software
Engineering: Guidelines and Examples”. John Wiley & Sons.
Santana, C., Queiroz, F., Vasconcelos, A., Gusmão, C. (2015) “Software Process
Improvement in Agile Software Development: A Systematic Literature Review” In:
41st Euromicro Conference on Software Engineering and Advanced Applications.
Svensson, R. B., Gorschek, T., Regnell, B., Torkar, R., Shahrokni, A. and Feldt, R.
(2012) “Quality Requirements in Industrial Practice—An Extended Interview Study
at Eleven Companies”. In: IEEE Transactions on Software Engineering, Vol. 38, Nº
4.
Turk, D., France, R., Rumpe, B. (2005) “Assumptions Under lying Agile Software
Development Processes” Journal of Database Management, Volume 16, No. 4, pp.
62-87.
58
Unterkalmsteiner, M., Gorschek, T., Moinul Islam, A. K. M., Cheng, C. K., Permadi R,
B., and Feldt, R. (2012) “Evaluation and Measurement of Software Process
Improvement - A Systematic Literature Review”. IEEE Transactions on Software
Engineering, Vol. 38, Nº. 2, March.
Weber, K, C., Macedo, M. M., de Oliveira, N. H. F., Barroso, E. T., Duarte, V. C.
(2015). “Impactos Socio-econômicos no Brasil do Modelo MPS-SW para Melhoria
de Processos de Software”. In: XIV Simpósio Brasileiro de Qualidade de Software
(SBQS).
Weber, K. C., Macedo, M. M., Duarte, V. C., Oliveira, N. H. F., Barroso, E. T. (2015).
“Pesquisa ‘MPS Cidadão’: Impactos Econômicos e Sociais da Melhoria de Processos
de Software no Brasil Usando o Modelo MPS-SW”, Softex.
Wholin, C., Runeson, O. Höst, M., Ohlsson, M. C.., Regnell, B., Wesslén, A. (2012)
Experimentation in Software Engineering. Springer. E-Book.
59
Utilização da Ferramenta Redmine para Auxiliar na
Obtenção da Certificação MPS-BR Nível F
Thiago Detomi1, Paulo Afonso Júnior2, Heitor Costa2
1
Laboratório de Projetos e Pesquisas - Universidade Federal de Lavras - MG - Brazil
2
Departamento de Ciência da Computação - Universidade Federal de Lavras - MG -
Brazil
thiago.detomi@lemaf.ufla.br, {pauloa.junior, heitor}@dcc.ufla.br
Resumo. Neste artigo, é relatada a experiência na utilização de uma ferramenta

de controle de projetos na implantação dos processos do nível F do MPS-BR em
uma empresa desenvolvedora de software. Para a escolha dessa ferramenta,
alguns critérios foram definidos para avaliar as ferramentas existentes, os quais
devem ser atendidos para ser considerada na implantação dos processos. Após
essa avaliação, a ferramenta Redmine foi selecionada e utilizada pela gestão de
projetos e pelas equipes de desenvolvimento de forma a auxiliar no processo de
implantação dos processos e da obtenção da certificação. A seleção foi mediante
a Redmine passar por uma análise crítica de viabilidade para entender suas
características e suas limitações dentro do contexto da organização. Os
resultados evidenciam os pontos fortes e limitações da Redmine quanto ao
processo de certificação MPS-BR nível F neste cenário.
Abstract. In this paper, we reported the experience of using a project control tool
in the implementation of MPS-BR level F processes in a software development
company. To choose this tool, we defined some criteria to evaluate the existing
tools, which must be considered in the implementation of the processes. After this
evaluation, Redmine tool was selected and used by project management and
development teams to assist in the process implementation and certification
process. The selection was through Redmine undergo a critical analysis of
feasibility to understand its characteristics and its limitations within the context
of the organization. The results highlights Redmine's strengths and limitations
regarding the MPS-BR level F certification process in this scenario.
1. Introdução
As mudanças estão cada vez mais frequentes nos ambientes corporativos, motivando as
empresas a melhorarem seus processos de forma a maximizar sua capacidade produtiva.
Dessa forma, as certificações mostram-se cada vez mais presentes nas empresas, tanto
pelos benefícios esperados quanto pelo desafio de melhorar seus processos em diversos
aspectos, especialmente no setor de Tecnologia da Informação, na qual certificações são
cada vez mais necessárias. Dentro das diversas certificações de melhoria de processos
possíveis para empresas desse setor, destacam-se os modelos de maturidade.
60
Os modelos de maturidade oferecem informações estratégicas para avaliar o
desempenho dos processos organizacionais como uma forma de auxiliar a gestão dos
projetos na empresa. Os modelos de maturidade em gestão de projetos servem como uma
estrutura para comparação entre práticas atuais exercidas por uma organização e o que
são consideradas como melhores práticas de gestão de projetos pelo mercado [Ibbs;
Kwak, 2002]. Os modelos e maturidade em gestão de projetos consistem em um arquétipo
de crescimento que estabelece estágios pré-definidos, permitindo autoavaliações e
aperfeiçoamentos [Prado, 2008]. São exemplos de modelos de maturidade Capability
Maturity Model Integration (CMMI), Project Management Maturity Model (PMMM),
Organizational Project Management Maturity Model (OPM3) e Melhoria de Processo de
Software Brasileiro (MPS-BR), abordado neste trabalho.
MPS-BR é um programa criado pela SOFTEX com o apoio do Ministério da
Ciência e Tecnologia, Inovações e Comunicações (MCTIC) iniciado em 2003, cujo
objetivo é melhorar a capacidade de desenvolvimento de software, serviços e práticas de
gestão na indústria de Tecnologia da Informação (SOFTEX, 2016). O modelo MPS-BR
está em conformidade com as normas internacionais ISO/IEC 122007 e ISO/IEC 330xx
e o modelo CMMI, adequando-se à realidade das empresas brasileiras [Koscianski;
Soares, 2007]. Esse programa baseia-se nos conceitos de maturidade e capacidade de
processo para a avaliação e melhoria da qualidade e produtividade de software e serviços
correlatos e para a melhoria da qualidade e produtividade dos serviços prestados. Esse
programa possui quatro componentes: i) Modelo de Referência MPS para Software (MR-
MPS-SW); ii) Modelo de Referência MPS para Serviços (MR-MPS-SV); iii) Método de
Avaliação (MA-MPS); e iv) Modelo de Negócio para Melhoria de Processo de Software
e Serviços [SOFTEX, 2016].
No processo de implantação dos processos de MPS-BR em uma empresa de
software, sobretudo em uma empresa que utiliza métodos ágeis no desenvolvimento, é
comum a utilização de ferramentas para auxiliar no processo de gerenciamento dos
projetos. Neste trabalho, o objetivo é apresentar uma análise crítica da ferramenta
Redmine1 durante o processo de certificação MPS-BR Nível F na empresa GT4W2
(Geotechnology for Web), de forma a avaliar a sua efetividade durante e após o processo.
O restante do artigo está organizado da seguinte forma. A necessidade de realizar
a adequação na empresa por utilizar Scrum e desejar a implantação de processos de
qualidade do MPS-BR no desenvolvimento de sistemas de software é apresentada na
Seção 2. A escolha de uma ferramenta computacional (apoio computacional) para apoiar
o controle de projetos é destacada na Seção 3. A utilização da ferramenta escolhida -
Redmine - é mostrada na Seção 4. Resultados obtidos com a implantação são discutidos
na Seção 5. Resumo de alguns trabalhos relacionados é apresentado na Seção 6.
Considerações finais são apresentados na Seção 7.
2. MPS-BR Nível F em Conjunto com o Scrum na GT4W

A GT4W é uma empresa de Tecnologia da Informação sediada em Lavras/MG, mas teve
seu primeiro contato com o processo de implantação do MPS-BR em Belo Horizonte/MG.
A empresa tem como principal produto projetos de desenvolvimento de sistemas de
software para o setor público. A empresa é parceira do Laboratório de Estudos e Projetos
1
http://www.redmine.org
2
http://www.gt4w.com.br/
61
em Manejo Florestal (LEMAF) da Universidade Federal de Lavras (UFLA) em projetos
para controle e monitoramento ambiental em âmbito federal e estadual, que utilizam como
base o Georreferenciamento e a metodologia ágil Scrum para controle de seus projetos,
possuindo equipes alocadas na UFLA. Scrum é uma metodologia ágil utilizada para
gerenciar o desenvolvimento de produtos complexos criado na década de 90 [Schwaber;
Sutherland, 2016], sendo um framework no qual as pessoas podem empregar diversas
técnicas e processos.
O Scrum possui as seguintes práticas e ritos: i) Product Backlog; ii) Sprint
Planning; iii) Sprint; iv) Daily Stand-up Meeting; iv) Sprint Review; e v) Sprint
Retrospective. Além disso, possui três papéis principais: i) Product Owner; ii) Scrum
Master; e iii) Time de desenvolvedores. O framework (Figura 1) tem início com a
definição do Product Backlog, que contém a lista priorizada e refinada dos requisitos do
produto, sendo de responsabilidade do Product Owner o seu gerenciamento. Definido o
Product Backlog, o Product Owner e o Time de desenvolvedores, em uma reunião
chamada Sprint Planning, definem e estimam o que pode ser realizado em uma iteração
com um tempo definido, chamada Sprint.
Figura 1 - Scrum Tradicional
Durante o progresso da Sprint, é realizada uma reunião diária entre o Time de

desenvolvedores, chamada Daily Stand-up Meeting, na qual cada desenvolvedor reporta
em que está trabalhando e se há algum impedimento que precisa ser tratado. Ao final da
iteração, que normalmente leva de 2 a 4 semanas, é realizada a Sprint Review, na qual o
Time de desenvolvedores apresenta o resultado da Sprint para o Product Owner que
informa se o resultado foi ou não favorável.
Ao final do processo, é feita a Sprint Retrospective, uma reunião reflexiva entre
os desenvolvedores para analisar os pontos positivos e o que pode ser melhorado nas
próximas iterações. O processo retorna para a Sprint Planning, quando uma nova iteração
é planejada, até o produto estar funcional. O Scrum Master é responsável por garantir que
esse processo ocorra e remover qualquer impedimento de um membro do Time de
desenvolvedores.
Para acompanhar o trabalho sendo desenvolvido na iteração (chamado na
literatura de Work in Progress - WIP), é utilizada uma ferramenta chamada kanban que
exibe a lista das atividades necessárias, apresentadas em um quadro, para alcançar o
objetivo da Sprint. Esse quadro é dividido em colunas, por exemplo, listando as atividades
a fazer, as atividades sendo trabalhadas no momento e as atividades finalizadas (podendo
ser personalizado de acordo com a cultura de cada equipe, colocando mais colunas). O
kanban é atualizado em tempo real, à medida que o Time de desenvolvedores realiza as
atividades, movendo as atividades de colunas.
62
A GT4W emprega uma utilização customizada do Scrum em seus projetos e seus
resultados mostraram-se satisfatórios no decorrer do tempo. Porém, a necessidade do
mercado, aliada ao crescimento da empresa, convenceu a gestão executiva a buscar a
certificação MPS-BR para melhorar seus processos e ser um diferencial competitivo para
a empresa, uma vez que grande parte de seus projetos são originados de licitações
provenientes do setor público.
A customização do Scrum na GT4W possui algumas particularidades. Antes de
iniciar o projeto, o Gerente de Projetos em conjunto com o Product Owner elabora o
Documento de Visão do projeto, cujo objetivo é nortear a gestão quanto aos objetivos e
ao escopo do projeto a ser desenvolvido, fornecendo requisitos macros que o projeto deve
atender, do ponto de vista funcional e não-funcional. De posse do Documento de Visão,
o Product Owner refina os requisitos macro em forma de histórias de usuários para serem
executadas nas sprints. Havia também um papel adicional na equipe, chamado Líder
Técnico, sendo um desenvolvedor mais experiente que orienta os menos experientes e
lida com tarefas mais complexas. Outro ponto importante a destacar é o fato de o Scrum
Master fazer parte do Time de desenvolvedores, ao contrário do Scrum tradicional, cuja
figura do Scrum Master fica alocada integralmente em remover impedimentos e garantir
os ritos do framework.
Uma instituição implementadora foi contratada para acompanhar o andamento do
processo e constatou que a empresa possuía certa organização e padronização em seus
processos, sendo aconselhada a buscar o Nível F, implantando os processos referentes aos
níveis G e F do MPS-BR. O nível G (Parcialmente Gerenciado) possui dois processos: i)
Gerência de Requisitos (GRE); e ii) Gerência de Projetos (GPR). O nível F (Gerenciado)
possui cinco processos: i) Aquisição (AQU); ii) Gerência da Configuração (GCO); iii)
Garantia da Qualidade (GQA); iv) Gerência de Portfolio de Projetos (GPP); e v) Medição
(MED). O processo de Aquisição não foi considerado no escopo da avaliação, pois a
GT4W se enquadra como uma fábrica de software.
3. Seleção da Redmine para Apoiar o Controle de Projetos

Com o advento da necessidade de implantar o MPS-BR na empresa e a definição do nível
F como objetivo primário, foi recomendada pelo consultor responsável da instituição
implementadora, a utilização de um sistema computacional (apoio computacional) para
ajudar a controlar os projetos para atendimento a algumas exigências da implantação, por
exemplo, a rastreabilidade bidirecional entre requisitos e atividades. O controle era
realizado utilizando planilhas personalizadas para cada equipe sem padronização. Diante
dessa necessidade, a comissão formada pelos gestores responsáveis e a instituição
implementadora estabeleceram, baseados na experiência prévia da instituição
implementadora em certificações anteriores, um conjunto de nove critérios categorizados
de acordo com a necessidade para a implantação da certificação que a ferramenta deveria
atender, sendo eles:
 Integração com o Git: a empresa utiliza o Git para controle de versões e de releases
dos sistemas desenvolvidos, sendo fundamental a integração com os repositórios de
forma a ser possível acessar o código fonte gerado no projeto;
 Open source: a ferramenta deve possuir código aberto para futuras customizações pela
equipe de desenvolvimento;
 Rastreabilidade bidirecional de requisitos: permitir identificar cada item
desenvolvido presente no Documento de Visão do projeto (mais alto nível de
63
abstração), as histórias de usuários do Product Backlog associadas ao item de visão,
as tarefas associadas às histórias de usuários e os commits no repositório e vice-versa,
possibilitando navegar entre os diversos níveis de atividades, fornecendo ampla
visibilidade do projeto;
 Possibilidade de trabalhar com Scrum: Scrum é utilizado pelas equipes de
desenvolvimento;
 Histórico de atualização de tarefas: manter um histórico que permitisse visualizar
quem alterou o estado da atividade e quando foi realizada a alteração;
 Controle da equipe: possibilidade de configurar a equipe, gerenciar membros de
projetos e permissões de acesso, de forma a limitar o acesso a determinadas áreas do
sistema para usuários;
 Autenticação de usuários: login utilizando uma credencial para acesso ao sistema;
 Gratuita: GT4W é uma microempresa, não tendo recursos para investir em uma
ferramenta proprietária;
 Self-hosted: a ferramenta deveria ser implantada nos servidores locais da empresa, não
dependendo de serviços em nuvem para seu funcionamento. Essa não dependência é
explícita em alguns contratos com clientes.
Esses critérios foram categorizados de acordo com seu grau de relevância para a
certificação (Tabela 1), sendo: i) 1: pouco relevante; ii) 2: relevante; e iii) 3: muito
relevante. O grau de relevância “pouco relevante” é considerado pouco importante, não
inviabilizando a utilização da ferramenta, caso não seja atendido. O grau de relevância
“relevante” é de relevância média, considerado importante, mas não chega a inviabilizar
o uso da ferramenta, caso não seja atendido. O grau de relevância “muito relevante” é
considerado muito importante, que inviabiliza o uso da ferramenta, caso não seja
atendido. Assim, os critérios Integração com o Git, Rastreabilidade bidirecional de
requisitos, Possibilidade de trabalhar com Scrum, Gratuita e Self-hosted são
considerados muito relevantes. Por outro lado, o critério Open source e Histórico de
atualização de tarefas são considerados pouco relevantes. Os dois critérios restantes,
Controle da equipe e Autenticação de usuários, são considerados relevantes.
Tabela 1. Critérios e Grau de Relevância para a Seleção da Ferramenta de Controle de

Projetos
ID Critério Grau de Relevância
1 Integração com o Git 3
2 Open source 1
3 Rastreabilidade bidirecional de requisitos 3
4 Possibilidade de trabalhar com Scrum 3
5 Histórico de atualização de tarefas 1
6 Controle da equipe 2
7 Autenticação de usuários 2
8 Gratuita 3
9 Self-hosted 3
Uma vez definida a lista de critérios, foi feita uma pesquisa para identificar
possíveis ferramentas computacionais (apoio computacional) candidatas a serem
64
utilizadas para apoiar no processo de certificação baseada nessa lista. As ferramentas
encontradas foram:
 JIRA é amplamente conhecida na gestão ágil de projetos, mas foi descartada pelo fato
de não atender o critério 8 (Gratuita) e inclusive possui alto custo para implantação e
customização;
 Open Project é uma ferramenta para controle de projetos que possui uma versão
gratuita, mas foi descartada pelos envolvidos não possuírem contato prévio com ela,
ocasionando na necessidade de esforço (tempo) para estudo do seu comportamento
prático. Dessa forma, a sua utilização tornou-se inviável por conta do curto tempo entre
a implantação da ferramenta nos projetos e a avaliação final da certificação;
 Trello consiste em uma ferramenta online para criação e controle de kanbans. Foram
realizados testes práticos com essa ferramenta anteriormente, porém a Rastreabilidade
bidirecional de requisitos (critério 3) não se mostrou ineficiente, apesar dos plug-ins
existentes para a ferramenta. Além disso, Trello não é Self-hosted (critério 9), sendo
descartada;
 Redmine é uma aplicação web para gerenciamento de projetos escrita utilizando o
framework Ruby on Rails. Com as pesquisas realizadas na Internet e em fóruns de
discussão, essa ferramenta apresentou bons resultados baseados nos critérios e nos
graus de relevância definidos. O principal ponto que contribuiu para a sua escolha foi
a indicação da instituição implementadora que acompanhava a implantação dos
processos, pois o consultor responsável havia tido contato com a ferramenta em
processos de certificação anteriores, atingindo seu o objetivo.
Selecionada a ferramenta, três equipes de desenvolvimento foram selecionadas
para executarem um piloto com a Redmine, cujo objetivo era analisá-la na prática,
consistindo incialmente em utilizá-la em conjunto com as planilhas que faziam parte da
cultura da empresa, a fim de evitar possíveis perdas de informações e mitigar o impacto
das mudanças.
4. Utilização da Redmine nos Projetos

Para a certificação MPS-BR Nível F, a empresa precisava apresentar quatro projetos
candidatos à avaliação, dois finalizados e dois em andamento. Os projetos seriam
avaliados quanto ao escopo da avaliação do Nível F: i) Gerência de Projetos; ii) Gerência
de Requisitos; iii) Gerência da Configuração; iv) Garantia da Qualidade; v) Gerência de
Portfolio de Projetos; e vi) Medição. A Redmine foi selecionada para auxiliar na Gerência
de Projetos e na Gerência de Requisitos.
Durante o período da certificação, quatro projetos haviam sido finalizados
seguindo as recomendações presentes no MPS-BR e três projetos estavam sendo iniciados
por três equipes diferentes alocadas no LEMAF/UFLA, em Lavras, Minas Gerais. Os
projetos estariam finalizados no período da avaliação final, sendo selecionados como
projetos candidatos aqueles com os melhores resultados baseado em análises pela equipe
de implantação em conjunto com a instituição implementadora contratada. Para os
projetos iniciantes, foi proposta a utilização da Redmine para fins de experiência e de
feedback, de forma a avaliar a sua efetividade no processo estabelecido.
Uma vez definidas as equipes e os projetos que participariam da experiência com
a Redmine, foram realizadas reuniões com a instituição implementadora para definir
como seria a estrutura da Redmine. Nessas reuniões, foram discutidos diversos aspectos
65
de como a ferramenta seria utilizada para atender aos requisitos do MPS-BR. Dentre os
vários pontos, os mais importantes foram a estruturação dos requisitos de projeto, a
rastreabilidade bidirecional de requisitos e o acesso ao repositório Git.
Inicialmente, para adaptar-se ao contexto da organização, foi necessário inserir
uma extensão na Redmine que permitia trabalhar com metodologias ágeis. Essa extensão
permitia a utilização do Kanban e as demais características do Scrum, como a criação de
Product Backlog e Sprints. A Redmine precisou ser configurada quanto ao tipo das
tarefas, de forma a adequar-se ao processo, podendo adicionar tarefas dos seguintes tipos
ao Product Backlog dos projetos:
 Itens de visão: tipo de tarefa que faz referência aos itens macro destacados no
documento de visão do projeto;
 Histórias de usuário: tipo de tarefa que reflete uma função do sistema. Um conjunto
de histórias de usuários são vinculadas a um item de visão;
 Atividade: tipo de tarefa que detalha o que será necessário para construir uma história
de usuário. Um conjunto de tarefas é vinculado a uma história de usuário;
 Bugs: tipo de tarefa que consiste em problemas encontrados em determinada história
de usuário durante o andamento da Sprint, relatado pelo tester.
Após os tipos de tarefas do projeto terem sido configurados, foi necessário
configurar os papéis dos usuários do sistema. A Redmine contém os papéis padrão do
Scrum, tais como, Scrum Master, Product Owner e Time. Mas, para adequação ao
processo definido, foi necessário incluir os papéis “Líder Técnico” e “Analistas de
Qualidade”, atribuídos aos respectivos responsáveis pelas funções. As Sprints foram
configuradas com 10 dias úteis de desenvolvimento (tempo médio da iteração, empregado
pela organização).
Em seguida, os projetos em andamento deveriam ser cadastrados pelo respectivo
Product Owner de cada equipe selecionada, cabendo a ele a tarefa de cadastrar sua equipe
e o Backlog do projeto. A estrutura da configuração dos projetos na Redmine é
apresentada na Figura 2. Os repositórios Git eram adicionados ao projeto na Redmine
pela equipe de infraestrutura da empresa. Como a Redmine não permite criar uma
referência para o repositório Git, sua atualização deveria ser realizada com um job
implementado pela própria equipe de infraestrutura, que atualizava diariamente os
repositórios dos projetos, excluindo as versões anteriores e armazenando apenas a versão
mais atual do repositório do projeto.
Figura 2 - Estrutura dos Projetos na Redmine
66
As equipes envolvidas foram treinadas pela equipe de qualidade e pelo Gerente
de Projetos antes de iniciar de fato a utilização da Redmine. O treinamento consistiu em
uma apresentação da ferramenta juntamente com sua política de uso e os padrões de
nomenclaturas e de projeto. Ainda nesse treinamento, os desenvolvedores foram
orientados a identificar a atividade sendo trabalhada utilizando comentários nos commits
realizados ao finalizar determinada atividade. Para fins de identificação de tarefas no Git,
a Redmine exige informação do caractere “#” seguido do código identificador (id) da
atividade trabalhada no comentário do commit, estabelecendo um vínculo entre a tarefa e
o commit no repositório. Dessa forma, o critério Rastreabilidade bidirecional de
requisitos (Seção 3) é atendido.
Após esse treinamento, as equipes foram capazes de iniciar a utilização da
ferramenta Redmine em seus projetos. Foi aconselhado manter o uso das planilhas em
paralelo a essa ferramenta no primeiro momento, de forma que o impacto nas equipes
fosse mitigado, visto que as planilhas eram utilizadas desde os primeiros projetos da
empresa, sendo a primeira vez que uma ferramenta estava sendo implantada para controle
dos projetos. O fluxo realizado para a implantação da Redmine para ser utilizada pelas
equipes é apresentado na Figura 3.
Figura 3 - Passos para Implantação do Redmine
Em um primeiro momento, houve certa resistência quanto ao uso da Redmine

pelos desenvolvedores, com a justificativa de que ela era ineficiente em alguns aspectos,
como a impossibilidade de vincular mais de uma pessoa a uma tarefa (característica
comum no Time de desenvolvedores quando se desenvolve em par). Outro ponto
levantado pelo Time de desenvolvedores está relacionado com a estimativa das histórias
de usuários, que a ferramenta exigia uma estimativa em horas de desenvolvimento, algo
que não condizia com a realidade do Time de desenvolvedores, pois utilizava a escala de
Fibonacci para estimar as histórias de usuários que entram na Sprint. Essa é uma
característica comum no Scrum, empregada por grande parte das equipes da empresa.
Para relatar casos em que a ferramenta não se adaptava ao processo de desenvolvimento
da equipe, foi solicitado às equipes envolvidas que relatassem (via e-mail) aos
responsáveis pela certificação para que alternativas fossem adotadas. Com a realização
das Sprints posteriores, a resistência foi menor.
Ao longo do processo de certificação, cada projeto teve a duração média de três
iterações. Alguns projetos foram finalizados após a instituição avaliadora auditar os
projetos, sendo considerados (auditados) como projetos em andamento.
67
5. Resultados Obtidos
Durante a utilização da Redmine pelas equipes envolvidas no processo de implantação da
qualidade, foi possível ter uma visão mais ampla dos projetos em execução, algo que se
tornava ineficiente quando as planilhas eram a principal forma de controle utilizada. O
desempenho dessa ferramenta foi medido com base nos critérios descritos na Seção 3, os
quais foram analisados quanto à sua efetividade no processo, atendendo, não atendendo
ou atendendo parcialmente o critério em questão.
O critério 1 (Integração com o Git) foi considerado de alto grau de relevância para
a obtenção da certificação, o qual a Redmine atendeu parcialmente, de forma a conseguir
ser efetiva para a instituição avaliadora quanto ao acesso ao repositório, mas, do ponto de
vista de infraestrutura, mostrou-se tecnicamente inviável. Isso ocorreu, pois a Redmine
exige que os repositórios Git sejam clonados e inseridos em seu diretório para serem
acessados, sendo necessário ter um espaço cada vez maior no storage, à medida que novos
projetos são criados. Além disso, foi necessário criar uma rotina de atualização para
realizar a cópia do repositório diariamente na Redmine, dependendo constantemente da
intervenção da equipe de infraestrutura para dar suporte à ferramenta. Isso tornava um
procedimento de alto custo para a empresa, que conta apenas com dois analistas de
infraestrutura e uma alta quantidade de projetos, além do risco de informações sensíveis
se perderem por causa do espaço limitado nos storages disponíveis. O modelo ideal seria
a ferramenta ter uma referência para os repositórios dos projetos, de forma a não ser
necessário criar cópias adicionais ou rotinas para substituir os repositórios por versões
mais atualizadas.
O critério 2 (Open source), de baixa relevância, está relacionado à licença da
ferramenta, que preferencialmente deveria ser de código aberto, para que melhorias
futuras pudessem ser propostas pelas equipes de desenvolvimento e pela equipe de
infraestrutura. A Redmine atendeu esse critério por ser de código aberto, escrita utilizando
o framework Ruby on Rails publicada sob a licença GPL3. É importante frisar que, no
período da certificação, não havia desenvolvedores na empresa com conhecimento pleno
em Ruby on Rails, mas poderia ser cogitada a contratação de alguém com o perfil para
melhorar a ferramenta.
O critério 3 (Rastreabilidade bidirecional de requisitos) é um dos critérios de
maior grau de relevância para o processo de certificação, sendo considerado crítico pela
instituição implementadora e profundamente analisado durante a auditoria da instituição
avaliadora. Com esse critério atendido, para o MPS-BR Nível F, pode-se identificar cada
item desenvolvido no projeto, desde seu nível mais abstrato até a atividadea concluída
pelo desenvolvedor na Sprint e vice-versa. Em linhas gerais, acessando um item de visão,
deveria ser possível acessar cada história de usuário associada àquele item. Acessando
uma história de usuário, deveria ser possível acessar cada tarefa associada àquela história
de usuário e, em cada tarefa, deveria ser possível acessar o commit realizado pelo
desenvolvedor relacionado àquela tarefa e vice-versa (Figura 4). Esse critério foi atendido
parcialmente, pois a Redmine não faz a vinculação do código gerado pelo commit dos
desenvolvedores armazenado nos repositórios do projeto no Gitlab4 da empresa e o
projeto da Redmine. Para atender esse critério, o Product Owner adicionava aos
comentários de cada atividade os comentários dos commits realizados pelos
3
Gnu Genreal Public Licence v2 - http://www.gnu.org/licenses/old-licenses/gpl-2.0.html.
4
Gerenciador de repositório de software - https://about.gitlab.com
68
desenvolvedores e cabia ao gerente de projetos gerar relatórios periódicos baseados
nesses comentários dos commits. Isso permitia criar um mapeamento que associava a
atividade realizada a seu respectivo commit por meio do código identificador da atividade
da Redmine no comentário realizado, conforme orientado no treinamento realizado.
Figura 4 - Rastreabilidade Bidirecional de Requisitos
O Scrum é adotado pela GT4W no desenvolvimento de software, então o critério

4 (Possibilidade de trabalhar com Scrum) foi elencado pelos envolvidos e atribuído alto
grau de relevância. Assim, a Redmine atendeu esse critério, pois, apesar de não possuir o
framework Scrum como padrão, existem extensões criadas pela comunidade que
permitem a utilização de Scrum. No processo para obtenção da certificação, foi utilizado
o plug-in Redmine Plugin Scrum5 que permitiu adaptar a Redmine ao Scrum. Mesmo
com a utilização desse plug-in, foi necessário configurar a ferramenta por causa da
customização do Scrum empregado pela empresa, sendo necessário criar alguns papéis
adicionais (Seção 2). Um feedback negativo das equipes quanto a esse critério foi a
impossibilidade de utilizar estimativa por pontos de complexidade nas histórias de
usuários, sendo a Redmine restrita à estimativa por horas de desenvolvimento.
O critério 5 (Histórico de atualização de tarefas) possui baixo grau de relevância,
não inviabilizando a utilização da ferramenta. Esse critério foi atendido pela Redmine
pois mantém a informação de quem moveu a atividade no kanban, bem como a data e o
horário que seu estado foi alterado. Isso permitiu saber exatamente quais membros da
equipe trabalharam em quais atividades.
O critério 6 (Controle da equipe) também foi levantado pelos envolvidos com
médio grau de relevância. Esse critério consiste no controle da equipe do projeto, como
o cadastro dos usuários e a atribuição de perfis e de permissões. A Redmine atendeu, pois
possui configurações de perfis (que apresentavam com os perfis padrão de Scrum diante
da instalação do plug-in) e de permissões de acesso que podem limitar ou conceder o
acesso a determinada ação mediante à permissão relacionada. No processo de obtenção
da certificação foi importante o cadastro de novos perfis para membros da equipe, tal
como o Líder Técnico e o Tester, bem como as permissões relacionadas.
O critério 7 (Autenticação de usuários), de média relevância, foi atendido pela
Redmine por fornecer login e senha para cada usuário que utilizar a ferramenta. Dessa
forma, a Redmine “exigia” do membro da equipe ou gerente de projetos sua respectiva
5
https://redmine.ociotec.com/projects/redmine-plugin-scrum.
69
credencial, formada pelo e-mail corporativo e uma senha de acesso, criada no momento
do cadastro.
O critério 8 (Gratuita) foi atendido por a Redmine ser gratuita. O fato de ser
gratuita foi levantado por ser uma ferramenta piloto na organização, podendo adequar ou
não ao processo. Assim, para evitar custos com ferramentas que poderiam ser descartadas,
optou-se pela utilização de ferramentas gratuitas.
O critério 9 (Self-hosted) foi considerado de alto grau de relevância, sendo
necessária a hospedagem internamente na empresa. Esse critério exige que a ferramenta
esteja alocada nos servidores internos da empresa, sem a necessidade da utilização de
nuvem para acessar o conteúdo dos projetos. Esse critério foi definido por questões de
segurança e disponibilidade, uma vez que o acesso à Internet não é 100% estável no
ambiente organizacional. A Redmine foi hospedada em um servidor interno dedicado na
rede interna da organização, atendendo esse critério.
Um resumo dos critérios elaborados e se eles foram atendidos, não atendidos ou
atendidos parcialmente pela ferramenta Redmine é apresentado na Tabela 2.
Tabela 2. Atendimento aos Critérios

Grau de
ID Critério Atendimento
Relevância
1 Integração com o Git 3 Atendeu parcialmente
2 Open source 1 Atendeu
3 Rastreabilidade bidirecional de requisitos 3 Atendeu parcialmente
4 Possibilidade de trabalhar com Scrum 3 Atendeu
5 Histórico de atualização de tarefas 1 Atendeu
6 Controle da equipe 2 Atendeu
7 Autenticação de usuários 2 Atendeu
8 Gratuita 3 Atendeu
9 Self-hosted 3 Atendeu
Como descrito, a Redmine não atendeu totalmente todos os critérios, mas, para os
pontos que não atendeu com eficácia, foram criados mecanismos que permitiram sua
utilização durante o processo de certificação, atingindo desempenho satisfatório no
processo de obtenção da certificação. A gestão de projetos passou a adotar a Redmine em
conjunto com o Microsoft Project® como fonte de controle dos projetos, automatizando
seu processo, trazendo como benefícios a agilidade aos ativos dos projetos, o controle de
acesso, a geração de relatórios e a rastreabilidade de requisitos e tornando a gestão de
projetos mais eficaz.
O objetivo macro da utilização da Redmine foi atingido e a certificação MPS-BR
Nível F foi obtida com êxito pela empresa, sendo os processos auditados pela instituição
avaliadora da SOFTEX e o resultado auditado posteriormente para a confirmação da
certificação.
6. Trabalhos Relacionados
Há estudos anteriores a este sobre a implantações da certificação MPS.BR em empresas
que necessitaram do apoio de ferramentas para serem bem-sucedidas na implantação dos
70
processos. Em um dos trabalhos [Catunda et al., 2011], os autores destacam a implantação
dos processos do nível F do MPS.BR em uma empresa que desejava organizar melhor
seu processo de desenvolvimento de softwares. Nesse trabalho, é possível verificar a
metodologia utilizada para implantar os processos necessários para o nível F em conjunto
com o Scrum. Também, foi elencada a necessidade de utilizar a uma ferramenta para a
gerência de projetos, sendo utilizada Redmine em conjunto com o Microsoft Word® e o
Microsoft Project®. Como resultado, foi destacado que, sem o apoio de ferramentas
automatizadas, o Scrum pode ser prejudicado ao implementar os processos do MPS.BR
e a ferramenta Redmine permitiu mais agilidade.
Em outro trabalho [França et al., 2009], foi relatada a utilização da ferramenta
automatizada WebAPSEE na implementação dos processos do nível G do MPS.BR.
Nesse trabalho, os autores descreveram a experiência sob o ponto de vista da utilização
da WebAPSEE para auxiliar o processo de implantação em um órgão ligado à reitoria da
Universidade Federal do Pará (UFPA). Os autores destacam que a ferramenta permitiu a
modelagem e a execução dos processos de software de forma flexível, permitindo
implantar os processos de Gestão de Projetos (GPR) e Gestão de Requisitos (GRE),
obtendo a certificação MPS.BR nível G. Como lições aprendidas, foram ressaltadas
situações ocorridas durante a implantação dos processos.
Em mais um trabalho [Oliveira et al., 2010], foi realizado um estudo cujo objetivo
foi a criação do projeto Spider, que consiste em uma suíte de ferramentas livres para
apoiar a implantação dos processos de níveis G, F e E do MPS.BR. Esse projeto tem como
justificativas a alta demanda por profissionais e empresas qualificados, a crescente
quantidade de terceirizações envolvendo empresas nacionais e internacionais, os
resultados obtidos por algumas empresas públicas e privadas do setor de Tecnologia da
Informação no estado do Pará, entre outras. O trabalho elencou, dentre uma série de
resultados, o levantamento de ferramentas livres e open source para apoio aos processos
de Gerência de Projetos, Gerência de Requisitos, Gerência de Configuração e Gerência
de Portfólio; o desenvolvimento de ferramentas para apoio a estimativas de projetos,
quanto ao tamanho e custo dos mesmos.
Este trabalho tem como foco a análise da ferramenta Redmine na prática,
juntamente com a descrição de seu modo de utilização como apoio à implantação dos
processos do nível F do MPS.BR em uma empresa cuja principal linha de produtos é
relacionada a projetos de desenvolvimento de sistemas de software de gestão ambiental
que utilizam como base o Georreferenciamento utilizando Scrum customizado para
atender aos processos organizacionais. A empresa em questão possui algumas
particularidades como a execução de múltiplos projetos simultaneamente e as
necessidades descritas nos critérios na Seção 2 deste artigo.
Este trabalho explorou o desempenho da ferramenta Redmine durante o processo de
implantação de processos para obtenção da certificação MPS-BR Nível F na empresa
GT4W. Em reuniões de consultorias, a comissão responsável, formada pela instituição
implementadora e a diretoria executiva elaboraram nove critérios a serem atendidos pela
ferramenta e, posteriormente, avaliadas na prática, analisando se ela atendeu, atendeu
parcialmente ou não atendeu os critérios.
71
No que concerne à utilização do Scrum, a ferramenta mostrou-se eficiente durante
a implantação, mas, em seguida, foi identificada a necessidade de trabalhar com múltiplos
projetos em uma mesma Sprint na equipe, sendo uma característica que ainda não existe
na Redmine. Isso inviabilizou a empresa a manter a utilização da ferramenta como fonte
única de controle dos projetos. Outro ponto que contribuiu para a decisão de descontinuar
a utilização de Redmine na empresa foi a integração com o Git, uma vez que a integração
exige fazer uma cópia dos repositórios no diretório da Redmine para serem referenciados
no projeto. Assim, há a necessidade de cada vez mais ter um espaço maior no storage à
medida que novos projetos são criados, tornando inviável do ponto de vista de
infraestrutura ao longo do tempo, uma vez que os repositórios são alocados localmente.
Do ponto de vista das equipes que utilizaram a ferramenta, o feedback em geral
foi positivo, sendo relatados alguns problemas de adaptação, tais como, a impossibilidade
de mais de uma pessoa estar associada a uma tarefa e a recomendação de, no primeiro
momento, atualizar o andamento das atividades nas planilhas e na Redmine. Outro ponto
criticado pelos desenvolvedores está relacionado com a estimativa das atividades, em que
a equipe tinha como costume estimar com base em pontos de complexidade e a Redmine
exige que a estimativa seja informada em horas de trabalho.
Durante o processo de implantação, ocorreu também uma falha no storage da
Redmine que ocasionou a perda de informações de projetos (Backlog e o histórico de
atualização das tarefas). Mais tarde, foi identificada que a causa do problema estava
relacionada à instabilidade do ambiente no qual a ferramenta estava hospedada. Após o
episódio, políticas de backups diários foram implementadas pela equipe de infraestrutura
para evitar problemas futuros.
Um aspecto que deve ser considerado é o fato da Redmine ser uma ferramenta
open source. Desenvolvedores podem criar ou alterar extensões e plug-ins para adaptá-la
ao ambiente da organização, sendo necessário desenvolvedores com conhecimentos em
Ruby on Rails. Assim, pode ser que alguns pontos negativos citados tenham sido
resolvidos pela comunidade após a realização deste trabalho.
De modo geral, o processo de implantação do MPS-BR Nível F na GT4W foi um
êxito e a Redmine permitiu a automatização de alguns processos da gestão dos projetos,
que dependia integralmente de planilhas de controle, promovendo, com a utilização da
Redmine, mais agilidade, flexibilidade, disponibilidade e a rastreabilidade necessárias do
foi realizado nos projetos e melhorando significativamente a eficácia da gerência de
projetos. Ainda existem algumas limitações relacionadas à ferramenta a serem tratadas,
conforme descrito neste trabalho, mas, apesar de não atender 100% de todos os critérios,
a ferramenta Redmine não deve ser descartada como uma opção para controle dos
projetos, sobretudo em processos de certificação MPS-BR.
Referências
Catunda, E.; Nascimento, C.; Cerdeiral, C.; Santos, G.; Nunes, E.; Schots, N. C. L.;
Schots, M.; Rocha, A. R. "Implementação do Nível F do MR-MPS com Práticas Ágeis
do Scrum em uma Fábrica de Software." X Simpósio Brasileiro de Qualidade de
Software (SBQS’11), Curitiba–Brasil (2011).
França, B. B. N. de; Sales, E. de O.; Reis, C. A. L.; Reis, R. Q. Utilização do Ambiente
WebAPSEE na implantação do nível G do MPS. BR no CTIC-UFPA. 2009. VIII
Simpósio Brasileiro de Qualidade de Software. pp 310- 317
72
Ibbs, C. W.; Kwak, Y. H. (2002). “Assessing Project Management Maturity”. Project
Management Journal 31.1. pp 32-43.
Koscianski, A.; Soares, M. dos S. Qualidade de Software. 1ª edição. Editora Novatec.
2007.
Oliveira, S. R. B., et al. "SPIDER-Um Suite de Ferramentas de Software Livre de Apoio
à Implementação do modelo MPS. BR." Anais do VIII Encontro Anual de
Computação–ENACOMP (2010).
Prado, Darci. "Maturidade em gerenciamento de projetos." Nova Lima: INDG
Tecnologia e Serviços Ltda 7 (2008).
Schwaber, K.; Sutherland, J. The Scrum Guide. Disponível em:
<http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-
US.pdf#zoom=100> Acesso em 19 abr de 2016
SOFTEX, 2016. Disponível em: <http://www.softex.br/mpsbr/#>. Acesso em: 18 abr
2016.
SOFTEX. Guia Geral do Software, 2016. Disponível em: <http://www.softex.br/wp-
content/uploads/2016/04/MPS.BR_Guia_Geral_Software_2016-com-
ISBN.pdf?x15632>. Acesso em: 18 abr 2016.
73
MoLEva: Um Método de Avaliação de Qualidade para
Aplicativos Educacionais Móveis
Gustavo W. Soad1, Ellen F. Barbosa1
1
Instituto de Ciências Matemáticas e Computação – Universidade de São Paulo (USP) –
São Carlos – SP – Brasil
gustavo.soad@usp.br, francine@icmc.usp.br
Abstract. The use of learning applications has been growing continuously,

allowing students and teachers greater flexibility and convenience in the
execution of educational activities and practices. Despite the benefits, mobile
learning has problems and challenges, for example, to adequately evaluate the
quality of the educational applications developed. In this context, the present
work proposes a method of quality evaluation for mobile learning
applications. In addition, a case study was also conducted. From the results
obtained, it was possible to identify points of improvement in the applications,
besides providing a score that can be used as comparative for the choice of
this type of application.
Resumo. A utilização de aplicativos educacionais móveis vem crescendo con-

tinuamente, possibilitando a alunos e professores maior flexibilidade e como-
didade na execução de atividades e práticas educacionais. Apesar dos benefí-
cios, a aprendizagem móvel possui problemas e desafios, por exemplo, avaliar
adequadamente a qualidade dos aplicativos educacionais desenvolvidos. Nes-
se contexto, o presente trabalho propõe um método de avaliação de qualidade
para aplicativos educacionais móveis. Além disso, também foi conduzido um
estudo de caso. A partir dos resultados obtidos, foi possível identificar pontos
de melhoria nos aplicativos, além de fornecer uma pontuação que pode ser
utilizada como comparativo para a escolha desse tipo de aplicativo.
1. Introdução
Nos últimos anos, temas relacionados ao ensino e aprendizagem têm sido amplamente
discutidos e estudados pela comunidade científica. Em especial, aplicações computacio-
nais têm apresentado uma crescente importância, desempenhando um papel fundamental
em atividades de ensino e aprendizagem, sendo relevantes não apenas no âmbito acadê-
mico como também no meio industrial [Barbosa 2004, Rubens et al. 2014].
Tais aplicações proporcionaram, entre várias práticas educacionais inovadoras,
uma nova modalidade de ensino - a aprendizagem móvel ou mobile learning (m-
learning) [Nah et al. 2008, Wexler et al. 2008, Kearney et al. 2012]. Em linhas gerais, o
m-learning caracteriza-se pela capacidade de proporcionar uma forte interação entre os
aprendizes e instrutores, possibilitando aos mesmos contribuir, participar e acessar o
ambiente de ensino por meio de dispositivos móveis (celulares, tablets, laptops, rádio,
tv, entre outros) a qualquer momento e em qualquer lugar.
74
Apesar dos benefícios proporcionados no contexto de ensino e aprendizagem,
por se tratar de um conceito novo e ainda incipiente, o m-learning apresenta problemas
e desafios organizacionais, culturais e tecnológicos em sua utilização [Economides
2008, Sarrab et al. 2013, Sharples 2013]. Um destes problemas é que os métodos exis-
tentes para avaliação da qualidade de software ainda são muito genéricos, não contem-
plando aspectos específicos dos aplicativos educacionais móveis.
De fato, aspectos de qualidade, em particular, representam uma questão impor-
tante a ser abordada, principalmente em virtude da crescente popularidade dos aplicati-
vos móveis em diferentes setores da sociedade. Neste cenário emergente, a qualidade
não é apenas relacionada a aspectos técnicos. Há também a necessidade de lidar com
questões intrínsecas (por exemplo, educacionais, socioculturais e socioeconômicas) re-
lacionadas com as atividades diárias de aprendizes, professores e tutores [Economides
2008, Kearney et al. 2012, Abdurrahman et al. 2015].
Apesar de sua relevância, poucos estudos sobre as diretrizes de qualidade para
aplicativos móveis são encontrados na literatura. Como consequência, torna-se difícil
identificar mecanismos bem definidos e amplamente utilizados para apoiar a avaliação
da qualidade de aplicativos educacionais móveis.
Dentro do contexto apresentado, o presente trabalho visa a proposição de um
método para avaliar a qualidade de aplicativos educacionais móveis denominado
MoLEva (Mobile Learning Evaluation).
O artigo encontra-se organizado como se segue. A Seção 2 apresenta os
trabalhos relacionados. A Seção 3 descreve o método MoLEva e a suas etapas de
desenvolvimento. A Seção 4 traz a avaliação do método e apresenta a análise dos
resultados obtidos. Por fim, na Seção 5, são sumarizadas as conclusões do trabalho e as
perspectivas para continuidade da pesquisa.
Para definir o nível de qualidade de um produto de software é necessária uma avaliação
de qualidade, que pode ser conduzida sob os aspectos do processo de desenvolvimento,
que se refere às atividades realizadas durante as etapas do seu ciclo de vida, e sob a qua-
lidade de produto, que se refere às características do produto após o seu desenvolvimen-
to.
A base para o desenvolvimento de um método de avaliação é o seu modelo de
qualidade. Um modelo de qualidade corresponde a um conjunto de características que se
relacionam entre si e que fornecem a base para a especificação de requisitos de qualida-
de e avaliação de qualidade [ISO/IEC 9126 2001].
Visando estabelecer formas de garantir a qualidade de um produto de software,
diversos modelos e padrões vêm sendo estabelecidos. Nestes modelos, a especificação e
avaliação da qualidade do produto de software são fatores fundamentais para a garantia
da qualidade adequada.
Existem dois modelos de qualidade que são considerados seminais: o modelo de
McCall [Cavano e McCall 1978] e o modelo de Boehm [Boehm et al. 1976]. Além dos
modelos citados, a norma ISO/IEC 25010 [ISO/IEC 25010 2010] também possui um
papel importante. Esta norma define um modelo de qualidade composto por
75
características internas (características do produto em seu projeto e construção) e
externas (características do produto quando é avaliado em um ambiente simulado e com
dados simulados) relacionadas ao produto de software. As características definidas, por
sua vez, são subdivididas em subcaracterísticas.
Além desses modelos, também existem modelos específicos para o contexto
educacional, por exemplo, o TUP (Technology Usability Pedagogy) [Bednarik et al.
2004], que propõe um modelo que permite a avaliação de softwares educacionais. Outro
modelo proposto também é definido em Duarte Filho e Barbosa (2013a), e seu objetivo
é avaliar ambientes educacionais móveis.
Os trabalhos citados anteriormente contribuíram para o desenvolvimento do mé-
todo MoLEva. Além disso, as características definidas pela norma ISO/IEC 25010 fo-
ram fundamentais para a proposição do método MoLEva, já que esta norma define ca-
racterísticas de qualidade gerais para os produtos de software. Dessa maneira, é possível
utilizar as características definidas incorporando-as ao modelo MoLEva, além de auxili-
ar no desenvolvimento da hierarquia do modelo de qualidade MoLEva.
3. MoLEva: Método de Avaliação de Qualidade

Com o objetivo de desenvolver o método de avaliação de qualidade para aplicativos
educacionais móveis, foi necessário realizar estudos sobre as características de qualida-
de presentes nesse tipo de aplicativo. Para isso, foi conduzido um mapeamento
sistemático a fim de obter um conjunto de características de qualidade para aplicativos
educacionais móveis [Soad et al. 2015].
A partir dos resultados obtidos, foi definido um conjunto de características de
qualidade para o contexto de aplicativos educacionais móveis, estabelecendo assim a
base para a criação do modelo de qualidade para o método MoLEva. Outras pesquisas
como Duarte Filho e Barbosa (2013a) e Acharya e Sinha (2013) também foram utiliza-
das para auxiliar na definição das etapas do processo de avaliação utilizado pelo método
MoLEva.
Em linhas gerais, o processo de desenvolvimento do método MoLEva é compos-
to por seis etapas, em conformidade com a ISO/IEC 14598 [ISO/IEC 14598 1998], as
quais foram simplificadas e adaptadas para o contexto de aplicativos educacionais mó-
veis. As etapas são:
- Definir objetivos e contextualização da avaliação: o objetivo definido para o méto-
do MoLEva é analisar e comparar os aplicativos educacionais móveis em relação aos
aspectos técnicos, educacionais, socioeconômicos e socioculturais, identificando pontos
fortes e fracos de cada aplicativo considerado.
- Definir e configurar o modelo de qualidade: o modelo de qualidade a ser adotado no
processo estabelece um conjunto bem definido de critérios e requisitos para aplicativos
educacionais móveis. É essencial que o modelo definido nessa etapa seja configurado de
acordo com o contexto de aplicativos educacionais, pois dessa maneira, é possível for-
necer uma base de características que esse tipo de aplicativo deve satisfazer para conse-
guir excelência em seu nível de qualidade.
- Identificar métricas de avaliação: nesta etapa, os requisitos de qualidade são mapea-
dos em atributos que podem ser medidos. Em suma, os atributos mensuráveis são confi-
76
gurados com base no conhecimento de especialistas, por meio da criação de perguntas
simples e diretas, que são avaliadas e pontuadas por meio de um checklist.
- Definir níveis de pontuação e critérios de julgamento: nesta etapa, são definidos os
níveis de pontuação para as perguntas do checklist. Para isso, foi necessário primeira-
mente especificar os tipos de respostas nominais que seriam aplicadas às questões. Além
disso, nessa etapa também são definidos os critérios de julgamento, que por sua vez de-
finirão qual o nível de qualidade do aplicativo.
- Projetar a avaliação: nessa etapa deve ser definido o plano de avaliação que deverá
ser seguido durante a execução da avaliação. Esse plano deve conter as diretrizes e pro-
cedimentos necessários para que as avaliações sejam feitas, além de definir a técnica de
coleta de dados. No caso do MoLEva a técnica utilizada para avaliação é o checklist.
Para facilitar na definição do plano de avaliação alguns pontos são sugeridos por Duarte
Filho e Barbosa (2013a), como: (i) identificar o perfil dos avaliadores; (ii) mapear os
recursos necessários para viabilizar a avaliação; (iii) tempo médio estipulado para a exe-
cução da avaliação; e (iv) como serão apresentados os resultados gerados pela avaliação.
- Executar a avaliação: na fase final, o avaliador deve executar três tarefas principais:
(i) coletar as medidas de qualidade; (ii) comparar as medidas em relação aos critérios de
qualidade pré-definidos; e (iii) avaliar os dados obtidos durante a avaliação. As etapas
citadas devem ser executadas por desenvolvedores e especialistas em qualidade de
software.
As etapas do processo citadas anteriormente foram executadas algumas vezes,
com o objetivo de refinar o método MoLEva. Resultados sobre os primeiros testes com
o método MoLEva foram publicados em Soad et al. (2016). Dessa forma, foi possível
estabelecer o método de avaliação de qualidade, que consiste em três etapas, que são: (i)
configuração da avaliação, que possibilita a configuração dos critérios de qualidade que
devem ser considerados, além de possibilitar a customização dos critérios de julgamen-
to; (ii) execução da avaliação, que é a etapa, na qual o checklist é aplicado; e (iii) análise
dos resultados da avaliação, que apresenta os resultados obtidos com a execução da ava-
liação.
Para definir os principais componentes do método MoLEva, utilizou-se como
base a norma ISO/IEC 14598 [ISO/IEC 14598 1998], estabelecendo assim um método
formado por três componentes fundamentais:
 Modelo de qualidade: define um conjunto de características de qualidades para
aplicativos educacionais móveis, fornecendo assim a base para a avaliação de
qualidade;
 Métricas: definem a forma de coleta de dados para possibilitar a medição da qua-
lidade dos aplicativos;
 Critérios de julgamento: definem como o aplicativo será julgado a partir dos da-
dos coletados durante a avaliação.
3.1. Modelo de Qualidade

O principal componente do MoLEva é seu modelo de qualidade, responsável por definir
o conjunto de características que fornece a base para a avaliação de qualidade de aplica-
77
tivos educacionais móveis. O modelo de qualidade do método MoLEva é dividido em
três categorias, fundamentadas na divisão dos requisitos de qualidade para aplicativos
m-learning definidos em Soad et al. (2015) e Duarte Filho e Barbosa (2013b). As cate-
gorias são:
 Pedagógica: são os aspectos educacionais presentes no aplicativo, ou seja, são as
características que têm como foco o aprendizado do aluno;
 Social: referem-se aos aspectos sociais presentes no aplicativo, abordando carac-
terísticas econômicas e culturais;
 Técnica: são os aspectos técnicos do aplicativo, ou seja, referem-se às caracterís-
ticas da aplicativo que contribuem para seu uso e funcionamento.
O modelo de qualidade possui uma estrutura composta por categorias, critérios e
características de qualidade, dispostos de maneira hierárquica. Essa divisão foi funda-
mentada na norma ISO/IEC 25010 [ISO/IEC 25010 2010]. A Figura 1 apresenta uma
visão geral do modelo de qualidade que compõe o MoLEva.
Figura 1. Modelo de Qualidade do MoLEva
78
As categorias definidas no modelo possuem uma subdivisão, totalizando 12 cri-
térios de qualidade. Para a categoria Pedagógica, são definidos três critérios de qualida-
de. O primeiro é o critério Aprendizagem que é definido pela capacidade do aplicativo
em disponibilizar funcionalidades que contribuam para o aprendizado do aluno. O se-
gundo é Conteúdo, que é definido pela capacidade em fornecer conteúdo gerenciável e
de qualidade. O terceiro (e último) critério pedagógico existente no modelo é a
Interatividade que é definida como, a capacidade do aplicativo em disponibilizar fun-
cionalidades que contribuam para que os usuários interajam entre si e com o aplicativo.
Algumas das características relacionadas a categoria Pedagógica são apresentadas na
Tabela 1.
Tabela 1. Características de Qualidade Relacionadas à Categoria Pedagógica
A próxima categoria estabelecida no modelo de qualidade do MoLEva é a cate-

goria Social. Para essa categoria são definidos dois critérios de qualidade. O primeiro é
o critério Socioeconômico, que é caracterizado pela capacidade em proporcionar viabi-
lidade na utilização do aplicativo, fazendo uma relação de custo e benefício. O segundo
critério relacionado à categoria Social é o Sociocultural. Ele é caracterizado pela capa-
cidade do aplicativo em se adaptar ao contexto sociocultural do usuário, considerando
características como idade, nível de ensino, determinado grupo cultural, entre outros.
Algumas características relacionadas à categoria Social são apresentadas na Tabela 2.
Tabela 2. Características de Qualidade Relacionadas à Categoria Social
A última categoria a ser apresentada é a Técnica, que é composta por sete crité-
rios de qualidade. O primeiro critério apresentado é a Adequação Funcional, que é
definido como a capacidade do aplicativo em disponibilizar funções que atendam às
necessidades implícitas e explícitas em relação ao aplicativo. O segundo critério é a
Eficiência do Desempenho. Ele é caracterizado pela capacidade do aplicativo em for-
necer um bom desempenho em relação à quantidade de recursos utilizados sob condi-
ções estabelecidas, ou seja, refere-se à otimização do uso dos recursos disponíveis.
O terceiro critério é definido como Compatibilidade. Ele se caracteriza como a
capacidade do aplicativo em trocar informações ou realizar operações com outros apli-
cativos, compartilhando o mesmo ambiente de hardware e software. O quarto critério é a
Usabilidade. Esse critério é definido como a capacidade do aplicativo em ser utilizado
79
por usuários específicos em um contexto específico, oferecendo maneiras que possibili-
tam o aplicativo ser entendido, aprendido, utilizado e atraente ao usuário.
O quinto critério é definido como Confiabilidade. Ele é caracterizado pela ca-
pacidade do aplicativo em proporcionar um comportamento consistente com o esperado
durante um longo período de tempo. O sexto critério é definido como Segurança. Esse
critério é caracterizado pela capacidade do aplicativo em proteger as informações e da-
dos, protegendo-os de acesso não autorizado e garantindo seu acesso de acordo com os
diferentes níveis de autorização.
Por fim, o último critério de qualidade é definido como Portabilidade. Este cri-
tério é caracterizado pela capacidade do aplicativo ser transferido de um hardware ou
software para outro. Algumas das características relacionadas à categoria Técnica são
apresentadas na Tabela 3.
Tabela 3. Características de Qualidade Relacionadas à Categoria Técnica
3.2. Métricas
Para determinar o valor associado às características de qualidade definidas pelo método
MoLEva, é necessária uma medição. Dessa maneira, é possível medir e interpretar a
qualidade do critério que está sendo avaliado.
O termo “métrica” utilizado não possui o sentido matemático usual, mas se refe-
re à uma escala e um método que pode ser utilizado para medição. Essa definição é fun-
damentada nas diretrizes da ISO/IEC 14598 [ISO/IEC 14598 1998], na fase de especifi-
cação da avaliação.
As métricas que compõem o método de qualidade MoLEva foram definidas ma-
peando as características de qualidade em atributos mensuráveis, permitindo assim que
elas fossem medidas e pontuadas. Para isso, optou-se em utilizar a técnica de checklist.
A aplicação dessa técnica consiste em um conjunto de perguntas objetivas, que permi-
tem a coleta de informações por meio de respostas simples e objetivas.
O desenvolvimento do checklist do MoLEva utilizou como base o proposto em
Duarte Filho (2016). As perguntas contidas nesse checklist foram adaptadas para o con-
texto de aplicativos educacionais móveis. Além disso, o modelo de qualidade descrito
anteriormente e ilustrado na Figura 1, foi essencial para a criação de novas perguntas, já
que ele é a base para o método de avaliação MoLEva.
Ao final do desenvolvimento, o checklist (https://goo.gl/xHbaEn) foi composto
por 85 perguntas, abordando os 12 critérios (sub-categorias) de qualidade definidos no
80
modelo da Figura 1. Esse conjunto de perguntas é fundamental para a avaliação de qua-
lidade, já que a partir dele são coletas as informações necessárias para definição do nível
de qualidade do aplicativo.
3.3. Critérios de Julgamento

A definição de critérios de julgamento permite determinar o nível de qualidade do apli-
cativo. Por meio dessa definição, é possível fazer comparações entre os aplicativos,
identificando-se, também, possibilidades de melhorias.
Para definir o nível de qualidade do aplicativo a ser avaliado e identificar os pos-
síveis pontos de atenção, é necessário atribuir valores quantitativos para as perguntas
contidas no checklist. Por esse motivo, as respostas obtidas na aplicação da avaliação de
qualidade devem ser convertidas em dados quantitativos. Para as respostas binárias, os
valores atribuídos são 10 pontos para respostas “Sim” e 0 pontos para respostas “Não”.
Com relação às respostas por grau de concordância, a pontuação atribuída é mos-
trada na Tabela 4. Para cada grau de concordância, foi atribuído um significado possí-
vel, objetivando traduzir o dado quantitativo em qualitativo, facilitando assim o signifi-
cado numérico da resposta. Os valores atribuídos para as respostas foram baseados nos
critérios de pontuação definidos em Duarte Filho e Barbosa (2013a).
Tabela 4. Pontuações Definidas para as Respostas por Grau de Concordância
As pontuações são atribuídas a cada pergunta do checklist. Essas perguntas con-

templam os 12 critérios de qualidade definidos no método MoLEva. O cálculo final do
nível de qualidade é definido pela média aritmética da pontuação de cada critério.
Para efeito de normalização dos resultados, os critérios de qualidade recebem a
porcentagem de pontos equivalentes à pontuação recebida. Por exemplo, para um crité-
rio que possua a pontuação máxima igual a 80 pontos, esses pontos serão equivalentes a
100% de qualidade.
Outro fator que interfere no cálculo do nível de qualidade são as respostas que
não possuem pontuação e as perguntas que não devem ser consideradas no cálculo da
qualidade, que são: (i) “não se aplica”, é utilizada para proposições que fazem referência
a um aspecto que não se enquadra ao domínio do aplicativo móvel sendo avaliado; e (ii)
“avaliação prejudicada”, que se refere a proposições que o avaliador não está em condi-
ções de avaliar. Isso pode ocorrer por falta de recursos, informações ou conhecimento
específico.
Nesse caso o resultado final deve ser normalizado inferindo o valor 100% para o
total possível das questões de cada critério avaliado. O cálculo para obter o nível de qua-
lidade por critério é dado pela fórmula a seguir:
81
onde, NQCR é o Nível de Qualidade por Critério; TPC é o Total de Perguntas conside-
radas por Critério; p é a pontuação atribuída para cada pergunta; e n é o total de pergun-
tas do critério avaliado.
A partir dos resultados obtidos para cada critério, é possível calcular o nível de
qualidade para cada uma das três categorias definidas no modelo (Pedagógica, Social e
Técnica). O cálculo para obter o nível de qualidade por categoria é dado pela fórmula a
seguir:
onde, NQCA é o Nível de Qualidade por Categoria; TCQ é o Total de Critérios de

Qualidade relacionados à categoria avaliada; e n é o total de critérios relacionados à
categoria avaliada.
Por fim, o resultado final que representa o nível de qualidade geral do aplicativo,
considerando-se as três categorias é calculado. O cálculo para obter o nível de qualidade
geral do aplicativo é dado pela fórmula a seguir:
onde, NQA é o Nível de Qualidade do Aplicativo; NQP é o Nível de Qualidade da cate-

goria Pedagógica; NQS é o Nível de Qualidade da categoria Social; NQT é o Nível de
Qualidade da categoria Técnica; e TC é o Total de Categorias avaliadas, nesse caso será
igual.
Para definir o nível de qualidade, o resultado final é atribuído de acordo com os
critérios de julgamento definidos a partir do trabalho de Martinez et al. (1999) e também
utilizado em Duarte Filho e Barbosa (2013a). Esta definição foi feita com o objetivo de
definir um valor padrão. Dessa maneira, o nível de qualidade do aplicativo é dividido
em três com seus respectivos valores padrões: (i) Superior, pontuação igual ou maior
que 80%; (ii) Médio, pontuação igual ou maior que 50% e menor que 80%; e (iii) Baixo,
pontuação menor que 50%.
De acordo com os possíveis níveis de qualidade do aplicativo, considera-se que
um aplicativo com o nível superior possui um bom nível de qualidade, já que para obter
essa pontuação o aplicativo conseguiu satisfazer os critérios de qualidade avaliados. Por
outro lado, um nível de qualidade médio revela que o aplicativo necessita de melhorias.
Por fim, um nível de qualidade baixo sugere que o aplicativo não conseguiu al-
cançar níveis satisfatórios de qualidade. Dessa maneira, o resultado da avaliação sugere
que esse aplicativo deva passar por uma restruturação, com base nos critérios de quali-
dade não satisfeitos a partir da avaliação conduzida.
Embora o método MoLEva defina pontuações para suas questões, é importante
ressaltar que os valores definidos podem ser alterados de acordo com os objetivos da
avaliação. Dessa maneira, é possível inclusive atribuir pesos diferentes para cada critério
de qualidade. Essa possibilidade permite que o método possa ser adaptado para cada
necessidade. Por este motivo, a definição da pontuação exige conhecimento e bom senso
do especialista que deseja customizá-las e atribuí-las ao método.
82
4. Avaliação do Método MoLEva
Para avaliar o método MoLEva, optou-se pela condução de um estudo de caso. O estudo
de caso envolvendo a aplicação do método MoLEva foi conduzido no contexto de apli-
cativos para o ensino de idiomas. Além de disponibilizarem várias opções de aplicativos
em diferentes sistemas operacionais, esse tipo de aplicativo possui um objetivo bem
definido, que é o ensino de idiomas. Para este estudo de caso foram selecionados dois
aplicativos educacionais móveis: (i) Duolingo; e (ii) Wlingua.
Tais aplicativos foram escolhidos pois, além de possuírem uma boa avaliação
nas lojas de aplicativos, eles também estão disponíveis para os três principais sistemas
operacionais existentes atualmente (Android, iOS e Windows).
4.1. Planejamento do Estudo de Caso

Antes da execução do estudo de caso foi necessário fazer o seu planejamento. Para isso
foi necessária a definição dos seus objetivos. Além disso, também são definidos os per-
fis dos participantes do estudo. Por fim, são definidos os instrumentos utilizados durante
o estudo de caso.
Objetivo
O objetivo do estudo de caso é validar a utilização do método MoLEva na avali-
ação de aplicativos educacionais móveis. Para isso é feita a análise do resultado obtido
após a execução do método.
Participantes
Para o presente estudo de caso, foram selecionados oito alunos de pós-graduação
do ICMC-USP na área Engenharia de Software, sendo um doutor, seis doutorandos e
um mestre. Dentre os alunos participantes, dois já atuavam como professor.
Instrumentação
No que se refere à instrumentação utilizada no estudo de caso, os seguintes do-
cumentos foram apresentados aos participantes: (i) termo de adesão ao estudo experi-
mental; (ii) formulário de caracterização do participante; (iii) documento com a orienta-
ção das atividades que o participante deveria realizar; (iv) ferramenta web utilizada para
a aplicação do método MoLEva (http://moleva-gustavosoad.rhcloud.com).
4.2. Execução do Estudo de Caso

Para a execução do estudo de caso os participantes selecionados foram divididos em
dois grupos. Essa divisão foi feita a partir das respostas de cada um deles no formulário
de caracterização do participante. Esse documento foi submetido aos participantes obje-
tivando coletar as informações necessárias para a divisão dos grupos.
Para que esta divisão fosse feita de forma balanceada, as seguintes características
foram consideradas por ordem de prioridade: (i) conhecimento sobre qualidade de
software; (ii) experiência em avaliação de qualidade de aplicativos; (iii) utilização dos
aplicativos educacionais móveis contidos no estudo de caso; e (iv) nível de conhecimen-
to no idioma inglês.
83
4.3. Análise dos Resultados
O estudo de caso foi executado por oito participantes, sendo que os dispositivos utiliza-
dos durante o estudo de caso foram exclusivamente smartphones. Já os sistemas opera-
cionais utilizados foram variados. Embora a maioria tenha sido Android (5 avaliações),
também foram utilizados o iOS (2 avaliações) e Windows (1 avaliação).
A análise dos resultados da avaliação de qualidade dos aplicativos é importante
para a avaliação do método MoLEva, já que por meio dos resultados é possível identifi-
car se a partir da aplicação do método conseguiu-se definir um nível de qualidade para o
aplicativo, além de revelar suas deficiências. Para este estudo de caso, os valores dos
critérios de julgamento mantiveram-se com o padrão definido pelo método MoLEva.
Com o objetivo de analisar duas avaliações de qualidade individualmente (uma
do Duolingo e outra do Wlingua), foram selecionadas as avaliações que foram realiza-
das pelos avaliadores mais experientes de cada aplicação (o nível de experiência dos
avaliadores foi baseado no seu conhecimento sobre avaliação de qualidade de software e
aplicativos educacionais móveis). A Figura 2, apresenta a avaliação de qualidade dos
aplicativos Duolingo e Wlingua sob a perspectiva dos critérios de qualidade
estabelecidos pelo método.
Figura 2. Resultado da Avaliação de Qualidade dos Aplicativos por Critérios de

Qualidade: Avaliadores Experientes
O resultado por critérios de qualidade indica que o método MoLEva conseguiu

identificar alguns critérios que chamam a atenção para melhoria nos aplicativos. Um
desses critérios é “Segurança”, identificado nos dois aplicativos como sendo o critério
com menor pontuação. Este resultado mostra que uma análise relacionada à segurança
desses aplicativos deve ser realizada, pois aspectos de segurança podem acarretar riscos
para os aplicativos e seus usuários.
Além disso, o aplicativo Duolingo possui outros dois critérios com o nível de
qualidade mais baixo. Um deles é o critério “Sociocultural”, que sugere que o aplicativo
pode ter problemas ao fornecer funcionalidades e se adaptar ao contexto cultural de seus
usuários. Por exemplo, o aplicativo não possui mecanismos para denunciar mensagens
ou conteúdos considerados ofensivos. O outro critério avaliado com o nível baixo é o
“Socioeconômico”, indicando que o aplicativo deve dar maior atenção aos fatores soci-
84
ais e econômicos que permeiam o aplicativo. Por exemplo, foi identificado que não é
possível reportar um problema pelo aplicativo, caso um problema ocorra.
Já o aplicativo Wlingua obteve melhores pontuações relacionadas a estes crité-
rios. Por outro lado, o critério “Adequação Funcional” não foi bem pontuado, o que su-
gere que o aplicativo pode ter deficiências em suas funcionalidades, além de possíveis
funcionalidades que deveriam existir no aplicativo, mas que não estão presentes.
Embora alguns critérios não tenham sido bem avaliados, é importante ressaltar
que para ambos aplicativos o critério “Portabilidade” resultou em 100% da pontuação,
indicando que os aplicativos podem ser utilizados em diversos tipos de dispositivos sem
que ocorra problemas.
Além disso, é importante ressaltar que o aplicativo Duolingo obteve 100% para
o critério “Confiabilidade”, indicando que o aplicativo possui um comportamento con-
sistente. Já o aplicativo Wlingua também obteve 100% de pontuação em outro critério
que foi o “Socioeconômico”, indicando que o aplicativo é viável e possui uma boa rela-
ção custo-benefício.
Para os dois avaliadores citados, também foram analisadas as informações obti-
das por categoria, apresentadas na Figura 3. Observa-se que o Duolingo apresenta um
baixo nível de qualidade para as questões relacionadas à categoria “Social”, embora
apresente uma pontuação consistente para os critérios “Pedagógicos” e “Técnicos”. Por
este motivo, é possível concluir que o aplicativo deveria ter atenção à categoria
“Social”. Já o aplicativo Wlingua possui todos os critérios entre o nível médido e supe-
rior, demonstrando assim que todos as categorias estão com um bom nível de qualidade.
Embora o resultado seja satisfatório para o aplicativo Wlingua, é importante que as
deficiências identificadas sejam melhoradas, removendo assim as lacunas existentes no
aplicativo.
Figura 3. Resultado da Avaliação de Qualidade dos Aplicativos por Categoria:

Avaliadores Experientes
Após a avaliação individual feita com os avaliadores mais experientes, também

foram obtidos os dados relacionados à consolidação de todas as avaliações. A Figura 4,
apresenta o resultado por critério de qualidade considerando a média de todas as avalia-
ções. Observa-se que para o Duolingo houve uma melhora nas avaliações que estavam
com pontuações menores na avaliação individual, porém a característica
“Socioeconômica” continua com pontuação baixa. Este resultado é importante, pois
85
caso a pontuação seja um consenso entre os avaliadores, isso pode representar uma mai-
or assertividade na análise do nível de qualidade.
Figura 4. Resultado da Avaliação de Qualidade dos Aplicativos por Critério de

Qualidade
Já as pontuações mais altas relacionadas ao Duolingo continuaram as mesmas,

indicando que o resultado obtido com as avaliações está consistente com relação aos
critérios mais bem avaliados. Com relação ao aplicativo Wlingua, suas pontuações tam-
bém se mantiveram consistentes, porém nota-se que quase todos os critérios apresenta-
ram quedas ao considerar todas as avaliações realizadas.
Com relação ao resultado por categoria, apresentado na Figura 5, observa-se que
os níveis de qualidade obtiveram poucas alterações. Entretanto, para o aplicativo
Wlingua, é possível identificar uma considerável alteração da avaliação individual para
a geral. Na avaliação individual a categoria “Social” obteve 93,75 pontos, já na geral
resultou em 60,42 pontos. Este resultado mostra uma diferença considerável entre as
avaliações. Dessa maneira, é importante que seja considerado nos trabalhos futuros a
investigação de divergências no entendimento das perguntas relacionadas à esta catego-
ria.
Figura 5. Resultado da Avaliação de Qualidade dos Aplicativos por Categoria
Por fim, o nível de qualidade definido para o aplicativo Duolingo foi de 63,91
pontos, já o Wlingua recebeu a pontuação final igual a 65,88 pontos. Este resultado
mostra que ambos os aplicativos foram classificados com o nível médio de qualidade.
86
4.4. Ameaças à Validade
O primeiro aspecto a ser considerado é que a condução do estudo ocorreu de maneira
remota, não sendo executada em um ambiente controlado. Dessa maneira, todos os ava-
liadores receberam as orientações por meio de documentos. Além disso, não houve ne-
nhum treinamento relacionado ao método MoLEva, visto que as informações sobre o
método estavam contidas apenas nos documentos.
Outro ponto importante está relacionado com a interpretação dos itens avaliados.
Apesar de existir um exemplo para cada questão do checklist, uma interpretação incor-
reta pode ocasionar em uma avaliação incorreta.
Além disso, os participantes selecionados são todos do meio acadêmico e da
mesma universidade. Seria interessante a participação de uma quantidade maior de par-
ticipantes e de uma maneira mais abrangente, considerando outras universidades. É im-
portante observar, ainda, que dentre os participantes nenhum é da indústria.
Ressalta-se que novos experimentos vêm sendo planejados de modo a considerar
as ameaças identificadas. A execução de novos experimentos faz parte das atividades
futuras associadas à continuidade da pesquisa, devendo ser realizada em curto prazo.
5. Conclusão
A partir dos resultados obtidos com o estudo de caso realizado foi possível concluir que
o método MoLEva é factível de ser aplicado na avaliação de qualidade de aplicativos
educacionais móveis. Este resultado é favorável para o método MoLEva, pois ele foi
capaz de indicar pontos relevantes de melhoria para os aplicativos avaliados. Ressalta-
se, também, que sua avaliação possibilita a comparação entre aplicativos, permitindo
que o usuário escolha o aplicativo que possui os pontos positivos mais relevantes para
sua necessidade, auxiliando assim na tomada de decisão.
Apesar das análises apresentadas fornecerem indícios de que o método MoLEva
pode ser utilizado nas avaliações de qualidade de aplicativos educacionais móveis, é
fundamental que mais estudos e experimentos formais sejam planejados e conduzidos,
em diferentes domínios de aplicação.
Por fim, pretende-se fazer novas pesquisas baseadas nos resultados obtidos com
o MoLEva, buscando desenvolver uma versão mais ágil de ser executada e automati-
zando alguns pontos da avaliação.
Agradecimentos
Os autores agradecem o financiamento brasileiro Agências - FAPESP (Processo 2014 /
03389-9), CAPES (Procad 071/2013) e CNPq.
Referências
Abdurrahman, J., Beer, M., and Crowther, P. (2015). Pedagogical requirements for mobile learning: a
review on mobilearn task model. Journal of Interactive Media in Education, 2015(1):1–17.
Acharya, A. and Sinha, D. (2013). Assessing the quality of m-learning systems using ISO/IEC 25010.
International Journal of Advanced Computer Research, 3(3).
Barbosa, E. F. (2004). Uma contribuição ao processo de desenvolvimento e modelagem de módulos
educacionais. PhD thesis, Universidade de São Paulo.
87
Bednarik, R., Gerdt, P., Miraftabi, R., and Tukiainen, M. (2004). Development of the tup model -
evaluating educational software. In IEEE International Conference on Advanced Learning
Technologies, 2004. Proceedings., pages 699–701.
Boehm, B. W., Brown, J. R., and Lipow, M. (1976). Quantitative evaluation of software quality. In
Proceedings of the 2nd international conference on Software engineering, pages 592–605. IEEE
Computer Society Press.
Cavano, J. P. and McCall, J. A. (1978). A framework for the measurement of software quality. ACM
SIGSOFT Software Engineering Notes, 3(5):133–139.
Duarte Filho, N. F. (2016). Uma contribuição ao estabelecimento de uma arquitetura de referência para
ambientes de aprendizagem móvel. PhD thesis, Universidade de São Paulo.
Duarte Filho, N. F. and Barbosa, E. F. (2013a). A contribution to the quality evaluation of mobile learning
environments. In Frontiers in Education Conference, 2013 IEEE, pages 379–382.
Duarte Filho, N. F. and Barbosa, E. F. (2013b). A requirements catalog for mobile learning environments.
In Proceedings of the 28th Annual ACM Symposium on Applied Computing, SAC ’13, pages 1266–
1271, New York, NY, USA. ACM.
Economides, A. A. (2008). Requirements of mobile learning applications. International Journal of
Innovation and Learning, 5(5).
ISO/IEC 14598 (1998). ISO/IEC 14598: Information Technology - Evaluation of Software Products.
ISO/IEC.
ISO/IEC 25010 (2010). ISO/IEC 25010 - Systems and software engineering - Systems and software
Quality Requirements and Evaluation (SQuaRE) - System and software quality models. Technical
report.
ISO/IEC 9126 (2001). ISO/IEC 9126. Software engineering – Product quality. ISO/IEC.
Kearney, M., Schuck, S., Burden, K., and Aubusson, P. (2012). Viewing mobile learning from a
pedagogical perspective. Research in Learning Technology, 20(0).
Martinez, M., Azevedo, G., Lopes, S., Pagliuso, P., Colombo, R., Rodrigues, M., and Jino, M. (1999).
The software product evaluation database-supporting mede-pros. In Software Engineering Standards,
1999. Proceedings. Fourth IEEE International Symposium and Forum on, pages 182–191.
Nah, K. C., White, P., and Sussex, R. (2008). The potential of using a mobile phone to access the internet
for learning efl listening skills within a korean context. ReCALL, 20(03):331–347.
Rubens, N., Kaplan, D., and Okamoto, T. (2014). E-learning 3.0: Anyone, anywhere, anytime, and ai. In
New Horizons in Web Based Learning, pages 171–180. Springer.
Sarrab, M., Al-Shihi, H., and Rehman, O. (2013). Exploring major challenges and benefits of m-learning
adoption. British Journal of Applied Science & Technology, 3(4):826 – 839.
Sharples, M. (2013). Mobile learning: research, practice and challenges. Distance Education in China,
3(5):5–11.
Soad, G., Filho, N. F. D., and Barbosa, E. F. (2015). Uma contribuição ao estabelecimento de
características de qualidade para aplicações educacionais móveis. In XIV Simpósio Brasileiro de
Qualidade de Software (SBQS), pages 165–179.
Soad, G., Filho, N. F. D., and Barbosa, E. F. (2016). Quality evaluation of mobile learning applications.
In 2016 IEEE Frontiers in Education Conference (FIE), pages 1–8.
Wexler, S., Brown, J., Metcalf, D., Rogers, D., and Wagner, E. (2008). Mobile learning: What it is, why it
matters, and how to incorporate it into your learning strategy. Guild Research.
88
Mineração de Textos para Apoiar a Predição de Severidade de
Relatórios de Incidentes: um Estudo de Viabilidade
Jacson Rodrigues Barbosa1,4 , Ivone Penque Matsuno1,3 , Eduardo R. Guimarães4 ,
Solange Oliveira Rezende1 , Auri M. R. Vincenzi2 , Márcio E. Delamaro1
1
Instituto de Ciências Matemáticas e de Computação (ICMC)
Universidade de São Paulo (USP) - São Carlos/SP, Brasil, 13560-970
2
Departamento de Computação (DC) - Universidade Federal de São Carlos (UFSCar)
São Carlos/SP, Brasil, 13565-905
3
Universidade Federal de Mato Grosso do Sul (UFMS)
Três Lagoas/MS, Brasil, 79620-080
4
Instituto de Informática (INF) - Universidade Federal de Goiás (UFG)
Goiânia/GO, Brasil, 74690-900
{jacsonrb, ivone.matsuno}@usp.br, eduardo.humberto@ufg.br
{solange, delamaro}@icmc.usp.br, auri@dc.ufscar.br
Abstract. Context: Due to a large number of incident reports that are persistent
in Bug Tracking Systems repositories and the need to prioritize them according
to the type of severity, it is necessary to investigate tools that support the
prediction of incident reports severity. Objective: Apply Text Mining (TM)
techniques and learning methods to help the prediction of incident reports
severity from their descriptions. Method: A viability study was conducted
to evaluate the application of preprocessing techniques and classification
methods. Results: The semi-supervised learning method TCBHN presented
good performance concerning the other approaches. Conclusion: The use of
two-way heterogeneous networks and semi-supervised classification methods
for predicting the severity of incident reports are promising.
Resumo. Contexto: Devido à grande quantidade de relatórios de incidentes

que são persistidos em Sistema de Rastreamento de Incidentes (SRI) e a
necessidade em priorizá-los conforme o tipo de severidade, faz-se necessário
investigar ferramentas que apoiem a predição de severidade de relatórios
de incidentes. Objetivo: Aplicar técnicas de Mineração de Textos (MT) e
métodos de aprendizado para apoiar a predição de severidade de relatórios
de incidentes a partir das descrições dos mesmos. Método: Um estudo
de viabilidade foi conduzido para avaliar a aplicação de técnicas de
pré-processamento e métodos de classificação. Resultados: O método de
aprendizado semissupervisionado TCBHN apresentou bom desempenho em
relação às demais abordagens. Conclusão: Utilização de redes heterogêneas
bipartidas e métodos de classificação semissupervisionados para predição de
severidade de relatórios de incidentes são promissores.
89
1. Introdução
Em todas as fases do ciclo de vida de desenvolvimento de software é comum identificar
defeitos, tendo em vista que 50-80% do custo total da manutenção de software está
associado com o custo para a correção de defeitos [Xia et al. 2015]. Muitos projetos
de software, para apoiar a gestão desses relatórios de incidentes, fazem uso de Sistema de
Rastreamento de Incidentes (SRI), tais como o Bugzilla1 , Jira2 , Mantis3 e outros.
O registro de um relatório de incidente é, em geral, feito por um ser humano
ao detectar que existe algum problema com o produto em uso. Como a análise é
conduzida de maneira subjetiva por diferentes pessoas, a severidade e/ou prioridade do
defeito reportado acaba sendo sub ou superestimada, dificultando a priorização de quais
problemas deveriam ser resolvidos primeiro. Devido ao grande número de relatórios de
incidentes produzidos diariamente, há um grande desperdício de recursos humanos que
devem ser alocados para reorganizar a prioridade e severidade dos diversos defeitos de
forma manual.
Diante deste cenário, diversas técnicas automáticas têm sido propostas e usadas
com o intuito de reduzir o impacto dos defeitos em softwares. Dentre essas técnicas
têm-se: atribuição de severidade/prioridade de relatório de incidente, detecção de relatório
de incidente duplicados e predição do tempo de correção de defeitos [Xia et al. 2015].
Comumente para construir os correspondentes modelos de predição dessas técnicas,
faz-se necessário primeiramente extrair os dados a partir de um repositório de SRI.
Conforme Shull et al. (2001), o estudo conduzido é classificado como Estudo
de Viabilidade [Shull et al. 2001]. No presente estudo, é proposta uma abordagem para
viabilizar a predição de severidade de relatório de incidente a partir de técnicas de
Mineração de Textos (MT).
Este texto está organizado da seguinte forma. Na Seção 2, apresenta-se a
fundamentação teórica. Nas Seções 3 e 4, são apresentadas respectivamente a definição e
a implementação do estudo de viabilidade. Na Seção 5, discutem-se os resultados obtidos
e as ameaças à validade deste. Os trabalhos relacionados são discutidos na Seção 6. Por
fim, as conclusões e os trabalhos futuros são descritos na Seção 7.
2. Mineração de Repositórios de Relatórios de Incidentes - Visão Geral

Nesta seção são apresentados os principais conceitos relacionados a este trabalho.
2.1. Relatório de Incidente

Sistema de Rastreamento de Incidentes (SRI) é uma importante ferramenta que viabiliza
o gerenciamento de relatórios de incidentes. Qualquer interessado (stakeholder) ao
identificar uma falha durante a execução de um software pode fazer uso do SRI para
registro do incidente ocorrido. Durante o registro, dependendo do SRI podem ser
inseridas algumas informações cadastrais sobre o defeito. Por exemplo, no Bugzilla
pode ser fornecido: Summary (definição do título), Product (produto no qual deu origem
ao registro), Component (componente relacionado à ocorrência), Description (descrição
1
Bugzilla: https://www.bugzilla.org/
2
Jira: https://jira.atlassian.com/
3
Mantis: https://www.mantisbt.org/
90
detalhada do defeito), Priority (define a prioridade de correção de um defeito em relação
aos demais, sendo que P1 é considerada a maior prioridade e P5 a menor), Severity
(descreve o impacto do defeito, situações possíveis são apresentadas na Tabela 1) e Status
(estado atual).
Tabela 1. Tipos de Severidade de relatório de incidente, adaptada

de [Saha et al. 2015]
Severidade Descrição
blocker – BL Bloqueia o desenvolvimento e/ou a atividade de teste de software
critical – CR Provoca perda de dados, crashes ou comprometimento da memória
major – MA Ocasiona maior perda das funcionalidades
normal – NO Causa alguma perda de funcionalidade em circunstâncias específicas
minor – MI Resulta em menor perda de funcionalidade
trivial – TR Problema elementar, tais como texto desalinhado ou erro ortográfico
Na Figura 1 é exibido o ciclo de vida do relatório de incidente no Bugzilla.

Após consolidada a submissão do relatório de incidente no referido SRI, as atividades de
verificação da validade do mesmo e definição de quem irá tratar o relatório de incidente é
do responsável pela triagem [Zhou et al. 2014].
Figura 1. Ciclo de Vida do relatório de incidente no Bugzilla [Zhang et al. 2016].
2.2. Mineração de Repositório de SRI

Mineração de Repositório de SRI (MRSRI) é semelhante ao processo de mineração de
dados. As principais atividades e objetos da MRSRI são apresentadas na Figura 2. As
atividades correspondem aos retângulos arredondados e os objetos às bases cilíndricas.
A atividade de pré-processamento corresponde à primeira fase da MRSRI, sendo
que um ou mais tipos de SRI, podem ser fornecidos como entrada para viabilizar a
coleta de dados (relatórios de incidentes) [Jung et al. 2012]. Finalizada a coleta dos
dados, atividades de pré-processamento são conduzidas para transformar os dados em
uma representação adequada para a extração de padrões. Por exemplo, ao pré-processar os
relatórios de incidentes (dados em linguagem natural no formato texto) faz-se necessário
conduzir um conjunto de passos:
91
Figura 2. Fluxo Geral da Mineração de Repositório de SRI.
• Tokenization: objetiva remover caracteres numéricos e sinais de pontuação.

• Remoção das stop-words: preposição, advérbios e outras estruturas (definidas
como stop-words) comumente utilizadas para apoiar a construção de
frases na linguagem humana (a, de, para, até), em geral não agregam
informação no contexto de algoritmos de mineração de relatórios de
incidentes [Lamkanfi et al. 2011]. Em razão disso, a partir de um conjunto de
stop-words definido, todas as stop-words presentes no texto em processamento
são removidas.
• Radicalização (Stemming): visa reduzir cada palavra do texto ao correspondente
radical (denotação mínima e não ambígua do termo). Por exemplo, as palavras
"mostram", mostrar" e "mostrado" podem ser reduzidas para mostr".
• Definição da representação dos dados: um formato adequado dos documentos
textuais necessita ser definido para viabilizar a análise, em geral é construído
uma bag-of-words (representação no modelo espaço vetorial) para atender esse
objetivo. Na qual cada linha representa um documento (relatório de incidente) e
cada coluna representa um atributo.
Para extrair padrões utilizam-se métodos de aprendizado de máquina (AM)
que podem ser divididos em três tipos: supervisionado, não supervisionado e
semissupervisionado. A principal diferença entre eles é o conjunto de exemplos para
treinamento. No aprendizado supervisionado os exemplos do conjunto de treinamento são
rotulados, ou seja, são classificados previamente. Novas ocorrências serão classificadas
com base no que foi apreendido no conjunto de treinamento. Já no aprendizado
não supervisionado não existe rótulo pré-definido para os exemplos do conjunto de
treinamento. A vantagem desse tipo de aprendizado é não depender de informações
rotuladas, porém os erros são maiores. No aprendizado supervisionado a acurácia, em
geral, é maior, entretanto existem cenários em que é difícil ter uma quantidade suficiente
de exemplos rotulados para gerar um bom modelo de classificação.
O aprendizado semissupervisionado também considera um conjunto de exemplos
rotulados, porém a quantidade de exemplos em que os rótulos são conhecidos é
bem inferior e, neste tipo de aprendizado, são necessários métodos específicos para
tratar este cenário. O objetivo do aprendizado semissupervisionado é fazer uso dos
exemplos não rotulados para melhorar o desempenho da classificação. A forma
como os exemplos não rotulados são tratados no aprendizado semissupervisionado
podem resultar em classificação superior a do aprendizado supervisionado, considerando
a mesma quantidade de exemplos rotulados, ou ainda um desempenho equivalente,
92
considerando uma menor quantidade de exemplos rotulados [Zhu and Goldberg 2009,
Chapelle et al. 2006].
Por fim, na atividade de pós-processamento o conhecimento produzido é avaliado
de acordo com métricas específicas. Caso o conhecimento produzido não seja adequado
para utilização, as atividades de pré-processamento serão retomadas com o intuito de
melhorar a qualidade do conhecimento produzido.
2.3. Predição de Severidade de Relatório de Incidente

O processo de atribuição de um rótulo pré-definido à uma instância de dados é conhecido
como classificação automática de documentos, que se trata de uma importante subárea
da mineração de dados [Lamkanfi et al. 2011]. Por exemplo, em uma determinada
empresa, ao receber e-mail de um cliente, o mesmo é classificado e encaminhado
automaticamente para o departamento (financeiro, assistência técnica ou pessoal) mais
adequado para atender à solicitação do cliente. A representação da função de classificação
de documentos é definida da seguinte maneira:
f : Documento → {r1 , · · · , rq } (1)
sendo que no contexto desse estudo, o documento corresponde a um exemplo de relatório

de incidente e {r1 , ..., rq } aos rótulos pré-definidos, ou seja, o tipo de severidade. Esse
processo de classificação de relatório de incidente com relação ao tipo de severidade, é
também conhecido como predição de severidade de relatório de incidente. Existem dois
tipos de predição de severidade: binária (por exemplo, severo ou não severo) e não binária
(por exemplo, blocker, critical, major, minor, normal ou trivial).
Segundo estudo secundário no contexto da predição de severidade de relatório de
incidente conduzido pelos autores, os estudos primários selecionados que investigaram
o desempenho de métodos de classificação para apoiar a predição utilizaram, em sua
maioria, métodos supervisionados, não existindo, assim, estudos que investigam o
impacto de métodos semissupervisionados que sejam de conhecimento dos autores.
3. Definição do Estudo de Viabilidade

Para avaliar a aplicabilidade de métodos semissupervisionados para Predição de
Severidade de relatórios de incidentes, foi proposto o referido estudo para um conjunto
de textos obtidos de repositórios de software instanciando cada etapa do processo de
mineração de textos conforme será apresentado nas subseções seguintes.
3.1. Definição da Questão de Pesquisa

Em particular, pretende-se por meio deste estudo responder à seguinte questão de
pesquisa:
• QP1: Os métodos de aprendizado semissupervisionado são adequados para apoiar
a predição de severidade de relatório de incidente?
3.2. Seleção do Dataset

Neste trabalho, utilizaram-se os dados do repositório SRI disponibilizado por
[Lamkanfi et al. 2013]. Sendo que foram considerados como dados a serem processados
apenas as descrições detalhadas dos relatórios de incidentes. Na Tabela 2 são
93
apresentadas, de forma resumida, as informações das coleções de textos utilizadas.
São apresentadas a descrição do software e a quantidade de documentos (relatório de
incidente) de cada um deles. Deste total de documentos, também é apresentada a
quantidade de documentos referentes a cada tipo de classe de cada coleção. Essa
informação também é importante para avaliar se a quantidade de exemplos rotulados
e/ou o desbalanceamento podem impactar no desempenho da classificação. Os textos
pré-processados e outras informações estão disponíveis em http://sites.labic.
icmc.usp.br/msr-bsp.
Tabela 2. Descrições das Coleções de Textos Utilizadas

Dataset Software no docs Distribuição das Classes por Severidade
BL CR MA NO MI TR
D1 Eclipse-CTD 5640 78 166 490 275 4547 84
D2 Eclipse-JDT 10814 94 274 1000 781 8306 359
D3 Eclipse-PDE 5655 47 117 476 208 4693 114
D4 Eclipse-Platform 24775 415 989 2718 1088 18891 674
D5 Mozilla-Bugzilla 4616 275 176 506 766 2478 415
D6 Mozilla-Firefox 69879 233 6603 9486 47635 4145 1777
D7 Mozilla-Thunderbird 19237 65 1894 2982 1415 12429 452
3.3. Design do Estudo de Viabilidade

3.3.1. Pré-processamento
Na etapa de pré-processamento são realizadas as seguintes tarefas: preparação dos

documentos, extração de termos e seleção de atributos e geração de uma representação
estruturada da coleção de documentos apropriada para os métodos de extração de padrões
utilizados. Neste trabalho, na preparação de documentos, foram realizadas padronização,
remoção das stopwords, radicalização dos termos (stemming) e foram selecionados como
termos os unigramas com frequência maior do que um.
Em relação à representação da coleção de textos foram utilizadas duas
representações: (i) modelo espaço vetorial, bag-of-words (bow) [Tan et al. 2005],
comumente utilizada e (ii) modelo de redes heterogêneas bipartidas [Rossi et al. 2016].
Bag-of-words é uma matriz de documento-termo, em que cada linha representa
um documento, cada coluna representa um termo (palavra) presente na coleção de
documentos e cada célula contém uma medida de frequência da palavra no respectivo
documento. Um exemplo é apresentado na Figura 3(a).
Uma rede heterogênea bipartida pode ser definida por N = (O, E, W), em que O
representa dois conjuntos de objetos da rede (também denominados por nós ou vértices),
E representa o conjunto de conexões (também denominadas relações ou arestas) que
ocorrem apenas a partir de objetos de um conjunto para os objetos do outro conjunto,
e W representa os pesos dessas conexões. Neste estudo O é composto pelos conjuntos de
documentos D e conjunto de termos T . E é composto por conexões eij que representam
que o termo tj está presente no documento di , 0 < i ≤ |D| e 0 < j ≤ |T |. Na Figura 3(b)
pode ser observado um exemplo da representação usando rede bipartida heterogênea.
94
Neste estudo de viabilidade, cada descrição de relatório de incidente extraída dos SRI
é considerada um documento e cada palavra é considerada um termo.
(a) Bag-of-words (bow)
(b) Redes heterogêneas bipartidas
Figura 3. Representações de Textos
3.3.2. Extração de Padrões
Nessa etapa, foram utilizados os principais métodos de aprendizado de máquina

supervisionados e semissupervisionados. Dos métodos supervisionados foram utilizados
um de cada tipo de abordagem: probabilística, baseada aprendizado estatístico, árvores
de decisão e distância.
• Naïve Bayes (NB) [Rish 2001]: este método baseia-se no teorema de Bayes
[Koch 1990] para identificar a classe para a qual um exemplo x tem a maior
probabilidade de estar associado, como dado pela Equação 2.
y = arg maxi P (yi |x) (2)

Para cada termo x é calculada a probabilidade de pertencer a uma determinada
categoria yi . Essa probabilidade P (yi |x) é calculada a partir das ocorrências do
termo x nos documentos de treinamento nos quais as categorias já são conhecidas.
Quando todas essas probabilidades são calculadas, um novo documento pode ser
classificado de acordo com a soma das probabilidades para cada categoria de
cada termo ocorrido dentro do documento. arg maxi retorna a classe com maior
probabilidade de estar associada ao termo x. A presença ou ausência de um termo
em um documento textual pode determinar a predição da categoria.
95
• Multinomial Naïve Bayes (MNB): este classificador é baseado no anterior, porém
a categoria não é determinada apenas pela presença ou ausência de um termo no
documento, mas também pelo número de ocorrências dos termos no documento.
• Support Vector Machines (SVM): este método é baseado em aprendizado
estatísticos desenvolvido por [Vapnik 1995] que estabelece uma série de
princípios que devem ser seguidos na obtenção de classificadores com boa
capacidade de generalização. O resultado deste classificador são hiperplanos entre
vetores de atributos que separam o espaço em várias categorias.
• J48: algoritmo C.45 [Quinlan 1993], este método é baseado em árvores de decisão
que usa a estratégia de divisão e conquista para segmentar recursivamente o espaço
de busca em subespaços, e cada subespaço é ajustado usando diferentes modelos.
As árvores de decisões são simples de entender e interpretar. No entanto, podem
criar árvores tendenciosas se algumas classes dominarem outras.
• k-Nearest Neighbor (kNN): este método é baseado em distâncias entre objetos, a
classificação de um novo objeto é feita considerando os exemplos do conjunto de
treinamento mais próximos a ele. A variação nesse algoritmo é a quantidade de
vizinhos K a serem considerados.
Os métodos semissupervisionados buscam a regularização da rede considerando

duas suposições: (i) dois objetos conectados na rede tendem a ser classificados com o
mesmo rótulo e (ii) os rótulos dos objetos devem estar próximos da informação da classe
real (conjunto de treinamento). A seguir são apresentados os algoritmos para realizar a
regularização em redes heterogêneas bipartidas utilizadas neste estudo de viabilidade,
com suas respectivas funções de regularização. Em cada função de regularização o
primeiro termo está relacionado com a primeira suposição e, analogamente, o segundo
termo descreve a segunda suposição.
• GNetMine [Ji et al. 2010]: este é uma extensão do algoritmo Learning with Local
and Global Consistency (LLGC) [Zhou et al. 2004]. A função de regularização a
ser minimizada por GNetMine é definida pela Equação 3.
2
X X fti f bj X
Q(F) = wti ,bj qP − qP + αti (fti − yti ), (3)

bk ∈B wti ,bk tk ∈T wtk ,bj

ti ∈T bj ∈B ti ∈T L
em que 0 < α < 1 dá a importância para cada termo da Equação 3.

• Label Propagation based on Bipartite Heterogeneous Network
(LPBHN) [Rossi et al. 2016]: este algoritmo é uma extensão do algoritmo
Gaussian Fields e Harmonic Function (GFHF) [Zhu and Goldberg 2009] para
redes heterogêneas bipartidas. Este algoritmo é livre de parâmetro. A função de
regularização a ser minimizada por LPBHN é definida pela Equação 4.
1 X X X
Q(F) = wti ,bj (fti − fbj )2 + lim µ (fti − yti )2 (4)
2 µ→∞
ti ∈T bj ∈B L ti ∈T
há uma restrição que fti = yti , portanto, o segundo termo da Equação 4 tem um
valor que tende ao infinito.
• Tag-based Model (TM) [Yin et al. 2009]: este algoritmo foi proposto
inicialmente para classificar objetos da web conectados a tags sociais. No contexto
96
deste trabalho, a função de regularização a ser minimizada por TM é é definida
pela Equação 5.
X X X X
Q(F) = β ||fbi − ybi ||2 + γ ||fbi − ybi ||2 + wbi ,tj ||fbi − ftj ||2 , (5)
bi ∈BL Bi ∈BU bi ∈B tj ∈T
em que cada parâmetro β e γ controla a importância dada ao termo da Equação 5.

• Transductive Classification based on Bipartite Heterogeneous Network
(TCBHN) [Rossi et al. 2016]: este é um algoritmo que executa otimização e
propagação de rótulo para minimizar a seguinte função de regularização é definida
pela Equação 6.
 2  2
1 X X X 1 X X X
Q(F) = fti ,ck − wti ,bj · fbj ,ck  +  yti ,ck − wti ,bj · fbj ,ck 
2 2
ck ∈C
U ti ∈T bj ∈T L ck ∈C ti ∈T bj ∈B
(6)
3.3.3. Pós-Processamento
Nesta etapa, é conduzida uma avaliação experimental, na qual analisam-se a viabilidade

e impacto do uso de aprendizado semissupervisionado na predição de severidade de
relatórios de incidentes.
Para comparar os resultados da classificação foi utilizada a medida F 1 que
representa a média harmônica das medidas de precisão (Precision) e cobertura (Recall),
em que ambas as medidas têm o mesmo peso (vide Equação 7).
P recision ∗ Recall
F1 = 2 ∗ . (7)
P recision + Recall
A precisão e a cobertura foram calculadas para cada classe na
avaliação multi-classe. A fórmula para cálculo da precisão e da cobertura
de uma classe ci são apresentadas nas Equações 8 e 9, respectivamente:
T Pc i T Pc i
P recisionci = , (8) Recallci = , (9)
T Pc i + F P c i T Pc i + F Nc i
Em que T P (True Positive) significa o número de documentos de teste corretamente
atribuídos à classe ci , F P (False Positive) significa o número de documentos de teste
da classe cj (cj 6= ci ) mas atribuído à classe ci , e F N (False Negative) é o número de
documentos de teste da classe ci atribuído à classe cj (cj 6= ci ).
A medida de precisão é a porcentagem de documentos corretamente classificados
como ci , considerando todos os documentos classificados como ci . A medida de cobertura
é a porcentagem de documentos corretamente classificados como ci , considerando todos
os documentos que realmente pertencem à classe ci .
Duas estratégias foram utilizadas para resumir os resultados de precisão
e cobertura, calculados para cada classe de uma coleção de texto, são elas:
micro-averaging e macro-averaging [Sokolova and Lapalme 2009]. A estratégia de
97
micro-averaging, realiza uma soma dos termos das medidas de avaliação. Portanto, a
precisão e a cobertura com a estratégia de micro-averaging são:
P P
M icro ci ∈C T Pci M icro ci ∈C T Pci
P recision =P , Recall =P .
ci ∈C (T Pci + F Pci ) ci ∈C (T Pci + F Nci )
(10) (11)
A estratégia de macro-averaging realiza a média sobre as medidas de avaliação
para cada classe. Portanto, o precision e o recall com a estratégia de macro-averaging
são:
P P
ci ∈C P recisionci Recallci
P recision M acro
= , Recall M acro
= ci ∈C .
|C| |C|
(12) (13)
As pontuações de micro-averaging são dominadas pelo número de T P . Portanto,
classes grandes dominam classes pequenas em pontuações de micro-averaging. Por outro
lado, a macro-averaging atribui igual peso para cada classe. Nesse caso, o número de
T P em classes pequenas é enfatizado nas pontuações de macro-averaging. Essas duas
estratégias atribuem pontuações diferentes e são complementares entre si. Denotam-se
F 1 calculado por micro-averaging, para precision e recall, como Micro-F 1 , e por
macro-averaging como Macro-F 1 .
Para obter Micro-F 1 e Macro-F 1 , primeiro é realizado um processo de validação
cruzada de 10 execuções. Para cada conjunto de treinamento (9 vezes), foram
realizadas 10 execuções para induzir um modelo de classificação, considerando N
documentos rotulados, selecionados aleatoriamente, em cada execução. Para analisar
o impacto do uso de documentos rotulados, tanto para os algoritmos supervisionados
quanto semissupervisionados, considerou-se uma variação absoluta na quantidade de
documentos rotulados. Foi considerado N = {1, 10, 20, 30, 40, 50} que considera apenas
a quantidade exata de 1 exemplo rotulado de cada classe, 10 exemplos rotulados de cada
classe, e assim sucessivamente.
Esta variação no número de documentos rotulados possibilitou demonstrar melhor
o comportamento dos algoritmos para diferentes números de documentos rotulados, isto é,
um trade-off entre o número de documentos rotulados e o desempenho da classificação e
as diferenças entre os algoritmos de aprendizagem supervisionados indutivos e algoritmos
de aprendizagem semissupervisionados à medida que aumenta o número de documentos
rotulados.
Os exemplos de treinamento restantes foram considerados como exemplos
não rotulados para algoritmos de aprendizagem semissupervisionados. Assim, foram
realizadas 100 execuções e em cada execução foi obtido um valor de acurácia. Os valores
finais de Micro-F 1 e Macro-F 1 apresentados na Seção 5 foram uma média dos 100 valores
obtidos usando validação cruzada 10-folds.
4. Implementação do Estudo de Viabilidade

4.1. Configuração dos Algoritmos de Aprendizagem Utilizados
Foram executados os algoritmos de aprendizagem supervisionados indutivos, citados
na Seção 3.3.2, para análise e comparação com a aprendizagem semissupervisionada.
98
Isso também permite analisar se o uso de documentos não rotulados, realmente
melhora o desempenho da classificação. Para avaliação da execução dos algoritmos
supervisionados foram utilizadas as implementações disponibilizadas na ferramenta
Weka4 . Os parâmetros e considerações dos algoritmos indutivos de aprendizagem
supervisionada são:
• Naïve Bayes (NB): configuração padrão.
• Multinomial Naïve Bayes (MNB): configuração padrão.
• Support Vector Machine (SVM): foi utilizado o algoritmo Sequential Minimal
Optimization (SMO) e foram considerados três tipos de kernel: Linear, Polinomial
(exponente = 2) e RBF (Radial Basis Function). Como o parâmetro C é real
e positivo, alguns autores definem esses valores como 10Y . Para cada tipo de
kernel, foi considerado Y = {−5; −4; −3; −2; −1; 0; 1; 2; 3; 4; 5}.
• J48: neste algoritmo de indução de árvores de decisão, foi utilizado o valor 0, 25
para parâmetro confidence factor.
• k-NN: Foi considerado k = {7; 17; 37; 57} [Rossi et al. 2016]. E também o
algoritmo k-NN, com e sem votação ponderada, que atribui para cada um dos
vizinhos mais próximos um voto de peso igual a (1−s), em que s é uma medida de
similaridade entre vizinhos. Foi utilizado o cosseno como medida de similaridade.
Foram utilizados algoritmos de aprendizagem semissupervisionados baseados
no modelo de redes heterogêneas bipartidas. Os algoritmos e seus parâmetros estão
em [Rossi et al. 2016]. Foram utilizadas todas as soluções iterativas para todos os
algoritmos que possuem soluções iterativas (GNetMine, LPBHN, TCBHN e TM). O
número máximo de iterações foi definido para 1000. Os parâmetros e considerações dos
algoritmos semissupervisionado utilizados neste estudo de viabilidade são definidos a
seguir:
• GNetMine: foi utilizado α = {0.1, 0.3, 0.5, 0.7, 0.9}.
• Label Propagation using Bipartite Heterogeneous Networks (LPBHN): este é
um algoritmo de aprendizagem semissupervisionado sem parâmetros.
• Tag-based Model (TM): foram utilizados β = {0.1, 1, 10, 100, 1000}, e γ =
{0.1, 1, 10, 100, 1000}.
• Transductive Categorization based on Bipartite Heterogeneous Networks
(TCBHN): foi considerada a solução iterativa de TCBHN, apresentada em
[Rossi et al. 2016]. Esta solução utiliza dois parâmetros o η (taxa de correção de
erro) e o ǫ (erro quadrático mínimo). Foram utilizados η = {0.01, 0.05, 0.1, 0.5},
ǫ = 0.01, 10 como o número máximo de iterações globais e 100 como número
máximo de iterações locais, o que dá um total de 1000 iterações.
5. Resultados Obtidos
Conforme critérios e configurações experimentais definidos anteriormente, os resultados
obtidos para cada uma dos conjuntos de dados são apresentados nos gráficos da Figura 4.
Nos gráficos as linhas contínuas indicam os resultados dos métodos supervisionados e as
linhas tracejadas indicam os métodos semissupervisionados.
Nesse estudo não se destacou um método de aprendizado que produziu resultados
superiores em ambas as medidas e em todos os conjuntos de dados. Com exceção, do
4
Weka: http://www.cs.waikato.ac.nz/ml/weka/
99
método supervisionado SVM que apresentou valores finais de Micro-F 1 e Macro-F 1
superiores no dataset D7 (como pode ser observado na Figura 4(g)). Naturalmente, os
métodos supervisionados deveriam apresentar melhores resultados, uma vez que possuem
mais informações rotuladas. Porém, o processo de rotular tem um custo alto e nem sempre
temos dados rotulados suficientes para gerar um bom modelo de classificação. Quando
se tem poucos exemplos rotulados, pode-se observar que algoritmos supervisionados não
apresentaram um bom desempenho. Nos datasets D2 (Figura 4(b)), D3 (Figura 4(c)) e
D5 (Figura 4(e)) os métodos semissupervisionados apresentaram resultados de Micro-F 1
superiores aos métodos supervisionados quando se tem poucos exemplos rotulados,
respondendo assim a questão de pesquisa (QP1).
Os riscos à validade dos resultados desse estudo são classificados em dois tipos:
• Validade interna: Como foram selecionados apenas relatórios de incidentes
com status “resolvido” (devido esses representarem relatórios de incidentes que
percorreram todo o ciclo de vida), o modelo de predição proposto não considerou
relatórios de incidentes imaturos, tais como os recém criados pelos stakeholders.
Essa restrição pode oferecer impacto no desempenho do modelo proposto.
• Validade externa: Os resultados desse estudo não podem ser generalizados para
software proprietários, visto que nesse foram analisados somente projetos de
software Open Source. Tendo em vista que todos os relatórios de incidentes
utilizados nesse foram extraídos do repositório Bugzilla, os resultados do presente
estudo também não podem ser generalizados para outros SRI.
Lamkanfi et al. (2010) propôs o primeiro modelo de predição automática de severidade
binária (severo ou não severo) de relatório de incidente, no qual são utilizados algoritmos
de mineração de texto que analisam as descrições textuais dos relatórios de incidentes
para apoiar a predição de severidade. Os autores concluíram que com pelo menos
500 registros por tipo de severidade pertencentes ao conjunto de treinamento do
modelo, é possível predizer a severidade de um relatório de incidente com razoável
acurácia [Lamkanfi et al. 2010].
Como evolução do estudo anterior, Lamkanfi et al. (2011) realizaram
outro estudo comparativo entre quatro algoritmos de mineração de texto (Naive
Bayes, Multinomial Naïve Bayes, K-Nearest Neighbor e Support Vector Machines)
utilizando a mesma amostra de dados, e identificaram que o algoritmo Multinomial
Naïve Bayes oferece uma melhor acurácia para a predição binária dos relatórios de
incidentes [Lamkanfi et al. 2011]. Neste estudo de viabilidade também utilizou-se a
descrição textual dos relatórios de incidentes como dados de entrada para o modelo de
predição de severidade, no entanto utilizou-se a representação de dados baseada em redes
heterogêneas bipartidas.
Considerando que existem diferentes tipos de severidade de relatório de incidente,
Tian et al. (2012) a partir de funções de similaridade de documentos (BM25F e BM25F
ext), propuseram um modelo de predição de severidade não binário que considera os
cinco principais tipos de severidade (blocker, critical, major, minor e trivial). Por meio
do referido modelo proposto, os autores conseguiram obter melhorias comparado com
outras propostas de classificação de severidade binária [Tian et al. 2012]. Neste estudo de
100
D1 D1 D2 D2
0.5 0.3 0.4 0.25
0.45 0.35
0.25
0.4 0.2
0.3
0.35 0.2
0.25 0.15
0.3
Micro F1
Micro F1
Macro F1
Macro F1
0.15 0.2
0.25
0.15 0.1
0.2 0.1
0.1
0.15 0.05
0.05
0.1 0.05
0.05 0 0 0
1 10 20 30 40 50 1 10 20 30 40 50 1 10 20 30 40 50 1 10 20 30 40 50
Número de Exemplos Rotulados Número de Exemplos Rotulados
(a) Eclipse-CTD (D1) (b) Eclipse-JDT (D2)

D3 D3 D4 D4
0.6 0.25 0.35 0.3
0.5 0.3 0.25

0.2
0.25
0.4 0.2
0.15
0.2
Micro F1
Micro F1
Macro F1
Macro F1
0.3 0.15
0.15
0.1
0.2 0.1
0.1
0.05
0.1 0.05 0.05
0 0 0 0
1 10 20 30 40 50 1 10 20 30 40 50 1 10 20 30 40 50 1 10 20 30 40 50
(c) Eclipse-PDE (D3) (d) Eclipse-Platform (D4)

D5 D5 D6 D6
0.35 0.4 0.35 0.35
0.3 0.35 0.3 0.3

0.3
0.25 0.25 0.25
0.25
0.2 0.2 0.2
Micro F1
Micro F1
Macro F1
Macro F1
0.2
0.15 0.15 0.15
0.15
0.1 0.1 0.1
0.1
0.05 0.05 0.05 0.05
0 0 0 0
1 10 20 30 40 50 1 10 20 30 40 50 1 10 20 30 40 50 1 10 20 30 40 50
(e) Mozilla-Bugzilla (D5) (f) Mozilla-Firefox (D6)

D7 D7
0.35 0.35
0.3 0.3
0.25 0.25
0.2 0.2
Micro F1
Macro F1
0.15 0.15
0.1 0.1
0.05 0.05
0 0
1 10 20 30 40 50 1 10 20 30 40 50
Número de Exemplos Rotulados
Número de Exemplos Rotulados
(g) Mozilla-Thunderbird (D7)
Figura 4. Resultados
viabilidade avaliou-se apenas a predição de severidade não binária a partir da aplicação

de algoritmos de semissupervisionados.
7. Conclusões
O presente trabalho viabilizou um estudo comparativo entre as abordagens de
aprendizagem supervisionada e semissupervisionada no contexto da predição de
severidade de relatório de incidente. Após analisar os resultados, constata-se que
com o uso de redes heterogêneas bipartidas e métodos semissupervisionados foram
obtidos resultados promissores no estudo. Considerando que o processo de rotulagem
101
de relatório de incidente dependendo da quantidade exige muito tempo de dedicação
dos desenvolvedores, a combinação entre a representação dos dados e os algoritmos
semissupervisionados utilizados demonstrou a aplicabilidade dos mesmos no contexto
da predição de severidade de relatório de incidente. Em resumo, ressaltam-se as seguintes
contribuições:
• Investigação pioneira ao utilizar algoritmos semissupervisionados para classificar
a severidade de relatórios de incidentes.
• Definição de um baseline para viabilizar futuras comparações com outras
estratégias/algoritmos.
• Disponibilização dos dados e resultados para análise e consulta pública.
No presente estudo, considerou-se o impacto de métodos semissupervisionados
apenas na classificação de severidade não binária. Faz-se necessário avaliar o desempenho
dos mesmos na classificação binária. Além disso, outras questões podem ser exploradas
para melhorar a classificação tais como: (i) avaliar o uso de técnicas de balanceamento
das classes; (ii) usar técnicas para enriquecimento das representações de textos; (iii)
propor novas representações de textos para o domínio específico na predição de severidade
de relatórios de incidentes; (iv) avaliar o tamanho do conjunto de exemplos rotulados
em relação ao percentual do tamanho dos datasets; (v) avaliar como os exemplos
não rotulados podem melhorar o desempenho da classificação; e (vi) utilizar dados de
produtos proprietários com o intuito de comparar o comportamento dos modelos de
predição utilizados em outro contexto.
Referências
[Chapelle et al. 2006] Chapelle, O., Schölkopf, B., and Zien, A., editors (2006).
Semi-Supervised Learning. MIT Press.
[Ji et al. 2010] Ji, M., Sun, Y., Danilevsky, M., Han, J., and Gao, J. (2010). Graph
regularized transductive classification on heterogeneous information networks. In
Proc. of the European Conf. on Machine Learning and Knowledge Discovery in
Databases, pages 570–586. Springer-Verlag.
[Jung et al. 2012] Jung, W., Lee, E., and Wu, C. (2012). A survey on mining software
repositories. IEICE Transactions on Information and Systems, E95.D(5):1384–1406.
[Koch 1990] Koch, K.-R. (1990). Bayes’ theorem. In Bayesian Inference with Geodetic
Applications, pages 4–8. Springer.
[Lamkanfi et al. 2010] Lamkanfi, A., Demeyer, S., Giger, E., and Goethals, B. (2010).
Predicting the severity of a reported bug. In 2010 7th IEEE Working Conference on
Mining Software Repositories (MSR 2010), pages 1–10.
[Lamkanfi et al. 2011] Lamkanfi, A., Demeyer, S., Soetens, Q. D., and Verdonck, T. (2011).
Comparing mining algorithms for predicting the severity of a reported bug. In
2011 15th European Conference on Software Maintenance and Reengineering, pages
249–258.
[Lamkanfi et al. 2013] Lamkanfi, A., Pérez, J., and Demeyer, S. (2013). The eclipse and
mozilla defect tracking dataset: a genuine dataset for mining bug information. In 2013
10th Working Conference on Mining Software Repositories (MSR), pages 203–206.
102
[Quinlan 1993] Quinlan, J. R. (1993). C4.5:Programs for Machine Learning, volume 1.
M.Kaufmann.
[Rish 2001] Rish, I. (2001). An empirical study of the naive bayes classifier. In
IJCAI-Workshop Empirical Methods in Artificial Intelligence, volume 3, pages 41–46.
IBM New York.
[Rossi et al. 2016] Rossi, R. G., Lopes, A. A., and Rezende, S. O. (2016). Optimization
and label propagation in bipartite heterogeneous networks to improve transductive
classification of texts. Information Processing & Management, 52(2):217 – 257.
[Saha et al. 2015] Saha, R. K., Lawall, J., Khurshid, S., and Perry, D. E. (2015). Are these
bugs really normal? In 2015 IEEE/ACM 12th Working Conference on Mining Software
Repositories, pages 258–268.
[Shull et al. 2001] Shull, F., Carver, J., and Travassos, G. H. (2001). An empirical
methodology for introducing software processes. In Proceedings of the 8th European
Software Engineering Conference Held Jointly with 9th ACM SIGSOFT International
Symposium on Foundations of Software Engineering, ESEC/FSE-9, pages 288–296,
New York, NY, USA. ACM.
[Sokolova and Lapalme 2009] Sokolova, M. and Lapalme, G. (2009). A systematic
analysis of performance measures for classification tasks. Information Processing &
Management, 45(4):427–437.
[Tan et al. 2005] Tan, P.-N., Steinbach, M., and Kumar, V. (2005). Introduction to Data
Mining. Addison-Wesley.
[Tian et al. 2012] Tian, Y., Lo, D., and Sun, C. (2012). Information retrieval based nearest
neighbor classification for fine-grained bug severity prediction. In 19th Working
Conference on Reverse Engineering, pages 215–224.
[Vapnik 1995] Vapnik, V. N. (1995). The nature of statistical learning theory.
[Xia et al. 2015] Xia, X., Lo, D., Shihab, E., Wang, X., and Yang, X. (2015). Elblocker:
Predicting blocking bugs with ensemble imbalance learning. Information and Software
Technology, 61:93 – 106.
[Yin et al. 2009] Yin, Z., Li, R., Mei, Q., and Han, J. (2009). Exploring social tagging graph
for web object classification. In Proc. of the Int. Conf. on Knowledge Discovery and
Data Mining, pages 957–966.
[Zhang et al. 2016] Zhang, T., Chen, J., Yang, G., Lee, B., and Luo, X. (2016). Towards
more accurate severity prediction and fixer recommendation of software bugs. J. Syst.
Softw., 117(C):166–184.
[Zhou et al. 2004] Zhou, D., Bousquet, O., Lal, T. N., Weston, J., and Schölkopf, B. (2004).
Learning with local and global consistency. In Advances in Neural Information
Processing Systems, volume 16, pages 321–328.
[Zhou et al. 2014] Zhou, Y., Tong, Y., Gu, R., and Gall, H. (2014). Combining text mining
and data mining for bug report classification. In 2014 IEEE International Conference
on Software Maintenance and Evolution, pages 311–320.
[Zhu and Goldberg 2009] Zhu, X. and Goldberg, A. B. (2009). Introduction to
semi-supervised learning. Morgan and Claypool Publishers.
103
Inferência da Familiaridade de Código por Meio da
Mineração de Repositórios de Software
Irvayne Matheus de Sousa Ibiapina1 , Francisco Vanderson de Moura Alves1 ,
Werney Ayala Luz Lira1 , Gleison de Andrade e Silva1 ,
Pedro de Alcântara dos Santos Neto1
1
LOST - Laboratory Of Software Technology
DC - Departamento de Computação
CCN - Centro de Ciências da Natureza
UFPI - Universidade Federal do Piauı́
irvaynematheus@gmail.com, vanderson.moura.vm@gmail.com
werney.zero@gmail.com, gleisondeandradeesilva@gmail.com
pasn@ufpi.edu.br
Abstract. The software development process is complex and, for this reason,
it is common to execute it as a team. But teamwork can generate problems
for an organization. One of these problems is the presence of portions of code
known only by a single developer (or a small group). This fact can cause great
difficulty in software maintenance. This paper presents a set of metrics and
a tool called CoDiVision, that performs a data mining of code repositories to
infer the familiarity that each developer has with the project. The CoDiVision
was evaluated through the analysis of medium and large projects and the results
indicate that the metrics and the tool can be an important support in software
development.
Resumo. O processo de desenvolvimento de software é algo complexo e, por

esse motivo, é comum realizá-lo em equipe. Porém, o trabalho em equipe pode
gerar problemas para uma organização. Um desses problemas é a existência
de porções de código conhecidas apenas por um único desenvolvedor (ou por
um grupo reduzido). Esse fato pode gerar grande dificuldade na manutenção de
software. Por conta disso, é apresentado neste trabalho um conjunto de métricas
e uma ferramenta, intitulada CoDiVision, que realiza mineração de dados de
repositórios de código para inferir a familiaridade de cada desenvolvedor a um
projeto. A CoDiVision foi avaliada por meio da análise de projetos de médio
e grande porte e os resultados obtidos indicam que as métricas e a ferramenta
podem ser importantes aliados ao desenvolvimento de software.
1. Introdução
O desenvolvimento de software é composto por várias atividades. Durante a
implementação (ou codificação) é comum que a equipe participante de um projeto seja
subdividida em grupos, de tal forma que cada grupo se responsabilize por uma parte es-
pecı́fica do produto. Porém, essa divisão do trabalho pode levar ao “domı́nio” de parte do
software, ou seja, do código associado a essa parte, por apenas um grupo de pessoas, ou
104
em um nı́vel mais extremo, por apenas uma única pessoa. Desse fato decorre, por exem-
plo, a dificuldade de manutenção do software, sendo exigido que tal pessoa participe de
toda e qualquer ação que envolva a parte do software de sua “propriedade” [Teles 2004].
Outro complicador associado a esse fato é o comprometimento da qualidade e legibili-
dade do código, uma vez que existe, fundamentalmente, apenas uma opinião sobre uma
área especı́fica de um projeto.
As metodologias ágeis se preocupam de forma explı́cita com essa questão, tanto
que prescrevem a necessidade de que o código seja coletivo, incentivando assim que várias
pessoas atuem nas mais variadas áreas, ao mesmo tempo em que incentiva o trabalho
em pares, permitindo assim que mais de uma pessoa esteja associada a todo e qualquer
código desenvolvido. Além disso, o fato de prescrever o desenvolvimento guiado por
testes e refatoração contı́nua promove uma maior coletividade de código, evitando assim
o “domı́nio” de partes do software por um desenvolvedor ou por um pequeno grupo de
desenvolvedores [Beck et al. 2001].
Neste trabalho são apresentadas novas métricas e uma ferramenta, intitulada Co-
DiVision, para inferir a familiaridade de desenvolvedores em projetos de desenvolvimento
de software. Por meio da sua utilização é possı́vel descobrir quais desenvolvedores pos-
suem mais familiaridade com cada região do projeto. Para que isso seja possı́vel são
utilizadas técnicas de Mineração de Repositórios de Software [Hassan 2008]. A partir
da mineração são obtidas as contribuições de cada desenvolvedor no projeto, que são as
linhas e arquivos adicionados, modificados e até mesmo removidos do projeto.
Com base nessas informações foram criadas métricas que tem como objetivo mo-
delar a familiaridade dos desenvolvedores considerando um contexto real. Por meio das
métricas procura-se representar fatos decorrentes do desenvolvimento de software e da
própria natureza humana, como um outro desenvolvedor realizar alterações no seu código,
ou o “esquecimento” de parte das alterações feitas no decorrer do tempo desde a última
alteração feita, ou ainda, o não reconhecimento de algumas contribuições em virtude de
terem sido feitas após a ultima alteração daquele desenvolvedor.
Quando alguém está familiarizado com algo, ele possui um entendimento sobre
esse algo. Assim, por mais que ele esteja sem contato com esse algo, pouco tempo
de contato o torna conhecedor novamente. Familiaridade de código tem essa mesma
interpretação neste trabalho. Um desenvolvedor com familiaridade em um código conse-
gue relembrar dos detalhes envolvidos na implementação com pouco tempo de interação.
A familiaridade é obtida quando um desenvolvedor já trabalhou no código, seja criando
ou alterando. Quanto mais ı́ntimo do código, mais familiaridade terá e mais facilidade
para trabalhar com o trecho em questão.
As informações sobre a familiaridade dos desenvolvedores podem apoiar na to-
mada de decisões em diversas situações durante o processo de desenvolvimento de soft-
ware. Dentre elas, podemos destacar a etapa de distribuição de tarefas entre desenvolve-
dores. Essa distribuição pode ser feita com dois objetivos: agilizar a execução de tarefas,
atribuindo-as àqueles desenvolvedores com maior familiaridade em partes do código re-
lacionada a cada tarefa; sugerir uma melhor distribuição de tarefas para equilibrar a fami-
liaridade dos desenvolvedores, visando a redução de possı́veis problemas que podem ser
ocasionados, a fim de melhorar o processo de desenvolvimento de software e consequen-
105
temente a qualidade do produto gerado.
Este trabalho está organizado da seguinte forma: a Seção 2 apresenta alguns con-
ceitos sobre sistemas de versionamento; a Seção 3 apresenta alguns estudos relacionados
ao tema; na Seção 4 são apresentadas as métricas para inferir a familiaridade; na Seção
5 são detalhadas as principais informações sobre a ferramenta CoDiVision; na Seção 6
são apresentados resultados obtidos após a aplicação da ferramenta na análise de projetos
privados. Na Seção 7 são discutidas ameaças à validade das métricas propostas. Por fim,
a Seção 8 apresenta as conclusões a respeito deste trabalho.
2. Sistemas de Controle de Versão

Um Sistema de Controle de Versão (SCV) ou VCS (do inglês Version Control System)
consiste, basicamente, em um local para armazenamento de artefatos gerados durante
o desenvolvimento de sistemas de software [Mason 2005], permitindo também um fácil
compartilhamento de código entre a equipe de desenvolvimento. Além disso, esses sis-
temas de controle de versão mantêm um registro das operações feitas no projeto e o de-
senvolvedor responsável por cada modificação realizada. A cada nova modificação feita
sobre um arquivo ou conjunto de arquivos é gerada uma nova versão [Spinellis 2005], ou
seja, um novo estado do projeto. Com isso, caso alguma alteração precise ser desfeita,
basta apenas retornar à uma versão anterior.
Esses sistemas podem ser classificados em sistemas centralizados ou distribuı́dos,
cada um destes tipos de sistemas possui caracterı́sticas diferentes. Porém, alguns termos
e caracterı́sticas em comum também são encontradas em ambos os modelos de sistema de
versionamento:
• Checkout: Normalmente é usado para denominar o primeiro download de todos
os arquivos do projeto a partir do repositório de código principal;
• Commit: É o envio das modificações feitas por cada desenvolvedor ao repositório;
• Update: É a atualização da cópia local de trabalho através do download das
modificações contidas no repositório;
• Merge: É a mesclagem entre versões diferentes, com o objetivo de gerar uma
versão que agregue todas as alterações realizadas;
• Branch: É uma versão paralela ou alternativa a uma versão existente. Novos
branchs não substituem versões anteriores, e são usados concorrentemente em
configurações alternativas.
Seja no modelo centralizado ou distribuı́do, o repositório em Sistemas de Controle
de Versão armazena todo o histórico de evolução do projeto. Informações como quais
artefatos foram modificados, adicionados, deletados e data de cada uma destas operações
são registradas pelo SCV. Outra das várias informações importantes armazenadas por
esses sistemas é a identificação do desenvolvedor responsável por gerar cada revisão do
projeto ao longo do desenvolvimento.
Neste trabalho, a modelagem da familiaridade em projetos de software é realizada por
meio da avaliação das operações (adição, deleção e modificação) sobre o código-fonte re-
alizadas pelos desenvolvedores durante o processo de desenvolvimento. Alguns trabalhos
106
que utilizam mineração de dados de repositórios de código visando avaliar as ativida-
des realizadas por desenvolvedores foram feitos. Além das operações feitas sobre linhas
de código, outras atividades também foram avaliadas em diferentes estudos, tais como o
número de aquivos criados ou modificados, e o número total de commits. Essas atividades
podem indicar informações relevantes acerca de um projeto.
Em [Meng et al. 2013] os autores utilizam mineração de dados a partir de repo-
sitórios de código de um SCV. São apresentados dois modelos que visam determinar
autoria de código sobre linhas de arquivo. Para determinar autoria sobre cada linha de
código, esses modelos levam em conta a última modificação sobre o arquivo e o histórico
de modificações sobre cada linha ao decorrer do desenvolvimento. Antes da utilização
destes modelos é criado um esquema de representação em formato de grafo do repo-
sitório de código utilizado. No grafo gerado estarão informações sobre as revisões do
projeto e desenvolvedores responsáveis por gerar uma dada revisão, bem como as versões
de código geradas em cada revisão. Os modelos apresentados foram comparados com
modelos de autoria em nı́vel de arquivo existentes. Foi verificado que os modelos pro-
postos obtiveram melhores resultados para o conjunto de dados utilizado na análise de
autoria de código. Diferentemente da abordagem apresentada, a ferramenta desenvolvida
neste trabalho apresenta métricas cujo objetivo é estimar a familiaridade de código sobre
um arquivo ou módulos de software, de acordo com as operações sobre linhas de código,
com ponderações diferentes para cada tipo de alteração.
Em [Fritz et al. 2014] é apresentado um modelo para definição do grau de conhe-
cimento dos desenvolvedores sobre entidades(classes, por exemplo) de código do pro-
jeto. Esse modelo utiliza como base uma métrica principal chamada DOK (Degree-of-
Knowledge) que é definida como base em duas outras métricas: DOI (Degree-of-Interest)
e DOA (Degree-of-Authorship). A métrica DOI representa a quantidade de seleções e
edições que um desenvolvedor especı́fico realizou sobre uma entidade de código, e au-
menta à medida que desenvolvedor continua interagindo com essa parte de código e é de-
teriorado gradualmente à medida que essa interação deixa de acontecer, ou seja, o grau de
interesse começa a diminuir a partir da interação do desenvolvedor com outras entidades
de código. A métrica DOA tem como objetivo determinar a autoria sobre uma entidade
de código e é baseada em três métricas auxiliares FA (first authorship), DL (number of
deliveries) e AC (number of acceptances). A métrica FA indica se um determinado desen-
volvedor é ou não o primeiro autor de uma entidade de código especı́fica. O valor de DL
indica o número de interações feitas por um desenvolvedor sobre um arquivo. O valor de
AC indica o número de interações realizadas por outros desenvolvedores sobre o mesmo
arquivo. Com isso, a métrica principal DOK é definida e visa modelar o conhecimento de
um desenvolvedor sobre uma entidade de código. Esse estudo se assemelha com o que
é apresentado neste trabalho. Contudo, a métrica principal implementada na ferramenta
Codivision busca estimar a familiaridade sobre o projeto considerando as alterações de
código em um nı́vel de granularidade menor, ou seja, são consideradas também interações
que representam alterações em linhas de código.
Os autores em [Moura et al. 2014] também utilizam SCV para extração de novas
métricas formuladas sob operações (em nı́vel de linha e arquivo) de adição, eliminação
e modificações realizadas por desenvolvedores em arquivos do projeto. As métricas ex-
traı́das são utilizadas para representar o montante de operações individuais realizadas pela
107
equipe de desenvolvimento. Duas abordagens de comparação entre desenvolvedores são
apresentadas. A primeira delas visa agrupá-los por classes hierarquicamente dominadas;
a segunda mostra a similaridade entre os desenvolvedores a partir de uma apresentação
gráfica. Um estudo de caso foi realizado em um projeto real de desenvolvimento de
software. Os resultados obtidos foram apresentados ao gerente de projeto por meio de
um questionário e segundo o gerente os resultados estariam muito próximos do espe-
rado. Neste trabalho, as métricas criadas e que foram implementadas na ferramenta pro-
posta, avaliam as operações arquivos e linhas de código de maneira integrada, tal que seja
possı́vel modelar de forma mais precisa a familiaridade de código dos desenvolvedores.
4. Familiaridade de Código
As métricas criadas para estimar a familiaridade dos desenvolvedores baseiam-se princi-
palmente nas alterações realizadas sobre o projeto. Essas alterações podem ser analisadas
de duas maneiras diferentes. O primeiro tipo de análise é feito com base em um arquivo
alterado como um todo. Por exemplo, ao modificar qualquer parte de um arquivo, isso
conta como uma alteração, mesmo que tenha sido alterado 1 (uma) ou várias linhas de
código. A segunda maneira, consiste em identificar cada linha alterada em um arquivo.
Essas alterações podem ser de três tipos: adição, deleção ou modificação. As linhas alte-
radas em cada arquivo dos commits podem ser obtidas por meio de uma operação de diff.
A Figura 1 mostra um exemplo de diff.
Figura 1. Exemplo de diff.
As duas primeiras linhas (“—” e “+++”) indicam o arquivo do qual está sendo
feito o diff e a versão desse arquivo. Em seguida, podem ocorrer um ou mais trechos que
iniciam com “@@” que apresentam a linha inicial do trecho que segue e a quantidade de
linhas desse trecho na versão anterior (“-”) e na versão atual (“+”) do arquivo respecti-
vamente. Em seguida são exibidas as linhas adicionadas na versão atual (“+”), as linhas
que existiam na versão anterior, mas foram removidas na versão atual (“-”) e as linhas
inalteradas. No exemplo da Figura 1 podemos identificar que o Arquivo A foi alterado
entre duas revisões X e Y. Essas alterações ocorreram no trecho iniciado na linha 10, que
possuı́a 1 linha na revisão X e passou a ter 2 linhas na revisão Y. Nesse trecho houve uma
deleção da linha 1 seguida de duas adições, caracterizada pela linha 1.1 e a linha 2.
O diff representa a diferença entre duas versões de um arquivo, porém o resul-
tado dessa operação apresenta apenas as linhas que foram adicionadas e removidas, não
108
identificando quais dessas linhas foram modificadas. Uma modificação pode ser classi-
ficada em duas formas: uma delas é considerar qualquer adição ou deleção como uma
modificação, o que resultaria na soma desses dois indicadores. Outra maneira é conside-
rar uma modificação como sendo um conjunto de linhas deletadas imediatamente seguida
por um conjunto (de mesmo tamanho) de linhas adicionadas. Esta última estratégia é a
utilizada neste trabalho.
Contudo, a ferramenta CoDiVision tenta identificar que pares deleção/adição re-
almente caracterizam uma modificação. Para tal, é utilizado o algoritmo de Levenshtein
[Sankoff and Kruskal 1983], que calcula a diferença entre duas cadeias de caracteres. O
cálculo é baseado no número de operações necessárias para transformar uma cadeia em
outra. Desse modo, o algoritmo recebe dois parâmetros de entrada: a linha marcada
como deletada e a respectiva linha adicionada. O retorno do algoritmo é um valor inteiro
e caso este valor represente menos de 25% do tamanho da cadeia de caracteres que re-
presenta a linha de código adicionada, a operação deleção/adição implicará realmente em
uma modificação, pois a diferença nessa linha de uma versão para outra é bem pequena
(menos de 25%).
4.1. Ponderação por Tipo de Alterações

É importante notar que cada tipo de alteração demanda um esforço diferente para realizá-
la. Por exemplo, geralmente é mais simples remover uma linha de um arquivo do que
adicionar uma nova linha. Desse modo, percebeu-se a necessidade de atribuir pesos a
cada tipo de alteração, com a finalidade de balancear o nı́vel de contribuição ao projeto
associado a cada tipo de alteração. O cálculo das alterações realizadas de acordo com
seus respectivos pesos é dado pela Equação 1.
Como já foi explicado anteriormente, são considerados três tipos de alterações
(adição, modificação, deleção). Além desses três tipos, são consideradas também as
alterações realizadas em linhas contendo comandos condicionais (como ”Se... Então”,
por exemplo), pois acredita-se que esses tipos de alterações são mais significativas.
W (d, a(v)) = (ADDd,a(v) ∗ WADD ) + (M ODd,a(v) ∗ WM OD ) +

(1)
(DELd,a(v) ∗ WDEL ) + (CON Dd,a(v) ∗ WCON D )
Onde:
• W (d, a(v)): é o valor da quantidade de alterações realizadas pelo desenvolvedor
d na versão v do arquivo a após a aplicação dos respectivos pesos;
• ADD: é a quantidade de linhas adicionadas pelo desenvolvedor d na versão v do
arquivo a;
• M OD: é a quantidade de linhas modificadas pelo desenvolvedor d na versão v do
arquivo a;
• DEL: é a quantidade de linhas apagadas pelo desenvolvedor d na versão v do
arquivo a;
• CON D: é a quantidade de linhas contendo instruções condicionais alteradas pelo
desenvolvedor d na versão v do arquivo a;
• WADD : é o peso associado às adições;
109
• WM OD : é o peso associado às modificações;
• WDEL : é o peso associado às deleções;
• WCON D : é o peso associado às condições.
4.2. Degradação por Tempo
Algo bastante comum do ser humano é esquecer de algo que tenha realizado com o passar
do tempo, ou seja, o indivı́duo “perde” parte do conhecimento adquirido. Quando se
trata de código isso não é diferente. Um desenvolvedor que fique por muito tempo sem
alterar um código tem seu conhecimento degradado, exigindo um esforço maior para uma
manutenção nessa parte do projeto.
A métrica de degradação por tempo pretende simular justamente o esquecimento,
como algo natural do ser humano. Essa degradação é calculada da seguinte maneira.
Um pequeno valor, que aumenta de acordo com a quantidade de dias passados, desde a
data do commit, é subtraı́do da quantidade total de contribuições ao projeto feitas pelo
desenvolvedor. O que foi descrito pode ser observado na Equação 2.
T (d, a(v)) = W (d, a(v)) ∗ {1 − [(Datual − Dv ) ∗ Pt ]} (2)
Onde:
• T (d, a(v)): é o valor da quantidade de alterações realizadas pelo desenvolvedor d
na versão v do arquivo a após a aplicação da degradação por tempo;
• W (d, a): é o valor calculado na Equação 1;
• Datual : é a data da realização do cálculo;
• Dv : é a data em que foi gerada a versão v;
• Pt : Porcentagem aplicada sobre o tempo decorrido (fator de esquecimento).
4.3. Degradação por Nova Alteração
A familiaridade que um membro da equipe possui sobre um arquivo pode ser determi-
nado pela quantidade de alterações feitas por ele. Mas é importante observar que como
o projeto é desenvolvido em equipe, vários usuários podem alterar os mesmos arquivos
constantemente. Como consequência disso, as alterações feitas por um membro podem
ser sobrescritas por outro membro, ou até mesmo pode adicionar um novo conteúdo e
com isso a familiaridade inicial acerca do arquivo pode não ser o mesmo depois dessas
várias alterações pelas quais o arquivo passou.
Semelhante ao que ocorre com a degradação por tempo, a métrica de degradação
por nova alteração pretende simular o impacto dessas novas alterações, feitas por outros
membros da equipe, na familiaridade acerca desse arquivo, para o membro que fez as
alterações anteriores. Para isso, um pequeno valor é subtraı́do da quantidade total de
alterações, baseado na quantidade de alterações realizadas por outros desenvolvedores,
após a versão do arquivo que está sendo feito o cálculo. Esse calculo pode ser observado
na Equação 3 onde F representa justamente a quantidade de alterações relatada anterior-
mente.
N (d, a(v)) = T (d, a(v)) ∗ [1 − (F ∗ Pn )] (3)
Onde:
110
• N (d, a(v)): é o valor da quantidade de alterações realizadas pelo desenvolvedor d
na versão v do arquivo a após a aplicação da degradação por nova alteração;
• T (d, a(v)): é o valor calculado na Equação 2;
• F : é a quantidade de vezes que o arquivo a foi alterado por um desenvolvedor
x 6= d em versões y > v;
• Pn : é a porcentagem aplicada sobre a quantidade de novas alterações.
4.4. Truck Factor
A partir do cálculo das métricas utilizadas neste trabalho, para a estimação da famili-
aridade dos desenvolvedores sobre o código, é possı́vel também calcular uma métrica
auxiliar, conhecida como Truck Factor (TF) [Torchiano et al. 2011]. Sua definição é de
certa forma uma brincadeira com os desenvolvedores e pode ser entendida como “a quan-
tidade de pessoas que precisam ser atropeladas por um caminhão para que o projeto entre
em apuros” (daı́ a denominação truck factor). Quanto menor esse número, maior são os
riscos para o projeto. Por exemplo, em uma equipe que possua TF com valor 1, caso
esse membro entre de férias ou adoeça e tenha que se ausentar por alguns dias, provavel-
mente o projeto sofreria grandes problemas, seguindo em um ritmo bem desacelerado se
comparado ao perı́odo em que o desenvolvedor com maior familiaridade esteja presente.
Essa métrica leva em consideração um limiar definido previamente, e é determi-
nada com base nos desenvolvedores que mantêm os maiores nı́veis de familiaridade. Por
exemplo, se for definido um limiar de 75% e a soma dos nı́veis de familiaridade dos n
primeiros desenvolvedores (ordenados de forma decrescente pelo nı́vel estimado de fami-
liaridade no projeto) atingir esse limiar, então o valor de TF será n.
5. Ferramenta CoDiVision
A CoDiVision é uma ferramenta para visualização da familiaridade que cada membro da
equipe tem em relação ao código do projeto que desenvolve. Ela pode ser acessada no
endereço: http://easii.ufpi.br/codivision/. A familiaridade é estimada
por meio das alterações, que podem ser caracterizadas por uma operação de remoção,
adição e modificação de arquivos e linhas de código, realizadas sobre o código-fonte. As
Figuras 2 e 3 apresentam as principais páginas referentes à interface gráfica da ferramenta.
A Figura 2(a) apresenta parte da página principal da ferramenta. Após o cadastro, um
usuário pode extrair dados de projetos a partir de um repositório de código SVN ou Git.
A Figura 2(b) apresenta a página onde é possı́vel adicionar um novo repositório
para ser extraı́do. Nele também são exibido todos os projetos adicionados. Caso o usuário
opte por visualizar informações referentes a algum projeto especı́fico, então é exibida a
página apresentada na Figura 3(a), onde são apresentados gráficos com as porcentagens
de alterações realizadas pelos desenvolvedores em relação ao projeto, que representa a
sua familiaridade.
A ferramenta também proporciona ao usuário a opção de realizar configurações
personalizadas. Com isso, o nı́vel de importância ou pesos para as operações de adição,
modificação, incluindo também pesos para modificações em partes de código que envol-
vem instruções condicionais, ou deleção de código podem ser ajustados. Isso possibilita
ao usuário atribuir pesos diferentes para cada tipo de operação citada, de acordo com sua
concepção. Os pesos para cada uma das operações citadas podem ser ajustados na página
apresentada na Figura 3(b).
111
(a) Página incial. (b) Projetos extraı́dos.
Figura 2. Interface da ferramenta.
(a) Gráficos (b) Configurações.
Figura 3. Interface da ferramenta.
Outros parâmetros utilizados no cálculo das métricas que estimam a familiari-

dade dos desenvolvedores também podem ser ajustados nessa página, tais como: os pesos
referentes aos parâmetros que representam a degradação do conhecimento dos desenvol-
vedores. O primeiro parâmetro refere-se ao valor que deve ser reduzido em relação ao
conhecimento a cada novo mês transcorrido, enquanto o segundo representa a degradação
por cada nova alteração feita por um diferente desenvolvedor. Além disso, o usuário
também poderá definir alertas de tal forma que quando algum desenvolvedor possuir um
conhecimento acima do valor informado, a ferramenta emitirá uma mensagem identifi-
cando qual desenvolvedor possui um “domı́nio” excessivo em uma determinada parte de
código. Por fim, nesta página também poderá ser definido um parâmetro para o cálculo
do Truck Fator.
6. Avaliação
Para avaliar as métricas utilizadas na estimação da familiaridade de desenvolvedores fo-
ram analisados 2 (dois) projetos para gestão de planos de saúde de uma empresa de de-
senvolvimento de software local. Os projetos foram extraı́dos do SVN. Durante essa
112
avaliação foram realizadas reuniões com os gerentes de cada um dos projetos. Nessas
reuniões foram solicitados aos gerentes que listassem os membros de sua equipe ordena-
dos de forma decrescente pela familiaridade, observando apenas as tarefa realizadas por
cada membro no projeto.
Nessa empresa, o trunk dos projetos era utilizado apenas para deploy. Todo o
desenvolvimento era feito nos branches. A cada mês era criado um novo branch que
contem o desenvolvimento realizado naquele perı́odo. Além desses branches para o de-
senvolvimento de novas funcionalidades, existe também um outro utilizado para correção
de defeitos.
Para realizar a avaliação, os valores para os pesos dos tipos de alterações foram
definidos de forma empı́rica, após uma reunião informal com desenvolvedores e com os
gerentes dos projetos analisados, bem como os parâmetros que são utilizados como base
para calcular a degradação da familiaridade, truck factor e indicar alertas de riscos iden-
tificados no projeto. Como apresentado na Seção 4.1, os valores de pesos para tipos de
alterações são utilizados durante o cálculo da métrica que representa o total de alterações
realizadas pelos desenvolvedores sobre o projeto, e que é a base para estimar a famili-
aridade dos envolvidos. A Tabela 1 apresenta os valores para cada um dos parâmetros
citados anteriormente.
Tabela 1. Parâmetros utilizados na avaliação dos projetos.

Parâmetros para
Métricas de Familiaridade
Degradação da
Tipos de Alterações
Familiaridade
Adição Modificação Deleção Condição Tempo Nova
(WADD ) (WM OD ) (WDEL ) (WCON D ) (Mês) Alteração
1,0 1,0 0,5 1,0 10% 5%
Indicadores de
Riscos ao Projeto
Truck Factor Alerta de Riscos
Alerta de Risco Alerta de Risco
TF
Moderado Alto
75% 50% 75%
Pode-se perceber que foi dada uma menor ponderação para as operações de
deleção feita sobre arquivos e linhas de código. Como explicado na Seção 4.1, as
operações sobre o código fonte requerem diferentes esforços para serem realizadas, e por
conta disso, nessa avaliação foi definido um peso menor para a operação de deleção, que
foi ponderada com o valor de 0,5. As demais operações foram ponderadas com o valor
de 1,0, ou seja, as operações de adição, modificação e alterações em linhas de código que
envolvem comandos condicionais, obtiveram maior importância do cálculo da métrica
que define a contribuição dos desenvolvedores. O parâmetros utilizados no cálculo das
métricas que determinam a degradação do conhecimento foram definidos como segue:
por mês (10%) e por nova alteração (5%). Dessa maneira, a familiaridade dos desenvol-
vedores foi degradada em 10% a cada mês decorrido desde a data do commit realizado
até a data atual. De maneira análoga, a cada nova alteração realizada sobre os arquivos
113
modificados por um desenvolvedor especı́fico, sua familiaridade foi degradada em 5% a
cada nova alteração realizada por outros desenvolvedores.
Os valores utilizados para o cálculo do Truck Factor, além do valor para indicar
alertas de riscos ao projeto foram definidos como segue: TF (75%), alerta de risco mo-
derado (50%) e de risco alto (75%). Dessa forma, o valor representado pelo ı́ndice TF
será igual a 1 quando apenas um desenvolvedor possuir 75% ou mais do conhecimento
sobre o projeto ou arquivo especı́fico. Nessas circunstâncias será dado um alerta de risco
alto, uma vez que apenas um desenvolvedor possui grande parte do conhecimento sobre
o projeto ou parte especı́fica. De forma análoga, caso algum desenvolvedor detenha um
conhecimento acima de 50% será indicado um alerta de risco moderado. Esses alertas de
riscos são diferenciadas por cores pela ferramenta CoDiVision. O alerta de risco mode-
rado e alto são apresentados na cor amarela e vermelha, respectivamente. Elas indicam
qual desenvolvedor detêm uma familiaridade elevada em relação aos demais indivı́duos
da equipe.
É importante ressaltar que os projetos analisados não são recentes, ou seja,
começaram a ser desenvolvidos há alguns anos. Contudo, foram extraı́dos apenas revisões
referentes aos últimos 6 (seis) meses, uma vez que a familiaridade dos desenvolvedores
sobre cada um dos projetos é melhor representada com base em alterações realizadas mais
recentemente.
6.1. Análise do Projeto A

Primeiramente foi analisado uma parte do projeto denominado de “Projeto A” que contou
com a participação de 4 desenvolvedores. Escolheu-se analisar dois branches relacio-
nados a duas entregas nesse projeto. As Figuras 4 e 5 mostram as familiaridade dos
desenvolvedores em cada um dos branches analisados.
Figura 4. Familiaridade inferida no Branch X do “Projeto A”.
Foi solicitado então ao gerente que ele listasse os desenvolvedores em ordem de-
crescente pela familiaridade. A Figura 4 mostra que apenas dois desenvolvedores partici-
param dessa entrega, no entanto, o gerente achou que mais membros tivessem contribuı́do
à iteração e com isso possuı́ssem mais familiaridade com o código. Ao analisar os resul-
tados o gerente verificou que o Desenvolvedor A1 estava de férias justamente no perı́odo
dessa entrega e que o Desenvolvedor A2 teve que ajudar o Desenvolvedor A4, que estava
114
entrando na equipe, em suas tarefas. Assim, a visualização gerada pela ferramenta estava
correta e consistente com os fatos acontecidos na iteração.
Figura 5. Familiaridade inferida no Branch Y do “Projeto A”.
Já na segunda iteração analisada (Branch Y), o gerente acertou praticamente toda
a ordenação, com um pequeno erro, justificado pela proximidade dos valores. Pode-se
perceber que houve uma boa divisão da familiaridade entre a equipe. O gerente do Projeto
A afirmou que os resultados emitidos pela ferramenta refletem exatamente a percepção de
familiaridade de código que ele identifica no projeto.
6.2. Análise do Projeto B

O segundo projeto (“Projeto B”) analisado contou com a participação de 11 desenvolve-
dores. A Figura 6 mostra a familiaridade de código dos desenvolvedores com o projeto
citado. Nesse primeiro momento foram analisadas as alterações realizadas no trunk do
projeto. Pode-se perceber uma certa estabilidade no projeto, pois o valor do TF para ele
foi de quatro, ou seja, mesmo que o membro com maior familiaridade venha a se ausen-
tar por algum motivo, existem três outros membros com um alto grau de familiaridade.
Desse modo a “dependência” por parte da equipe em relação à esse membro com maior
familiaridade não é tão crı́tica.
Figura 6. Familiaridade inferida no trunk X do “Projeto B”.
No momento da ordenação percebeu-se que o gerente tinha ciência dos dois de-
senvolvedores com maior familiaridade no projeto. Contudo, não se recordava que o
115
Desenvolvedor B8 tinha sua participação no projeto. Para os desenvolvedores B1 e B9
não foi considerado que o gerente errou pois a diferença de familiaridade entre os dois
foi minima (cerca de 2%). Não foi exigida a ordenação dos desenvolvedores com menor
familiaridade por conta da grande probabilidade de erro por parte do gerente, por ser uma
análise mais precisa.
Foi realizada uma segunda análise no mesmo projeto. Dessa vez foi analisado o
branch que era utilizado para resolução de defeitos. A Figura 7, mostra a familiaridade
dos desenvolvedores nesse branch. Novamente o gerente tinha ciência do desenvolvedor
com maior familiaridade no projeto, pois sua resposta foi bem rápida para esse desenvol-
vedor.
Figura 7. Familiaridade inferida no Branch do “Projeto B”.
A partir da analise da figura nota-se duas diferenças entre a ordenação feita pelo
gerente e a ordenação feita pela CoDiVision. A primeira diferença está relacionada aos
desenvolvedores B6 e B9. O gerente explicou que imaginava que o Desenvolvedor B6
tinha uma maior familiaridade por ser um desenvolvedor responsável por corrigir erros
ocorridos nas funcionalidades entregues recentemente, enquanto que o Desenvolvedor
B9 era responsável pela correção de pequenos defeitos. O segundo erro está relacionado
aos desenvolvedores B1 e B8. O gerente explicou que não considerou o fato do Desenvol-
vedor B8 ter entrado para a equipe a menos tempo que o Desenvolvedor B1. O gerente do
Projeto B afirmou que as informações sobre familiaridade, podem apoiar na distribuição
de tarafes e no acompanhamento da sua equipe, de forma a identificar os desenvolvedores
a serem mais ativos ao projeto.
7. Ameaças à Validade
As métricas propostas neste trabalho baseiam-se principalmente em alterações realizadas
sobre o código fonte. Por conta disso, possuem algumas limitações em determinados
tipos de contexto. Considerando o contexto de projetos de software compostos por de-
senvolvedores que assumem diferentes papéis dentro do projeto, podem existir indivı́duos
que realizam apenas reparos pontuais no sistema e que, mesmo contabilizando poucas
atividades referentes à alterações de código, possuem uma alta taxa de familiaridade, pois
acompanham todas as alterações realizadas por outros membros da equipe de desenvolvi-
mento, e assim terminam por manter um bom nı́vel de familiaridade com o código fonte.
Contudo, uma das métricas aqui propostas, apresentada na Seção 4.1, visa atri-
buir uma maior ponderação para tipos de alterações mais significativas (isto é, contendo
116
comandos condicionais) realizadas sobre o código fonte, pois acredita-se que esses tipos
de alterações são comumente realizadas por aqueles desenvolvedores que costumam re-
alizar alterações pontuais no sistema. Além disso, por meio dos resultados apresentados
neste trabalho, foi constatado que as métricas baseadas nas alterações realizadas por de-
senvolvedores sobre o código fonte fornecem uma boa base no processo de inferência da
familiaridade de código.
8. Conclusão
Neste trabalho foram apresentadas algumas métricas para representar a familiaridade de
desenvolvedores em projetos de desenvolvimento de software. Essas métricas são de-
finidas com base em operações de adição, deleção e modificação de arquivos e linhas
de código, que são realizadas pelos desenvolvedores sobre o código-fonte no decorrer
do desenvolvimento do projeto. Essas operações são capturadas por meio de técnicas
de mineração de dados em repositórios de código em sistemas de versionamento. As
métricas apresentadas têm como objetivo modelar a familiaridade de um desenvolvedor
considerando um contexto real, ou seja, elas buscam representar também a “perda” de co-
nhecimento dos desenvolvedores por perı́odo de tempo transcorrido e também por novas
operações realizadas por outros desenvolvedores nas mesmas entidades de código.
Para visualização da distribuição da familiaridade estimada por meio das métricas
criadas, foi desenvolvida uma ferramenta intitulada CoDiVision. Pôde ser observado que
o uso da ferramenta auxilia de maneira significativa na descoberta de riscos que podem
estar presentes em um projeto de software, no que diz respeito ao “domı́nio” excessivo
de um grupo reduzido de desenvolvedores em relação ao projeto, ou parte dele. A fer-
ramenta foi utilizada na análise de dois projetos privados. Os resultados mostraram que
as informações obtidas pela CoDiVision refletem bem, e de maneira precisa, a familia-
ridade associada a cada desenvolvedor do projeto. Por meio da estimação da familiari-
dade dos desenvolvedores, grupos de desenvolvimento de software têm uma visão ge-
ral da distribuição do conhecimento sobre o projeto, identificando assim a existência de
“domı́nio” excessivo do conhecimento por um pequeno grupo de desenvolvedores. Com
isso, responsáveis por projetos de software poderão impor estratégias que possam evitar
os riscos causados por esse fato.
Como proposta futura, pretende-se realizar uma análise comparativa das métricas
criadas neste trabalho com as que foram propostas em outros trabalhos, que utilizam como
base as atividades realizadas pelos desenvolvedores em um nı́vel de granularidade maior,
em termos de arquivo, afim de verificar que as métricas propostas podem estimar a fami-
liaridade de maneira mais precisa, já que levam em consideração também as operações
realizadas sobre o código-fonte em um nı́vel de granularidade menor.
Referências
Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,
Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., et al. (2001). Manifesto for agile
software development.
Fritz, T., Murphy, G. C., Murphy-Hill, E., Ou, J., and Hill, E. (2014). Degree-of-
knowledge: Modeling a developer’s knowledge of code. ACM Transactions on Soft-
ware Engineering and Methodology (TOSEM), 23(2):14.
117
Hassan, A. E. (2008). The road ahead for mining software repositories. In Frontiers of
Software Maintenance, 2008. FoSM 2008., pages 48–57. IEEE.
Mason, M. (2005). Pragmatic Version Control Using Subversion. Pragmatic Bookshelf.
Meng, X., Miller, B., Williams, W., and Bernat, A. (2013). Mining software repositories
for accurate authorship. In Software Maintenance (ICSM), 2013 29th IEEE Internati-
onal Conference on, pages 250–259.
Moura, M. H. D. d., Nascimento, H. A. D. d., and Rosa, T. C. (2014). Extracting new
metrics from version control system for the comparison of software developers. In
Software Engineering (SBES), 2014 Brazilian Symposium on, pages 41–50. IEEE.
Sankoff, D. and Kruskal, J. B., editors (1983). Time Warps, String Edits, and Macromo-
lecules: The Theory and Practice of Sequence Comparison. Addison-Wesley.
Spinellis, D. (2005). Version control systems. Software, IEEE, 22(5):108–109.
Teles, V. M. (2004). Extreme programming. São Paulo: Novatec.
Torchiano, M., Ricca, F., and Marchetto, A. (2011). Is my project’s truck factor low?:
Theoretical and empirical considerations about the truck factor threshold. In Proce-
edings of the 2Nd International Workshop on Emerging Trends in Software Metrics,
WETSoM ’11, pages 12–18, New York, NY, USA. ACM.
118
Alinhamento estratégico de melhoria de processos de
software: percepções de um processo de apoio à decisão
Francisco J. S. Vasconcellos1, Caíque Minhare1, Leonardo Fuchs1,
Jucele F. A. Vasconcellos1, José Adson O. G. da Cunha2, Auri M.R. Vincenzi3
1
Faculdade de Computação, Universidade Federal de Mato Grosso do Sul
Caixa Postal 549 – 79.070-900 – Campo Grande, MS – Brasil
2
Departamento de Ciências Exatas – Universidade Federal da Paraíba
Rio Tinto, PB – Brasil
3
Departamento de Ciência da Computação –Universidade Federal de São Carlos
São Carlos, SP – Brasil
{francisco.vasconcellos,jucele}@facom.ufms.br,
{caique.minhare,leonardo.fuchs}@aluno.ufms.br,
adson@dcx.ufpb.br, auri@dc.ufscar.br
Abstract. The alignment between software process improvement (SPI) and
organizational goals involves strategic and tactical decision making. This
article presents a qualitative study about the usefulness of a formal decision-
making process in the strategic alignment of SPI. The definition and
refinement of the proposed process helped to develop theoretical propositions
in an inductive way. Questionnaires adapted from the Technology Acceptance
Model positively evaluated both the ease of use and the perceived utility of the
proposed solution. The results indicate that a formal decision-making process
is useful and necessary for the strategic alignment of SPI.
Resumo. O alinhamento de melhoria do processo de software (MPS) com

objetivos organizacionais envolve decisões em níveis estratégico e tático. Este
artigo apresenta um estudo qualitativo sobre a utilidade de um processo
formal de tomada de decisão no alinhamento estratégico de MPS. A definição
e o refinamento do processo proposto ajudaram a desenvolver proposições
teóricas de forma indutiva. Questionários adaptados do Modelo de Aceitação
de Tecnologia avaliaram positivamente tanto a facilidade de uso quanto a
utilidade percebida da solução proposta. Os resultados indicam que um
processo formal de tomada de decisão é útil e necessário para o alinhamento
estratégico de MPS.
1. Introdução
A melhoria de processos de software (MPS) tem como objetivo aumentar a eficácia de
uma organização de software e a seleção das práticas a serem melhoradas depende do
contexto organizacional, cultura e prioridades (Humphrey 1989). Ebert (1999) afirma
que os objetivos estratégicos organizacionais devem estar claros antes da definição de
metas de melhoria pelo nível tático. De fato, estudos indicam o alinhamento com os
objetivos de negócios como um fator crítico para o sucesso de MPS (Dybå 2005). Além
disso, a norma ISO/IEC 33014 enfatiza que, quanto maior o alinhamento entre objetivos
de negócios e as decisões de melhoria de processos, maior a probabilidade de sucesso
do programa de melhorias (ISO/IEC 2013).
119
Motivados pelo estudo de Lepmets et al. (2012), Vasconcellos et al. (2017)
avaliam, em uma revisão sistemática da literatura (RSL), 19 abordagens para o
alinhamento estratégico de MPS. Entre outros aspectos, a falta de validação empírica
indica uma potencial falha na transferência adequada das soluções para a prática. Além
disso, nenhum método foi sugerido para apoiar o processo de tomada de decisão em um
alinhamento estratégico de MPS. Considerando a tomada de decisões como habilidade
que, como tal, pode ser aprimorada com experiência e treinamento, entende-se que esta
também pode ser auxiliada por processos que forneçam mecanismos de apoio à decisão
(Hastie e Dawes 2010). Assim, é importante considerar o emprego de métodos de apoio
à decisão e de Sistemas de Apoio à Decisão (SAD), para ajudar os profissionais a
decidirem sobre melhorias nos processos de software. Dentre os 51 estudos avaliados na
RSL, apenas um trabalho apresenta uma técnica para apoio à decisão, mas não a
emprega de modo a alinhar a seleção de melhorias no processo a objetivos
organizacionais. Outros estudos apresentam abordagens para a seleção e para o
monitoramento de ações de melhoria alinhadas a objetivos organizacionais, mas com
baixa evidência de efetiva transferência para a prática, o que nos remete à seguinte
questão de pesquisa:
Como organizações de software percebem a utilidade de um Sistema de Apoio à
Decisão para prover e manter o alinhamento entre ações de melhoria de processos
de software e suas necessidades organizacionais ?
O objetivo deste trabalho relaciona-se ao desenvolvimento do conhecimento
sobre a utilidade percebida, pelos profissionais, de um sistema de apoio à tomada de
decisões, representado por um processo e ferramental de apoio, aplicado ao alinhamento
estratégico de MPS. Este artigo apresenta resultados de duas fases de validação, de um
método composto por três fases, que busca a transferência adequada de uma solução
proposta para a indústria. Inspirado nos trabalhos de Shull et al. (2001) e pelo modelo
de transferência de tecnologia proposto por Gorschek et al. (2006), foram delineados
um processo e uma ferramenta de apoio, inicialmente com base no referencial teórico
(seção 2). Partindo da premissa de que um processo formal de tomada de decisões pode
ser útil para o alinhamento entre os objetivos da alta administração com as escolhas de
melhoria do processo, conjecturas iniciais foram aprimoradas por indução analítica
(Johnson 2004) através de um método iterativo de validação (seção 3). Os resultados
contribuíram para o aperfeiçoamento do conhecimento e para o refinamento da solução,
possibilitando assim, a análise apresentada na seção 4. Considerando as ameaças à
validade (seção 5), as conclusões e trabalhos futuros são apresentados na seção 6.
A proposição teórica inicial, composta por conjecturas, considera alguns constructos e
relações apoiadas pela revisão da literatura, como recomendam métodos qualitativos de
construção de teorias (Merriam 2009; Corbin e Strauss 2015). Além dos conceitos
necessários para as observações iniciais e para o estímulo de questões utilizadas durante
o processo de pesquisa, a literatura também contribuiu para aprimorar a sensibilidade
teórica do segundo e terceiro autores, iniciantes nesta área substantiva (Corbin e Strauss,
2015). Nesta seção são descritos conceitos relacionados ao alinhamento estratégico de
MPS e ao processo de tomada de decisão correspondente. As conjecturas iniciais são
listadas com identificadores de C1 a C7.
120
2.1. Alinhamento estratégico de MPS
Organizações de software com ou sem fins lucrativos possuem metas organizacionais
definidas pela alta administração. As melhorias em um processo de software podem ser
derivadas de metas organizacionais em um planejamento de MPS top-down (ISO/IEC
2013) ou alinhadas com os objetivos de negócios em uma estratégia de MPS bottom-up,
comum em um ambiente ágil (Lepmets e McBride 2012).
Independentemente do cenário, uma iniciativa de MPS invariavelmente exige
mudanças em um processo de software. Münch et al. (2012) afirmam que mudanças nos
processos de software devem ser cuidadosamente planejadas porque, para serem
eficazes, dependem dos seres humanos, do contexto organizacional e do ambiente de
negócios, representando assim, custos significativos para uma organização. Qualquer
mudança em um processo de software pode então ser vista como uma decisão
estratégica. Como o alinhamento de MPS envolve tais decisões estratégicas, este será
denominado alinhamento estratégico de MPS.
O modelo COBIT (ISACA 2012) e o padrão ISO/IEC (ISO/IEC 2015)
estabelecem três tarefas principais relacionadas à governança de tecnologia da
informação (TI): dirigir, monitorar e avaliar. Além disso, o padrão ISO/IEC recomenda
a delegação de responsabilidades específicas a gerentes funcionais de TI (o gerente de
esforços de melhoria de processos no contexto deste estudo). Assim, são apresentadas
duas conjecturas iniciais:
C1: O alinhamento estratégico de MPS envolve o planejamento e o monitoramento de
atividades, demandando tanto sistemas para apoio à tomada de decisão quanto para a
mensuração de resultados.
C2: O alinhamento estratégico de MPS envolve duas partes interessadas principais:
diretores e gerentes de MPS.
Trienekens et al. (2005) enfatizam o papel do processo de tomada de decisão na

decomposição da estratégia e metas de negócios em metas de equipes técnicas. Como
mostrado na Figura 1, são três níveis de tomada de decisão: estratégico, tático e
operacional. A decisão estratégica refere-se à priorização de objetivos de negócios (o
“porquê”). Gerentes de MPS tomam decisões táticas, selecionando alternativas de
melhorias (o “que”) alinhadas com as decisões estratégicas. A decisão operacional está
relacionada com a escolha de ferramentas, procedimentos e modelos utilizados para
apoiar a implementação de um programa de MPS (o “como”).
Priorização das metas organizacionais, estabelecimento de

direção e monitoramento das ações de MPS.
Seleção de alternativas MPS que melhor se alinham

com as decisões estratégicas.
Escolha de ferramentas, procedimentos e modelos

para apoiar a implementação de uma ação MPS.
Figura 1. Níveis de tomada de decisão (baseado em Trienekens et al.(2005)).
121
O foco do alinhamento estratégico de MPS está na sintonia entre diretores e
gestores de nível tático. O nível operacional depende do nível tático pois ambas as
decisões são técnicas. O alinhamento entre metas organizacionais e as decisões táticas
implica na tradução da visão empresarial para a visão técnica, que pode ser uma tarefa
desafiadora no processo de tomada de decisão de MPS. Esta questão levanta outra
conjectura:
C3: O processo de tomada de decisão deve relacionar a priorização dos objetivos
organizacionais (decisão estratégica) com a seleção de alternativas de MPS (decisão
tática).
Modelos de maturidade para desenvolvimento de software, como CMMI ou

MR-MPS-SW, recomendam processos para auxílio na tomada de decisões em projetos
de software. O objetivo desses processos é apoiar a tomada de decisões consideradas
críticas, por meio de um processo formal que pressupõe critérios estabelecidos para a
avaliação de alternativas identificadas. Embora a aplicação desses processos ocorra
usualmente em decisões relacionadas a projetos de software, parece aplicável à decisão
em iniciativas de MPS. Afinal, “processos de software são também software”
(Osterweil 1987), e esforços de melhoria de processos possuem características
gerenciais semelhantes a projetos. De fato, a ISO/IEC 33014 (ISO/IEC 2013)
recomenda que um programa de melhoria de processo seja implementado como um
projeto, com patrocínio definido, gerenciamento de projetos, orçamento, marcos e
responsabilidade estabelecidas. Tais aspectos sugerem uma nova conjectura:
C4: A lógica de tomada de decisão deve abranger e registrar critérios aplicados em
ambos os níveis de decisões, fornecendo elementos para uma revisão periódica de
planos de ação de MPS decorrentes.
Como os problemas de decisão estão diretamente relacionados ao gerenciamento
de melhoria de processos, é necessária a revisão de teorias de decisão e de sistemas de
apoio à decisão aplicáveis ao alinhamento estratégico de MPS.
2.2. Teorias de decisão e sistemas de apoio à decisão

A teoria da decisão é desenvolvida desde meados do século XX com base em
contribuições de várias disciplinas, estudadas por economistas, estatísticos, psicólogos,
cientistas políticos e sociais ou filósofos. Há dois campos de pesquisa em teoria da
decisão: normativo e descritivo (Peterson 2009). O ponto de vista normativo procura
produzir prescrições sobre o que decisores devem racionalmente (ou deveriam) fazer em
uma decisão. Alternativamente, teorias de decisão descritivas tentam explicar e prever
como decisões são realmente tomadas, por meio de processos empíricos decorrentes da
psicologia experimental.
As abordagens normativas, foco de nosso estudo, tratam questões sobre como
agir quando há incerteza e falta de informação. Exploram também preocupações sobre
como um indivíduo pode coordenar suas decisões ao longo do tempo, e de como as
pessoas tomam suas decisões em um grupo, envolvendo aspectos sociais e políticos.
Gigerenzer e Selten (2001) mencionam que Herbert Simon, ao conceber o termo
“racionalidade limitada” (do inglês bounded rationality), usou a metáfora da tesoura, na
qual uma lâmina representa as limitações cognitivas dos seres humanos enquanto a
outra é a estrutura do ambiente. As limitações e os erros de percepção restringem a
122
capacidade dos tomadores de decisão para selecionar a melhor opção a partir de
alternativas disponíveis, dificultando assim as decisões ótimas assumidas pelo modelo
racional. Pessoas com limitações de tempo, conhecimento e de outros recursos, podem
decidir e serem bem-sucedidas em seus ambientes. Assim, estudos devem considerar a
necessidade de ambos os lados da tesoura para cortar. O que Simon chama de
“ambiente” está relacionado com as necessidades, impulsos ou metas e com a percepção
da pessoa (Simon 1956). O autor afirma que as pessoas desenvolvem procedimentos de
decisão suscetíveis às restrições, mesmo que esses pareçam insensatos se as restrições
forem removidas. No lugar de examinar todas as alternativas possíveis, busca-se apenas
encontrar uma solução satisfatória o suficiente em relação a algum critério. Em suma:
atinge-se a “satisfação”. Este ponto remete a outra conjectura:
C5: Um processo decisório adequado ao alinhamento estratégico de MPS deve
equilibrar racionalidade e agilidade, visando ser útil.
A falta de informação adequada leva a uma dependência da intuição, experiência
e do julgamento por especialistas (Bhushan e Rai 2004). O problema é abstraído por
meio de ponderações, classificações ou julgamento de importância relacionado a um
conjunto de atividades, de acordo com seu impacto na situação e com o objetivo das
decisões a serem tomadas. Trata-se de um processo de tomada de decisão de múltiplos
critérios (do inglês Multiple Criteria Decision Making - MCDM). O Analytic Hierarchy
Process (AHP) representa uma abordagem sistemática de MCDM, desenvolvida na
década de 1970 por Thomas L. Saaty, para apoiar decisões baseadas na experiência,
intuição e em heurísticas. Trata-se de uma metodologia bem definida derivada de
princípios matemáticos sólidos (Saaty 2008), que fornece uma abordagem formal a
partir da qual uma melhor qualidade das soluções de problemas complexos justifica o
tempo investido no processo. Surge assim uma conjectura complementar:
C6: Uma abordagem MCDM (AHP, por exemplo) pode ser útil em um processo de
tomada de decisão de MPS.
Bazerman e Moore (2009), adotando uma abordagem descritiva, apresentam
limites existentes na tomada de decisões, incluindo a racionalidade limitada, a força de
vontade limitada, o interesse limitado, a consciência limitada e a ética limitada. Eles
fornecem razões práticas para questionar o uso da intuição na tomada de decisões.
Finalmente, o livro fornece seis etapas para melhorar as decisões: (1) usar ferramentas
de apoio à decisão, (2) adquirir experiência, (3) evitar viés, (4) analisar racionalmente,
(5) obter visão de fora, e (6) identificar vieses em outros. O passo da ferramenta leva ao
conceito de Sistemas de Apoio à Decisão (SAD) – do inglês, Decision Support Systems
– e seu papel na tomada de decisões. Como a preocupação principal aqui é a
compreensão da utilidade percebida, por profissionais, de um processo de tomada de
decisão aplicado ao alinhamento estratégico de MPS, o apoio ferramental atua
induzindo uma mudança direcionada, como sugere a abordagem de Silver (1990), na
qual o SAD assume um papel instrumental com o objetivo de facilitar a coleta de
conhecimento sobre o processo de tomada de decisão mais adequado ao contexto. Este
conceito reforça outra conjectura:
C7: Uma ferramenta pode melhorar um processo de tomada de decisão de MPS.
123
O método de pesquisa empregado neste trabalho pode ser descrito por meio do
Research Path Schema (RPS) proposto por Stol e Fitzgerald (2015), que sugere a ênfase
e ordem dada aos principais elementos presentes em qualquer metodologia de pesquisa.
O RPS baseia-se na premissa de que qualquer pesquisa envolva pelo menos três
elementos: (a) o conteúdo de interesse, (b) ideias que dão sentido a esse conteúdo, e (c)
técnicas ou procedimentos por meio dos quais essas ideias e conteúdos podem ser
estudados. Em RPS, esses três elementos são classificados como domínios substantivo,
conceitual e metodológico, respectivamente. Dependendo de como esses domínios são
combinados, diferentes caminhos podem ser estabelecidos. Neste trabalho, segue-se o
caminho observacional dirigido pelo sistema (do inglês system-driven observational
path). No caminho observacional o objetivo é coletar observações e explicá-las em
termos de um conjunto de conceitos (Stol e Fitzgerald, 2015). O pesquisador define o
tópico de interesse (domínio substantivo) e o método de pesquisa.
Conforme mostrado na Figura 2, o foco principal da pesquisa é o conhecimento
teórico sobre a utilidade de um processo formal de tomada de decisão para o
alinhamento entre as iniciativas de MPS e os objetivos de negócios da organização
(domínio substantivo). O metodológico é o domínio secundário. As principais
contribuições são observações empíricas (de estudos observacionais iterativos), que
levam ao estabelecimento de conceitos (formulação de proposições teóricas) sobre a
utilidade de uma solução.
Figura 2. Caminho de pesquisa (baseda em Stol e Fitzgerald (2015)).

A metodologia iterativa proposta por Shull et al. (2001) consiste em três tipos de
estudos: viabilidade, observacional e estudo de caso. Associando esta metodologia ao
modelo de transferência de tecnologia proposto por Gorschek et al. (2006) e Gorschek
(2015) delineou-se um método com três fases de validação: Acadêmica, Estática e
Dinâmica. A Validação Acadêmica engloba a elaboração e análise de viabilidade de um
processo de tomada de decisão para o alinhamento estratégico de iniciativas de MPS. A
fase de Validação Estática engloba uma a avaliação por amostragem objetivamente
selecionada de organizações que podem contribuir para a validação estática mencionada
por Gorschek (2015). Esta avaliação é realizada por meio de estudos observacionais
conforme proposto por Shull et al. (2001). A fase de Validação Dinâmica consiste em
estudos de caso em organizações, conduzidos “sem qualquer interferência, ajuda ou
124
assistência por parte dos pesquisadores” conforme estabelecido por Gorschek et al.
(2006). Este estudo descreve a execução e os resultados obtidos nas duas primeiras
fases, que servem de base para a última validação necessária. Embora não baseado no
Design Science Research (Wieringa 2014), este trabalho relaciona-se com a teoria do
design visto que pretende-se escalar uma tecnologia até a prática. Um processo (como o
artefato ou tecnologia a ser escalada para prática) e um SAD (como mecanismo de
apoio ao desenho do artefato) definem a solução candidata oferecida.
3.1. A Validação Acadêmica (Fase 1)

Na primeira fase os requisitos de um processo de tomada de decisão para o contexto do
alinhamento estratégico de MPS são identificados, oferecendo assim uma solução
candidata a ser utilizada na fase de Validação Estática. A concepção inicial do processo
de apoio à tomada de decisão surge por meio de informações extraídas da literatura e
por entrevistas não estruturadas com profissionais decisores em MPS, iniciadas com a
pergunta: “Como você define prioridades para iniciativas de MPS e como as alinha aos
objetivos organizacionais?”. Uma amostragem intencional de organizações de
diferentes portes, mas com certo nível de maturidade do processo de software, fornece
informações relevantes sobre técnicas aplicadas pelos decisores para selecionar e
priorizar melhorias nos processos. Entrevistas não estruturadas com especialistas no
domínio da tomada de decisão também são previstas para o entendimento sobre a
inserção de um processo formal e de um SAD em um ambiente de produção.
Para minimizar o viés, três pesquisadores, com diferentes níveis de experiência,
analisam os dados da entrevista e elaboram a proposta de solução. A validação da
solução candidata em ambiente acadêmico visa a coleta de feedback por pesquisadores
experientes e a identificação de falhas que possam ser corrigidas antes da validação por
profissionais. Ao todo, cinco autores contribuem para a análise da solução candidata,
representando assim, a triangulação por pesquisadores sugerida por Morse (2015).
3.2. A Validação Estática (Fase 2)

Como proposto por Gorschek et al. (2006), a Validação Estática envolve a apresentação
da solução candidata a ambientes reais com o objetivo de coletar dados para melhorias.
O treinamento de profissionais e a execução de casos aplicando o processo de apoio à
tomada de decisão visam à coleta de dados, tanto por observações feitas pelos
pesquisadores, quanto por entrevistas e questionários realizados junto aos profissionais.
As observações e questionários, triangulados com entrevistas informais e não
estruturadas, são o principal método de coleta de dados. Assim como na primeira fase, o
objetivo é coletar a visão dos decisores sobre como selecionar melhorias nos processos
de software e como alinhar esta iniciativa com as metas organizacionais prioritárias. O
componente ferramental da solução (SAD) atua como um mecanismo (Wieringa 2014b)
para auxiliar a obtenção do entendimento sobre o processo de tomada de decisão mais
adequado ao alinhamento estratégico de MPS.
A amostragem organizacional objetivamente selecionada visa facilitar o
tratamento de questões éticas e o rapport (Guest et al. 2013). Esta amostragem,
apresentada na Tabela 1, engloba a diversidade de tamanho, assim como uma variedade
de contextos e de maturidade de processo de software, aspecto importante de
generalização (Petersen e Wohlin 2009).
125
Tabela 1. Amostragem organizacional. Organizações A, B, C e D contribuíram
para a Fase 1, enquanto as organizações D, E e F contribuíram para a Fase 2.
Estrutura de Rigor do
Produto Processos Práticas Maturidade
decisão Mercado
Organização Tamanho da Org. e
Definidos ou Tradicionais ou Experiência com Nível de
Segmento número decisores
Informais ágeis modelos MPS regulação
sobre MPS
Sistemas
A bancários
Definidos Tradicionais MR-MPS-SW- C Grande – 5 Alto
Gestão
B financeira
Definidos Ágeis MR-MPS-SW- F Pequeno – 2 Médio
C Telecom Definidos Tradicionais CMMI L.3 Grande – 10 Alto

D Governo Definidos Ágeis MR-MPS-SW- G Médio – 3 Médio
Gestão
E financeira
Informais Ágeis Nenhuma Micro - 1 Médio
F ERP Definidos Tradicionais MR-MPS-SW- C Grande – 8 Baixo
Além de observações e de entrevistas informais, um questionário de descrição de

contexto (Petersen e Wohlin 2009) e um questionário adaptado do modelo de aceitação
de tecnologia (Technology Acceptance Model - TAM) (Davis 1989) avaliam a utilidade
percebida e a facilidade de uso da solução em cada caso. O questionário TAM adaptado
apresenta quatro questões para análise da utilidade percebida e outras quatro questões
para a avaliação da facilidade de uso, abordando os aspectos descritos na Tabela 2.
Tabela 2. Aspectos abordados na questões sobre utilidade e facilidade de uso.
Utilidade Facilidade de uso
U1: Execução de análise estratégica F1: Facilidade de aprendizagem
U2: Identificação de causas-raiz F2: Possibilidade de uso sem apoio
U3: Ligação de problemas a processos F3: Entendimento da sequência de passos
U4: Avaliação da utilidade percebida F4: Facilidade de análise estratégica
3.3. A Validação Dinâmica (Fase 3)

A Validação Dinâmica consiste na entrega da solução a ambientes reais sem que ocorra
qualquer interferência por parte dos proponentes da solução. O processo, mesmo útil,
pode vir a ser ignorado devido a fatores de confusão (confounding factors) não tratados
pelos pesquisadores (Unterkalmsteiner et al. 2012). Além disso, mesmo que os
profissionais usem a solução, estes podem não usá-la da maneira prevista (Gorschek,
2015). A Validação Estática coleta as necessidades de treinamento, de documentação,
de apoio, e de outros itens que permitirão o uso adequado da solução, ou seja, requisitos
para a Validação Dinâmica. Um trabalho futuro, para medir efeitos da solução e como
esta é usada na prática, estabelecerá procedimentos de avaliação desta fase.
4. Resultados e Análise
O desenvolvimento da solução ocorreu iterativamente pela análise dos resultados de
cada fase de validação. As conjecturas iniciais - confirmadas, melhoradas ou alteradas -
tornaram-se proposições pelo processo de teorização (Recker 2013).
4.1. Validação Acadêmica

Foram realizadas entrevistas com seis decisores (D) (das organizações A, B, C e D
listadas na Tabela 1) e com três especialistas em tomada de decisão (TD-Esp), sobre a
utilidade de um processo formal de tomada de decisão para a seleção e para a
priorização de esforços de MPS.
126
O processo de tomada de decisão baseado em AHP apoiado por planilhas do
Microsoft Excel® foi definido pelos três primeiros autores e avaliado por outros dois
pesquisadores (R). Sendo especialistas em Sistemas de Apoio à Decisão e em melhoria
de processos de software, esses pesquisadores contribuíram para o refinamento da
solução candidata, sendo convidados a participar da análise dos dados da Validação
Estática. As sugestões e críticas apresentadas levaram à elaboração de nova versão do
processo e à construção de um aplicativo Java, empregados na Validação Estática.
4.2. Validação Estática

A coleta de dados sobre a utilidade percebida e facilidade de uso da solução também
obteve sugestões de melhorias (tanto para o processo quanto para o software), por meio
de respostas às questões abertas inseridas ao final do questionário adaptado do TAM. O
questionário empregado utilizou uma escala de Likert de seis pontos, omitindo o valor
médio por não fornecer informações sobre a opinião do participante, ou seja, sobre
concordar ou discordar (Laitenberger e Dreyer 1998). Foi atribuída uma faixa de valores
numéricos entre 1 e 3 para cada tipo de resposta. As respostas positivas receberam
valores de 1 a 3 (concordo parcialmente, concordo e concordo fortemente). As respostas
negativas receberam valores de -1 a -3 (discordo parcialmente, discordo e discordo
fortemente). Com um total de 12 questionários aplicados (abrangendo as organizações
D, E e F) poderia ser obtido um valor máximo de 36 no somatório (Σ) de cada item. Os
resultados obtidos são apresentados na Tabela 3:
Tabela 3. Resultados das respostas ao questionário.
F1 F2 F3 F4 U1 U2 U3 U4
Σ 25 21 32 29 32 25 26 29
 2,08 1,75 2,67 2,42 2,67 2,08 2,17 2,42
σ 0,29 0,45 0,65 0,67 0,49 0,67 0,58 0,67
Pode-se perceber que a média obtida nos itens indica concordância de que a
solução proposta é útil e fácil de usar. No entanto, duas preocupações surgiram da
análise deste resultado. Primeiro, o item F2 (Possibilidade de uso sem apoio) apresenta
um baixo valor de média de concordância, associado a baixo desvio padrão. Isto indica
que o processo demanda apoio para seu uso efetivo. Além disso, os seguintes
comentários contribuíram para a análise desta questão:
"A análise da causa-raiz só será eficaz com o apoio de consultoria." (D2-org D)
"É difícil estabelecer os critérios de decisão sem apoio de especialistas." (D1-org D)
"Tivemos dificuldades em definir a granularidade dos problemas, gerando assim
muitas alternativas para serem avaliadas." (D2-org F)
O feedback acima demonstra a necessidade de melhor apoio de treinamento para
a transferência adequada da solução para a prática (tutoriais em vídeo, por exemplo). No
entanto, pode ser recomendável ainda o eventual apoio de consultoria, pelo menos no
primeiro uso.
A segunda preocupação diz respeito a dados oriundos de observações. Foi
observado certo desconforto e impaciência, por parte de um decisor, durante a execução
do processo. De fato, ao triangular esta observação com dados do questionário, este
decisor é o único a atribuir valores baixos nas questões relacionadas à utilidade
percebida, contribuindo assim para o alto desvio padrão resultante nos quesitos U2 e U4.
127
O seguinte extrato de repostas ao questionário corroboram a percepção: "Senti falta de
gestão de mudanças nas decisões." (D1-org F)
Este feedback motivou a triangulação com uma entrevista complementar
realizada com o decisor 2 da mesma organização. O seguinte dado surge quando
perguntada a opinião sobre o problema de mudanças nas decisões tomadas:
"Infelizmente, o processo de decisão depende do perfil do decisor e da cultura
organizacional. Em nossa organização, mesmo as decisões estratégicas são voláteis
[sic]…” (D2-org F)
Devido à posição de liderança do informante (D1 indica ser o decisor com mais
alto nível hierárquico na organização), foi realizada nova triangulação com os seguintes
dados de entrevista com especialista em tomada de decisão:
"Meu amigo... (mostrando desânimo em sua voz) alguns gerentes evitam processos
formais de tomada de decisão devido a motivos não publicáveis. Tais motivações
podem ser políticas, sociais ou mesmo antiéticas..." (TD-Esp1)
Consequentemente, devido ao risco de insucesso na efetiva transferência para a

prática na presença de cenários envolvendo decisores de nível estratégico com perfil
similar, postulou-se nova proposição P8. Os dados coletados confirmaram as conjecturas
C1, C4 e C5. Além da nova proposição P8, foi alterada C2 e aprimoradas C3, C6 e C7. A
Tabela 4 descreve as proposições resultantes (P1 a P8).
Tabela 4. Proposições decorrentes.
Pn Proposições
O alinhamento estratégico de MPS envolve o planejamento e o monitoramento de atividades,
P1 demandando tanto sistemas para apoio à tomada de decisão quanto para a mensuração de
resultados.
O alinhamento estratégico de MPS envolve dois papéis duas partes interessadas principais:
decisores dos níveis estratégico e tático. diretores e gerentes de MPS.
P2
“Concordo com os dois níveis de decisão, mas na minha empresa eu tomo as duas decisões às
vezes.” (D1-org B)
O processo de tomada de decisão deve relacionar a priorização dos objetivos organizacionais
(decisão estratégica) com a seleção de alternativas de MPS (decisão tática).
Aprimoramento: Critérios de decisão devem ser estabelecidos pelo nível estratégico, mas
P3 alternativas de MPS devem ser identificadas antes da seleção dos critérios de decisão.
“A determinação de critérios para a seleção de alternativas normalmente depende das opções
escolhidas. O nível tático deve determinar alternativas viáveis para que possam ser estabelecidos
os critérios de seleção.” (TD-Esp2)
A lógica de tomada de decisão deve abranger e registrar critérios aplicados em ambos os níveis de
P4 decisões, fornecendo elementos para uma revisão periódica de planos de ação de MPS
decorrentes.
Um processo decisório adequado ao alinhamento estratégico de MPS deve equilibrar
P5
racionalidade e agilidade, visando ser útil.
Uma abordagem MCDM (AHP, por exemplo) pode ser útil em um processo de tomada de decisão
de MPS.
Aprimoramento: Uma abordagem MCDM não é útil quando existe consenso sobre a escolha. Nos
casos em que os critérios não sejam declarados, o motivo da escolha deve ser documentado.
P6 “Não vejo benefícios em uma abordagem MCDM se houver consenso de escolha.” (D1-org C)
“O processo deve prever o registro de decisões tomadas com uso de conhecimento tácito,
buscando explicitá-lo.” (R2)
“Às vezes, o tomador de decisões não pode ou não quer explicitar os critérios de decisão
utilizados.” (TD-Esp1)
128
Uma ferramenta pode melhorar um processo de tomada de decisão de MPS.
Aprimoramento: A usabilidade, o controle de acesso e o controle de versões de decisões são
requisitos relevantes de uma ferramenta útil ao processo de tomada de decisão.
P7
“O uso de planilhas pode causar avaliação negativa pelos usuários ...” (R1)
“Acho fundamental o acesso controlado aos registros de decisões tomadas, seja para revisão
futura ou para comparação em caso de problemas semelhantes.” (D1-org A)
O sucesso de um processo formal de apoio à decisão para o alinhamento estratégico de iniciativas
P8 de MPS depende diretamente do grau de envolvimento e comprometimento da alta direção da
organização (decisores do nível estratégico).
Em outras palavras, não é possível adotar um processo que envolve a

participação direta da alta gerência, sem seu compromisso claro e definido. Humphey
(1989), em seu primeiro princípio básico de mudança de processo, estabelece que
“grandes mudanças no processo de software devem começar no topo”.
A seguir, é descrito o componente do processo da solução. A ferramenta deverá

ser aprimorada e por este motivo não é apresentada como resultado do presente
trabalho.
4.3. A Solução proposta

Devido à limitação de espaço, não é viável detalhar os procedimentos envolvidos em
cada atividade do processo ilustrado na Figura 3. O objetivo é fornecer sua visão geral.
Figura 3. O processo de apoio à tomada de decisão.

Os papéis relacionados aos decisores nos níveis estratégico e tático podem ser
combinados em uma única pessoa, como ocorreu na organização E (ver Tabela 1). Uma
ferramenta (SAD) armazena informações relevantes sobre as escolhas entre alternativas
e critérios adotados. Em alguns casos, o SAD apoiará decisões por meio de dados
históricos. O primeiro passo do processo, representado por um subprocesso, possui duas
atividades mostradas na Figura 4.
Figura 4. O subprocesso Identificação de Problemas.
129
Para identificar problemas, a análise de forças, fraquezas, oportunidades e
ameaças, ou Análise SWOT (Pickton e Wright 1998), extrai problemas no nível
organizacional. Os problemas são analisados quanto a possíveis causas-raiz, usando os
cinco porquês (Myszewski 2013) ou outro método de análise causal. Os problemas
considerados causas-raiz são priorizados usando uma matriz Gravidade-Urgência-
Tendência (GUT) resultando na lista ordenada de problemas (Backlog de problemas).
Seleção de Alternativas é outro subprocesso, detalhado na Figura 5. Como
mencionado anteriormente, a versão aprimorada da solução oferece um caminho ágil
para registrar uma escolha consensual (vide proposição P5). As alternativas devem ser
identificadas antes da seleção dos critérios de decisão (vide proposição P3).
Figura 5. O subprocesso Seleção de Alternativas.

As alternativas selecionadas compõem uma lista que é submetida à aprovação do
nível de decisão estratégico, garantindo assim o alinhamento das ações de MPS com os
objetivos da alta direção.
5. Ameaças à Validade
Apesar de esforços para reduzir ameaças à validade interna, selecionando uma amostra
diversificada de organizações e empregando a triangulação em diferentes níveis (Morse
2015), este estudo pode apresentar viés devido à amostragem intencional. O objetivo foi
facilitar o tratamento de questões éticas e o rapport. No entanto, esse rapport pode ser
responsável por outra ameaça à validade, pois a parceria entre os pesquisadores e as
instituições colaboradoras pode ter provocado a presença de um efeito Hawthorne
(McCambridge et al. 2014), induzindo respostas com viés positivo.
O contexto é importante para a generalização (Petersen e Wohlin 2009). Assim,
falhas em sua definição podem representar uma ameaça à validade externa. A
amostragem intencional para a Validação Estática pode representar uma ameaça à
validade externa da investigação, uma vez não ser possível generalizar resultados com
base em apenas três casos. No entanto, em harmonia com a afirmação de Corbin e
Strauss (2015) de que “a generalização não é o objetivo da pesquisa qualitativa”,
buscou-se obter credibilidade no estudo por meio de outros procedimentos. Como
recomendado por Creswell e Miller (2000), com a aplicação de diferentes tipos de
triangulação (de pesquisadores, de métodos e de dados), peer review, debriefing e pelo
trabalho em estreita colaboração com os participantes, acredita-se ter alcançado a
confiabilidade.
130
6. Conclusões e Trabalhos Futuros
A principal contribuição deste estudo foi a ampliação do conhecimento sobre o processo
de tomada de decisão aplicado ao alinhamento entre as iniciativas de melhoria de
processos de software e metas organizacionais. As suposições iniciais foram
aprimoradas no transcorrer da pesquisa tornando possível obter confiança suficiente
para a sequência do trabalho futuro (Fase 3).
O aprimoramento conceitual sobre a tomada de decisões no alinhamento
estratégico de MPS confirma que o processo é útil e necessário para a sintonia entre
decisões estratégicas e táticas e, consequentemente, para o sucesso das ações planejadas
pelo nível tático (gestores de MPS). A fase de Validação Dinâmica determinará se a
solução oferecida poderá ser adequadamente transferida para a indústria. Igualmente
importante, um processo para o monitoramento e gestão de planos de ação derivados
das decisões, deverá ser concebido e validado.
Por fim, o estudo desperta a necessidade de investigação sobre os fatores,
relacionados à capacidade cognitiva humana e interação social, que implicam em
comportamentos dos decisores e refletem nos processos de apoio à tomada de decisões.
Tal conclusão está diretamente relacionada ao estudo de Lenberg et al. (2015).
Referências
Bayona, Sussy, Jose a. Calvo-Manzano, e Tomás San Feliu. 2012. “Critical Success
Factors in Software Process Improvement: A Systematic Review.” Software
Process Improvement and Capability Determination, 1–12.
Bazerman, Max H, e Don A Moore. 2009. Judgment in Managerial Decision Making.
7th ed. New Jersey: John Wiley & Sons, Inc.
Bhushan, Navneet, e Kanwal Rai. 2004. Strategic Decision Making: Applying the
Analytical Hierarchy Process. 1st ed. London: Springer-Verlag.
Corbin, Juliet, e Anselm Strauss. 2015. Basics of Qualitative Research: Techniques and
Procedures for Developing Grounded Theory. London: SAGE Publications.
Creswell, John W., e Dana L. Miller. 2000. “Determining Validity in Qualitative
Inquiry.” Theory Into Practice 39 (3): 124–30.
Davis, Fred D. 1989. “Perceived Usefulness, Perceived Ease of Use, and User
Acceptance of Information Technology.” MIS Quarterly 13 (3): 319.
Dybå, Tore. 2005. “An Empirical Investigation of the Key Factors for Success in
Software Process Improvement.” IEEE Transactions on Software Engineering 31
(5): 410–24.
Ebert, Christof. 1999. “Technical Controlling and Software Process Improvement.”
Journal of Systems and Software 46 (1): 25–39.
Gigerenzer, Gerd., e Reinhard. Selten. 2001. Bounded Rationality: The Adaptive
Toolbox. MIT Press.
Gorschek, Tony. 2015. “How to Increase the Likelihood of Successful Transfer to
Industry -- Going Beyond the Empirical.” In 2015 IEEE/ACM 3rd International
Workshop on Conducting Empirical Studies in Industry, 10–11. IEEE.
131
Gorschek, Tony, Per Garre, Stig Larsson, e Claes Wohlin. 2006. “A Model for
Technology Transfer in Practice.” IEEE Software 23 (6): 88–95.
Guest, Greg, Emily E. Namey, e Marilyn L. Mitchell. 2013. Collecting Qualitative
Data: A Field Manual for Applied Research. London: SAGE Publications Ltd.
Hastie, Reid., e Robyn M. Dawes. 2010. Rational Choice in an Uncertain World: The
Psychology of Judgment and Decision Making. London: SAGE Publications Ltd.
Humphrey, Watts S. 1989. Managing the Software Process. Boston, MA, USA:
Addison-Wesley Longman Publishing.
ISACA. 2012. COBIT 5: A Business Framework for the Governance and Management
of Enterprise IT. ISACA.
ISO/IEC. 2013. “ISO/IEC TR 33014:2013: Information Technology - Process
Assessment - Guide for Process Improvement.” International Organization for
Standardization.
———. 2015. “ISO/IEC 38500:2015 - Information Technology – Governance of IT for
the Organization.” International Organization for Standardization.
Johnson, Phil. 2004. “Analytic Induction.” In Essential Guide to Qualitative Methods in
Organizational Research, 165–79. London: SAGE Publications Ltd.
Laitenberger, O., e H.M. Dreyer. 1998. “Evaluating the Usefulness and the Ease of Use
of a Web-Based Inspection Data Collection Tool.” In Proceedings Fifth
International Software Metrics Symposium. Metrics, 122–32. IEEE Comput. Soc.
Lenberg, Per, Robert Feldt, e Lars Göran Wallgren. 2015. “Behavioral Software
Engineering: A Definition and Systematic Literature Review.” Journal of Systems
and Software 107 (September): 15–37.
Lepmets, Marion, e Tom McBride. 2012. “Process Improvement for the Small and
Agile.” In EuroSPI 2012, 310–18. Springer, Berlin, Heidelberg.
Lepmets, Marion, Tom McBride, e Eric Ras. 2012. “Goal Alignment in Process
Improvement.” Journal of Systems and Software 85 (6). Elsevier Inc.: 1440–52.
McCambridge, Jim, John Witton, e Diana R. Elbourne. 2014. “Systematic Review of
the Hawthorne Effect: New Concepts Are Needed to Study Research Participation
Effects.” Journal of Clinical Epidemiology 67 (3): 267–77.
Merriam, Sharan B. 2009. Qualitative Research: A Guide to Design and
Implementation. San Francisco: Jossey-Bass.
Morse, Janice M. 2015. “Critical Analysis of Strategies for Determining Rigor in
Qualitative Inquiry.” Qualitative Health Research 25 (9). SAGE PublicationsSage
CA: Los Angeles, CA: 1212–22.
Münch, Jürgen, Ove Armbrust, Martin Kowalczyk, e Martín Soto. 2012. “Process
Improvement.” In Software Process Definition and Management, 139–76.
Myszewski, Jan M. 2013. “On Improvement Story by 5 Whys.” Edited by Madhav
Sinha. The TQM Journal 25 (4). Emerald Group Publishing Limited: 371–83.
132
Osterweil, Leon J. 1987. “Software Processes Are Software Too.” In Proceedings of the
9th International Conference on Software Engineering, 2–13.
Petersen, Kai, e Claes Wohlin. 2009. “Context in Industrial Software Engineering
Research.” In Proceedings of the 2009 3rd International Symposium on Empirical
Software Engineering and Measurement, 401–4. IEEE Computer Society.
Peterson, Martin. 2009. An Introduction to Decision Theory. Cambridge: Cambridge
University Press.
Pickton, David W., e Sheila Wright. 1998. “What’s Swot in Strategic Analysis?”
Strategic Change 7 (2): 101–9.
Qumer, A., e B. Henderson-Sellers. 2008. “A Framework to Support the Evaluation,
Adoption and Improvement of Agile Methods in Practice.” Journal of Systems and
Software 81 (11): 1899–1919.
Recker, Jan. 2013. Scientific Research in Information Systems. Berlin: Springer Berlin
Heidelberg.
Ringstad, Mats Angermo, Torgeir Dingsøyr, e Nils Brede Moe. 2011. “Agile Process
Improvement: Diagnosis and Planning to Improve Teamwork.” In , 167–78.
Springer, Berlin, Heidelberg.
Saaty, Thomas L. 2008. “Decision Making with the Analytic Hierarchy Process.”
International Journal of Services Sciences 1 (1): 83.
Shull, Forrest, Jeffrey Carver, e Guilherme H. Travassos. 2001. “An Empirical
Methodology for Introducing Software Processes.” ACM SIGSOFT Software
Engineering Notes 26 (5): 288.
Silver, Mark S. 1990. “Decision Support Systems: Directed and Nondirected Change.”
Information Systems Research 1 (1). INFORMS: 47–70.
Simon, Herbert A. 1956. “Rational Choice and the Structure of the Environment.”
Psychological Review 63 (2). American Psychological Association: 129–38.
Stol, Klaas-Jan, e Brian Fitzgerald. 2015. “Theory-Oriented Software Engineering.”
Science of Computer Programming 101 (April): 79–98.
Trienekens, Jos J.M., Rob J Kusters, Ben Rendering, e Kees Stokla. 2005. “Business-
Oriented Process Improvement: Practices and Experiences at Thales Naval The
Netherlands (TNNL).” Information and Software Technology 47 (2): 67–79.
Unterkalmsteiner, Michael, Tony Gorschek, A. K. M. M. Islam, Chow Kian Cheng,
Rahadian. B. Permadi, e Robert Feldt. 2012. “Evaluation and Measurement of
Software Process Improvement - A Systematic Literature Review.” IEEE
Transactions on Software Engineering 38 (2): 398–424.
Vasconcellos, F.J.S., G.B. Landre, J.A.O.G. Cunha, J.L. Oliveira, R.A. Ferreira, e
A.M.R. Vincenzi. 2017. “Approaches to Strategic Alignment of Software Process
Improvement: A Systematic Literature Review.” Journal of Systems and Software
123: 45–63.
Wieringa, Roel. 2014. Design Science Methodology for Information Systems and
Software Engineering. Berlin, Heidelberg: Springer Berlin Heidelberg.
133
Mudança Organizacional Dirigida a Melhoria de Processos
de Software: Um Mapeamento Sistemático
Monica Anastassiu1, Gleison Santos1, Flavia Santoro2
1
Programa de Pós-graduação em Informática – Universidade Federal do Estado do Rio
de Janeiro (UNIRIO) - Rio de Janeiro – RJ – Brasil
2
Departamento de Informática Aplicada – Universidade Federal do Estado do Rio de
Janeiro (UNIRIO) - Rio de Janeiro – RJ – Brasil
{monica.anastassiu,gleison.santos,flavia.santoro}@uniriotec.br
Abstract. The challenge faced by organizations to master the change process

creates barriers that can affect software process improvement (SPI) initia-
tives. A systematic mapping of the literature was carried out with the aim at
identifying and analyzing the elements that integrate different approaches re-
garding organizational change driven to SPI initiatives. Factors associated to
organizational change such as processes, people, competences, organizational
culture and leadership among others were identified based on 24 papers. The
research findings served as the basis for the construction of a conceptual meta
model for organizational change in the SPI context and can support the de-
velopment of improved strategies and approaches for driving SPI initiatives.
Resumo. A dificuldade que as organizações têm de dominar o processo de

mudança cria obstáculos que podem afetar iniciativas de melhoria de proces-
sos de software (SPI). Para identificar e analisar os elementos que integram
diferentes abordagens sobre mudança organizacional dirigidas a iniciativas
de melhorias de processos de software foi realizado um mapeamento sistemá-
tico da literatura. A partir de 24 artigos, foram identificados fatores envolvi-
dos na mudança organizacional como processos, pessoas, competências, cul-
tura organizacional e liderança, dentre outros. Sendo uma iniciativa de SPI
também uma mudança, os achados serviram de base para a construção de um
meta-modelo conceitual de mudança organizacional dirigida à SPI e podem
servir de apoio à elaboração de melhores estratégias e abordagens para con-
dução de iniciativas de melhoria de processos de software.
1. Introdução
O nível de exigência da qualidade dos serviços prestados pelas empresas de software
tem aumentado nos últimos anos. Neste cenário competitivo, as organizações de sof-
tware vêm adotando programas de melhoria em seus processos de software a fim de
produzir softwares de qualidade [Fuggetta, 2000; Montoni, 2010; Schots et al., 2011].
Modelos de maturidade, tais como o MR-MPS-SW [SOFTEX, 2016] e o CMMI-DEV
[SEI, 2010] e normas internacionais como a ISO/IEC 12207 [ISO/IEC, 2008c], são refe-
rências para guiar uma iniciativa de melhoria de processo de software em uma organi-
zação. Entretanto, independentemente de modelos a serem adotados, é necessária uma
gestão eficaz das mudanças a serem implantadas para que uma melhoria de processos
134
de software seja bem-sucedida [Mathiassen et al., 2005].
A dificuldade que as organizações têm de dominar o processo de mudança cria
obstáculos, tais como: estado de alerta organizacional, dificuldades com a decisão sobre
a mudança e resistência organizacional para novas iniciativas. A adoção de novas roti-
nas, em função de mudanças organizacionais, tem impactos relevantes em uma organi-
zação fomentados por estes obstáculos, como por exemplo: esforço adicional de plane-
jamento necessário para realizar a mudança com sucesso, eventual incerteza sobre os
resultados que a nova oportunidade de negócio vai levar, baixa eficiência inicial do
novo processo, tempo e custo da curva de aprendizado e, interdependências positivas e
negativas das novas rotinas com o estoque de rotinas estabelecidas em vigor [Kesting e
Smolinski, 2006]. Existem diversos estudos na literatura [Allison e Merali, 2007; Mar-
tins e Da Silva, 2010; Ferreira e Wazlawick, 2011; Matturro e Saavedra, 2012; Korsaa
et al., 2013; Pernstål et al., 2013; Virtanen et al., 2013, Kouzari et al., 2015] que per-
correm as questões a serem tratadas, tanto no âmbito tecnológico quanto no âmbito so-
ciocultural e organizacional, em uma mudança organizacional. Todavia, não foi possí-
vel identificar um conjunto de causas, efeitos e modos de atestar o alcance dos
objetivos de uma mudança organizacional.
Tomando como base que a melhoria de processos de software é a própria mu-
dança [Allison e Merali, 2007], este trabalho busca compreender como os aspectos re-
lacionados à mudança organizacional estão relacionados à melhoria de processos de
software. Assim, um mapeamento sistemático da literatura foi realizado para investigar
os elementos de mudança organizacional no contexto de iniciativas de melhorias de
processos de software, ampliando a investigação sobre fatores críticos de sucesso em
melhoria de processos de software. Compreender os fatores, de mudança organizacio-
nal, pode servir de apoio à elaboração de melhores estratégias e abordagens para con-
dução de iniciativas de melhoria de processos de software.
O restante do artigo está estruturado da seguinte forma: na Seção 2, apresenta-
mos a fundamentação teórica. Na seção 3, apresentamos a metodologia de pesquisa
escolhida. Na Seção 4, são apresentados os principais resultados obtidos. Na seção 5
são discutidos os resultados do estudo. Por fim, nossa conclusão é apresentada na Seção
6.
2. Fundamentação Teórica
Esta seção apresenta os conceitos relativos ao estudo, pesquisados por meio de uma
revisão informal da literatura sobre mudança organizacional em melhoria de processos
de software.
2.1 Mudança Organizacional

Para uma organização aumentar a capacidade de lidar com as exigências e expectativas
do mercado e de seus stakeholders, seus processos precisam ser modificados e aperfei-
çoados continuamente [Fuggetta, 2000]. Entretanto, a definição de mudança organiza-
cional não é facilmente encontrada na literatura. Destacamos o trabalho de Wincek et
al. (2014) onde constatamos o que mais se aproxima de uma definição sobre mudança
organizacional: “mudança organizacional é definida, no âmbito da gestão de mudança
organizacional, como qualquer mudança na posição ou na responsabilidade em uma
135
organização ou qualquer mudança em uma política organizacional ou procedimento,
que possam induzir riscos aos processos organizacionais considerados críticos”.
Mudanças resultam de ações intencionais de acordo com um objetivo ou por
meio de fatores contextuais, tais como pressões institucionais. Porém, em ambos os
casos, a mudança é retratada como a passagem de uma entidade de um estado, único e
identificável, para outro estado [Quattrone e Hopper, 2001]. A mudança altera proces-
sos de trabalho e reestrutura áreas de negócio buscando ajustar o foco da organização
para implantar novas estratégias e manter a condição de vantagem competitiva. A ques-
tão é transformar-se, reinventar-se, objetivando estar sempre em condições sustentáveis
de competitividade e que, embora haja uma concordância no mundo corporativo sobre a
necessidade de mudanças organizacionais, implantá-las não é uma tarefa simples, com
uma receita certa e definitiva [Barcaui, 2012].
Caracterizada pela subjetividade, a mudança organizacional é sujeita tanto às
percepções individuais, variando de pessoa para pessoa, quanto a como a organização
evidencia o fenômeno dentro de seus limites [Cao et al., 2000]. Mudanças organizacio-
nais também podem gerar outras mudanças que precisam ser igualmente tratadas e su-
jeitas a uma gestão efetiva, por exemplo, modificação nas condições de trabalho, mu-
dança pessoal, mudanças na alocação de tarefas e mudanças na hierarquia organizacio-
nal [Wincek et al., 2014].
A mudança organizacional é classificada em quatro tipos [Cao, et al., 2000]: (1)
mudanças nos processos organizacionais; (2) mudanças nas funções organizacionais;
(3) mudanças nos valores, crenças e comportamento humano em termos de relações
sociais para regras e práticas e; (4) mudanças na distribuição de poder e o modo como
as questões organizacionais são influenciadas. Todos estes tipos se interligam e se afe-
tam mutuamente, apresentando-se de uma forma sistêmica e, portanto, não isoladamen-
te [Cao et al., 2000].
Fatores contextuais internos (por exemplo: mudanças em valores e objetivos, em
estruturas organizacionais e cultura organizacional), fatores contextuais externos (por
exemplo: mudanças no ambiente, de mercado, nas atividades dos concorrentes e novas
tecnologias) são apontados como causadores de mudança organizacional [Cao et al.,
2000; Quattrone e Hopper, 2001; Nurcan e Rolland, 2003; Mathiassen et al., 2005].
Exemplos de possíveis efeitos causados pela mudança organizacional são: por um lado,
a diminuição da produtividade por conta do tempo necessário para a aprendizagem [Bo-
ria et al., 2012] e por outro a elevação do grau de consciência inovadora dos emprega-
dos quando, por causa da mudança, as capacidades dinâmicas destes são estimuladas
[Zhao e Liu, 2008]. Impactos gerados por uma mudança organizacional podem ser re-
duzidos planejando-se a mudança por etapas consoante com a cultura organizacional.
Neste sentido, a organização deve fornecer apoio às novas condutas do pessoal envolvi-
do na mudança, além de providenciar um patrocinador e agentes de mudança em níveis
mais baixos [Boria et al., 2012].
Uma mudança pode ser considerada de natureza estratégica ou significativa
quando existe impacto sobre a empresa devido a alguma adaptação organizacional radi-
cal [Chrusciel e Field, 2003], podendo induzir riscos aos processos organizacionais con-
siderados críticos [Wincek et al., 2014]. Mudanças que não induzem riscos aos proces-
sos organizacionais considerados críticos, não são mudanças organizacionais sujeitas a
136
um gerenciamento [Wincek et al., 2014].
Finalmente, constata-se que mudanças geram efeitos, quer sejam nas pessoas,
quer sejam nos processos, quer sejam na organização como um todo. Embora identifi-
cados alguns efeitos que a mudança possa gerar, não foi observada, na literatura, men-
ção sobre a medição de tais efeitos sob a perspectiva da relação custo e benefício.
2.2 Melhoria de Processos de Software

A fim de propor um gerenciamento eficaz do processo de software, diferentes aborda-
gens foram desenvolvidas das quais a melhoria de processos de software é a mais am-
plamente utilizada [Niazi et al., 2006]. Melhoria de processos de software (SPI, do in-
glês software process improvement) é uma abordagem sistemática para aumentar a efi-
ciência e eficácia de uma organização de desenvolvimento de software e melhorar pro-
dutos de software [Unterkalmsteiner et al., 2012]. Um projeto de SPI tem como objeti-
vo conhecer, definir e/ou melhorar os processos relacionados ao desenvolvimento de
software para torná-los mais efetivos e eficientes [Mendes et al., 2010].
No contexto de melhoria de processos de software, as próprias iniciativas de SPI
são a mudança. Por sua natureza, é considerada uma mudança emergente e restrita ao
contexto no qual estão inseridas. O desafio é compreender que a mudança não é um
resultado previsível e determinístico, mas um processo que surge a partir do relaciona-
mento entre as pessoas e seu contexto [Alisson e Merali, 2007]. Afetada por aspectos
sociais, uma vez que os processos implementados são definidos e usados por pessoas,
uma iniciativa de SPI se caracteriza por ser um complexo processo técnico-social-
psicológico [Bayona et al., 2013], acarreta em mudança em processos e nas funções
organizacionais [Wincek et al., 2014; Mathiassen et al., 2005] e resulta em aprendiza-
gem dos envolvidos e em mudanças na forma como as pessoas se comunicam e colabo-
ram enquanto executam seus trabalhos [Heikkilä, 2009]. Seu processo de gestão não
pode ser totalmente prescrito por ser a mudança muito dependente do contexto no qual
está inserida [Nurcan e Rolland, 2003].
O sucesso de iniciativas de SPI é influenciado por problemas, denominados de
fatores críticos, que são de caráter sociocultural, tecnológico e organizacional, sendo
sua compreensão fundamental para apoiar a gerência na implementação das melhorias
[Montoni, 2010]. Exemplos de fatores críticos de sucesso são: a escassez de competên-
cias [Beecham et al., 2003], a cultura organizacional [Müller et al., 2010], o conheci-
mento em mudança organizacional [Müller et al., 2010], a alocação de recursos, a
conscientização sobre SPI, a definição de metodologias de implementação de SPI, a
experiência dos empregados e o envolvimento da alta direção [Niazi et al., 2006; Kou-
zari et al., 2015].
Melhoria de processos de software pode não ser bem-sucedida sem compromis-
so gerencial e domínio de táticas apropriadas de mudanças, necessitando de estratégias
e habilidades para gerenciar a mudança [Mathiassen et al., 2005], de agentes de mudan-
ça para colocar em prática os novos processos e do envolvimento dos empregados para
manter a motivação da equipe e minimizar a resistência [Bayona et al., 2013].
O método de pesquisa selecionado para este estudo foi um mapeamento sistemático da
137
literatura (MSL). Segundo Kitchenham e Charters (2007), o MSL fornece uma visão
geral de um determinado tópico assegurando a repetitividade e reduzindo a possibilida-
de de viés do pesquisador. A execução de um MSL inclui as fases de planejamento (de-
finição do protocolo), condução (execução do protocolo, extração e análise dos dados) e
relato (disponibilização dos resultados). A seguir, apresentamos as principais partes do
protocolo de pesquisa e de sua execução.
3.1. Definição do protocolo

O objetivo deste estudo é identificar e analisar, em fontes de evidência, os elementos
que integram as diferentes abordagens sobre mudança organizacional no contexto de
iniciativas de melhorias de processos de software. Foi definida uma questão principal
de pesquisa (QPP) que foi subdividida em cinco questões secundárias (QS), apresenta-
das na Tabela 1. Critérios de exclusão (CE) e de inclusão (CI) foram igualmente defini-
dos e apresentados, respectivamente, nas Tabela 2 e 3.
Ta b e la 1. Qu e s tõ e s d e p e s q uis a p a ra o MS L s o b re m ud a nç a o rg a niza c io na l no c o nte xto
d e inic ia tiva s d e m e lh o ria d e p ro c e s s o d e s o ftwa re
QPP - Questão principal de pesquisa: Como é percebida a mudança organizacional no contexto de inici-
ativas de melhorias de processos de software em organizações?
QS1. O que é mudança organizacional no contexto de iniciativas de melhoria de processo de software?
QS2. Quais são as características da mudança organizacional e como estas influenciam as iniciativas de
melhoria de processo de software?
QS3. Qual é o foco da abordagem utilizada para apoiar as mudanças organizacionais no contexto de
iniciativas de melhoria de processo de software?
QS4. Quais são os impactos e consequências tratados pela abordagem que apoia a mudança organizaci-
onal no contexto de iniciativas de melhoria de processo de software?
QS5. Quais são as causas da mudança organizacional e como estas influenciam as inciativas de melhoria
de processo de software?
A biblioteca digital SCOPUS1, que possui máquina de busca com bom funcio-
namento e abrangência, foi selecionada como fonte de pesquisa. A string de busca utili-
zada para a pesquisa das publicações foi: ("software process improvement" or "SPI")
and ("change"). Decidiu-se fazer a busca da maneira mais ampla para aumentar o esco-
po de trabalhos retornados e evitar a exclusão de trabalhos baseados exclusivamente ao
uso de possíveis palavras-chave mais restritivas. A busca foi restrita à língua inglesa e
considerou trabalhos entre janeiro de 1999 e agosto de 2015.
Ta b e la 2. Crité rio s d e inc lu s ã o
Critério de Inclusão
CI1. Publicações que tratem de discussões teóricas sobre Mudança Organizacional no contexto de SPI.
CI2. Publicações que incluam discussão teórica sobre gestão de mudança no contexto de SPI.
CI3. Publicações que tragam um estudo de caso ou cenário real sobre gestão de mudança no contexto de
SPI.
CI4. Publicações que descrevam um método ou proposta para gestão de mudança no contexto de SPI.
CI5. Publicações que descrevam uma abordagem, um método ou proposta para implementar SPI.
CI6. Publicações que descrevam revisões sistemáticas ou mapeamentos sistemáticos relacionados a uma
das palavras-chave e suas variações.
Ta b e la 2. Crité rio s d e e xc lu s ã o
Critério de Exclusão
1
http://www.scopus.com
138
Critério de Exclusão
CE1. Publicações nas quais as palavras-chave da busca e suas variações (exceto plural) não estejam pre-
sentes no título e/ou no resumo e/ou nas palavras-chave.
CE2. Publicações que possuem as palavras-chave e suas variações presentes no título, resumo e palavras-
chave, porém não no corpo do texto da publicação (excetuando-se as seções de agradecimentos, biogra-
fia dos autores, referências bibliográficas e anexos).
CE3. Publicações em que a sigla SPI não signifique “software process improvement”.
CE4. Publicações que não seja possível adquirir o texto completo.
CE5. Publicações irrelevantes como capas de proceedings, anúncios de workshops, dentre outras.
CE6. Publicações que possuem as palavras-chave e suas variações, mas não tem uma proposta concreta
sobre assunto.
CE7. Publicações em que as palavras-chave da busca são utilizadas no corpo do texto, porém sem des-
crever uma iniciativa de melhoria de processos de software.
CE8. Publicações em que as palavras-chave da busca são utilizadas no corpo do texto e que descreva
uma iniciativa de melhoria de processos de software sem que haja qualquer menção à mudança.
3.2. Execução do protocolo

O procedimento de seleção foi realizado em quatro etapas (E):
• (E1) Seleção e catalogação preliminar das publicações coletadas a partir da
execução da string de busca na biblioteca digital;
• (E2) Seleção das publicações relevantes - 1º filtro para descarte de documentos
irrelevantes contidos no conjunto preliminar, por meio da leitura e a análise do
título, do resumo (abstract) e das palavras-chave e, da aplicação do critério de
exclusão (CE1);
• (E3) Seleção das publicações relevantes - 2º filtro para descarte de documentos
irrelevantes selecionados na Etapa 2, por meio da aplicação dos critérios de ex-
clusão (CE4) e (CE5); e
• (E4) Seleção das publicações relevantes - 3º filtro para garantir que todo o ma-
terial selecionado seja útil no contexto da pesquisa, por meio da leitura comple-
ta de cada publicação e da aplicação dos seguintes critérios de exclusão e de in-
clusão: (CE2), (CE3), (CE6), (CE7), (CE8), (CI1), (CI2), (CI3), (CI4), (CI5) e
(CI6).
4. Resultados
O MSL retornou 134 publicações, aos quais foram aplicados os procedimentos de sele-
ção citados em 3.2. Após a aplicação do 1º filtro (Etapa 2), restaram 83 publicações.
Após a aplicação do 2º filtro (Etapa 3), foram descartadas 39 publicações. Com a apli-
cação do 3º e último filtro (Etapa 4), 24 publicações foram selecionadas (cerca de 18%
do total de publicações).
As questões de pesquisa foram aplicadas às 24 publicações. Os 24 artigos sele-
cionados são apresentados na Tabela 4, indicando a contribuição para cada questão de
pesquisa.
As publicações variam de 1999 a 2014 (nenhum artigo de 2015 foi encontrado).
Com relação ao veículo de publicação, 82 publicações (61%) foram publicadas em re-
vistas e 40 (30%) em eventos científicos. A distribuição dos estudos com uma maior
139
concentração de estudos publicados em revistas, é um indício de que o tópico vem
amadurecendo na última década.
Ta b e la 4. P ub lic a ç õ e s s e le c io na d a s e c o ntrib uiç ã o p a ra a s q ue s tõ e s d e p e s q uis a
ID Publicação QS1 QS2 QS3 QS4 QS5
1 [Allison e Merali, 2007] X X X X
2 [Baddoo e Hall, 2003] X X X
3 [Bannerman, 2008] X
4 [Beecham et al., 2003] X
5 [Ferreira e Wazlawick, 2011] X X X X
6 [Holmberg et al., 2009] X X
7 [Mathiassen et al., 2005] X X X X
8 [Korsaa et al., 2013] X X X
9 [Martins e Da Silva, 2010] X X
10 [Matturro e Saavedra, 2012] X X X
11 [Heikkilä, 2009] X X X X
12 [Muñoz et al., 2011a] X X
13 [Muñoz et al., 2011b] X X X
14 [Moe e Dybå, 2006] X X X
15 [Muñoz et al., 2012] X X
16 [Muñoz et al., 2013] X X
17 [Niazi et al., 2008] X
18 [Peixoto et al., 2010] X
19 [Pernstål et al., 2013] X X
20 [Rainer e Hall, 2003]
21 [Müller et al., 2010] X X
22 [Sihvonen e Jantti, 2011] X X X
23 [Tuisk et al., 2012] X X
24 [Unterkalmsteiner et al., 2012] X X
A seguir, apresentamos os principais resultados obtidos com uma discussão

sobre cada questão de pesquisa formulada.
QPP: “Como é percebida a mudança organizacional no contexto de iniciativas de
melhorias de processos de software em organizações?”
Do total de publicações retornadas, 15 publicações (62%) consideram a melho-
ria de processos uma mudança organizacional, ou vice-versa. Apenas em uma publica-
ção [Bannerman, 2008] é declarado que mudança de processo não se equivale à melho-
ria de processo, necessariamente. Isto porque, segundo os autores, se a mudança
acontecer em um subprocesso e não levar em conta todo o processo, o processo como
um todo pode piorar no lugar de melhorar.
Os trabalhos encontrados afirmam que a mudança organizacional é complexa
[Holmberg et al., 2009], dependente da motivação das pessoas [Korsaa et al., 2013],
necessita de planejamento adequado [Pernstål, et al., 2013] e é relevante aos processos
de software [Rainer e Hall, 2003], afetando-os [Sihvone e Jantti, 2011]. Além disso,
afirmam que seu gerenciamento é chave para o sucesso de melhorias de processos de
software [Mathiassen et al., 2005] podendo ser um problema organizacional [Beecham
et al., 2003].
A melhoria de processo requer mudanças organizacionais e comportamentais
[Heikkilä, 2009]: maneiras como as pessoas se comunicam e como colaboram ao exe-
cutarem seu trabalho. Mudança é um fator relevante para o sucesso da SPI e mais im-
140
portante do que os fatores principais de apoio executivo e de experiência da equipe
[Rainer e Hall, 2003].
QS1: “O que é mudança organizacional no contexto de iniciativas de melhoria de
processo de software?”
Melhoria de processo de software é um caso particular de mudança
organizacional [Ferreira e Wazlawick, 2011; Muñoz et al., 2011a; Muñoz et al., 2011b;
Muñoz et al., 2013; Matturro e Saavedra, 2012]. A mudança não é um resultado previ-
sível, mas um processo emergente desenvolvido a partir do relacionamento entre as
pessoas e seu contexto [Allison e Merali, 2009], onde ferramentas e abordagens
estruturadas são aplicadas dentro das organizações para permitir sua transição de um
estado atual para um estado futuro desejado e vista como o resultado de um processo de
aprendizagem organizacional [Heikkilä, 2009].
QS2: “Quais são as características da mudança organizacional e como estas influen-
ciam as iniciativas de melhoria de processo de software?”
A complexidade dos relacionamentos, os motivos políticos que formam o com-
portamento dos envolvidos [Allison e Merali, 2007] e a natureza intensiva de aprendi-
zagem da mudança [Heikkilä, 2009] são facetas importantes de processos de mudança.
Para que a mudança aconteça é preciso mudar as pessoas [Mathiassen et al., 2005], da-
do que as pessoas podem apresentar resistência em aceitar mudanças em seus processos
de trabalho [Ferreira e Wazlawick, 2011; Korsaa et al., 2013]. Mudança de processo
pode ou não trazer benefícios aos negócios, embora ofereça oportunidades para melho-
rar o desempenho das empresas e vantagem competitiva [Bannerman, 2008]. Mudanças
precisam ser gerenciadas [Mathiassen et al., 2005; Heikkilä, 2009]. Além disso, é im-
portante destacar que uma mudança gera outras mudanças [Heikkilä, 2009].
QS3: “Qual é o foco das abordagens utilizadas para apoiar as mudanças organizaci-
onais no contexto de iniciativas de melhoria de processo de software?”
Diversas abordagens foram identificadas nos trabalhos selecionados. Pode-se
destacar o foco de algumas delas:
• Apoiar o entendimento do processo de mudança e seu entrelaçamento com o
processo de desenvolvimento de software [Allison e Merali, 2007].
• Guiar gerentes na definição de estratégias baseadas na natureza das questões que
desmotivam grupos de profissionais de software [Badoo e Hall, 2003], ter co-
nhecimento holístico sobre os problemas experimentados no desenvolvimento
de software [Beecham et al., 2003] e servir-se das práticas de trabalho existentes
[Holmberg et al., 2009].
• Comunicar os objetivos e métodos da mudança [Heikkilä, 2009] e implantar me-
lhorias de processo de forma gradual e contínua [Muñoz et al., 2011a].
• Manter o foco nos aspectos humanos [Korsaa et al., 2013] e obter a participação
e o envolvimento das pessoas em todas as fases da implementação da melhoria
de processo de software [Moe e Dybå, 2006].
• Permitir que as organizações identifiquem oportunidades de melhoria e endere-
cem os esforços nos processos de software que precisem ser melhorados, a fim
141
de alcançar os objetivos do negócio [Muñoz et al., 2012].
• Envolver as partes interessadas da melhoria de processo de software [Muñoz et
al., 2013] e estabelecer apoio à tomada de decisão baseado nas necessidades or-
ganizacionais [Pernstål et al., 2013].
• Apoiar mudanças e evoluções de processos de software usando técnicas de me-
ta-modelagem de processos que não apenas identifiquem os conceitos mais
apropriados somente para representar modelos de processos, mas também o que
foi efetivamente melhorado no processo [Martins e Da Silva, 2010].
QS4: “Quais são os impactos e consequências tratados pela abordagem que apoia a
mudança organizacional no contexto de iniciativas de melhoria de processo de sof-
tware?”
Dentre os impactos e consequências identificados estão:
• Massa crítica de pessoas fazendo mudanças que todos acreditam serem necessá-
rias, mentalidade de organização como um todo, mudanças simultâneas e mu-
danças percebidas como trabalho real [Holmberg et al., 2009].
• Insucesso em iniciativas de melhoria de processo de software por não levar em
conta pessoas, cultura e estruturas [Mathiassen et al., 2005].
• Resistência e motivação das pessoas envolvidas com melhoria de processos
[Korsaa et al., 2013].
• O processo de mudança resulta em novo comportamento e torna-se rotina na vi-
da prática e diária dos negócios da empresa [Heikkilä, 2009].
• Perceber as práticas contidas no novo processo como uma evolução da forma
como a organização já trabalhava, evita a resistência das pessoas à mudança
[Muñoz et al., 2011b].
• Aumento da capacidade de aprendizagem dos empregados, bem como da sua
capacidade de influenciar os resultados organizacionais. Maior comprometimen-
to, motivação em realizar e desejo por responsabilidades [Moe e Dybå, 2006].
QS5: “Quais são as causas da mudança organizacional e como estas influenciam as
inciativas de melhoria de processo de software?”
Iniciativas de melhoria de processos de software são originadas pelo contexto no
qual estão inseridas e por ações das pessoas envolvidas neste processo [Allison e Mera-
li, 2009; Mathiassen et al., 2005]. O contexto, caracterizado pelo ambiente interno, co-
mo por exemplo: baixo desempenho, novas ferramentas adquiridas para apoiar a equipe
de desenvolvimento de software, mudança na estratégia de marketing, mudança de re-
quisitos e expectativas de clientes [Martins e Da Silva, 2010].
5. Discussão
Melhoria de processos (incluindo processos de software) é considerada uma mudança
organizacional. No entanto, nem toda mudança pode ser considerada uma melhoria.
Uma mudança organizacional requer controle e monitoramento e depende fundamen-
talmente das pessoas envolvidas, sendo esta requisição e característica igualmente apli-
142
cadas à melhoria de processos de software.
Observamos que a mudança organizacional é caracterizada pelo seu caráter
emergente, que resulta como consequência de algo, e pela complexidade de seus relaci-
onamentos, não sendo possível ter uma definição específica sobre ela. O foco das abor-
dagens utilizadas para apoiar as mudanças organizacionais no contexto de iniciativas de
melhoria de processo de software recai principalmente na atenção a ser dada aos aspec-
tos humanos: desenvolver competências da equipe envolvida com a melhoria, obter a
participação e o envolvimento das pessoas e o comprometimento da alta direção, de-
senvolver uma comunicação adequada e valorizar práticas internas, dentre outros aspec-
tos. Os principais impactos gerados pela mudança são: resistência e motivação das pes-
soas envolvidas, queda na produtividade devido à curva de aprendizagem e desenvol-
vimento de novos comportamentos. A causa principal de uma mudança no âmbito da
melhoria de processos de software advém do contexto no qual a mudança está inserida.
Este contexto pode estar associado ao ambiente interno da organização, como por
exemplo a aquisição de novas ferramentas para apoiar equipes de desenvolvimento de
software, ou ao ambiente externo à organização, como por exemplo exigências de clien-
tes e regulações compulsórias.
É possível concluir que, tanto a mudança organizacional quanto as iniciativas de
melhoria em processo de software, são influenciados por aspectos que vão além das
questões técnicas e processuais. São influenciadas sobremaneira pelas pessoas que nes-
tes cenários estão envolvidas.
Esta pesquisa também serviu de base para a construção de um meta-modelo
conceitual para mudança organizacional em melhoria de processo de software [Anas-
tassiu et al., 2016], que visa associar os conceitos e abordagens importantes sobre mu-
dança organizacional, alinhando-se ao objetivo desta pesquisa. O meta-modelo é apre-
sentado na Figura 1. A aplicabilidade do meta-modelo foi avaliada por meio de um es-
tudo de caso exploratório e retroativo, mediante o histórico de uma iniciativa de melho-
ria no processo de software de uma empresa atuante na área de previdência comple-
mentar. Os dados foram coletados e utilizados para instanciar o modelo. Os resultados
obtidos, relatados em [Anastassiu et al., 2016], apontaram que o meta-modelo conceitu-
al de mudança organizacional é capaz de representar parte dos conceitos importantes
envolvidos com mudança organizacional no contexto de uma iniciativa de melhoria de
software. O resultado do estudo de caso possibilitou gerar uma versão revisada do meta-
modelo, servindo de apoio ao planejamento de estratégias e ações para melhoria em
processos de software, especialmente àquelas relacionadas aos aspectos humanos. Adi-
cionalmente, o meta-modelo conceitual pode servir de modelagem inicial para a cons-
trução de um sistema de apoio à mudança organizacional.
Uma limitação deste trabalho é o fato da pesquisa não abranger outras bases de
dados além da biblioteca digital SCOPUS, reduzindo a quantidade de artigos a serem
pesquisados. No entanto, acreditamos que os trabalhos retornados permitiram responder
adequadamente as questões de pesquisa formuladas, fornecendo subsídios importantes
para compreender o fenômeno de mudança organizacional associada a melhoria de pro-
cessos de software.
143
Fig ura 1. Mo d e lo Co nc e itua l d e Mud a nç a Org a niza c io na l. Fo nte : (Ana s ta s s iu e t a l., 2016)
144
6. Conclusão
Estando as organizações progressivamente dependentes de softwares, fica cada vez
mais premente desenvolver softwares de qualidade. Esta qualidade está sujeita ao pro-
cesso de como o software é desenvolvido. Melhorar continuamente este processo de-
pende de diversos fatores, dentre os quais fatores relacionados à mudança organizacio-
nal.
Este artigo apresenta os principais resultados de um mapeamento sistemático da
literatura, cujo objetivo era identificar e analisar os elementos que integram as diferen-
tes abordagens sobre mudança organizacional no contexto de iniciativas de melhorias
de processos de software. O resultado desta investigação mostrou que é possível consta-
tar que a mudança é intrínseca à melhoria de processos de software e, consequentemen-
te, os fatores a ela relacionados estão igualmente associados às melhorias de processos
de software, como, por exemplo: o contexto como potencial causa de uma melhoria de
processos dando-lhe um caráter particular, a necessidade de aprendizagem e a obtenção
das competências necessárias como características da mudança e os impactos que influ-
enciam o sucesso da melhoria causados por não se levar em conta a cultura organizaci-
onal, as estruturas e as pessoas. Essa pesquisa também serviu de base para a construção
de um meta-modelo conceitual para mudança organizacional em melhoria de processo
de software [Anastassiu et al., 2016], que visa associar os conceitos e abordagens im-
portantes sobre mudança organizacional. Atualmente os autores estão investigando os
fatores relacionados à resistência a mudança no contexto da melhoria de processos de
software.
Entendemos que os resultados obtidos podem servir de apoio à elaboração de
melhores estratégias e abordagens para a condução de iniciativas de melhoria de pro-
cessos de software.
Agradecimentos
Os autores agradecem à CAPES e à FAPERJ (projetos E-26/210.643/2016, E-
211.174/2016) e à UNIRIO (Edital PQ-UNIRIO no. 01/2016 e 01/2017) pelo apoio fi-
nanceiro.
Referências
Allison, I., Merali, Y. (2007), “Software process improvement as emergent change: A
structurational analysis”, In: Information and Software Technology, v. 49, pp. 668–
681.
Anastassiu, M., Santos, G., Santoro, F. (2016), “Meta-modelo para Mudança Organiza-
cional em Melhoria de Processo de Software”. I Workshop sobre Aspectos Sociais,
Humanos e Econômicos de Software (WASHES), Maceió - AL, outubro de 2016.
Baddoo, N., Hall, T. (2003), “De-motivators for software process improvement: an
analysis of practitioners´views”, In: The Journal of Systems and Software, v. 66, ed.
1, pp. 22-33.
Bannerman, P. L. (2008), “Commitment to Software Process Improvement - Develop-
ment of Diagnostic Tool to Facilitate Improvement”. International Conference on
145
Software Engineering, Leipzig, Germany, May-13, 2008.
Barcaui, A. (2012), PMO Escritórios de Projetos, Programas e Portfólio na prática,
Brasport, 5ª edição.
Bayona, S., Calvo-Manzano, J. A., Feliu, T. S. (2013), Review of Critical Success Fac-
tors Related to People in Software Process Improvement. 20th European Conference,
EuroSPI 2013, Dundalk, Ireland, June 25-27, 2013. Proceedings.
Beecham, S., Hall, T., Rainer, A. (2003), “Software Process Improvement Problems in
Twelve Software Companies: An Empirical Analysis”, In: Empirical Software Engi-
neering, v. 8, ed. 1, pp. 7-42.
Boria, J., Rubinstein, V., Rubinstein, A. (2012), “Cambio y Cultura”. WAMPS 2012.
Cao, G., Clarke, S., Lehaney, B. (2000), “A systemic view of organizational change and
TQM”, In: The TQM Magazine, v. 12, Iss 3, pp. 186 - 193.
Chrusciel, D. and Field, D. W. (2003), “From Critical Success Factors into Criteria for
Performance Excellence – An Organizational Change Strategy”, In: Journal of Indus-
trial Technology, v. 19, No. 4. (August 2003 to October 2003).
Ferreira, M.G., Wazlawick, R.S. (2011), “Complementing the SEI-IDEAL model with
Deployers' real experiences: The need to address human factors in SPI initiatives”,
14th Ibero-American Conference on Software Engineering and 14th Workshop on
Requirements Engineering, CIbSE 2011.
Fuggetta, A. (2000), “Software Process: A Roadmap”, In: Proceedings of The Future of
Software Engineering, ICSE’2000, Limerick, Ireland.
Heikkilä, M. (2009), “Learning and Organizational Change in SPI Initiatives”, Springer-
Verlag Berlin Heidelberg 2009.
Kesting, P. and Smolinski, R. (2006), “Obstacles to Organizational Change – A Rou-
tine-Based View on Dynamic Capabilities”, Disponível em:
http://ssrn.com/abstract=905526.
Korsaa, M., Johansen, J., Schweigert, T., Vohwinkel, D., Messnarz, R., Nevalainen, R.,
Biro, M. (2013), “The people aspects in modern process improvement management
approaches”, In: Journal of software: Evolution and Process, 25(4), pp. 381-391.
Kouzari, E., Gerogiannis, V. C., Stamelos, I., Kakarontzas G. (2015), “Critical Success
Factors and Barriers for Lightweight Software Process Improvement in Agile Devel-
opment A Literature Review”, In: Software Technologies (ICSOFT), 10th Interna-
tional Joint Conference.
Martins, P. V., Da Silva, A. R. (2010), “PIT-ProcessM: A Software Process Improve-
ment meta-model”, 7th International Conference on the Quality of Information and
Communications Technology, QUATIC 2010, IEEE.
Mathiassen, L., Ngwenyama, K. O., Aaen I. (2005), “Managing Change in Software
Process Improvement”, IEEE SOFTWARE 2005.
Matturro, G., Saavedra, J. (2012), “Factors that affect software process improvement. A
systematic mapping of literature”, In: 15th Ibero-American Conference on Software
146
Engineering, CIbSE 2012, Buenos Aires, Argentina.
Moe, N. B., Dybå, T. (2006), “Improving by involving: A case study in a small software
company”, In: Lecture Notes in Computer Science (including subseries Lecture
Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), v. 4257 LNCS,
pp. 159-170.
Montoni, M., (2010), “Uma investigação sobre os fatores críticos de sucesso em inicia-
tivas de melhoria de processos de software”, Tese de D.Sc., Universidade Federal do
Rio de Janeiro - UFRJ, Rio de janeiro, RJ, Brasil. Morgan, D. L. (1997), “Focus
Groups as Qualitative Research”. Sage Publications, 2nd ed.
Müller, S. D., Mathiassenb, L., Balshøj, H. H. (2010), “Software Process Improvement
as Organizational Change: A metaphorical Analysis of the Literature”, In: The Jour-
nal of Systems and Software 83 (2010) 2128–2146.
Muñoz, M., Jezreel, M., Calvo-Manzano, J. A., Cuevas, G., San Feliu, T. (2011a), “The
results analysis of using MIGME-RRC methodology for software process improve-
ment”, In: Proceedings of the 6th Iberian Conference on Information Systems and
Technologies, CISTI 2011.
Muñoz, M., Jezreel, M., Giner, A., Calvo-Manzano J. A., San Feliu, T. (2011b), “Ad-
vantages of using a multi-model environment in software process improvement”, In:
Proceedings of the 6th Iberian Conference on Information Systems and Technolo-
gies, CISTI 2011.
Muñoz, M., Mejia, J., Calvo-Manzano, J. A., Cuevas, G., Feliu, S. B. (2013), “Method
to evaluate process performance focused on minimizing resistance to change”, In: In-
ternational Journal of Human Capital and Information Technology Professionals, v.
4, ed.2, pp. 1-15.
Muñoz, M., Mejia, J., Calvo-Manzano, J. A., Cuevas, G., San Feliu, T. (2012), “As-
sessment of organization software processes performance focusing on minimizing
resistance to change”, In: Iberian Conference on Information Systems and Technolo-
gies, CISTI.
Niazi, M., Wilson, D., Zowghi, D. (2006), "Critical success factors for software process
improvement implementation: An empirical study", In: Software Process Improve-
ment and Practice, v. 11, n. 2, pp. 193-211.
Nurcan, S. and Rolland, C. (2003), “A Multi-Method for Defining the Organizational
Change”, In: Information and Software Technology, v. 45, Issue 2, pp. 61–82.
Pernstål, J., Gorschek, T., Feldt, R., Florén, D. (2013), “Software process improvement
in inter-departmental development of software-intensive automotive systems - A
case study”, In: Lecture Notes in Computer Science, v. 7983, pp. 93-107. Springer-
Verlag Berlin Heidelberg 2013.
Quattrone, P. and Hopper, T. (2001), “What does Organizational Change Mean? Specu-
lations on a Taken for Granted Category”, In: Management Accounting Research,
2001, 12, 403–435.
Rainer, A. and Hall, T. (2003), “A quantitative and qualitative analysis of factors affect-
ing software processes”, In: Journal of Systems and Software, v. 66, nº 1, pp. 7-21.
147
SEI. (2010), CMMI-DEV, Versão 1.3, Pittsburg, Software Engineering Institute.
Sihvonen, H. M., Jantti, M. (2011), „How does training support software process im-
provement in organizational changes?”, In: Proceedings - 5th International Confer-
ence on New Trends in Information Science and Service Science, NISS 2011, v. 1,
pp. 8-15.
Tuisk, A., Karpištšenko, A., Lepmets, M. (2012), “Integrated process improvement ap-
proach: Case studies in Skype Technologies Ltd.”, In: Communications in Computer
and Information Science, v. 290 CCIS, pp. 13-35.
Unterkalmsteiner, M., Gorschek, T., Moinul, A., Kian Cheng, C., Bayu, R., Feldt, R.
(2012), Evaluation and Measurement of Software Process Improvement-A Systemat-
ic Literature Review. IEEE Transactions on Software Engineering 38(2), 398–424
(2012).
Virtanen, Pasi, Samuli Pekkola, and Tero Päivärinta. (2013), "Why SPI initiative failed:
contextual factors and changing software development environment."System Scienc-
es (HICSS), 2013 46th Hawaii International Conference On. IEEE, 2013.
Zhao, Y., Liu, Y. (2008), “Organizational change: A case study on Anhui Telecom
Company”. 2008 International Seminar on Business and Information Management.
Wincek, J., Sousa, L. S., Myers, M. R., Ozogc, H. (2014), “Organizational Change
Management for Process Safety”, In: Wiley Online Library (wileyonlinelibrary.com).
DOI 10.1002/prs.11688.
148
Catálogo de Benefícios Relatados por Organizações que
Implementaram Melhoria de Processos de Software
Diego Cruz e Gleison Santos
Programa de Pós-Graduação em Informática - Universidade Federal do Estado do Rio de

Janeiro (UNIRIO) - Av. Pasteur, 458, Urca, CEP 22290-240 - Rio de Janeiro, RJ
{diego.dacruz, gleison.santos}@uniriotec.br
Abstract. Awareness of software process improvement (SPI) benefits may motivate
organisations to decide to adopt and maintain practices in maturity models such as MR-
MPS-SW and CMMI-Dev. We performed a systematic data collection and analysis to
identify and catalog informations about SPI benefits obtained in the state of practice. We
conducted a systematic mapping review and an expert panel that were analyzed by means
of a thematic analysis with Grounded Theory procedures. After analyzing 57 experience
reports and 4 experts interviews, we identified 121 benefit sheets that were organized in a
SPI benefit catalog. The experts evaluation generated evidences that the sheets’ structure
is proper and relevant to the organisational context. We also found that its content can
positively influence motivation of team affected by the SPI initiative besides the high
management.
Resumo. A percepção dos benefícios gerados por implementação de melhoria de
processos de software (SPI) é um fator motivacional para que organizações decidam
adotar e manter práticas propostas em modelos de maturidade como MR-MPS-SW e
CMMI-Dev. Com objetivo de contribuir para maior evidência dos possíveis benefícios da
adoção de práticas propostas por modelos e normas internacionais de SPI, esta pesquisa
englobou uma abordagem sistemática de coleta e análise de dados para identificar e
catalogar informações sobre benefícios de SPI obtidos no estado da prática. O método
contempla execução de um mapeamento sistemático da literatura e Expert Panel cujos
resultados foram analisados utilizando procedimentos de análise temática com
codificação baseada em Grounded Theory (GT). A análise dos 57 relatos de experiência
de implementação de SPI selecionados e das 4 entrevistas com especialistas em SPI
resultaram na identificação de 121 fichas de benefícios de SPI que foram organizadas
em um catálogo de benefícios. A avaliação por especialistas mostrou indícios de que a
estrutura é adequada e relevante ao contexto de SPI e de que o conteúdo poderia
influenciar positivamente na motivação de equipe envolvida na SPI e da alta gestão.
1. Introdução
O sucesso das organizações desenvolvedoras de software cada vez mais depende da
qualidade final dos seus produtos em equilíbrio com o cumprimento dos prazos, custos e
escopo estabelecidos, assim como, a minimização das incertezas e maximização das
oportunidades que cercam um projeto, tudo isso em um menor tempo possível de
desenvolvimento [Neto et al. 2013]. Para guiar as organizações no aumento da
maturidade organizacional, bem como o aumento da sua capacidade de desenvolver
softwares, foram criados padrões internacionais como a ISO/IEC 12207 [ISO/IEC 2008],
149
ISO/IEC 15504 [ISO/IEC 2003] e modelos de qualidade de processo de software como o
CMMI-DEV (Capability Maturity Model Integration for Development) [CMMI Product
Team 2010] e o MR-MPS-SW (Modelo de Referência MPS para Melhoria de Processos
de Software) [SOFTEX 2016]. A adoção de práticas propostas por modelos e normas
internacionais de melhoria de processos de software (SPI, do inglês Software Process
Improvement) é um processo social cujos fatores de sucesso são amplamente discutidos
na literatura. Problemas como a falta de apoio e comprometimento alta direção com as
práticas de melhoria, bem como dos colaboradores à execução de atividades propostas
pelos modelos pode gerar o fracasso ou descontinuação das iniciativas em organizações.
Nesse contexto, autores como Montoni e Rocha (2011) acreditam que a visualização dos
possíveis benefícios de SPI pelos colaboradores pode contribuir para redução da
resistência a mudanças durante a introdução de práticas propostas por modelos e normas
internacionais de SPI. Coleman e O’Connor (2008) e Travassos e Kalinowski (2009)
acreditam que evidenciar os possíveis benefícios da SPI promove o apoio da alta gestão,
garantindo a manutenção das atividades de melhoria de processos na organização.
Este trabalho tem por objetivo contribuir para a maior visibilidade sobre os
possíveis benefícios de melhoria de processos de software por meio da elaboração de um
catálogo com benefícios relatados por organizações que implementaram melhoria de
processos de software baseada em modelos de maturidade, como o MR-MPS-SW
[SOFTEX 2016] e o CMMI-DEV [CMMI Product Team 2010] e em normas
internacionais, como a ISO/IEC 15504 [ISO/IEC 2003]. A metodologia de pesquisa
inclui a coleta, análise de dados e avaliação de artefatos baseada nas diretrizes da Design
Science Research [Dresh et al. 2015]. A próxima seção apresenta uma revisão da
literatura, a seção 3 apresenta o planejamento, execução e principais resultados do estudo,
suas limitações e ameaças à validade e na seção 4 é apresentada a conclusão.
2. Benefícios de Melhoria de Processos de Software

A aplicação de boas práticas de Engenharia de Software pode melhorar o desempenho
das organizações com respeito a custo, prazo, produtividade, qualidade, satisfação do
cliente e retorno do investimento e, consequentemente, aumentar sua vantagem
competitiva [Santos 2011]. A melhoria de processos de software (SPI) tem como objetivo
compreender o processo de software, como ele é usado dentro de uma organização e,
assim, conduzir a implementação de mudanças para que esse processo alcance metas
específicas, tais como obter maior qualidade dos produtos ou reduzir custos [Coleman et
al. 2008]. Assim, organizações têm adotado normas e modelos de melhoria de processo
como referência para obter a melhoria desejada em seus programas e projetos, visando
alcançar maior maturidade no desenvolvimento de software e melhor desempenho no
negócio [Cerdeiral 2008].
Dentre as normas e modelos de qualidade mais comuns estão as normas ISO/IEC
12207 [ISO/IEC 2008], ISO/IEC 15504 [ISO/IEC 2003] e os modelos de maturidade
CMMI-DEV [CMMI Product Team 2010] e o MR-MPS-SW [SOFTEX 2016].
Decisões por adotar novas práticas para melhoria de processos organizacionais
devem estar alinhadas aos objetivos de negócio, assim, é fundamental que setores
estratégicos e tomadores de decisão estimem o Retorno sobre Investimento (do inglês
150
Return On Investment ou ROI), que consiste na razão entre a representação financeira dos
benefícios e a representação financeira do custo. Na SPI, é importante que os benefícios
não só excedam os custos, mas os ultrapassem suficientemente para justificar as
dificuldades associadas à adoção das práticas [Rico, 2002], pois as iniciativas de melhoria
necessitam de um investimento significante e com benefícios muitas vezes invisíveis, o
que pode levar uma relação custo-benefício fora do esperado pelas organizações
[Solingen 2004]. Para analisar o impacto das iniciativas de SPI, organizações
frequentemente utilizam a estratégia de comparação pré-pós, ou seja, analisar o contexto
antes e depois da implementação da SPI para verificar se os objetivos de melhoria foram
alcançados [Unterkalmsteiner et al. 2012]. Nesse contexto, é essencial que organizações
tenham ciência dos possíveis ganhos proporcionados pela SPI para definirem de objetivos
iniciais de implementação realistas e evitar frustrações levariam ao abandono das práticas
de melhoria.
Em uma abordagem que sugere a comparação pré-pós, Ramos et al. (2013)
definiram uma estratégia para análise do Retorno sobre o Investimento com base na
expectativa da organização. A estratégia consiste em identificar benefícios esperados pela
organização com base nos objetivos de negócio e identificar as medidas necessárias para
avaliar o alcance dos objetivos após a institucionalização do processo. Mcloughlin (2010)
também define uma estratégia para implementação de SPI orientada a objetivos,
denominada Rosetta Stone Metodology, baseada no paradigma Goal-Question-Metric
(GQM) [Basili 1994]. Em sua pesquisa, o autor realiza um mapeamento entre as áreas de
processos do CMMI e uma árvore de benefícios definida por Goyal et al. [2001 apud
Mcloughlin 2010] para permitir que se identifique as áreas de processos do CMMI a
serem implementadas com base nos objetivos organizacionais. A partir dos trabalhos de
Ramos et al. (2013) e Mcloughlin (2010) foi identificada uma lista considerável de
benefícios e medidas que serviram para apoiar suas abordagens e facilitar organizações
na definição de metas iniciais de implementação. Apesar disso, a árvore de benefícios
usada por Mcloughlin (2010) não é específica de SPI e não há detalhes que propiciem o
entendimento mais significativo dos benefícios. Não é possível saber, por exemplo, “que
fatores podem influenciar na produtividade?”, “em que contexto de SPI o aumento da
produtividade foi relatado?” ou “que outros benefícios são gerados pelo aumento da
produtividade?”.
Todavia, considera-se que a exploração e coleta de detalhes como os referentes a
essas questões possam auxiliar a compreensão e reconhecimento dos benefícios da SPI
por profissionais e gestores de organizações inexperientes em SPI e de organizações
engajadas em iniciativas de melhoria de processos de software. Nesse sentido, as
próximas seções apresentam as etapas que levaram à identificação de benefícios
associados a iniciativas de SPI baseadas em modelos de maturidade e normas
internacionais.
3. Planejamento e execução do Estudo

A Design Science Research (DSR) é um método que fundamenta e operacionaliza a
condução de pesquisas quando o objetivo a ser alcançado é um artefato ou uma
prescrição. O planejamento desse estudo baseou-se em [Dresh et al.2015] que define duas
151
etapas principais para pesquisas em DSR: (i) Projeto e desenvolvimento do artefato e (ii)
Avaliação do artefato. A etapa de projeto e desenvolvimento do artefato desse estudo
compreende a coleta de dados por meio de mapeamento sistemático da literatura (MSL) e
análise qualitativa utilizando procedimentos de Grounded Theory (GT), seguido de
auditoria dos procedimentos de codificação e definição da estruturação do catálogo. Para
a etapa de avaliação do artefato, planejou-se um painel de especialistas para operar tanto
como meio de avaliação do catálogo, como também uma fonte secundária para coleta de
dados relativos ao objeto de pesquisa (benefícios). A Figura 1 apresenta os elementos
envolvidos na criação do artefato proposto nesse estudo, enquanto a Tabela 1 apresenta as
atividades envolvidas.
Figura 1 - Modelo de pesquisa em Design Science Research
Tabela 1 - Atividades da metodologia de pesquisa baseada em Design Science Research

Projeto e desenvolvimento do artefato
Mapeamento Sistemático da Análise qualitativa Auditoria por pares Definição do artefato
Literatura (MSL) Análise temática das Auditores revisam os códigos A estrutura do catálogo é
Seleção de publicações no publicações selecionadas no gerados durante o definida e as informações são
escopo de pesquisa MSL, utilizando procedimento de codificação organizadas em um layout
procedimentos de GT estabelecido
Avaliação do artefato
Painel de especialistas Análise qualitativa Auditoria dos novos Atualização do catálogo
Entrevistas com especialistas Análise temática das achados Os novos achados são
para avaliar a forma e entrevistas utilizando Os novos achados são mesclados aos obtidos no
conteúdo do catálogo de procedimentos de GT auditados por um auditor MSL
benefícios experiente em SPI
3.1 Protocolo de Mapeamento Sistemático

O protocolo do mapeamento sistemático da literatura foi desenvolvido com base nas
152
diretrizes propostas por Petersen et al. (2015) que delimitam quatro etapas essenciais a
serem seguidas: (i) definição de questões de pesquisa ou escopo do mapeamento; (ii)
realização da pesquisa de estudos primários relevantes; (iii) extração de dados; e (iv)
análise de síntese dos dados.
O MSL proposto nesse estudo visa identificar estudos primários caracterizados
como relatos de experiência de implementação de modelo ou norma de melhoria de
processos de software e que relatem benefícios obtidos pela adoção de práticas de SPI no
contexto da indústria de software nacional e internacional, com objetivo de identificar
benefícios de SPI e informações sobre fatores que influenciam positivamente na
ocorrência, fatores que influenciam negativamente na ocorrência, contexto de melhoria
de processos em que foram relatados, a relação com outros benefícios e as medidas ou
técnicas utilizadas para acompanhamento de ocorrência. O protocolo de MSL completo
encontra-se disponível em [Cruz, 2016].
Questões de pesquisa: foi formulada a seguinte questão principal de pesquisa: QP 1.

Quais benefícios são relatados por organizações que implementaram melhoria de
processos de software? Foram também formuladas as seguintes questões secundárias:
QS 1. Quais fatores exercem influência positiva na obtenção dos benefícios relatados?;
QS 2. Que métodos a organização utiliza para constatar a ocorrência dos benefícios
relatados?; QS 3. Em que contexto de melhoria de processos de software os benefícios
ocorrem?; QS 4. Em que publicações os benefícios foram relatados?; QS 5. Qual relação
entre os benefícios relatados?
Escopo de pesquisa: A pesquisa se deu a partir de consulta estruturada nas bibliotecas
digitais da Scopus e Compendex, pela robustez e abrangência de indexação (que
considera boa parte também das publicações da ACM Digital Library e IEEE Xplore)
[Ribeiro e Travassos 2016], e a partir de consultas manuais nos anais do Workshop Anual
de Melhoria de Processos de Software (WAMPS) e do Simpósio Brasileiro de Qualidade
de Software (SBQS), por serem os maiores eventos específicos em Qualidade de
Software no Brasil, com grande volume de publicações relacionadas a SPI.
Para a Scopus não houve restrições de data. Para a Compendex, o estudo

englobou o período compreendido entre 1989 (ano de lançamento do CMM) e 2016.
Nestas duas fontes, foi utilizada uma expressão de busca. Todos os anais do SBQS entre
2002 e 2015 e do WAMPS entre 2005 e 2015 foram considerados. Foram aceitos
trabalhos em inglês e português. Para estes dois eventos foi feito uma busca manual em
todos os trabalhos.
Métodos de busca de publicações: As etapas do mapeamento sistemático incluíram: (i)
Seleção e catalogação preliminar das publicações; (ii) Leitura dos títulos e abstracts com
aplicação dos critérios de inclusão e exclusão para identificar publicações em potencial
para a pesquisa. Em caso de dúvida, a publicação foi incluída no escopo para leitura
completa; (iii) Aplicação de critérios de inclusão e exclusão com base na leitura completa
das publicações selecionadas na etapa de leitura dos títulos e abstracts; (iv) Análise
qualitativa sobre publicações incluídas no escopo de pesquisa utilizando conceitos de
Grounded Theory; e (v) Auditoria dos procedimentos de codificação.
153
Considerou-se os seguintes critérios de inclusão (CI) e exclusão (CE): CI1 -
Publicações que relatem uma ou mais experiências de implementação de melhoria de
processos de software, caracterizando relatos de experiência; CI2 - Artigos que relatem
benefícios da implementação de SPI (* apenas durante leitura completa); CE1 - O artigo
não está relacionado ao contexto de Engenharia de Software; CE2 - O artigo está escrito
em idioma diferente do inglês e portuguêsCE3 - Não foi possível ter acesso ao trabalho
completo; CE4 - É uma apresentação de conferência.
Definição de expressões de busca: A elaboração da expressão de busca partiu da
composição: (benefit or benefits) AND (SPI OR ‘software process improvement’) com o
objetivo de identificar novas palavras-chave. Com base nas publicações que retornaram
na primeira execução, foram identificadas palavras frequentemente citadas em títulos e
resumos de publicações caracterizadas como relatos de experiência. Assim, a segunda
versão da expressão de busca compreendeu os termos: ("software process improvement"
OR spi OR cmmi OR cmm OR "maturity level" OR "mps.br") AND (benefit OR tangible
OR intangible OR objective OR goal OR "success factors" OR csf OR motivator OR
motivation OR lesson OR "experience report" OR roi OR investment). Esta expressão foi
executada no engenho de busca Scopus e, após análise dos resultados foi revista e
identificaram-se termos que ampliavam consideravelmente o número de falso-positivos.
As palavras-chave removidas da expressão foram: objective, csf, motivator e motivation.
A decisão por remoção destes termos foi baseada nos artigos já selecionados e em
execuções-teste para avaliar a possível perda, onde concluiu-se que não haveria perda
significativa na execução da expressão atualizada na base da Compendex.
Resultados da execução do protocolo: Foram identificados 57 relatos de experiência. A
Tabela 2 sumariza a seleção de publicações nos engenhos de busca e anais analisados.
Tabela 2- Seleção de publicações nos engenhos de busca automatizada e anais de eventos
Fontes
Totais SCOPUS COMPENDEX SBQS WAMPS
Total de artigos analisados 1033 347 388 217
Artigos no escopo 22 4 11 20
Total de artigos no escopo 57
Os relatos de implementação de SPI que entraram no escopo de pesquisa são de

organizações de diversos países, principalmente no Brasil e Estados Unidos. Das
organizações estudadas, 35 são brasileiras ou multinacionais que implementaram SPI na
sede localizada no Brasil, 8 organizações dos Estados Unidos, 2 da Irlanda e 1 de cada
um dos seguintes países: Canadá, Argentina, Turquia, Áustria, Índia, Alemanha e China.
Uma organização implementou em duas sedes, sendo uma na Alemanha e outra na
Holanda. Em 4 publicações não foi possível identificar o país da iniciativa.
3.2 Análise Qualitativa dos Benefícios de Melhoria de Processos de Software

Para responder às questões de pesquisa, uma análise temática foi realizada utilizando
conceitos de codificação aberta (open coding) e codificação axial (axial coding) da
Grounded Theory (GT) ou Teoria fundamentada nos dados [Strauss e Corbin, 2008]. As
análises foram realizadas com apoio da ferramenta ATLAS.ti, que é específica para
154
análise qualitativa desta natureza (disponível em http://www.atlasti.com).
Na pré-análise de relatos de experiência foi realizada a atividade da análise
temática conhecida como “leitura flutuante” [Bardin 1977] que objetivou gerar
impressões iniciais acerca do material a ser analisado e onde foi possível identificar as
principais categorias e subcategorias que poderiam ser exploradas no estudo. No decorrer
da análise, as categorias foram tornando-se mais evidentes até que foi possível definir o
modelo de análise apresentado na Figura 2 que representa o esquema teórico utilizado
para codificação e define relacionamentos entre as classes de dados identificadas nesse
estudo. A classe central da Figura 2 (Benefícios de Melhoria de Processos de Software) é
referente à questão principal de pesquisa, enquanto seus atributos e atributos aninhados
(subatributos) fazem referência às questões de pesquisa secundárias. Já as duas classes
superiores (Categoria de Benefícios de Melhoria de Processos de Software e Grupo de
Benefícios de Melhoria de processos de software) correspondem a agrupamentos
realizados durante as etapas de codificação axial.
Figura 2: Modelo para análise dos benefícios de melhoria de processos de software
Benefícios com definições similares foram associados a uma descrição mais

abstrata que na Figura 2 é representada pela classe Grupo de Benefícios de Melhoria de
Processos de Software. O grafo da Figura 3 exemplifica a formação de um Grupo de
Benefícios de Melhoria de processos de software. Os números entre chaves no fim dos
nomes dos nós representam respectivamente o grau (quantidade de trechos de artigo que
estão associados ao nó) e a densidade (quantidade de elementos ligados ao nó). Nesse
contexto, o Grupo {BEN002} é uma representação abstrata dos benefícios [BEN059],
[BEN174] e [BEN023] de modo que um conjunto de benefícios é definido em um único
código, denominado grupo de benefícios, que, portanto, herda todos os relacionamentos
dos benefícios que o compõem, como medidas e fatores de influência positiva e negativa.
Finalizada a primeira etapa de codificação, foram identificados 169 Benefícios de

SPI, 119 Fatores de influência positiva, 3 fatores de influência negativa, 35 Medidas para
acompanhamento, 17 Fórmulas, 13 Técnicas para acompanhamento, 57 Referências
bibliográficas e 29 contextos de ocorrência. Na segunda fase, benefícios semelhantes
foram agrupados reduzindo de 169 para 121 benefícios que, por fim, foram distribuídos
155
em 12 categorias de benefício.
Figura 3 - Exemplo de agrupamento de benefícios
A Tabela 3 apresenta as 12 categorias de benefícios criadas durante a análise

qualitativa, a quantidade de benefícios e/ou grupos de benefícios existentes em cada
categoria e exemplos de benefícios e/ou grupos de benefício contidos nas categorias.
Tabela 3 - Categorias de benefícios identificadas na codificação axial
Benefí-
Categoria de benefícios Exemplos de benefícios/grupos de benefícios
cios
CAT001 - Benefícios relacionados Aumento da receita/lucro, Aumento do faturamento, Maior
a Ganhos Financeiros e redução de 6 visibilidade dos lucros, Redução de custos dos projetos e
custo operacional Retorno do investimento (Ganhos Financeiros).
CAT002 - Benefícios Relacionados Melhor comunicação entre colaboradores e equipes/projetos,
à Melhoria da Comunicação e Melhor definição dos canais de comunicação e Melhor
5
Relacionamento na Organização comunicação entre o departamento de desenvolvimento, a alta
direção e representantes das organizações clientes.
CAT003 - Benefícios Relacionados Aumento da satisfação dos colaboradores, Redução na
11
ao Ambiente de Trabalho sobrecarga de trabalho e Aumento da moral dos colaboradores.
CAT004 - Benefícios Relacionados Maior comprometimento de envolvidos no projetos e Maior
à Mudança Cultural na 11 atenção da equipe de projetos com a qualidade dos
Organização produtos de trabalho
CAT005 - Benefícios Relacionados Maior participação/envolvimento dos clientes nos projetos,
à Qualidade de Relacionamento 7 Mais liberdade para os clientes solicitarem mudanças e
com o Cliente Redução de problemas com clientes.
CAT006 - Benefícios Relacionados Maior precisão na elaboração de estimativas, Maior
ao Planejamento de Projetos 7 previsibilidade da qualidade do produto e Maior capacidade de
negociação de mudanças com os clientes.
CAT007 - Benefícios Relacionados Melhor priorização de projetos de desenvolvimento de
à Qualidade de Gerenciamento de 11 software, Maior controle sobre os projetos e Melhor
Projetos visibilidade da distribuição de tarefas e evolução do produto.
CAT008 - Benefícios Relacionados Redução do tempo necessário para realização de tarefas,
à Qualidade de Execução de 29 Redução de retrabalho, Identificação de erros nas fases iniciais
Projetos do projeto e Aumento da produtividade.
CAT009 - Benefícios Relacionados Aumento da satisfação da alta gerência, Melhoria do time-to-
13
à Organização e Alta Direção market e Maior e melhor continuidade dos serviços.
CAT010 - Benefícios Relacionados Aumento da qualidade do produto / Redução da
à Qualidade dos Produtos de 4 densidade de defeitos, Maior padronização dos processos e
Trabalho produtos de trabalho e Melhoria da qualidade dos requisitos.
CAT011 - Benefícios Relacionados Maior número de profissionais interessados em trabalhar para
à Atração, Retenção e Capacitação 7 a organização, Redução da rotatividade de profissionais e
de Profissionais de Software Maior facilidade para treinamento de colaboradores.
CAT012 - Benefícios Relacionados Institucionalização dos processos de software e Geração de
ao Programa de Melhoria de 10 informações sobre os resultados da melhoria de processos de
Processos de Software software que auxiliam gerentes na tomada de decisão
156
Com relação à questão de pesquisa principal QP1 “Quais benefícios são relatados
por organizações que implementaram melhoria de processos de software?”, 169
benefícios foram identificados, dos quais os mais citados em publicações distintas são
apresentados na Tabela 4.
Tabela 4 - Benefícios mais citados
Nome do Benefício Citações
BEN028 - Aumento da qualidade do produto 20
BEN004 - Melhor estimativa de prazo 17
BEN031 - Aumento da produtividade 17
BEN025 - Redução da taxa de defeitos 16
BEN029 - Aumento da satisfação do cliente 12
BEN003 - Redução de retrabalho 11
BEN023 - Redução dos custos de desenvolvimento 9
BEN030 - Identificação de erros nas fases iniciais do projeto 7
BEN065 - Aumento da satisfação dos colaboradores 7
BEN145 - Redução do número de defeitos encontrados durante a avaliação do cliente 7
Com relação à questão secundária QS1 “Quais fatores exercem influência positiva
na obtenção dos benefícios relatados?”, foram identificados 119 fatores de influência
positiva, ou seja, fatores que podem facilitar a ocorrência dos benefícios aos quais estão
relacionados. O grafo da Figura 4 apresenta exemplos de fatores que influenciam
positivamente no benefício [BEN004] - “Melhor estimativa de prazo”.
Figura 4 - Exemplo da codificação de fatores de influência positiva
Com relação à questão secundária QS2 - “Que métodos a organização utiliza para
constatar a ocorrência dos benefícios relatados?”, foram identificadas 35 medidas para
acompanhamento, 17 Fórmulas e 13 Técnicas para acompanhamento. As medidas mais
citadas pelos autores estão representadas no gráfico da Figura 5. Para a maior parte das
medidas identificadas não foi possível identificar a fórmula nas publicações analisadas,
entretanto, 11 das 35 medidas são diretas, ou seja, não necessitam de fórmulas, por
exemplo “Quantidade de defeitos no produto final”. Das 24 medidas que não são diretas,
15 tiveram fórmulas definidas por algum autor. Já as “técnicas para acompanhamento”
são maneiras de se identificar a ocorrência de benefícios que muitas vezes não são
mensurados numericamente e a coleta de dados é realizada a partir da percepção das
pessoas envolvidas. Nesse estudo, a única técnica que obteve mais de uma citação foi a
“[TEC001] Elaborar um questionário de satisfação”, com 5 citações.
157
Figura 5 - Medidas mais citadas
Para a questão secundária QS3 - “Em que contexto de melhoria de processos de

software os benefícios ocorrem?”, foram identificados 29 contextos de ocorrência. Os
gráficos da Figura 6 apresentam um panorama geral dos contextos de SPI identificados.
No gráfico A é indicada a quantidade benefícios associados ao modelo MR-MPS-SW, no
gráfico B é indicada a quantidade benefícios associados ao modelo CMMI-DEV, no
gráfico C é indicada a quantidade benefícios associados às normas ISO e aos modelos
Competisoft e Bootstrap, enquanto o gráfico D apresenta a quantidade benefícios
identificados em implementações múltiplas. Os gráficos apontam uma maior
concentração dos benefícios identificados nos contextos dos níveis mais baixos do
CMMI-DEV (níveis 2 e 3) e do MR-MPS-SW (níveis G, F, E e D).
Figura 6 - Quantidade de benefícios associadas a contextos de SPI
Em resposta à questão secundária QS4- “Em que publicações os benefícios foram

relatados?”, a análise resultou na associação dos benefícios às referências bibliográficas
de onde foram extraídos, permitindo rastreabilidade da origem cada benefício. O grafo da
Figura 7 apresenta a codificação das referências do benefício [BEN012], onde pode-se
observar que o mesmo foi extraído dos artigos [REF022] e [REF002].
158
Figura 7 - Exemplo de codificação de referências bibliográficas
Para a questão secundária QS5- “Qual relação entre os benefícios relatados?”, a

análise qualitativa realizada nesse estudo permitiu identificar que alguns benefícios
podem influenciar na ocorrência de outros, por exemplo, o benefício “aumento da
produtividade” pode influenciar positivamente na ocorrência do benefício “aumento do
lucro por colaborador”. Esta questão é representada no auto relacionamento apresentado
na classe de Benefícios do modelo de análise apresentado na Figura 2.
Ao fim do processo de codificação, foi realizada uma auditoria dos procedimentos
de codificação em duas etapas. Na primeira etapa, 2 auditores da área de melhoria de
processos de software que possuem publicações científicas cuja metodologia inclui
procedimentos da Grounded Theory foram selecionados e avaliaram a clareza da
descrição dos códigos gerados e a consistência entre o código e os trechos de artigos aos
quais está associado. Na segunda etapa, um auditor com larga experiência em projetos de
implementação e avaliação em modelos de melhoria de processos de software em
organizações avaliou a coerência dos relacionamentos entre os códigos obtidos. As
sugestões dos auditores nas etapas de auditoria contribuíram para a padronização e
correção de termos e fórmulas, além de garantir que os procedimentos de coleta e análise
foram executados de acordo com a metodologia de análise definida.
3.3 Estrutura do Catálogo de Benefícios

As informações sobre benefícios capturadas no mapeamento sistemático da literatura
foram organizadas em fichas de benefício para compor o catálogo que é composto por: (i)
Capa, onde são apresentados os dados de identificação do catálogo (título, autor, filiação,
versão e ano de criação); (ii) Seção introdutória, onde o leitor é resumidamente instruído
quanto ao conteúdo do catálogo e a metodologia utilizada para coleta dos dados; (iii)
Seção de estrutura das fichas, onde é apresentada detalhadamente a estrutura em que as
fichas com dados sobre os benefícios estão organizadas; (iv) Sumário, onde são indicadas
as páginas de localização das fichas contidas no catálogo; e (v) Capítulos formados pelas
categorias de benefícios.
A Figura 8 apresenta a ficha do grupo de benefícios “Aumento da receita/lucro”,
que agrupa os benefícios “Aumento do lucro por colaborador” e “Aumento do percentual
de lucro” e pode gerar “Aumento da satisfação da alta gerência”. Está na categoria
“Benefícios Relacionados a Ganhos Financeiros e Redução de Custo Operacional”. O
catálogo completo encontra-se disponível no apêndice D de [Cruz, 2016].
159
Categoria: Benefícios Relacionados a Ganhos Financeiros e Redução de Custo Operacional
Benefício: Aumento da receita/lucro

Inclui:  Aumento do lucro por colaborador
 Aumento do percentual de lucro
Benefício derivado:  Aumento da satisfação da alta gerência
Medidas para acompanhamento do aumento da receita/lucro:

 Lucro por colaborador
 Taxa de variação do lucro anual
Fatores que influenciaram positivamente no aumento da receita/lucro:

 Entregar mais funcionalidades por release, com menos defeitos
 Redução de retrabalho
 Redução do tempo de teste do sistema
Contextos de melhoria de processos de software em que o aumento da receita/lucro foi identificado:

 CMMI-DEV nível 3
 CMMI-DEV nível 5
 CMMI-DEV com Personal Software Process (PSP)
 ISO 9001 com MR-MPS-SW nível F e CMMI-DEV nível 3
Representação gráfica do aumento da receita/lucro:
Publicações que relataram aumento da receita/lucro após a implementação de melhoria de processos:

 Falessi, D., et al. (2014). "Achieving and maintaining CMMI maturity level 5 in a small organization."
IEEE Software 31(5): 80-86.
 Ferreira, A. I. F., et al. (2008). "ROI of software process improvement at BL informática: SPI is really
worth it." Software Process Improvement and Practice 13(4): 311-318.
 Laporte, C. Y., et al. (2007). Improvement of software engineering performances an experience
report at bombardier transportation - total transit systems signalling group. 17th Annual
International Symposium of the International Council on Systems Engineering, INCOSE 2007 -
Systems Engineering: Key to Intelligent Enterprises.
 Seshagiri, G. (2012). "High maturity pays off it is hard to believe unless you do it." CrossTalk 25(1).
Figura 8 – Exemplo de ficha de benefício
160
3.4. Avaliação do artefato
Para avaliação do artefato produzido nesta pesquisa, as técnicas Grupo Focal [Caplan
1990] e Painel de Especialistas [Pinheiro et al. 2013] foram selecionadas como as mais
apropriadas. A desvantagem Grupo Focal em relação ao Painel de Especialistas é
necessidade de disponibilidade dos participantes em um mesmo dia e horário, envolvendo
questões de deslocamento e disponibilidade de espaço físico. Outra razão que conduziu à
seleção da técnica de Painel de Especialistas como mais adequada foi modelo de
entrevista individualizado e estruturado, com a possibilidade de mesclar o uso de
questionários com discussões. No Grupo Focal, os participantes são deixados livres para
discutirem sobre um assunto de interesse da pesquisa sem a condução direta do
pesquisador, o que representaria um alto risco para o estudo.
O painel de especialistas atuou tanto como uma técnica para avaliação do catálogo,
como uma fonte de novos conceitos e relacionamentos, ressaltando também a característica
exploratória desta etapa do estudo. Foram selecionados 4 especialistas em SPI,
implementadores e/ou avaliadores em modelos de maturidade, como MR-MPS-SW e
CMMI-Dev, com pelo menos 10 anos de experiência em participação em projetos de
implementação de SPI, que avaliaram a estrutura e conteúdo do catálogo obtido nesse
estudo por meio de um questionário e discussões. Como resultado, foi possível perceber
indícios de que as seções contidas nas fichas de benefício são adequadas e relevantes ao
contexto organizacional. Todos os especialistas entrevistados concordam que as
informações contidas no catálogo podem auxiliar organizações a definirem seus objetivos
iniciais de implementação, auxiliar na venda da melhoria de processos de software nas
organizações (convencimento da alta gerência em investir em SPI) e ser utilizadas por um
gerente para motivar sua equipe a executar práticas de SPI. Por fim, as entrevistas
permitiram identificar novos relacionamentos entre os benefícios e pontos de melhoria
em descrições de categorias de benefícios e de nomes de benefícios. Foram identificados
37 novos relacionamentos, avaliados por um profissional experiente em SPI com o
propósito de mitigar indícios de interpretação inadequada por parte do pesquisador.
Como não houve ocorrências de má interpretação, os novos relacionamentos foram
incluídos no catálogo.
3.5 Limitações e Ameaças à validade

Algumas limitações e ameaças podem ser identificadas nesse estudo. Dentre as
limitações, destaca-se o fato de nem todas as fichas de benefícios serem completas. Isso
porque, em alguns relatos não foram mencionadas medidas, fórmulas, técnicas ou fatores
de influência. Dentre as ameaças à validade identificadas, destacam-se:
Ameaça à validade interna: São eventos não controlados que podem produzir
distorções no resultado esperado. Estudos relevantes que usam termos diferentes dos
previstos na expressão de busca ou que ainda não haviam sido indexados aos engenhos
podem não ter sido selecionados. Apesar da imparcialidade do pesquisador nas
entrevistas, não é possível saber se de alguma forma sua presença influenciou nas
respostas fornecidas pelos participantes.
Ameaça à validade externa: As ameaças deste tipo prejudicam a generalização dos
161
resultados do estudo. A limitação de fontes de dados a relatos de experiência e entrevistas
com especialistas limita também a abrangência dos resultados. É possível que novos
achados possam ser evidenciados a partir da realização de novas análises e exploração de
novas fontes de dados.
Ameaça à validade do constructo: São eventos que podem prejudicar a medição correta
no estudo. O questionário utilizado no painel de especialistas poderia gerar desvio de
interpretações, por isso, foi realizada uma rodada piloto para ajustar questões, simplificar
e direcionar as respostas. Em alguns momentos é possível que as opções de resposta não
tivessem a intensidade da opinião do entrevistado. Além disso, é possível que o valor
percebido com relação às opções de resposta varie de acordo com os critérios pessoais de
cada participante.
Ameaça à validade de conclusão: Estas ameaças prejudicam o estabelecimento de
relacionamentos estatísticos. Neste estudo não foram realizados estudos experimentais,
nem testes estatísticos, assim, os resultados não poderão ser considerados conclusivos.
4. Conclusão
Este trabalho identificou benefícios reportados por organizações que implementaram SPI
baseada em modelos e normas internacionais. Muitas vezes, na decisão por investir em
SPI, benefícios são definidos como objetivos iniciais de implementação para que no
futuro seja possível avaliar o retorno obtido. Assim, informações sobre experiências
obtidas por outras organizações possibilitam que investidores de organizações
inexperientes na melhoria de processos de software reflitam com melhor percepção sobre
aquilo que se adquiriu ou se deseja adquirir em termos de melhoria de processos.
O estudo incluiu um mapeamento sistemático da literatura, onde foram
identificados 57 relatos de experiência de implementação de SPI em que autores
relataram benefícios resultantes da adoção de práticas propostas por modelos e normas de
SPI. A análise temática realizada sobre esses estudos resultou na catalogação de 121
fichas de benefício com fatores de influência positiva, medidas para acompanhamento,
fórmulas de medidas, técnicas para acompanhamento, referências bibliográficas e
contextos de ocorrência e cujo índice de completude varia de acordo com a
disponibilidade das informações nas fontes analisadas.
Por fim, a estrutura e conteúdo do catálogo de benefícios foram avaliados por
especialistas em SPI. Os resultados da avaliação indicaram que as fichas de benefício
podem auxiliar organizações a definirem seus objetivos iniciais de implementação e
influenciar na motivação, tanto de gestores em decidir por implementar SPI, quanto de
colaboradores em executar práticas de melhoria. Também foram obtidos indícios de que
os tipos de informação apresentados nas fichas de benefício são adequados e relevantes
ao contexto organizacional. Entretanto, novos estudos serão realizados junto à indústria
em vista de confirmar os indícios obtidos nesse trabalho.
Agradecimentos
Os autores agradecem à FAPERJ (projetos E-26/210.643/2016, E-211.174/2016) e à
UNIRIO (Edital PQ-UNIRIO no. 01/2016 e 01/2017) pelo apoio financeiro.
162
Referências
Bardin, L. (1977). Análise de conteúdo. Lisboa: Editora Edições 70.
Caplan, S. (1990). “Using focus group methodology for ergonomic design”. Ergonomics, v. 33,
n.5, p. 527-33.
Cerdeiral, C.T (2008). Uma Abordagem para Gerência e Avaliação de Projetos de Melhoria de
Processos de Software do Ponto de Vista da Instituição de Consultoria. Dissertação de M. Sc.,
COPPE/UFRJ, Rio de Janeiro, Brasil.
CMMI Product Team (2010). CMMI for Development (CMMI-DEV) Version 1.3. Software
Engineering Institute. Technical Report CMU/SEI-2010-TR-033. Pittsburgh, PA: Software
Engineering Institute, Carnegie Mellon University.
Cruz, D. (2016). “Catálogo de Benefícios Relatados por Organizações que Implementaram
Melhoria de Processos de Software.”, Dissertação de M. Sc. UNIRIO, Rio de Janeiro, Brasil.
Coleman, G., O’Connor, R. (2008). “Investigating software process in practice: A grounded
theory perspective”, Journal of Systems and Software, v.81, 5, pp.772-784.
Dresh, A., Lacerda, D.P. E Júnior, J.A.V.A (2015). Design Science Research: Método de
Pesquisa para Avanço da Ciência e Tecnologia. Bookman.
ISO/IEC (2003). “ISO/IEC 15504: IT Process Assessment.” The International Organization for
the Standardization and the International Electrotechnical Commission.
ISO/IEC (2008). ISO/IEC 12207: System and software engineering – Software life cycle
processes”, The International Organization for the Standardization and the International
Electrotechnical Commission.
Mcloughlin, F., e Richardson, I. (2010). “The Rosetta Stone methodology–a benefits driven
approach to SPI”, In Systems, Software and Services Process Improvement, pp. 201-212,
Springer Berlin Heidelberg.
Montoni, M.A. e Rocha, A.R.C. (2011). “Uma Investigação sobre os Fatores Críticos de Sucesso
em Iniciativas de Melhoria de Processos de Software”. Simpósio Brasileiro de Qualidade de
Software (SBQS), Curitiba, PR, Brasil.
Neto, J.B.M, Cardoso, M.P., Bezerra, S. (2013). “RisAgi: Uma Metodologia Ágil para Gestão de
Riscos em Projetos de Desenvolvimento de Software”, Workshop Anual de Melhoria de
Processos de Software e Serviços, Campinas, SP.
Petrersen, K. et al. (2008). “Systematic mapping studies in software engineering”, International
conference on Evaluation and Assessment in Software Engineering, p. 68–77, Bari, Italy.
Pinheiro J. Q., Farias T. M., Abe-Lima J. Y. (2013). “Painel de especialistas e estratégia
multimétodos: reflexões, exemplos, perspectivas”, Psico, v. 44, Porto Alegre.
Ramos, C. S., Rocha A. R. E Oliveira, K. M. (2013). “Towards a strategy for analysing benefits
of Software Process Improvement”, SEKE, 2013.
Rico D., 2002, Software “Process Improvement (SPI): Modeling Return on Investment (ROI)”.
Em http://davidfrico.com/dacs02.pdf. Consulta realizada 15/05/2017.
Santos, G. (2011). Influência e Impacto do Programa MPS.BR na Pesquisa Relacionada à
Qualidade de Software no Brasil, Simpósio Brasileiro de Qualidade de Software, Curitiba/PR.
SOFTEX (2016), “Melhoria do Processo de Software Brasileiro – Guia Geral MPS de Software”,
Consulta realizada 15/05/2017.
Solingen, R. V. (2004). "Measuring the ROI of software process improvement.". IEEE Software.
V. 21, n.3, pp. 32-38.
Strauss, A., Corbin, J. (2008). Pesquisa Qualitativa – Técnicas e Procedimentos para o
desenvolvimento de teoria fundamentada. 2a. Ed., Porto Alegre: Artmed e Bookman.
Travassos, G.H. e Kalinowski, M. (2009). “iMPS 2009: caracterização e variação de desempenho
de organizações que adotaram o modelo MPS”, SOFTEX, Campinas SP
Unterkalmsteiner, M. et al. (2012). “Evaluation and Measurement of Software Process
Improvement-A Systematic Literature Review, Software Engineering”, IEEE, v38, pp398-424
163
Dinâmica das práticas da liderança em iniciativa de
melhoria de processos de software
Alessandra Zoucas1, Cristiano Cunha1, Marcello Thiry2

1
Universidade Federal de Santa Catarina (UFSC)
Programa de Pós-Graduação em Engenharia e Gestão do Conhecimento (EGC)
Laboratório de Liderança & Gestão Responsável (LGR)
Florianópolis – SC – Brasil
Universidade do Vale do Itajaí (UNIVALI) – Campus São José

2
Ciência da Computação - Rodovia SC 407, km 04, São José – SC - Brasil.
{alessandrazoucas, 01cunha, marcello.thiry}@gmail.com

Abstract. Studies on critical success factors in initiatives to improve software
processes reinforce that factors related to leadership are determinant for their
success. Thus, the present research aimed to understand how leadership
practices occurred in an initiative to improve software processes. For this, a
qualitative study was carried out in a software process improvement initiative
that was successfully completed in the official MPS-SW evaluation at the G
level of maturity in 2015. Data were collected in in-depth semi-structured
interviews, in addition to Of the documentation provided by the company
involved in the study. The thematic analysis was applied as a method of
investigation of leadership practices in the case studied. We found different
types of leadership practice that occurred in the case studied. This paper also
shows how leadership practices are entangled in the daily work of the
organizational unit during the software process improvement initiative.
Resumo. Estudos sobre fatores críticos de sucesso em iniciativas de melhoria

de processos de software reforçam que fatores ligados à liderança são
determinantes para seu sucesso. Assim, esta pesquisa teve como objetivo
compreender como as práticas da liderança ocorreram em uma iniciativa de
melhoria de processos de software. Para isso, foi realizado um estudo
qualitativo, em uma iniciativa de melhoria de processo de software concluída
e que obteve êxito em avaliação oficial MPS-SW no nível G de maturidade,
realizada em 2015. Os dados foram coletados em entrevistas semiestruturadas
em profundidade. A análise temática foi aplicada como método de
investigação das práticas da liderança no caso estudado. Foram encontrados
diferentes tipos de prática da liderança que ocorreram no caso estudado. Este
trabalho também apresenta como as práticas de liderança estão enredadas no
trabalho diário da unidade organizacional durante a iniciativa de melhoria de
processos de software.
164
1. Introdução
As Organizações de Desenvolvimento de Software (ODSs) procuram melhorar a
qualidade de seus produtos para elevar a satisfação de seus clientes, obter
reconhecimento do mercado e consequentemente alavancar o volume de negociações.
Uma iniciativa de melhoria de processos de software (MPS) é uma estratégia adotada
pelas ODSs com o propósito de aumentar a qualidade de seus produtos em decorrência
da melhoria de seus processos de desenvolvimento [Laporte; Trudel, 1998; Paulk et al.,
1993]. Deste modo, as ODSs podem alcançar a melhoria de sua imagem e
reconhecimento no mercado. Além disso, as ODSs que passaram com sucesso por
iniciativas MPS tipicamente detêm uma unidade organizacional competente nos seus
processos de desenvolvimento de software, e esta característica pode acelerar tanto suas
ações de inovação quanto de migração tecnológica, gerando mais um diferencial
competitivo significativo para elas [Weber; Macedo; Franco, 2015].
Um tema conhecido na área de qualidade de software é a importância do
comprometimento e do envolvimento da liderança para o sucesso das iniciativas MPS
[Ahire; Golhar; Waller, 1996; Black; Porter, 1996; Powell, 1995; Saraph; Benson;
Schroeder, 1989; Yusof; Aspinwall, 1999; Dybå, 2005; El Emam et al., 2001;
Goldenson; Herbsleb, 1995; Stelzer; Mellis, 1999].
Apesar de não haver consenso sobre a definição do termo liderança na literatura
especializada, a maioria dos autores a descrevem como um processo de influência
[Yukl, 1989]. Heifetz (1998) define a liderança como atividade de influência social,
exercida pelo líder, com o propósito de mobilizar indivíduos de um grupo em direção às
metas comuns. A liderança eficaz direciona o grupo para situações que estimulam os
envolvidos para aprender a se adaptar com sucesso às mudanças e desafios [Heifetz,
1998]. Portanto, no contexto das iniciativas MPS, se não houver apoio dos líderes, a
melhoria de processos de desenvolvimento de software pode não ocorrer ou não
permanecer por muito tempo na organização [Laporte; Trudel, 1998; Paulk et al., 1997].
A liderança é um tema que está diretamente relacionado com os principais
fatores críticos de sucesso (FCS) em iniciativas MPS [Zoucas; Thiry; Cunha, 2012;
Zoucas et al., 2012]. Contudo, os achados de pesquisadores na área de MPS mostram
que aspectos ligados à liderança são frequentemente negligenciados e tornam-se uma
causa de falha organizacional para os esforços investidos nestas iniciativas [Laporte;
Trudel, 1998]. Esta perspectiva corrobora o pensamento de pesquisadores que
investigaram fatores que podem influenciar no sucesso das iniciativas MPS e mostram
que embora a área de Engenharia de Software seja de natureza técnica, existem falhas de
natureza humana e social em iniciativas MPS [Montoni; Rocha, 2011; Santos, 2011].
Niazi, Wilson e Zowghi (2005), também corroboram essa perspectiva quando
argumentam que, o problema atual com as inciativas MPS não é a falta de norma ou
modelo de referência de processos, mas sim a falta de uma estratégia eficaz de
implementar com sucesso essas normas ou modelos [Niazi; Wilson; Zowghi, 2005]. Na
literatura, muita atenção tem sido dada a ''quais atividades implementar'' em iniciativas
MPS, em vez de focar em ''como implementar'' essas atividades. Identificar de apenas “o
que” implementar não é suficiente, mas que também é necessário conhecer “como”
implementar, para se obter uma implementação bem-sucedida nas iniciativas MPS
[Niazi; Wilson; Zowghi, 2005].
165
Neste trabalho, iniciativas MPS bem-sucedidas, são aquelas que foram
submetidas a uma avaliação formal de um modelo de referência de processos como, por
exemplo, o MR-MPS-SW ou o CMMI-DEV. Portanto, ao buscar compreender como
ocorre a liderança nas iniciativas MPS bem sucedidas, espera-se contribuir para
identificar estratégias eficazes de implementar com normas ou modelos de referência de
processos e assim aumentar a adesão das empresas à MPS e elevar o seu nível de
maturidade.
O objetivo desta pesquisa foi compreender como as práticas da liderança
ocorreram em uma iniciativa de melhoria de processos de software bem sucedida em
2015. O presente artigo apresenta uma pesquisa qualitativa que coletou dados a partir de
entrevistas semiestruturadas em profundidade com envolvidos em iniciativa MPS. Para
isso utilizou-se um roteiro de entrevistas semiestruturadas em profundidade para uma
pesquisa interpretativa que tem como propósito identificar as competências chaves de
líderes em iniciativas MPS [Zoucas; Cunha, 2016]. Os dados transcritos das entrevistas
foram analisados a partir da análise temática proposta por Braun e Clarke (2006) e com
o apoio da ferramenta Atlas TI.
O artigo está dividido em 5 seções, incluindo esta introdução. A segunda Seção
apresenta a investigação de trabalhos relacionados. As competências-chave dos líderes
são apresentadas na seção 3, o roteiro de entrevistas e a abordagem desenvolvida com o
propósito de identificar as competências-chave de líderes em iniciativas MPS estão
registrados na Seção 4 e as considerações finais do trabalho são discutidas na Seção 5.
2. Trabalhos relacionados
A pesquisa sobre liderança é uma parte importante e central da literatura sobre gestão e
comportamento organizacional [Yukl, 1989]. Os estudos científicos sobre liderança
existem há décadas, em diferentes áreas do conhecimento, como por exemplo, gestão,
psicologia, sociologia, ciência política, administração pública, administração
educacional, entre outras [Bass, 1990; Burns, 2010; Dinh et al., 2014; Hart; Quinn,
1993; Heifetz, 1998; Lawrence; Street; Northouse, 2007; Quinn et al., 2003; Stogdill,
1974; Yukl, 1989].
Com o propósito de identificar estudos sobre a liderança em iniciativas MPS, foi
realizada uma revisão sistemática da literatura com vinte e três artigos selecionados e o
resultado foi publicado no SBQS 2012 [Zoucas; Thiry; Cunha, 2012]. Do total de
artigos selecionados, quatorze deles discutem diferentes abordagens de implementação
de melhoria de processo de desenvolvimento de software. Eles focam em fatores
econômicos ou se concentram em metodologias específicas, como Agile; ou enfatizam
áreas de processos específicas, como aquisição de software, ou ainda relatam os
resultados de estudos de caso da aplicação de abordagem de implementação de MPS.
Enfim, todos os 14 trabalhos estudados sobre abordagens de implementação de MPS,
discutem a relevância da liderança durante a aplicação de tais abordagens, mas nenhum
deles busca compreender como a liderança ocorreu durante as iniciativas MPS.
Apenas quatro artigos abordam a relevância da Gestão do Conhecimento durante as
fases das iniciativas MPS. Nesse sentido, todos os quatro artigos mencionam a
importância do envolvimento da liderança em tais iniciativas, porém não avançam no
166
conhecimento para buscar compreender como o fenômeno da liderança acontece nesse
contexto.
Os últimos cinco artigos discutem especialmente os fatores críticos de sucesso (FCS) em
iniciativas MPS. Nesses artigos, identificou-se que a liderança é considerada como um
dos principais FCS em iniciativas MPS. Para confirmar este entendimento, foi realizado
um correlacionamento entre os FCS mais relevantes para as iniciativas MPS,
identificados pelos autores desses cinco artigos, com os oito papéis do líder descritos
por Quinn et al. (2003).
Observou-se que todos os FCS mais relevantes para as iniciativas MPS, que
foram considerados nos estudos, se correlacionam com ao menos um dos oito papéis do
líder descrito por Quinn et. al. (2003), apresentados na introdução deste artigo. Portanto,
estes cinco artigos que mostram os fatores críticos de sucesso (FCS) em iniciativas MPS
evidenciam a relevância da liderança para o sucesso das iniciativas MPS. Dentre os FCS
identificados nos trabalhos analisados, constatou-se que os que são relacionados aos
termos líder, liderança ou alta gerência estão entre os principais fatores de sucesso para
as iniciativas MPS, sobressaindo-se aos demais.
Os autores desses trabalhos analisam que a liderança é importante tanto durante
a implementação da melhoria de processos, quanto depois que a iniciativa MPS for
concluída, pois favorece a permanência das melhorias implementadas na unidade
organizacional. Porém, esses estudos não deixam claro quais são os estilos da liderança
ou papéis assumidos pelos líderes que colaboram durante a iniciativa MPS e que ajudam
as melhorias a perdurar na organização. Isto pode ser atribuído ao fato de esses autores
não se aprofundarem especificamente na compreensão da liderança nas iniciativas MPS,
pois os seus objetivos são identificar os fatores críticos de sucesso nas inciativas MPS.
Uma visão ainda atual e importante apresentada pelos trabalhos estudados é que,
mesmo as questões organizacionais, humanas e sociais sendo tão importantes quanto os
aspectos técnicos para as iniciativas MPS, elas ainda são pouco exploradas pelas
pesquisas em MPS. O papel fundamental dos líderes durante as iniciativas MPS é
estabelecer e manter contextos organizacionais que sejam favoráveis à MPS. Em vez de
focar as atividades de MPS em procedimentos técnicos, as ODSs devem concentrar seus
esforços de MPS também em criar uma cultura organizacional onde a esta possa
prosperar. Apesar de as questões organizacionais serem pelo menos tão importante
quanto a tecnologia para as iniciativas MPS, os artigos que vêm sendo publicados sobre
MPS se concentram quase que exclusivamente em técnicas e ferramentas de Engenharia
de Software [Dybå, 2003, 2005].
Ao fim da análise dos artigos selecionados na revisão sistemática da literatura,
foi observada uma oportunidade de pesquisa ao se identificar que a compreensão sobre
como implementar a MPS com sucesso ainda é uma questão em aberto. A literatura
contém, na sua grande maioria, estudos de caso de empresas que descrevem suas
iniciativas MPS, no entanto, estes são cientificamente limitados e inconclusivos [Dybå,
2005].
Com a revisão sistemática da literatura foi possível verificar que os autores dos
trabalhos analisados demonstram perceber a relevância da liderança para o sucesso das
iniciativas MPS. Contudo, não foram encontradas pesquisas desenvolvidas com o
167
propósito de compreender o fenômeno da liderança em iniciativas MPS. Portanto, existe
espaço para uma investigação específica da liderança em iniciativas MPS, que poderia
contribuir para uma gestão mais efetiva de tais iniciativas. Desse modo, com a pesquisa
proposta, espera-se contribuir tanto para a ampliação do conhecimento científico sobre a
liderança no processo de criação do conhecimento organizacional quanto para o
progresso das iniciativas MPS.
3. Práticas da Liderança
O termo prática é utilizado em diferentes áreas do conhecimento, como Filosofia,
História, Sociologia, Antropologia, entre outros [SAVIGNY; SCHATZKI; KNORR-
CETINA, 2001]. Nos últimos anos, a produção científica sobre o tema vem aumentando
consideravelmente, pois a academia vem debatendo o termo prática, uma vez que esta
passou a ser considerada na investigação de diferentes fenômenos [BISPO, 2013;
GHERARDI, 2006; NICOLINI, 2013; SAVIGNY; SCHATZKI; KNORR-CETINA,
2001]. Apesar de o estudo sobre prática não ser uma novidade, definir o que se entende
por “prática” não é uma atividade trivial, e esta dificuldade “não se deve apenas à
polissemia do termo, mas também aos vários posicionamentos epistêmicos de diferentes
pesquisadores” [GHERARDI; STRATI, 2014].
Além disso, a partir da ampliação do volume de trabalhos sobre práticas,
emergiu um corpo de pesquisas chamado Practice Based Studies (PBS), ou Estudos
Baseados em Prática [GHERARDI; STRATI, 2014], que tem pressupostos e
referenciais bibliográficos semelhantes e que adota a prática como forma de
compreender a aprendizagem, o conhecimento e as organizações. O tema vem
despertando, especialmente nos últimos anos, o interesse dos autores de estudos
organizacionais [BISPO; SOARES; CAVALCANTE, 2014]. Porém, o aumento do
interesse sobre PBS em diferentes áreas veio acompanhado de “preocupações sobre a
perda do poder crítico do conceito de prática em relação a abordagens mais ortodoxas,
moldadas por pressupostos de racionalismo e cognitivismo, nos estudos
organizacionais” [GHERARDI; STRATI, 2014]. Existem estudos sobre práticas que
assumem o termo “prática” como sinônimo de “rotina”, ou como algo que expresse
apenas “o que as pessoas fazem”, sem considerar a prática como fonte geradora de
conhecimento.
Gherardi (2006), uma pesquisadora com expressiva produção científica sobre a
perspectiva sociológica da aprendizagem organizacional a partir das práticas, aponta que
as práticas: a) são incompletas e indeterminadas até que sejam executadas situadamente;
e b) se autoreproduzem, mas nunca são idênticas a si mesmas. Para ela, um dos atributos
essenciais para a compreensão do conceito de prática é o fato de que esta é um conjunto
de atividades que tem significado e passa a ser reconhecido enquanto unidade num
contexto de ação situada [GHERARDI, 2006, p. 34]. Também está alinhado com a
perspectiva de Endrissat e Arx (2013, p. 295), quando os autores afirmam que “as
práticas estão situadas, porque a liderança é encontrada em micro atividades que estão
embutidas em uma situação específica”.
Nesta pesquisa, foi considerado que a situação é uma circunstância, gerada pela
pressão contextual, que motivou uma determinada atividade. O contexto corresponde ao
ambiente físico onde ocorreu a iniciativa MPS estudada, o que contempla os produtos
168
de trabalho usados e gerados, como, por exemplo, os processos melhorados, ferramentas
utilizadas para a modelagem dos processos e sua execução, o período em que a
iniciativa MPS foi realizada, incluindo as pessoas que participaram dela.
4. Método de pesquisa
No contexto desta pesquisa, entrevistas foram realizadas com o objetivo de compreender
a liderança na iniciativa MPS estudada pela ótica de entrevistados que estiveram
envolvidos diretamente nessas iniciativas. Para isto, foram conduzidas entrevistas
semiestruturadas em profundidade, por ser esta uma abordagem considerada adequada
para o contexto do estudo de caso. As entrevistas abordaram diferentes aspectos
relacionados com o processo da liderança na iniciativa MPS em que os entrevistados
estiveram envolvidos, tais como: a contextualização da unidade organizacional e das
práticas da liderança, para caracterizar o “onde”; o perfil dos envolvidos, para
caracterizar o “quem”; as práticas realizadas e ferramentas usadas pelos envolvidos
durante a iniciativa MPS, para caracterizar o “como” e o "porquê" das práticas de
liderança.
Os entrevistados foram convidados a expor suas percepções e experiências
enquanto envolvidos na iniciativa MPS. Ao abordar tais informações, os pesquisadores
buscaram compreender como ocorreu a liderança no contexto de uma unidade
organizacional que obteve êxito em avaliação oficial de melhoria de processo de
software.
As entrevistas foram planejadas, e posteriormente foi encaminhado um e-mail
para as ODSs, confirmando quais pessoas os pesquisadores gostariam de entrevistar,
além de sugestões de data, local e horário das entrevistas. Primeiramente, foram
identificados os sujeitos do estudo, profissionais envolvidos na iniciativa MPS nas
unidades organizacionais estudadas. O objetivo foi obter um perfil dos envolvidos nas
iniciativas MPS para apoiar a seleção dos profissionais a serem entrevistados. Aos
envolvidos foi aplicado um roteiro de entrevista [Zoucas; Cunha, 2016], para ajudar a
identificar suas práticas durante a iniciativa MPS. O objetivo desse levantamento foi
aferir consistência interna às práticas identificadas.
As transcrições das entrevistas foram examinadas com o apoio da ferramenta
AtlasTI, através de análise temática, que se trata de um método sistematizado em seis
fases, para identificar, analisar e relatar padrões nos dados coletados (BRAUN;
CLARKE, 2006). Estas fases e suas respectivas características foram propostas por
Virginia Braun e Victoria Clarke (2006) conforme segue:
 fase 1: familiarização com os dados;
 fase 2: geração inicial de códigos;
 fase 3: busca de temas;
 fase 4: revisão de temas potenciais;
 fase 5: definição e denominação de temas;
 fase 6: produção do relatório.
169
Assim, os pesquisadores identificaram e descreveram atividades que constituem
as práticas de liderança resultantes da análise temática no caso estudado, como forma de
compreender a liderança em uma iniciativa MPS distinta.
5. Análise dos dados coletados

A iniciativa MPS estudada ocorreu em uma empresa catarinense fundada em 1996,
voltada para o desenvolvimento institucional e especializada em projetos de Gestão da
Informação e Desenvolvimento Institucional. A força de trabalho da empresa, durante a
iniciativa MPS, estava distribuída da seguinte maneira: três sócios e dirigentes
envolvidos com a parte administrativa; 30 empregados efetivos atuando com as
atividades técnicas, o que inclui os gerentes de projetos; quatro bolsistas e estagiários e
27 prestadores de serviço terceirizados, também envolvidos com a parte técnica, mas um
destes permaneceu focado nas atividades de melhoria de processo.
Antes desta empresa adotar a iniciativa MPS, os entrevistados percebiam que
havia problemas nos processos de desenvolvimento de software da unidade
organizacional, pois tinham dificuldades para acompanhar os projetos em
desenvolvimento. Eles tinham a sensação de que os projetos não eram finalizados. Os
projetos atrasavam, e a alta gestão não sabia como controlar sua evolução, pois não
havia uma sistemática de trabalho a ser seguida.
A iniciativa MPS foi conduzida conforme a abordagem de melhoria de processos
usada pela equipe de consultores contratada para orientar os envolvidos nesta iniciativa
MPS. Um esquema desta abordagem está apresentado a seguir na figura 1.
Figura 1. Abordagem de melhoria de processos
170
A iniciativa MPS trouxe para esta empresa diferentes benefícios para sua
unidade organizacional. Entre elas, os entrevistados citaram que foi construído um
processo padrão para as atividades de desenvolvimento de software. Assim, para realizar
os projetos da unidade organizacional, seus colaboradores passaram a executar o
processo melhorado, que foi formalizado como o padrão de desenvolvimento.
Esse processo foi publicado e passou a ser seguido, para garantir a aderência da
execução dos projetos à sua política organizacional. Isso não significa, entretanto, que
todos os projetos usam os processos padrão da mesma forma. “Projetos têm
características diferentes no que se refere, por exemplo, ao tamanho, requisitos de
qualidade, inovação e experiência da equipe. Estas características têm influência na
adequação de um processo ao projeto e precisam ser consideradas” [SOFTEX, 2016].
Portanto, a empresa estabeleceu e passou a seguir um processo para os seus projetos de
desenvolvimento de software, que contempla as atividades de planejamento e estimativa
de esforço para as tarefas dos projetos, bem como atividades de processos
organizacionais.
Os entrevistados também relataram que estão conseguindo identificar os
requisitos dos softwares com mais qualidade, refletindo exatamente o que deve ser
desenvolvido, e assim conseguem transmitir para os desenvolvedores com mais clareza
o que se espera que eles entreguem. Os desenvolvedores têm conseguido entregar
corretamente o que se espera e dentro do prazo acordado. Dessa forma, os entregáveis
vêm sendo construídos cada vez mais corretamente e logo da primeira vez. Portanto, a
iniciativa MPS também reduziu o retrabalho da equipe.
A Liderança na iniciativa MPS desta empresa envolveu toda a equipe, pois ela é
composta de apenas uma unidade organizacional. Nesta iniciativa MPS, identifiquei
quatro práticas de liderança: Sensibilização, Direcionamento, Reunião MPS
(Comunicação) e Acompanhamento. Cumpre destacar que cada prática engloba uma ou
mais atividades, que identifiquei a partir de uma ou mais situações que ocorreram
exclusivamente neste caso estudado, como é pontuado a seguir:
Sensibilização: ações que visam despertar nos envolvidos sentimentos a favor da
iniciativa MPS. Pode incluir as seguintes atividades:
 Apresentar para a equipe diferentes possibilidades de implementação da MPS.
 Apresentar para a equipe os problemas e dificuldades enfrentadas pela
necessidade de melhoria de processos.
 Apresentar para a equipe os benefícios que a melhoria de processos poderá
proporcionar para o trabalho e para a empresa.
 Apresentar para a equipe os ganhos reais que a melhoria de processos
proporcionou para o trabalho e para a empresa.
 Reconhecer comprometimento nas ações de melhoria de processo.
Direcionamento: ações que visam organizar atividades a serem realizadas para que a
iniciativa MPS possa ser concluída com sucesso. Pode incluir as seguintes atividades:
 Agendar reuniões MPS
171
 Realizar treinamentos internos,
 Realizar intervenções na infraestrutura
 Estabelecer marcos da iniciativa MPS
 Definir os entregáveis da iniciativa MPS
Reunião MPS (Comunicação): – troca de informações em horário planejado, entre os

membros da equipe da unidade organizacional, com pauta conhecida, para analisar e
estudar juntos, discutir tópicos, tomar decisões, analisar cenários, solucionar problemas
etc.
 Realizar reunião MPS com consultor
 Realizar reunião MPS sem consultor
 Identificar conhecimento tácito
 Tomar decisão de forma compartilhada
 Obter o comprometimento dos envolvidos com a iniciativa MPS
 Negociar melhorias com os envolvidos
 Revisar, validar e aprimorar processos melhorados
 Identificar conflito de interesses
Acompanhamento: verificar se há desvio ou fator que esteja impedindo que a iniciativa

MPS alcance os resultados esperados;
 Verificar se a equipe está desenvolvendo os entregáveis da iniciativa MPS
 Verificar se a equipe está alcançando os marcos da iniciativa MPS
 Verificar se há impedimentos para executar os processos melhorados
 Verificar necessidade de capacitação
 Escalonamento para Alta Gestão em caso de impedimento na iniciativa MPS
Todas as quatro práticas e 23 atividades que constituem as práticas apesentadas

estão identificadas como “práticas da liderança”, pois elas têm como propósito interferir
nos integrantes da equipe desta empresa com o intuito de fomentar a iniciativa MPS e
propiciar que a meta organizacional de melhoria de processos seja atingida. Como
consequência a empresa obteve uma avaliação de processos bem sucedida no nível de
maturidade pretendido.
Cumpre ressaltar que não foi identificada nenhuma prática que inicie e termine
durante a iniciativa estudada. Elas estão ocorrendo durante toda a iniciativa,
apresentando uma forma complexa de relação entre as práticas identificadas. Portanto as
práticas estão enredadas no ambiente de melhoria de processos de software.
172
6. Conclusão
Esta pesquisa foi desenvolvida a partir da premissa de que as iniciativas MPS são
realizadas em conformidade com modelos de referência de processos como uma
estratégia para aumentar a qualidade do que é produzido na indústria de software.
As iniciativas MPS ocorrem tipicamente no contexto de ODSs e estas, por sua
vez, apresentam características diferenciadas das organizações tradicionais pelo fato de
criarem e disseminarem conhecimentos continuamente. Portanto, elas podem ser
classificadas como organizações intensivas em conhecimento (ALVESSON, 1993;
SWART; KINNIE, 2003).
Nessa perspectiva, ainda que a literatura sobre iniciativas MPS considere o
exercício da liderança como imprescindível para o sucesso delas (MONTONI; ROCHA,
2010, 2011a; SANTOS, 2011), verificou-se a carência de estudos cujo objeto de análise
é o fenômeno da liderança em iniciativas MPS. Portanto esta pesquisa foi conduzida
uma pesquisa qualitativa com foco em compreender como ocorre a liderança em
iniciativas de melhoria de processo de software.
Mediante a análise das entrevistas, foram encontrados nesta pesquisa, subsídios
teóricos e empíricos que podem explicar como ocorreu a liderança na iniciativa MPS
estudada. Foi identificado que nas iniciativas MPS estudadas havia um aspecto
contextual, que é inerente à unidade organizacional estudada e confere a cada prática
contextualizada a característica de ser uma prática exclusiva e única, diferente de
qualquer prática encontrada com o mesmo propósito em outros contextos. Entretanto,
existiu também um aspecto processual, que está relacionado à abordagem de
implementação de melhoria de processos usada pela equipe de consultores.
Considerando que nenhum outro trabalho foi encontrado na fase de revisão
bibliográfica sobre a liderança como prática em iniciativas MPS, pois foram
encontrados apenas trabalhos com considerações sobre a importância do envolvimento
da liderança para o sucesso de tais iniciativas. Portanto, provavelmente, este trabalho é a
primeira investigação científica realizada sobre como ocorre a liderança em iniciativas
MPS. Assim sendo, este trabalho não tem a pretensão de encerrar o debate sobre
liderança em iniciativa MPS. Ele é um ponto de partida para o estudo da liderança nesta
área e deve ser aprofundado para receber novas contribuições oriundas, tanto da
expansão da amostra quanto de sua análise por outras perspectivas.
A expansão da amostra diz respeito a também considerar como objeto de estudo
iniciativas MPS realizadas por empresas que alcançaram outros níveis de maturidade, ou
que foram avaliadas com sucesso em relação a outros modelos de referência como o
CMMI-DEV. Ou ainda, modelos de referência de melhoria de processos de serviços
como é o caso do MPS-SV e o CMMI-SVC. A análise por outras perspectivas diz
respeito a analisar os dados coletados com o intuito de, por exemplo, identificar o papel
da liderança nas iniciativas MPS por uma perspectiva prática, ou ainda com enfoque em
uma determinada teoria da liderança.
173
Referências
Ahire, S. L.; Golhar, D. Y.; Waller, M. A. (1996) Development and validation of TQM
implementation constructs. Decision Sciences, v. 27, n. 1, p. 23-56.
Bass, B. M. (1990) Bass & Stogdill’s handbook of leadership: theory, research and
managerial application. New York, USA: The Free Press.
Black, S. A.; Porter, L. J. (1996) Identification of the critical factors of TQM. Decision
Sciences, v. 27, n. 1, p. 1-21.
Braun, V.; Clarke, V. (2006) Using thematic analysis in psychology. Qualitative
Research in Psychology, v. 3, n. 2, p. 77-101.
Burns, J. M. (2010) Leadership. New York, USA: Harpercollins Publichers.
Contandriopoulos AP, Champagne F, Potvin L, Denis JL, Boyle P. (1997) Saber
preparar uma pesquisa. 2ª ed. São Paulo (SP): Hucitec.
Dinh, J. E. et al. (2014) Leadership theory and research in the new millennium: Current
theoretical trends and changing perspectives. Leadership Quarterly, v.25, n.1, p.36-62.
Dybå (2003) Factors of software process improvement success in small and large
organizations: an empirical study in the scandinavian context. ACM SIGSOFT
Software Engineering Notes, n. 7465, p. 148-157, 2003.
Dybå (2005) An empirical investigation of the key factors for success in software
process improvement. Software Engineering, IEEE Transactions on, v. 31, n. 5, p.
410-424.
El Emam, K. et al. (2001) Modeling the likelihood of software process improvement:
An exploratory study. Empirical Software Engineering, v. 6, p. 207-229.
Goldenson, D.; Herbsleb, J. (1995) After the appraisal: A systematic survey of process
improvement, its benefits, and factors that influence success. Cmu/Sei-95-Tr-009, n.
August.
Hart, S.; Quinn, R. (1993) Roles executives play: CEOs, behavioral complexity, and
firm performance. Human Relations.
Heifetz, R. A. (1998) Leadership without easy answers. Oxford: TheBelknap Press of
Harvard University Press.
Laporte, C. Y.; Trudel, S. (1998) Addressing the people issues of process improvement
activities at Oerlikon Aerospace. Software Process: Improvement and Practice, v. 4,
n. 4, p. 187.
Lawrence, K. A.; Street, T.; Quinn, R. E. (2003) Behavioral complexity in leadership:
The psychometric properties of a new instrument.
Montoni, M.; Rocha, A. (2011) Uma investigação sobre os Fatores Críticos de Sucesso
em iniciativas de melhoria de processos de software. In: SBQS – Simpósio Brasileiro
de Qualidade de Software, Anais... SBQS, p. 151-166. Curitiba, PR - Brazil.
Newstrom, J. W. (2008) Comportamento organizacional. 12. ed. McGraw Hill.
174
Niazi, M.; Wilson, D.; Zowghi, D. (2005) A maturity model for the implementation of
software process improvement: an empirical study. Journal of Systems and Software,
v. 74, n. 2, p. 155-172.
Northouse, P. G. (2007) Leadership : theory and practice. Thousand Oaks: Sage
Publications.
Paulk, M. C. et al. (1993) Capability maturity model, version 1.1. IEEE Software, v. 10,
n. 4, p. 18-27.
Powell, T. C. (1995) TQM as competitive advantage strategic. Management Journal.
Disponível em: <http://www.thomaspowell.co.uk/article_pdfs/TQM_as_CA.pdf>
Acesso em:25 de março de 2013
Quinn, R. E. Thompson, M.; Faerman, S. R.; Mcgrath, M. (2003) Competências
gerenciais: princípios e aplicações. 1. ed. Elsevier.
Santos, G. (2011) Influência e impacto do Programa MPS.BR na pesquisa relacionada a
qualidade de software no Brasil. In: SBQS – Simpósio Brasileiro de Qualidade de
Software, Anais... SBQS, p. 73-87.
Saraph, J. V.; Benson, P. G.; Schroeder, R. G. (1989) An instrument for measuring the
critical factors of quality management. Decision Sciences, v. 20, n. 4, p. 810-829.
Stelzer, D.; Mellis, W. (1999) Success factors of organizational change in software
process improvement. Software Process Improvement and Practice, v. 4, n. 4, p.1-34.
Stogdill, R. M. Handbook of leadership: A survey of theory and research. New York,
USA: Free Press.
Taylor, S. J.; Bogdan, R. (1974) Introduction to qualitative research methods: a
guidebook and resource. New York, USA: Wiley, 1998.
Trevizan, M. A. et al. (1987) Estrutura teórica do Modelo Mintzberg. Revista Gaúcha de
Enfermagem, v. 8, n. 2, p. 236-243.
Weber, K. C.; Macedo, M. De M.; Franco, N. H. (2015) Impactos socioeconômicos no
Brasil do Modelo MPS-SW para Melhoria de Processos de Software. In: SBQS -
Simpósio Brasileiro de Qualidade de Software. Anais... Manaus (AM), 2015.
Disponível em: <http://www.softex.br/wp-content/uploads/2015/09/140339_2-
Ajustes-formais-Kival-v020614.pdf> Acesso em: 21 jan. 2016.
Yukl, G. A. (2008) Leadership in organizations. 7th ed. ed. Upper Saddle River, NJ:
Pearson/Prentice Hall.
Yusof, S. M.; Aspinwall, E. (1999) Critical success factors for total quality management
implementation in small and medium enterprises totalvquality management.
Zoucas, A. et al. (2012) Revealing the influence of leadership on software process
improvement initiatives. In: 2012 Eighth international conference on the quality of
information and communications technology. Proceedings... p. 149-152.
Zoucas, A.; Thiry, M.; Cunha, C. (2012) Compreendendo a influência da liderança nas
iniciativas de melhoria de processo de desenvolvimento de software. In: SBQS –
Simpósio Brasileiro de Qualidade de Software. Anais...Fortaleza, CE Brasil.
175
Práticas para Tratamento de Fatores Críticos de Sucesso
Raphael Freire1, Davi Viana2, Gleison Santos1
1
Programa de Pós-Graduação em Informática - Universidade Federal do Estado do Rio
de Janeiro (UNIRIO) - Av. Pasteur, 458, Urca, CEP 22290-240 - Rio de Janeiro, RJ
2
Programa de Pós-Graduação em Ciência da Computação - Universidade Federal do
Maranhão (UFMA) - Av. dos Portugueses, 1966, Bacanga, CEP 65080-805 - São Luís,
MA
{raphael.freire,gleison.santos}@uniriotec.br, davi.viana@lsdi.ufma.br
Abstract. Organizations confront a series of difficulties conducting software

process improvement (SPI) initiatives. The causes of such difficulties may be
related to organizational, technological or sociocultural aspects. Some of
these aspects are known as critical success factors. In this context, this
research presents a catalog of practices that can address negative critical
factors. The catalog was conceived from cycles of incremental learning, using
the Design Science Research methodology. We performed two case studies in
order to evaluate the catalog and we identified the relevance of 84% of the
practices in SPI initiatives contexts.
Resumo. As organizações confrontam uma série de dificuldades na condução
de iniciativas de melhoria de processos de software (SPI). As causas podem
estar relacionadas a aspectos de cunho organizacional, tecnológico e
sociocultural. Alguns desses aspectos são considerados fatores críticos de
sucesso. Neste contexto, este trabalho apresenta um catálogo de práticas que
podem ser utilizadas para tratar os fatores críticos negativos. Este catálogo
foi concebido a partir de ciclos de aprendizado incrementais, utilizando a
metodologia Design Science Research. Em uma avaliação do catálogo
realizada por meio de dois estudos de caso, foi identificada a pertinência de
84% das práticas em relação aos contextos das iniciativas de MPS em
questão.
1. Introdução
A aplicação das boas práticas de Engenharia de Software em iniciativas de Melhoria de
Processo de Software (ou, SPI, do inglês software process improvement) tem se tornado
uma estratégia constante em organizações de software para aumentar a qualidade dos
seus produtos. As organizações partem da suposição de que a qualidade do produto
pode ser elevada devido ao aumento da qualidade do processo de desenvolvimento
(FUGGETTA, 2000; MONTONI e ROCHA, 2011). O sucesso na implementação de
iniciativas de melhoria de processos de software depende fundamentalmente de
estratégias e abordagens adotadas para apoiar a execução de tais iniciativas.
Entretanto, a falta de adequação dessas abordagens utilizadas é uma das razões
para o fracasso das iniciativas de melhoria (MONTONI, 2010). Outros fatores sociais e
culturais, como comunicação, falta de motivação e falta de apoio da alta direção
também são apontados como causadores de fracassos na condução destas iniciativas
176
(BAYONA et al., 2012). Além disso, aspectos relacionados com a equipe de
consultoria, como falta de competências técnicas, falta de confiança no consultor e falta
de abertura para ouvir opiniões, são fatores críticos que podem influenciar
negativamente as iniciativas de melhoria de processos de software (MONTONI, 2010).
Diversos estudos foram realizados na área com o intuito de identificar as causas
dos problemas que influenciam o sucesso de iniciativas de melhoria, bem como analisar
suas interações, efeitos e ações de tratamento (DUTRA, 2015; BAYONA et al., 2013;
BAYONA et al., 2012; MONTONI, 2010). Esses problemas são tratados, comumente,
como Fatores Críticos de Sucesso (FCS), pois constituem um número reduzido de
questões importantes em que a alta gerência deve colocar atenção para alcançar os
resultados esperados com a implementação de melhorias nos processos (MONTONI,
2010). Contudo, poucos trabalhos buscam identificar práticas no sentido de mitigar os
efeitos negativos dos FCS (MENDES et al., 2007).
A aplicação de práticas de Gerência de Conhecimento (GC) e Aprendizagem
Organizacional (AO) e de práticas gerenciais pode ser uma estratégia utilizada para as
organizações reagirem a estes fatores críticos de influência negativa. Práticas de GC e
AO buscam organizar a identificação e utilização de conhecimento organizacional em
benefício das atividades organizacionais (IANDOLI e ZOLLO, 2008; SENGE, 1991),
enquanto as práticas gerenciais auxiliam nas questões organizacionais e culturais, como
inserir o corpo funcional em atividades de conscientização para ressaltar a importância
do projeto de melhoria (PARENTE et al., 2008).
Neste sentido, o objetivo deste trabalho é investigar quais práticas podem ser
empregadas com o objetivo de reagir aos FCS causadores de fracassos em SPI. Neste
trabalho, esses FCS são denominados de fatores críticos de influência negativa. Para
realizar esta pesquisa foi adotada a metodologia Design Science Research (DSR), onde
foram conduzidos ciclos de aprendizado incrementais com intuito de obter
conhecimento em relação ao tratamento destes fatores. Como resultado, foram
identificadas 135 práticas gerenciais, 27 práticas de GC e AO e 24 ferramentas que
podem ser utilizadas neste contexto.
Além desta seção introdutória, o artigo está organizado da seguinte forma: Seção
2 apresenta uma revisão da literatura sobre FCS e conceitos sobre GC e AO; Seção 3
descreve a metodologia de pesquisa e os ciclos de aprendizado incrementais realizados;
Seção 4 expõe o catálogo de práticas para tratamento dos fatores críticos negativos e
discorre sobre as limitações do trabalho. Por fim, a Seção 5 apresenta as considerações
finais.
2. Fatores Críticos de Sucesso e Gerência do Conhecimento em Melhoria de

Processos de Software
A partir de uma revisão da literatura, foram identificados diversos estudos que apontam
fatores críticos de sucesso de iniciativas de SPI (BAYONA et al., 2013; MONTONI,
2010; VIRTANEN et al., 2013; BAYONA et al., 2012; HABIB, 2009), dificuldades
(ROCHA et al., 2005), fatores desmotivadores (BADDOO, 2001) e fatores de
resistência (NASIR et al., 2008) relacionados à adoção de modelos de maturidade para
melhoria de processos.
HABIB (2009) realizou um estudo empírico para identificar fatores críticos de
sucesso, motivadores e obstáculos em iniciativas SPI em 4 países (Suécia, Paquistão,
177
Dinamarca e Noruega). Os principais fatores críticos encontrados foram:
comprometimento da alta gestão, envolvimento e experiência dos membros da
organização, conscientização e implementação em SPI e alocação de recursos. Por sua
vez, BAYONA et al. (2013) realizaram revisão sistemática para apontar fatores críticos
de sucesso relacionados aos aspectos humanos. Alguns dos fatores identificados foram:
presença de líderes na iniciativa de SPI, comprometimento da gerência, envolvimento
da equipe de desenvolvimento e motivação.
VIRTANEN et al. (2013) identificaram que iniciativas de SPI costumam falhar,
pois a alta direção costuma priorizar mais projetos em andamento do que o projeto de
melhoria. Isso ocorre, pois a organização não aloca adequadamente recursos financeiros
e tempo para o projeto de SPI. Em relação aos fatores desmotivadores, BADDOO
(2001) identificou uma série de fatores, alguns dos exemplos são: imposição do
processo, comunicação inadequada, falta de visibilidade em relação aos benefícios do
projeto de melhoria e falta de recursos.
MONTONI (2010) concebeu um framework teórico constituído de conceitos e
relacionamentos de influência, fundamentados em um conjunto de proposições
(hipóteses), representando a visão e a perspectiva de implementadores de SPI. Foram
identificados diversos fatores críticos de sucesso que influenciam iniciativas de SPI, por
exemplo, “apoio, comprometimento e envolvimento”, “aceitação às mudanças” e
“motivação e satisfação dos membros da organização”. Além dos fatores críticos de
sucesso, MONTONI (2010) apresenta 41 tipos de achados de fatores de influência
negativa, que foram identificados por meio da aplicação de procedimentos do método
Grounded Theory (STRAUSS e CORBIN, 2008).
A aplicação de AO e GC em relação ao que deve ser feito nas atividades dos
processos de software e sua melhoria são fatores críticos em Engenharia de Software
(VIANA et al., 2012). A GC consiste em um processo de criação, captura,
armazenamento e utilização do conhecimento de tal forma que ele possa ser transferido
significativamente para outra pessoa (RAS et al., 2005). Segundo TIWANA (2002), o
principal objetivo da GC no contexto organizacional é facilitar a aplicação oportuna de
conhecimento fragmentado por meio da integração.
Segundo LAND et al. (2001), é fundamental que o conhecimento seja aprendido
a nível organizacional, de tal forma que agregue sucesso às atividades de
desenvolvimento de software realizadas. De acordo com SENGE (1991), Aprendizagem
Organizacional (AO) pode ser definida como o ciclo contínuo de experiência e sua
transformação em conhecimento acessível por toda organização e que seja relevante
para suas finalidades básicas. Em outras palavras, AO é um processo adaptativo de
mudança influenciado pela experiência no passado, e é centralizado no desenvolvimento
ou modificação de rotinas e apoiado pela memória organizacional (MENOLLI, et al.,
2016).
Neste contexto, VIANA (2015) desenvolveu o framework KL-SPI (Knowledge
and Learning to Facilitate Software Process Improvement) que visa facilitar a AO e GC
em organizações que implementam SPI. Este framework é composto por três
componentes: (i) estratégia de diagnóstico do Estado da Prática de AO e GC nas
organizações, (ii) catálogo de práticas de AO e GC e (iii) ferramentas para auxiliar a AO
em SPI. VIANA (2015) definiu o catálogo de práticas de AO e GC a partir de
investigações do estado da prática e de resultados de mapeamento sistemático literatura.
178
Além da aplicação de GC, verifica-se que a utilização de práticas gerenciais para
o tratamento de FCS de influência negativa é recomendada. ZANETTI et al. (2008)
destacam que tratar iniciativas de melhoria como um projeto tradicional, ou seja,
utilizando princípios de Gerência de Projetos, é importante para facilitar a percepção
das melhorias obtidas a cada etapa do projeto e serve como incentivo para os membros
da organização. Outra prática gerencial relevante consiste em homologar os processos
com a alta direção. Este mecanismo é fundamental para o alinhamento e
comprometimento da alta gerência e facilita a institucionalização dos processos
(PORTO et al., 2008).
O presente trabalho concentra-se no tratamento dos 41 fatores críticos negativos
identificados por MONTONI (2010), que podem ser encontrados, em sua íntegra, no
Relatório Técnico1 correspondente a esse artigo. Decidiu-se escolher o trabalho de
MONTONI (2010), pois nele foi feito um detalhamento e desdobramento sobre cada
FCS, diferente dos demais trabalhos que apenas elencaram os fatores sem gerar
categorias, associações e análises entre os FCS. Além disso, considerou-se o framework
KL-SPI (VIANA, 2015), como referência para as práticas de GC e AO que visam tratar
os fatores críticos negativos. Essas práticas foram definidas a partir da integração de
investigações da prática com um mapeamento sistemático da literatura sobre AO e GC
em Engenharia de Software e SPI. Desta forma, elas foram consideradas adequadas para
o contexto desta pesquisa.
3. Desenvolvimento da Pesquisa
3.1. Metodologia da Pesquisa

A Figura 1 apresenta a abordagem metodológica deste trabalho, baseada no método
Design Science Research (DSR) ou Pesquisa em Ciência do Design (WIERINGA,
2014). A abordagem DSR fundamenta e operacionaliza a condução da pesquisa quando
o objetivo a ser alcançado é um artefato ou uma prescrição. Este método busca, a partir
da compreensão do problema, construir e avaliar artefatos que permitam transformar
situações, alterando suas condições para estados melhores ou desejáveis. Outra
característica desta abordagem é ser orientada à solução de problemas específicos, não
necessariamente buscando a solução ótima, mas a solução satisfatória para situação
(DRESCH et al., 2015).
O artefato proposto é um catálogo constituído de práticas de Gerência de
Conhecimento e Aprendizagem Organizacional, gerenciais e ferramentas que visa
apoiar as organizações desenvolvedoras de software a confrontar com fatores críticos
negativos durante uma iniciativa de SPI. No bloco “Estado da arte” estão os pilares
deste estudo: o MR-MPS-SW (Modelo de Referência para Melhoria de Processos de
Software) (SOFTEX, 2016) e o CMMI-DEV (Capability Maturity Model Integration
for Development) (CMMI Product Team, 2010), análise qualitativa, o conjunto de
fatores críticos de sucesso proposto por MONTONI (2010) e o framework KL-SPI
concebido por VIANA (2015). O requisito principal do artefato é fornecer
recomendações de práticas para as organizações mitigarem ou amenizarem o efeito de
fatores que exerçam influência negativa em melhoria de processos de software. As
1
O Relatório Técnico encontra-se disponível no endereço:
http://www.seer.unirio.br/index.php/monografiasppgi/article/view/6505
179
atividades correspondentes a esta metodologia são apresentadas na Tabela 1. Essas
atividades visam obter conhecimento em relação às práticas que podem ser utilizadas
para tratar os fatores críticos negativos levantados por MONTONI (2010). Para isso,
foram realizadas entrevistas com especialistas, investigação na literatura, entre outros
estudos.
Figura 1.Modelo de pesquisa em Design Science utilizado neste trabalho
Tabela 1. Ciclos de aprendizado incrementais realizados durante a pesquisa
Objetivo do ciclo Principais ações Principais achados
Compreender as Realização de entrevistas e Identificados os processos que os consultores

dificuldades de aplicação de questionários possuem maior grau de dificuldade para avaliar e
capacitação de para consultores implementar (exemplo: Aquisição– AQU e
implementadores de Gerência de Portfólio de Projetos – GPP. Foram
SPI verificados os tipos de conhecimento necessários
durante a implementação de uma iniciativa SPI
Verificar quais Associar as práticas de GC e Para o fator crítico “Alta rotatividade”, foram
práticas de GC e AO propostas pelo catálogo identificadas práticas como “Utilização de
AO poderiam ser de práticas do KL-SPI com os ferramentas organizacionais/repositórios de
aplicadas para tratar fatores críticos negativos conhecimento”, “Integração dos colaboradores”,
fatores críticos apontados por MONTONI “Interação com colaboradores experientes”,
negativos (2010) “Mentoring” e “Treinamento”. Para os fatores
“Falta de motivação” e “Membros da equipe
180
Objetivo do ciclo Principais ações Principais achados
insatisfeitos com a organização”, foi sugerida a
prática “Premiação de projetos”
Observar o uso de Realização de estudo de caso Identificou-se que as práticas “Utilização de

práticas de GC e exploratório descritivo e ferramentas organizacionais/repositórios de
AO em um contexto entrevista semiestruturada conhecimento”, “Aprender-fazendo”, “Workshops”
real e, se possível, e “Realização de acompanhamento/tutoria”auxiliam
com presença de no tratamento do fator crítico negativo “Alta
fatores críticos rotatividade”, corroborando parcialmente com os
negativos achados do ciclo anterior
Investigar na Realização de mapeamento Obtidas ao todo 186 práticas, sendo 135 práticas
literatura (relatos de sistemático da literatura e gerenciais, 27 práticas de GC e AO e 24
experiência e artigos análise temática utilizando ferramentas. Estas práticas foram divididas em 8
técnicos) mais procedimentos da Grounded categorias. Além disso, foram obtidas informações
práticas para Theory estatísticas como quantidade de publicações por
tratamento de evento, por organização, tipo de artigo e tipo de
fatores críticos organização
negativos
Avaliar o Realização de auditoria para Os auditores recomendaram diversas práticas

mapeamento entre avaliar a codificação e a sugestões para tratamentos dos fatores críticos.
as práticas sob o coerência das associações Algumas práticas foram excluídas por não terem
ponto de vista de entre os códigos sido consideradas adequadas
especialistas em SPI
3.2. Mapeamento Sistemático da Literatura

Tendo em vista que nos três primeiros ciclos de aprendizado não se obteve um número
expressivo de práticas para tratamento dos fatores críticos negativos, a motivação deste
mapeamento sistemático da literatura consistiu em investigar na literatura a existência
de mais práticas.
O planejamento deste estudo foi baseado nas diretrizes propostas por
KITCHENHAM e CHARTERS (2007) e PETERSEN et al. (2015) para um
mapeamento sistemático. O objetivo do mapeamento segue o paradigma Goal Question
Metric (GQM) (BASILI e ROMBACH, 1988) e compreende: Analisar relatos de
experiência e publicações científicas por meio de um mapeamento sistemático da
literatura com o propósito de identificar práticas de Gerência de Conhecimento, de
Aprendizagem Organizacional e gerenciais com relação a fatores críticos de influência
negativa em iniciativas de melhoria de processos de software baseadas em um modelo
de maturidade, como o MR-MPS-SW e o CMMI-DEV, do ponto de vista dos
pesquisadores e profissionais envolvidos no contexto acadêmico e industrial
Para alcançar o objetivo descrito, foi definida a seguinte questão de pesquisa
principal: “Como os fatores críticos de influência negativa são tratados em iniciativas
de melhoria de processos de software?”. Para responder essa questão foram
estabelecidas quatro questões secundárias (QS):
• QS1. “Que práticas de Gerência de Conhecimento e Aprendizagem
Organizacional foram utilizadas para tratar fatores críticos de influência negativa
em iniciativas de SPI?”
181
• QS2. “Que práticas gerenciais foram utilizadas para tratar fatores críticos de
influência negativa em iniciativas de SPI?”
• QS3. “Que ferramentas foram utilizadas para tratar fatores críticos de influência
negativa em iniciativas de SPI?”
• QS4. “Em que contexto as práticas e ferramentas identificadas foram
utilizadas?”
É importante ressaltar que quando se trata de “fatores críticos de influência
negativa” no âmbito deste trabalho, restringe-se aos 41 fatores críticos negativos
identificados por MONTONI (2010). Logo, as questões de pesquisa apresentadas
correspondem a este escopo de fatores críticos. Além disso, para responder a QS1,
tomou-se como referência o catálogo de práticas de AO e GC de VIANA (2015).
Além disso, para responder às questões de pesquisa foi realizada uma análise
temática utilizando alguns conceitos da Grounded Theory (STRAUSS e CORBIN,
2008). O método Grounded Theory (GT ou Teoria fundamentada a dados) consiste em
um conjunto de procedimentos sistemáticos de coleta e análise dos dados para gerar,
elaborar e validar teorias substantivas sobre fenômenos essencialmente sociais, ou
processos sociais abrangentes (BANDEIRA-DE-MELLO e CUNHA, 2006). Este
método compreende três fases: aberta, axial e seletiva. A codificação aberta envolve a
quebra, a análise, a comparação, a conceituação e a categorização dos dados. Nesta fase,
o pesquisador explora os dados, examinando minuciosamente aquilo que lhe parece
relevante devido à leitura intensiva dos textos. Além disso, os incidentes ou eventos são
agrupados em códigos através da comparação incidente–incidente. Após a identificação
de categorias conceituais pela codificação aberta, a codificação axial examina as
relações entre as categorias que formam as proposições da teoria substantiva
(BANDEIRA-DE-MELLO e CUNHA, 2006).
Em relação ao escopo, foram selecionadas as conferências nacionais SBQS
(Simpósio Brasileiro de Qualidade de Software) e WAMPS (Workshop Anual do MPS)
e as internacionais PROFES (International Conference on Product-Focused Software
Process Improvement) e EuroSPI (European Software Process Improvement). Esta
escolha justifica-se, pois se tratam das conferências reconhecidas como as mais
relevantes, na área de SPI, no contexto brasileiro (SBQS e WAMPS) e internacional
(PROFES e EuroSPI). Em relação ao idioma, foram aceitos trabalhos escritos em
português, inglês e espanhol, pois são os idiomas aceitos para publicação nas
conferências selecionadas.
Foram identificados, ao todo, cerca de 1200 artigos, e, após aplicação dos filtros
permaneceram 100 artigos, sendo 43 referentes ao SBQS, 34 ao WAMPS, 12 ao
PROFES e 11 ao EuroSPI. Em relação à concentração de artigos selecionados ao longo
do tempo, cabe destacar que houve um crescimento considerável no número de
publicações entre 2005 e 2007. Isto pode ser explicado devido ao lançamento do
modelo MR-MPS-SW, que ocorreu em 2005. Outro fator que contribui para este
crescimento foi a realização dos eventos “Workshop de Instituições Organizadoras de
Grupos de Empresas (IOGE's) MPS.BR” e “Workshop de avaliadores MPS.BR” entre
os anos de 2006 e 2008.
Ao final da codificação aberta, foram obtidos ao todo 186 códigos referentes às
práticas, sendo 135 práticas gerenciais, 27 práticas de GC e AO e 24 ferramentas. O
passo seguinte foi realizar a codificação axial. Os 186 códigos gerados foram
182
enquadrados em 8 categorias, conforme Tabela 2, onde também é apresentada a
quantidade de práticas por categoria. Alguns códigos se enquadraram em mais de uma
categoria. As descrições e detalhes sobre cada categoria são descritas no Relatório
Técnico referente a esse artigo.
Tabela 2- Quantidade de Práticas por Categoria
# Descrição da Categoria Quantidade

de práticas
01 Estratégia de Implementação 39
02 Melhoria Contínua do Processo 18
03 Acompanhamento do Andamento das Atividades do Processo 18
04 Colaboradores Possuírem Competências Adequadas para Execução das Atividades 17
05 Definição, Validação e Padronização dos Processos e Procedimentos 21
06 Conscientização, Incentivo e Divulgação do Processo 38
07 Utilização de Ferramentas de Apoio 28
08 Contexto Organizacional 18
Em relação à categoria “Acompanhamento do Andamento das Atividades do
Processo” estão as práticas que visam acompanhar e monitorar o processo para que ele
seja conduzido corretamente durante o andamento das atividades da iniciativa de SPI.
Uma prática tipicamente utilizada é mentoring ou mentoria, que é uma técnica de
acompanhamento assistido, conhecida também como treinamento “on the job”. Esta
técnica é normalmente realizada pela consultoria para acompanhar os membros da
organização durante a utilização dos processos para dirimir dúvidas que possam surgir
em relação ao seu uso (MONTEIRO et al., 2008). Muito similares a esta prática existem
“Reuniões semanais para tirar dúvidas sobre o que está impedindo a execução do
processo ou tem impacto na produtividade de uma determinada atividade” e “Grupo de
Processos de Engenharia de Software (SEPG) atuar mais próximo da equipe de
desenvolvimento” (FERREIRA et al., 2005; MENDES et al., 2011).
No contexto ágil, a adoção de práticas relacionadas com acompanhamento do
andamento do processo também mostrou ser pertinente. SILVA et al. (2014) relatam
que a participação do Grupo de Qualidade como um real integrante do time de
desenvolvimento, durante as cerimônias Scrum, promoveu a aproximação do grupo de
qualidade junto às equipes de desenvolvimento e facilitou a institucionalização do
modelo de maturidade, combatendo então os fatores negativos “Falta de cultura de
metodologia da organização” e “Grupo de qualidade isolado das equipes de
desenvolvimento”, respectivamente.
No que tange a categoria “Incentivo, Divulgação e Conscientização do
Processo”, FERREIRA et al. (2005) destacam que um dos mecanismos motivadores
(fator negativo “Falta de motivação”) é incentivar as equipes através de relatórios
contendo indicadores de melhoria alcançados. PIRES et al. (2004) ressaltam que, para
combater a resistência das equipes em relação à adoção dos novos processos (fator
negativo “Cultura organizacional resistente a mudanças”), o artifício utilizado foi o
envolvimento da alta gerência motivando as equipes por meio de palestras e oficinas.
183
3.3. Auditoria das Práticas sob o Ponto de Vista de Especialistas em SPI
Finalizada a codificação, foram realizadas duas auditorias: a primeira consistiu em
avaliar se os códigos gerados refletiam corretamente o conteúdo das citações e, a
segunda, avaliar a coerência das associações entre os fatores negativos e as práticas
indicadas para tratamentos destes. As auditorias foram baseadas em diretrizes propostas
por BANDEIRA-DE-MELO e CUNHA (2010) e DUTRA (2015). Para evitar viés,
foram selecionados auditores que não participaram do mapeamento sistemático da
literatura, pois isso poderia influenciar nos resultados gerados.
Na primeira etapa da auditoria foram selecionados dois participantes, um com
mestrado acadêmico concluído e outro em andamento na área de SPI com pesquisa
voltada para análise qualitativa utilizando análise temática e GT. Além disso, os
auditores receberam uma planilha que continha todos os códigos gerados na codificação
aberta e espaço para indicar possíveis problemas identificados.
Ao final da primeira auditoria, foram identificados aproximadamente 15 erros de
codificação, ou seja, um número pouco significativo em relação ao total de códigos.
Entretanto, os auditores sugeriram diversas melhorias no texto dos códigos gerados,
criação de notas explicativas (memos) para justificar alguns códigos e foram discutidas
questões sobre os fatores críticos até que se chegasse a um entendimento comum.
Em relação à segunda parte da auditoria, o objetivo principal foi capturar a
percepção de especialistas em SPI em relação às associações entre as práticas e os
fatores negativos que foram realizadas durante a análise temática utilizando
procedimentos de GT. Nesta etapa foram selecionados também dois participantes: um
pós-doutorando com doutorado ligado a SPI, implementadora e avaliadora líder
intermediária credenciada do modelo de referência MR-MPS-SW e MR-MPS-SV e
membro de Instituição Implementadora e Avaliadora de melhoria de processos. O
segundo possui doutorado em Engenharia de Software com pesquisa voltada para
Engenharia de Software e Gerência do Conhecimento, docente e pesquisador e que já
ministrou disciplina de Gestão da Qualidade de Software. Além disso, possui
conhecimento comprovado no modelo MR-MPS-SW, além de ter participado de
implementações MR-MPS-SW.
Semelhantemente à auditoria 1, nesta etapa os auditores receberam dois
arquivos: um relatório, exportado da ferramenta Atlas.Ti2, que continha os fatores
críticos negativos e suas práticas correspondentes, e (ii) uma planilha contendo os
fatores críticos negativos e uma pergunta para avaliar a coerência das associações entre
os códigos.
Para cada um dos 41 fatores negativos, o auditor deveria responder o seguinte
questionamento “Existem elementos que levam a acreditar que a adoção das práticas (de
GC/AO, gerencial ou ferramenta) pode ser utilizada no tratamento do fator negativo?”.
Os auditores deveriam responder “Sim” ou “Não”, justificando o erro, caso ocorresse, e
dispunham de espaço para sugerir correções.
Ao final desta auditoria, foram obtidas diversas sugestões para as
recomendações indicadas para tratamentos dos fatores críticos. Os auditores apontaram
práticas que deveriam ser acrescentadas ou excluídas. Por exemplo, para o fator
2
Atlas.Ti é uma de análise qualitativa de dados (Site: atlasti.com)
184
negativo“Equipes diferentes de desenvolvimento não querem executar o processo da
mesma forma”, um dos auditores sugeriu incluir as práticas “Permitir adaptações no
processo padrão para cada projeto, respeitando as necessidades de cada projeto e as
adaptações permitidas pela empresa” e “Grupo de Garantia da Qualidade avaliar os
produtos gerados e a aderência ao processo”.
Em relação aos fatores negativos “Imposição do processo às pessoas que devem
executá-lo” e “Mudança de procedimentos de execução dos processos implementados”
foi sugerida a prática “Apresentar periodicamente para todos o andamento do projeto,
quais são os objetivos pretendidos e quais são os passos para o alcance das metas”. E
para “Alta rotatividade” foi indicada a prática “Existência de um processo padrão
formal para que todos adotem os mesmos procedimentos e estejam cientes de suas
responsabilidades”. As sugestões foram examinadas e o artefato sofreu as adaptações
necessárias.
4. Catálogo de Práticas para Tratamento de Fatores Críticos Negativos

4.1. Estrutura do Catálogo
Finalizados os ciclos de aprendizado incrementais apresentados nas seções anteriores, o
catálogo de práticas de GC e AO e ferramentas foi confeccionado de tal forma que
foram unificadas todas as práticas identificadas. Buscou-se gerar um instrumento com a
finalidade de apoiar as organizações, mais especificamente o grupo de processos ou
grupo responsável pela implementação, a tratar fatores negativos já existentes ou
mitigar fatores que possam vir a surgir no futuro.
Este catálogo também é útil para consultores de Instituições Implementadoras
(IIs) do modelo MR-MPS-SW, pois em determinados contextos, a equipe de processos
da organização pode não possuir o nível de experiência adequado para tomada de
decisão em situações negativas no decorrer do projeto de melhoria. Então, as
recomendações dadas pelo catálogo poderão nortear as ações dos consultores.
O Catálogo é formado por um total de 35 fichas, cada uma corresponde a um
fator crítico negativo. A Figura 2 apresenta uma das fichas, que é referente ao fator
crítico negativo “Equipes diferentes de desenvolvimento não quererem executar o
processo da mesma forma”.
Na primeira linha da ficha é apresentado o nome do fator crítico negativo, logo
abaixo, a categoria a que este fator pertence. Em seguida, são exibidos os 3 blocos
principais que formam o catálogo: “Práticas de GC e AO”, “Práticas gerenciais” e
“Ferramentas” que são indicadas para tratamento do fator. Em cada um dos blocos é
diferenciado se a prática teve ou não evidência de uso. As práticas que foram
classificadas em “Práticas com evidência de uso” são aquelas onde o autor da
publicação explicitou que houve uso de tal prática. O Relatório Técnico referente a esse
artigo apresenta a relação completa de todas as práticas com as respectivas referências e
evidências de uso. Abaixo dos blocos, são indicados os contextos onde as práticas foram
aplicadas (no exemplo em questão, CMMI-DEV nível 2 e 3 e MR-MPS-SW nível G e
F). Por último, são apresentadas as referências das práticas, ou seja, as fontes que as
respaldam.
185
Figura 2. Exemplo de ficha do Catálogo
No exemplo em questão, as práticas gerencias “Equipe de implementação
acompanhar os membros da organização durante o preenchimento dos artefatos” e
“Grupo de Garantia de Qualidade de Software institucionalizar o processo de revisão e
inspeção” são oriundas do 4° ciclo, então são indicadas as referências da literatura
“(Tavares et al., 2002; Mendes et al., 2011; Chiuki et al., 2014; Rocha et al., 2014)”. As
práticas de GC e AO “Wiki”, “Padronização dos produtos de trabalho” e “Atuação de
especialista” foram geradas a partir do Ciclo de aprendizado 02 e “Permitir adaptações
no processo padrão para cada projeto, respeitando as necessidades de cada projeto e as
adaptações permitidas pela organização” foi uma sugestão dada por um dos
especialistas no Ciclo de aprendizado 05.
4.2. Discussão sobre o Catálogo
A Figura 3 apresenta um mapa mental do Catálogo de forma sintetizada. Do lado
esquerdo encontram-se alguns dos fatores críticos negativos, e à direita parte das
práticas de GC e AO, práticas gerenciais e ferramentas para tratamento destes fatores.
Percebe-se que para alguns fatores, como “Alta rotatividade de pessoal”, não foram
identificadas ferramentas para tratar o fator.
186
Figura 3. Mapa mental sintetizado do Catálogo
Um ponto importante a se destacar em relação ao Catálogo é que algumas
práticas foram indicadas para mais de um fator negativo. Uma prática gerencial que se
enquadra nessa situação é “Execução de auditorias internas e/ou externas,
intermediárias e periódicas antes da avaliação oficial”. Em algumas publicações, autores
relatam que cada vez que essa prática era aplicada percebiam-se novas oportunidades de
melhoria no processo e os ajustes eram realizados no ciclo posterior, contribuindo então
para a adequação do processo (MARCZAK et al., 2003). Já em ROCHA et al. (2005),
notou-se elevação nos níveis de motivação ao realizar auditorias internas, pois foi
gerado um clima de competição saudável no qual todos fiscalizavam todos. Por outro
lado, em um contexto de desenvolvimento utilizando práticas ágeis identificou-se que
187
auditorias constantes provocaram maior atenção dos colaboradores em seguir os
processos (SILVA et al., 2014).
DRESCH et al. (2015) ressaltam que um dos fatores fundamentais para o
sucesso de uma pesquisa conduzida com DSR é a relevância da pesquisa para as
organizações. Dessa forma, após construção do catálogo, verificou-se a necessidade de
avaliá-lo sob o ponto de vista de organizações que participaram de uma iniciativa SPI.
Para isso, foram realizados dois estudos de caso em diferentes organizações para
analisar o catálogo de forma quantitativa e qualitativa. O participante do estudo teve
alto grau de envolvimento com os projetos de melhoria, tendo exercido o papel de
coordenador do grupo de processos e líder de qualidade. Após execução das entrevistas
e preenchimento de questionários, foi obtido um grau de 84% das práticas em relação às
iniciativas de SPI em questão.
Dessa forma, observa-se que o catálogo poderá auxiliar as organizações, mais
especificamente o grupo de processos ou grupo responsável pela implementação, a
tratar fatores negativos já existentes ou mitigar fatores que possam vir a surgir no
futuro. Este catálogo também é útil para consultores de IIs, pois em determinados
contextos, a equipe de processos da organização pode não possuir o nível de experiência
adequado para tomada de decisão em situações negativas no decorrer do projeto de
melhoria. Então, as recomendações dadas pelo catálogo poderão nortear as ações dos
consultores. O catálogo é útil também para a alta direção da organização, pois contém
diversas práticas que direcionam o alinhamento do projeto de melhoria com os objetivos
estratégicos da organização. Além disso, como as práticas potencializam as chances de
sucesso da iniciativa de SPI, então como consequência, aumentam-se as chances de a
organização obter vários benefícios, como aumento do lucro, ROI (retorno sobre o
investimento), aumento da satisfação dos clientes, entre outros.
As principais limitações deste trabalho são:
• Alguns fatores críticos negativos, como “Disputas internas (políticas) dentro da
organização a ser avaliada” e “Falta de abertura do líder de qualidade para ouvir
outras opiniões” não foram contemplados devido à sua natureza. Não foram
sugeridas práticas para estes fatores, pois envolvem variáveis difíceis de serem
controladas, como fatores políticos da organização ou fatores psicológicos de
membros da organização;
• Não considerar, no escopo do mapeamento sistemático da literatura, artigos
publicados de outros eventos, como ESELAW (Experimental Software
Engineering Latin America Workshop), AGILE (Agile Process in Software
Engineering and Extreme Programming), periódicos e journals como Software
Quality Journal, Journal of Systems and Software e Software Practice and
Experience.
5. Considerações Finais e Trabalhos Futuros

Tendo em vista que as organizações que desenvolvem software e implementam um
modelo de maturidade são suscetíveis a uma série de fatores e riscos que podem
prejudicar ou comprometer a iniciativa de melhoria, este trabalho se propôs a identificar
práticas que podem ser utilizadas para tratar estes problemas. Para isso, optou-se pela
metodologia DSR, onde foram realizados 6 ciclos de aprendizado incrementais, que
188
consistiram em cinco avaliações intermediárias e, por último, uma avaliação final para
obter a percepção de um membro responsável pela condução de uma iniciativa de SPI.
A principal contribuição deste trabalho foi a geração de um catálogo com 135
práticas gerenciais, 27 práticas de GC e AO e 24 ferramentas para tratamento de fatores
críticos de influência negativa. Este instrumento pode ser utilizado por organizações
desenvolvedoras de software como insumo para elaboração de um plano de ação (ou
plano de risco) durante a iniciativa de SPI. É recomendado que a organização tenha um
plano de gestão de riscos antes mesmo do início do projeto de melhoria (DUTRA,
2015).
Alguns possíveis trabalhos futuros incluem: (i) realizar experimentos para
verificar a efetividade de práticas que foram identificadas no catálogo, (ii) realizar
entrevistas com diversos implementadores e consultores credenciados pelo modelo de
referência MPS.BR para capturar opinião em relação aos resultados gerados no
catálogo, (iii) aplicar o estudo de caso em outras organizações que estejam planejando
ou executando uma iniciativa de SPI, e capturar a opinião não apenas de membros da
organização, mas também de consultores que participam (ou participaram) do projeto de
melhoria e (iv) incluir outras fontes no escopo do mapeamento sistemático da literatura.
Agradecimentos
Os autores agradecem à FAPERJ (projetos E-26/210.643/2016, E-211.174/2016) e à
UNIRIO (Edital PQ-UNIRIO no. 01/2016 e 01/2017) pelo apoio financeiro. O Segundo
autor agradece à UFMA através do Projeto PVCET201-2016.
Referências
BANDEIRA-DE-MELLO, R., CUNHA, C., 2006, "Grounded Theory". In: GODOI, C.K., BANDEIRA-DE-
MELLO, R., SILVA, A.B.D. (eds), Pesquisa Qualitativa em Estudos Organizacionais: Paradigmas,
Estratégias e Métodos, São Paulo, Saraiva.
BANDEIRA-DE-MELLO, R., CUNHA, C., 2010, “Grounded Theory”. In: GODOI, C. K., BANDEIRA-DE-
MELLO, R., SILVA, A.B. (eds), Pesquisa Qualitativa em Estudos Organizacionais: Paradigmas, Estratégias e
Métodos, Chapter 8, 2a ed, São Paulo, Saraiva.
BASILI, V., ROMBACH, H., 1988, “The Tame Project: Towards Improvement-Oriented Software Environments”,
IEEE Transactions on Software Engineering, v.14, n. 6, pp. 758-773
BAYONA, S., CALVO-MANZANO, J. A., FELIU, T. S. (2012) Critical Success Factors in Software Process
Improvement: A Systematic Review. 12th International Conference, SPICE 2012, Palma, Spain, May 29-31,
2012.
BAYONA, S., CALVO-MANZANO, J. A., FELIU, T. S. (2013). Review of Critical Success Factors Related to
People in Software Process Improvement. 20th European Conference, EuroSPI 2013, Dundalk, Ireland, June
25-27, 2013. Proceedings.
CMMI PRODUCT TEAM, 2010, CMMI® for Development (CMMI-DEV), V1.3, Software Engineering Institute.
Disponível em: http://cmmiinstitute.com/resources/cmmi-development-version-13. Acessado em 18 de
dezembro de 2015.
DRESCH, ALINE; LACERDA, D. P. ; ANTUNES JUNIOR, J. A. V. . Design Science Research: Método de
Pesquisa para Avanço da Ciência e Tecnologia. 1. ed. Porto Alegre: Bookman, 2015. v. 1. 181p
DUTRA, E. Riscos em iniciativas de melhoria de processos de software baseadas no MR-MPS-SW e no CMMI-
DEV: uma investigação no contexto brasileiro. 2015. XIV Simpósio Brasileiro de Qualidade de Software,
SBQS 2015, Manaus, AM .
FERREIRA, A. I. F., CERQUEIRA, R., ROCHA, A. R., et al. (2005) "Implantação de Processo de Software na BL
Informática - Um Caso de Sucesso". IV Simpósio Brasileiro de Qualidade de Software, SBQS 2005, Porto
Alegre, RS.
FUGGETTA, A. (2000) Software Process: A Roadmap, In: Proceedings of The Future of Software Engineering,
ICSE2000, Limerick, Ireland.
IANDOLI, L., G. ZOLLO, Organization cognition and learning: building systems for the leaning organization, Inf.
Sci. Publ. (2008).
189
KITCHENHAM, B. E CHARTERS, S., 2007, “Guidelines for performing Systematic Literature Reviews in Software
Engineering”, Technical Report EBSE 2007-001, Keele University and Durham University Joint Report,
2007.
MARCZAK, SABRINA; SÁ, L. ; CECCATO, I. ; AUDY, J. L. N. ; ANTUNES, D. . Uma proposta de organização e
funcionamento da função de Garantia da Qualidade de Software em um contexto de implantação do SW-
CMM. In: II Simpósio Brasileiro de Qualidade de Software, 2003, Fortaleza, CE. Anais do Simpósio
Brasileiro de Qualidade de Software. Fortaleza, CE: UNIFOR, 2003. p. 1-12.
MENDES, F. F., OLIVEIRA, J. L., FERNANDES, P. G., SOUZA, A. S. (2007) "Análise de Riscos na Implantação
de Melhorias de Processos de Software". In: ProQualiti - Qualidade na Produção de Software, v. 3, nro. 3, pp.
25-32, Nov/2007.
MENDES, F. F., ALMEIDA, J. N., ARRUDA JUNIOR, E. Experiência de Implantação de Melhoria de Processos de
Software em um Laboratório de Pesquisa. In: Workshop Anual do MPS, 2011, Campinas. VII Workshop
Anual do MPS - WAMPS 2011, 2011.
MENOLLI, ANDRÉ LUÍS ANDRADE; PINTO, H. SOFIA ; REINEHR, SHEILA ; MALUCELLI, ANDREIA .
SECOL: a semantic environment based on social media to support organisational learning. BEHAVIOUR &
INFORMATION TECHNOLOGY, v. 36, p. 1-26, 2016.
MONTEIRO, R. W., Cabral, R., Alho, F., et al. (2008) "O Esforço Requerido para Institucionalização de Processos
de Software na Prodepa". In: ProQualiti - Qualidade na Produção de Software, v. 4, nro. 2, pp. 65-72,
Out/2008.
MONTONI, M., 2010, Uma investigação sobre os fatores críticos de sucesso em iniciativas de melhoria de processos
de software, Tese de D.Sc., Universidade Federal do Rio de Janeiro - UFRJ, Rio de Janeiro, RJ, Brasil.
MONTONI, M. A., ROCHA, A. R., 2011, "Uma Investigação sobre os Fatores Críticos de Sucesso em Iniciativas de
Melhoria de Processos de Software". In: Proceedings of X Simpósio Brasileiro de Qualidade de Software, v.
1, pp. 1-15, Curitiba, PR.
NASIR, M.H.N.M., AHMAD, R., HASSAN, N.H., 2008, “Resistance factors in the implementation of software
process improvement project”, Telematics and Informatics v. 3, pp. IEEE, Kuala Lumpur, Malaysia
PARENTE, T. M. G., ALBUQUERQUE, A. B. (2008) "Domínio Informática: a qualidade como foco do seu Plano
Estratégico". In: ProQualiti – Qualidade na Produção de Software, v. 4, nro. 2, pp. 47-52, Out/2008.
PETERSEN, K., VAKKALANKA, S., KUZNIARZ, L., 2015, “Guidelines for conducting systematic mapping
studies in software engineering: An update”. Information and Software Technology, Num. 64, pp. 1–18.
PIRES, C. G., Marinho, F., Telles, G., Belchior, A. (2004) "A Experiência de Melhoria do Processo do Instituto
Atlântico Baseado no SW-CMM nível 2". III Simpósio Brasileiro de Qualidade de Software, SBQS 2004,
Brasília, Distrito Federal.
PORTO, Josiane Brietzke; PEREIRA, A. C. ; POHREN, Juliana . Proposta de Melhoria de Processos da SWB
Soluções Integradas usando o MR-MPS e a abordagem PRO2PI. ProQuality (UFLA), v. 4, p. 57-64, 2008.
RAS, E.; M. MEMMEL, S. WEIBELZAHL, Integration of E-Learning and Knowledge Management – Barriers,
Solutions and Future Issues, in: Proceedings of third Conference Professional Knowledge Management –
Experiences and Visions, Berlin, 2005.
ROCHA, Ana Regina ; MONTONI, Mariano ; SANTOS, G. ; MAFRA, Sômulo ; FIGUEIREDO, Sávio ;
ALBUQUERQUE, Adriano Bessa ; MIAN, Paula . Estação TABA: Uma Infra-estrutura para Implantação do
Modelo de Referência para Melhoria de Processo de Software. In: IV Simpósio Brasileiro de Qualidade de
Software, 2005, Porto Alegre - RS. Anais IV Simpósio Brasileiro de Qualidade de Software, 2005. p. 49-60.
SENGE, P.M., 1991, "The fifth discipline, the art and practice of the learning organization", Performance +
Instruction, v. 30, n. 5, pp. 37-37.
SILVA, N. V., Antiquera, P. R. S.,. Burity, E. R. Encontrando o Equilíbrio entre a Metodologia Scrum na Fábrica
JAVA e o modelo MPS.br- SW - nível F. In: Workshop Anual do MPS.BR, 2014, Campinas. X Workshop
Anual do MPS.BR (WAMPS 2014). Campinas - SP: SOFTEX - Associação para Promoção da Excelência do
Software Brasileiro, 2014.
SOFTEX, 2016, MPS.BR: Guia Geral MPS de Software, Disponível em: http://www.softex.br/mpsbr/guias/.
Acessado em 14 de janeiro de 2016.
STRAUSS, A., CORBIN, J., 2008, Pesquisa Qualitativa – Técnicas e Procedimentos para o desenvolvimento de
teoria fundamentada. 2a. Ed., Porto Alegre: Artmed e Bookman.
TIWANA, A. Knowledge Management Toolkit, Person Education, 2002.
VIANA, D., Conte, T., Vilela, D., et al., 2012, "The influence of human aspects on software process improvement:
Qualitative research findings and comparison to previous studies". In: EASE 2012, on, pp. 121-125, 14-15
May 2012.
VIANA, D. “FACILITANDO A APRENDIZAGEM ORGANIZACIONAL EM MELHORIA DE PROCESSO DE
SOFTWARE”. Tese de Doutorado - UNIVERSIDADE FEDERAL DO AMAZONAS – UFAM. Manaus,
Amazonas, Março de 2015.
VIRTANEN, P., PEKKOLA, S. and PÄIVÄRINTA, T. "Why SPI initiative failed: contextual factors and changing
software development environment."System Sciences (HICSS), 2013 46th Hawaii International Conference
On. IEEE, 2013.
WIERINGA, R., 2014, “Design Science Methodology for Information Systems and Software Engineering”, Springer
Heidelberg, ISBN 978-3-662-43839-8, 332pp.
190
A Software Measurement Pattern Language for
Measurement Planning aiming at SPC
Research Papers Track
Daisy Ferreira Brito1, Monalessa Perini Barcellos1, Gleison Santos2
¹Ontology and Conceptual Modeling Research Group (NEMO)

Computer Science Department, Federal University of Espírito Santo
Vitória – ES – Brazil
²Graduate Program on Information Systems –
Federal University of the State of Rio de Janeiro - UNIRIO – RJ – Brazil
{dfbrito, monalessa}@inf.ufes.br, gleison.santos@uniriotec.br
Abstract. The growing interest of organizations in improving their software
processes has led them to aim at achieving the high maturity, where statistical
process control (SPC) is required. One of the challenges to perform SPC is
selecting measures suitable for it. Measures used in SPC can be found in the
literature and could be reused by organizations, but information is disperse and
non-structured, not favoring reuse. This paper presents MePPLa (Measurement
Planning Pattern Language), a pattern language developed based on the findings
of a systematic mapping and a survey that investigated measures for SPC. An
initial evaluation of MePPLa showed that it favors reuse, contributes to
productivity in measurement planning and to the quality of the measurement plan.
1. Introduction
Software organizations have increased their interest in software process improvement
(SPI). There are several patterns and maturity models that support SPI implementation.
Some of them, such as CMMI (Capability Maturity Model Integration) [SEI 2010] and
MR-MPS-SW (Reference Model for Brazilian Software Process Improvement)
[Montoni et al. 2009], propose a SPI implementation in levels. At the highest levels
(CMMI levels 4 and 5 and MR-MPS-SW levels B and A) SPC is required.
For applying SPC, a good foundation is necessary, i.e., processes characterized
by appropriate measures and data that can be used to analyze processes behavior and
predictability. However, software organizations face many difficulties related to
defining measures suitable for SPC [Barcellos et al. 2013; Schots et al. 2014].
In the literature there are several works presenting measures that can be used in
SPC initiatives. These measures can be reused by organizations intending to carry out
SPC. However, selecting which measures are useful in a certain context is not trivial,
because information is disperse and non-structured, making access difficult, effort-
demanding and sometimes inefficient.
From a set of measures used in SPC initiatives, it is possible to identify some
patterns of measures used to monitor certain measurement goals and to perform
statistical control of certain processes. A pattern can be understood as a successful
solution to a recurrent problem [Deutsch et al. 2004]. Thus, patterns for measurement
planning present solutions to problems related to measurement planning, such as the
selection of measures to be included in a measurement plan.
191
Patterns can be organized into pattern languages, which represent patterns and
their relationships and also define a process that guides patterns selection and use. The
use of pattern languages favors reuse and, consequently, contributes to improve
productivity. In addition, since a pattern language provides a mechanism for selecting
patterns (for example, a flow that guides the user in patterns selection), even users
without much knowledge of the problem domain can be guided to the solution [Falbo et
al. 2013].
Considering the benefits provided by pattern languages, they can be useful in the
software measurement planning context. For example, they can assist organizations in
measurement plan elaboration through the reuse of measurement planning patterns.
Therefore, we developed MePPLa (Measurement Planning Pattern Language), a pattern
language that helps organizations to elaborate measurement plans suitable for SPC. In
MePPLa, each pattern is a solution composed of a measurement goal, a process to be
submitted to SPC, and measures to analyze the process behavior and monitor the
referred goal. The patterns were identified based on the results of a systematic mapping
study [Brito and Barcellos 2016] and a survey [Brito et al. 2017] that investigated
measures used in SPC.
This paper introduces MePPLa and is organized as follows: Section 2 provides
the background for the paper talking about software measurement, SPC and pattern
languages; Section 3 concerns the research method; Section 4 presents MePPLa;
Section 5 addresses MePPLa evaluation; and Section 6 presents final considerations.
2. Background
2.1. Software Measurement and Statistical Process Control
Software measurement is the continuous process of defining, collecting, and analyzing
data regarding software processes and products to understand and control them, as well
as supply meaningful information to their improvement [Solingen and Berghout 1999].
It is a primary support process for managing projects, and it is also a key discipline in
evaluating the quality of software products and the performance and capability of
organizational software processes [ISO/IEC 2007].
For performing software measurement, initially, an organization must plan it.
Based on its goals, the organization must define which entities (processes, products and
so on) are to be considered for software measurement and which of their properties (e.
g., size, cost, time, etc.) are to be measured. The organization has also to define which
measures are to be used to quantify those properties. For each measure, an operational
definition should be specified, indicating, among others, how the measure must be
collected and analyzed. Once planned, measurement can start. Measurement execution
involves collecting data for the defined measures, storing and analyzing them. Data
analysis provides information to decision making, supporting the identification of
appropriate actions. Finally, the measurement process and its products should be
evaluated to identify potential improvements [Barcellos et al. 2010].
There are some approaches in the literature to support measurement planning.
One of the best known is GQM (Goal-Question-Metric) [Basili et al. 1994], which
represents a systematic approach for tailoring and integrating goals to software
processes, products and quality perspectives of interest, based upon project and
organizational specific needs. To put it simply, GQM states that from goals it is possible
to identify information needs that can be met by measures. By following this idea, from
192
their goals, organizations can derive information needs and define measures able to
meet them.
Depending on the organization’s maturity level, software measurement is
performed in different ways. At initial levels (such as CMMI levels 2 and 3),
measurement consists in collecting data from projects and comparing them with their
corresponding planned values. At high maturity levels (such as CMMI levels 4 and 5), it
is also necessary to carry out SPC to get to know processes behavior, determine their
performance in previous executions, and predict their performance in current and future
projects, verifying if they can achieve the established goals [Barcellos et al. 2013].
SPC uses a set of statistical techniques to determine if a process is under control,
considering the statistical point of view. A process is under control if its behavior is
stable, i.e., if its variations are within the expected limits, calculated from historical data
[Florac and Carleton 1999]. The behavior of a process is described by data collected for
measures related to it [Barcellos et al. 2013].
A process under control is a stable process and, as such, has repeatable behavior.
So, it is possible to predict its performance in future executions and, thus, to prepare
achievable plans and to improve the process continuously. On the other hand, a process
that varies beyond the expected limits is an unstable process and the causes of these
variations (said special causes) must be investigated and addressed by improvement
actions, to stabilize the process. Once the processes are stable, their levels of variation
can be established and sustained, being possible to predict their results. Thus, it is also
possible to identify the processes that can achieve the established goals and the
processes that are failing in meeting the goals. In this case, actions to change the process
to make it capable should be carried out. Stabilizing their critical processes is a
characteristic of high maturity organizations or organizations that are looking forward to
achieving the highest maturity levels [Florac and Carleton 1999].
2.2. From Patterns to Pattern Languages
According to Deutsch et al. (2004), patterns are vehicles for encapsulating knowledge.
They allow capturing what must be done to solve a given problem. In order to use a
pattern it is necessary to recognize an opportunity to apply it, that is, it is necessary to
understand and recognize the context in which the recurrent problem treated by the
pattern occurs and to identify if the problem to be addressed is an instance of the
recurrent problem.
Buschmann et al. (2007) point out that many patterns found in the literature are
related to others, but most fail to explain how patterns can be combined to form
solutions to larger problems than those treated by each pattern individually. The
solution descriptions tend to concentrate on applying the patterns in an isolated way.
Thus, they do not properly solve problems that arise when several patterns are applied
in combination. This situation is problematic, since features introduced by one pattern
may be required by others. Therefore, a broader context is needed to describe the larger
problems that can be solved and those that can arise when patterns are used in
combination. This context can be provided by what is known in Software Engineering
as Pattern Language (PL).
A software pattern language is a network of interrelated patterns that defines a
process for systematically solving problems related to software development [Deutsch
2004]. This process aims to provide global support for patterns use in order to solve
problems related to a technical domain or some specific application. This holistic view
193
should provide explicit guidance on the problems that may arise in the domain, inform
the possible means of solving them and suggest one or more patterns to solve each
specific problem [Falbo et al. 2013].
Pattern languages reflect the fact that patterns tend to be strongly related and it is
difficult, or even impossible, to use them in isolation [Falbo et al. 2013]. In this sense,
in order for a PL to be effective in its goal of guiding the user on patterns application
and to properly address the combined application of several patterns, it is necessary that
relations between patterns are defined and made explicit in the PL.
Visual notations can be used to graphically represent PLs. The purpose of
adopting visual notations is to give an overview of the patterns and their relationships,
contributing to a holistic understanding of the PL and assisting in patterns selection
[Quirino 2016]. In this sense, Quirino (2016) proposes a cognitively rich visual notation
named OPL-ML (Ontology Pattern Language Modeling Language) for representing
pattern languages in the ontology engineering domain. Although proposed to represent
ontology pattern languages, OPL-ML can also be applied to represent PLs in other
domains, such as Software Engineering.
Regarding PLs related to software measurement, there are some proposals in the
literature. Andrade et al. (2010), for example, present a pattern language to support
estimates for software projects in micro and small enterprises. The language is intended
to assist the project manager in estimating a software project during the project planning
phase. For this, the patterns give guidance on what managers must do to collect actual
data and use them to support estimates and decision making. Based on the work by
Andrade et al. (2010), Braga et al. (2012) propose a pattern language for estimates in
agile projects. The language consists of eight patterns that can help agile teams to
perform estimates for agile software projects. Figure 1 illustrates the pattern language
proposed by Braga et al. (2012).
Figure 1 - Pattern Language for Software Estimates in Agile Projects

[Braga et al. 2012].
3. Research Method
The research method adopted in this work followed the Design Science Research
paradigm [Hevner 2004]. According to Hevner (2007), the Design Science paradigm
considers three cycles of closely related activities: Relevance, Design and Rigor.
The Relevance Cycle starts the research and defines the problem to be addressed,
the research requirements and the criteria to evaluate the results [Hevner 2007]. The
problem addressed in this work refers to the difficulty faced by software organizations
when planning measurement for SPC, especially when selecting the measures to be
considered. In order to understand the state of the art about measures used in SPC
initiatives or suggested for it, we investigated the literature through a systematic
mapping study [Brito and Barcellos 2016]. From the results we got some perceptions:
(i) prevalence of defect-related measures; (ii) lack of concern about relations between
measures; (iii) lack of approaches to support measures selection; and (iv) lack of
194
operational definitions for the measures. Considering the problem, the gaps identified
from the systematic mapping and the benefits of using pattern languages reported in the
literature, we noticed that the use of a measurement planning pattern language could
help organizations in developing measurement plans for SPC. Thus, we decided to
propose a pattern language for this purpose. As the main requirements, we established
that the pattern language should be able to guide users on selecting patterns to be
included in a measurement plan and should also represent relationships between
measures. In addition, the pattern language should be graphically represented. As
criteria for results evaluation, it should be considered the viability of using the pattern
language and its usefulness.
The Design Cycle refers to development and evaluation of artifacts or theories to
solve the identified problem [Hevner 2007]. As previously mentioned, the problem that
motivated this work is the difficulty of developing measurement plans for SPC. In order
to address it, we propose the use of a measurement planning pattern language. The
artifact proposed in this work is MePPLa (Measurement Planning Pattern Language), a
pattern language that provides patterns related to processes and composed of
measurement goal, information needs and measures suitable for SPC, which can be
reused to help measurement plans elaboration aiming at SPC. The patterns of MePPLa
were identified from the results of the systematic mapping [Brito and Barcellos 2016]
and from a survey conducted with some professionals to obtain information about the
state of the practice on measures used in SPC [Brito 2017]. To support the use of
MePPLa, we developed a tool. For evaluating MePPLa, we performed an experimental
study in which participants used the pattern language and provided their perceptions
about it.
Finally, the Rigor Cycle refers to knowledge use and generation. Rigor is
achieved through the adequate application of existing foundations and methodologies
[Hevner 2004]. A knowledge base is used to support the research and the knowledge
generated by the research contributes to the growth of the knowledge base [Hevner
2007]. In this work, the main theoretical foundations are knowledge related to
secondary studies (particularly, systematic mappings), software measurement, statistical
process control, pattern languages, and evaluation methods (particularly, experimental
study and survey). The main contributions to the knowledge base are the following: (i)
MePPLa, which can support organizations in measurement planning for SPC and can be
evolved to incorporate new patterns; (ii) the systematic mapping that consolidates
information about measures used in SPC initiatives or suggested for it, providing a
panorama of the research topic and indicating possible future research [Brito and
Barcellos 2016]; (iii) the survey conducted with professionals with experience in SPC,
providing information about measures that have been used in SPC initiatives in
Brazilian organizations [Brito 2017]; and (iv) the tool developed to support the use of
MePPLa.
4. MePPLa: A Measurement Planning Pattern Language

MePPLa is a pattern language with the purpose of helping measurement planning for
SPC. It currently comprises 26 patterns, of which 12 are related to the Project
Management process, 6 related to the Codification process and 8 related to the Testing
process. The MePPLa application context encompasses organizations that intend to
submit these processes (or some of them) to SPC, including CMMI level 3 or MR-
MPS-SW level C organizations that want to implement SPC practices for achieving
high maturity. In order to use MePPLa, the organization must have established its
195
organizational (business) goals, and identified the processes related to them and that
will be submitted to SPC. Thenceforth, the organization can use MePPLa to select, for
each process, the patterns to be included in the measurement plan.
As previously mentioned, MePPLa patterns were identified from investigative
studies into the literature [Brito and Barcellos 2016] and practice [Brito 2017]. These
studies investigated measures used in SPC as well as measurement goals and processes
related to the measures. As a result, 110 measures, 18 processes and 49 goals were
identified. Based on this set of measures, processes and goals, and taking the purpose
and context of use of MePPLa into account, we selected the Project Management,
Coding and Testing processes as the ones to be treated in the first version of MePPLa.
The Coding and Testing processes were both identified in the survey and in the
literature, being the Testing process the most cited in both studies. The Project
Management process, in turn, was identified only in the literature, but since it is
considered a suitable process for SPC, because it is usually a critical process and
executed in all projects, it was also selected to be treated in MePPLa. Once the
processes were selected, the measurement goals and measures related to them were
analyzed and patterns were extracted. The MePPLa patterns follow the GQM structure
[Basili et al. 1994], thus a measurement planning pattern has a measurement goal,
information needs derived from it and measures to meet the information needs
(including the operational definition of the measures).
During patterns extraction, we took some actions aiming to define patterns
suitable for the MePPLa scope. For instance, we disregarded very general measurement
goals such as gaining market competition, which is more a business goal than a
measurement goal, and understanding the software processes performance. We also
unified some similar or complementary measurement goals. For example, the goals
related to the Testing process Reducing the number of escaped defects and Improving
defect detection were unified in Improving test effectiveness. As for the measures, we
disregarded very specific measures with little potential for reuse, such as Percentage of
effort saved by process automation and Rate of effort spent on internal revision of tests
development.
Concerning the Project Management process, we extracted patterns related to
project planning and project monitoring and control. For the first, we identified patterns
to deal with estimates considering different granularities. We extracted patterns related
to effort, duration and cost estimates for activity, phase and process. Thus, when the
pattern language is applied, the user can choose which granularities s/he wants to
consider in the measurement plan. For the Codification process, we identified patterns
containing measures related to productivity, defect density and rework. As for the
Testing process, we extracted patterns related to delivery defects, detected defects and
effort spent on tests activities.
In order to refine the alignment between processes and related patterns, we
decomposed some processes. The Project Management process was decomposed into
Project Planning and Project Monitoring and Control, and the Testing process was
decomposed into Test Preparation and Test Execution.
For each identified pattern, we established a detailed description. Table 1 shows,
as an example, the description of the Test Preparation Productivity pattern. Due to
space limitation, we omitted part of the operational definition of the base measures.
196
Table 1 - Description of the Tests Preparation Productivity Pattern.
Test Preparation Productivity

Name: Test Preparation Productivity
Process / Sub-process: Tests / Test Preparation
Measurement Goal: Improve productivity in test preparation
Information Needs: What is the productivity in tests preparation?
Measures: Test Preparation Productivity, Number of Elaborated Test Cases, Test Preparation Effort.
Operational Definition of Measures:
Derived measure Test Preparation Productivity
Mnemonic TPP
Measure used to quantify productivity in the tests preparation, that is, the ratio between the number of
Description
test cases produced and the effort spent on test preparation.
Entity Tests Preparation sub-process
Property Productivity
Scale Positive real numbers accurate to two decimal places
Measurement unit Test Cases / Man-Hour
Formula (NPTC/ TPE)
Measurement Procedure Calculate productivity in test preparation using the formula for calculating the measure.
Measurement Periodicity The measurement must be performed for each execution of the Test Preparation sub-process.
<<indicate the role responsible for collecting data for the measure. It is recommended that the
Measurement Responsible
measurement responsible is the data provider (i.e., a role involved in tests preparation)>>
Measurement Moment At the end of each execution of the Test Preparation sub-process.
For process behavior analysis (organizational context):
- Represent in a control chart values collected for the measure in several projects.
- Obtain the process control limits and analyze the process behavior:
(i) If the values pass in the stability tests, then the process is stable and a baseline can be established.
Stability tests [WHEELER and CHAMBERS 2010]: Test 1: There is at least one point outside 3σ; Test :
there are at least two out of three successive points at the sa e side a d at ore tha σ fro the
central limit; Test 3: there are at least four out of five successive points at the same side and at more
tha σ fro the ce tral li it; Test 4: There are at least eight successive points at the same side.
(ii) If the values do not pass in the stability tests, the process is unstable. It is necessary to investigate
Measurement Analysis
the special causes, identify corrective actions and execute them.
Procedure
For quantitative project management (project context):
- Represent in a control chart values collected for the measure in the project.
- Analyze the process behavior considering the organizational behavior expected for it (i.e., by using the
process baseline as reference).
(i) If the values pass in the stability tests considering the process baseline as reference, then the
process behaved according to the behavior expected for it in the organization.
(ii) If the values do not pass in the stability tests considering the process baseline as reference, then the
process did not behave according to the behavior expected for it in the organization. It is necessary to
investigate the causes, identify corrective actions and execute them.
In the project context, the analysis must be performed once to each execution of the Test Preparation
Analysis Periodicity sub-process. In the organizational context <<indicate the periodicity based on a time period (e.g.,
fortnightly) or on an amount of new data collected (e.g., each 4 new values collected)>>
Analysis Responsible <<indicate the role responsible for analyze data collected for the measure>>
In the project context, the analysis must be performed after each execution of the Test Preparation sub-
Analysis Moment process. In the organizational context, analysis must be performed during the activity in which
organizational process behavior analysis is done <<indicate which is the activity in your organization >>.
Base Measure 1 Number of Prepared Test Cases
Mnemonic NPTC
Description Measure that quantifies the number of test cases elaborated in the test preparation.
Property Number of test cases
Unit of measurement -
Formula -
Measurement Procedure Obtain and record the number of test cases prepared in the test preparation.
… …
Base Measure 2 Test Preparation Effort
Mnemonic TPE
Description Measure that quantifies the test preparation effort.
Property Effort
Unit of measurement Man-hour
Formula -
Measurement Procedure Obtain and record the effort spent on the preparation of the tests, i.e., test cases preparation.
… …
Related Patterns: Test Preparation Efficiency.
197
According to Barcellos et al. (2013), ideally, the operational definition of a
measure used in SPC should include: name, description, mnemonic, measured property,
measured entity, scale, measurement unit, formula, measurement procedure,
measurement responsible, measurement periodicity, measurement moment,
measurement analysis procedure, measurement analysis responsible, measurement
analysis periodicity, and measurement analysis moment (for base measures that
compose derived measures and are not directly analyzed, it is not necessary to provide
information about measurement analysis). Considering that MePPLa contains patterns
to be used by different organizations, there are pieces of information that cannot be
predefined, and, thus, are not included in the patterns descriptions and must be
completed when applying a pattern (i.e., when including it in a measurement plan). For
these pieces of information, the pattern provides some guidelines (shown in Table 1 in
italics and delimitated by << >>) aiming to help organizations to complete the
operational definition of the selected measures.
Once the patterns were defined, we developed models for graphically
representing the pattern language. We used OPL-ML [Quirino 2016] as modeling
language for representing MePPLa. According to OPL-ML, a pattern language must
have the structural and behavioral perspectives separately represented. Thus, MePPLa is
composed of two types of models, the structural model, which represents the patterns
and the structural relations between them, and the behavioral model, which describes
the process for selecting and applying the patterns.
The structural model provides information about structural relations (e.g.,
dependence and composition), which are especially useful during measurement
analysis, since they reveal related measures and goals that impact on others. This model
can also be useful in measurement planning by helping identify which patterns can be
selected for a better analysis of goals achievement and identification of causes that may
be interfering with it. During MePPLa development, the structural model was useful for
us to develop the behavioral model, since the structural model indicates the
dependencies that must be considered in the flows that guide patterns selection. Figure 2
presents the structural model containing patterns related to the Testing process.
Figure 2 - Structural model of the Testing Pattern Group

In MePPLa two types of structural relations are used: dependence, when a
pattern requires the application of another, and correlation, which was added to the
notation provided by OPL-ML to indicate patterns whose measures are correlated, but
the patterns are not dependent. For example, the measure requirements change rate is
198
correlated to amount of rework, since many changes in requirements may impact the
amount of rework. However, a pattern including the measured amount of rework does
not depend on the application of the pattern containing the measure requirements
change rate to be applied (and vice-versa). As Quirino (2016) suggests, patterns can be
organized into groups. In MePPLa, patterns were grouped considering the processes and
sub-processes to which they relate.
As shown in Figure 2, there are only correlation relations between patterns from
the Testing group. For example, Test Efficiency is correlated to Test Effectiveness; since
improvements in test effectiveness may impact test efficiency (more effective tests may
require more effort). The structural model for Testing has two subgroups, one related to
the Test Execution sub-process and another related to the Tests Preparation sub-process.
The behavioral model (or process model) has two formats: the black box format,
which provides a general view of the pattern language from the behavioral perspective;
and the detailed format, which provides a detailed view of the pattern language process,
containing the flows that guide patterns application. Both formats must be understood
as a process to be followed step by step, from an entry point to an end point. Figure 3
shows the behavioral model of MePPLa in the black box format. In this format it is
possible to see the processes treated in MePPLa, since the pattern groups refer to the
processes addressed by MePPLa. As the name suggests, in the black box format it is not
possible to visualize the patterns and flows within each group.
Figure 3 – Black-box format of the behavioral model

For each pattern group (i.e., for each process) we developed a detailed
behavioral model presenting the group internal content, i.e., its patterns and flows
between them. Figure 4 shows the detailed behavioral model of the Testing process.
Due to space limitations, detailed behavioral models of other processes are not
presented in this paper.
The detailed behavioral models are consistent with the structural model. Thus,
the patterns are grouped according to the processes and sub-processes to which they
relate. Patterns are connected by flows to guide users in patterns selection, respecting
the relationships between the patterns defined in the structural model (for example, if in
the structural model a pattern A depends on a pattern B, in the behavioral model the
user is guided to apply B before A). To navigate the model, the user must choose an
entry point according to the measurement goal to be considered in the measurement
plan. For example, in Figure 4, if the measurement goal Improve test effectiveness and
efficiency is relevant, the user should start navigation from EP1. If this measurement
goal is not relevant and Improve test preparation performance is, then the user should
start navigation from EP2. Note that if the user starts navigation from EP1, s/he will
also be guided to the patterns related to Improve test preparation performance and, by
following the flows, s/he can decide if they are relevant or not. From an entry point, the
user must follow the flows and select the patterns according to the goals that s/he wants
to treat in the measurement plan. When a pattern is applied, it means that its description
is to be included in the measurement plan.
199
Figure 4 - Behavioral model of the Testing Pattern Group.
The full specification of MePPLa can be found in [Brito 2017]. To support the
use of MePPLa, we developed a tool1 that allows users to navigate the behavioral
models and select the patterns they want to include in their measurement plans. As a
result, a file containing the detailed descriptions of the selected patterns is produced.
Information recorded in the file can be extracted and included in the organization's
measurement plan or organizations can edit the file and turn it into a measurement plan.
5. MePPLa Evaluation
As a first evaluation of MePPLa, we conducted a study to evaluate whether MePPLa is
useful to software measurement planning for SPC and whether its use is feasible. Using
the GQM approach [Basili et al. 1994] this goal is formalized as follows: Analyze
MePPLa, with the purpose of evaluating the pattern language, with respect to its
usefulness in software measurement planning aiming at SPC and feasibility of use, from
the point of view of software measurement professionals, in the context of software
projects. To analyze the results, we considered the following indicators: (i) adequacy of
the result obtained from the use of MePPLa; (ii) MePPLa usefulness; and (iii) benefits
provided by MePPLa.
The instrumentation used in the study consists of three forms: (i) a consent form,
in which participants declared to accept participating in the study; (ii) a form to
characterize the participants profile, aiming to obtain information about the participants'
knowledge and experience in software measurement, SPC and pattern languages; and
(iii) a questionnaire to capture the participants’ perceptions about MePPLa.
The procedure adopted in the study consisted in sending to the participants a
document containing information about MePPLa and the supporting tool. Based on the
instructions provided in the document, participants used the tool and, then, answered the
questionnaire (iii).
The questionnaire included questions related to MePPLa usefulness, adequacy
of results obtained from the use of MePPLa, quality of the produced result, and
productivity of the measurement planning activity. The questionnaire contained
1
The tool is available in http://dev.nemo.inf.ufes.br:8180/MPPL/login.faces.
200
objective questions and a discursive one. For the objective questions, we asked the
participant to provide a justification for the given answer. The discursive question
aimed at the general evaluation and improvement of MePPLa.
The study participants were three professionals with experience in SPC
implementation or evaluation in software organizations (CMMI and MR-MPS-SW
appraisers or implementers) and one graduate student. Among the participants, two
declared medium knowledge of software measurement and SPC, and two declared high
knowledge. Concerning practical experience in measurement planning and SPC, two
participants declared high experience, one declared medium and one participant
declared low experience. As for the experience with pattern languages, two participants
declared high experience, one declared low experience and one reported that the use of
MePPLa it would be the first experience with pattern languages. Next, we present the
results and some discussions related to each of the three indicators used in the study.
(i) Adequacy of the result obtained from the use of MePPLa
The use of MePPLa results in a set of measurement goals, information needs
and measures (plus operational definition) related to processes to be submitted to SPC.
As previously said, this set can be included in a measurement plan or can be turned into
one by adding complimentary information not provided by the patterns. Three
participants reported that the result is adequate and one participant considered it
inadequate. The participant who considered the result inadequate justified that it was
due to lack of detailed information in the operational definition of measures and absence
of business goals.
Regarding the operational definition of measures, since the patterns defined in
MePPLa are to be used by several organizations, some pieces of information cannot be
predefined because they depend on the organization for which the measurement
planning is performed. For these pieces of information, the pattern provides guidelines
to help organizations to complete the operational definition. Even so, after the study,
considering the participant feedback, we reviewed the operational definitions of
measures and made changes to improve them.
As for the business goals, as previously explained, they must be established
before using MePPLa. Based on the business goals, it is necessary to identify the related
processes to be submitted to SPC and, henceforward, using MePPLa to apply patterns
related to the processes.
(ii) MePPLa usefulness
Three participants considered MePPLa useful or very useful. However, although
considering the patterns useful, one participant found MePPLa useless and justified
their perception in the difficulty to change information in the operational definition of
measures and to include new measures into the resulting measurement plan.
It is possible to notice that the justification given by the participant is directly
related to limitations of the supporting tool and not to MePPLa itself. We took the
participant feedback into account and improved the tool accordingly.
(iii) Benefits provided by MePPLa
All participants considered that MePPLa contributes to the reuse of measures
and measurement goals, being aligned with ―favoring reuse‖, which is one of the
expected benefits of using pattern languages. Three participants emphasized that they
were properly guided in selecting measures that should be in the measurement plan.
201
Also, two of the three participants who had previous experiences elaborating
measurement plans for SPC reported that MePPLa makes the measurement planning
much more productive or more productive. One participant reported that MePPLa made
the activity less productive, due to limitations to edit the operational definition of
measures. As discussed earlier, this limitation refers to the supporting tool rather than to
MePPLa and it was addressed after the study.
All participants considered MePPLa very easy or easy to use. Three of them
highlighted that MePPLa contributes to the quality of the measurement plan, since the
patterns provide well-defined measures and only particularities have to be addressed by
the organizations. One participant believes that MePPLa contributes partially to the
quality of measurement plan, because some aspects such as business goals are not
included in the patterns. As mentioned before, organizational goals must be established
before using MePPLa.
By analyzing the results and comments made by the participants it is possible to

notice that most of the limitations pointed out refer to the supporting tool. In fact, the
participant who considered MePPLa useless made it clear in a comment that the critics
did not refer to MePPLa, but to the supporting tool. Thus, we believe that the tool
limitations influenced MePPLa evaluation. Even so, considering the results as a whole,
we can understand them as preliminary evidence that MePPLa is easy to use, it is
useful, provides benefits in terms of quality and productivity, and is capable of
producing adequate results.
5.1. Threats to Validity
Every study presents threats to the validity of its results. Threats should be addressed as
much as possible and should be considered together with the results obtained in the
study. Following the classification presented by Wöhlin et al. (2000), next we discuss
the main threats to the study results.
Internal Validity: It is defined as the ability of a new study to repeat the behavior
of the current study with the same participants and objects. The main threat to internal
validity is communication and sharing of information among participants. To address
this threat, we sent the document with instructions for evaluating MePPLa to the
participant's personal email, so that s/he could individually use the tool and answer the
questionnaire at the time s/he considered most appropriate. This can minimize the threat
of communication, since participants are not physically close during the study and do
not perform the study at the same time.
External Validity: This threat is related to the ability to repeat the same behavior
with different groups from the one that participated in the study. In this context, we
identified as a threat the short time participants had to perform the evaluation (less than
a week). It is possible that different results are obtained with participants who have
more time to perform the evaluation. Another threat refers to the fact that the
participants did not use MePPLa in real projects. Evaluating MePPLa with participants
using it in real projects may provide different results.
Construction Validity: Refers to the relationship between the study instruments
and participants and the theory being tested. We identified as a threat the possibility of
the participants give answers that do not reflect the reality due to personal expectations
or to imagine that they were being evaluated. To minimize this threat, we informed the
participants that the study does not represent any type of personal assessment and aims
to evaluate MePPLa. Moreover, we ensured the participants anonymity. Another threat
202
concerns the document made available to the participants. The document should provide
the necessary information for participants to evaluate MePPLa (i.e., information about
MePPLa and the tool). We sought to produce a simple and small documentation that did
not require much time from the participants. However, in doing so, important
information about MePPLa and its use, which could impact on the evaluation results,
may not have been included or not being sufficiently clear (e.g., it seems that the need
of establishing the business goals before using MePPLa was not clear for one
participant). We also considered a threat the use of the supporting tool to evaluate
MePPLa. By using the tool, participants evaluated not only MePPLa, but also aspects
related to the tool itself. Evaluating MePPLa by using only its specification document
may produce different results.
Conclusion Validity: It measures the relationship between the treatments and the
results and affects the ability of the study to generate conclusions. In this context the
main threats are: (i) small number of participants; (ii) short period for evaluation; (iii)
supporting tool limitations and (iii) MePPLa was not used in real projects. These threats
limit results generalization, thus they should be considered preliminary results.
6. Final Considerations
The importance of SPC for the software industry has increased in recent years due to the
interest of organizations in achieving high maturity [Fernandez-Corrales et al. 2013].
The use of SPC allows getting know the processes behavior and predicting their
performance.
Process stability, measurement capacity and data reliability are critical issues for
a successful implementation of SPC. In other words, if the process is consistently
performed, if the correct measures are selected and a reliable data collection mechanism
is established, it is possible to obtain the benefits provided by SPC [Abubakar and
Jawawi 2013]. Selecting measures suitable for SPC has been pointed as one of the
difficulties when implementing SPC in software organizations. The literature cites
several measures for it, but information is disperse and non-structured. Moreover,
usually there are no guidelines on which measures should be selected in a given context.
Reusing measures applied in SPC initiatives can help select measures
appropriate for this purpose. Extracting measurement patterns from previous SPC
initiatives can contribute to reuse and assist organizations in measurement planning for
SPC. Considering that, we proposed MePPLa (Measurement Planning Pattern
Language), a pattern language to help measurement planning aiming at SPC.
In the context of this work, we investigated the state of the art on measures used
in SPC initiatives by carrying out a systematic mapping [Brito and Barcellos 2016]. We
identified some gaps, such as: (i) lack of approaches to select measures suitable for
SPC; (ii) absence of operational definition of measures; and (iii) lack of concern with
related measures. These gaps are addressed in MePPLa, since: (i) MePPLa provides a
flow that guides the user in selecting patterns containing measures; (ii) MePPLa
provides operational definitions for the measures included in the patterns; (iii) MePPLa
has a structural model in which information about the structural relationships between
patterns reveals correlated measures and goals that impact on others.
Comparing MePPLa with the pattern languages proposed in [Andrade et al.
2010; Braga et al. 2012] and presented in Section 2, some important differences can be
highlighted: (i) the pattern languages do not address SPC; (ii) the patterns of these
pattern languages provide guidelines for project planning, while MePPLa provides
203
patterns based on the GQM format and using them helps measurement planning aiming
at SPC; (iii) the patterns of the pattern languages do not provide operational definition
of measures; (iv) the pattern languages do not use a cognitively rich visual notation; and
(v) these pattern languages do not separate the structural and behavioral perspectives.
It is worth pointing out that the version of MePPLa addressed in this paper is a
first version, which considers three processes and has a limited number of patterns.
Pattern languages may be always evolving, for example, having new patterns added and
new relationships identified. Thus, as a pattern language, MePPLa can be extended to
include new patterns and handle new processes.
Among the limitations of this work, we can highlight MePPLa evaluation, which
involved a small number of participants, in a very short period of time and outside an
organizational context. In addition, limitations of the supporting tool used in the
evaluation influenced the results.
As future work, we plan to conduct new studies for better evaluating MePPLa,
to evolve MePPLa to treat other processes and include other patterns, and to improve
the supporting tool to favor the use of MePPLa by organizations.
Acknowledgements
This research is funded by the Brazilian Research Funding Agency CNPq (Process
461777/2014-2) and FAPES (Process 69382549/2014), FAPERJ (projects E-
26/210.643/2016, E- 211.174/2016) and UNIRIO (grant PQ-UNIRIO 01/2016 e
01/2017).
References
Abubakar, A. M. and Jawawi, D. N. A. (2013). A Study on Code Peer Review Process
Monitoring using Statistical Process Control. Software Engineering Postgraduates
Workshop (SEPoW), p. 136–141.
Andrade, T. de C., Freitas, F. G. de, Andrade, R. M. de C., Souza, J. T. de. (2010).
Software Estimation Patterns applied at a Small Enterprise. Proceedings of the 8th
Latin American Conference on Pattern Languages of Programs. Article No. 15.
Salvador, Bahia, Brazil (in Portuguese only).
Barcellos, M. P., Falbo, R. A., Rocha, A. R. (2010). Establishing a well-founded
conceptualization about software measurement in high maturity levels. In Proc. of
the 7th International Conference on the Quality of Information and Communications
Technology, p. 467–472.
Barcellos, M. P., Falbo, R. A., Rocha, A. R. (2013). A strategy for preparing software
organizations for statistical process control. Journal of the Brazilian Computer
Society, v. 19, n. 4, p. 445–473.
Basili, V. R., Rombach, H. D., Caldiera. (1994). G. Goal Question Metric Paradigm,
Encyclopedia of Software Engineering, 2 Volume Set, John Wiley & Sons, Inc.
Braga, M.R.R., Bezerra, C.I.M., Monteiro, J.M., Andrade, R. (2012). A pattern
language for agile software estimation. Proc. of the 9th Latin-American Conference
on Pattern Languages of Programming. Natal, RN, Brazil.
Brito, D. F., Barcellos, M. P. (2016). Measures Suitable for SPC: A Systematic
Mapping. Proc. Of the XV Brazilian Symposium on Software Quality, Maceió – AL,
Brazil.
204
Brito, D. F. (2017) Linguagem de Padrões para apoiar o Planejamento de Medição para
o Controle Estatístico de Processos de Software. Dissertação de Mestrado, Programa
de Pós-Graduação em Informática, Universidade Federal do Espírito Santo, ES,
Brasil (in Portuguese only).
Buschmann, F., Henney, K., Schimdt, D. (2007), Pattern-oriented Software
Architecture: On Patterns and Pattern Language. John Wiley & Sons Ltd.
Deutsch, P. (2004). Models and Patterns. In: J. Greenfield; K. Short; S. Cook; S. Kent
(Orgs.); Software Factories: Assembling Applications with Patterns, Models,
Frameworks, and Tools. Indianapolis: John Wiley & Sons.
Falbo, R. A., Barcellos, M. P., Nardi, J. C., Guizzardi, G. (2013). Organizing ontology
design patterns as ontology pattern language. Proc. of the 10th Extended Semantic
Web Conference - ESWC. Montpellier, France.
Fernandez-Corrales, C., Jenkins, M., Villegas, J. (2013). Application of Statistical
Process Control to Software Defect Metrics: An Industry Experience Report. ACM /
IEEE International Symposium on Empirical Software Engineering and
Measurement, p. 323–331.
Florac, W. A. and Carleton, A. D. (1999). Measuring the Software Process: Statistical
Process Control for Software Process Improvement. Pearson Education.
Hevner, A. R. A. (2007). Three Cycle View of Design Science Research. Scand. J. Inf.
Syst. 19, 87–92.
Hevner, A.R., March, S.T., Park, J., Ram, S. (2004). Design Science in Information
Systems Research. 28, 75–105.
ISO/IEC (2007). ISO/IEC15939—Systems and Software Engineering—Measurement
Process.
Montoni M, Rocha AR, Weber KC (2009) MPS.BR: A Successful Program for
Software Process Improvement in Brazil. Software Process Improvement and
Practice 14:289-300.
Quirino, G. K. S. (2016). Uma Notação Visual para Representação de Linguagens de
Padrões Ontológicos. Dissertação de Mestrado, Programa de Pós-Graduação em
Informática, Universidade Federal do Espírito Santo, ES, Brasil (in Portuguese only).
Rocha, A. R. C. da, Souza, G. dos S. and Barcellos, M. P. (2012). Medição de Software
e Controle Estatístico de Processos, Ministério da Ciência, Tecnologia e Inovação -
SEPIN - PBQP Software, Brasília – Brasil, ISSN 1679-1878 (in Portuguese only).
Schots, N., Rocha, A. and Santos, G. A (2014) Body of Knowledge for Executing
Performance Analysis of Software Processes. SEKE, pp 560-565.
SEI (2010). CMMI for Development, Version 1.3. Carnegie Mellon University.
Solingen, R., Berghout, E. (1999). The Goal/Question/Metric Method: a practical guide
for quality improvement of software development. New York: McGraw-Hill
Publishing Company.
Wheeler, D. J., Chambers, D. S. Understanding Statistical Process Control. 2nd ed.
Knoxville - SPC Press, 1992.
Wöhlin, C., Runeson, P., Höst, M., Ohlsson, M., Regnell, B., Wesslén, A. (2000).
Experimentation in Software Engineering: An Introduction. The Kluwer
International Series in Software Engineering, Norwell, USA, Kluwer Academic
Publishers.
205
Estimativa de Projetos de Aplicativos Móveis: Um
Mapeamento Sistemático da Literatura
Ervili T. B. de Souza¹, Tayana Conte¹
1
Grupo de Pesquisa em Usabilidade e Engenharia de Software (USES) – Instituto de
Computação - Universidade Federal do Amazonas (UFAM)
Av. Rodrigo Otávio, nº 6.200. CEP: 69077–000, Manaus – AM – Brasil
{etbs, tayana}@icomp.ufam.edu.br
Abstract. Mobile applications have needs and characteristics different from

other information systems. These characteristics are factors that influence the
effort estimation. In this context, this paper presents a systematic literature
mapping about characteristics of effort predictor factors and estimation
models for mobile application projects. As a result, we identified five models
for size estimation, three models for effort estimation, three models for
estimating size and effort together and ninety-three predictor factors. From
the results, we conclude that there is no standardization of effort predictor
factors that support professionals to estimate.
Resumo. As aplicações móveis têm necessidades e características diferentes

em relação aos demais sistemas de informação. Essas características são
fatores que influenciam a estimativa de esforço. Neste contexto, este artigo
apresenta um mapeamento sistemático da literatura que caracteriza fatores
preditores de esforço e modelos de estimativa voltados para projetos de
aplicativos móveis. Como resultado, foram identificados cinco modelos para
estimar tamanho, três modelos de esforço, três modelos para estimar tamanho
e esforço em conjunto e noventa e três fatores preditores. A partir dos
resultados, conclui-se que não há uma padronização dos fatores preditores de
esforço que apoie os profissionais a estimar aplicativos móveis.
1. Introdução
A eMarketer (2016) estima que existam mais de 2,16 bilhões de clientes móveis em
todo o mundo, ou seja, mais de um quarto da população mundial utiliza smartphones,
prevendo um maior crescimento no uso desta tecnologia nos próximos anos. Com a
evolução dos dispositivos móveis, os usuários foram motivados a incorporar os
aplicativos aos seus dispositivos para ajudá-los a realizar suas atividades diárias, como
comunicação, negócios, esportes, educação e notícias.
Um aplicativo móvel é definido como o aplicativo desenvolvido para a geração
atual de dispositivos móveis, popularmente conhecidos como smartphones
[NAGAPPAN 2016]. De acordo com Dombroviak e Ramnath (2007), as aplicações
móveis têm necessidades e características diferentes que os sistemas de informação
tradicionais, tais como: centricidade (coleta de dados ou execução de ações em resposta
206
ao ambiente), consciência de localização absoluta (usam tipicamente métodos como
GPS ou triangulação de sinal), consciência de aproximação (sensibilidade de
aproximação de determinado objeto e espaço), consciência de espaço (o dispositivo está
dentro da área de limite definido de lugares, exemplos: edifícios, prédios e etc.) e
consciência de transição (o grau em que o comportamento de uma aplicação depende do
conhecimento de transições entre espaços). Além dessas, De Souza e Aquino (2014)
complementam com as seguintes características: consumo de bateria, tipos de
conectividade, fator de desempenho e outros. Segundo Nitze et al. (2014), essas
características são fatores influentes (ou restrições) que modificam a estimativa de
esforço, devido a isto, determinados processos como a estimativa de esforço devem ser
adaptados para este novo contexto. Os processos de estimativa são baseados em
características de sistemas que quantificam a complexidade de implementá-los [DE
SOUZA e AQUINO 2014].
Considerando a importância que o desenvolvimento de aplicativos móveis
desempenha na indústria de hoje e suas diferentes características comparada a sistemas
de software em geral, um mapeamento sistemático da literatura é importante para
estabelecer o estado atual de como é realizada a estimativa de esforço de aplicativos
móveis. Este mapeamento sistemático foi orientado a identificar, avaliar e interpretar
todas as pesquisas disponíveis relevantes [KITCHENHAM e CHARTES 2007].
Além desta seção introdutória, as seções seguintes deste artigo estão organizadas
da seguinte forma: A Seção 2 apresenta o referencial teórico sobre conceitos de
estimativa de projetos. A Seção 3 detalha o protocolo do mapeamento sistemático e o
método de pesquisa utilizado. A Seção 4 apresenta os resultados do mapeamento para
cada questão de pesquisa. A Seção 5 discute os resultados encontrados sobre estimativa
de tamanho, esforço e fatores preditores de esforço de aplicativos móveis. Por fim, a
Seção 6 apresenta conclusões e trabalhos futuros.
Segundo Mendes (2014), estimar em Engenharia de Software consiste em prever prazo,
recurso e esforço necessários para desenvolver um conjunto de tarefas do ciclo de vida
de um projeto de software. Abreu (2011) divide a estimativa de projetos de software em
três tipos:
• Estimativa de Tamanho - Grandeza física medida através dos requisitos, análise
e projeto ou código do software com base nas suas funções e complexidade do
problema.
• Estimativa de Esforço - Trabalho necessário para o desenvolvimento do projeto
obtido a partir da estimativa de tamanho.
• Estimativa de Prazo - Tempo necessário para o desenvolvimento do projeto
obtido a partir da estimativa de esforço e quantidade de recursos envolvidos no
projeto
Mendes (2014) divide as categorias de estimativa em três tipos: estimativa
baseada por especialistas que é o processo de estimativa fundamentada na experiência
no desenvolvimento ou gestão de projetos anteriores, técnicas algorítmicas que
207
constroem modelos que representam precisamente a relação entre esforço e
características do projeto através do uso de modelos algorítmicos (um exemplo é o
COCOMO [BOEHM 1981]) e técnicas de inteligência artificial que são usadas como
um complemento para as duas categorias anteriores. Além disso, Mendes (2007) afirma
que fatores preditores de esforço são métricas de tamanho e fatores de custo.
Em relação a estimativa de aplicativos móveis, De Souza e Aquino (2014)
realizaram uma revisão sistemática da literatura sobre as características das aplicações
móveis. Do conjunto de 234 artigos identificados, 40 foram aceitos por meio dos
critérios definidos por eles e 29 características foram extraídas. Depois, os autores
realizaram um refinamento dessas características por meio de um survey nas
universidades e empresas que desenvolvem aplicativos móveis com a finalidade de
ratificar as características previamente levantadas e para provar sua respectiva influência
sobre o desenvolvimento móvel, resultando em 13 características. Porém, o foco deste
mapeamento sistemático é investigar como é realizada a estimativa de aplicativos
móveis e não em características especificas de aplicativos móveis. A seção a seguir
apresenta o protocolo do mapeamento sistemático da literatura realizado pelas autoras
deste artigo.
3. Mapeamento Sistemático da Literatura
3.1. Questões de Pesquisa

Uma abordagem para a formulação das questões de pesquisa é utilizar os critérios
especificados pelo PICOC [KITCHENHAM E CHARTERS 2007] que investiga as
estruturas das perguntas de acordo com cinco atributos: população, intervenção,
comparação, resultados e contexto. No entanto, o foco deste mapeamento da literatura é
caracterizar intervenções, logo os atributos de comparação não serão utilizados e,
portanto, apenas atributos como a população, intervenção e resultado (PIO) serão
considerados. A Tabela 1 mostra os detalhes.
Tabela 1. Questões de investigação estruturadas pelos critérios do PIO
População Projetos de Aplicativos Móveis
Intervenção Métodos / técnicas/ modelos utilizados para a estimativa de tamanho e/ou
esforço para aplicativos móveis, fatores preditores considerados.
Resultado Métodos / técnicas/ modelos utilizados para aplicativos móveis e fatores
preditores.
A questão de pesquisa foi formulada para que pudesse abranger todo o escopo de
estimativa de projetos de aplicativos móveis em Engenharia de Software. Neste
contexto, a questão de pesquisa deste mapeamento sistemático é a seguinte: “Como é
realizada a estimativa de projetos de aplicativos móveis? ”. A partir dessa questão de
pesquisa foram definidas três subquestões:
• Que modelos e métodos têm sido utilizados para a estimativa de tamanho e
esforço de aplicativos móveis?
• Como foram avaliados os modelos e métodos de estimativa?
208
• Que fatores têm sido investigados como preditores de esforço para Aplicativos
Móveis?
3.2. Termos de Pesquisa

Os termos de pesquisa foram reunidos em uma string de busca que foi utilizada no
processo de pesquisa. Os termos estão escritos em inglês por ser adotado pela grande
maioria das conferências e periódicos internacionais relacionados ao tema de pesquisa.
A seguir está a string de busca, sendo que foi utilizado um recurso oferecido pelas
fontes de busca que delimita a área de pesquisa Ciência da Computação.
(“Mobile apps” OR “Mobile Applications” OR “Mobile Computing” OR “Mobile System” OR
“Mobile Software”) AND (“Process” OR “Technique” OR “Model” OR “Method” OR
“Approach” OR “Features” OR “Characteristics” OR “Factors”) AND (“Effort Estimat*”
OR “Effort Prediction” OR “Effort Measurement” OR “Size Estimat*” OR “Functional Size
Measurement”)
Para avaliar a qualidade e abrangência da string de busca, foi realizada uma
pesquisa exploratória na qual foram definidos 4 artigos de controle, que são Nitze et al.
(2014), De Souza e Aquino (2014), Heeringen e Gorb (2014) e Ferrucci et al. (2015b).
Após a execução da string de busca nas bibliotecas digitais, verificou-se que os artigos
de controle estavam entre as publicações retornadas.
2.4. Fontes de Busca

A busca foi realizada nas bibliotecas digitais Scopus, Engineering Village e ACM, pois
as três bibliotecas digitais possuem um bom funcionamento e abrangência de suas
máquinas de busca, evidenciada em alguns trabalhos, como o de Nitze et al. (2014),
Francese et al. (2015) e Pocatilu e Vetrici (2009). Kitchenham e Charters (2007)
afirmam que a Scopus é a maior base de dados de indexação de resumos e citações. A
ACM DL também indexa algumas publicações da Springer Link, Science Direct.
Trindade et al. (2008) afirmam que Engineering Village agrega informações de diversos
bancos de dados bibliográficos em Ciência da Computação (Compendex e Referex),
abrangendo importantes periódicos e conferências da IEEE, ACM, Springer e Elsevier.
3.5. Critérios de Seleção de Estudos

A fim de selecionar os estudos que melhor respondem as questões de pesquisa,
Kitchenham e Charters (2007) sugerem a definição de critérios de inclusão e exclusão
para os estudos que são retornados pela string de busca. Para este mapeamento, foram
definidos os critérios descritos na Tabela 2. Não foi adicionado critério de exclusão de
artigos que não fossem relacionados a artigos primários com o objetivo de abranger
estudos secundários e terciários, pois nenhuma revisão ou mapeamento da literatura
específico sobre estimativa de aplicativos móveis foi retornado nas buscas.
3.6. Processo de Seleção de Estudos

O mapeamento sistemático foi conduzido por duas pesquisadoras e o processo de
seleção de estudos foi sistematizado seguindo três etapas: (1) execução da busca; (2)
primeiro filtro e (3) segundo filtro.
209
Durante a execução de busca, foram realizados quatro refinamentos na string de
busca para obter melhores resultados. Não houve restrição no período de tempo, porém
a busca do último refinamento da string ocorreu em novembro de 2016. Utilizou-se a
string de busca nas fontes selecionadas e armazenou-se o conjunto de referências
recuperadas na ferramenta Start1.
Tabela 2. Critérios de Seleção
# Código Descrição
Critérios CI01 O artigo analisa a estimativa de esforço e/ou tamanho dentro do domínio do
de desenvolvimento de Aplicativos Móveis.
Inclusão CI02 O artigo caracteriza os fatores preditores de esforço no desenvolvimento de
Aplicativos Móveis.
Critérios CE01 O artigo não analisa a estimativa de esforço e/ou tamanho dentro do domínio
de do desenvolvimento de Aplicativos Móveis.
Exclusão CE02 O artigo não realiza a estimativa nas fases iniciais do projeto.
CE03 O artigo estima o tamanho do espaço de armazenamento que o aplicativo irá
ocupar.
CE04 Artigos duplicados.
CE05 Falta de disponibilidade do artigo para download.
CE06 Artigos que não estão escritos em Inglês ou em Português.
No primeiro filtro, foram analisados os artigos retornados na busca por meio dos
critérios de inclusão e exclusão, através da leitura dos títulos e abstracts dos artigos. No
segundo filtro, foi realizada a leitura completa dos artigos incluídos no primeiro filtro e
analisados novamente por meio dos critérios de inclusão e exclusão. Foram excluídos os
artigos cujo conteúdo não atendia aos critérios de seleção, justificando a decisão. Após a
verificação dos resultados da seleção do segundo filtro, foi realizada a extração dos
dados dos artigos incluídos. Os resultados quantitativos obtidos em cada etapa do
procedimento de seleção dos artigos são resumidos na Figura 1.
Figura 1.Processo de Seleção de Publicação
Durante a execução da busca, foram retornados 487 artigos nas fontes de busca.
Em seguida, foram removidos os artigos duplicados, o primeiro filtro foi realizado por
uma pesquisadora que analisou cada artigo, supervisionado pela outra pesquisadora. Foi
conduzido um teste na biblioteca Engineering Village, porém 100% das publicações
foram duplicadas em relação aos resultados da Scopus. A lista de todas as publicações
extraídas está disponível no Relatório Técnico [DE SOUZA e CONTE 2017].
1
http://lapes.dc.ufscar.br/tools/start_tool
210
Com intuito de garantir a confiabilidade do processo de seleção, uma amostra de
50 artigos, selecionados aleatoriamente, foi utilizada para analisar o grau de
concordância entre as duas pesquisadoras durante a seleção dos artigos. O acordo entre
estas duas pesquisadoras foi avaliado utilizando-se o método estatístico Teste Kappa
[COHEN 1960]. O resultado obtido foi um nível de concordância igual a 0,729,
indicando uma concordância significativa entre as pesquisadoras [LANDIS & KOCH
1977].
3.7. Procedimento de Extração dos Dados dos Artigos Selecionados

Depois do término do segundo filtro, os artigos selecionados foram submetidos ao
processo de extração dos dados. A extração foi realizada de forma sistemática por meio
de um formulário definido para registrar as informações necessárias relativas a cada
artigo. O formulário de extração permite o registro de todas as informações necessárias
para responder às questões de pesquisa. O modelo do formulário de extração encontra-se
no relatório técnico [DE SOUZA e CONTE 2017].
4. Resultados
4.1 Visão Geral dos Resultados

No primeiro momento, os resultados do mapeamento sistemático foram analisados
quantitativamente em relação aos veículos e ao ano de publicação. Em relação aos
veículos de publicação, 11% dos artigos foram publicados em revistas ou periódicos,
enquanto 89% foram publicados em conferências. No que se refere ao período de
publicação, a Figura 2 mostra as publicações por ano. Desde 2005, a estimativa de
projeto de aplicativos móveis vem sendo relatada nas publicações científicas. Uma
possível explicação por não ter estudos em 2016 é que as publicações e trabalhos
relevantes ainda não tinham sido indexados nas fontes de busca.
Das publicações analisadas para os projetos de aplicativos móveis, 28%
descrevem modelos de estimativa de tamanho, 6% abordam modelos de estimativa de
esforço, 17% analisam fatores preditores de esforço, 11% abordam modelos de
estimativa de tamanho e esforço no mesmo trabalho e 39% falavam de ambos
(estimativa de tamanho, esforço e fatores preditores de esforço para projetos de
aplicativos móveis).
Figura 2. Distribuição das publicações por ano e por tipo de publicação.
211
4.2. Que modelos e métodos têm sido utilizados para a estimativa de tamanho e
esforço de aplicativos móveis?
Foram identificados 11 modelos de estimativa de projetos de aplicativos móveis. Pode-
se observar que modelos de estimativa de tamanho foram os mais citados com 45%,
enquanto que os modelos de estimativa de esforço com 27% e os modelos que estimam
tamanho e esforço em conjunto correspondem 27% também. Os resultados dessa
questão de pesquisa foram subdividos em modelos de estimativa de tamanho, esforço e
ambos.
• Estimativa de Tamanho – o modelo é focado em estimar o tamanho funcional do
aplicativo em pontos de função [Albrecht 1979] ou pontos de função cosmic
[COSMIC 2015]. Os modelos são encontrados em Abdullah et al. (2013),
Abdullah et al. (2014), Heeringen e Gorb (2014), Ferrucci et al. (2015a) e
D’Avanzo et al. (2015).
• Estimativa de Esforço – o modelo é focado em estimar o esforço que será
necessário para desenvolver o aplicativo móvel em horas/ pontos de função
cosmic. Os modelos são encontrados em Pocatilu e Ventrici (2009a), Pocatilu e
Ventrici (2009b) e Keränen e Abrahamsson (2005).
• Ambos – o modelo é focado em estimar conjuntamente o tamanho e esforço para
desenvolver o aplicativo móvel. Os modelos são encontrados em Nitze et al.
(2014), De Souza e Aquino (2015) e Francese et al. (2015).
O resumo de cada modelo encontra-se no relatório técnico em De Souza e Conte
(2017). Além disso, algumas características dos modelos julgadas relevantes foram
analisadas a seguir:
• Classificação de Estimativa - os modelos encontrados foram classificados em
três categorias de estimativa definidos por Mendes (2014). As categorias são
modelos classificados como técnicas algorítmicas, baseado por especialista e
híbridos (como por exemplo, Pocatilu e Ventrici (2009b) utiliza um modelo que
é classificado em técnicas algorítmicas e baseado por especialistas). Cerca de
64% modelos são classificados como técnicas algorítmicas, 27% híbridos e
apenas 9% baseado por especialistas.
• Entrada de Dados – os modelos apontados possuem entrada de dados
especificas para estimar projetos. Cerca de 18% dos modelos utilizam diagramas
da UML, 64% usam documentos de requisitos, apenas 9% usam templete de
mockups e 9% usam uses stores. Logo a maioria utiliza documento de requisitos
para estimar esse tipo de projeto.
• Métrica de Tamanho – os modelos encontrados que estimam somente o tamanho
e esforço conjuntamente contabilizam 9 modelos e definiram a métrica de
tamanho em pontos de função cosmic [COSMIC 2015], pontos de função
[Albrecht 1979], medição RAD (documento de análise de requisitos) e medição
SC (código-fonte) [FRANCESE et al 2015]. Cerca de 78% utilizam pontos de
função cosmic, 11% pontos de função, e 11% medição RAD & medição SC.
212
• Métrica de Esforço – os modelos que estimam somente o esforço conjuntamente
com o tamanho contabilizam 6 modelos e utilizam as seguintes nomenclaturas
para as métricas de esforço: cerca de 33% utiliza horas, 17% pessoa-hora, 33%
homens-ano e 17% não informam a métrica que utiliza.
• Ponderam Fatores – os modelos utilizam fatores preditores de esforço para
estimar projetos de aplicativos móveis. Esses fatores foram classificados em
Métricas de Tamanho e Fatores de Custo que são detalhados na seção 4.4. Cerca
de 73% dos modelos ponderam fatores preditores de esforço específicos para
aplicativos móveis que podem ser encontrados em Abdullah et al. (2013),
Abdullah et al. (2014), Heeringen e Gorb (2014), Nitze et al. (2014), De Souza e
Aquino (2015), Pocatilu e Ventrici (2009a), Pocatilu e Ventrici (2009b) e
Francese et al. (2015). Os outros 27% dos modelos não ponderam fatores.
4.3. Como foram avaliados os modelos e métodos de estimativa?

De 11 modelos de estimativa de projetos de aplicativos móveis identificados, apenas 7
foram avaliados experimentalmente, correspondendo cerca de 64% dos modelos
encontrados.
Apenas um estudo comparativo, realizado por Ferrucci et al. (2015b), foi
encontrado no mapeamento. Eles compararam dois modelos de estimativa de tamanho
proposto por D’Avanzo et al. (2015) e Heeringen e Gorb (2014). Os resultados
mostraram que o tamanho funcional COSMIC [COSMIC 2015] avaliado com o modelo
Heeringen e Gorb (2014) que a precisão da predição não satisfez os critérios de
avaliação e se mostrou ligeiramente pior do que o obtido no estudo original baseado na
abordagem proposta por D’Avanzo et al. (2015). A Tabela 3 mostra como foram
avaliados experimentalmente os modelos.
Tabela 3. Lista de Modelos Avaliados Experimentalmente
Referência Metodologia Ambiente Tipo de Análise de Amostra
Dados
Abdullah et al. (2013) Estudo de Caso Industria Quantitativo 1
D’Avanzo et al. (2015) Experimento Industria Quantitativo 8
Controlado
Ferrucci et al. (2015) (a) Estudo de Caso Industria Quantitativo 13
Ferrucci et al. (2015b) Experimento Industria Quantitativo 13
Controlado
Francese et al. (2015) Estudo de Caso Academia Quantitativo 23
Keränen e Abrahamsson (2005) Estudo de Caso Industria Quantitativo e Qual. 1
De Souza e Aquino (2014 a,b,c) e Experimento Academia Quantitativo 2
De Souza e Aquino (2015) Controlado
Os principais resultados estão destacados a seguir:
• Metodologia Experimental – os modelos foram avaliados da seguinte forma:
cerca de 57% usaram estudo de caso e 43% usaram experimento controlado.
• Ambiente – cerca de 29% dos modelos foram avaliados na academia e 71%
foram avaliados na indústria.
213
• Tipo de Análise de Dados – os modelos foram avaliados pelos seguintes tipos de
análise de dados: Cerca de 86% quantitativamente e 14% qualitativamente.
• Amostra – foi contado o número de aplicativos que foram usados para o
experimento que variou entre 1 a 23 aplicativos.
4.4. Que fatores têm sido investigados como preditores de esforço para Aplicativos
Móveis?
Entre os estudos selecionados, foram encontradas evidências relevantes de fatores
preditores de esforço de projeto de aplicativos móveis. Dos 18 estudos retornados,
apenas 10 apontaram fatores preditores de esforço, correspondendo a cerca de 59%.
Foram extraídos 93 fatores que foram organizados em uma hierarquia de 4 níveis (ver
Figura 3, adaptação da hierarquia da taxonomia proposta por Britto et al. (2017), cada
nível é formado por categorias.
Figura 3. Fatores Preditores de Esforço: Como estão organizados
As categorias do terceiro e quarto níveis hierárquico são definidas da seguinte forma:

• Métricas de tamanho
▪ Tamanho - Esta categoria inclui métricas que medem diretamente o
comprimento de aplicações Web com base no tamanho / comprimento dos
seus elementos de composição.
▪ Funcionalidade - Esta categoria engloba métricas que medem indiretamente
o tamanho do aplicativo móvel, baseadas em suas características e funções.
▪ Complexidade - Esta categoria abrange métricas que medem indiretamente o
tamanho do aplicativo móvel, baseadas na dificuldade associada com os
seus elementos de composição.
• Fatores de custo
▪ Cliente - esta categoria abrange fatores de custo relacionados ao cliente que
exige o desenvolvimento de um aplicativo móvel.
▪ Empresa - esta categoria engloba os fatores de custos associados à empresa
contratada por um cliente para desenvolver um aplicativo o aplicativo
móvel.
▪ Produto - esta categoria inclui os fatores de custo relacionados a requisitos e
restrições associada a um aplicativo móvel.
214
▪ Projeto - esta categoria abrange os fatores de custo associados à
configuração de um aplicativo móvel.
▪ Equipe - esta categoria abrange os fatores de custo que estão associados com
a equipe de desenvolvimento responsável pela execução de um projeto de
aplicativo móvel.
▪ Tecnologia - Esta categoria abrange os fatores de custos associados às
tecnologias (Linguagem de programação, ferramentas, plataformas) exigidos
em um projeto de aplicativo móvel.
Os fatores preditores de esforço estão no Apêndice deste artigo.
5. Discussão
Este mapeamento sistemático visou identificar modelos de estimativa e fatores
preditores de esforço no contexto do desenvolvimento de aplicativos móveis. Os
resultados mostraram que existem vários estudos propondo modelos e fatores preditores.
No entanto, ainda existem algumas lacunas que podem ser exploradas por estudos
futuros:
▪ Não houve consenso sobre quais fatores preditores de esforço utilizar no
processo de estimativa, ou seja, apenas alguns fatores são comuns em vários
estudos. Logo, uma investigação mais detalhada sobre os preditores de esforço é
justificada;
▪ Apenas 1 estudo apresentou uma comparação entre dois modelos [FERRUCCI
ET AL. 2015b], o que dificulta a definição do modelo mais adequado para o
contexto de aplicativos móveis. Outro fator limitante é a indisponibilidade dos
modelos em um número considerável de estudos, o que dificulta a realização
desse tipo de comparação;
▪ Quando se trata dos modelos de estimativa mais utilizados, os resultados
mostraram que há uma tendência dos pesquisadores em proporem modelos
do tipo técnicas algorítmicas para estimar projetos de aplicativos móveis.
▪ Alguns modelos foram avaliados experimentalmente, de 11 modelos
encontrados, apenas 7 foram avaliados. Dos que foram avaliados, apenas 1 foi
analisado qualitativamente. Segundo Usman et al. (2014), a não medição da
precisão da previsão dos modelos pode implicar no não interesse dos
pesquisadores e profissionais no uso dos modelos, uma vez que não conseguiram
fornecer evidência de quão adequadas são os modelos de estimativa de esforço.
▪ Poucos modelos estimam o tamanho e esforço conjuntamente. De 11 modelos
encontrados, apenas 3 foram propostos. Modelos que estimam o tamanho e
esforço em conjunto torna mais simples a estimativa.
▪ Atualmente, não há diretrizes para os profissionais decidirem qual modelo de
estimativa ou fatores preditores de esforço escolherem em um determinado
projeto de aplicativo móvel.
215
Apesar da maioria dos modelos de estimativa utilizarem fatores preditores de
esforço, ainda há espaço para mais pesquisas nesta área, a fim de melhorar a qualidade
dos modelos de estimativa.

Neste mapeamento sistemático, foram analisadas as publicações referentes aos modelos
de estimativa de tamanho, esforço e fatores preditores de esforço de projetos de
aplicativos móveis. A partir de um conjunto inicial de 487 publicações, foram
selecionadas 18 publicações, resultando em 6 modelos para estimar tamanho, 3 modelos
de esforço, 3 modelos para estimar ambos em conjunto e 93 fatores preditores de
esforço.
Embora vários estudos tenham sido conduzidos com relação à estimativa de
tamanho e esforço para projetos de aplicativos móveis, os resultados revelaram que não
há um modelo contendo todos fatores citados na literatura que ajude os profissionais a
selecionarem preditores de esforço. Assim, as lacunas identificadas neste mapeamento
sistemático podem ser um ponto de partida para outros pesquisadores. Como trabalhos
futuros pretende-se investigar qualitativamente quais são os fatores preditores de esforço
que os especialistas e praticantes apontam hoje em dia na indústria e em seguida,
comparar esses fatores resultantes dessas duas investigações (MSL e Qualitativo).
Através desta comparação, pretende-se criar um conjunto mais completo de fatores
preditores de esforço que servirá como base para uma taxonomia de fatores preditores
de esforço para projetos de aplicativos móveis.
Agradecimentos
As autoras gostariam de agradecer a pesquisadora Emilia Mendes, a agência de fomento
FAPEAM através do número de processo 062.02646/2014 e ao Grupo Usabilidade e
Engenharia de Software (USES) da Universidade Federal do Amazonas (UFAM) por
todo apoio a este trabalho.
Referencias
Abdullah, N. A. S., Rusli, N. I. A., e Ibrahim, M. F. (2013). “A case study in COSMIC
functional size measurement: Angry bird mobile application”, In 2013 IEEE
Conference on Open Systems, ICOS 2013, p. 139–144.
Abdullah, N. A. S., Rusli, N. I. A., e Ibrahim, M. F. (2014). “Mobile game size
estimation: Cosmic fsm rules, uml mapping model and unity3d game engine”. In
Open Systems (ICOS), p. 42-47.
Abreu, F. P. (2011). “Estimativa de Software Baseada em Ponto de Caso de Uso: Curso
introdutório”, http://pt.slideshare.net/enovar/estimativa-de-software-em-pontos-de-
caso-de-uso, Outubro.
Albrecht, A. J. (1979). “Measuring application development productivity”. In Proc. of
the Joint SHARE/GUIDE/IBM Application Development Symposium, p. 83-92.
Boehm, B. W. (1981). “Software engineering economics”, Vol. 197, Englewood Cliffs
(NJ): Prentice-hall.
216
Britto, R., Usman, M., Mendes, E. (2017). “A Taxonomy of Web Effort Predictors”, In
Journal of Web Engineering (JWE).
Cohen, J., (1960). “A coefficient of agreement of nominal scales”. Educational and
Psychological Measurement, p.37–46.
COSMIC. (2015). “The COSMIC Functional Size Measurement Method Version 4.0.1
Measurement Manual”, http://cosmic-sizing.org/publications/measurement-manual-
401/, Abril.
D’Avanzo, L. D., Ferrucci, F., Gravino, C., Salza, P., Giovanni, V., Ii, P., e Sa, F.
(2015). “COSMIC Functional Measurement of Mobile Applications and Code Size
Estimation”, p. 1631–1636.
De Souza, E. T. B. e Conte, T. (2017). “Estimativa de Projetos de Aplicativos Móveis:
Um Mapeamento Sistemático”. In Relatório Técnico USES TR-USES-2017-011.
http://uses.icomp.ufam.edu.br/wp-content/uploads/2017/05/RT-USES-2017-011.pdf.
De Souza, L. S., e De Aquino Jr, G. S. (2014). “Meffortmob: a effort size measurement
for mobile application development”. In: International Journal of Software
Engineering and Applications, v.5, nº4, p. 63.
Dombroviak, K. M., & Ramnath, R. (2007). “A taxonomy of mobile and pervasive
applications”. In Proceedings of the 2007 ACM symposium on Applied computing,
p. 1609-1615.
eMarketer. (2016). “2 Billion Consumers Worldwide to Get Smart(phones)”,
http://www.emarketer.com/Article/2-Billion-Consumers-Worldwide-Smartphones-
by-2016/1011694, Abril.
Ferrucci, F., Gravino, C., Salza, P., e Sarro, F. (2015). “Investigating Functional and
Code Size Measures for Mobile Applications”. In 2015 41st Euromicro Conference
on Software Engineering and Advanced Applications, p. 365–368.
Ferrucci, F., Gravino, C., Salza, P., e Sarro, F. (2015). “Investigating Functional and
Code Size Measures for Mobile Applications: A Replicated Study”. In International
Conference on Product-Focused Software Process Improvement, p. 271–287.
Francese, R., Gravino, C., Risi, M., Scanniello, G., e Tortora, G. (2015). “On the Use of
Requirements Measures to Predict Software Project and Product Measures in the
Context of Android Mobile Apps: A Preliminary Study”. In 2015 41st Euromicro
Conference on Software Engineering and Advanced Applications, p. 357–364.
Heeringen, H. Van, e Gorp, E. Van. (2014). “Measure the functional size of a mobile
app: Using the cosmic functional size measurement method”. Proceedings - 2014
Joint Conference of the International Workshop on Software Measurement, IWSM
2014 and the International Conference on Software Process and Product
Measurement, Mensura 2014, p. 11–16.
Keränen, H., e Abrahamsson, P. (2005). “A Case Study on Naked Objects in Agile
Software Development”, p. 189–197.
217
Kitchenham, B., e Charters, S. (2007). Guidelines for performing Systematic Literature
Reviews in Software Engineering. Staffordshire, UK.
Landis, J.R. e Koch, G.G., (1977). “The Measurement of Observer Agreement for
Categorical Data. Biometrics, p. 159–174.
Mendes, E. (2014). “Practitioner's Knowledge Representation: A Pathway to Improve
Software Effort Estimation”. Springer Science and Business, p.27.
Nagappan, M. (2016). “Future Trends in Software Engineering Research for Mobile
Apps”. Software Analysis, Evolution, and Reengineering (SANER ’16), p. 14–18.
Nitze, A., Schmietendorf, A., e Dumke, R. (2014). “An analogy-based effort estimation
approach for mobile application development projects”. Conference on Software
Process and Product Measurement (IWSM-MENSURA), p. 99–103.
Pocatilu, P., e Vetrici, M. (2009). “M-applications Development using High
Performance Project Management Techniques 3 Time / Duration Management
Models”, p. 123–128.
Trindade, C. C., Moraes, A. K., e Meira, S. R. L. (2008). “Comunicação em equipes
distribuídas de desenvolvimento de software: Revisão sistemática”. In ESELAW'08:
Proceedings of the 5th Experimental Software Engineering Latin American
Workshop.
Usman, M., Mendes, E., Weidt, F., & Britto, R. (2014). “Effort estimation in agile
software development: a systematic literature review”. In Proceedings of the 10th
International Conference on Predictive Models in Software Engineering, p. 82–91.
Apêndice
A Referência EP1 a EP15 estão descritas no Apêndice B do Relatório Técnico em De
Souza e Conte (2017).
Métricas Categoria Fator Referência
Métricas Tamanho
de Requisitos e Número de Requisitos Funcionais EP1
Tamanho Modelos Número de Atores do Caso de Uso EP1
Número de Casos de Uso EP1
Número de Classes EP1
Número de Diagramas de Sequência EP1
Código Fonte Número de Classes EP1
Número de Arquivos EP1
Número de Métodos (incluindo os herdados) EP1
Número de todas as linhas EP1
Número de linhas contendo código fonte EP1
Número de linhas contendo comentários EP1
Número de declarações EP1
Tamanho do código (kB) EP11
Número de arquivos XMI sobre elementos gráficos de EP1
um aplicativo para dispositivos móveis.
Complexidade Complexidade EP5

Complexidade Ciclomática EP1
218
Funcionalidade COSMIC EP3, EP4,
EP7, EP11,
EP12, EP13,
EP14, EP15
IFPUG EP2
Fatores Equipe de Produtividade da equipe EP6
de Custo Desenvolviment Comunicação entre a equipe EP5, EP6
o Experiência da equipe EP6, EP7
Envolvimento individual dos membros da equipe. EP6
Conhecimento de desenvolvimento em áreas e aplicações EP6
empresariais
Educação de pessoas EP6
Definição de papéis das equipes EP6, EP7
Nível de mudanças de Equipe EP7
Empresa Organização de Domínio de Negócios EP7
Dados de Domínio de Negócios Warehouse & BI EP7
Nível de certificação da empresa EP6
Regras e Regulamentos dirigidos EP7
Objetivos das partes interessadas. EP6
Cliente de Domínio Empresarial e Gestão de Contas EP7
Hipotecas de domínio empresarial EP7
Falhas de software e hardware EP6
Envolvimento dos concorrentes EP6
Cliente Competências e expectativas dos usuários e clientes EP6
Fornecedor Competências de fornecedores EP6
Projeto Preparação da gestão da mudança EP6
Steady Heartbeat EP7
Processo de validação e verificação e implementação EP6
Agile (Scrum) EP7
Teste em ambiente real EP6
Baseado em Release (um aplicativo) EP7
Migração EP7
Nenhuma informação disponível no Campo de aplicação EP6
(especialmente para novos, Aplicações inovadoras)
Tecnologia orientada (Tecnology Driven) EP7
Versão única do Projeto EP7
Dificuldade de mensurar o processo EP5
Dificuldade de enumerar os estados do programa EP5
Dificuldade de entendimento dos custos de modificações EP5
Falta de agendar atrasos no cronograma EP5
Falta de Confiabilidade EP5
Tecnologia Tempo de vida que a instância da aplicação EP8
Persistência dos dados da aplicação EP8
Tempo de Vida EP8
Fator de Contexto EP2
Consciência de Localização Absoluta EP8
219
Consciência de Espaço EP8
Restrição de Tempo de Resposta EP8
Consciência de Proximidade EP8
Consciência de Eventos EP8
Consciência de Transição EP8
Consciência de Objetos EP8
Publicidade (anúncios) EP3
Realidade aumentada EP3
Consciência operacional EP8
Centricidade EP8
Objetivo EP7
Sistema de Rastreamento EP3
Produto
Rede de dados Largura de banda da rede EP2, EP6
Tráfego mínimo de dados EP4
Comutação de Wifi EP4
Tipos de Conectividade na rede EP2, EP4
Interface Variação de interface EP2
Qualidade visual EP3
Modos de apresentação EP3, EP4
Interface Gráfica: Tamanho das Telas EP2
Limitação de Baixo Consumo de Bateria EP2, EP4
Hardware Interrupções de Chamada EP4
Fator de Desempenho EP2, EP4
Portabilidade Compatibilidades de software; EP6
Compatibilidades de dispositivos móveis; EP3, EP6
Portabilidade entre sistemas operacionais EP3, EP5
Compatibilidade entre emuladores e dispositivos móveis EP6
Infra-Estrutura Maturidade tecnológica da plataforma EP3
Dependências com outros sistemas EP7
Tipos de sistemas de back-end (CMS, web site,ERP, EP3, EP4
CRM ...)
Sistema Operacional EP5
Bugs existentes no software EP6
Uso de APIs nativas (Maior Esforço) EP6
Requisitos Não- Colaboração EP8
Funcionais Segurança EP4, EP7
Qualidade dos produtos EP6
220
Capacidade do Cliente na Solicitação de Requisitos Não-
Funcionais
Andreia R. Silva1, Placido R. Pinheiro1, Adriano B. Albuquerque1,
Jonatas C. Barroso2
1
Programa de Pós-Graduação em Informática Aplicada
Universidade de Fortaleza – Fortaleza, CE – Brazil
2
Departamento de Computação – Universidade Federal do Ceará (UFC)
Fortaleza, CE – Brazil
andrearsp@gmail.com, placido@unifor.br, adrianoba@bnb.gov.br,
jonatascbarroso@gmail.com
Abstract. Non-functional requirements (NFR) need to be known and properly

treated since the beginning of the software development cycle. This study aims
to investigate whether the NFR of the application can be obtained from the
customers, according to the opinion of the professionals involved with the
software development process. For this, a research process based on the
model provided by Kitchenham and Pfleeger was used. 98 (ninety eight)
professionals with different levels of experience participated of the research.
Results showed that professionals believe that most NFR types can not be
requested by the application customers because of lack of technical
knowledge.
Resumo. Requisitos não-funcionais (RNFs) precisam ser conhecidos e

adequadamente tratados desde o início do ciclo de desenvolvimento do
software. O objetivo deste artigo foi investigar se é possível obter dos clientes
os RNFs da aplicação, de acordo com a opinião dos profissionais envolvidos
com o processo de desenvolvimento. Para isso, foi utilizado um processo de
pesquisa baseado no modelo disponibilizado por Kitchenham e Pfleeger. A
pesquisa contou com a participação de 98 (noventa e oito) profissionais com
diferentes níveis de experiência. Os resultados mostraram que os profissionais
acreditam que a maioria dos tipos de RNFs não pode ser solicitada pelo
cliente da aplicação em virtude da falta de conhecimento técnico necessário.
1. Introdução
Requisitos Não-Funcionais (RNFs) precisam ser conhecidos e adequadamente tratados
desde o início do ciclo de desenvolvimento do software, pois eles podem influenciar a
escolha das tecnologias utilizadas, os padrões de desenvolvimento adotados, as
estratégias de alocação de recursos de hardware e os mecanismos de segurança. Além
disso, conhecer os RNFs nos estágios iniciais do desenvolvimento pode ajudar a
221
melhorar as estimativas de tamanho, esforço e custo do projeto e também pode evitar o
retrabalho.
Toda aplicação possui RNF [Slankas e Williams 2013], mas alguns fatores
contribuem para a falta de tratamento desses requisitos. Primeiramente, a elicitação de
RNFs é uma atividade complexa e de alto custo que exige o envolvimento de
profissionais experientes e com conhecimentos específicos [Silva, Pinheiro e
Albuquerque 2016]. Além disso, os engenheiros de requisitos não possuem o apoio
necessário para a realização dessa atividade. Os métodos de desenvolvimento e técnicas
de elicitação dispensaram grande parte de sua atenção ao tratamento dos requisitos
funcionais [Cysneiros 2000; Rahman e Ripon 2013; Silva et al. 2016a]. Na literatura, é
possível encontrar conceitos sobre RNFs, mas não há muitos detalhes de como tratá-los.
Outro fator importante é que os clientes, muitas vezes, não possuem os conhecimentos
técnicos necessários para solicitar RNFs ou, até mesmo, para compreendê-los. Mas,
sendo a qualidade um conceito relativo, que depende de cada cliente, envolvê-lo no
processo de elicitação desses requisitos é fundamental.
Os objetivos dessa investigação foram identificar se, na opinião dos profissionais
envolvidos com o processo de desenvolvimento, é possível obter dos clientes os
requisitos não-funcionais necessários para a aplicação a ser desenvolvida; e obter uma
visão atual da prática de elicitação de RNFs em organizações de software.
Uma busca na literatura permitiu encontrar alguns trabalhos relacionados que
analisam a situação da elicitação de RNFs em organizações [Ameller et al. 2012; Borg
et al. 2003; Phillips, Aurum e Svensson 2012; Svensson, Gorschek e Regnell 2009;
Svensson et al. 2011; Vara et al. 2011], mas esses estudos não capturam a opinião dos
participantes sobre quais requisitos podem ser elicitados com o cliente. Além disso,
essas pesquisas, com exceção do trabalho de Phillips, Aurum e Svensson (2012),
contaram com uma quantidade média de 19 (dezenove) participantes em poucas
organizações. Portanto, a realização de uma nova pesquisa abordando esse tema é
importante para ter uma visão mais atual e detalhada sobre como as organizações estão
elicitando esses requisitos.
Parte dos resultados deste estudo pode ser conferido no trabalho já publicado em
[Silva et al. 2016b]. Portanto, este artigo abordará apenas as diferenças; especialmente,
o método de pesquisa utilizado (Seção 2), os resultados obtidos no estudo que não foram
abordados no trabalho anterior (Seção 3), as ameaças à validade (Seção 4), a
comparação com os trabalhos relacionados (Seção 5) e, finalizando, as lições aprendidas
e as principais conclusões da pesquisa (Seção 6).
Dentre as principais preocupações existentes no planejamento de um survey, Zhang e
Budgen (2013) destacam: definição da população a ser estudada, utilização de formas
adequadas de amostragem, obtenção de uma taxa de resposta adequada e utilização de
mecanismos para evitar vieses nas perguntas. Para o contexto deste trabalho, foi
desenvolvido um processo de pesquisa baseado no modelo disponibilizado por
Kitchenham e Pfleeger (2001, 2002a, 2002b, 2002c, 2002d, 2003).
222
Esse processo, resumido na Figura 1, incluiu a Composição de um questionário,
a Validação do questionário por investigadores experientes, a aplicação de um Piloto
para assegurar a aplicabilidade e a viabilidade do questionário, a Evolução do
questionário com base nas avaliações realizadas e a Realização da pesquisa com os
profissionais por meio da aplicação do questionário finalizado. As atividades do
processo estão detalhadas nas subseções seguintes.
Figura 1. Processo de definição e aplicação da pesquisa
2.1. Composição do Questionário

Para alcançar os objetivos deste estudo, as questões que a pesquisa buscou responder
foram:
 QP1 - Os profissionais acreditam ser possível elicitar RNFs com o cliente? As
propostas encontradas na literatura que apóiam a elicitação dos RNFs abordam
as características não-funcionais do software do ponto de vista técnico,
utilizando uma linguagem que não facilita a compreensão pelos clientes da
aplicação [Dorr et al. 2003; Rao e Gopichand 2011; Sindre e Opdahl 2005;
Wang et al. 2010]. Assim, o propósito desta questão é identificar se os
profissionais acreditam que os clientes são capazes de opinar sobre esses tipos de
requisitos.
 QP2 - Os RNFs são elicitados nas organizações? O propósito desta questão é
conhecer o cenário atual das organizações quanto à prática de elicitação de
requisitos não-funcionais.
 QP3 - Qual a qualidade dos RNFs elicitados? Com esta questão busca-se
conhecer como os profissionais classificam, em termos de qualidade, os
requisitos definidos nas organizações de desenvolvimento de software.
 QP4 - Por quais motivos as organizações de desenvolvimento de software não
elicitam RNFs? É possível que organizações também não costumem elicitar
RNFs. A opinião dos profissionais participantes da pesquisa dará subsídios para
entender as causas desse fenômeno e ajudará a definir os aspectos a serem
tratados para enfrentar esse problema.
 QP5 - Um mecanismo de apoio à elicitação dos RNFs seria útil? Uma vez que a
elicitação de RNFs é fundamental para a qualidade do software desenvolvido,
em particular, buscou-se ainda capturar, do ponto de vista dos profissionais que
223
participam do desenvolvimento de software, a importância de um guia para
apoiar a elicitação desses requisitos e a expectativa desses profissionais em
relação à composição desse guia.
A pesquisa foi composta por 5 (cinco) partes1, contendo questões objetivas e
subjetivas. Além disso, algumas questões eram dependentes de outras e, portanto, só
eram disponibilizadas para os participantes de acordo com as respostas atribuídas a
outras questões. Assim, o formulário foi estruturado de forma a obter o perfil do
participante, dados da organização onde trabalha e respostas às questões de pesquisa.
 Parte I - Contemplou questões relacionadas à organização em que o participante
atuava no momento da pesquisa, tais como tempo de atuação, tipo de
organização e tipo de serviço prestado.
 Parte II - Abordou questões relacionadas ao perfil do participante, como grau de
escolaridade e tempo de experiência.
 Parte III - Buscou identificar, dentre as subcaracterísticas de RNFs
disponibilizadas pela norma ISO/IEC 25010-2011 [ISO 2011], aquelas que
poderiam ser solicitadas pelo cliente. Para isso, foram listadas e devidamente
conceituadas as subcaracterísticas de requisitos não-funcionais. Em seguida, foi
solicitado que o participante escolhesse apenas uma opção dentre três
disponíveis: Cliente, Equipe Técnica e Não Se Aplica. O participante deveria
selecionar a opção Cliente caso concordasse que, mesmo sem conhecimento
técnico, o cliente seria capaz de solicitar um requisito correspondente à
respectiva subcaracterística. A opção Equipe Técnica deveria ser selecionada
caso o participante considerasse que apenas uma equipe com conhecimentos
técnicos e informações especializadas poderia definir um requisito associado à
respectiva subcaracterística. Já a opção Não Se Aplica seria selecionada nos
casos em que o participante considerasse que um requisito correspondente à
subcaracterística deveria ser inerente ao software, ou seja, obrigatoriamente
atendido independente da solicitação do cliente. Esses esclarecimentos dos itens
de resposta estavam presentes no cabeçalho do formulário. Além disso, como o
objetivo dessa parte do formulário é identificar RNFs que o cliente é capaz de
solicitar, a participação de uma equipe técnica nas discussões não anula a
capacidade do cliente em definir esses requisitos. Por isso, não houve
necessidade de permitir múltiplas respostas.
 Parte IV - Esta parte do formulário objetivou identificar a situação atual das
organizações dos participantes em relação à definição de RNFs. Nos casos em
que foi afirmado que os requisitos eram definidos, buscou-se classificá-los
quanto à sua qualidade. Para isso, os conceitos do que seria uma definição de
requisitos Boa, Razoável ou Ruim foram descritos no formulário. Além disso,
essa seção procurou também identificar os motivos pelos quais esses requisitos
não são definidos, através de itens de múltipla escolha e um campo de texto para
Outros Motivos.
1
Formulário da pesquisa: http://goo.gl/forms/QQX5Vtc24b.
224
 Parte V - Objetivou capturar as expectativas dos participantes quanto à
disponibilização de um guia de apoio à elicitação de RNFs.
2.2. Validação e Evolução do Questionário

Durante o planejamento da pesquisa, buscou-se diminuir a subjetividade das questões e
melhorar a usabilidade do questionário. Portanto, as questões relacionadas foram
agrupadas e cada questão foi avaliada buscando eliminar ambiguidades ou dúvidas que
pudessem ser geradas. Além disso, a pesquisa listou os conceitos de cada característica e
subcaracterística apresentada na norma e definiu parâmetros para a classificação dos
requisitos quanto à qualidade da especificação. Por exemplo, para considerar que a
definição de um requisito é boa, os participantes deveriam considerá-lo completo,
consistente, claro e verificável. Por outro lado, se a definição dos requisitos apresentasse
incompletude, inconsistência ou subjetividade, seria considerado ruim.
Dentre os vários catálogos de tipos de RNFs disponíveis na literatura, a ISO
25010 [ISO 2011] foi escolhida por ser um padrão internacional que contém categorias e
subcategorias de RNFs, além de possuir as definições de cada um dos tipos.
Para assegurar que os objetivos da pesquisa poderiam ser satisfeitos, o
questionário foi inicialmente avaliado por 4 (quatro) pesquisadores de engenharia de
software e diversas melhorias foram solicitadas e incorporadas à pesquisa. Dentre elas, a
definição do que representa uma boa definição de um requisito, diminuindo a
subjetividade na interpretação do texto.
2.3. Aplicação do Piloto e Evolução do Questionário

O questionário foi aplicado em uma organização de desenvolvimento de software do
setor público que demonstrou interesse em avaliar a opinião de seus colaboradores em
relação à definição dos RNFs de suas aplicações. Essa pesquisa piloto contou com a
participação de 45 (quarenta e cinco) profissionais distribuídos entre 3 (três) grandes
filiais e representando diferentes papéis no desenvolvimento de software (gerentes de
projetos, analistas de qualidade, analistas de sistema, arquitetos de software e
desenvolvedores). Os dados retornados pela pesquisa aplicada na empresa foram
analisados e utilizados para evolução do questionário final. Contudo, considerando que
os resultados traduziam a realidade de uma única organização, os mesmos não foram
considerados na execução e nas análises realizadas neste trabalho.
Após a execução da pesquisa piloto, uma das melhorias identificadas foi a
inclusão da opção Não Se Aplica como item de resposta possível na Parte III do
formulário; anteriormente contava apenas com as opções Cliente e Equipe Técnica. As
definições das características e subcaracterísticas de RNFs também foram revisadas e
alguns conceitos foram reescritos utilizando uma linguagem menos técnica, a fim de
melhorar o entendimento dos requisitos por todos os participantes.
Por fim, pode-se concluir que a realização da validação do formulário por
pesquisadores e a aplicação da pesquisa piloto, com a participação de uma quantidade
significante de respostas, contribuíram para identificar melhorias e verificar a
viabilidade de aplicação desta pesquisa.
225
2.4. Realização da Pesquisa
Um dos elementos principais na concepção de uma pesquisa é a determinação da
população a ser estudada. Para o contexto deste estudo, idealmente, um conjunto
representativo de profissionais da indústria envolvidos no desenvolvimento de software
deveria ser examinado. Optou-se por não limitar a papéis específicos do
desenvolvimento pois todos os papéis possuem alguma relação com RNFs em suas
atividades e por ser importante obter a visão dos mais diversos profissionais.
Contudo, o acesso a esse grupo não é trivial. Como o desenvolvimento de
software é realizado por profissionais do mundo inteiro e não foi localizada nenhuma
informação a respeito do tamanho dessa população, foi considerado um grupo de
pessoas envolvidas em um fórum de discussão brasileiro sobre processos e métricas de
software. Os profissionais envolvidos pertenciam a diversos tipos de empresa e
representavam papéis distintos no desenvolvimento de software. Além disso, a
facilidade de acesso aos endereços de e-mail desses profissionais foi um dos pontos que
contribuíram para a seleção desse fórum.
3. Análise dos Resultados

A Análise dos Dados foi realizada em uma série de passos. Primeiramente, após
finalizado o prazo da pesquisa, os dados foram exportados para uma planilha que
permitiu agrupar, ordenar e filtrar as respostas de cada questão do formulário. Assim, os
Dados Quantitativos de cada parte do formulário foram analisados, discutidos e
combinados a fim de obter as conclusões relacionadas com as questões de pesquisa.
Buscando verificar a falta de coerência das respostas, aquelas respostas que tivessem
algum padrão de repetição, isto é, o mesmo item de resposta selecionado para todas as
questões seriam descartadas da análise.
Por outro lado, os Dados Qualitativos relacionados ao conteúdo do guia e aos
motivos da falta de elicitação nas organizações foram classificados por 2 (dois)
pesquisadores independentemente. Os dados semanticamente similares foram agrupados
e as diferenças e dificuldades de categorização foram discutidas até haver um consenso.
Dentre esses dados, aqueles textos que não deixavam clara a contribuição do
participante.
3.1. Perfil dos Participantes

A pesquisa contou com a participação de 98 (noventa e oito) profissionais2, dos quais
65,3% dos participantes atuam em organizações públicas que possuem mais de 100
(cem) empregados. Desses participantes, 95% trabalham em organizações que atuam há
mais de 9 (nove) anos. Também buscou-se conhecer a opinião de profissionais que
atuam nas diversas fases do ciclo de desenvolvimento do software.
Com o intuito de obter uma visão geral do perfil dos profissionais que
participaram da pesquisa, esses foram agrupados de acordo com as funções que
desempenham nas organizações e tempo de experiência com TI (Tecnologia da
Informação), conforme pode ser visto na Figura 2. Quanto ao nível de formação dos
2
Dados da pesquisa: http://goo.gl/2qe32j.
226
profissionais, 25 (vinte e cinco) possuem apenas o curso superior, mas 39 (trinta e nove)
especialistas, 30 (trinta) mestres e 3 (três) doutores também participaram da pesquisa.
Além disso, participantes de todas as regiões do Brasil responderam à pesquisa.
Cerca de 69,4% dos participantes afirmaram que os RNFs costumam ser
elicitados nas empresas em que atuam. Contudo, apenas 11,8% desses profissionais
consideram que a definição dos RNFs é boa, enquanto 67,6% a classificam como
razoável e 20,6% consideram ruim a definição desses requisitos. Por outro lado, 30,6%
dos participantes relataram que em suas empresas os RNFs não são costumeiramente
elicitados.
Figura 2. Distribuição dos participantes por função e tempo de experiência
Para esses profissionais, os principais motivos para essa falta de definição são:
falta de conhecimento das equipes, ausência de solicitação desses requisitos pelo cliente
e falta de capacidade (técnica ou financeira) da organização para atender a requisitos
não-funcionais. Além das opções disponíveis para seleção no formulário da pesquisa,
foram informados pelos participantes os seguintes motivos para não elicitarem RNFs
nas empresas em que atuam: (i) o aumento do custo do produto provocado pela
definição dos RNFs, (ii) o fato dos RNFs serem definidos de acordo com a tecnologia
em uso, (iii) a ausência de um método ou padrão adotado na organização e (iv) a
imaturidade da empresa em perceber a importância dessa definição.
Cerca de 90% dos participantes afirmaram que um guia seria útil para prover
apoio à atividade de identificação dos requisitos não-funcionais. Do total de
profissionais que confirmaram a utilidade, 47 (quarenta e sete) participantes registraram
informações do que deve conter nesse guia. As sugestões para o conteúdo do guia
envolve a disponibilização de modelos, questionários e templates, conceitos e exemplos
de uso dos RNFs, entre outros.
3.2. Discussão dos Resultados

Como as Partes I, II, IV e V da pesquisa já foram abordadas em outro estudo
[Silva et al. 2016b], esta seção explora a Parte III do questionário que trata dos tipos de
requisitos não-funcionais que, na visão dos participantes, o cliente é capaz de solicitar.
Portanto, essa parte da pesquisa buscou identificar, dentre as subcaracterísticas de RNFs
disponibilizadas pela norma ISO/IEC 25010-2011 [ISO 2011], aquelas que podem ser
elicitadas com o cliente e aquelas que requerem o apoio de uma equipe técnica. Também
buscou identificar aquelas subcaracterísticas que, na opinião dos profissionais, não
devem ser questionadas ao cliente, mas obrigatoriamente cumpridas, independente do
227
software. A Tabela 1 apresenta o resultado das opiniões dos participantes em termos
percentuais. As características e subcaracterísticas foram organizadas em ordem
alfabética, diferentemente da forma como são apresentadas na norma.
Ao analisar os dados, é possível perceber que as características selecionadas para
tratamento com o cliente são aquelas que podem mais facilmente ser percebidas pelos
mesmos, isto é, aquelas relacionadas com Usabilidade e Adequação Funcional. Por
outro lado, as subcaracterísticas que para serem elicitadas necessitam de conhecimentos
técnicos especializados e estão no topo do ranking incluem todas as subcaracterísticas
de Manutenibilidade, Compatibilidade, Portabilidade e Desempenho. Além disso, com
exceção da subcaracterística Disponibilidade, todos os itens de Confiabilidade também
estão presentes nessa lista.
Tabela 1. Quem possui capacidade de solicitar RNFs
Participação (%)
Característica Subcaracterística
Cliente Equipe Técnica Não Se Aplica
Apropriação 61,2 23,5 15,3
Adequação
Completude 42,9 44,9 12,2
Funcional
Corretude 35,7 49,0 15,3
Coexistência 22,4 70,4 7,1
Compatibilidade
Interoperabilidade 22,4 72,4 5,1
Disponibilidade 42,9 44,9 12,2
Maturidade 9,2 70,4 20,4
Confiabilidade
Recuperabilidade 7,1 82,7 10,2
Tolerância a Falhas 15,3 75,5 9,2
Capacidade 14,3 81,6 4,1
Desempenho Comportamento do Tempo 28,6 65,3 6,1
Utilização de Recursos 14,3 75,5 10,2
Analisabilidade 4,1 88,8 7,1
Modificabilidade 7,1 82,7 10,2
Manutenibilidade Modularidade 4,1 84,7 11,2
Reusabilidade 3,1 87,8 9,2
Testabilidade 8,2 78,6 13,3
Adaptabilidade 18,4 76,5 5,1
Portabilidade Instalabilidade 19,4 69,4 11,2
Substituibilidade 20,4 75,5 4,1
Auditabilidade 41,8 52,0 6,1
Autenticidade 40,8 44,9 14,3
Segurança Confidencialidade 50,0 39,8 10,2
Integridade 27,6 56,1 16,3
Não-Repúdio 29,6 58,2 12,2
Acessibilidade 41,8 48,0 10,2
Aprendizibilidade 67,3 24,5 8,2
Interface Estética do Usuário 64,3 29,6 6,1
Usabilidade
Operacionalidade 60,2 29,6 10,2
Proteção Contra Erros do Usuário 16,3 70,4 13,3
Reconhecibilidade 74,5 18,4 7,1
No caso específico da Disponibilidade, o percentual de diferença entre as

respostas que consideraram que o cliente pode ser questionado sobre esse requisito e as
respostas que representam a opinião daqueles que consideram que o requisito deve ser
228
tratado por uma equipe técnica foi de apenas 2%. Isto é, embora seja um aspecto mais
técnico, há uma grande aceitação de que o cliente é capaz de solicitar um requisito dessa
subcaracterística. As subcaracterísticas de Segurança, com exceção de Autenticidade e
Confidencialidade também integraram o ranking da equipe técnica. Curiosamente, a
única subcaracterística de Usabilidade presente nessa lista foi a Proteção Contra Erros
do Usuário, com mais de 70% das respostas, talvez por também ser um aspecto mais
técnico.
3.3. Análise por Perfil dos Profissionais

Para conhecer as diferenças de opinião daqueles profissionais que, em geral,
possuem maior contato com o cliente e daqueles que trabalham mais internamente, as
respostas foram analisadas de acordo com o perfil dos profissionais. Dessa forma, foi
considerado no grupo de profissionais que possuem maior contato com o cliente (Grupo
A) os seguintes papéis: Gerente de Projetos, Analista de Negócios e Analista de
Sistemas. Os demais papéis formaram o grupo da equipe técnica (Grupo B). Então, a
distribuição dos participantes nos grupos ficou da seguinte forma: Grupo A com 68,4%
e o Grupo B com 31,6% dos participantes.
A Tabela 2 apresenta as respostas dos profissionais do primeiro grupo, ou seja,
aqueles que possuem contato com o cliente. Os dados foram ordenados de acordo com a
quantidade de respostas que consideraram que a subcaracterística deve ser solicitada
pelo cliente. Para esse resultado, apenas as subcaracterísticas que obtiveram mais da
metade dos votos foram consideradas. Já a Tabela 3 apresenta as respostas dos
profissionais do Grupo B, ou seja, que, em geral, não possuem contato com o cliente:
Analistas de Qualidade, Analistas de Testes, Arquitetos, Desenvolvedores e
Pesquisadores. Da mesma forma, somente foram consideradas nessa análise as
subcaracterísticas que obtiveram mais da metade dos votos.
Tabela 2. Subcaracterísticas que o cliente é capaz de solicitar (Grupo A)
Característica Subcaracterística Cliente (%)

Reconhecibilidade 71,6
Interface Estética do Usuário 68,7
Usabilidade
Aprendizibilidade 67,2
Operacionalidade 62,7
Adequação Funcional Apropriação 59,7
Tabela 3. Subcaracterísticas que o cliente é capaz de solicitar (Grupo B)

Usabilidade
Auditabilidade 64,5
Segurança
Confidencialidade 61,3
Confiabilidade Disponibilidade 54,8
Usabilidade
Segurança Autenticidade 51,6
229
Como é possível perceber, ambos os grupos concordam que as subcaracterísticas
Aprendizibilidade, Apropriação, Interface Estética do Usuário, Reconhecibilidade e
Operacionalidade podem ser solicitadas pelo cliente. Por outro lado, o grupo
representando a equipe técnica de desenvolvimento, considera que, além das já citadas,
as subcaracterísticas Auditabilidade, Autenticidade, Confidencialidade e
Disponibilidade também podem ser solicitadas pelo cliente.
Já na perspectiva dos tipos de organizações, essa mesma análise cruzada mostrou
que não há uma distinção relevante de opiniões entre profissionais de diferentes
organizações, como pode ser percebido nas Tabelas 4 e 5. A Confidencialidade, uma das
subcaracterísticas de Segurança, segundo a opinião de profissionais de organizações
públicas, pode ser solicitada pelo cliente. A natureza dessas organizações, que em geral
desenvolvem software para entes públicos no Brasil, pode ter influenciado nessa
resposta, haja vista que há uma preocupação maior com a segurança dos dados do
governo.
Tabela 4. Subcaracterísticas que o cliente é capaz de solicitar (Org. Privadas)

Usabilidade
Usabilidade
Tabela 5. Subcaracterísticas que o cliente é capaz de solicitar (Org. Públicas)

Usabilidade Aprendizibilidade 66,7
Usabilidade Operacionalidade 58,0
Segurança Confidencialidade 55,1
4. Ameaças à Validade
Questões relacionadas à validade de um instrumento de pesquisa foram apresentadas por
Kitchenham e Pfleeger (2002c), dentre as quais, destaca-se a validade do conteúdo. A
avaliação da Validade do Conteúdo é subjetiva e tem como propósito identificar o quão
apropriado um instrumento de pesquisa é para um grupo de colaboradores conhecedores
do assunto. Para viabilizar essa avaliação, 4 (quatro) pesquisadores de engenharia de
software foram convidados para analisar o questionário da pesquisa. Todos os
problemas identificados durante a avaliação foram devidamente tratados.
Em relação à Validade Interna, buscou-se reduzir o viés identificado durante o
piloto, quando profissionais informaram que algumas características não deveriam
sequer ser questionadas, mas obrigatoriamente embutidas no software. Com isso, um
item de resposta para tratar esse cenário foi definido.
Além disso, buscou-se reduzir a possibilidade de subjetividade na interpretação
das questões especificamente relacionadas às características e subcaracterísticas da
230
norma ISO/IEC 25010 [ISO 2011]. Portanto, foram incluídas as definições de cada
subcaracterística para evitar interpretações incorretas a respeito da definição dos
requisitos. Contudo, não é possível evitar todos os problemas e, considerando a
quantidade de características e subcaracterísticas da norma, pode ter havido uma certa
fadiga ou falta de comprometimento por parte dos participantes.
Para reduzir essa possibilidade, buscou-se identificar respostas que tenham
seguido um mesmo padrão para todas as subcaracterísticas. Contudo, não foi detectado
nenhum caso.
Para evitar respostas descomprometidas, optou-se por enviar apenas um
lembrete para os participantes que não haviam respondido após a primeira solicitação.
Por fim, na busca por desenvolver um questionário simples, o tempo de resposta da
pesquisa foi um dos quesitos avaliados no piloto a fim de que não fosse superior a 15
(quinze) minutos.
Finalmente, outra possível ameaça à validade interna da pesquisa é que os
participantes não foram questionados quanto ao seu conhecimento sobre RNFs e à
prática de elicitação, bem como aos conceitos presentes na norma utilizada. Isto pode ter
gerado uma interpretação incorreta das questões presentes na Parte III do formulário.
A Validade Externa da pesquisa determina a capacidade de generalização dos
resultados obtidos com a amostra em relação à população em geral. Nesse sentido, a
participação de profissionais que em sua maioria possui pós-graduação e mais de 9
(nove) anos de experiência pode ser considerada uma ameaça à pesquisa.
Deve-se ressaltar ainda que, embora a aplicação da pesquisa tenha obtido
respostas de participantes de diferentes organizações e regiões do Brasil, não é possível
generalizar os resultados para diferentes contextos. Para isso, seria necessária a
realização de pesquisas com amostras selecionadas por meio de princípios
probabilísticos. Contudo, este fato não invalida a importância dos resultados obtidos.
Outros aspectos podem afetar a validade dos resultados, segundo [Kitchenham e
Pfleeger 2002d]: validação, codificação e análise dos dados. Com relação à Validação
dos Dados, foram descartadas as duas respostas que, nas questões subjetivas,
apresentavam caracteres especiais que não traduziam nenhum texto. Como nenhum
outro filtro foi aplicado, é possível considerar esse aspecto como uma ameaça mínima à
validade do estudo.
Outra ameaça potencial está relacionada com a Codificação dos Dados. Embora
os dados crus obtidos durante a aplicação do questionário não tenham sido manipulados,
na análise dos resultados foram definidos dois grupos com relação ao contato com o
cliente: Grupo A com profissionais que possivelmente possuem mais contato com o
cliente (Gerentes de Projeto, Analistas de Negócio e Analistas de Sistema) e Grupo B
com profissionais que, em geral, atuam mais internamente nas organizações (Analistas
de Qualidade, Analistas de Testes, Arquitetos, Desenvolvedores e Pesquisadores). Essa
classificação foi estabelecida levando em consideração as atribuições dos papéis de
acordo com a informação dada pelo participante.
O terceiro aspecto é a própria Análise dos Dados, considerando que a principal
limitação da análise quantitativa está relacionada com a falta de controle sobre a
coerência das respostas por não utilizar um método para avaliar a confiabilidade. Como
231
discutido anteriormente, foram buscadas respostas com algum padrão de repetição nos
diversos itens objetivos e não foi encontrado qualquer registro que configurasse essa
prática. Além disso, os participantes informaram o e-mail de contato ao preencher o
formulário e nenhuma participação repetida foi identificada.
Com relação à questão qualitativa, o principal fator de limitação deste trabalho é
o número de respostas úteis recebidas, levando em consideração a população de
profissionais que atuam com desenvolvimento de software. Como verificado nos
trabalhos relacionados, a participação de profissionais em investigações relacionadas é
menor, muitas vezes representando poucas organizações. Quando comparado com os
estudos anteriores, esta pesquisa contou com a participação de uma quantidade maior de
profissionais, além de estarem distribuídos geograficamente por todas as regiões do
Brasil.
5. Comparação com os Trabalhos Relacionados

O trabalho aqui apresentado difere dos trabalhos relacionados [Ameller et al. 2012;
Borg et al. 2003; Phillips, Aurum e Svensson 2012; Svensson, Gorschek e Regnell
2009; Svensson et al. 2011; Vara et al. 2011] por apresentar as subcaracterísticas de
RNFs que, na opinião dos diferentes profissionais que atuam com desenvolvimento de
software, podem ser solicitadas pelo cliente, além daquelas que somente uma equipe
com conhecimentos técnicos é capaz de definir. Além disso, assim como as demais
investigações a respeito da elicitação de RNFs, este estudo demonstrou também que o
assunto abordado ainda representa um desafio para a engenharia de requisitos.
A Tabela 6 apresenta a comparação desta investigação com os outros estudos
relacionados com relação aos objetivos do estudo e à quantidade participações na
pesquisa.
Tabela 6. Comparação com os trabalhos relacionados
[Bor [Svensson, [Var [Phillips,

[Svensson [Ameller
Este g et Gorschek a et Aurum e
Característica et al. et al.
Estudo al. e Regnell al. Svensson
2011] 2012]
2003] 2009] 2011] 2012]
Investiga a situação da
elicitação de RNFs em Sim Sim P P P P P
organizações?
A pesquisa captura a
opinião dos profissionais
sobre quais RNFs podem Sim Não Não Não Não Não Não
ser elicitadas com o
cliente?
Quantidade de
98 14 10 22 35 13 82
participantes na pesquisa
Legenda: P (o trabalho relacionado responde apenas parcialmente à questão).
6. Conclusão
Realizar um survey não é uma atividade trivial e, ao contrário de um experimento,
muitas vezes não é possível repetir, principalmente em um domínio como o da
232
engenharia de software em que é difícil obter participantes. Dessa forma, algumas lições
aprendidas com a realização deste estudo são listadas a seguir:
 Considerando a difusão dos métodos ágeis em que os profissionais técnicos
também podem envolver-se com os clientes, o formulário poderia conter uma
pergunta para indicar, independente do papel assumido pelo profissional, se o
participante possui, ou não, contato direto com o cliente.
 A Parte III da pesquisa, que trata dos requisitos que podem ser solicitados pelos
clientes, poderia ter sido enviada para os autores de trabalhos relacionados com a
elicitação de RNFs para obter também a opinião de estudiosos da área.
 Além disso, seria interessante haver questões para identificar a familiaridade do
participante com RNFs e com os conceitos presentes na norma utilizada, a fim
de evitar vieses durante o preenchimento do formulário.
 O escopo da pesquisa poderia ser dividido de forma a tratar na primeira parte
apenas a situação das empresas quanto à elicitação dos RNFs e, apenas em um
segundo momento, tratar das características que são consideradas aplicáveis ao
cliente. Dessa forma, o questionário poderia ser simplificado, evitando a taxa de
fadiga da pesquisa e, adicionalmente, optando por realizar entrevistas mais
específicas com os profissionais.
Embora tenham sido feitas análises abordando diferentes visões: profissionais
com contato com o cliente (Grupo A), sem contato com o cliente (Grupo B), de
organizações públicas e de organizações privadas; algumas subcaracterísticas de
requisitos não-funcionais apareceram no topo das listas dos requisitos, isto é, mais de
50% dos participantes afirmaram que estas subcaracterísticas podem ser elicitadas pelo
cliente. Entre elas, pode-se destacar aquelas relacionadas com Adequação Funcional e
Usabilidade, presentes na opinião de todos os grupos. Essas características estão mais
relacionadas com aquilo que o cliente ou usuário final da aplicação é capaz de perceber
mais facilmente quando o software é finalizado. A seguir são listadas as características
mais pontuadas por cada grupo:
 Grupo A - Adequação Funcional e Usabilidade.
 Grupo B - Adequação Funcional, Confiabilidade, Segurança e Usabilidade.
 Organizações Públicas - Adequação Funcional, Segurança e Usabilidade.
 Organizações Privadas - Adequação Funcional e Usabilidade.
No entanto, de maneira geral, os profissionais acreditam que a maioria dos tipos
de RNFs não pode ser solicitada pelo cliente da aplicação em virtude da falta de
conhecimento técnico necessário. De qualquer forma, esses requisitos, independente da
capacidade do cliente, devem ser abordados na fase de elicitação, pois negligenciar esses
requisitos pode contribuir para o fracasso do projeto.
Algumas oportunidades de trabalhos futuros foram identificados durante este
estudo. Por exemplo, realizar uma pesquisa com autores de trabalhos voltados para
elicitação de RNFs para obter a opinião desses pesquisadores a respeito do
envolvimento do cliente nesse processo. Da mesma forma, uma pesquisa para identificar
como os RNFs são abordados no planejamento de tempo e custo dos projetos. Além
233
disso, uma pesquisa para identificar como os RNFs são tratados pelos desenvolvedores
de software também é uma das oportunidades de pesquisa para continuar este estudo.
Agradecimentos
O autor P. R. Pinheiro agradece ao Conselho Nacional de Desenvolvimento Científico e
Tecnológico (CNPq) pelo Grant #475239/2012-1.
Referências
Ameller, D. et al. (2012) “How do Software Architects Consider Non-functional
Requirements: An Exploratory Study”, In: 2012 20th IEEE International
Requirements Engineering Conference, pp. 41-50.
Borg, A. et al. (2003) “The Bad Conscience of Requirements Engineering: An
Investigation in Real-world Treatment of Non-functional Requirements”, In: Third
Conference on Software Engineering Research and Practice in Sweden, pp. 1-8.
Cysneiros, L. M. (2000), Requisitos Não Funcionais: Da Elicitação ao Modelo
Conceitual, Tese de Doutorado, Pontifícia Universidade Católica do Rio de Janeiro
(PUC-RJ).
Dorr, J. et al. (2003) “Eliciting Efficiency Requirements with Use Cases”, In:
Proceedings of the International Workshop on Requirements Engineering:
Foundations of Software Quality.
International Organization for Standardization - ISO (2011), ISO/IEC 25010 - Systems
and software engineering / Systems and software Quality Requirements and
Evaluation (SQuaRE) / System and software quality models.
Kitchenham, B. A. and Pfleeger, S. L. (2001). “Principles of Survey Research - Part 1:
Turning Lemons into Lemonade”. In: SIGSOFT Softw. Eng. Notes, vol. 26, no. 6,
pages 16-18.
Designing a Survey”. In: SIGSOFT Softw. Eng. Notes, vol. 27, no. 1, pages 18-20.
Constructing a Survey Instrument”. In: SIGSOFT Softw. Eng. Notes, vol. 27, no. 2,
pages 20-24.
Questionnaire Evaluation”. In: SIGSOFT Softw. Eng. Notes, vol. 27, no. 3, pages 20-
23.
Populations and Samples”. In: SIGSOFT Softw. Eng. Notes, vol. 27, no. 5, pages 17-
20.
Data Analysis”. In: SIGSOFT Softw. Eng. Notes, vol. 28, no. 2, pages 24-27.
Phillips, L. B., Aurum, A. and Svensson, R. B. (2012) “Managing Software Quality
Requirements”, In: 2012 38th Euromicro Conference on Software Engineering and
Advanced Applications, pp. 349-356.
234
Rahman, M. M. and Ripon, S. (2013). “Elicitation and Modeling Non-Functional
Requirements - A POS Case Study”. In: International Journal of Future Computer
and Communication, vol. 2, no. 5, pages 485-489.
Rao, A. A. and Gopichand, M. (2011). “Four Layered Approach to Non-Functional
Requirements Analysis”. In: International Journal of Computer Science Issues, vol.
8, no. 2, pages 371-379.
Silva, A., Pinheiro, P. and Albuquerque, A. (2016) “A Brief Analysis of Reported
Problems in the Use of Function Points”, In: Software Engineering Perspectives and
Application in Intelligent Systems: Proceedings of the 5th Computer Science On-line
Conference 2016 (CSOC2016), vol 2, pp. 117-126, Cham.
Silva, A. et al. (2016) “A Process for Creating the Elicitation Guide of Non-functional
Requirements”, In: Software Engineering Perspectives and Application in Intelligent
Systems: Proceedings of the 5th Computer Science On-line Conference 2016
(CSOC2016), vol 2, pp. 293-302, Cham.
Silva, A. et al. (2016) “A Survey About the Situation of the Elicitation of Non-
Functional Requirements”, In: 2016 11th Iberian Conference on Information Systems
and Technologies, pp. 1-6.
Sindre, G. and Opdahl, A. L. (2005). “Eliciting Security Requirements with Misuse
Cases”. In: Requirements Engineering, vol. 10, no. 1, pages 34-44.
Slankas, J. and Williams, L. (2013) “Automated extraction of non-functional
requirements in available documentation”, In: 2013 1st International Workshop on
Natural Language Analysis in Software Engineering (NaturaLiSE), pp. 9-16.
Svensson, R. B., Gorschek, T. and Regnell, B. (2009) “Quality Requirements in
Practice: An Interview Study in Requirements Engineering for Embedded Systems”,
In: Proceedings of the Requirements Engineering: Foundation for Software Quality:
15th International Working Conference, pp. 218-232.
Svensson, R. B. et al. (2011) “Prioritization of Quality Requirements: State of Practice
in Eleven Companies”, In: 2011 IEEE 19th International Requirements Engineering
Conference, pp. 69-78.
Vara, J. L. et al. (2011) “An Empirical Study on the Importance of Quality
Requirements in Industry”, In: 23rd International Conference Software Engineering
and Knowledge Engineering, pp. 438-443.
Wang, T. et al. (2010) “A QoS Ontology Cooperated with Feature Models for Non-
functional Requirements Elicitation”, In: Proceedings of the Second Asia-Pacific
Symposium on Internetware, pp. 17:1-17:4.
Zhang, C. and Budgen, D. (2013). “A Survey of Experienced User Perceptions About
Software Design Patterns”. In: Inf. Softw. Technol., vol. 55, no. 5, pages 822-835.
235
Avaliação por experiência de usuário de ferramentas que
apoiam a engenharia de requisitos no contexto de Micro e
Pequenas Empresas
Adailton F. Araújo1 , Juliano L. Oliveira 1 , Bruno N. Machado1 ,
Almir F. Silva 2 , Jailton A. Louzada 2 , Paulo M. S. Rodrigues 2
1
Instituto de Informática – Universidade Federal de Goiás (UFG)
74001-970 – Goiânia – GO – Brasil
2
Decisão Sistemas
Rua Uberaba Qd 77 Lt 9 Jd Luz 74915-440 – Goiânia – GO – Brasil
{adailton,juliano,brunonunes}@inf.ufg.br
{almir,jailton,paulomarcos}@decisaosistemas.com.br
Abstract. Research in Software Requirements Engineering (SRE) have develo-

ped solutions to various problems of the area. However, such solutions are
focused to the environments of large organizations. This paper answers the fol-
lowing research question: The existing tools to support the SRE are appropriate
to the context of MSEs producing software? To answer this question was made
an selection and empirical assessment of tools for SRE, based on characteris-
tics presented by the ISO 24766 standard. The results showed that the evaluated
tools are inappropriate for the needs of MSEs. The obtained findings confirm
and extend similar results from the literature and point to the need to evolve the
ERS tools to contemplate the idiosyncrasies of MSEs.
Resumo. As pesquisas em Engenharia de Requisitos de Software (ERS) têm de-

senvolvido soluções para diversos problemas da área. Todavia, tais soluções
são focadas para os ambientes das grandes organizações. Este trabalho res-
ponde a seguinte questão de pesquisa: As ferramentas existentes para apoiar
a ERS são adequadas para o contexto de MPEs produtoras de software? Para
responder essa questão foi realizada uma seleção e avaliação empı́rica de fer-
ramentas para ERS, com base em caracterı́sticas apresentadas pela norma ISO
24766. Os resultados apontaram que as ferramentas avaliadas não são apro-
priadas para as necessidades das MPEs. As conclusões obtidas confirmam e
estendem resultados similares disponı́veis na literatura e apontam a necessi-
dade de evoluir as ferramentas ERS para contemplarem as idiossincrasias das
MPEs.
1. Introdução
Organizações de pequeno porte representam 99,2 % da indústria de software mundial
[Qyser et al. 2008] e 93% da indústria de software brasileira [ABES 2014]. Apesar des-
ses números, em geral, organizações de pequeno porte que atuam na produção de soft-
ware enfrentam muitas dificuldades para serem reconhecidas como desenvolvedoras de
236
software de qualidade [Laporte et al. 2008]. Um dos fatores chave para obter essa qua-
lidade é a Engenharia de Requisitos de Software (ERS), uma disciplina da Engenharia
de Software que envolve a descoberta, documentação e evolução dos requisitos de um
produto de software [Hull et al. 2011].
A complexidade e dimensão dos softwares atuais exigem que a ERS seja apoiada
por ferramentas de software apropriadas. O mercado atual disponibiliza diversas ferra-
mentas de apoio a ERS. Todavia, essas ferramentas para ERS não consideram a realidade
de uma micro ou pequena empresa (MPE), que diferentemente de grandes organizações,
as MPEs possuem recursos humanos limitados, tanto em termos quantitativos quanto qua-
litativos, para desempenhar o processo de ER. Por isso, as MPEs demandam processos e
ferramentas prescritivos e prontos para usar, pois não possuem recursos disponı́veis para
customizações. Além do custo direto das mudanças, as customizações exigem esforço
adicional para garantir a integração e consistência das caracterı́sticas customizadas. Uma
MPE não possui recursos humanos capacitados para isso.
Nessa linha, verificou-se que poucos trabalhos têm sido conduzidos com foco na
avaliação dessas ferramentas. Além disso, os estudos disponı́veis são limitados quanto à
representação da realidade atual das ferramentas para ERS, ou quanto à adoção de dire-
trizes objetivas para avaliação de ferramentas [Carrillo De Gea et al. 2012]. Dessa forma,
há pouco conhecimento sobre ferramentas para ERS e, quando se considera a realidade de
pequenas organizações desenvolvedoras de software, esse conhecimento é ainda menor.
O objetivo deste artigo é diminuir essa lacuna de conhecimento, identificando e
avaliando ferramentas que apoiam a ERS e, mais especificamente, considerando os dife-
renciais de organizações de pequeno porte com relação à execução do processo de ERS.
Nesse sentido, destaca-se como contribuição deste trabalho de pesquisa a apresentação de
um panorama consolidado de ferramentas para ERS sob a ótica de capacidades voltadas
para o contexto de organizações classificadas como micro ou pequenas empresas produ-
toras de software. O restante do artigo está organizado da seguinte forma. A Seção 2 des-
creve a metodologia de pesquisa empregada. A Seção 3 apresenta os resultados obtidos
na avaliação empı́rica das ferramentas. A Seção 4 analisa e discute esses resultados, esta-
belecendo um mapeamento do conhecimento sobre ferramentas de ERS e sua adequação
ao contexto de MPE. Por fim, a Seção 5 sintetiza as contribuições e conclusões deste
trabalho e indica direções para trabalhos futuros.
2. Metodologia
Os resultados apresentados neste artigo foram desenvolvidos no contexto de um projeto
de pesquisa maior, cuja metodologia compreende as seguintes fases: (1) mapeamento sis-
temático da literatura para identificar o estado da arte no processo de ERS; (2) seleção
de ferramentas de software que apoiam esse processo; (3) identificação de particularida-
des desse processo quando aplicado no contexto de MPE; (4) sı́ntese de caracterı́sticas
de ferramentas para ERS que contemplam essas particularidades; (5) avaliação empı́rica
da adequação das ferramentas selecionadas a essas caracterı́sticas; (6) comparação en-
tre ferramentas para identificar as mais adequadas ao contexto de MPE; e (7) avaliação
empı́rica de ferramentas para confirmar sua adequação ao contexto de MPE e para iden-
tificar possı́veis pontos de melhoria. Por limitações de espaço, o presente artigo discute
exclusivamente os resultados da quinta fase desse projeto de pesquisa. O restante desta
237
seção sintetiza alguns dos resultados de fases anteriores que são necessários para compre-
ender a avaliação de ferramentas descrita neste artigo.
O ponto de partida para classificar caracterı́sticas de ferramentas para ERS foi
o guia apresentado em [ISO/IEC/IEEE 2009]. Esse guia descreve cerca de cento e cin-
quenta recursos que uma ferramenta de ERS deveria oferecer e, consequentemente, o
conjunto de atividades que as ferramentas deveriam apoiar. Ele classifica esses recursos
em cinco categorias relacionadas a ERS (eliciação, análise, especificação, verificação e
validação, e gerência de requisitos) e define uma categoria para outros tipos de recursos.
No entanto, o conjunto de capacidades definidas pelo guia é muito extenso e com-
plexo para ser aplicado em MPE. Assim, optou-se por elencar um subconjunto de carac-
terı́sticas essenciais para o contexto de MPE, tendo como base as caracterı́sticas originais
do guia. A extração desse subconjunto de caracterı́sticas foi realizada nas duas etapas
descritas a seguir.
Na primeira etapa, a lista de caracterı́sticas foi avaliada por três professores pes-
quisadores, que possuem mais de cinco anos de experiência prática e de pesquisa com
ERS, sendo um doutor e dois mestres. Nesta etapa, cada pesquisador avaliou individual-
mente o nı́vel de adequação de cada caracterı́stica ao contexto de MPE, usando os seguin-
tes parâmetros: Indispensável, Muito importante, Importante ou Dispensável. Logo em
seguida, houve uma reunião entre os pesquisadores para avaliar os pontos de divergência
entre as respostas dos três pesquisadores. Nesta reunião cada avaliador expôs suas justifi-
cativas para suas avaliações, onde chegou-se a um senso comum sobre as avaliações que
possuı́am divergências.
Na segunda etapa, o subconjunto de caracterı́sticas classificadas como Indis-
pensável e Muito Importante, na primeira etapa, foi avaliado por cinco profissionais,
sendo três especialistas e dois mestrandos, que já atuaram com ERS em MPEs e par-
ticiparam de uma revisão sistemática sobre o tema, que avaliou mais de 500 trabalhos
cientı́ficos. Nesta etapa, cada profissional avaliou individualmente o nı́vel de adequação
de cada caracterı́stica ao contexto de MPE, usando os mesmos parâmetros da primeira
etapa. Além desta classificação, o profissional também teve a opção de indicar se sentiu
falta de mais alguma caracterı́stica. A lista de sugestões também foi avaliada por todos
os profissionais. Ao final, as caracterı́sticas avaliadas como Indispensável e Muito Impor-
tante, pela maioria dos profissionais, constituı́ram a lista final, com as trinta caracterı́sticas
listadas na Tabela 1.
A busca por ferramentas para ERS foi realizada por meio do mapeamento da li-
teratura que identificou um trabalho recente que descreve um conjunto de ferramentas
relevantes para ERS [Carrillo De Gea et al. 2012]. Dentre essas ferramentas foram avali-
adas no presente trabalho todas as que ofereciam acesso livre ou versão de demonstração.
A Tabela 2 identifica as ferramentas avaliadas.
Um critério fundamental adotado na avaliação das ferramentas foi o de levar em
consideração apenas funcionalidades predefinidas nas ferramentas para atendimento es-
pecı́fico de cada caracterı́stica avaliada. Logo, não foi considerada qualquer forma de
adaptação ou de criação de novas funções e tampouco foram avaliadas soluções de con-
torno oferecidas pela ferramenta para atender determinada caracterı́stica. Esse critério de
avaliação se baseia no fato de que MPE precisam de ferramentas que possam ser aplica-
238
Tabela 1. Caracterı́sticas Relevantes para ERS em MPE
Categoria Caracterı́sticas
Elicitação (EL) EL1-Descrever o Mundo Real (Domı́nio do Problema); EL2-Manter glossário
de conceitos; EL3-Identificar e classificar stakeholders; EL4-Associar arquivos
com necessidades e requisitos identificados; EL5-Priorizar requisitos; EL6-Editar
relações entre requisitos; EL7-Apoiar técnicas de eliciação de requisitos.
Análise (AN) AN1-Descrever o Software (Domı́nio da Solução); AN2-Identificar e classificar
modelos associados aos requisitos; AN3-Editar atributos para descrever requisitos;
AN4-Editar protótipos de requisitos; AN5-Reutilizar especificações de requisitos.
Especificação (ES) ES1-Manter templates para especificação de requisitos; ES2- Ordenar os requisitos
em documento de especificação de requisitos; ES3-Visualizar e exportar documento
de especificação de requisitos.
Verificação e Validação VV1-Verificar a qualidade técnica dos requisitos; VV2-Validar (aprovar) requisitos
(VV) individualmente ou por grupo.
Gerência (GE) GE1-Controlar o acesso aos requisitos; GE2-Controlar mudanças em baselines de
requisitos; GE3-Controlar o versionamento de requisitos; GE4-Controlar conteúdo
das baselines de requisitos; GE5-Manter rastreabilidade entre requisitos e outros
produtos de trabalho.
Outros Recursos (OT) OT1-Executar em múltiplas plataformas; OT2-Oferecer mecanismos de busca
flexı́veis; OT3-Prover usabilidade e qualidade em uso; OT4-Editar documentos
cooperativamente; OT5-Realizar comunicações relacionadas ao processo de ERS;
OT6-Prover ambiente de projeto para ERS; OT7-Orientar o processo de ERS; OT8-
Corrigir ortografia de textos.
Tabela 2. Ferramentas Avaliadas

ID Ferramenta Versão Link
F1 Caliber RM 11.3 http://www.borland.com/Products/ Requirements-Management
F2 Cameo Requirements+ 18.0 http://www.magicdraw.com/cameoreq
F3 CaseComplete 9.2.5332 http://casecomplete.com/
F4 DOORS 5.0 http://www-01.ibm.com/ software/awdtools/doors/
F5 Enterprise Architect 1107 http://www.sparxsystems.com/ products/ea/
F6 Jama 3.6.3 http://www.jamasoftware.com/
F7 OSRMT 1.5 http://sourceforge.net/projects/osrmt/
F8 Polarion 3.8.3 http://www.polarion.com/products/ requirements/index.php
F9 QPack 6.0.3.72 http://www.orcanos.com/ Requirements management.html
F10 RaQuest 4.1 http://www.raquest.com/
F11 ReqMan indefinida http://www.requirementone.com
F12 Rommana 14.2 http://www.rommanasoftware.com/
http://www.serena.com/index.php/ en/products/other-products/
F13 Serena 3.2.1
prototype-composer/
F14 SpiraTeam 4.1.0.5 http://www.inflectra.com/ SpiraTest/Default.aspx
F15 TraceCloud indefinida http://www.tracecloud.com
F16 TrackStudio 3.5 http://www.trackstudio.com/
F17 Visual Studio 2013.2 https://www.visualstudio.com/
das de forma simples e direta, pois não há recursos humanos disponı́veis para lidar com
adaptação de ferramentas. Dessa forma, a avaliação verificou, para cada caracterı́stica, se
a ferramenta apresenta funcionalidade pronta para ser utilizada.
O grau de atendimento de cada caracterı́stica em cada ferramenta foi avaliado com
base em uma escala de quatro valores: T para caracterı́stica totalmente atendida; L para
largamente; P para parcialmente; e N para caracterı́stica não atendida. Essa avaliação
seguiu o seguinte procedimento em cada ferramenta avaliada:
1. Obtenção da ferramenta: instala a ferramenta, quando necessário, e efetua a sua
239
configuração inicial (usuário, permissões, preferências, etc.). Para ferramenta proprietária
(com restrições de acesso) foi considerada apenas a versão de demonstração disponibili-
zada pelo fornecedor.
2. Ambientação com a ferramenta: explora os recursos funcionais e a documentação de
apoio disponı́vel para a ferramenta, sem foco nas caracterı́sticas a serem avaliadas.
3. Avaliação da ferramenta: pesquisa as funcionalidades relacionadas com cada carac-
terı́stica, explorando a interface, a documentação e o portal da ferramenta (se disponı́vel).
4. Classificação da ferramenta: classifica cada caracterı́stica em relação ao grau de atendi-
mento pela ferramenta, conforme a escala definida.
5. Registro da avaliação: documenta os aspectos relevantes de cada ferramenta em relação a
cada caracterı́stica avaliada.
A avaliação empı́rica de cada ferramenta em relação às caracterı́sticas essenciais
de ERS apontadas para o contexto de MPE gerou uma matriz com 510 células valoradas
com T, L, P ou N, correspondendo a 30 caracterı́sticas avaliadas em 17 ferramentas. Após
essa avaliação, realizou-se uma análise quantitativa e qualitativa dos resultados, a fim de
identificar correlações e tendências relacionadas ao atendimento das caracterı́sticas ava-
liadas pelo conjunto de ferramentas disponı́veis para ERS. Os resultados dessas análises
são descritos no restante deste artigo.
3. Resultados das Avaliações

Esta seção apresenta os resultados da avaliação qualitativa das caracterı́sticas identifica-
das na Tabela 1 nas ferramentas selecionadas para avaliação, definidas na Tabela 2. As
avaliações estão agrupadas de acordo com as categorias de requisitos para ferramentas de
ERS propostas em [ISO/IEC/IEEE 2009].
3.1. Eliciação de Requisitos

A Eliciação de Requisitos identifica os stakeholders envolvidos no Domı́nio do Problema
e descreve suas expectativas e necessidades com relação ao software que é objeto do
processo de ERS [Burnay et al. 2014].
EL1 - Descrever o Domı́nio do Problema: o Domı́nio do Problema também é
referenciado na literatura como ambiente do sistema, domı́nio de aplicação, contexto
do problema, entre outros termos. Independentemente do termo usado para designar o
Domı́nio do Problema, há consenso de que é essencial para a ERS a descrição explı́cita
dos conceitos do mundo real em que o software irá atuar. Apesar de ser uma caracterı́stica
essencial para a ERS, as ferramentas analisadas não oferecem funcionalidades especı́ficas
para apoiar a descrição do Domı́nio do Problema.
EL2 - Manter glossário de conceitos: F1, F2, F4, F5 e F10 oferecem funcionali-
dades para manter um glossário de dados. Tipicamente, o usuário identifica e explica os
termos usados no sistema por meio de formulários de cadastro de termos.
EL3 - Identificar e classificar stakeholders: das ferramentas avaliadas, apenas F4
oferece apoio a identificação e classificação de stakeholders. Nela é possı́vel, por exem-
plo, atribuir todos os stakeholders ao criar um projeto e customizar e-mails com textos
predefinidos por projeto, bem como monitorar e rastrear as iterações dos stakeholders na
ferramenta. As demais ferramentas oferecem apenas mecanismos genéricos para cadastro
de usuários e/ou membros do Projeto.
240
EL4 - Associar arquivos com necessidades e requisitos identificados: F10 e F13
não permitem anexar e associar arquivos. Já as ferramentas F1, F3, F5, F6, F7, F9, F11,
F12, F14, F15, F16 e F17 permitem anexar e associar arquivos aos requisitos na forma de
objeto, ou seja, o arquivo anexado não se torna um artefato independente e rastreável. F2
e F8 possibilitam a incorporação de arquivos e imagens que podem ser observados dentro
dos artefatos criados na ferramenta.
EL5 - Priorizar requisitos: somente F10 oferece apoio especı́fico para priorização
de requisitos. As demais ferramentas apresentam apenas um atributo do requisito onde
pode ser atribuı́do o valor que representa sua prioridade.
EL6 - Editar relações entre requisitos: com exceção de F9 e F16, todas as ferra-
mentas oferecem algum apoio à edição de relações entre requisitos. Nessas ferramentas
as ligações entre requisitos podem ser realizadas no momento em que cada requisito é
identificado ou posteriormente.
EL7 - Apoiar técnicas de eliciação de requisitos: diversas técnicas podem ser apli-
cadas no processo de ERS. Na avaliação das ferramentas foram observadas as seguintes
técnicas: 1) Análise de Domı́nio; 2) Análise de Cenários; 3) Entrevista e Questionário; 4)
Análise de Documentos; 5) Etnografia; 6) Workshop, JAD, Brainstorming e outros tipos
de reuniões; 7) Análise Orientada a Objetos e 8) Análise de Processos de Negócio.
As técnicas 1, 2, 5 e 6 não são apoiadas pelas ferramentas avaliadas. Já a técnica
2 é apoiada por F3, F5 e F13. A técnica 3 é apoiada por F1, F11 e F17. As técnicas 7 e 8
são apoiadas apenas por F4, F5 e F8.
3.2. Análise de Requisitos

A Análise de Requisitos define modelos para a solução de software que atende as neces-
sidades identificadas [ISO/IEC/IEEE 2011].
AN1 - Descrever o Software (Domı́nio da Solução): enquanto o Domı́nio do Pro-
blema estabelece o escopo de necessidades para a ERS, o Domı́nio da Solução define as
caracterı́sticas essenciais do software que precisa ser construı́do para atender a essas ne-
cessidades. Da mesma forma que as ferramentas não contemplam diretamente a descrição
do Domı́nio do Problema, elas também não oferecem funcionalidades especı́ficas para
apoiar a descrição do Domı́nio da Solução.
AN2 - Identificar e classificar modelos associados aos requisitos: todas as ferra-
mentas avaliadas fornecem algum apoio à identificação de requisitos com base em mo-
delos, que podem ser simples, contendo apenas tı́tulo e descrição do requisito, ou sofis-
ticados, com diversas seções e usando metadados personalizados. F1, F6, F9, F12, F15,
F16 e F17 não oferecem apoio direto para classificação de requisitos, embora F1, F15 e
F16 permitam criar uma estrutura hierárquica de pastas para classificar requisitos. F2 e
F7 oferecem formulários para escrever requisitos, anexar imagens, e criar tabelas, além
de prover uma barra de ferramenta para edição. F7 permite criar requisitos com tipos pre-
definidos, no entanto não é possı́vel alterar o tipo do requisito após sua criação. F3, F5,
F8, F10, F11, F13 e F14 oferecem um campo para indicar o tipo do requisito, permitindo
a classificação dos requisitos em funcionais ou não funcionais e suas subclassificações.
F8 trabalha com o mecanismo de selecionar declarações textuais e transformá-las em re-
quisitos. Para realizar a classificação, é necessário criar uma seção ou um documento que
241
irá abordar determinado tipo (ou classe) de requisito. F4 permite criar requisitos a partir
de outros requisitos e a classificação de requisitos ocorre de diversas maneiras. É possı́vel
criar e classificar tipos de requisitos e atribuir modelos aos tipos criados.
AN3 - Editar atributos para descrever requisitos: F2, F3, F6, F10, F12, F13, F14
e F17 apresentam um conjunto de atributos nativos para descrição de requisitos, e não
permitem a criação de novos atributos. F1, F4, F5, F7, F11, F15 e F16 oferecem atributos
nativos e também permitem a criação de novos atributos para cada requisito.
AN4 - Editar protótipos de requisitos: F1, F2, F3, F6, F7, F8, F9, F10, F11, F12,
F14, F15 e F16 não oferecem apoio à prototipação. F17 permite criar protótipos e vin-
culá-los a requisitos para serem utilizados por outros interessados, mantendo a rastreabi-
lidade desses artefatos no projeto. F4 e F5 permitem a criação de wireframes e protótipos
estáticos que podem ser usados como esboços no projeto de requisitos, mantendo a ras-
treabilidade de artefatos diversos com os protótipos ou esboços de tela. F13 oferece apoio
completo à técnica de prototipação, desde a confecção das interfaces até sua aplicação em
um fluxo de atividades, sendo também possı́vel a criação de fluxos de decisões dentro do
fluxo de atividades.
AN5 - Reutilizar especificações de requisitos: F6 é a única ferramenta avaliada que
oferece apoio à reutilização de requisitos. Nela o reúso é feito por meio da sincronização
de itens de requisitos.
3.3. Especificação de Requisitos
A Especificação de Requisitos documenta e apresenta, de diferentes maneiras,

informações sobre os requisitos relevantes para diferentes stakeholders [IEEE 1998].
ES1 - Manter Templates para especificação de requisitos: F3, F6, F7, F9, F10 e
F12 não definem templates para documentação de requisitos. F1, F14, F15, F16 e F17
não oferecem templates próprios, mas permitem a importação de templates externos. F13
oferece seis templates de documentação (dicionário de dados, matriz de requisitos, fases
de processos, fluxos de atividades, mapa de processo, e interface de usuário), mas esses
templates não são parametrizáveis. F11 oferece dois templates predefinidos de relatórios,
um no formato doc e outro em formato xls. F8 traz um template padrão que pode ser
adaptado pelo usuário. Na exportação do documento, é possı́vel atribuir permissões para
definir como outros stakeholders podem interagir com o documento. EM F5, além da
visualização em forma de relatórios, há opção para visualização gráfica das informações
a partir de um modelo. Os gráficos podem ser gerados dinamicamente, com base em
informações selecionadas pelo usuário. F2 permite importação e criação de templates de
documentação usando html e oferece uma linguagem própria a fim de desenvolver tem-
plate customizado. F4 disponibiliza templates que seguem padrões predefinidos (como
IEEE, RUP, e Metodologia Ágil).
ES2 - Ordenar os requisitos em documento de especificação de requisitos: F1, F2,
F4, F7, F8, F9, F10, F11, F12, F13, F14, F15, F16 e F17 não apresentam suporte a esse
tipo de funcionalidade. F5 permite alterar a ordem e o agrupamento das informações que
compõem determinado template, exibindo uma lista para seleção das informações que
irão compor o documento.
242
ES3 - Visualizar e exportar documento de especificação de requisitos: F10 não
permite visualizar ou exportar documento de requisitos. F2, F3, F6, F7, F8, F9, F11, F12
e F13 não oferecem mecanismos de visualização do documento, mas oferecem mecanis-
mos para exportação dos requisitos. F2, F7 e F9 permitem exportar requisitos no formato
html. Além desse formato, F7 também exporta no formato pdf. F13 exporta diferentes
artefatos, porém em um único formato (doc). F11 exporta apenas os requisitos especifica-
dos, ou seja, não é possı́vel exportar outros dados, sendo oferecidos apenas dois formatos
(doc e o xls). F8 exporta nos formatos docx, pdf e rtf. No formato docx a ferramenta
oferece a possibilidade de atribuir permissões de leitura e escrita no documento expor-
tado. F1, F4, F5, F14, F15, F16 e F17 oferecem mecanismos tanto para pré-visualização
de informações gerenciadas pela ferramenta quanto para exportação dos requisitos em
artefatos. F16 exporta os requisitos apenas em formato pdf e essa exportação acontece
apenas para requisitos individuais, sem a possibilidade de exportação de um conjunto de
requisitos. F4 permite exportar requisitos em diversos formatos (pdf, doc, html e csv). Já
F5 permite exportar nos formatos docx, rtf e pdf.
3.4. Verificação e Validação de Requisitos
Verificação e Validação estão relacionadas à qualidade dos requisitos. A Verificação ava-

lia a viabilidade técnica de um conjunto de requisitos enquanto a validação registra o
comprometimento dos stakeholders com esses requisitos [ISO/IEC/IEEE 2011].
VV1 - Verificar a qualidade técnica de requisitos: das ferramentas avaliadas, ape-
nas F4 oferece mecanismos especı́ficos para verificação de requisitos. Ela permite dispo-
nibilizar verificações para um ou mais stakeholders, e fornece funções para acompanhar
e realizar verificações de requisitos.
VV2 - Validar (aprovar) requisitos individualmente ou por grupo: F3, F7, F11,
F10, F12 e F13 oferecem mecanismos de validação somente para requisitos individuais,
por meio de um campo de ”status”do requisito. F17 cria tarefas para cada demanda de
requisito, e uma dessas tarefas pode ser a de validação. Logo, as validações dos requisitos
são registradas nas tarefas e não nos requisitos. F14, F15 e F16 permitem que comentários
sejam adicionados aos requisitos, contudo não permitem que eles sejam aplicados em um
conjunto de requisitos, ou direcionam os comentários apenas para os donos/autores dos
requisitos, excluindo outros envolvidos no projeto. F1 permite que um usuário envie
comentários para os demais stakeholders sobre validação de requisitos. F5, F8 e F9 ofe-
recem mecanismos para comentar ou justificar a validação de cada requisito. F9 permite
o envio de convites para outros usuários visualizarem e inserirem comentários sobre re-
quisitos. F5 oferece um meio para auditar um conjunto de requisitos, permitindo criar um
documento com os requisitos a serem auditados e criar o pontos para serem usados como
critério de auditoria. F6 permite controlar a validação individual de requisitos. Cada
envolvido pode adicionar comentários a respeito de um cenário especı́fico, marcar um
requisito como ”aprovado”ou indicar que “necessita de mais trabalho”, além de haver su-
porte a votação. Existe também um contador para medir o tempo gasto em cada validação.
F4 permite atribuir atividades de validação para indivı́duos ou grupos envolvidos no pro-
jeto, sendo possı́vel acompanhar o andamento da atividade, o percentual concluı́do e os
comentários inseridos por cada stakeholder.
243
3.5. Gerência de Requisitos
A Gerência de Requisitos estabelece baselines de requisitos e controla mudanças

nessas baselines com base em informações de rastreabilidade de requisitos
[ISO/IEC/IEEE 2011].
GE1 - Controlar o acesso aos requisitos: F2, F10 e F13 não oferecem funcionali-
dades apropriadas ao controle de acesso. F1, F5, F6, F7, F8, F9, F11, F12, F14, F15, F16
e F17 implementam controle de acesso permitindo criar usuários e adicionar permissões
individuais ou por grupo. F4 permite o cadastro de usuários com base em perfis de acesso,
de maneira que cada usuário ou grupo de usuários pode atuar na escrita ou somente na
visualização dos requisitos.
GE2 - Controlar mudanças em baselines de requisitos: F2, F3, F7, F9, F11, F13,
F15 e F16 não possuem funcionalidades para controle de mudança em baseline. F5, F8
e F10 permitem definir baselines, identificando-as com nome e versão. Além disso, elas
permitem emitir relatórios do conteúdo de baselines, ou restaurar o projeto para alguma
baseline definida. F14 permite ainda que as baselines criadas sejam gerenciadas usando
diversos atributos. F12 oferece suporte à gestão de baselines por meio de controle de
versões de iterações. Porém, ela não oferece opção de geração de relatórios contrastando
baselines. F6 oferece esses relatórios, detalhando as atualizações de itens inseridos e de-
letados. F1 permite a criação de baselines e possibilita enviar um e-mail a cada alteração
ocorrida. F17 permite a criação de baselines e também que várias baselines sejam aces-
sadas para a verificação de mudanças. F4 permite a criação e consulta aos dados das
baselines criadas.
GE3 - Controlar o versionamento de requisitos: F2, F3, F7, F8, F9, F11, F12,
F13, F15 e F16 não apoiam versionamento dos requisitos. F1, F4, F5, F6, F10 e F14
possuem funcionalidades de versionamento similares, permitindo que as versões sejam
recuperadas por usuários com as devidas permissões. F17 permite, além de seu meca-
nismo de versionamento nativo, a integração com repositórios de versionamento externo,
como GitHub.
GE4 - Controlar o conteúdo das baselines de requisitos: F2, F3, F7, F9, F11, F13
e F15 não oferecem funcionalidades especı́ficas para controle de conteúdo de baselines
de requisitos. F1, F4, F5, F8, F10, F12, F14 e F17 oferecem esse controle, identificando
univocamente as baselines, definindo seus respectivos conteúdos e fornecendo relatórios
sobre esse conteúdo. F6 permite, ainda, emissão de relatórios para comparar versões de
diferentes baselines e acompanhar a evolução de alterações nessas baselines.
GE5 - Manter rastreabilidade entre requisitos e outros produtos de trabalho: F1,
F2, F3, F4, F6, F7, F8, F9, F11, F12, F13 e F16 não apresentam funcionalidades es-
pecı́ficas para apoiar a manutenção de informações de rastreabilidade de requisitos para
outros produtos de trabalho do software. F14 e F15 fornecem rastreabilidade apenas entre
requisitos e artefatos de teste de software. É possı́vel criar vı́nculos entre eles e gerar re-
latórios sobre estes vı́nculos. F13 permite criar ligações entre requisitos (rastreabilidade
horizontal), e também dos requisitos com interfaces e fluxos de atividades (rastreabilidade
vertical). F5 permitir criar relações com todos os artefatos internos, bem como com arte-
fatos externos, por meio de plugins e extensões para outras ferramentas. F17 fornece um
ambiente completo de desenvolvimento de software, permitindo que os requisitos possam
244
ser associados a outros produtos de trabalhos.
3.6. Outros Recursos - Ambiente para Engenharia de Requisitos
Além de prover suporte às cinco categorias funcionais do processo de ERS, uma fer-
ramenta deveria oferecer um ambiente integrado para o trabalho colaborativo sobre re-
quisitos de software [ISO/IEC/IEEE 2009]. Esse ambiente compreende caracterı́sticas
não-funcionais discutidas a seguir.
OT1 - Executar em múltiplas plataformas: F1, F2, F3, F5, F10 e F13 são ferra-
mentas desktop e funcionam em plataforma MS-Windows. F1 também executa em Apple
Mac OS X, enquanto F2, desenvolvida em Java, pode ser utilizada em outras plataformas.
F7 e F17 possuem uma parte desktop, que executa apenas em ambiente MS-Windows, e
uma parte web multiplataforma. Em F7 a versão web permite somente consulta de arte-
fatos e visualização de dados do projeto. F4, F6, F8, F9, F11, F12, F14, F15 e F16 são
ferramentas totalmente web e por isso foram classificadas como multiplataforma (no lado
cliente).
OT2 - Oferecer mecanismos de busca flexı́veis: F3, F11 e F12 não oferece fun-
cionalidades especı́ficas para busca de informações. F7, F8, F13 e F16 oferecem apenas
um campo geral para pesquisa em todo o projeto. F1 e F15 fornecem busca por palavra
chave e pelo ID do requisito. F14 permite a busca por todos os tipos de atributos relaci-
onados com os requisitos. F17 permite combinar vários atributos através de expressões
lógicas para obter uma busca direcionada. F9 tem um mecanismo de busca baseado em
filtro aplicado em documento, defeito, caso de teste, dentre outros artefatos, mas não per-
mite buscar o conteúdo presente em determinado requisito. F6 oferece suporte à busca
por meio de um filtro contendo várias seções customizáveis, com regras de ordenação de
itens, tais como ID, nome, descrição, release, dentre outros. F2 permite realizar busca com
expressões regulares ou busca por palavra completa, além de diferenciar letras maiúsculas
e minúsculas nas buscas. F5 e F10, além do campo de pesquisa geral, apresentam meca-
nismos para busca por diversos atributos e permitem combinação entre os atributos a fim
de refinar a busca. F4 permite realizar buscas por tipo de artefato, inclusive utilizando
filtros como data de modificação e autor, e também permite busca em projetos individuais
ou em todos os projetos.
OT3 - Prover usabilidade e qualidade em uso: F7, F14, F15 e F16 apresentam
interfaces pouco atrativas ou com documentação limitada. F5 e F4 possui interface ex-
tensa, o que torna o seu entendimento mais complexo. F10 trabalha integrada com F5,
porém focada em ERS. Ela permite definir a estrutura das informações na interface de
acordo com as necessidades do usuário. F8, F10, F11 e F13 possuem interface intuitiva e
de fácil aprendizagem. F3 provê boa experiência de uso por meio de um “roadmap” que
dá uma visão geral dos passos a serem seguidos no processo de ERS. F6 apresenta suas
funcionalidades por meio de um fluxo de revisão que torna o processo mais dispendioso
para ser compreendido nos momentos iniciais, mas proporciona maior eficiência para o
usuário mais experiente. F9 apresenta um painel de controle com relatórios customizáveis
e que provê uma visão geral dos requisitos do projeto. F12 apresenta uma visão geral das
suas funcionalidades em forma de “Workflows”. A navegação no fluxo de processo é feita
por abas, de forma intuitiva. F17 tem uma interface web simples e atrativa, facilitando
o entendimento e uso das funcionalidades. F1 e F2 possui uma interface parecida com a
das ferramentas MS-Office, o que passa uma sensação de familiaridade aos usuários.
245
OT4 - Editar documentos cooperativamente: F2, F3, F7, F9, F10 e F13
não apoiam o trabalho cooperativo. F12 oferece uma funcionalidade de grupos de
colaboração, porém essa funcionalidade não estava inoperante durante a avaliação da fer-
ramenta. F14, F15 e F16 são ferramentas web que permitem que vários usuários acessem
requisitos ao mesmo tempo. F1 permite que vários usuários trabalhem no mesmo re-
quisito e que se comuniquem utilizando um fórum. F17 mantém uma parte web (Team
Fundation Server) e uma parte desktop. F11 oferece mecanismos de envio de convite para
outras pessoas participarem do projeto, de acordo com o nı́vel de permissão atribuı́do. F8,
permite criar projetos em grupos, onde os envolvidos no projeto trabalham de forma si-
multânea. F6 oferece uma seção (Jama Review Center) onde os usuários podem enviar
um conjunto especı́fico de requisitos a serem revisados, de forma que stakeholders pos-
sam inserir comentários, realizar edições e sinalizar questões. F4 fornece funcionalidades
para que usuários trabalhem no mesmo documento sem que haja conflitos, permitindo
realizar comentários, realizar revisões em pares e escrever sobre o mesmo requisito.
OT5 - Realizar comunicações relacionadas ao processo de ERS: F2, F3, F7, F9,
F10, F11, F12 e F13 não oferecem funções especı́ficas para suporte a comunicações. F1,
F5, F8, F14 e F16 oferecem mecanismos de chat e/ou fórum para comunicação dentro
da ferramenta, sendo que F5 e F16 permitem criar um fórum ou chat para cada requisito.
Em F15 os envolvidos em um determinado requisito podem comunicar-se utilizando um
chat. F17 provê uma sala virtual (Team Room) onde são marcadas reuniões e os usuários
podem se comunicar de forma interativa. F6 oferece apoio ao registro de comunicações
(por meio do Jama Review Center), onde os envolvidos em determinado projeto podem
inserir anotações ou sinalizar questões e comentários. F4 permite o envio de e-mails
internos ou externos, mantendo uma rastreabilidade das conversas realizadas durante a
evolução dos requisitos.
OT6 - Prover ambiente de projeto para ERS: F1, F2, F3, F7, F8, F9, F10, F13,
F14, F15, F16 e F17 não fornecem funções especı́ficas para apoiar a gestão do projeto
de ERS. F11 permite a criação, controle e monitoramento do plano de execução do pro-
jeto de requisitos. É possı́vel criar atividades e sub atividades para cada etapa do projeto,
bem como alocar recursos e estimar tempo para realização de cada atividade. F12 e F6
oferecem apoio à gestão do projeto de engenharia de requisitos por meio de relatórios
de custo estimado por funcionalidade, tarefa, tópicos de colaboração, componentes fun-
cionais, tempo de vida do projeto, riscos e tarefas. F4 permite informar no cadastro do
projeto dados inerentes ao projeto, e monitorar alguns resultados, como percentual de
execução e linha de tempo da execução do projeto.
OT7 - Orientar o processo de ERS: F5, F13, F16 e F17 não são ferramentas espe-
cializadas em ERS. Elas apoiam atividades de ERS sem definir diretrizes ou orientações,
funcionando como uma caixa de ferramentas. F3 e a F4 são especializadas em ERS,
porém também não definem um processo de ERS especı́fico, cabendo ao usuário decidir
como conduzir a ERS. F1, F2, F6 F7, F8, F9 F10, F11, F12, F14 e F15 são ferramen-
tas especializadas em ERS que apresentam um processo de ERS definido e que serve de
orientação sobre a forma de aplicação da ferramenta no desenvolvimento de um projeto
de ERS.
OT8 - Corrigir ortografia de textos: F3, F6, F7, F9, F10, F11, F12, F13, F14 ,F15,
F16, e F17 não fornecem apoio à correção ortográfica do texto dos requisitos. F2 fornece
246
este apoio, contudo somente para texto escrito em inglês. F1, F4, F5, e F8 permitem a
correção ortográfica de requisitos com base na linguagem do projeto. A análise descrita
nesta seção evidencia que as ferramentas mais aderentes as caracterı́sticas avaliadas são
F1, F4, F5 e F17. A seção a seguir irá mostrar a consolidação e discussão dos resultados
obtidos com a avaliação.
4. Discussão dos Resultados

Esta seção analisa quantitativa e qualitativamente os resultados obtidos da avaliação
das ferramentas de ERS, visando responder a questão de pesquisa trabalhada neste ar-
tigo: qual a adequação das ferramentas existentes para ERS ao contexto de pequenas
organizações produtoras de software? A análise considera a matriz de 510 valores de
grau de atendimento resultantes do processo de avaliação das ferramentas e foca em três
perspectivas relacionadas a essa questão: a) grau de atendimento às caracterı́sticas por
categoria de recurso de ERS; b) grau de atendimento às caracterı́sticas por ferramentas de
ERS; e c) grau de atendimento às caracterı́sticas independente de categoria ou ferramenta
de ERS.
Cada caracterı́stica foi avaliada segundo os aspectos descritos na Seção 3. A ca-
racterı́stica foi avaliada como T quando todos esses aspectos foram contemplados na fer-
ramenta. Se a maior parte dos aspectos está contemplada na ferramenta, a caracterı́stica
foi avaliada como L. Se apenas alguns aspectos estão presentes, a caracterı́stica foi avali-
ada como P. Se nenhum dos aspectos avaliados está contemplado na ferramenta, a carac-
terı́stica foi avaliada como N.
A Figura 1(a) mostra, para cada categoria de recursos de ERS, o percentual de
caracterı́sticas daquela categoria avaliado com valor maior que N (Não atendida), ou seja,
o percentual de caracterı́sticas que são minimamente atendidas pelas ferramentas em cada
categoria avaliada. Por exemplo, a categoria Eliciação tem 7 caracterı́sticas avaliadas em
17 ferramentas, totalizando 119 valores, dos quais cerca de 50% são maiores que N. Esses
resultados evidenciam que as ferramentas avaliadas possuem, em todas as categorias de
recursos de ERS, lacunas em relação ao atendimento das caracterı́sticas no contexto de
MPE.
(a) Grau de Atendimento > N por Categoria. (b) Distribuição de Grau de Atendimento por Cate-
goria.
Figura 1. Grau de Atendimento por Categoria.
Embora a Figura 1(a) mostre certa uniformidade em relação ao percentual de aten-

dimento por categoria de recurso de ERS, esses percentuais não indicam que tais catego-
rias estejam sendo, de fato, bem apoiadas pelas ferramentas avaliadas. A Figura 1(b)
247
mostra que a maioria das caracterı́sticas avaliadas em cada categoria não são atendidas de
maneira completa, isto é, poucas caracterı́sticas são totalmente apoiadas (grau T) pelas
ferramentas avaliadas. Na Figura 1(b), a soma dos percentuais dos valores P, L e T para
cada categoria é igual ao percentual da respectiva categoria apresentado na Figura 1(a).
A Figura 2(a) mostra, para cada ferramenta de ERS, o percentual de caracterı́sticas
daquela ferramenta avaliado com valor maior que N (Não atendida), ou seja, o percentual
de caracterı́sticas que são minimamente atendidas pela ferramenta avaliada. Por exemplo,
a ferramenta F1 foi avaliada em 30 caracterı́sticas, totalizando 30 valores, dos quais cerca
de 70% são maiores que N. Esses resultados evidenciam que todas as ferramentas avali-
adas possuem lacunas em relação ao atendimento das caracterı́sticas de ERS no contexto
de MPE.
Vale notar que, embora F4 e F5 tenham os melhores percentuais de atendimento
na Figura 2(a), esses percentuais indicam apenas que essas ferramentas oferecem algum
tipo de apoio às caracterı́sticas avaliadas, mas não permitem avaliar se as ferramentas
apoiam bem ou mal essas caracterı́sticas. Para essa análise deve ser observada a Figura
2(b), que destaca as ferramentas da Figura 2(a) com maior e menor percentuais de aten-
dimento. Ao analisar em detalhes as ferramentas F3 e F9, que apresentaram os piores
resultados, observa-se que elas são equivalentes, visto que nos três graus de atendimento
ambas alcançaram o mesmo percentual. Já a comparação detalhada de F4 e F5 evidencia
que, mesmo tendo um percentual de atendimento maior na Figura 2(a), isso não significa
que F5 oferece melhor apoio às caracterı́sticas avaliadas. De fato, a Figura 2(b) mostra
que F4 apresenta um percentual maior de grau de atendimento T em relação às carac-
terı́sticas avaliadas, ou seja, F4 atende melhor essas caracterı́sticas do que F5.
(a) Grau de Atendimento > N por Ferramenta. (b) Distribuição de Grau de Atendimento em Fer-
ramentas.
Figura 2. Grau de Atendimento por Ferramentas.
A Figura 3(a) mostra, para cada caracterı́stica de ERS em MPE, o percentual dessa
caracterı́stica avaliado com valor maior que N (Não atendida), ou seja, o percentual da
caracterı́stica que é minimamente atendido pelas ferramentas avaliadas. Por exemplo,
a caracterı́stica EL2 foi avaliada em 17 ferramentas, totalizando 17 valores, dos quais
cerca de 24% são maiores que N. Esses resultados evidenciam que algumas caracterı́sticas
de ERS no contexto de MPE não são adequadamente contempladas pelas ferramentas
avaliadas.
Além disso, mesmo as caracterı́sticas que obtiveram 100% de atendimento na Fi-
gura 3(a) (EL3, AN2, AN3, VV2, OT1, OT3 e OT7), ou seja, caracterı́sticas contempladas
por todas as ferramentas, não são, de fato, bem atendidas pelas ferramentas. Como mostra
248
(a) Grau de Atendimento > N por Caracterı́stica. (b) Distribuição de Atendimento em Carac-
terı́sticas.
Figura 3. Grau de Atendimento por Caracterı́sticas.
a Figura 3(b), a maioria dessas caracterı́sticas são atendidas apenas de forma parcial.
Os resultados apresentados por esta seção confirmam o maior nı́vel de completude
das ferramentas F1, F4, F5 e F17, apontado na Seção 3. Entretanto, com a consolidação
e o detalhamento dos resultados da avaliação, fica evidente essas ferramentas não apoiam
de forma efetiva o processo de ERS no contexto de MPEs, pois o atendimento às carac-
terı́sticas ocorre de maneira incompleta. Além disso, mesmo que essas ferramentas tives-
sem atingido um maior nı́vel de aderência, a implantação das mesmas em MPEs poderia
se tornar inviável ao se considerar o custo para obtenção das licenças. Um levantamento
orçamentário realizado durante a avaliação das ferramentas mostrou que em 2015, para
obter uma licença para 5 usuários, uma empresa teria que arcar com R$ 40.000,00 por
ano em média para as ferramentas F1, F4, F5 e F17. Esse valor considera apenas o custo
do módulo das ferramentas que oferecem apoio à ERS e não a toda suite da ferramenta.
Logo, pode-se dizer que esse valor poderia se tornar inviável para uma MPE que tem
rendimentos anuais de até R$ 360.000,00. O mesmo não se pode dizer para as grandes
organizações que poderiam arcar também com os custos para customizações que seriam
inviáveis para MPEs.
5. Conclusões
Este trabalho apresentou um panorama de ferramentas para ERS em relação ao apoio for-
necido às caracterı́sticas essenciais para o contexto de MPE, contribuindo para o avanço
do conhecimento sobre o estado arte na ER. Os critérios utilizados na avaliação empı́rica
das ferramentas permitiram a sua análise objetiva e indicam a conclusão de que essas fer-
ramentas não fornecem suporte adequado ao processo de ERS no contexto de pequenas
organizações produtoras de software.
Outros trabalhos de pequisa avaliaram ferramentas de ERS, como por exemplo
[Carrillo De Gea et al. 2012], [Zowghi and Coulin 2005], [Carrillo de Gea et al. 2011] e
[Yahya et al. 2013]. Porém, ao contrário de trabalhos que se concentram em atividades ou
aspectos especı́ficos de ERS, como [Zowghi and Coulin 2005] e [Yahya et al. 2013], as
caracterı́sticas aqui analisadas abrangem todas as cinco principais categorias de atividades
da ERS e mais um conjunto de caracterı́sticas gerais de ferramentas de apoio a ERS.
Além disso, as avaliações discutidas neste trabalho aplicaram um método de
avaliação baseado na experiência de usuário, ou seja, avaliando a qualidade em
uso da ferramenta, diferentemente da abordagem de [Carrillo De Gea et al. 2012] e
[Carrillo de Gea et al. 2011], cujas avaliações são baseadas no relato de representantes de
vendedores de cada ferramenta e na utilização por amostragem do conjunto de ferramen-
249
tas avaliadas. Outro diferencial deste trabalho, é a avaliação com foco em caracterı́sticas
essenciais para o contexto de MPE, que muitas vezes não apresentam maturidade sufici-
ente para exercer todas as atividades do processo de ERS por completo.
Como trabalhos futuros e já em andamento, destaca-se a comparação entre as
ferramentas apresentadas neste trabalho para identificar as ferramentas mais adequadas
e as caracterı́sticas mais relevantes no contexto de MPE; a avaliação empı́rica dessas
ferramentas para confirmar sua adequação ao contexto de MPE e para identificar possı́veis
pontos de melhoria; e a construção de uma ferramenta de ERS alinhada ao contexto de
MPEs. Os autores agradecem ao CNPq e à FAPEG pelo apoio financeiro a este projeto
de pesquisa.
Referências
ABES (2014). Mercado Brasileiro de Software - Panorama e Tendências. Associação
Brasileira das Empresas de Software.
Burnay, C., Jureta, I. J., and Faulkner, S. (2014). What stakeholders will or will not
say: A theoretical and empirical study of topic importance in requirements engineering
elicitation interviews. Information Systems, 46(1):61–81.
Carrillo de Gea, J., Nicolas, J., Aleman, J., Toval, A., Ebert, C., and Vizcaino, A. (2011).
Requirements engineering tools. Software, IEEE, 28(4):86–91.
Carrillo De Gea, J. M., Nicolás, J., Fernández Alemán, J. L., Toval, A., Ebert, C., and
Vizcaı́No, A. (2012). Requirements engineering tools: Capabilities, survey and asses-
sment. Inf. Softw. Technol., 54(10):1142–1157.
Hull, E., Jackson, K., and Dick, J. (2011). Requirements engineering. Springer, 3rd
edition.
IEEE (1998). IEEE Standard 830-1998 - Recommended Practice for Software Require-
ments Specifications. IEEE.
ISO/IEC/IEEE (2009). TR 24766: Information technology - Systems and software engi-
neering - Guide for requirements engineering tool capabilities. ISO.
ISO/IEC/IEEE (2011). Standard 29148-2011 - Systems and software engineering - Life
cycle processes - Requirements Engineering. ISO.
Laporte, C., Alexandre, S., and Renault, A. (2008). Developing international standards
for very small enterprise. Computer, 41(3):98–101.
Qyser, A. A. M., Ramachandram, S., and Ashraf, M. A. (2008). An evolutionary software
product development process for small and medium enterprises. In 4th International
Conference on Emerging Technologies - ICET, pages 298–303. IEEE.
Yahya, S., Kamalrudin, M., and Sidek, S. (2013). A review on tool supports for security
requirements engineering. In IEEE Conference on Open Systems (ICOS), pages 190–
194. IEEE.
Zowghi, D. and Coulin, C. (2005). Engineering and Managing Software Requirements,
chapter Requirements Elicitation: A Survey of Techniques, Approaches, and Tools,
pages 19–46. Springer.
250
Como desenvolvedor quero utilizar user story para
representar os requisitos que levam à definição do MVP e
criação de Mockups
Taynah Almeida1, Ana Carolina Oran1, Gleison Santos2, Tayana Conte1
1
Instituto de Computação – Universidade Federal do Amazonas (UFAM)
Manaus – AM – Brasil
2
Universidade Federal do Estado do Rio de Janeiro (UNIRIO)
Rio de Janeiro – RJ – Brasil
{tmas, ana.oran, tayana}@icomp.ufam.edu.br,
gleison.santos@uniriotec.br
Abstract. User stories reflect user’s necessities and the MVP (Minimun Viable
Product) aims to validate a software product with its users. Aiming to evaluate
if user stories help to define MVP, this paper presents the results of an
empirical study. The study shows positive acceptance of user story as a way to
specify requirements, to define MVP, and build mockups, due to its ease of use
and simplicity. The results show that the defects found after mockups’
inspection are related to human factors. The results show that the defects
found after mockups’ inspection were not generated from defects inserted in
the user story’s specification, but due the fact that the participants did not
follow the specification for the building of the mockups.
Resumo. User stories refletem necessidades de um usuário e o MVP

(Minimum Viable Product) tem por objetivo validar um produto junto aos seus
usuários. Com o propósito de avaliar se user stories auxiliam na definição do
MVP, este artigo apresenta os resultados de um estudo experimental que
mostram a aceitação positiva da user story para especificar requisitos, definir
o MVP e construir mockups, em virtude da sua facilidade de uso e
simplicidade. Os resultados mostram que os defeitos encontrados após a
inspeção dos mockups não foram gerados a partir de defeitos inseridos na
especificação da user story, mas devido ao fato de os participantes não
seguirem a especificação para a construção dos mockups.
1. Introdução
No processo de desenvolvimento de software a fase de especificação de requisitos é uma
das mais importantes, qualquer erro cometido nesta fase pode comprometer todo o
projeto. Por conta disso, escolher bem a técnica que será utilizada para descrever e
documentar as funcionalidades de um sistema é essencial para que o projeto seja bem
sucedido [Agarwal e Rathod 2006].
Há diferentes formas para especificar requisitos de um sistema. Uma forma que
tem despertado interesse nas comunidades acadêmicas e industriais é a user story
utilizada no método Behavior-Driven Development (BDD ou Desenvolvimento Dirigido
251
a Comportamento). User stories, no formato utilizado em BDD, ajudam a resolver os
problemas de comunicação e validação entre stakeholders [Carrera Barroso et al. 2012],
facilitando o entendimento dos requisitos do sistema pelo time de desenvolvimento. De
acordo com Silva (2016), BDD ajuda na prevenção de problemas devido à utilização de
user stories descritas em formato de linguagem natural.
Além de descrever as necessidades dos stakeholders, utilizando as user stories
pode-se construir e validar a ideia principal de um produto junto ao cliente, através da
técnica de desenvolvimento Minimum Viable Product (MVP). MVP possibilita a criação
de um produto mínimo para que a empresa de desenvolvimento antecipe o feedback do
cliente sobre a solução proposta [Ries 2014]. Com a utilização de MVP pode-se testar o
produto e medir sua aceitação, buscando o ajuste da solução ao problema [Cooper e
Vlaskovits, 2010].
Para a definição de um MVP é necessário escolher os requisitos mínimos que
atendam às necessidades do cliente e para isso deve-se ter conhecimento dos requisitos
do produto. Com o objetivo de verificar se user stories auxiliam na definição do MVP e
na construção de mockups (representação dos aspectos da interface do usuário [Luna et
al. 2010]), este artigo descreve a condução de um estudo experimental exploratório e a
análise dos resultados, onde foi verificado a utilização da user story para especificar
requisitos, para definir o MVP e construir mockups, avaliando a aceitação e dificuldades
na utilização. Para direcionar a pesquisa, foi definida a seguinte questão de pesquisa: “A
user story auxilia na definição do MVP e construção de mockups?”. Os resultados
demonstram que as user stories possuem algumas deficiências, porém estas não
comprometem a definição do MVP. Além disso, a análise dos mockups mostrou que os
defeitos foram, em maioria, devido aos erros de fator humano.
O restante do artigo está organizado da seguinte forma: a Seção 2 apresenta a
fundamentação teórica com conceitos sobre user stories no formato utilizado em BDD,
sobre MVP e trabalhos relacionados; a Seção 3 descreve o planejamento e execução do
estudo experimental; a Seção 4 apresenta a análise dos resultados encontrados no estudo
e por fim, a Seção 5 apresenta as conclusões e ameaças à validade do estudo.
2.1 User story usada em Behavior-Driven Development

Behavior-Driven Development (BDD) é uma abordagem ágil de desenvolvimento
sugerida por Dan North (2006). Esse método surgiu em resposta aos problemas de
ambiguidade e erro de comunicação que ocorriam quando técnicos e clientes se
comunicavam no Test-Driven Development (TDD) [North 2006]. Segundo Solis e Wang
(2011), o BDD fornece uma linguagem ubíqua específica que ajuda os stakeholders a
especificar seus testes. Para North (2006), requisitos são comportamentos associados à
user stories, que capturam as funcionalidades, com cenários para especificar tais
requisitos. O autor criou um critério de aceitação para o comportamento da user story,
papel que é desempenhado pelos cenários.
As user stories são artefatos informais de linguagem natural que surgiram no
Desenvolvimento XP (Extreme Programming) [Beck 1999]. Elas são úteis na
identificação de funcionalidades de um sistema de software e fazem parte de uma
252
abordagem ágil cujo objetivo é discutir os requisitos, ajudando a especificá-los. Para
Zeaaraoui et al. (2013), as user stories consistem em descrições breves, na perspectiva
do usuário final, das funcionalidades que eles desejam ou necessitam. Na Figura 1 pode-
se verificar a estrutura de uma user story.
Figura 1: Estrutura da user story
As user stories apoiam a comunicação entre desenvolvedores e clientes, o que

permite que ambos tirem dúvidas sobre o projeto e validem as informações de requisitos
[Carrera Barroso et al. 2012]. Apesar de ter estrutura simples, elas possuem informações
que permitem estimar a dificuldade ou o consumo de tempo que o desenvolvimento
pode custar, pois podem ser decompostas em tarefas que se tornam unidades
quantificáveis de esforço de desenvolvimento [Breitman e do Prado Leite 2002].
As user stories são uma maneira simples de expressar comportamentos ou
características da necessidade do usuário. No entanto, elas possuem certa limitação, e
uma delas é ser aberta a muitas interpretações. Por melhor detalhada que uma user story
possa ser, ela não apresenta a interação do usuário com o sistema. A user story mostra
como determinada tarefa pode ser feita, e apesar de poder ser decomposta em tarefas
menores, não mostra a complexidade e nem o detalhamento da execução dessas tarefas
[Khanh 2017]. Por esse motivo, a user story, no formato apresentado na Figura 1, não é
suficiente para especificar requisitos e necessita de cenários que descrevem o
comportamento do sistema para ajudar nessa parte.
North (2006) desenvolveu um modelo para capturar o critério de aceitação da
user story que fosse estruturado em forma de cenários com comportamentos, como
apresentado na Figura 2. Cenários são descritos por Sutcliffe (1998) como “fatos
descrevendo um sistema existente e seu ambiente, incluindo o comportamento dos
agentes e informações de contexto suficientes para permitir a descoberta e validação de
requisitos do sistema”. Breitman e do Prado Leite (2000) afirmam que cenários devem
ser amplamente utilizados durante o processo de desenvolvimento de software, pois
utilizam elementos conhecidos pelos usuários e isso o torna um meio confiável de
extrair e validar informações de requisitos. O BDD propõe como formato de
especificação de requisitos a integração entre user stories e cenários, mais detalhes são
apresentados no relatório técnico [Almeida et al. 2017].
Figura 2: Estrutura do cenário utilizado em BDD
A integração das user stories com os cenários permite a especificação e o

detalhamento do comportamento do sistema em uma linguagem simples que facilita a
comunicação e compreensão dos requisitos do sistema e pode ajudar a identificar quais
253
funcionalidades são prioritárias para o usuário e devem ser incluídas no produto mínimo
viável do sistema (MVP), cujo conceito veremos a seguir.
2.2 Minimum Viable Product

O conceito de MVP (Produto Mínimo Viável, do inglês Minimum Viable Product) foi
criado aproximadamente em 2001, tornando-se popular alguns anos mais tarde, no
contexto de startups [Ries 2014]. Trata-se da identificação e implementação de um
produto que entrega valor real ao cliente [Paternoster 2014]. MVPs são definidos como
produtos com funcionalidades suficientes apenas para reunir aprendizado validado sobre
o produto e devem ter enfoque nos estágios iniciais de desenvolvimento [Duc e
Abrahamsson 2016]. É a construção da versão mais simples de um produto que pode
ser disponibilizada para negócio e que necessita de quantidade mínima de esforço e
desenvolvimento [Ries 2014].
Segundo Ries (2014), MVP é a versão do produto que garante uma volta
completa no ciclo construir-medir-aprender, com o mínimo de esforço e menor tempo
de desenvolvimento. Embora muitas funcionalidades do produto que não estão no MVP
logo sejam demandadas pelos usuários, é preciso evitar o impulso de incluí-los no
desenvolvimento inicial, pois o tempo será mais bem gasto desenvolvendo os
experimentos que medirão o impacto do MVP [Moogk 2012]. Caroli (2015) explica que
o objetivo do MVP é validar a ideia principal de um produto antes de investir tempo,
dinheiro e esforço em algo que não irá atender as expectativas do cliente. Portanto, o
MVP é uma versão mais simples de um produto, com as mínimas características
necessárias para ele ser inserido no mercado e que deve ser complementado em ciclos
posteriores de desenvolvimento.
Ries (2014) demonstra o passo a passo do processo da seguinte forma: primeiro
deve-se imaginar o problema que precisa de solução e então desenvolver um MVP para
começar o processo de aprendizagem o mais rápido possível. Uma vez que o MVP está
estabelecido, é possível trabalhar uma versão inicial da aplicação.
Neste trabalho são utilizados dois dos sete passos citados por Caroli (2015) para
a definição de um MVP, devido ao foco estar relacionado à elicitação de requisitos e
não na parte de negócios que visa avaliar a viabilidade econômica. Os passos utilizados
foram: (i) visão do produto, que descreve o software a ser desenvolvido em termos de
utilidade e usuário; (ii) elicitação de requisitos e jornadas, que divide as funcionalidades
do MVP e demais iterações.
2.3 Trabalhos Relacionados

Keogh (2010) destaca a importância do método BDD para todo o ciclo de vida do
desenvolvimento de software, especialmente para a interação entre atividades de
negócios e desenvolvimento de software. O autor argumenta que o método permite fazer
entregas de valor para o cliente ao definir comportamentos. Ele afirma que a linguagem
natural utilizada no BDD, para ilustrar exemplos e comportamentos, ajuda a decompor a
aprendizagem para elicitar requisitos e gerar entendimento compartilhado do domínio.
Lazăr et al. (2010) afirmam que o BDD permite que desenvolvedores e clientes
falem a mesma língua, encorajando a colaboração entre todos os participantes do
projeto. Os autores pontuam dois princípios do BDD: 1) desenvolvedores e clientes
254
devem se referir ao mesmo sistema da mesma forma e 2) todo sistema deve ter um valor
identificado e verificável para o negócio.
Münch (2013) destaca, que durante o desenvolvimento de um novo produto de
software, faz-se necessário obter feedback do cliente final o mais rápido possível. Para
isto, realizou um estudo que utilizou a colaboração indústria-academia para desenvolver
um software com ciclo interativo e incremental, com o método de MVP que trata de um
produto de software que pode estar incompleto em funcionalidade ou qualidade, mas
exibe características que permitem determinar o valor para o cliente.
Nos trabalhos apresentados não encontramos aplicação de user stories como
base para construção de MVP. Por esta razão, o objetivo deste estudo foi verificar se
user stories ajudam desenvolvedores a definir o MVP e construir mockups.
3. Estudo experimental
Com o propósito de verificar a aceitação e a dificuldade de uso das user stories,
utilizadas no BDD, na definição do MVP e construção de mockups foi realizado um
estudo experimental exploratório. As Seções 3.1 e 3.2 apresentam, respectivamente, o
planejamento e a execução desse estudo. A versão completa do pacote experimental
encontra-se disponível no relatório técnico [Almeida et al. 2017].
3.1 Planejamento do estudo

Para orientar o projeto do estudo experimental, seu objetivo foi definido usando o
paradigma GQM [Basili 1988]: “Analisar a relação entre user story usada em BDD e
MVP com o propósito de verificar a facilidade de uso, com respeito à especificação de
requisitos e construção de mockups do ponto de vista de pesquisadores em engenharia
de software no contexto de estudantes de graduação e pós-graduação”.
O estudo foi realizado em um ambiente acadêmico e conduzido com 31
estudantes de graduação dos cursos de Ciência da Computação, Sistemas de Informação
e Engenharia da Computação da Universidade Federal do Amazonas (UFAM), que
estavam cursando a disciplina introdutória de “Engenharia de Software”. Os alunos
foram caracterizados como novatos, uma vez que não conheciam especificação de
requisitos e tinham apenas conhecimento acadêmico sobre user stories. Não foi
realizado teste piloto, entretanto o protocolo de experimentação e formulários foram
elaborados por dois dos autores e revisados pelos outros dois.
Todos os participantes assinaram o formulário de consentimento, o Termo de
Consentimento Livre e Esclarecido (TCLE), no qual concordaram em fornecer os
resultados para análise. Os artefatos utilizados no estudo foram: a) descrição textual de
um cenário de aplicação; b) modelos de especificação de user stories; c) artefatos para
criação da especificação; d) artefatos para definição do MVP; e) artefato para criação de
mockups; e) artefato para inspeção dos mockups; f) questionários de avaliação,
conforme apresentados na Tabela 1 e g) artefato para criação da visão do produto.
Todos os participantes receberam treinamento de duas horas em um mesmo
ambiente sobre user stories utilizadas em BDD e sobre MVP. Durante o treinamento
também foram realizados exercícios práticos sobre user story e MVP. Não foi
255
necessário realizar treinamento sobre construção de mockups, pois os participantes já
possuíam conhecimento prévio.
Tabela 1: Extrato dos questionários aplicados [Almeida et al. 2017]
Questionário Perguntas
A) Avaliação de 1) Você teve dificuldades ao especificar no formato user stories? Quais?
especificação 2) Quais são as vantagens da user story? Justifique.
1) Você teve dificuldade em extrair informações da especificação user
story para definição do MVP? Teve algum aspecto que não estava
B) Avaliação de
especificado que fez falta na definição do MVP? Quais?
MVP
2) Você acredita que a user story é útil para identificar os requisitos do
MVP? Justifique.
1) Você teve dificuldade em fazer o mockup do MVP? Teve algum
aspecto do MVP ou da user story que dificultou a construção do mockup?
C) Avaliação de
Quais?
mockups
2) Se você tivesse que fazer outro mockup de MVP, acredita que a
especificação user story ajudaria? Por quê?
1) Minha interação com a user story foi clara e compreensível.
D) TAM:
2) Interagir com a user story não exige muito do meu esforço mental.
1) A especificação user story detalhou bem as informações para a
E) Avaliação definição do MVP? Por quê?
geral 2) Houve retrabalho ou outro problema ao utilizar a especificação user
story? Quais?
Para avaliar os mockups criados baseados nas user stories, foi criado um
formulário de inspeção com tipos de defeitos baseados em Travassos et al. (1999),
apresentado na Tabela 2.
Tabela 2: Classificação de defeitos entre especificação e mockups.
Categoria Descrição Exemplo
Omissão Informações que foram descritas Na especificação tem a descrição: “O
na especificação e não foram cliente seleciona a opção Salvar” No
inseridas no mockup mockup não tem o botão Salvar
Fato incorreto Informações que foram descritas Na especificação tem a descrição: “O
na especificação e inseridas no cliente seleciona a opção Salvar” No
mockup de outra forma mockup o nome do botão é Inserir
Informação Informações que foram inseridas No mockup tem a opção Salvar e
estranha no mockup e que não estavam Cancelar. Na especificação só tem a
descritas na especificação descrição da opção Salvar.
Inconsistência Informações que foram descritas No mockup tem que mostrar os campos
como um cálculo ou informação idade e preço da entrada do cinema,
derivada de outra que no mockup dependentes da data de nascimento. Ou
não obedeceram a dependência, seja, o campo idade e preço devem ser
um conflito de informações. calculados a partir da data de nascimento
e não inserido pelo usuário.
As informações que foram No mockup tem botões com o mesmo
inseridas no mockup são nome, campos com descrição iguais ou
Ambiguidade ambíguas, isto é, é possível que sem navegação entre as telas. Nome de
os stakeholders interpretem de botão ou campo sem o objetivo claro: o
maneira diferente. nome do botão é OK e deveria ser Salvar.
256
Foi utilizado o cenário de um sistema de apoio ao gerenciamento do andamento
do Trabalho de Conclusão de Curso (TCC) por parte do coordenador do curso, do
orientador e do aluno. As funcionalidades do sistema são: cadastrar os orientadores e
alunos, cadastrar cronograma de atividades, disponibilizar programação do Workshop
de TCCs, formalizar a orientação, cadastrar o tema do TCC, trocar mensagens com o
orientador via chat, realizar as entregas de tarefas e atividades pelo sistema, visualizar o
calendário de atividades e de workshop de TCC, cadastrar temas de interesse para
orientação, cadastrar o plano de trabalho com as metas definidas, cadastrar as tarefas do
aluno, visualizar as tarefas do aluno, cadastrar as notas das atividades do orientando e
cadastrar a defesa. Como restrição, o sistema não permite cadastrar mais de uma defesa
de TCC no mesmo horário e local. O cenário foi representado em formato de linguagem
natural e sua qualidade foi verificada por todos os autores.
3.2 Execução do estudo experimental

O estudo experimental foi realizado em quatro dias: no primeiro dia, foi realizado o
treinamento sobre user stories e sobre MVP para todos os participantes. Além do
treinamento, foram realizados exercícios sobre ambos os tópicos.
No segundo dia, os participantes foram divididos aleatoriamente em seis grupos,
com entre quatro e seis integrantes cada. Os participantes receberam o cenário
(Gerenciamento de TCC) para fazerem as especificações com user stories no formato
utilizado em BDD e também modelos para serem seguidos e auxiliar a especificação dos
requisitos com as user stories. Foi aplicado um questionário de avaliação de
especificação com o objetivo de capturar a experiência dos participantes na utilização de
user story para especificação (questionário A da Tabela 1).
No terceiro dia, as atividades foram voltadas para definição de um MVP baseado
na especificação e na construção dos mockups do MVP. Cada grupo utilizou sua própria
especificação, feita no segundo dia, artefatos para elaboração de visão do produto, do
MVP e dos mockups para realizar essas atividades. Ao final da atividade, foram
aplicados questionários de avaliação sobre a definição do MVP com o objetivo de
capturar a experiência dos participantes na utilização da user story para a definição do
MVP (questionário B da Tabela 1) e questionário sobre os mockups para avaliar a
utilização do MVP e user stories na construção dos mockups (questionário C da Tabela
1). Além disso, foi aplicado o questionário TAM para avaliação da facilidade de uso,
utilidade e uso futuro da user story (questionário D da Tabela 1).
No quarto dia foi realizada a inspeção dos mockups, onde cada grupo recebeu a
especificação e os mockups criados por outro grupo, para identificar os defeitos entre o
que foi especificado, o que foi incluído no MVP e o que foi construído no mockup.
Dessa forma, o grupo 1 verificou os defeitos dos mockups criados pelo grupo 5, o grupo
2 verificou nos mockups feitos por 6, grupo 3 os feitos por 4, grupo 4 os feitos por 3,
grupo 5 os feitos por 1 e grupo 6 os feitos pelo grupo 2. Após a inspeção dos mockups,
foi aplicado um questionário geral (questionário E da Tabela 1) visando capturar a
experiência da atividade como um todo.
257
4. Análise dos Resultados
Nesta seção, apresenta-se a análise dos resultados sobre a aceitação e dificuldades de
uso das user stories para definição do MVP e construção de mockups. Para isso foi
analisada a percepção sobre facilidade de uso, utilidade e uso futuro da especificação
com user story e os resultados da inspeção realizada para detectar defeitos cometidos na
criação dos mockups a partir das especificações.
4.1 Análise da percepção sobre facilidade de uso, utilidade e uso futuro

Com o objetivo de avaliar a aceitabilidade das user stories, foram analisados os
questionários sobre a aceitação da tecnologia definidos com base nos indicadores do
Technology Acceptance Model (TAM) [Davis 1989] – questionário D da Tabela 1. Os
dados coletados foram apresentados em forma de gráficos para fim de análise. Os
indicadores definidos foram: (i) utilidade percebida, que indica o grau que uma pessoa
acredita que a tecnologia pode melhorar seu desempenho no trabalho, (ii) facilidade de
uso percebida, que indica o grau que uma pessoa acredita que usar a tecnologia
específica seria livre de esforço e (iii) intenção de uso futuro, que indica o grau que
uma pessoa acredita que voltará a utilizar a tecnologia novamente. A razão para focar
nestes indicadores é que, de acordo com Davis (1989), estes aspectos são fortemente
correlacionados com a aceitação da tecnologia pelo usuário.
Os participantes forneceram suas respostas em uma escala de seis pontos,
baseados nos questionários aplicados por Lanubile et al (2003). As possíveis respostas
nos questionários são: concordo totalmente, concordo amplamente, concordo
parcialmente, discordo parcialmente, discordo amplamente e discordo totalmente. Não
foi utilizado um nível intermediário, uma vez que este nível neutro não fornece
informações sobre o lado ao qual os sujeitos estão inclinados (positivos ou negativos)
[Laitenberger e Dreyer 1998]. Neste questionário, os participantes responderam o seu
grau de aceitação referente à utilidade, facilidade de uso e intenção de uso futuro.
A Figura 4 apresenta as percepções dos participantes em relação à facilidade de
uso das user stories no formato utilizado em BDD. O eixo X dos gráficos da Figura 4
refere-se às possíveis respostas do questionário pós-modelagem e o eixo Y refere-se à
quantidade de participantes. É possível observar que na questão “Interagir com a user
story não exige muito do meu esforço mental” não houve homogeneidade nas respostas
e os participantes ficaram divididos entre concordar parcialmente e discordar
parcialmente. Entre os que discordaram, o participante P6 afirmou que teve dificuldade
“(...) em descrever as funções”, P12 afirmou que teve “dificuldade de diferenciar uma
funcionalidade (user story) de um cenário” e P30 disse que não sabia “(...) Definir o
nível de detalhes das especificações, se deve estar mais próxima do cliente ou dos
desenvolvedores”. Na questão “Minha interação com a user story foi clara e
compreensível” apenas dois participantes discordaram de alguma forma, o participante
P14 disse que “(...) fiquei um pouco confuso em como diferenciar as funcionalidades
(user stories) dos cenários”. Na questão “Considero a user story fácil para especificar
requisitos” três participantes discordaram, o participante P22 afirmou que teve
dificuldade “(...) para saber a forma de separar e lidar com outra user story
relacionada”. Na questão “Eu acredito que é fácil conseguir que a user story faça o que
quero” cinco participantes discordaram, o participante P9 disse “(...) demorei para
258
identificar funcionalidades que deveriam existir para o programa funcionar
corretamente”. A grande maioria dos participantes concordou total, ampla ou
parcialmente, ou seja, no geral, user stories foi considerada fácil de utilizar.
Figura 4: Percepção dos participantes sobre a Facilidade de Uso da user story
A Figura 5 apresenta as percepções dos participantes em relação à utilidade das

user stories. Novamente, os gráficos apontam para a concordância dos participantes, que
consideraram as user stories úteis para definição do MVP do sistema. Apenas um
participante discordou totalmente em três das quatro questões (P23). Este participante
afirmou que para a definição do MVP a “(...)user story não é clara o suficiente”. Para a
questão “Usando a user story, melhorou o meu desempenho na definição de MVPs”
dois participantes discordaram parcialmente, o participante P30 afirmou que “Uma das
desvantagens da user story é a simplicidade, pois não é possível listar todas as
funcionalidades de uma vez.”. Para a questão “Usando a user story, aumentou minha
produtividade na definição de MVPs” três participantes discordaram parcialmente, o
participante P21 disse que “(...) faltaram algumas coisas”. E para a questão “Usando a
user story, me permitiu detectar os requisitos do MVP mais rapidamente” o participante
P21 discordou parcialmente e disse que “(...) foi percebido que faltou uma tela de login”
e P16 discordou amplamente, dizendo que “user story estava bem especificada, mas o
aspecto como login e etc. não foram usados na user story, causou dúvidas”.
Figura 5: Percepção dos participantes sobre a Utilidade da user story
259
A Figura 6 apresenta as percepções dos participantes em relação ao uso futuro
das user stories. Como podemos verificar, a maioria dos participantes concordou em
utilizar novamente as user stories e apenas um participante (P22) discordou totalmente
das duas questões. Este participante afirmou que o “(...) tempo de especificação demora
para ser feito”. Na questão “Eu prevejo que vou usar user story no futuro para auxiliar a
definição de MVPs” apenas um participante discordou parcialmente (P16) apesar de ter
tido uma opinião contrária na questão “Se você tivesse que fazer outro MVP novamente,
gostaria de receber uma especificação user story? Por quê?”, do questionário B da
Tabela 1, onde o participante respondeu “Sim, pois a user story auxilia na construção
da funcionalidade”. Na questão “Eu preferiria usar a user story para auxiliar a definição
de MVPs ao invés de fazê-los de forma tradicional” três participantes discordaram
parcialmente, o participante P9 disse que “(...) Devido às falhas na especificação, o
MVP saiu com menos coisas do que nossa equipe gostaria”.
Figura 6: Percepção dos participantes sobre o Uso Futuro da user story
4.2 Análise das inspeções

A avaliação dos mockups do MVP em relação à especificação resultou em 48 defeitos.
Os tipos de defeitos identificados na inspeção dos mockups criados a partir da
especificação de user story foram: Fato incorreto (18), Informação estranha (12),
Omissão (12), Inconsistência (2) e Ambiguidade (4).
A grande maioria dos defeitos cometidos não estava relacionada aos defeitos
inseridos na especificação das user stories e sim ao fato de a especificação não ter sido
totalmente seguida na construção dos mockups, como por exemplo: não inserção de
informações que estavam descritas, alteração de mensagem no mockup, inserção de
botões não especificados, não indicação da navegabilidade entre as telas e apresentação
de formato dos campos de maneira incorreta.
4.3 Análise Qualitativa

Além da análise realizada por meio do modelo TAM, foi feita uma análise específica
dos dados qualitativos contidos nos questionários aplicados ao longo da execução do
estudo, correspondente a comentários e observações dos participantes. O objetivo foi
avaliar as user stories e identificar possíveis falhas.
A análise dos resultados sobre a especificação identificou as dificuldades
encontradas pelos participantes (P) na utilização das user stories:
260
- Dificuldade em diferenciar funcionalidades (user stories – Figura 1) e cenários
(comportamento – Figura 2):
• “(...) fiquei um pouco confuso em como diferenciar as funcionalidades dos
cenários” – P14
• “Tive dificuldade confundindo funcionalidades com cenários” – P10
Quanto à comunicação de requisitos utilizando user stories, boa parte dos
participantes afirma que existem outras especificações que comunicam os requisitos aos
integrantes da equipe e que as user stories não cobrem detalhes, conforme mostram as
citações abaixo:
• “(...) acho que outras especificações serão necessárias antes de começar a
implementar uma funcionalidade” – P13
• “(...) necessária especificação mais detalhista para os desenvolvedores” – P30
Quanto à análise dos resultados com relação à utilização de user stories para
definição do MVP e criação dos mockups, foram identificados três problemas: algumas
funcionalidades do MVP não estavam especificadas, houve dificuldade em definir o que
entra no MVP (P13) e algumas funções não ficaram claras (P6).
• “(...) a tela de login que foi totalmente esquecida durante a especificação” – P1
• “(...) a user story estava bem especificada, mas o aspecto como login e etc não
foram usados na user story, causou dúvidas” – P16
O participante P4 destacou como ponto positivo as user stories ajudarem a
identificar funcionalidades que faltaram. Além disso, os demais participantes
ressaltaram que as user stories são fáceis, simples e que conseguem descrever as
funcionalidades detalhadamente, o que facilita a visualização do sistema. Outros cinco
participantes destacam que elas oferecem uma visão clara do grau de necessidade do
usuário. Apenas o participante P13, discorda e acredita que user stories não são úteis
para identificar os requisitos para definição do MVP.
• “(...) mais fácil para escolher os mais importantes” – P4
• “(...) demonstra com elegância as necessidades e cenários específicos para cada
funcionalidade, especificando corretamente o espelho do comportamento”– P15
Apesar de acreditarem que o uso de user stories ajudou na definição dos MVPs,
os participantes afirmaram que elas não são suficientes. O participante P4 considera que
a especificação fica incompleta e que algumas funcionalidades ficaram pendentes. Os
participantes P13, P14 e P15 acham que é necessária deliberação adicional para o
entendimento da funcionalidade. Outros acreditam que as user stories servem apenas
para ter uma ideia geral do produto.
• “(...) foi necessário deliberação adicional entre a equipe” – P13
• “(...) ainda faltou algumas funções que não estavam na user story” – P6
A maior dificuldade encontrada em relação à construção do mockup do MVP foi
por conta da especificação user story estar incompleta, conforme pontuam os
participantes P30 e P19:
261
• “(...) algumas funcionalidades não foram incluídas pois não foram incluídas na
user story” – P30
• “A dificuldade foi devido a não fazer a user story com todos os cenários que só
foram percebidos durante a execução dos mockups” – P19
Entretanto, quando questionados se utilizariam novamente a técnica para fazer o
mockup de um MVP, a maioria disse que sim, pois as user stories fornecem visão ampla
do sistema e isso ajuda a identificar requisitos.
• “(...) a user story bem feita fornece uma Visão ampla do sistema” – P7
• “(...) com a user story já é possível ter uma certa pré-visualização de como pode
ser feito o mockup e o comportamento.” – P8
• “(...) a especificação idealiza a essência de funcionamento e das características
da parte crítica (fundamental) como um todo.” – P15
Nos resultados do questionário final, foi verificada a percepção dos participantes
em relação a toda a atividade envolvendo especificação de requisitos até elaboração do
mockup de MVP. Os aspectos positivos ressaltados foram em relação à visão detalhada
do sistema a ser desenvolvido.
• “(...) é fácil ter visão geral do sistema e analisar o essencial” – P7
• “(...) define de maneira clara os requisitos das funcionalidades que podem ser
inseridas no MVP” – P8
• “(...) as funcionalidades e cenários que descrevem bem o comportamento do
sistema e facilita a criação do projeto do MVP” – P14
Os pontos negativos da utilização da técnica envolvem principalmente o
retrabalho que pode ocorrer, tendo que escrever cenários muito parecidos para diferentes
tipos de atores. Além disso, a falta da especificação de funcionalidades e de organização
das user stories foi apontada por muitos participantes.
• “percebemos que não havíamos especificado coisas essenciais como navegação
e login” – P7
• “(...) não especificamos uma característica implícita no problema: a tela de
login” – P15
• “(...) a organização da especificação não facilitou a verificação entre o MVP e
as especificações” – P2
Ao verificar se os participantes utilizariam novamente user stories para fazer
especificação, os motivos listados por aqueles que concordaram foram: simplicidade,
facilidade e praticidade de visualizar o projeto, nível de detalhamento, interação
desenvolvedor-usuário, agilidade. Três participantes ficaram na dúvida e acreditam que
depende do tamanho e tipo do projeto.
Dentre as vantagens das user stories mais citadas pelos participantes, estão a
facilidade de comunicação entre equipe de desenvolvedores e o cliente, especificações
serem detalhadas e a facilidade tanto de fazer as especificações quanto de enxergar o
tamanho do sistema de maneira geral. As desvantagens identificadas pelos participantes
262
são o fato de que muitos cenários fazem a user story ficar extensa e repetitiva, e o fato
de elas não evitarem que alguns cenários sejam esquecidos.
5. Conclusão
Este trabalho apresentou um estudo experimental exploratório que analisou os
resultados relacionados à aceitação e dificuldades existentes na utilização de user stories
para definição de MVPs e construção de mockups. A questão de pesquisa investigada
foi avaliar se a user story auxilia na definição do MVP e construção de mockups.
De acordo com a análise realizada sobre os resultados alcançados, identificou-se
que user story, como forma de especificação de requisitos, teve aceitação positiva pelos
participantes no auxílio na definição do MVP e construção de mockups. Entretanto, foi
possível observar que a técnica possui algumas deficiências, mas que não foram
suficientes para comprometer a definição do MVP e construção de mockups. Portanto,
não é possível afirmar que a utilização de user stories é capaz de prejudicar a definição
do MVP de um produto de software. A partir da análise das inspeções realizadas nos
mockups, foi verificado que os defeitos encontrados nos mockups não foram gerados a
partir de defeitos inseridos na especificação da user story, mas devido aos participantes
não seguirem estritamente a user story como base para construção de mockups.
Neste estudo, existiram algumas ameaças que podem afetar a validade dos
resultados e que foram mitigadas quando possível. As principais ameaças encontradas
foram: (1) efeitos de treinamento: os participantes receberam treinamento para
especificação de user stories que incluíram atividades teóricas e exercícios práticos em
sala de aula; (2) uso de cenário: foi minimizado utilizando cenário escrito em linguagem
natural, onde os requisitos deste cenário estavam explícitos de forma similar aos
exercícios realizados no treinamento; (3) Representatividade dos participantes: os
participantes do estudo foram estudantes, e ainda que Höst et al. (2000) afirmem que
estes podem representar adequadamente uma população de profissionais da indústria, os
participantes foram caracterizados como novatos e podem ter tido dificuldade para
compreender algumas questões dos formulários de avaliação; (4) Tamanho da amostra:
devido ao número limitado de participantes os resultados deste estudo não podem ser
considerados conclusivos. A participação de estudantes e a quantidade da amostra
reduzida foram consideradas limitações aos resultados deste estudo.
Como trabalho futuro, pretende-se fazer estudos de caso na indústria para
reafirmar ou descartar os problemas encontrados e, possivelmente, encontrar novos.
Além disso, replicar o estudo utilizando outras especificações simultaneamente, para
observar o resultado e comparar com os obtidos utilizando user stories.
263
Agradecimentos
Os autores agradecem o apoio financeiro do CNPq processo 423149/2016-4, CAPES

processo 175956/2013, da FAPEAM, processo 062.00578/2014, da FAPERJ (projetos
E-26/010.000883/2016, E-211.174/2016) e UNIRIO (PQ-UNIRIO 01/2016 e 01/2017).
Referências
Agarwal, N. and Rathod, U. (2006). Defining ‘success’ for software projects: An
exploratory revelation. International journal of project management, v. 24, n. 4, pages
358–370.
Almeida, T., Oran, A.C., Santos, G. e Conte, T. (2017). Relatório técnico: Como
desenvolvedor quero utilizar user story para representar os requisitos que levam à
definição do MVP e criação de Mockups. TR-USES-2017-0014. Disponível em:
http://uses.icomp.ufam.edu.br/relatorios-tecnicos/.
Basili, V. R. and Rombach, H. D. (1988). The TAME project: Towards improvement
oriented software environments. IEEE Transactions on software engineering, v. 14, n.
6, pages 758–773.
Beck, K. (1999). Embracing change with extreme programming. Computer, v. 32, n. 10,
pages 70–77.
Breitman, K. and do Prado Leite, J. C. S. (2002). Managing user stories. In International
Workshop on Time-Constrained Requirements Engineering, page 168.
Breitman, K. and do Prado Leite, J. S. (2000). Scenario-based software process.
In Proceedings Seventh IEEE International Conference and Workshop on the
Engineering of Computer Based Systems (ECBS 2000), pages 375–380.
Caroli, P. (2015). Direto ao ponto: criando produtos de forma enxuta. Casa do Código.
Carrera Barroso, A., Solitario, J. J. and Iglesias Fernandez, C. A. (2012). Behaviour
driven development for multi-agent systems. In: International Workshop on
Infrastructures and Tools for Multiagent Systems, page 107-120.
Cooper, B. and Vlaskovits, P. (2010). The Entrepreneur’s Guide to Customer
Development. Paperback.
Davis, F. D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of
information technology. MIS quarterly, pages 319–340.
Duc, A. N. and Abrahamsson, P. (2016). Minimum viable product or multiple facet
product? the role of mvp in software startups. In International Conference on Agile
Software Development, pages 118–130. Springer.Höst, M., Regnell, B. and Wohlin,
C. (2000). Using students as subjects—a comparative study of students and
professionals in lead-time impact assessment. Empirical Software Engineering, pages
201–214.
Keogh, E. (2010). BDD: A Lean Toolkit. In: Proc. of Lean Software & Systems Conf..
Khanh, N. T., Daengdej, J. and Arifin, H. H. (2017). Human stories: A new written
technique in agile software requirements. In Proceedings of the 6th International
Conference on Software and Computer Applications (ICSCA 2017), pages 15–22.
264
Laitenberger, O. and Dreyer, H. M. (1998). Evaluating the usefulness and the ease of
use of a web-based section data collection tool. In Proceedings of the 5th
International Symposium on Software Metrics, pages 122 - 132.
Lanubile, F., Mallardo, T. and Calefato, F. (2003). Tool support for Geographically
Dispersed Inspection Teams. In Software Process Improvement and Practice, pages
217 – 231.
Lazăr, I., Motogna, S. and Pârv, B. (2010). Behaviour-driven development of
foundational UML components. Electronic Notes in Theoretical Computer Science,
pages 91 – 105.
Luna, E. R., Panach, J. I. and Grigera, J. et al. (2010). Incorporating usability
requirements in a test/model-driven engineering approach. Journal of Web
Engineering, v. 9, n. 2, pages 132 – 156.
Moogk, D. R. (2012). Minimum viable product and the importance of experimentation
in technology startups. Technology Innovation Management, v. 2, n. 3, page 23.
Münch, J., Fagerholm, F., Johnson, P., Pirttilahti, J., Torkkel, J. and Jäarvinen, J.
(2013). Creating minimum viable products in industry-academia collaborations. In
Lean Enterprise Software and Systems, pages 137-151.
North, D. (2006). “Introducing bdd”, http://dannorth.net/introducing-bdd/, Março.
Paternoster, N., Giardino, C., Unterkalmsteiner, M., Gorschek, T. and Abrahamsson, P.
(2014). Software development in startup companies: A systematic mapping study. In
Information and Software Technology, v. 56, n. 10, pages 1200–1218.
Ries, E. (2014). A startup enxuta, Leya, 1ª edição.
Silva, T. R. (2016). Definition of a behavior-driven model for requirements
specification and testing of interactive systems. In Requirements Engineering
Conference (RE), 2016 IEEE 24th International, pages 444–449. IEEE.
Solis, C. and Wang, X. (2011). A study of the characteristics of behaviour driven
development. In Software Engineering and Advanced Applications, pages 383–387.
Sutcliffe, A. (1998). Scenario-based requirements analysis. In: Requirements
engineering, v. 3, n. 1, pages 48-65.
Travassos, G., Shull, F., Fredericks, M. and Basili, V. R. (1999). Detecting defects in
object-oriented designs: using reading techniques to increase software quality. In
ACM Sigplan Notices, v. 34, n. 10, pages 47–56. ACM.
Zeaaraoui, A., Bougroun, Z., Belkasmi, M. G. and Bouchentouf, T. (2013). User stories
template for object-oriented applications. In Innovative Computing Technology
(INTECH), 2013 Third Intl. Conf. on, pages 407–410. IEEE.
265
Uma Abordagem para Caracterização dos Aspectos Não-
Funcionais e Classificação do Nível de Exigência em Editais
de Licitação de Software no Setor Público Brasileiro
Bruno de F. Barros1, Reinaldo C. Silva Filho2, Allan R. dos Santos Araújo1
1
Programa de pós-graduação em Engenharia de Software
Centro de Estudos e Sistemas Avançados do Recife (CESAR) – Recife, PE – Brazil
2
Núcleo de Tecnologia da Informação
Universidade Federal de Alagoas (UFAL) – Maceió, AL – Brazil
{brunobarros,reinaldo}@nti.ufal.br, arsa@cesar.org.br
Abstract. Efforts have led to software contracts measured by the amount of

functionality delivered. However, this quantity is just one of many factors to
derive the cost. An instrument was established to characterize the non-
functional aspects in government software bidding documents. Four
experimental studies were conducted to evaluate the effectiveness of the
instrument. In order to do so, 11 professionals involved in biddings
participated as evaluators and Kendall's Coefficient de Concordance (W) was
used. The results indicate a substantial agreement of the requirements levels
and it was possible to obtain evidence of effectiveness, allowing the instrument
to serve as a common mechanism for comparing bidding documents.
Resumo. Esforços levaram a contratos de software medidos pela quantidade

de funcionalidades entregues. Porém, essa quantidade é apenas um dos muitos
fatores para derivar o custo. Foi estabelecido um instrumento para
caracterizar os aspectos não-funcionais em editais de software para o
governo. Quatro estudos experimentais foram conduzidos para avaliar a
eficácia do instrumento. Para tanto, 11 profissionais que atuam em licitações
participaram como avaliadores e o Coeficiente de Concordância (W) de
Kendall foi utilizado. Os resultados indicam uma concordância substancial
dos níveis de exigência e foi possível obter indícios de eficácia, permitindo que
o instrumento sirva de mecanismo comum para comparar editais de licitação.
1. Introdução
Organizações públicas e privadas buscam mais eficiência no campo da Tecnologia da
Informação e Comunicação (TIC) por meio da terceirização, por meio de licitações
[Meli 2012]. Segundo Meli (2012), há muitas razões para isso: manter os custos fixos a
um baixo nível, aumentando o nível de eficiência nos gastos públicos; obter rápido
acesso a competências e tecnologias revolucionárias, etc.
No domínio da TIC, esforços levaram a disseminação de contratos cuja as
atividades de desenvolvimento e manutenção de software são medidas pela quantidade
de funcionalidades entregues, utilizando o método de Análise de Pontos por Função
(APF) [IFPUG 2010]. Porém, a quantidade de funcionalidades é apenas um dos muitos
266
fatores a serem considerados para derivar o custo do projeto de software [Meli 2012],
entre eles: sistemas de software, que podem ser de diferentes naturezas (aplicações web,
de tomada de decisões, business intelligence, por exemplo), aspectos de implementação
(arquitetura, linguagem de programação, ferramentas, requisitos de qualidade, restrições
técnicas, e muitos outros), atendimento a cláusulas contratuais de garantia de níveis de
serviço. Esses requerem esforço de desenvolvimento que diferem muito, mesmo quando
a quantidade de funcionalidade a ser entregue é igual [Meli 2012].
Análises mostram que não existe correlação próxima entre Pontos de Função
Não Ajustados (UFP, do inglês Unadjusted Function Points) e o esforço requerido para
entregar o produto [Green et al. 2012]. Em adição, as características gerais de sistemas e
o fator de ajuste de valor são controversos e criticados tanto por razões práticas como
teóricas [Lokan 2000]. Acórdãos do Tribunal de Contas da União (TCU) reforçam a
determinação de não usar qualquer tipo de fator de ajuste na medição por Pontos de
Função (PF) na contratação de serviços de desenvolvimento de software, para
impossibilitar alterações na remuneração [Brasil, Ministério do Planejamento 2015].
Ainda assim o mecanismo de estimativa de formação do preço por PF sugere
que todos os aspectos não-funcionais devem ser levados em consideração para que haja
uma equidade no esforço e custo necessários para uma justa entrega dos produtos de
software [Meli 2012]. Porém, em primeira análise, por meio da avaliação de editais de
órgãos públicos brasileiros para aquisição de serviços de desenvolvimento e manutenção
de software, não foi possível identificar uma sistemática que considerasse os aspectos
não-funcionais na composição do custo do serviço a ser adquirido.
No Brasil, os valores de referência estabelecidos para o preço da contratação de
serviços de software para o governo se baseiam no custo do PF. Em linhas gerais, a
definição desse custo é fundamentada em pesquisa de mercado (contratações similares)
e pesquisa junto a fornecedores [BRASIL 2014]. Essas formas de compor o preço não
consideram, de forma sistemática e repetível, os aspectos não-funcionais especificados
nos termos de referência dos editais. Ao mesmo tempo, a literatura de Engenharia de
Software apresenta outras alternativas para quantificar os aspectos não-funcionais e
apoiar a estimativa do custo do software, porém essas também apresentam limitações,
especialmente no contexto de contratações de serviços de software para o governo.
Em análise de algumas licitações, foi percebido que as exigências para seleção
do fornecedor aparentemente não influenciavam no preço de referência para a
contratação. Poder-se-ia inferir que quanto mais exigências a serem atendidas por uma
organização na prestação do serviço, maior os seus custos para prover o serviço e,
consequentemente, maior deveria ser o valor de referência estabelecido para a
contratação. No entanto não é isso que se observa na prática. Não há, aparentemente,
uma relação entre a quantidade de exigências estabelecidas pela contratante e o custo de
referência para a prestação do serviço.
Eis que surgem algumas questões: os aspectos não-funcionais estão sendo
considerados para definir esses valores de referência? Esse valor pode indicar qual edital
apresenta mais aspectos não-funcionais a serem atendidos? Diante de alguns editais,
qual deles vai requerer menor (ou maior) investimento para atender esses aspectos?
267
Nesse contexto, este trabalho apresenta um instrumento para caracterizar os
aspectos não-funcionais explicitados em editais de licitação de software para o governo,
no modelo fábrica de software. A caracterização dos aspectos não-funcionais poderá
auxiliar na composição de um preço de referência mais justo tanto para o governo
quanto para a empresa que fornecerá o serviço.
Este trabalho está organizado da seguinte forma: a Seção 2 apresenta os
trabalhos relacionados. A Seção 3 detalha o método de pesquisa para o desenvolvimento
deste trabalho. A Seção 4 provê uma visão geral do instrumento baseado em heurísticas.
A Seção 5 detalha o objetivo, contexto, o desenho e resultados do estudo baseado em
abordagem experimental conduzido para avaliar o instrumento. Finalmente, a Seção 6
descreve as conclusões e direções futuras.
Há outros estudos relacionados a identificação e dimensionamento dos requisitos não-
funcionais (RNF), porém com limitada aplicação em contratações de serviços de
desenvolvimento e manutenção de software no contexto de licitações no setor público.
Buglione et al. (2008) investigaram uma predição, antecipada e ao nível do
projeto, do tamanho do produto com a intenção de reduzir o efeito do “cone da
incerteza”. Eles propuseram usar a técnica Project Size Unit (PSU) para predizer o
tamanho do produto (requisitos funcionais e RNF) medido em unidades de tamanho
funcional [COSMIC 2015]. Porém, os autores concluem que sua aplicabilidade ainda
carece de investigação em projetos reais e há preocupações relacionadas à validade.
Abordagem de como detectar, classificar e rastrear os RNF sugerem que esses
tendem a estar implicitamente presentes em requisitos funcionais do sistema de software
[Mahmoud and Williams 2016]. Tal conhecimento pode ser capturado, modelado, e
utilizado para identificar RNF específicos do sistema. Porém, em editais de licitação do
governo geralmente não são contempladas as especificações dos requisitos funcionais
que devem ser entregues para os usuários.
Um dos esforços mais recentes na comunidade de Engenharia de Software para a
avaliação de tamanho não-funcional, o Processo de Avaliação de Software Não-
Funcional, ou SNAP [IFPUG 2015], limita-se a medir apenas o tamanho não-funcional
do software, não considerando as tarefas relacionadas ao projeto. Esse próprio processo
de avaliação afirma que, apesar de não afetarem o tamanho do software, tarefas
relacionadas ao projeto afetam o esforço requerido para entregar o produto, e por
consequência afetam o custo.
A abordagem foi desenvolvida em duas etapas: (i) concepção do instrumento para
caracterizar o nível de exigência dos editais de licitação, e (ii) avaliação e evolução do
instrumento, a qual foi realizada a partir de quatro ciclos de estudos baseados em
abordagem experimental. A Figura 1 ilustra as duas etapas.
268
Figura 1. Etapas para o desenvolvimento da pesquisa
A pesquisa teve início na revisão da literatura para identificação de abordagens

de identificação e dimensionamento de RNF. Em seguida, a partir do levantamento
bibliográfico, foi elaborado o instrumento, baseado em heurísticas, para a caracterização
do nível de exigência dos editais de licitação.
A segunda etapa foi realizada em quatro ciclos de avaliação e evolução, com os
seguintes objetivos: (i) avaliar a instrumentação; (ii) avaliar o esforço necessário dos
participantes; (iii) obter elementos para aperfeiçoar o instrumento; (iv) obter feedback
dos participantes, e; (v) avaliar a abordagem com relação à capacidade de caracterizar
adequadamente os aspectos não-funcionais dos editais. Os ciclos de avaliação e
evolução foram realizados com diferentes perfis de participantes. A população objeto de
estudo foi a de profissionais que participaram de alguma fase de contratações de
serviços de software através de licitação de terceirização. Em cada ciclo de avaliação,
selecionou-se de forma aleatória editais de licitação de desenvolvimento e manutenção
de software no modelo fábrica de software. Optou-se por utilizar editais
disponibilizados pelo Núcleo de Contratações de Tecnologia da Informação (NCTI1).
Cada ciclo de avaliação e evolução foi composto pelas atividades a seguir:
• Planejamento (seleção do perfil ideal dos participantes; seleção dos editais; e
instrumentação)
• Execução
• Avaliação dos resultados e feedback dos participantes
• Evolução do instrumento
1
https://www.governoeletronico.gov.br/eixos-de-atuacao/governo/sistema-de-administracao-dos-recursos-
de-tecnologia-da-informacao-sisp/ncti-nucleo-de-contratacoes-de-tecnologia-da-informacao
269
4. Heurísticas para Determinar o Nível de Exigência
As heurísticas foram concebidas para servir de mecanismo comum para comparar
editais com vistas aos seus aspectos não-funcionais, e que fossem fáceis de serem
aplicadas, inclusive por pessoas com pouco conhecimento técnico. Elas consistem
basicamente em examinar os editais e julgar o seu nível de exigência requerido ao
fornecedor a partir da própria opinião do avaliador. A seguir são apresentadas as regras
heurísticas propostas.
I) Identificar exigências
Por exigências define-se obrigações relacionadas a capacidade técnica necessária para
habilitar as empresas licitantes, ou seja, capacidades que as empresas já devem possuir
antes do início da contratação. Essas geralmente estão expressas em forma de requisitos
não-funcionais, incluindo como o software deve ser desenvolvido e mantido, e como
deve se comportar quando em operação. Os requisitos não-funcionais dizem respeito a:
• A qualidade do sistema de software;
• O ambiente em que o sistema de software deve ser desenvolvido e o ambiente
em que vai ser executado;
• Os processos e a tecnologia a serem usados para desenvolver e manter o sistema
de software e a tecnologia a ser usada para sua execução.
Figura 2. Exemplo de identificação de uma exigência
As frases das exigências identificadas devem ser marcadas com um marca texto.
A Figura 2 ilustra como as exigências devem ser identificadas.
A fim de identificar exigências nos editais, o avaliador deve procurar
declarações que indiquem obrigatoriedades a serem cumpridas pelo fornecedor para a
contratação do serviço de software que está sendo considerado. Essas exigências
também podem ser identificadas próximas a verbos, como por exemplo o verbo “dever”
e suas variações (deve, deverá, devem etc.). Essas declarações são geralmente expressas
em frases como “A contratada deverá...”, “A contratada deve...”. Os editais geralmente
registram os critérios desejados para a contratação e contêm palavras ou frases
relacionadas a esses critérios.
II) Descartar exigências de menor relevância
Na prática, algumas exigências são pouco expressivas sob o ponto de vista do
investimento necessário para atendê-las, ou seja, são pequenas do ponto de vista global
da contratação e há muita disponibilidade no mercado em questão para atendê-las. Por
exemplo, a maioria das empresas do mercado atenderia a tais exigências sem a
270
necessidade de nenhum investimento. Essas exigências de menor relevância devem ser
desconsideradas do nível de exigência dos editais, ou seja, não devem ser identificadas.
III) Avaliar o nível das exigências
Após a identificação de todas as exigências do edital, o avaliador deve atribuir um nível
de exigência para cada exigência identificada no passo anterior.
O nível de exigência deve ser considerado “muito comum” quando as exigências
forem fáceis de serem atendidas pela maioria das empresas atuantes no mercado
nacional, independente do porte e sem considerar se elas já participaram de alguma
licitação. Esse tipo de exigência não requer que a maioria das empresas realizem
investimentos para atendê-las. Por exemplo, as qualificações exigidas para o pessoal são
abundantes no mercado, ou a tecnologia a ser aplicada é amplamente difundida e não
oferece desafios técnicos. Nesses casos, há grandes chances da maioria das empresas
possuir pessoas com a referida qualificação em seu quadro e/ou já ter tido experiência
com a tecnologia em questão.
No outro extremo, o nível de exigência deve ser considerado “muito raro”
quando, por exemplo, as exigências envolverem recursos raros ou inexistentes no
mercado nacional, ou seja, exigências muito difíceis de serem atendidas pelas empresas
atuantes no mercado e que podem demandar altos investimentos. Algumas dessas
exigências são atendidas por um grupo muito restrito de empresas. Uma empresa que
desejasse atender esse nível de exigência teria que realizar grandes investimentos.
Para exigências “muito comuns” deve ser atribuído o número 1 (um) e, no outro
extremo, para exigências “muito raras” deve ser atribuído o número 5 (cinco). A Figura
3 estabelece os níveis da escala de nível de exigência.
Figura 3. Escala com os níveis de exigência
A ilustração da Figura 4 contém um exemplo de como as exigências

identificadas devem ser marcadas com o nível de exigência avaliado.
Figura 4. Exemplo de avaliação de um nível de exigência
271
5. Avaliação do Instrumento
Em linha com o entendimento de Shull et al. (2004), que estudos experimentais devem
ser realizados e repetidos para melhorar a credibilidade da pesquisa, quatro avaliações
baseada em abordagem experimental [Wohlin et al. 2000] foram executadas para guiar a
evolução do instrumento.
As seções a seguir apresentam o detalhamento do quarto e último estudo baseado
em abordagem experimental, realizado com o propósito de avaliar o uso do instrumento.
5.1. Definição
Utilizando o paradigma GQM [Basili et al. 1994], o objetivo do quarto ciclo foi
declarado como:
Analisar O instrumento
Com propósito de Avaliar
Com respeito a Eficácia da caracterização do nível de exigência de editais de
licitação
Do ponto de vista Profissionais que atuam em alguma etapa de licitações públicas
No contexto de Contratação de serviços de software para o governo, na
modalidade fábrica de software
Com base nesse objetivo foi formulada a seguinte questão:
Questão 1: O instrumento é eficaz na caracterização dos níveis de exigência dos
editais?
O instrumento será considerado eficaz se vários participantes aplicarem o
instrumento para avaliar editais de licitação, escolhidos ao acaso, e for constatada
concordância com relação ao nível de exigência do edital. Essa questão é respondida de
acordo com as métricas associadas, descritas a seguir:
Métrica 1: Nível de exigência, nível associado a cada exigência identificada no
edital. Deve-se obter o valor associado a cada exigência identificada no edital. Esse
valor segue uma escala ordinal de 1 a 5.
Métrica 2: Distribuição dos níveis de exigência do edital, quantifica a frequência
de ocorrências de cada possível resultado (escala de 1 a 5) dos níveis de exigência
encontrados no edital.
Métrica 3: Classificação de abundâncias dos níveis de exigência do edital,
através da transformação da distribuição de frequência dos níveis de exigência em
ordem de classificação dos mais abundantes, de forma a torná-los adequados para
análise estatística. Essa classificação foi baseada no estudo de Legendre (2005) que
propôs o uso do Coeficiente de Concordância (W) de Kendall para identificar grupos de
espécies significativamente associados.
Métrica 4: Coeficiente de Concordância (W) de Kendall [Kendall and Smith
1939], é uma medida de concordância entre várias variáveis (m) quantitativas ou
semiquantitativas que avaliam um conjunto de n objetos de interesse.
5.2. Contexto
O instrumento foi aplicado com profissionais que já participaram de alguma etapa de
contratações desses serviços através de licitações, e foi avaliado a partir de editais que já
272
foram executados, ou seja, o resultado da concorrência pública já foi divulgado. Dessa
forma, a experiência é caracterizada como on-line (projetos industriais), baseado em
problemas do mundo real, e conta com participação de profissionais.
5.3. Variáveis
Neste estudo, as variáveis independentes são a experiência dos participantes, as
exigências dos editais e o instrumento proposto. A variável dependente é a eficácia.
5.4. Formulação das Hipóteses

Dois tipos de hipóteses foram formuladas para avaliar este estudo: uma Hipótese Nula,
que o estudo pretende rejeitar com a maior significância possível; e uma Hipótese
Alternativa.
• Hipótese Nula: Não há concordância entre os níveis de exigência indicados pelos
participantes a partir da aplicação do instrumento.
• Hipótese Alternativa: Há concordância entre os níveis de exigência indicados

pelos participantes a partir da aplicação do instrumento.
Onde o valor de W é referente ao coeficiente de concordância de Kendall

[Kendall and Smith 1939] e pode variar de 0 a 1. Quanto maior o valor de W, mais forte
é a concordância. Um coeficiente de concordância de Kendall elevado ou significativo
denota que os avaliadores estão aplicando essencialmente o mesmo padrão ao avaliar as
amostras [Siegel and Jr. 2006].
5.5. Participantes
Os participantes foram escolhidos com base na técnica não-probabilística de
amostragem por conveniência 2 e snowball 3, e é composta de profissionais que
participaram de alguma fase de contratações de serviços de software através de licitação.
5.6. Arranjo Experimental

A definição, hipóteses e medidas para este experimento indicam que o tipo de projeto é:
“um fator com um tratamento”, já que o objetivo deste estudo não é avaliar o
instrumento contra algum outro método existente.
A variável dependente é medida em escala ordinal, e portanto um teste não-
paramétricos é indicado [Wohlin et al. 2000]. Neste caso em particular, o teste de
Coeficiente de Concordância (W) de Kendall [Kendall and Smith 1939] é utilizado.
2
Se baseia na coleta de dados de membros da população que estão convenientemente disponíveis para
participar do estudo, ou seja, os membros mais acessíveis [Marshall 1996].
3
Permite que cada indivíduo da amostra seja perguntado para indicar o nome de outros indivíduos da
mesma população de estudo [Goodman 1961].
273
5.7. Instrumentação
Os instrumentos utilizados neste estudo foram:
• Questionário para ser preenchido pelos participantes no início do experimento -
Esses dados provêm a entrada para caracterização do participante.
• Material de apoio ao uso das heurísticas – consiste de documento para
treinamento contendo a descrição completa das heurísticas e exemplos.
• Editais de licitação – principais seções dos editais de desenvolvimento e
manutenção de software, selecionados aleatoriamente.
• Questionário para a fase final de execução do experimento. Proverá dados
quantitativos e qualitativos sobre experiência dos participantes no experimento.
• Softwares de apoio a medição – os dados serão organizados em planilhas
eletrônicas e pacotes estatísticos para a análise dos resultados e hipóteses.
A Tabela 1 a seguir apresenta os editais selecionados.
Tabela 1. Editais selecionados para o estudo
Nº Ano Órgão UF
26 2014 ANVISA – Agência Nacional de Vigilância Sanitária DF

11 2015 Secretaria de Portos da Presidência da República DF
5.8. Operação
Todo o material necessário para a execução deste estudo foi preparado previamente e
submetido a um avaliador externo para correção de possíveis mau-entendimentos. Em
seguida iniciou-se a busca por indivíduos pertencentes a população desta pesquisa.
Esses eram então convidados a participar da pesquisa com uma breve explicação do
objetivo, do procedimento e do tempo necessário para execução.
A execução deste estudo foi conduzida no período de março a abril de 2017. Os
dados foram coletados manualmente pelos participantes que preenchiam os
questionários e seguiam as orientações do instrumento para caracterizar os aspectos não-
funcionais dos editais.
Foram abordadas pessoalmente 18 pessoas para participar da pesquisa
presencial, sendo que 12 aceitaram participar da avaliação e as outras seis informaram
não estar disponíveis. As abordagens um-a-um foram particularmente importantes para
garantir uma melhor taxa de resposta. Os participantes realizaram a avaliação sob as
mesmas circunstâncias (com a presença do pesquisador durante a avaliação). As
avaliações eram iniciadas com uma breve apresentação da pesquisa, em seguida os
participantes leram e assinaram o Termo de Consentimento Livre e Esclarecido. Então,
os participantes preencheram o questionário de caracterização e deram início a leitura
das orientações contendo o instrumento para avaliar as principais seções de dois editais
de licitação selecionados ao acaso. Por fim, os participantes preencheram o questionário
pós-execução como o objetivo de obter opiniões e considerações quanto a utilização do
instrumento para avaliar os editais.
274
Convites também foram enviados para participação online. Desses, 11 convites
foram enviados diretamente para os indivíduos, e outros convites foram enviados a
grupo de discussão na internet sobre o tema de contratações públicas de TI, e grupo de
trabalho sobre métricas de software. A pesquisa ficou disponível por 12 dias, mas,
apesar de somados esses grupos possuírem cerca de 400 membros, apenas dois
indivíduos aceitaram participar da pesquisa.
Os dados foram coletados de 14 pessoas que concordaram em participar da
pesquisa. Após a validação dos dados, admitiu-se 11 participantes para as análise e
interpretação dos resultados.
5.9. Análise e Interpretação

Como primeiro passo na análise dos dados, utilizou-se estatísticas descritivas para
visualizar os dados coletados. Para obter um melhor entendimento dos dados
relacionados a experiência dos participantes, em função da sua dispersão e inclinação,
um boxplot (diagrama de caixa) e gráficos de barras são apresentados na Figura 5.
Figura 5. (a) Boxplot para os anos de experiência em TI dos participantes. (b)

Histograma para a quantidade de participantes por participações em licitações
de software. (c) Gráfico de barras com os níveis de formação dos participantes.
Conforme a Figura 5, observa-se que a maioria dos participantes possui entre 15

e 30 anos de experiência em TI, a maioria dos participantes informou já ter participado
de 2 a 5 licitações e, quanto ao nível de formação, a maioria informou possuir
especialização, seguido por graduação completa e mestrado.
5.9.1. Testes de Hipóteses

O Coeficiente de Concordância W de Kendall [Kendall and Smith 1939] foi utilizado
para analisar os resultados e determinar se há concordância entre os níveis de exigência
275
identificados e avaliados pelos participantes a partir da aplicação do instrumento. O
Coeficiente de Concordância W de Kendall quantifica o grau de concordância entre três
avaliadores ou mais em relação à sua classificação do mesmo grupo de sujeitos. Seu
valor varia de 0 a 1, onde 0 representa ausência total de concordância e 1 representa
concordância perfeita. A Tabela 2 sugere interpretação para o coeficiente de
concordância W de Kendall.
Tabela 2. Interpretação do Coeficiente de Concordância (W) de Kendall.
Adaptado de [Landis and Koch 1977].
W de Kendall Interpretação
0 Não há concordância
0,01 – 0,20 Fraca concordância
0,21 – 0,40 Ligeiramente concordantes
0,41 – 0,60 Moderadamente concordantes
0,61 – 0,80 Concordância substancial
0,81 – 0,99 Concordância quase perfeita
1 Concordância perfeita
A Tabela 3 lista os dados da distribuição de frequência e classificação de

abundâncias dos níveis de exigências avaliados pelos participantes para o primeiro
edital selecionado (Edital ANVISA 26/2014).
Tabela 3. Tabela superior: distribuição de frequência dos níveis de exigência
avaliados para o “Edital ANVISA”. Tabela inferior: dados transformados em
classificação de abundâncias dos níveis de exigência.
Distribuição de frequência dos níveis de exigência

1 (muito comum) 2 (comum) 3 (incomum) 4 (raro) 5 (muito raro)
Participante 1 15 14 7 0 0
Classificação das abundâncias dos níveis de exigência

1 (muito comum) 2 (comum) 3 (incomum) 4 (raro) 5 (muito raro)
Participante 1 5 4 3 1,5 1,5
Participante 3 4 5 2,5 2,5 1
Participante 10 3,5 5 2 3,5 1
Participante 11 4,5 3 4,5 2 1
276
Os dados da tabela superior (ver Tabela 3) foram transformados em uma
classificação da ordem de abundâncias (tabela inferior), ou seja, os dados foram
ordenados pela quantidade de exigências identificadas em cada nível de exigência, onde
“1” indica o nível com a menor quantidade de exigências, e “5” o nível com a maior
quantidade de exigências. Observa-se também que é atribuída a média dos postos
quando ocorrem observações empatadas.
O gráfico da Figura 6, plotado com os dados das classificações de abundâncias
(Tabela 3, tabela inferior), ilustra que pode haver convergência nos resultados das
avaliações realizadas no edital pelos participantes. Porém, para verificar essa
convergência, surge a necessidade de aplicar teste estatístico apropriado.
Figura 6. Gráfico de curvas das abundâncias relativas da classificação dos

níveis de exigência identificados e avaliados pelos participantes.
A análise estatística foi realizada utilizando o pacote estatístico Minitab 17, no

nível de significância α = 0,05. A seguir são apresentados os resultados do teste
estatístico W.
Tabela 4. Resultados do teste estatístico W
Teste da estatística W – edital 1

Objetos = 5
Avaliadores = 11
W de Kendall = 0,75
Qui-quadrado = 32,98 Graus de liberdade (GL) = 4 Valor p = 0,00 Rejeita H0
Com os resultados apresentados na Tabela 4, o grau de concordância entre os 11

avaliadores é expresso por W = 0,75. Portanto, o W de Kendall para este estudo
apresenta uma concordância substancial entre os participantes na avaliação do nível de
exigência do edital.
Para determinar a significância estatística dessa concordância, a quantidade é
aproximadamente distribuída como um qui-quadrado com N - 1 graus de liberdade
277
[Siegel and Jr. 2006]. Conforme a Tabela 4, obteve-se que com um qui-quadrado =
32,98, com grau de liberdade = 4, tem probabilidade de ocorrência sob H0 de p < 0,05.
Logo, pode-se concluir que a concordância entre os 11 participantes é mais alta do que
seria se fosse devido ao acaso, isto é, se suas avaliações tivessem sido aleatórias ou
independentes. A probabilidade muito baixa sob H0 associada com o valor observado de
W, permite rejeitar a hipótese nula de que não há concordância entre os níveis de
exigência indicados pelos participantes a partir da aplicação do instrumento, e obter
indícios de que há uma concordância substancial entre os participantes no que se refere
ao nível de exigência do primeiro edital avaliado.
5.10. Resultados
Após análise e interpretação dos resultados, pode-se responder à questão: O instrumento
é eficaz na caracterização dos níveis de exigência dos editais?
Diante dos resultados, sumarizados na Tabela 5, obteve-se indícios de que há
uma concordância substancial entre os participantes no que se refere aos níveis de
exigência avaliados pelos participantes nos dois editais. Portanto, respondendo à
Questão 1, o instrumento pode ser considerado eficaz quanto a capacidade de
caracterização dos níveis de exigência dos editais.
Tabela 5. Resumo dos testes de hipóteses
Edital Hipótese nula Resultado (W de Kendall) Valor p Rejeita H0?

1 W=0 0,75 0,00 Sim
2 W=0 0,70 0,00 Sim
A Figura 7 a seguir ilustra a utilização do instrumento, permitindo que ele sirva

de mecanismo comum para comparação de editais de licitação de software.
Curvas de Distribuição de Frequência

ANVISA
Quantidade de exigências
31
Secretaria de Portos
14
9
6
4 4 3
1 1
0
1 2 3 4 5
Nível de exigência
Figura 7. Uso do instrumento para comparar editais de licitação
Conforme a Figura 7, observa-se a comparação dos níveis de exigência de dois

editais avaliados por um participante utilizando o instrumento. A partir da
caracterização dos aspectos não-funcionais, pode-se classificar o “Edital ANVISA”
como sendo mais exigente do que o “Edital Secretaria de Portos”.
278
5.11. Ameaças à Validade
A presença do pesquisador pode ser uma ameaça à validade. Dúvidas pontuais
esclarecidas aos participantes relacionadas às orientações para avaliação dos editais
podem ter influência sobre os resultados.
A avaliação a partir de apenas algumas seções dos editais também pode ser uma
ameaça à validade. Assumiu-se que o tamanho elevado dos editais (quantidade de
páginas) poderia demandar muito esforço para os participantes no momento da
avaliação. Logo, resultados podem ser diferentes caso o instrumento seja aplicado em
todo o termo de referência de um edital.
O tamanho pequeno da amostra, e a distribuição geográfica dos participantes,
não são ideais do ponto de vista estatístico. Embora os resultado deste estudo não
possam ser generalizados, eles apoiam a indicação de que o instrumento é eficaz na
caracterização do nível de exigência dos editais.

As formas de compor o preço de referência de contratações de software não consideram,
de forma sistemática e repetível, os aspectos não-funcionais especificados nos termos de
referência dos editais. Ao mesmo tempo, a literatura de Engenharia de Software
apresenta outras alternativas para quantificar os aspectos não-funcionais e apoiar a
estimativa do custo do software, porém essas também apresentam limitações,
especialmente no contexto de contratações de serviços de software para o governo.
Dada a extensão do problema, foi descrita uma proposta baseada em heurísticas
e um procedimento para caracterizar os aspectos não-funcionais de projetos de software
no contexto de editais de licitação no setor público brasileiro. As heurísticas propostas
foram montadas com a premissa de que devem servir de mecanismo para comparar
editais com vistas aos seus aspectos não-funcionais, e que fossem fáceis de serem
aplicadas, inclusive por pessoas com pouco conhecimento técnico. Com o propósito de
avaliar a eficácia do instrumento estudos baseados em abordagem experimental foram
conduzidos.
Considerando as limitações, os estudos possibilitaram observar a evolução do
instrumento e obter indícios de que há uma concordância substancial entre os
participantes no que se refere aos níveis de exigência avaliados utilizando o instrumento
desenvolvido.
Como trabalhos futuros, há a intenção de: analisar se há correlação entre os
preços estimados das contratações e os níveis de exigência (caracterizados através deste
instrumento) de editais de licitação de software para o setor público; replicar esta
experiência com participantes do mesmo público-alvo desta pesquisa, e de outros
estados brasileiros, permitindo ampliar o entendimento sobre a eficácia do instrumento.
Referências
Basili, V., Caldiera, G. and Rombach, H. D. (1994). Goal Question Metric Paradigm.
Encyclopedia of Software Engineering, v. 2, p. 528–534.
Brasil, Ministério do Planejamento, O. e G. S. de L. e T. da I. (2015). Roteiro de
279
Métricas de Software do SISP: Versão 2.1. Brasília: .
BRASIL, M. S. (2014). Guia de Boas Práticas em Contratação de TI. v 2 ed. Brasília: .
Buglione, L., Ormandjieva, O. and Daneva, M. (2008). Using PSU for early prediction
of COSMIC size of functional and non-functional requirements. Lecture Notes in
Computer Science, v. 5338 LNCS, p. 352–361.
COSMIC (2015). The COSMIC Functional Size Measurement Method Version 4.0.1 -
Measurement Manual. n. April, p. 1–98.
Goodman, L. A. (1961). Snowball Sampling. The Annals of Mathematical Statistics, v.
32, n. 1, p. 148–170.
Green, C., Bradley, D., Ben-Cnaan, T., et al. (2012). Software Non-Functional
Assessment Process. The IFPUG Guide to IT and Software Measurement. Auerbach
Publications. p. 495–523.
IFPUG (2010). Counting Practices Manual. 4.3 ed.
IFPUG (2015). Software Non-functional Assessment Process (SNAP). Assessment
Practices Manual. International Function Point Users Group.
Kendall, M. G. and Smith, B. B. (1939). The Problem of m Rankings. The Annals of
Mathematical Statistics, v. 10, n. 3, p. 275–287.
Landis, J. R. and Koch, G. G. (1977). The Measurement of Observer Agreement for
Categorical Data. Biometrics, v. 33, n. 1, p. 159–174.
Legendre, P. (2005). Species Associations: the Kendall Coefficient of Concordance
Revisited. Journal of Agricultural, Biological, and Environmental Statistics, v. 10, n. 2,
p. 226–245.
Lokan, C. J. (2000). An empirical analysis of function point adjustment factors.
Information and Software Technology, v. 42, n. 9, p. 649–660.
Mahmoud, A. and Williams, G. (2016). Detecting , classifying , and tracing non-
functional software requirements. Requirements Engineering, v. 21, n. 3, p. 357–381.
Marshall, M. N. (1996). Sampling for qualitative research. Family Practice, v. 13, n. 6,
p. 522–525.
Meli, R. (2012). Software Measurement in Procurement Contracts. The IFPUG Guide to
IT and Software Measurement. Auerbach Publications. p. 561–583.
Shull, F., Mendoncça, M. G., Basili, V., et al. (2004). Knowledge-Sharing Issues in
Experimental Software Engineering. Empirical Software Engineering, v. 9, n. 1, p. 111–
137.
Siegel, S. and Jr., N. J. C. (2006). Estatística não-paramétrica para as ciências do
comportamento. 2a ed. Porto Alegre: Artmed.
Wohlin, C., Runeson, P., Höst, M., et al. (2000). Experimentation in Software
Engineering: An Introduction. Boston, MA: Springer US. v. 6
280
Uma Proposta de Boas Práticas para Aplicação de Teste
Baseado em Modelos em Métodos Ágeis
Aline Zanin1 , Avelino Francisco Zorzo1 , Élder de Macedo Rodrigues2
1
Pontifı́cia Universidade Católica do Rio Grande do Sul (PUCRS)
2
Universidade Federal do Pampa (Unipampa)
aline.zanin@acad.pucrs.br, avelino.zorzo@pucrs.br
elderrodrigues@unipampa.edu.br
Abstract. This paper analyzes how Model-based Testing (MBT) can be applied
by teams that use agile methods, more specifically Scrum. Hence, we perfor-
med a systematic literature review to identify the works that were published and
show the problems related to MBT process when applied in the agile context.
Furthermore, we performed also a field research conducted through interviews
with professionals who work on software quality in agile teams. Finally, we
correlated the opinion of the specialists against the literature review and pro-
vide a proposal of better practices for implementing MBT in agile teams. This
proposal was validated through a survey.
Resumo. Este trabalho analisa como Teste Baseado em Modelos (Model-based

Testing - MBT) pode ser aplicado em times que utilizam métodos ágeis, mais
especificamente Scrum. Para isso, realizamos dois estudos: um mapeamento
sistemático de literatura e uma pesquisa de campo. Os resultados do mapea-
mento sistemático foram utilizados para identificar os trabalhos já publicados
que apresentam dificuldades encontradas no processo de MBT quando apli-
cado em projetos ágeis de desenvolvimento de software. A pesquisa de campo,
por sua vez, foi realizada através de entrevistas realizadas com profissionais
que trabalham focados em testes de software em equipes ágeis. Neste estudo
objetivamos coletar as opiniões dos profissionais a respeito da utilização de
MBT no contexto de suas equipes. Por fim, corroboramos o resultado obtido
na entrevista com os especialistas e os resultados obtidos com o mapeamento
sistemático e elaboramos uma proposta de boas práticas para implementação
de MBT em equipes ágeis. Os resultados atuais, obtidos através de uma survey
indicam que a proposta é adequada para o contexto a qual se propõe.
1. Introdução
O desenvolvimento ágil de software teve sua popularização e ascensão no ano de 2001,
através de um documento chamado manifesto ágil de software [3]. Neste documento
estão descritos os princı́pios e valores que devem ser seguidos por empresas e profissio-
nais que desejam adotar os métodos ágeis de desenvolvimento. Dentre estes princı́pios
destacam-se: interação com o cliente acima de documentação e contratos fechados; boa
receptividade à mudança de requisitos; multidisciplinaridade e responsabilidade coletiva
nas equipes de desenvolvimento, integrando pessoas relacionadas a negócios e equipe de
desenvolvimento para o trabalho conjunto diário.
281
Esta multidisciplinaridade das equipes exige uma responsabilidade coletiva sob
todas as atividades de um projeto e neste contexto, um dos segmentos que empreendeu
mudanças foi o segmento de testes de software. Se antes, na abordagem tradicional de de-
senvolvimento de sistemas, os profissionais de qualidade, embora envolvidos no processo
de desenvolvimento de sistemas como um todo, tinham como atividade e responsabili-
dade principal a realização do controle de qualidade dos produtos e processos, agora,
em métodos ágeis, cria-se uma cultura de responsabilidade coletiva. Nesta cultura, todos
os profissionais são responsáveis pela excelência no desenvolvimento de todo o trabalho
e devem contribuir da melhor forma possı́vel para o bom andamento dos trabalhos da
equipe e da comunicação entre os envolvidos no projeto e com o cliente. Desta forma
estabelece-se uma única equipe multidisciplinar [9].
Contudo para que este trabalho multidisciplinar possa ser executado com quali-
dade se faz necessário utilizar técnicas de desenvolvimento e de testes que favoreçam a
comunicação entre os membros do time de desenvolvimento. Para isso é necessário olhar
para técnicas que já apresentam histórico de sucesso em sua aplicação em projetos que
utilizam ciclo de vida tradicional de software, por exemplo, cascata ou espiral, e analisar a
sua aplicabilidade em equipes ágeis. Dentre as diversas abordagens, técnicas e estratégias
de testes apresentadas na literatura, a técnica de teste baseado em modelos (Model Ba-
sed Testing - MBT [2]) é um exemplo de técnica que apresenta diversos benefı́cios, já
relatados em trabalhos acadêmicos, e cuja aplicabilidade em equipes ágeis ainda é pouco
explorada.
Embora MBT demande a construção de modelos, o que pode por vezes causar
uma desconfiança em relação a aplicabilidade desta técnica em métodos ágeis, é impor-
tante enfatizar que a representação dos requisitos de software em modelos é uma estratégia
para tornar os requisitos de software mais visuais e intuitivos [6] e desta forma, pode in-
clusive favorecer a comunicação entre os membros de um projeto e o cliente. Com isso,
a documentação se torna de mais fácil compreensão quando comparada a longos docu-
mentos textuais. Além disso a representação de requisitos em modelos, permite ao cliente
visualizar a estrutura de funcionamento da funcionalidade que está sendo projetada o que
ajuda a evitar ruı́dos de comunicação entre os membros do projeto e o cliente. Partindo do
princı́pio que a comunicação entre os envolvidos é um dos pilares do manifesto ágil [3],
considera-se que a aplicação de MBT pode agregar valor a um cenário ágil, envolvendo
as vantagens da utilização de modelos e da realização eficaz de testes de software.
Contudo, embora os benefı́cios desta técnica sejam conhecidos e existam indı́cios
que sua aplicação em equipes ágeis pode proporcionar grandes benefı́cios ao aliar as van-
tagens proporcionadas pela técnica de MBT e as vantagens proporcionadas pela utilização
de métodos ágeis, se faz necessário analisar a melhor forma de aplicar esta técnica neste
contexto. Isto porque a estrutura de trabalho e principalmente a periodicidade de entregas
de produtos difere no ciclo de vida tradicional e na utilização de métodos ágeis.
Até onde conseguimos identificar, não existem trabalhos cientı́ficos que apresen-
tem boas práticas na aplicação de MBT em time ágeis. Desta forma, buscamos com este
trabalho diminuir esta lacuna, respondendo a seguinte questão de pesquisa: Quais são
as boas práticas que devem ser observadas para implantação de MBT em equipes ágeis?
Com o objetivo de responder a esta pergunta, realizamos um mapeamento sistemático de
literatura buscando trabalhos que relatam os desafios da realização de testes ou descrevem
282
a aplicação da técnica de MBT em times ágeis; paralelamente foram conduzidas entre-
vistas com profissionais que trabalham focados em testes de software e integram equipes
ágeis. Nestas entrevistas buscamos apresentar a técnica de MBT e coletar a opinião des-
tes profissionais sobre as dificuldades e vantagens de aplicar esta técnica no contexto dos
projetos nos quais estão inseridos nas empresas em que atuam.
A partir dos resultados obtidos no mapeamento sistemático de literatura e das res-
postas coletadas nas entrevistas com os profissionais, identificamos as dificuldades e as
vantagens da aplicação de MBT em métodos ágeis que foram comuns nos dois estudos.
Baseado nisso, e na experiência que possuı́mos, por integrarmos um grupo de pesquisa
que trabalha faz dez anos com MBT [20], [8], [19], [18], [4], [5], analisamos estes pontos
afim de propor um conjunto de boas práticas na implantação de MBT em times de desen-
volvimento ágil. Por fim, realizamos uma survey com um conjunto de 30 profissionais
que atuam em equipes ágeis de desenvolvimento de sistemas para verificar se o conjunto
de boas práticas sugeridas são coerentes e se elas podem auxiliar no processo de adoção
de teste baseado em modelos por equipes ágeis.
Este artigo está organizado da seguinte maneira: na Seção 2 apresentamos a me-
todologia de pesquisa. Na Seção 3 apresentamos os resultados da revisão literatura. Na
Seção 4, por sua vez, apresentamos a estrutura utilizada para as entrevistas com os especi-
alistas. Na Seção apresentamos os problemas comuns encontrados na literatura e nas en-
trevistas. Na Seção 6 apresentamos o conjunto de boas práticas para implantação de MBT
em equipes ágeis. Na Seção 7 apresentamos uma primeira avaliação sobre a coerência e
efetividade das boas práticas sugeridas. Finalmente, apresentamos as considerações fi-
nais, agradecimentos e trabalhos futuros.
2. Metodologia e Desenvolvimento
O estudo apresentado neste artigo foi realizado em quatro etapas. Sendo elas: mapea-
mento de literatura, entrevistas com especialistas, formulação de uma proposta de boas
práticas e validação dos resultados.
Na etapa de mapeamento de literatura, efetuou-se uma busca na base de dados Sco-
pus Database visando localizar artigos que apresentam abordagens, técnicas, métodos,
processos e relatos de aplicação da técnica de MBT em times ágeis. Para cada trabalho
localizado nesta pesquisa buscou-se analisar as dificuldades na implantação de MBT em
times ágeis descritas pelos autores. Optou-se por utilizara base de dados Scopus Database
porque esta base concentra mais de 6,8 milhões de artigos e indexa diversas outras bases
de dados, entre elas a IEEE1 e a ACM2 que estão entre as principais bases eletrônicas de
dados para ciência da computação [15].
Na etapa de entrevistas com especialistas efetuou-se uma pesquisa de campo, com
o objetivo de obter um entendimento sobre a visão dos profissionais que atuam com testes
de software sobre a aplicação de MBT em times de desenvolvimento ágil. Para esta etapa
do estudo, foi realizado um conjunto de seis entrevistas com profissionais que atuam como
analistas de testes e qualidade em equipes ágeis de desenvolvimento de sistemas. Os pro-
fissionais entrevistados estão geograficamente distribuı́dos em diversos estados brasileiros
1
http://ieeexplore.ieee.org/Xplore/home.jsp
2
http://dl.acm.org/
283
(Rio Grande do Sul, Santa Catarina e Minas Gerais) e por este motivo as entrevistas3 fo-
ram realizadas fazendo uso de um software que permite comunicação pela Internet através
de conexões de voz e vı́deo.
Na etapa de formulação de uma proposta de boas práticas na implantação de MBT
em equipes ágeis, efetuou-se uma comparação dos resultados obtidos no mapeamento de
literatura com os resultados obtidos nas entrevistas com os profissionais. A partir disso,
definiu-se um conjunto de dificuldades que foram relatos comuns nos dois estudos. Com
o objetivo de sanar estas dificuldades, propusemos para cada uma delas, uma ou mais
práticas para serem utilizadas na implantação de MBT em equipe ágeis.
Por fim, na etapa de validação dos resultados, realizamos uma survey com um
conjunto de 30 profissionais que trabalham com teste de software. Esta survey foi execu-
tada para verificar se o conjunto de boas práticas sugeridas são coerentes e se elas podem
auxiliar no processo de uso de MBT com métodos ágeis. A Figura 1 demonstra grafica-
mente as etapas deste processo de pesquisa que serão descritas detalhadamente nas seções
seguintes.
Figura 1. Fluxograma do Processo de Pesquisa
3. Revisão de Literatura
Nesta seção são apresentados alguns trabalhos disponı́veis na literatura que descrevem
metodologias, técnicas, processos, abordagens, ferramentas ou relatos de experiência com
a realização de MBT em equipes ágeis de desenvolvimento de sistemas e que em seu
escopo apresentam as dificuldades encontradas neste processo. Esta pesquisa foi reali-
zada através de uma busca efetuada na base de dados Scopus4 , fazendo uso das seguintes
palavras chave: “TITLE-ABS-KEY ( ( mbt OR “model-based testing”OR “model ba-
sed testing”OR “model-based test”OR “model based test”OR “model-based software tes-
ting”OR “model based software testing”) AND ( approach OR method OR methodology
OR technique) AND ( agility OR agile OR scrum OR xp OR “Extreme Programming”OR
fdd OR “Feature-Driven Development”OR tdd OR “Test Driven Development”OR lean
OR kanban ) AND (software ) ) ”.
Esta busca retornou 39 artigos, sendo que destes, foram incluı́dos nesta pesquisa
apenas artigos escritos entre 2001 e 2016, disponibilizados na web nos idiomas inglês
e português, que descrevem, de forma detalhada, metodologias, ferramentas, processos
ou técnicas utilizadas para testes de software baseado em modelos em times ágeis, que
apresentam, de forma detalhada, alguma metodologia, ferramenta, processo ou técnicas
utilizadas especificamente para criação de modelos baseado em Gherkin, Specification By
Example ou User Story.
A partir dos resultados retornados por esta busca foram analisados os trabalhos
que apresentam desafios na aplicação de MBT em métodos ágeis, sendo selecionados os
seguintes.
3
As perguntas efetuadas neste estudo, podem ser visualizados em: https://goo.gl/UwQhJ1
4
https://www.scopus.com
284
Aichernig et. al [1] apresentam um trabalho que descreve uma estratégia para
realização de Test Driven Development -TDD baseado em modelos. Nesta estratégia, mo-
delos formais são criados e com base nestes é realizada a geração de scripts de testes.
A partir disso é realizada a validação destes scripts e posteriormente aplicado TDD em
seu formato tradicional, implementando os casos de teste anteriormente validados. Neste
trabalho os autores apresentam como dificuldade na aplicação de MBT a garantia da qua-
lidade dos scripts de testes gerados. Esta preocupação é devido a realização dos testes
ser feita baseando-se em scripts gerados com base nos modelos e sendo assim, modelos
incorretamente criados, ou modelos aonde existem lacunas de requisitos não modelados,
impactam diretamente na qualidade dos scripts de teste.
Katara et. al (2006)[14] apresentam um trabalho que descreve uma abordagem
baseada na utilização de diagramas de casos de uso para automação de teste de software.
Em relação às dificuldades encontradas para integração de MBT e métodos ágeis, os au-
tores descrevem que os modelos gerados por equipes ágeis costumeiramente possuem um
nı́vel de abstração de detalhes elevado, o que impede ou dificulta aplicação de MBT. Esta
dificuldade se justifica, uma vez que, demanda-se um tempo adicional para que o modelo
criado com alto nı́vel de abstração possa ser completado com as informações requeridas
para aplicação de MBT. Além disso os autores enfatizam a dificuldade mensurar se os
requisitos foram cobertos integralmente pelos modelos criados.
Entin et al. (2011)[10] apresentam uma abordagem para combinar as técnicas
de Captura e Repetição (CR) e MBT. Esta abordagem consiste em criar um conjunto
reutilizável de caminhos de teste, através de uma ferramenta de CR e posteriormente
integrar estes caminhos a modelos comportamentais que serão a base para aplicação da
técnica de MBT e geração de Scripts de teste. Neste trabalho os autores apresentam como
dificuldades na utilização de MBT em projetos ágeis que utilizam o método Scrum, o fato
de a grande maioria das abordagens de MBT não deixarem claro como é feito o processo
de migração de um caso de teste abstrato (gerado através dos caminhos percorridos nos
modelos) para um caso de teste executável. Este processo é, em muitos casos, realizado
de forma manual, o que ocasiona um problema de consumo excessivo de tempo e recurso
e por vezes torna inviável a realização de MBT em uma sprint.
Jalalina et. al (2012)[13] apresentam um conjunto de padrões utilizados em MBT
que quando aplicados a projetos ágeis podem auxiliar a resolver problemas com de-
ficiência de documentação e atualização de scripts. Contudo, o trabalho apresentado
pelos autores não tem foco exclusivo em MBT e sim em resolver problemas encontra-
dos em métodos ágeis, sendo para alguns deles aplicado MBT como solução. Entre as
dificuldades descritas neste trabalho, sobre a integração de MBT com métodos ágeis,
encontram-se: a falta de sistemas de controle de versão com suporte ao gerenciamento de
modelos, a integração de modelos com IDEs populares de desenvolvimento de sistemas,
e a inexistência de integração entre modelo e código,
Entin et al. (2012)[11] apresentam os desafios enfrentados na implantação e
utilização de MBT em um projeto de desenvolvimento ágil que utiliza Scrum. Os au-
tores focam seu trabalho na criação e manutenção de modelos, realização de teste base-
ado em riscos na interface gráfica de usuário (GUI), algoritmos de derivação de casos de
teste e, escolha de arquitetura. Em relação aos desafios apresentados, os autores iniciam
abordando o fato de que projetos ágeis têm ciclos de desenvolvimento curtos e, por isso,
285
faz-se necessária a definição de um processo concreto de criação e manutenção dos mo-
delos durante todo o processo de desenvolvimento. Outro desafio apontado diz respeito à
necessidade de atualização contı́nua dos modelos para a realização de testes de regressão,
isto porque no contexto apresentado, as equipes costumam realizar estes testes continua-
mente para garantir que alterações efetuadas no código por um desenvolvedor, ao serem
incorporadas no sistema (processo de branch merges), não interfiram no funcionamento
do sistema como um todo. Os autores apresentam também como desafio a necessidade
de prover alternativas para a definição correta do nı́vel abstração dos modelos, afim de
que os modelos criados possam ser reutilizáveis para novos testes. E por fim, o trabalho
aponta como desafio a necessidade de tornar possı́vel gerar casos de teste para os cenários
considerados crı́ticos, de alta prioridade, otimizando desta forma o tempo de execução de
testes.
Sivanandan et al. (2014)[21] apresentam o projeto de um framework que utiliza
MBT para automação de Teste Baseado em Comportamento (Behaviour Driven Test -
BDT) e analisa como este framework pode ser usado durante o desenvolvimento ágil.
Para conceber este projeto, os autores propõem a integração da ferramenta Graphwalker,
do framework Robot e da utilização de BDT. Entretanto, os autores não são claros a res-
peito de como é feita a integração, não sendo possı́vel identificar como foram concebidos
os modelos e gerados os scripts de teste. Neste trabalho os autores apresentam como de-
safios para utilização de MBT em métodos ágeis: criar e manter modelos pouco rı́gidos
e flexı́veis, manter a conformidades do código com o modelo e garantir a cobertura de
testes.
Entin et al. (2015)[12] apresentam os resultados da análise da aplicação da técnica
de MBT em um projeto Scrum. O processo proposto, e utilizado neste trabalho, faz uso
da linguagem de domı́nio especı́fico Gherkin para a definição dos requisitos e realiza
a geração automatizada de modelos a partir destes requisitos. O autor apresenta como
desafios na utilização de MBT em times ágeis, os seguintes pontos: construir um modelo
fiel aos requisitos, uma vez que os requisitos criados por equipes ágeis costumam ser bem
sintetizados; falta de domı́nio de modelagem de sistemas pelos responsáveis pelo negócio
em times Scrum (Product Owner – PO); reduzir o esforço de manutenção de modelos afim
de mantê-los atualizados conforme os requisitos do sistema forem sendo alterados, isto
porque é comum em métodos ágeis a mudança de requisitos durante o projeto; construção
e alteração manual dos modelos.
Nan Li et al (2016) [16] propõem a utilização de modelos comportamentais de
Unified Modeling Language - UML para geração de cenários no formato aceito pela fer-
ramenta Cucumber. Após este processo, o programador poderá utilizar estes cenários para
a criação de casos de teste automatizados concretos. Neste trabalho os autores apresen-
tam como principal dificuldade para utilização de MBT em equipes ágeis o fato de que
os desenvolvedores costumam criar modelos comportamentais, contudo não costumam
evolui-los para realização de testes. Uma das justificativas para isso é que estes modelos
não são compatı́veis com as ferramentas tradicionalmente utilizadas pelas equipes ágeis,
e.g. Cucumber. Além disso, os autores apontam como dificuldade a complexidade da
criação de modelos devido a quantidade de informações detalhadas que são necessárias
inserir nestes para aplicar MBT.
286
4. Entrevistas com Especialistas
Com o objetivo de obter informações sobre a aplicação de MBT em equipes ágeis, rea-
lizamos um conjunto de entrevistas semi estruturadas com especialistas em teste de soft-
ware que trabalham em times ágeis. Primeiramente foi apresentado a estes profissionais a
técnica de MBT, para isso explicou-se como ela funciona e quais são as principais vanta-
gens e desvantagens de sua utilização quando aplicada em uma estrutura de ciclo de vida
tradicional de software. Posteriormente, ainda com objetivo de familiarizar os entrevista-
dos com a técnica de MBT, realizou-se uma demonstração de um exemplo de aplicação
prática da técnica.
Para a demonstração da técnica de MBT foi utilizada uma ferramenta de teste
funcional baseado em modelos, desenvolvida no Centro de Pesquisas em Engenharia de
Software da PUCRS [20], como parte de uma linha de produto de ferramentas de testes
baseado em modelos. E como ferramenta a ser testada utilizou-se a ferramenta de gestão
de projetos EPESI 5 . Esta ferramenta foi modelada e casos de teste foram gerados a partir
dos modelos.
Posteriormente, estes profissionais responderam perguntas sobre como esta
técnica poderia ser utilizada nos projetos em que eles trabalham, considerando uma es-
trutura ágil de desenvolvimento de sistemas. Cada profissional respondeu as perguntas
em um momento diferente. As perguntas versaram sobre as dificuldades, vantagens, des-
vantagens e sugestões de possı́veis melhorias para a inserção e utilização de MBT neste
cenário.
Analisando as respostas das entrevistas, pudemos identificar pontos que são apon-
tados pelos especialistas como as principais dificuldades para implantação de MBT nos
times aonde estão inseridos. Neste contexto, os especialistas entrevistados são unânimes
na percepção de que a maior dificuldade na aplicação da técnica de MBT está na etapa
de construção dos modelos. Esta dificuldade se deve ao fato dos modelos precisarem ser
construı́dos com base nas informações de negócio que as equipes possuem, sendo que,
nem sempre estas informações são representativas suficientes para criação dos modelos.
Esta dificuldade é comum nas equipes onde os entrevistados estão inseridos, mesmo con-
siderando o fato de que cada equipe recebe os requisitos de uma forma, variando entre
requisitos textuais, mokups de telas, histórias de usuário ou fluxogramas.
Além da falta e informações para a criação dos modelos, outro ponto para o qual
deve ser dada atenção no processo de MBT é a gestão do tempo. De acordo com os
entrevistados, devido ao fato das equipes ágeis, em sua maioria, trabalharem com ciclos
curtos de entregas, o tempo disponı́vel para análise, desenvolvimento e testes do produto
que será entregue ao cliente é reduzido. Desta forma, se algum dos profissionais, ou até
mesmo se toda equipe, dedicar seu tempo para modelar todo o sistema para aplicação de
MBT, podem, nestes ciclos de desenvolvimento, não restar tempo hábil para execução de
todo processo de desenvolvimento e de testes do produto.
Para reduzir este problema, uma solução plausı́vel é a construção colaborativa dos
modelos. Desta forma, os modelos devem ter sua criação iniciada no inı́cio do processo
de desenvolvimento, ou seja, quando os requisitos são levantados junto ao cliente. Neste
contexto, a modelagem iniciaria sendo feita pelo profissional que possui relação direta
5
http://epe.si/
287
com o cliente e posteriormente seria atualizada por todo time de desenvolvimento, tendo
as informações de teste inseridas pelos profissionais de qualidade. Contudo, é importante
enfatizar que projetos que fazem uso de métodos ágeis tem em sua cultura a boa recepção a
mudança de requisitos, por este motivo, um dos entrevistados aponta que uma dificuldade
que pode ser encontrada no momento da aplicação de MBT em equipes ágeis é encontrar
tempo e recursos humanos para fazer contı́nuas atualizações nos modelos.
Para que este fluxo de construção e atualização contı́nua dos modelos obtenha
êxito, se faz necessário o envolvimento de toda a equipe no processo e isto faz com que
surja outro desafio: conscientizar as equipes de desenvolvimento da importância de MBT
e dos benefı́cios que ele pode trazer, facilitando o trabalho da equipe e melhorando a
qualidade dos produtos entregues. Para isso, se faz necessário utilizar estratégias de de-
senvolvimento de equipes para prover a capacitação e fomentar a motivação da equipe de
desenvolvimento para o emprego desta técnica. Isto pode ser considerado um desafio por-
que, devido ao princı́pio ágil de utilizar documentação enxuta, alguns projetos optam pela
não utilização de modelos para representação de requisitos, o que faz com as equipes de
desenvolvimento não estejam familiarizadas com linguagens de modelagem (e.g. UML).
Outro ponto de dificuldade relatado de forma unânime pelos especialistas diz res-
peito a falta de integração da ferramenta de MBT com as ferramentas de desenvolvimento
de sistemas. Os especialistas entrevistados sugerem que além de gerar scripts automa-
tizados, a ferramenta que realiza MBT deve ser integrada com as IDEs tradicionais de
desenvolvimento de sistemas (e.g. Eclipse e Visual Studio). Além disso, os scripts devem
ser gerados de forma automatizada e utilizando a estrutura padrão de alguma ferramenta
de automação de testes (e.g. Seleniun WebDriver), para que a manutenção seja facilitada
e as habilidades dos profissionais valorizadas.
Após a geração dos scripts de testes, em virtude da técnica de MBT gerar scripts
para todos os caminhos de teste compreendidos pela funcionalidade modelada, se faz
necessário utilizar, de forma conjunta, outras técnicas para viabilizar a execução de todos
os testes. Estas técnicas devem ser aplicadas para reduzir o número de entradas as quais o
sistema precisa ser submetido para ser testado. São exemplos de técnicas que podem ser
empregadas Pairwise test (que foi citada por um dos especialistas entrevistados), partição
e equivalência e análise de valor limite.
Juntamente com a redução do número de entradas as quais o sistema precisa ser
submetido, é necessário que os scripts gerados possuam alguma forma de priorização,
podendo assim evitar que sejam realizados testes de prioridade menor quando não existe
tempo disponı́vel para execução de todos os casos de teste gerados.
5. Definição e Descrição dos Problemas Comuns encontrados

Nesta seção apresentamos a definição e a descrição dos problemas que são comuns na
literatura e nas entrevistas com os especialistas.
I. Ausência de tempo para criação de modelos: devido aos ciclos de desen-
volvimento serem bastante curtos, em times de desenvolvimento ágil, se faz necessário
prover mecanismos para que a criação dos modelos seja feita durante todo o ciclo de
desenvolvimento e não apenas no intervalo de tempo destinado ao teste de software, con-
forme relatado por Entin et al. (2012)[11]. Isto é, quando for realizado o primeiro contato
288
com o cliente para levantamento de requisitos e/ou escrita de histórias de usuário já deve
ser iniciada a criação dos modelos. Os modelos produzidos devem ser adaptados durante
todo o processo de desenvolvimento. Alternativamente os modelos podem ser construı́dos
automaticamente, baseados na especificação de requisitos e/ou nas histórias de usuário.
II. Falta de informações para criação dos modelos: uma dificuldade recorrente
é que as documentações existentes em projetos ágeis não são suficientes para a concepção
dos modelos para realização de MBT. Por este motivo embora algumas equipes costu-
mem efetuar a criação de modelos, estes não costumam ser ricos em detalhes, conforme
descrito por Katara et. al (2006)[14], e tendem a ser construı́dos baseados no conheci-
mento de negócio prévio do testador oque os torna são passı́veis de falhas que impac-
tam diretamente na qualidade dos testes. Além disso, devido a cultura de utilizar me-
nos documentação e mais contato pessoal, muitas informações podem ser discutidas em
reuniões e não documentadas o que também impacta na qualidade dos modelos.
III. Necessidade de dinamismo para adaptar as mudanças: um princı́pio
básico dos métodos ágeis é que as equipes devem estar abertas para receber as mudanças
de requisitos solicitadas pelos clientes. Neste contexto é necessário que a técnica de testes
utilizada propicie a alteração contı́nua dos artefatos para suprir esta demanda. MBT pode
auxiliar as equipes de desenvolvimento neste sentido, pois possibilita a automação do
sincronismo das alterações realizadas nos modelos com a atualização dos artefatos de tes-
tes. Entretanto, é necessário um mapeamento eficiente entre modelo e requisito para que,
quando ocorrerem mudanças de requisitos, possa ser alterado apenas a parte do modelo
que é impactada pela mudança sem necessidade de refazer completamente a modelagem.
IV. Dificuldade na criação manual dos Modelos e execução manual de casos
de teste: uma dificuldade inerente ao processo de MBT é a criação manual dos modelos
que são a base da aplicação da técnica. Esta dificuldade acontece por vários motivos já
descritos (e.g. tempo, recurso, conhecimento de modelagem). Desta forma para uma
melhor eficácia de MBT de faz necessário encontrar técnicas para a geração automatizada
destes modelos. Além disso, indo ao encontro a uma prática comum em métodos ágeis,
a técnica de MBT precisa gerar scripts automatizados de testes e não casos de testes para
execução manual.
V. Necessidade de adoção de técnicas de priorização para a seleção dos scripts
e casos de teste de maior relevância: Este desafio surge, uma vez que, os métodos
de geração de sequências de testes, costumeiramente utilizados pelas ferramentas de
MBT (e.g. W [7] e Harmonized State Identification (HSI) [17]), efetuam a geração de
sequências que cobrem todas as funcionalidades do sistema em teste, porém, embora es-
tes métodos busquem selecionar os melhores caminhos para minimizar os testes e ainda
garantir a cobertura, o número de scripts ou casos de teste gerados pode a ser elevado.
Neste caso, quando o ciclo de entrega do projeto é curto, se faz necessário priorizar os
testes, garantindo que as funcionalidades prioritárias sejam testadas antes das outras. Ou-
tro cenário em que a priorização ou seleção dos testes que serão executados prioritaria-
mente se faz necessário é em testes de regressão, aonde o testador não deseja testar toda
a funcionalidade e sim apenas uma fração dela, aonde foram feitas alterações.
VI. Necessidade de adoção de conjunta de MBT com outras técnicas de teste:
Esta dificuldade, assim como a anterior, está relacionada a redução da quantidade de testes
289
que precisam ser feitos para validar um sistema. Em alguns cenários o número de testes
é elevado devido a quantidade de entradas a qual o sistema pode ser submetido. Desta
forma, utilizar técnicas de seleção de entradas como por exemplo partição e equivalência,
análise de valor limite e pairwise test se tornam de grande importância para garantir a
cobertura reduzir a quantidade de testes.
Baseado na problemática apontada pela literatura, considerando a análise das res-
postas obtidas nas entrevistas com os especialistas e a experiência que adquirimos nos
últimos anos com aplicação de MBT, realizamos a concepção de um conjunto de boas
práticas para a implantação de MBT em times ágeis que será apresentado na próxima
seção.
6. Proposta de Boas Práticas

Para que possamos conceber este conjunto de boas práticas para implantação de MBT em
Métodos Ágeis, primeiramente identificamos os principais problemas e desafios encontra-
dos pelas equipes de desenvolvimento. Posteriormente, para cada problema identificado,
propomos uma ou mais estratégias de solução através de boas práticas. Consideramos
que ao seguir este conjunto de boas práticas, as equipes de desenvolvimento obterão maior
eficácia na implantação de MBT, e por este motivo poderão usufruir melhor das vantagens
que esta técnica proporciona e consequentemente agregar qualidade ao produto entregue
ao cliente. Estes resultados serão atingidos através da prevenção de erros e problemas
comuns nos trabalhos analisados na literatura e nos relatos dos entrevistados. A partir dos
desafios citados e visando a melhor integração da técnica de MBT com métodos ágeis,
elencamos as seguintes boas práticas para implantação de MBT em métodos ágeis:
1. Conscientize a equipe da importância da criação de modelos e dê ciência dos

benefı́cios da utilização de MBT:
• Apresente resultados positivos reais de equipes que utilizam modelos para
guiar o processo de desenvolvimento.
• Fale sobre a técnica de MBT, apresente as vantagens, e permita a equipe
que sane suas dúvidas de forma a agregar confiança na técnica.
2. Proporcione para toda a equipe de desenvolvimento capacitação para criação dos
modelos.
3. Conscientize a equipe de desenvolvimento sobre a importância do trabalho em
equipe e especialmente da importância dos testes de software.
4. Inicie o processo de criação de modelos juntamente com a escrita das histórias de
usuário:
• Quando são escritas as histórias de usuário pelo Product Owner, o mesmo
efetua a criação do primeiro modelo, a exemplo do proposto por [12].
• Os modelos criados pelo Product Owner deverão ser evoluı́dos pela equipe
de desenvolvimento. Esta evolução deverá ser feita sempre que forem al-
terados requisitos, seja esta alteração solicitada formalmente ou definida
em reunião de equipe. Esta etapa visa solucionar a questão aponta na en-
trevista referente a falta de controle dos requisitos definidos em reuniões.
• No momento da realização dos testes de software, que pode ser paralelo
ao desenvolvimento da funcionalidade, devem ser revisados e otimizados
os modelos e realizada a geração dos artefatos de testes.
290
Esta proposta busca auxiliar resolver os problemas I, II e II, descrito na Seção
5, pelos seguintes motivos: com a criação dos modelos no inı́cio do processo
de desenvolvimento, ainda em contato com o cliente, as equipes ganharão maior
tempo para construir os modelos e maior riqueza de detalhes dada a presença do
cliente para sanar dúvidas. Além disso, com os modelos sendo construı́dos junto
com o software estes poderão ser mais facilmente adaptados quando necessário
por mudança de requisito ou manutenção.
5. Priorize a geração automatizada de modelos e scripts evitando a criação manual
de modelos e de casos de teste. Esta prática visa auxiliar na solução dos problemas
I e IV, uma vez que gerando automaticamente os modelos e os demais artefatos de
testes otimiza-se o tempo de trabalho da equipe
6. Inclua, no processo de MBT, uma forma de realizar a priorização dos scripts de
testes gerados, de forma que o responsável pelos testes possa definir qual parte
do sistema em teste deseja testar prioritariamente. Esta definição pode ser feita
através de uma parametrização na ferramenta de MBT que permita definir quais
atividades de um determinado modelo devem obrigatoriamente ser cobertas pelos
testes. Esta prática visa atender ao desafio número V, uma vez que visa solucionar
o problema de priorização dos casos de teste.
7. Busque alinhar a atividade de testes de software com os princı́pios do manifesto
ágil, evitando que as equipes se segmentem por visualizarem a atividade de testes
como um processo separado das demais atividades da equipe de desenvolvimento.
Esta prática visa ajudar na solução de todos os desafios encontrados, uma vez
que quando a equipe estiver alinhada aos princı́pios e valores ágeis, o time deverá
trabalhar de forma mais integrada afim de obter melhores resultados e se adequar
melhor com as práticas supra citadas.
7. Avaliação da Proposta de Boas Práticas

Com objetivo de realizar uma validação inicial da nossa proposta de boas práticas, pre-
paramos uma survey com profissionais que trabalham em equipes de desenvolvimento de
sistemas para identificar qual a visão deles em relação às boas práticas propostas. Opta-
mos pela realização desta survey porque acreditamos que as pessoas que estão diariamente
trabalhando na indústria são as pessoas que melhor podem descrever como acontecem os
processos cotidianos e que medidas podem ajudar ou não o seu trabalho.
Esta survey foi escrita em estrutura de questionário e distribuı́da de forma virtual.
O questionário foi formado por perguntas para identificação do perfil do respondente e
perguntas relacionadas diretamente com o processo de teste baseado em modelos e as
sugestões de melhorias propostas 6 . Obtivemos 30 respostas para esta survey, sendo que
34,6% dos respondentes trabalham com testes a mais de 6 anos, 27,6 % entre 4 e 6 anos,
24,1% de 2 a 4 anos e 13,8% até dois anos. Analisando as respostas obtidas podemos
constatar que obtivemos um retorno positivo em relação a proposta apresentada, sendo
que, a sı́ntese das respostas obtidas será apresentada na sequência.
As propostas de melhoria número um e dois foram validadas da seguinte maneira:
questionamos primeiramente se o respondente acreditava que caso uma equipe de de-
senvolvimento ágil seja conscientizada da aplicabilidade e benefı́cios de utilizar MBT, a
6
Este questionário pode ser visualizado na ı́ntegra em https://goo.gl/iobm2e
291
equipe poderia motivar-se para aprender e explorar a técnica, e o resultado foi que 84%
dos entrevistados acreditam que sim. Além disso, perguntamos também se os responden-
tes acreditavam que a realização de capacitações para a criação de modelos auxilia ou
viabiliza a criação de modelos durante o processo de desenvolvimento e testes de soft-
ware. Esta pergunta teve 92% de respostas positivas. O conjunto destas duas respostas
nos leva a crer que as boas práticas propostas números um e dois estão condizentes com
a realidade das equipes.
A proposta de boas práticas número três, que diz respeito ao trabalho colabora-
tivo foi avaliada através da seguinte pergunta: Conscientizar a equipe da importância do
trabalho coletivo, e da importância da realização de testes no processo de desenvolvi-
mento de sistemas pode motivar os profissionais a envolver-se com a criação e edição de
modelos que representem o funcionamento esperado para o software? Obtivemos, para
esta pergunta 96% de respostas favoráveis e 4% contrários. O que nos leva a crer que
os profissionais que foram questionados estão alinhados com a nossa proposta de que a
conscientização da equipe auxilia o processo de implantação de MBT.
A proposta de boas práticas número quatro, que diz respeito a iniciar a criação dos
modelos juntamente com a escrita das histórias de usuários, juntamente com as suas sub
propostas, foi avaliada da seguinte forma: primeiramente questionamos os profissionais
se as equipes em que eles atuam costumam construir modelos comportamentais. Para
esta questão, obtivemos uma resposta apontando que 55,2% das equipes de desenvolvi-
mento efetuam, durante o processo de desenvolvimento, a construção de algum modelo
comportamental. Posteriormente, questionamos quem era responsável pela construção do
modelo e nesta resposta os mais diversos papéis foram citados. Estes dados podem ser
vistos na Figura 2, no gráfico “Construção de Algum Modelo Comportamental”. Mais es-
pecificamente 25% responderam que os modelos são construı́dos pelos desenvolvedores;
20,2% construı́dos pelo Project Owner (PO); 8,3% construı́dos pelo Scrum Master; 8,3%
construı́dos pelo cliente. Além disso 37,5% responderam que os modelos são construı́dos
por outros papéis não listados, e.g. testador, analista de testes e analista de sistemas. Estes
dados podem ser vistos na Figura 2, no gráfico “Quem Constrói os Modelos”.
A diversidade na responsabilidade da construção dos modelos é um indı́cio que
este trabalho pode ser dividido entre todos os profissionais e todo o processo de desen-
volvimento de sistemas, sem sobrecarregar apenas a etapa de testes de software. Isto nos
leva a crer que a proposta de boas práticas descrita no item quatro, está condizente com a
realidade. Além disso, questionamos os profissionais referente a viabilidade do PO ficar
responsável pela criação inicial do modelo que representa o fluxo principal do software.
Obtivemos uma aceitação de 86,2% (Figura 2, no gráfico Criação do Modelo Inicial pelo
PO) o que vem ao encontro ao proposto na proposta de melhoria número quatro.
A proposta de boas práticas número cinco foi validada através de duas perguntas.
A primeira: A geração automatizada de scripts para automação de testes baseado nos mo-
delos, pode apresentar vantagens quando aplicada em equipes ágeis? E a segunda: Uma
vez criados os modelos iniciais pelo PO, se você fosse desafiado a realizar atualizações
nos modelos, de acordo com a evolução do desenvolvimento, para posteriormente gerar
automaticamente os artefatos de teste, qual seria a sua opinião? Para a primeira pergunta
obtivemos uma aceitação de 96,6% (Figura 2 - Vantagem da Geração Automatizada) e
para a segunda, 82,8% dos respondentes declararam que seriam favoráveis, 13,8% fa-
292
voráveis com ressalvas e apenas 3,4% contrários (Figura 2 - “Realizar Atualização dos
Modelos”).
Na sequência afim de validar a proposta de boas práticas número seis, que diz
respeito a gerar scripts de teste com prioridades distintas, ou então permitir a seleção da
fração da funcionalidade que deseja testar, para que não sejam gerados scripts que repre-
sentem toda a funcionalidade, quando deseja-se testar um fluxo especı́fico, realizamos a
seguinte pergunta: Considerando um diagrama de atividades, ou outro diagrama que re-
presente o fluxo funcional do software de forma similar, você considera importante que
possam ser gerados scripts, que representem apenas as funcionalidades pré-selecionadas
do software representado no modelo? Obtivemos nesta pergunta 75,9% de resposta fa-
vorável e 24,1% contrária. Estes dados podem ser vistos na Figura 2, no gráfico “Geração
de Scrips por Funcionalidade”.
Analisando as respostas de todas as perguntas podemos constatar que com a
aplicação destas boas práticas, pode-se propiciar uma facilitação da implantação de MBT
em métodos ágeis, uma vez que as práticas propostas estão alinhadas com a visão dos en-
trevistados e resolvem lacunas especı́ficas que foram comuns na literatura e na entrevista
com profissionais especialistas na área.
Figura 2. Gráficos contendo os resultados da Pesquisa
8. Considerações Finais e Trabalhos Futuros

Apresentamos neste trabalho uma proposta de boas práticas para aplicação de MBT em
equipes de desenvolvimento ágil. Cada uma das boas práticas sugeridas, visa minimizar
um problema identificado como comum na revisão de literatura e relatado por profissi-
onais da área em entrevistas. Uma primeira avaliação das boas práticas sugeridas foi
293
realizada com 30 profissionais da área de teste que responderam a uma survey. Esta
avaliação inicial indica que as boas práticas sugeridas são coerentes e relevantes dada a
boa aceitação demonstrada pelos resultados deste estudo.
Contudo, embora os resultados preliminares apontem uma boa viabilidade e be-
nefı́cios na aplicação desta proposta de boas práticas, ainda existem diversos pontos para
serem explorados afim de evoluir este trabalho. Entre estes, objetivamos realizar um es-
tudo de caso, em um ambiente industrial, para avaliar se as boas práticas propostas neste
trabalho apresentaram benefı́cios reais para as equipes de desenvolvimento e teste. Assim
iremos mitigar um das principais ameaça a validade do estudo apresentado, que é o fato
do mesmo não ter sido aplicado ainda, de forma prática, em alguma empresa que trabalha
com métodos ágeis. Como resultado teremos como avaliar a nossa proposta com base nas
experiências reais de profissionais que a aplicaram em um ambiente real de desenvolvi-
mento. Ainda, almejamos evoluir este conjunto de boas práticas para um framework de
suporte a implantação e realização de testes baseados em modelos em times de desenvol-
vimento ágil.
Referências
[1] B. K. Aichernig, F. Lorber, and S. Tiran. Formal test-driven development with verified test
cases. In Model-Driven Engineering and Software Development (MODELSWARD),
2014 2nd International Conference on, 2014.
[2] L. Apfelbaum and J. Doyle. Model based testing. In Software Quality Week Conference,
1997.
[3] K. Beck, M. Beedle, A. Van Bennekum, A. Cockburn, W. Cunningham, M. Fowler,
J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, et al. Manifesto for agile software
development. http://www.agilemanifesto.org, 2001. acessado em 07/03/2017.
[4] M. Bernardino, E. M. Rodrigues, and A. F. Zorzo. Performance testing modeling: an
empirical evaluation of DSL and UML-based approaches. In Proceedings of the
31st Annual ACM Symposium on Applied Computing, 2016.
[5] M. Bernardino, A. F. Zorzo, and E. M. Rodrigues. Canopus: A domain-specific lan-
guage for modeling performance testing. In 2016 IEEE International Conference
on Software Testing, Verification and Validation (ICST), 2016.
[6] D. A. Carlson. Designing xml vocabularies with uml (poster session). In Addendum to
the 2000 Proceedings of the Conference on Object-oriented Programming, Systems,
Languages, and Applications (Addendum), 2000.
[7] T. S. Chow. Testing software design modeled by finite-state machines. IEEE Transactions
on Software Engineering, 4(3), 1978.
[8] L. T. Costa, R. M. Czekster, F. M. de Oliveira, E. M. Rodrigues, M. B. da Silveira, and
A. F. Zorzo. Generating performance test scripts and scenarios based on abstract
intermediate models. In Proceedings of the 24nd International Conference on Soft-
ware Engineering and Knowledge Engineering, 2010, 2012.
[9] L. Crispin and J. Gregory. Agile testing: A practical guide for testers and agile teams.
Pearson Education, 2009.
294
[10] V. Entin, M. Winder, B. Zhang, and S. Christmann. Combining model-based and capture-
replay testing techniques of graphical user interfaces: An industrial approach. In
Proceedings of the IEEE Fourth International Conference on Software Testing, Ve-
rification and Validation Workshops, 2011.
[11] V. Entin, M. Winder, B. Zhang, and S. Christmann. Introducing model-based testing in
an industrial Scrum project. In Proceedings of the 7th International Workshop on
Automation of Software Test, 2012.
[12] V. Entin, M. Winder, B. Zhang, and A. Claus. A process to increase the model quality in
the context of model-based testing. In Proceedings of the IEEE Eighth International
Conference on Software Testing, Verification and Validation Workshops (ICSTW),
2015.
[13] D. Jalalinasab and R. Ramsin. Towards model-based testing patterns for enhancing agile
methodologies. In SoMeT, 2012.
[14] M. Katara and A. Kervinen. Making model-based testing more agile: a use case driven
approach. In Proceedings of the Haifa Verification Conference, 2006.
[15] B. Kitchenham, O. P. Brereton, D. Budgen, M. Turner, J. Bailey, and S. Linkman. Syste-
matic literature reviews in software engineering–a systematic literature review. In-
formation and software technology, 51(1), 2009.
[16] N. Li, A. Escalona, and T. Kamal. Skyfire: Model-based testing with cucumber. In
Proceedings of the IEEE International Conference on Software Testing, Verification
and Validation, ICST 2016, 2016.
[17] G. Luo, A. Petrenko, and G. v. Bochmann. Selecting test sequences for partially-specified
nondeterministic finite state machines. In Protocol Test Systems. 1995.
[18] E. M. Rodrigues, F. M. de Oliveira, L. T. Costa, M. Bernardino, A. F. Zorzo, S. d. R. S.
Souza, and R. Saad. An empirical comparison of model-based and capture and
replay approaches for performance testing. Empirical Software Engineering, 20(6),
2015.
[19] E. M. Rodrigues, R. S. Saad, F. M. Oliveira, L. T. Costa, M. Bernardino, and A. F. Zorzo.
Evaluating capture and replay and model-based performance testing tools: An em-
pirical comparison. In Proceedings of the 8th ACM/IEEE International Symposium
on Empirical Software Engineering and Measurement- ESEM, 2014.
[20] E. M. Rodrigues, L. D. Viccari, A. F. Zorzo, and I. Gimenes. PLeTs - Test automa-
tion using software product lines and model based testing. In Proceedings of the
22nd International Conference on Software Engineering and Knowledge Enginee-
ring, 2010, 2010.
[21] S. Sivanandan and Y. C. B. Agile development cycle: Approach to design an effective
model based testing with behaviour driven automation framework. In Proceedings
of the 20th Annual International Conference on Advanced Computing and Commu-
nications, 2014.
295
Software Testing Processes in ISO Standards:
How to Harmonize Them?
Fabiano B. Ruy1,3, Érica F. Souza2, Ricardo A. Falbo3, Monalessa P. Barcellos3
1
Informatics Department – Federal Institute of Espírito Santo (IFES),
Campus Serra, Serra, ES, Brazil
2
Computer Department – Federal Technological University of Paraná (UTFPR),
Cornélio Procópio, PR, Brazil
3
Ontology and Conceptual Modeling Research (NEMO), Computer Science Department
– Federal University of Espírito Santo (UFES), Vitória, ES, Brazil
{fabianoruy, falbo, monalessa}@inf.ufes.br, ericasouza@utfpr.edu.br
Abstract. Software organizations usually adopt quality standards for

improving their testing processes. ISO provides different standards addressing
the testing process, such as ISO/IEC 12207, ISO/IEC 29110 and ISO/IEC
29119. However, these standards are not properly aligned and, when used in
combination, can give rise to conceptual inconsistencies and divergences. This
paper presents an initiative harmonizing ISO testing processes extracted from
these standards. Two ontologies were used in such initiative: a Software
Process Ontology for harmonizing the standards’ structure, and a Reference
Ontology on Software Testing (ROoST) for harmonizing standards’ content.
1. Introduction
Software Verification & Validation (V&V) activities intend to ensure, respectively, that
a software product is being built in conformance with its specification, and that it
satisfies its intended use and user needs [IEEE 2004]. Software testing is the dynamic
V&V of the behavior of a program against the expected one, considering a finite set of
test cases [Bourque and Fairley 2014]. It is a fundamental process for software
organizations, since it allows achieving quality software products. To be effective,
testing activities should be integrated into a well-defined and controlled process. The
importance of testing processes is widely recognized, and there is a growing concern in
how to improve the accomplishment of this process [TMMi Foundation 2012].
To define and improve their testing processes, software organizations can adopt
testing-related standards that support better defining the activities to be performed,
artifacts to be produced, roles involved, and other elements of this process. These
standards are used to guide software organizations efforts towards quality software
testing processes. In this context, the International Organization for Standardization
(ISO) has a set of standards covering the testing domain, such as ISO/IEC 12207
[ISO/IEC 2008], ISO/IEC 29110 [ISO/IEC 2011] and ISO/IEC 29119 [ISO/IEC 2013].
ISO/IEC 12207 and ISO/IEC 29110 are broader standards in the sense that they provide
a comprehensive description of software life cycle processes, including recommended
testing practices. On the other hand, ISO/IEC 29119 is specific for software testing. Its
purpose is to define a generic process model for software testing that can be used by any
organization when performing any form of software testing [ISO/IEC 2013].
296
The combined use of standards can help software organizations to define and
improve their testing processes. When an organization adopts related standards, it can
exploit synergies between them, overcoming the weakness of a single standard by the
strengths of the others [Jeners et al. 2013]. Regarding the testing domain, for example,
while ISO/IEC 12207 and 29110 are more general, ISO/IEC 29119 provides richer
details concerning testing activities and work products. While ISO/IEC 29119 focuses
on testing, the other two offer a better view on how testing activities interrelate with the
other development processes. Thus, the process team can select the portions of each
standard that better address the organization’s goals for defining its processes.
However, implementing a process adherent to multiple standards is not an easy
task. Besides the well-known difficulties on implementing each standard, there is a
significant effort on considering the portions from different standards dealing with the
same aspects. Most of the standards are created independently, by different groups or
organizations, defining their own scope, structure, abstraction level and terminology
[Biffl et al. 2006], and not necessarily sharing the same semantics. Even standards
developed by the same standardization organization, attempting to share a similar
conceptual base (e.g. ISO/IEC 24744 metamodel intends to be a common basis for ISO
Software Engineering standards [ISO/IEC 2007]), are not perfectly aligned and can
present structural and conceptual divergences. The ISO itself has started an initiative for
harmonizing its own standards [Henderson-Sellers et al. 2014].
Among the main identified problems regarding the combined use of multiple
standards, there are [Yoo et al. 2006] [Pardo et al. 2013] [Jeners et al. 2013]: diversity in
the representation structure; diversity in the adopted vocabulary (in terms and
meanings); differences in elements granularity; and divergent presentation (regarding
language, abstraction level, and subjectivity). Hence, when multiple standards are used
in combination, some harmonization effort should be considered. By harmonizing the
standards, they can be analyzed and compared, similarities can be identified and
divergences solved, providing an integrated view of the target standards. Thus,
organizations can reduce costs and efforts on the standards deployment. These problems
can be associated to the structure and content of the involved standards. Structural
issues arise when standards are organized in different ways. They can conflict, for
example, by using different notions, hard to be directly correlated; or worst, by applying
the same notions differently. Content problems, in turn, regard the knowledge
represented by the standards, which, again, can be described in different ways. Different
terms can be used to refer to equivalent content, making difficult to correlate them.
This paper discusses how test-related processes and activities provided by
distinct standards can be harmonized with the support of ontologies and conceptual
models. It focuses on testing processes extracted from the standards ISO/IEC 12207,
29110 and 29119, identifying some structural and content problems and discussing how
they can be addressed. The remainder of the text is organized as follows. Section 2
presents a background on Software Testing and related ISO standards, and introduces
some harmonization concepts, perspectives and techniques. Section 3 discusses
structural aspects regarding the selected ISO standards and how they can be addressed.
Section 4 focuses on content aspects, presenting a content mapping and discussing some
inconsistencies and divergences. Section 5 addresses related works, and Section 6
concludes the paper.
297
2. Background
To achieve quality software products, it is essential to perform Verification &
Validation (V&V) activities throughout the software development process. V&V
activities can be static and dynamic. The dynamic activities require the execution of a
program, while static activities do not. Static V&V are typically done by means of
technical reviews and inspections. Dynamic V&V, the focus of this study, are done by
means of testing [Mathur 2012].
Ideally, testing activities should be defined and organized as a well-defined
process. Although each organization may introduce particularities in its testing process,
in general, the following activities should be considered: Test Planning, Test Design,
Test Execution and Test Result Analysis [Bourque and Fairley 2014]. Key aspects of
Test Planning include, among others, coordination of personnel, management of
available test facilities and test environment, scheduling testing activities and planning
for possible undesirable outcomes. Test Case Design aims at designing the test cases
and test procedures. During Test Execution, test cases are executed, producing actual
results. In Test Result Analysis, test results are evaluated to determine whether (or not)
tests have been successful in identifying defects.
There are several standards that can support testing process improvement.
Among the ISO standards covering the testing domain, there are: ISO/IEC 12207
[ISO/IEC 2008], ISO/IEC 29110 [ISO/IEC 2011] and ISO/IEC 29119 [ISO/IEC 2013].
ISO/IEC 12207 provides a comprehensive set of life cycle processes, activities
and tasks for software. In relation to software testing, ISO/IEC 12207 provides activities
and tasks in many software specific processes. The Software Construction Process
includes activities to elaborate test procedures and test data for unit testing. In the
Software Integration Process, the main testing activities are to develop, document and
evaluate a set of test cases and test procedures for conducting qualification tests. The
Software Qualification Testing Process purpose is to confirm that the integrated
software product meets its defined requirements. This process may be used in the
Verification and Validation Processes. Finally, Software Verification Process confirms
that each software work product properly reflects the specified requirements, while
Validation confirms that the requirements for an intended use are fulfilled.
ISO/IEC 29110 is to be used by very small organizations for establishing
processes to implement development approaches considering some activities, including
software testing. The main testing tasks in this standard are established in the following
activities: Software Architectural and Detailed Design (includes tasks related to the
design of test cases and test procedures), Software Construction (includes unit testing
tasks, from its design to execution), and Software Integration and Tests (involves
setting, executing and updating test cases and test procedures).
Unlike the other two standards, ISO/IEC 29119 is specific for software testing.
Its purpose is to define a set of standards for software testing that can be used by any
organization when performing any form of software testing. It is divided in four parts:
Part 1 - Concepts and definitions, Part 2 - Test processes, Part 3 - Test documentation,
and Part 4 - Test techniques. The Part 1 introduces the main concepts of software
testing. Part 2 presents several test processes, organized in a model comprising three
layers: Organizational Test Process, Test Management Processes and Dynamic Test
298
Processes. Each layer describes processes composed of sub-processes. Part 3 describes
test documents that are output of the test processes specified in Part 2. Finally, Part 4
defines test design techniques that can be used during the Test Design and
Implementation process defined in Part 2.
Different standards on the same area are often applied together. However, this
combined adoption requires some harmonization. Standards Harmonization is not a
recent topic in Software Engineering. Since the 1990’s diverse initiatives have been
conducted to alleviate the effects of standards incompatibilities and to present a more
aligned view of them. Examples are mappings comparing specific standards (such as
ISO 9001 and CMM/CMMI [Paulk 1993]); development of conceptual models
representing a domain comprising a set of standards [García et al. 2006] [Falbo &
Bertollo 2009]; standards providing some alignment or mappings to other related
standards (such as MR-MPS.BR [SOFTEX 2016] does to CMMI-DEV [SEI 2010], and
ISO/IEC 29110 does to ISO/IEC 12207); and a number of approaches and techniques
aiming to homogenize, compare, map, integrate and harmonize standards [Ferchichi et
al. 2008] [Jeners et al. 2013] [Pardo et al. 2013] [Henderson-Sellers et al. 2014].
These initiatives vary in the domains and standards chosen, harmonization
perspectives, levels of detail, techniques applied, among others. Regarding the
harmonization perspective, some initiatives focus on the standards structure, analyzing
and making correspondences between structural elements only, i.e. those used to
organize/categorize the standards contents (such as process, activity and task in
ISO/IEC 29110); and some focus on the standards’ contents, dealing with the
represented knowledge (such as the Software Implementation process, the Software
Integration and Test activity, and the Perform Software Tests task in ISO/IEC 29110).
While the former presents a way for understanding the structural similarities and
differences between distinct standards, the second deals with the more specific
knowledge, used to describe the processes that are the target of the standards.
Several techniques have been applied for harmonizing standards [Pardo et al.
2013]. Homogenization is used for adapting the standards to a pre-defined structure.
This technique is related to the structural perspective, and can be used to support other
techniques. Comparison analyzes standards or their processes looking for similarities
and differences, while Mapping focuses on comparing the elements (such as activities,
work products and roles) and establishing links between them. Comparison and
Mapping can be used in both structural and content perspectives. Finally, Integration
consists in defining a new (integrated) artifact unifying the selected elements of
different standards. It can be applied to both standards’ structure and content. The more
elaborated harmonization approaches often apply a set of these techniques [Ferchichi et
al. 2008] [Jeners et al. 2013] [Pardo et al. 2013], e.g., first homogenizing the involved
standards to the same format, next mapping them to identify related elements, and
finally deriving an integrated artifact adherent to all involved standards.
Since these tasks frequently involve knowledge representation, some approaches
make use of conceptual models to support the harmonization efforts and for better
dealing with the standards’ knowledge [Jeners et al. 2013] [Pardo et al. 2015]. The
effective application of the techniques requires understanding the involved standards
and, mainly, the semantics underlying them and their domains. It is necessary to deal
with the elements meanings, and not only with the terms used to name them. In this
299
context, a semantic referential can be used for confirming the similarities and for
guiding a suitable domain-grounded solution when the standards conflict. Ontologies
have been frequently used in this quest [Henderson-Sellers et al. 2014] [Pardo et al.
2015]. An ontology is a formal, explicit specification of a shared conceptualization
[Studer et al. 1998]. In the context of standards harmonization, ontologies apply by
offering a well-agreed structure for homogenizing standards and classifying their
elements. Ontologies can provide concepts and relations specialized to the target
domain of harmonization, and thus can be used to solve inconsistencies and
terminological conflicts, bringing about benefits such as the provision of precise and
clear definitions and a more straightforward representation of processes and standards
[Pardo et al. 2013].
In the next sections, we discuss structural and content harmonization, including
problems and conflicts we have found in the aforementioned test-related ISO Standards.
These issues are addressed by applying harmonization techniques supported by an
ontological framework.
3. Software Testing in ISO Standards: Structure Harmonization

To understand the structural differences between the standards, we have developed a
structural model for each one. A Standard Structural Model (SSM) is a conceptual
model extracted from a standard, considering only its structural elements, i.e. those
elements used to describe processes in the standards (such as process, activity and
artifact), disregarding their contents (e.g., the specific processes, activities and artifacts
being described in the standard). Once the SSMs have been developed, we performed a
structural analysis to identify similarities and differences between them.
ISO standards, in general, decompose their work units in three granularity levels:
process, activity and task. ISO/IEC 12207 provides definitions for such types of work
units that are used by the other two standards. Process is defined as “a set of interrelated
or interacting activities which transforms inputs into outputs”. Activity is defined as “a
set of cohesive tasks of a process”. Finally, Task is defined as a “requirement,
recommendation, or permissible action, intended to contribute to the achievement of
one or more outcomes of a process”. In addition, a process aims to achieve a purpose,
and shall result in outcomes. An outcome statement can describe: the production of an
artifact, a significant change in state, or the meeting of specified constraints, such as
requirements, goals, etc. [ISO/IEC 2008]. Moreover, the three considered standards deal
with stakeholders and with work products in similar ways: stakeholders participate in
work units; while work units produce (output) and use (input) work products.
Stakeholder is defined as an “individual or organization having a right, share, claim or
interest in a system or in its possession of characteristics that meet their needs and
expectations” [ISO/IEC 2008]. Work product is defined as an “artifact associated with
the execution of a process” [ISO/IEC 2011].
Figure 1 shows the SSMs of the three considered standards. In the SSMs,
concepts in yellow and relations in black are those common to the three standards.
Concepts and relations in red are those that are specific to a standard, and thus they
cannot be harmonized. It is worth noting that concepts representing stakeholders and
work products are included in the SSMs even not being explicitly defined in the
standards’ structure (as it is the case of ISO/IEC 12207), but addressed in their texts.
300
Figure 1. Standards Structural Models
As Figure 1 shows, ISO/IEC 12207 has the simplest structure. Besides the
concepts and relations that are common to the other standards, it groups processes into
Process Categories. ISO/IEC 29119 is structurally strongly aligned to ISO/IEC 12207.
The main differences are admitting processes to be decomposed into sub-processes, and
considering documents as a composite work product (named Information Item in
ISO/IEC 29119).
ISO/IEC 29110 is the most detailed standard in terms of structure. Processes are
grouped into Profiles that, in turn, are grouped in Profile Groups. Information regarding
301
the way processes (and also activities) exchange information with other processes (and
activities) is also present in this standard. Stakeholders (named Roles in this standard)
are described in terms of Competencies, and can be the source or the destination of
work products. Moreover, ISO/IEC 29110 points out products generated and consumed
by a process (said internal products), as well as describes how some work products are
decomposed into other work products. Finally, this standard also points out Tools that
can be used to support activities, and how the activities contribute to achieve the process
objectives. An Objective is a specific goal to ensure the accomplishment of the process
purpose, and includes the outcomes related to the objective.
Although at first glance the SSMs of the three standards share several
commonalities (concepts in yellow and relations in black in Figure 1), when looking
deeper, there are still differences even where the standards seem to converge. Next, we
present some problems we detected when analyzing the portions of these standards
related to software testing:
(1) Vocabulary-related Problems: Although both ISO/IEC 29110 and 29119 refer to
12207 as being their structural basis, different terms are used to designate the same
concept. For instance, ISO/IEC 29110 uses “Role”, while 12207 and 29119 use
“Stakeholder” to refer to the same notion. ISO/IEC 29119 uses “Information Item”,
while 12207 and 29110 use “Work Product” to refer to the notion of artifacts
produced and consumed by work units. Organizations using these standards
together must identify those “synonyms” to link the corresponding notions.
(2) Work Unit Granularity: Although the three standards adopt a structure in which
processes are composed of activities that are composed of tasks, what is considered
a process, an activity or a task varies. For example, what is considered a process in
ISO/IEC 29119 can be defined as an activity in 12207 or 29110. ISO/IEC 29119 is
devoted to software testing, and describes processes composed of sub-process (e.g.,
the Test Management Process is composed of Test Planning, Test Monitoring &
Control, and Test Completion Processes), which are then decomposed into testing
activities and tasks. ISO/IEC 12207 defines a Software Qualification Testing
Process, but other processes such as Software Construction Process and Software
Integration Process clearly include activities and/or tasks related to test. In ISO/IEC
29110, test activities and tasks are part of the Software Implementation Process.
Identifying the correspondences between work units described at different levels in
different standards is a challenge, since we need to analyze each work unit without
considering the work unit granularity defined by the standards.
(3) Work Products Descriptions: Different standards define work products in
different levels of detail. While ISO/IEC 12207 does not define clearly the work
products (they are only mentioned in the text, often subjectively), ISO/IEC 29110
and 29119 (Part 3 is devoted to test documentation) provide detailed descriptions of
work products, describing even the information items that they must include.
Again, identifying correspondences between work products described at different
levels of details is a challenge, since the details provided, many times, are not
enough to allow establishing proper correspondences.
(4) Stakeholders Descriptions: Analogously to work products, ISO/IEC 29110 and
29119 define explicitly the stakeholders/roles involved in the activities and tasks,
while 12207 is almost always neutral in relation to this (most of the times just
mentioning a generic process “implementer” role).
302
(5) Outcomes Descriptions: Both ISO/IEC 12207 and 29119 define outcomes related
to processes, while 29110 defines process objectives that are related to outcomes.
Although 29110 adopts a little different view, the outcomes considered in this
standard are exactly the same of the ones considered in 12207, making a direct link
between these two standards. The main problem in this case is to find which
outcomes refer to the testing process. This problem is amplified in 12207, since
testing activities and tasks are spread out in several processes. In the case of 29119,
once it is difficult to establish correspondences between its work units and the ones
from 12207, it is hard to establish correspondences between the outcomes.
Moreover, outcomes refer to very different things (the production of an artifact, a
significant change in state, or the meeting of specified constraints), so it becomes
even harder to compare outcomes from these two standards.
By developing the SSMs, it becomes easier to compare and map standards’
concepts and relations. However, we must still deal with divergences between the
standards, and a direct correspondence could be not precise, or even possible. Instead of
just linking the related structural elements, we advocate in favor of using an ontology as
interlingua. This allows us to use a semantic referential to which we can link each SSM
element. The ontology provides the domain grounding, independently of any specific
standard. Thus, structural inconsistencies and divergences can appear more explicitly
and be solved by following the semantic referential. Since all structural elements are
related to the corresponding ontology concepts, the SSMs can be homogenized
according to the ontology, being more precisely compared. Moreover, later, during
content harmonization, this referential guides the mapping by allowing only elements
with similar semantics to be compared.
Figure 2 presents a fragment of the Software Process Ontology (SPO) of SEON1
(Software Engineering Ontology Network) [Ruy et al. 2016], useful for the scope of our
harmonization effort (i.e., work units, work products and stakeholders and how they
relate). We used this fragment for harmonizing the structure of the three ISO standards
considered. It is important to highlight that we did not consider outcomes in the scope of
our harmonization effort, because outcomes refer to very different things, being hard to
establish a meaning for this concept.
According to SPO, processes are actions performed by software organizations.
There are two types of processes: General process represents overall process performed
in a specific project or organization, which is necessarily composed of specific
processes. Specific processes are composed of activities. Analogously, an activity can
be simple or composite. A composite activity is composed of other activities, while a
simple activity is an atomic action that cannot be decomposed into smaller activities.
Activities produce and use artifacts. Artifacts can be simple or composite. Composite
artifacts are composed of other artifacts; simple artifacts are atomic objects. Moreover,
regarding its nature, an artifact can be a software product, a software item, a model, an
information item or a document. Stakeholders participate in activities.
1
SEON is available at https://nemo.inf.ufes.br/seon/.
303
Figure 2. The SPO fragment used for harmonizing the Standards Structural Models.
It is important to say that SPO is grounded in the Unified Foundational Ontology
– UFO [Guizzardi et al. 2008]. According to UFO, processes and activities (shown in
yellow in Figure 2) are actions; artifacts (shown in green in Figure 2) are objects; and
stakeholders (shown in blue in Figure 2) are agents. Based on this foundation, in Table
1, we establish admissible mappings between the standards’ elements and the ontology’
concepts, clarifying some notions used in the SSMs.
Table 1. Admissible Structural Mappings between Standards’ Elements and Ontology’s Concepts.
Ontology Concept ISO 12207 Element ISO 29110 Element ISO 29119 Element
Process (action) Process (action)
Performed Process (action) Process (action)
Activity (action) Activity (action)
Process (action) Process (action)
Activity (action)
Performed Activity (action) Activity (action) Activity (action)
Task (action)
Task (action) Task (action)
Information Item (object)
Artifact (object) Artifact (object) Product (object)
Document (object)
Stakeholder (agent) Stakeholder (agent) Role (agent) Stakeholder (agent)
For example, concerning work units, we can see equivalent elements with
distinct classification. “Perform the defined tests” is considered a task in ISO/IEC
29110 (SI 5.4); both an activity (7.1.7.3.1) and a task (7.1.7.3.1.1) in ISO/IEC 12207;
and a process (8.4) or an activity (8.4 TE1) in ISO/IEC 29119. With the ontology, each
structural element can be linked to the proper concept according to its real meaning. The
alignment of the SSMs by means of an ontology is a fundamental step in harmonizing
these standards since it “translates” each standard to the same semantic interlingua, and
defines which types of elements can be compared during the content harmonization, as
discussed in next section.
4. Software Testing in ISO Standards: Content Harmonization

Regarding the standards’ contents, ISO/IEC 29119, being the one specific for software
testing, is the most complete and detailed. It establishes several test-related processes,
organized in three layers. The first layer contains only one process: the Organizational
Test Process, which deals with organizational test policies, strategies, processes,
procedures and other assets. The second layer, Test Management Processes, defines
three processes that cover test management, namely: Test Planning Process, Test
304
Monitoring and Control Process, and Test Completion Process. Finally, the last layer,
Dynamic Test Processes, defines generic processes for performing dynamic testing,
namely: Test Design and Implementation Process, Test Environment Set-Up and
Maintenance Process, Test Execution Process, Test Incident Reporting Process.
ISO/IEC 12207 is the most general, and is organized in terms of System Context
Processes (including Agreement, Organizational, Project and Technical Processes) and
Software Specific Processes (including Software Implementation, Support and Reuse
Processes). The Life Cycle Model Management Process aims to define, maintain, and
assure availability of policies, life cycle processes, life cycle models, and procedures for
use by the organization. In this sense, we can say that it is responsible to deal with
organizational test policies, strategies, processes and procedures, like the Organizational
Test Process of ISO/IEC 29119. The Infrastructure Management Process aims to
provide the enabling infrastructure and services to projects to support organization and
project objectives throughout the life cycle. Thus, it covers the Test Environment Set-
Up and Maintenance Process of ISO/IEC 29119. The Project Planning and the Project
Assessment and Control Processes addresses project planning, activation, monitoring,
control, assessment and closure, and cover the Test Management Processes of ISO/IEC
29119. The remainder processes of ISO/IEC 29119 are covered by activities and tasks
spread out in different Software Specific Processes of ISO/IEC 12207, including the
following (as discussed in Section 2): Software Construction, Integration, Qualification
Testing, Verification and Validation Processes.
ISO/IEC 29110 is also a general standard, but simpler, since it is devoted to very
small organizations. It does not cover organizational aspects, neither aspects related to
infrastructure. It has only two processes: Project Management Process and Software
Implementation Process. The Project Management Process comprises activities to plan,
execute, assess, control and close the project, being directly related to the Project
Planning and Project Assessment and Control Processes of ISO/IEC 12207. Test
activities are covered by activities in the Software Implementation Process, in particular
Software Architectural and Detailed Design, Software Construction, and Software
Integration and Tests, as discussed in Section 2.
For harmonizing the standards’ contents, we used ROoST [Souza et al. 2017],
the SEON’s Software Testing Ontology, as an interlingua. ROoST extends SPO and this
enabled us to align structural and content harmonization. We focused on test technical
activities, disregarding test management, test environment setting, defects correction,
configuration management, and test organizational aspects. Table 2 shows ROoST work
units and the standards’ mappings to it. The first column presents ROoST concepts. The
other columns present the work units of each standard mapped to these concepts,
usually with total coverage, but some with partial, as indicated.
Total coverage here refers to the fact that the standard’s work unit is completely
covered by the ROoST concept. Partial coverage means that the standard’s work unit is
broader and that there are some portions that are not covered by the ROoST concept.
For instance, the Software Construction Process of ISO/IEC 12207 has several activities
and tasks that are not related to test, and thus that are not related to any ROoST concept.
305
Table 2. Content Mappings.
ROoST Concept ISO 12207 Element ISO 29110 Element ISO 29119 Element
(7.1.5) Software Construction (SI.3) Software
Process {partial} Architectural and
(7.1.6) Software Integration Detailed Design {partial}
Testing Process Process {partial} (SI.4) Software (8) Dynamic Test Processes
[Performed Process] (7.1.7) Software Qualification Construction {partial} {partial}
Testing Process (SI.5) Software
(7.2.5) Software Validation Integration and Tests
Process {partial} {partial}
(8.2) Test Design &

(7.1.5.3.1.1) Develop test (SI.3.5) Establish or Implementation Process
procedures and data for testing update Test Cases and
(8.2.4.1) Identify Feature Sets
each software unit and database Test Procedures
(and tasks a,b,c,d,e)
(7.1.6.3.1.4) Develop and (SI.3.6) Verify and obtain
(8.2.4.2) Derive Test
document a set of tests, test approval of the Test Cases
Conditions (and tasks a,b,c,e)
cases, and test procedures and Test Procedures
(8.2.4.3) Derive Test Coverage
Test Case Design (7.2.5.3.2.1) Prepare selected test (SI.4.4) Design or update
Items (and tasks a,b,c)
[Performed Activity] requirements, test cases, and test unit test cases
specifications for analyzing test (8.2.4.4) Derive Test Cases
(SI.5.2) Understand Test
results (and tasks a,b,c,e)
Cases and Test
(7.2.5.3.2.2) Ensure that the Procedures (8.2.4.5) Assemble Test Sets
artifacts reflect the particular (and tasks a,b)
(SI.5.3) Update Test Cases
requirements for the specific and Procedures for (8.2.4.6) Derive Test
intended use integration testing Procedures (and tasks
a,b,c,d,f)
(7.1.5.3.1.2) Test each software
unit and database, and document (8.4) Test Execution Process
the test (8.4.4.1) Execute Test
(7.1.6.3.1.2) Integrate the Procedures (and tasks a,b,c)
software units and software (8.4.4.2) Compare Test Results
components and test {partial} (SI.5.4) Perform Software (and tasks a,b)
Test Execution (7.1.7.3.1.1) Conduct qualification Tests using Test Cases and (8.4.4.3) Record Test
[Performed Activity] testing Test Procedures for Execution (and task a)
(7.2.5.3.2.3) Conduct the tests Integration
previously selected and analyzed (8.5) Test Incident Reporting
(7.2.5.3.2.5) Test the software Process
product as appropriate in (8.5.4.2) Create/Update
selected areas of the target Incident Report (and tasks a,b)
environment
(7.1.5.3.1.5) Evaluate and
document the software code and
test results
(7.1.6.3.1.5) Evaluate and
document the integration plan,
Test Result Analysis design, code, tests, test results (8.5.4.1) Analyze Test Results
-
[Performed Activity] (7.1.7.3.1.3) Evaluate the design, (and tasks a,b)
code, tests, test results, and user
documentation
(7.2.5.3.2.4) Validate that the
software product satisfies its
intended use
Besides the work units, we also harmonized artifacts (namely: Test Plan, Test
Case, Test Results, Test Case Design Input and Code to be Tested) and stakeholders
306
(namely: Test Manager, Test Case Designer and Tester). Moreover, taking the
harmonized content shown in Table 2, we defined an integrated process, covering the
main test-related work units of the harmonized standards. The work products and
stakeholders’ mappings, as well as the integrated process, are not discussed here due to
space limitations.
Defining the content elements and mapping them to create an integrated view is
a complex effort requiring semantic analysis and tough decisions. Since ROoST
concepts extend SPO concepts, the content mappings were also supported by the
structural mappings results, considering only the admissible ones, as shown in Table 1.
Along the contents harmonization some issues were identified. They are related
to inconsistencies and divergences observed in the standards that can jeopardize a
harmonization effort. Next, we present the main issues detected:
(1) Content Organization: Each standard organize the contents in a different way.
While ISO/IEC 29119 presents a number of processes specific for tests,
decomposed in detailed activities and tasks, testing content in ISO/IEC 12207 and
29110 is more general and dispersed in different processes and activities devoted to
other areas such as software design, construction, integration and validation.
Sometimes even small tasks (or artifacts) include other actions (or information)
with the testing ones, being hard to extract/analyze the exact testing portion.
(2) Content Presentation: To understand and extract information from text in natural
language is not a simple task. The standards are subjective, sometimes providing
only information pieces or omitting them. The work units, in general, are well
structured; but the work products and stakeholders, when explicitly mentioned,
many times are not clearly related to the respective work units. Moreover, the
language used varies in some respects, such as writing style, adopted terms and
abstraction levels, which makes the comparisons harder.
(3) Granularity: The differences in granularity also affect the contents harmonization.
A couple of standards presenting work units with too distinct sizes are harder to
map, causing losing in precision. Sometimes several small tasks in a standard have
no direct correspondence and need to be all mapped as part of a single bigger
concept.
(4) Use of Terms: Inconsistency in the definition or description of some terms can also
cause understanding problems and consequently affect the contents harmonization.
For instance, ISO/IEC 29110 uses “Document” and “Information Item” for naming
artifacts. According to this standard, Information Items correspond to the Test
Processes outputs and the Document contains Information Items as shown in the
structural model. However, the standard allows dubious interpretation in some parts
of the text as to whether the outputs are Documents or Information Items, especially
in Parts 2 and 3 of the standard.
As we can notice, in both the structural and contents harmonization we deal with
some inconsistencies and divergences between the standards. The identified issues in
the contents occur mainly because of differences in the descriptions, as well as the
standard subjectivity, making harder to correlate them. As advocated here, such issues
can be mitigated by following a semantic referential. Once identified the standards
similarities, differences and main issues to be addressed, it is possible to provide an
integrated view of the target standards. These results are valuable to understand how the
307
standards behave in combination, being useful for reducing costs and efforts in
organizations aiming at their deployment, and for standardization organizations to
provide more aligned standards. Finally, the adopted approach favors the definition of
an integrated process, unifying the selected aspects of each standard.
5. Related Works
Several works have been conducted for harmonizing software engineering standards.
Jeners et al. (2013) propose an approach based on metamodels and comparison
techniques for mapping and integrating standards. They harmonize general software
process (such as CMMI-DEV) and governance (such as COBIT) standards. Pardo et al.
(2013) propose a harmonization framework with a detailed process, making use of two
ontologies, for managing and executing harmonization initiatives for multimodel
environments. They present some applications, mostly using IT Governance standards
for the Bank sector. Henderson-Sellers et al. (2014), as part of an ISO harmonization
initiative, propose an ontological framework as a reference infrastructure for
harmonizing the ISO SC7 standards. Although these works are general and applicable
for diverse software engineering related standards, we have not found studies
specifically discussing the issues around the testing process.
Considering our approach, we can make comparisons regarding aspects coming
from the findings of a systematic literature mapping we have conducted on Software
Engineering standards harmonization by means of common models. Like we do, many
works consider harmonization in two perspectives, structural (usually already embedded
in the approach) and content, for effectively analyzing the standards knowledge (e.g.,
[Ferchichi et al. 2008] [Jeners et al. 2013] [Pardo et al. 2013]). Regarding the
techniques, the most frequently applied are homogenization, mapping and integration.
Few works combine the three techniques, starting from the standards information
extraction, organizing and mapping it, and producing an integrated artifact (e.g.,
[Ferchichi et al. 2008] [Pardo et al. 2015]). A trend perceived in the analyzed works is
the increasing adoption of semantic referential for supporting the harmonization efforts
(e.g., [Henderson-Sellers et al. 2014] [Pardo et al. 2015]). Although those works use
metamodels and ontologies with some variation, the purposes converge to the same:
relying on a consistent representation of the domain semantics. In this sense, we are
working on a more advanced solution, by using SEON, an ontology network fully
grounded in UFO (a foundational ontology) and with a core ontology on software
processes and diverse domain specific ontologies, able to address standards regarding
several domains and description levels. Finally, the majority of the harmonization works
focus on supporting software organizations aiming at deploying multiple standards (e.g.,
[Pardo et al. 2015] [Mejia et al. 2016]). Our focus is, besides helping the standards
users, to make more evident the standards similarities and misalignments, providing
useful material also for supporting standards developers in future standards reviews.
6. Conclusions
This paper presented an initiative harmonizing software testing practices from three ISO
standards. It was supported by ontologies and conducted in two steps, focusing on
structural and content aspects. The standards similarities and differences were analyzed,
and the main result is a mapping between the standards contents, using of a software
testing ontology as interlingua. Along the harmonization efforts, diverse issues arose
308
regarding standards divergences and inconsistencies. The results produced and the
identified issues are useful for SPI initiatives in multimodel environments and also for
future improvements in the standards.
The harmonization of multiple standards involves a large amount of information
from the standards, which was captured, analyzed and mapped. Although we present
results covering most of the investigated aspects, some were omitted (due to space
limitations) and part of the test scope was disregarded in this study. For example,
concerning structural aspects we have not considered notions referring to very different
things, such as outcome. However, this is an important element, mainly in certification
standards, and thus we intend to address this notion in future works. Other example is
task, which can represent many different things, but we considered only its work unit
facet. Considering the contents, we have limited the scope as described, but we intend to
extend it in future works.
The use of a fragment of SPO for harmonizing the standards’ structures, and
ROoST for harmonizing standards’ contents showed valuable benefits in considering
semantics. Thus, as an ongoing work, we are developing an ontology-based approach
for standards harmonization, improving and systematizing the approach followed here.
Acknowledgements
This research is funded by the Brazilian Research Funding Agency CNPq (Process
461777/2014-2) and FAPES (Process 69382549/2014).
References
Biffl, S., Winkler, D., Höhn, R. and Wetzel, H. (2006). Software Process Improvement
in Europe: Potential of the New V-model XT and Research Issues. Software Process:
Improvement and Practice, 11(3), pp.229-238.
Bourque, P. and Fairley, R. E. (2014). Guide to the Software Engineering Body of
Knowledge, SWEBOK, Version 3.0. IEEE Computer Society Press.
Falbo, R.A. and Bertollo, G. (2009). A Software Process Ontology as a Common
Vocabulary about Software Processes. International Journal of Business Process
Integration and Management, 4(4), pp.239-250.
Ferchichi, A., Bigand, M. and Lefebvre, H. (2008). An Ontology for Quality Standards
Integration in Software Collaborative Projects. In: Proceedings of the First
International Workshop on Model Driven Interoperability for Sustainable
Information Systems (MDISIS’08), pages 17–30, Montpellier, France.
García, F., Bertoa, M., Calero C., Vallecillo, A., Ruíz, F., Piattini, M. and Genero, M.
(2006). Towards a Consistent Terminology for Software Measurement. Information
and Software Technology, 48 (8), pp.631-644.
Guizzardi, G., Falbo, R.A., Guizzardi, R.S.S. (2008). Grounding Software Domain
Ontologies in the Unified Foundational Ontology (UFO): The Case of the ODE
Software Process Ontology. In: Proceedings of the XI Iberoamerican Workshop on
Requirements Engineering and Software Environments, pp. 244-251. Recife, Brazil.
Henderson-Sellers, B., Gonzalez-Perez, C., Mcbride, T. and Low, G. (2014). An
Ontology for ISO Software Engineering Standards: 1) Creating the Infrastructure.
Computer Standards & Interfaces, 36(3), pp. 563-576.
309
IEEE (2004). IEEE Standard for Software Verification and Validation, Std 1012, New
York, USA.
ISO/IEC (2007). ISO/IEC 24744 - Software Engineering – Metamodel for Development
Methodologies.
ISO/IEC (2008). ISO/IEC 12207 - Systems and Software Engineering – Software Life
Cycle Processes.
ISO/IEC (2011). ISO/IEC TR 29110 - Software Engineering - Lifecycle Profiles for
Very Small Entities (VSEs).
ISO/IEC (2013). ISO/IEC 29119 - Software and Systems Engineering - Software
Testing (Parts 1, 2, 3 and 4).
Jeners, S., Lichter, H. and Rosenkranz, C.G. (2013). Efficient Adoption and Assessment
of Multiple Process Improvement Reference Models. e-Informatica Software
Engineering Journal, 7(1).
Mathur, A. P. (2012). Foundations of Software Testing. 5 ed. India: Dorling Kindersley
(India), Pearson Education in South Asia.
Mejia, J., Muñoz, E. and Muñoz, M. (2016). Reinforcing the Applicability of Multi-
Model Environments for Software Process Improvement Using Knowledge
Management. Science of Computer Programming, 121, pp. 3-15.
Pardo, C., Pino, F.J., Garcia, F., Baldassarre, M.T. and Piattini, M. (2013). From Chaos
to the Systematic Harmonization of Multiple Reference Models: A Harmonization
Framework Applied in Two Case Studies. Journal of Systems and Software, 86(1),
pp.125-143.
Pardo. C., García, F., Piattini, M., Pino, F.J. and Baldassarre, M.T. (2015). A 360-
degree Process Improvement Approach based on Multiple Models. Revista Facultad
de Ingeniería Universidad de Antioquia, (77), pp.95-104.
Paulk, M.C. (1993). Comparing ISO 9001 and the Capability Maturity Model for
Software. Software Quality Journal, 2(4), pp.245-256.
Ruy, F.B., Falbo, R.A., Barcellos, M.P., Costa, S.D. and Guizzardi, G. (2016). SEON:
A Software Engineering Ontology Network. In Proceedings of 20th International
Conference on Knowledge Engineering and Knowledge Management (EKAW’16),
Bologna, Italy, pp.527-542.
SEI (2010). CMMI for Development, Version 1.3. CMU/SEI-2010-TR-033. Software
Engineering Institute, Carnegie Mellon University.
SOFTEX (2016). Brazilian Software Process Improvement (MPS.BR) - General Guide:
2016, Brazil.
Souza, É.F.D., Falbo, R.D.A. and Vijaykumar, N.L., (2017). ROoST: Reference
Ontology on Software Testing. Applied Ontology, 12, pp. 59-90.
Studer, R., Benjamins, R. and Fensel, D. (1998). Knowledge Engineering: Principles
and Methods. Data & Knowledge Engineering, 25(1–2), pp. 161–198.
TMMi Foundation (2012). Test Maturity Model integration (TMMi) 1.0, Ireland.
Yoo, C., Yoon, J., Lee, B., Lee, C., Lee, J., Hyun, S. and Wu, C. (2006). A Unified
Model for the Implementation of both ISO 9001:2000 and CMMI by ISO-certified
Organizations. Journal of Systems and Software 79 (7), pp. 954–961.
310
QoS-TI: Um Framework Adaptável para Qualidade do
Serviço de Suporte de TI nos Institutos Federais
Cristiano D. da Silva1, 2, Alexandre Marcos de Lins Vasconcelos1
1
Centro de Informática – Universidade Federal de Pernambuco (UFPE)
Caixa Postal 7.851 – 91.501-970 – Recife – PE – Brazil
2
Instituto Federal de Educação, Ciência e Tecnologia de Goiás (IFG)
Av. Assis Chateaubriand, nº 1.658 – 74.130-102 – Goiânia – GO – Brazil
{cds3,amlv}@cin.ufpe.br
Abstract. This article presents QoS-TI, a framework that aims to support the
implementation or improvement of Service Desks in Federal Institute (IFs).
Structured through a life cycle based on the IDEAL model and a process
Toolbox, the QoS-TI framework incorporates several practices identified in
the quality and service models ITIL, ISO 9001, ISO 20000, CMMI Services
and MR-MPS-SV, and provides a "how-to" approach, rather than a "what to
do" approach. After its development, the framework was evaluated by IFs’s
specialists. The aspects evaluated received positive opinions from most
specialists.
Resumo. Este artigo apresenta o QoS-TI, um framework que tem por objetivo
apoiar a implantação ou a melhoria de Centrais de Serviços de TI nos Institutos
Federais (IFs). Estruturado através de um ciclo de vida baseado no modelo
IDEAL e de um Toolbox de processos, o framework QoS-TI incorpora diversas
práticas identificadas nos modelos de qualidade e serviços ITIL, ISO 9001,
ISO 20000, CMMI Services e MR-MPS-SV, e fornece uma abordagem focada
em “como fazer”, ao invés de “o quê fazer”. Após o seu desenvolvimento, o
framework foi avaliado por especialistas dos IFs. Os aspectos avaliados
receberam opiniões positivas da maioria dos especialistas.
1. Introdução
Os Institutos Federais de Educação, Ciência e Tecnologia (IFs) expandiram-se por meio
da estrutura multicampi, o que acarretou profundas mudanças em suas organizações
administrativa e acadêmica (Brasil, 2015). Em consequência dessa ampliação ocorreu o
aumento de demandas por serviços, sistemas e soluções de TI; o que ocasionou diversos
problemas. Ficou evidente a necessidade de desenvolver uma proposta que apoie os IFs
a melhorar o serviço de suporte de TI. A Central de Serviços de TI é uma alternativa,
pois implementa a interface única entre usuários e o setor de TI, todavia com papel mais
amplo do que apenas o de suporte técnico, pois engloba processos, pessoas e tecnologias
voltadas para o gerenciamento de serviços de TI.
Este trabalho teve como objetivo desenvolver um framework, com abordagem
prática em “como fazer”, que oriente a implantação e/ou a melhoria de Centrais de
Serviços de TI dos Institutos Federais. A proposta buscou incorporar as boas práticas
311
identificadas nos modelos de qualidade e serviços pesquisados, criando uma dinâmica
de implantação e melhoria de Centrais de Serviços de TI através de uma estrutura
composta por um Ciclo de Vida, baseado no modelo IDEAL (Mcfeeley, 1996), e de
um Toolbox de processos, estruturado conforme as sete dimensões do Extended Process
Maturity Framework – EPMF (Rudd, 2010).
A justificativa desta pesquisa é decorrente da carência de orientações de
implantação e/ou melhoria de uma Central de Serviços de TI sob o ponto de vista
prático, pois as principais normas, modelos e trabalhos estudados concentram “no que
tem que ser feito”, pois apresentam os requisitos que devem ser atendidos para a entrega
do serviço com qualidade, mas pouco abordam o “como”, isto é, não mostram o
caminho para a implantação da Central de Serviços. A avaliação da proposta foi
realizada por especialistas dos IFs, e com isso, buscou-se mostrar que o framework é
adequado para implantar e/ou melhorar uma Central de Serviços.
Além desta seção introdutória, o artigo está organizado da seguinte forma: a
seção 2 apresenta a revisão da literatura sobre qualidade de serviços, normas e modelos
de gerenciamento de serviços; a seção 3 apresenta trabalhos relacionados; a seção 4
apresenta o framework QoS-TI; a seção 5 apresenta a avaliação do framework, realizada
por especialistas; por fim, a seção 6 apresenta as considerações finais.
Inúmeras são as definições dadas ao termo “qualidade”. Feigenbaum (1961) enfatiza
que qualidade não é apenas uma técnica para eliminar defeitos nas operações, é um
sistema de gestão e um compromisso com a excelência. Juran (1992) define qualidade
como adequação ao uso, ou seja, são características que atendem as necessidades do
cliente e promovem a sua satisfação. Ishikawa (1993) afirma que a qualidade se
fundamenta no cliente, com a entrega de produtos/serviços que atendam às suas
necessidades. Para a Softex (2015), qualidade é um fator crítico de sucesso para o setor
de serviços, já o CMMI Institute (2010) afirma que a qualidade de um sistema ou
produto é altamente influenciada pela qualidade do processo utilizado para desenvolvê-
lo e mantê-lo. No que se refere ao termo “serviço” podemos citar a definição da
Information Technology Infrastructure Library - ITIL (OGC, 2007), “serviço é um meio
de entregar valor aos clientes, facilitando os resultados que eles querem alcançar sem
que tenham que assumir custos e riscos específicos”. Nesse sentido, o conceito de
qualidade de serviço utilizado neste trabalho está relacionado à qualidade do processo
de gerenciamento do serviço e ao atendimento das necessidades dos clientes.
Várias normas e modelos para melhoria da qualidade de serviços foram criadas e
aperfeiçoadas ao longo dos anos, e entre eles podemos destacar: a Information
Technology Infrastructure Library (OGC, 2007), a ISO 9001 (ABNT, 2015), a ISO/IEC
20000 (ABNT, 2011), o modelo de referência MR-MPS-SV (SOFTEX, 2015) e o
Capability Model Integration for Services (CMMI-SVC, 2010).
A ITIL é uma compilação das melhores práticas utilizadas para o gerenciamento
de serviços de tecnologia de informação, obtidas em consenso após décadas de
observação prática, pesquisa e trabalho de profissionais de TI em todo mundo
(Fernandes e Abreu, 2014). A biblioteca descreve sobre particularidades da função
Central de Serviços, dentre as quais podemos destacar: escolha e treinamento de
312
pessoal, definição de responsabilidades, tipos de estruturas, ponto único de contato,
medição de desempenho e pesquisa de satisfação. A norma ISO 9001 tem foco nas
especificações dos requisitos do sistema de gestão da qualidade da organização. A
norma ISO/IEC 20000 tem foco na padronização, no cliente, nos processos e na
melhoria contínua dos processos. O CMMI-SVC (Capability Maturity Model
Integration for Services) é um conjunto de boas práticas orientadas à gestão das
organizações prestadoras de serviços (CMMI Product Team, 2010). O MR-MPS-SV é
um modelo de referência para serviços (Softex, 2015). Comparando as normas e
modelos, podemos identificar os principais requisitos e processos aplicáveis à Central
de Serviços de TI.
Esta seção faz uma revisão de trabalhos que apresentam contribuições sobre
gerenciamento de serviços de TI, melhoria da qualidade de processos em serviços de TI
e implantação de Centrais de Serviços de TI. A Tabela 1 demonstra os trabalhos
relacionados e o diferencial do trabalho proposto.
Tabela 1. Diferença do trabalho proposto em relação aos trabalhos anteriores
Trabalhos Relacionados
Diferencial do Trabalho Proposto
Autores Título
Experiência de Implantação do Os autores aplicam um modelo de qualidade a uma Central de Serviços.
Araujo, et al.
MR-MPS-SV no Service Desk da O trabalho proposto por esta pesquisa busca garantir a qualidade desde
(2014)
ECO Sistemas o processo de implantação da Central de Serviços.
A Study of Service Desk Setup in O estudo de Tang e Todo foca na transformação de processos
Tang e Todo
Implementing IT Service específicos de uma Central de Serviços. Este trabalho propõe um
(2013)
Management in Enterprises framework de implantação ou melhoria do serviço.
Implementando o Nível G do MR- Os autores detalham os elementos de uma Central de Serviços e sua
Rodrigues, Souza
MPS-SV com base no conceito de relação com o modelo MPS. Esta pesquisa tem foco prático em “como
e Oliveira (2013)
Central de Serviços fazer” ao invés de “o que fazer”.
Towards an Improved IT Service Os autores analisam uma Central de Serviços em funcionamento e
Jantti, Cater-Steel
Desk System and Processes: A propõem soluções aos desafios encontrados. Esta pesquisa propõe uma
e Shrestha(2012)
Case Study solução para implantação ou melhoria de uma Central de Serviço.
Os autores focam em requisitos funcionais de processos específicos. O

Keller e Implementing a service desk: A
trabalho proposto foca em um framework de implantação como um
Midboe(2010) practitioner's perspective
todo, compreendendo desde a preparação até a operação.
A Implantação de um Service
Os autores implantaram uma Central de Serviços com base nos
Brigano e Barros Desk: Um Estudo de Caso
problemas operacionais. Este trabalho propõe uma solução com base em
(2010) Aplicando Conceitos do ITIL e do
melhores práticas.
PMBOK
Ao proceder à revisão bibliográfica em repositórios de teses e dissertações e em

diversos periódicos, no período de 2010 a 2016, não foram encontrados trabalhos que
propusessem um framework ou modelo com abordagem prática para a implantação e/ou
melhoria de Centrais de Serviços, assim podemos classificar os trabalhos encontrados
como moderadamente relacionados.
4. O Framework QoS-TI
O framework QoS-TI (Qualidade do serviço de suporte de TI) incorpora as melhores
práticas identificadas nos modelos pesquisados, criando uma dinâmica de implantação e
313
melhoria de centrais de serviços de TI, através de uma estrutura composta por um Ciclo
de Vida e um Toolbox de processos, ver Figura 1.
Figure 1. Estrutura do framework QoS-TI
O ciclo de vida consiste no conjunto de fases do projeto, estabelecendo o que

precisa ser feito para alcançar os objetivos (Pmbok, 2013). Este ciclo de vida está
detalhado na subseção 4.1. Já o Toolbox, consiste em um conjunto de dimensões que
fornecem processos com abordagem prática para apoiar a implantação e/ou melhoria de
centrais de serviços. Este Toolbox está detalhado na subseção 4.2.
Para facilitar o acesso pelos potenciais usuários, todos os fluxos e templates,
utilizados nas fases do ciclo de vida e os processos do Toolbox foram disponibilizados
no seguinte endereço eletrônico: https://sites.google.com/site/frameworkqosti/.
O framework foi originado atendendo os princípios descritos a seguir:
• Adaptabilidade – capacidade de aplicação a novas centrais de serviços ou às já
existentes (o framework é preparado para implantar uma central de serviços do
“zero” ou para diagnosticar problemas no serviço e implementar melhorias);
• Entrega de resultado – adota como estratégia de implantação uma abordagem
sequencial/iterativa, permitindo agregar valor ao cliente no decurso da execução
do projeto, através das fases e da implantação dos processos;
• Flexibilidade – pode ser utilizado para que a própria organização realize a
implantação da Central de Serviços de TI ou como parâmetro para terceirização;
• Foco na qualidade – incorpora práticas existentes em modelos especializados
para o gerenciamento de processos e serviços;
• Praticidade – descreve como implantar e/ou melhorar uma Central de Serviços
de TI, através de uma abordagem prática, que é composta por um ciclo de vida e
um Toolbox de processos.
314
4.1. Ciclo de Vida
A implantação do framework QoS-TI é realizada através de diversas fases e esse
conjunto de fases é denominado Ciclo de Vida. O ciclo de vida do framework QoS-TI é
composto por cinco fases, adaptadas do modelo IDEAL (MCFEELEY, 1996): iniciação;
diagnóstico; estabelecimento; ação e aprendizado.
O ciclo de vida inicia com a identificação das razões para a mudança e a
construção do patrocínio para o projeto. Em seguida é realizado um diagnóstico da
situação atual (AS-IS) para identificação de pontos de melhoria. Logo após, são
definidos os objetivos e o plano de ações para alcançar a situação desejada (TO-BE). A
fase Ação orienta a organização a implementar as ações planejadas, já a fase
Aprendizado completa o ciclo com o objetivo de aperfeiçoar o serviço prestado.
Uma fase engloba um conjunto de atividades, relacionadas de maneira lógica,
onde a sua conclusão é marcada por entregas (Pmbok, 2013). As fases possuem fluxos,
atividades e templates. As fases do framework QoS-TI são apresentadas a seguir.
Fase Iniciação: A fase Iniciação representa o início do ciclo de vida do framework, seu
propósito é construir uma base para a oferta do serviço. Para isso, a fase busca
responder às seguintes perguntas: As razões da organização para empreender o esforço
estão claramente definidas? As partes interessadas estão identificadas? Qual a estratégia
de oferta do serviço? Existe infraestrutura para gerenciar a execução do projeto de
implantação ou melhoria? O fluxo que representa a fase Iniciação é apresentado na
Figura 2.
Figura 2: Fluxo da fase Iniciação do framework QoS-TI
O fluxo começa com a identificação das razões para realizar a mudança

organizacional. Em seguida, busca-se estabelecer o contexto, ter clareza sobre a visão
organizacional e do que ela significa para a área de TI. A atividade “construir
patrocínio” busca o comprometimento dos stakeholders com os recursos essenciais para
o projeto. A análise comparativa de insourcing x outsourcing visa subsidiar a decisão da
oferta do serviço, se é mais vantajoso subcontratar ou oferecer com o quadro de pessoal
próprio. Após a análise comparativa, o Comitê Gestor de TI avalia e discute as
possibilidades, e decide qual a estratégia de oferta do serviço será adotada. Por último, a
atividade “estabelecer a infraestrutura de gerenciamento” define a equipe de
gerenciamento do trabalho, o cronograma inicial e o estabelecimento de regras de
comunicação. Os templates da fase Iniciação são: razões para mudança; contexto;
análise comparativa; infraestrutura de gerenciamento.
315
Fase Diagnóstico: O propósito da fase Diagnóstico é desenvolver um entendimento
sobre a situação atual (AS-IS), a fim de identificar necessidades de melhoria e
desenvolver recomendações. Nesta fase procuramos responder à seguinte pergunta:
Como estamos agora?
O instrumento de diagnóstico é um questionário, disponível nos templates do
framework. O resultado do diagnóstico identifica necessidades e oportunidades de
melhoria na oferta do serviço de suporte de TI. O principal artefato produzido nesta fase
é o relatório de resultados e recomendações. O fluxo que representa a fase Diagnóstico é
apresentado na Figura 3.
Figura 3: Fluxo da fase Diagnóstico do framework QoS-TI
O fluxo inicia com o planejamento do diagnóstico, são definidos: o período, o

local, os respondentes, o tempo, os critérios e a forma de aplicação do diagnóstico.
Nessa etapa é importante que o objetivo do diagnóstico seja totalmente entendido pelos
respondentes, os quais devem ter características e conhecimentos suficientes para que as
respostas sejam as mais assertivas possíveis. Sugerimos reunir a equipe e aplicar o
diagnóstico, abrindo espaço para discussões e a obtenção de uma visão homogênea da
área de TI sobre os itens avaliados. Após a aplicação do diagnóstico e a compilação dos
resultados, a atividade “realizar recomendações” aponta os pontos fortes, pontos fracos e
as recomendações de melhoria. Por fim, a apresentação dos resultados do diagnóstico às
partes interessadas visa demonstrar a relevância e justificar futuras decisões, mantendo o
patrocínio e o apoio da organização. Os templates da fase Diagnóstico são: instrumento
de diagnóstico; resultados do diagnóstico e recomendações.
Fase Estabelecimento: A fase Estabelecimento realiza a definição dos objetivos e o
planejamento da situação desejada (TO-BE), procurando responder às seguintes
perguntas: Onde desejamos chegar? Qual a central de serviços de TI que queremos ter?
Para responder a estas perguntas serão realizadas duas importantes atividades: a
identificação de oportunidades de melhoria e a seleção de objetivos. As oportunidades
de melhoria são identificadas com base nos resultados do diagnóstico, e a seleção de
objetivos através da escolha, no Toolbox, de processos que iremos implantar. A visão
resumida do Toolbox está detalhada na seção 4.4. O fluxo que representa a fase
Estabelecimento pode ser visualizado na Figura 4.
316
Figura 4: Fluxo da fase Estabelecimento do framework QoS-TI
O fluxo inicia com a análise das oportunidades de melhoria do serviço. Em

seguida, o Toolbox de processos é utilizado para a definição de objetivos, ou seja, a
escolha de quais dimensões pretende-se abordar e quais processos se quer implantar. A
seleção dos objetivos define a situação desejada (TO-BE) e os processos que serão
executados na fase Ação. Deve-se considerar a limitação de recursos, as dependências
existentes entre as atividades, fatores externos que podem intervir nas mudanças e as
prioridades da organização. Estratégias precisam ser desenvolvidas para preparar a
organização e a área de TI para a implantação da solução, e para que o serviço entre em
operação. As estratégias a serem definidas incluem fatores de ordem técnica e não
técnica, incluindo a cultura da organização, aspectos políticos, prováveis fontes de
resistência, limitação de recursos, excesso de atividades, dentre outras dificuldades. Por
último, um planejamento de ações deve ser desenvolvido, incluindo tarefas, pontos de
decisão, recursos, responsabilidades, métricas, mecanismos de controle de riscos e
outros elementos requeridos pela organização. Os templates da fase Estabelecimento
são: estratégias de implantação; e planejamento de ações.
Fase Ação: O propósito da fase Ação é apoiar a organização na implementação da
iniciativa que foi planejada nas fases anteriores. A fase Ação procura responder à
seguinte questão: Como chegaremos lá? Para isso, são executadas atividades de criação,
validação, teste, refinamento e implementação da solução (estratégias, ações planejadas
e processos selecionados). A Figura 5 apresenta o fluxo que representa a fase Ação.
Figura 5: Fluxo da fase Ação do framework QoS-TI
A equipe do projeto realiza a validação da solução criada na fase

Estabelecimento, podendo acrescentar o uso de ferramentas, técnicas e outros
conhecimentos e habilidades. Serão realizados os ajustes necessários, visando obter a
“melhor solução” para a entrada em operação. A solução precisa ser testada para
verificar se funciona conforme o planejado. Será realizado um teste, no qual é verificado
o funcionamento do sistema, dos processos, a coordenação da equipe, a interação com
317
os usuários, dentre outros. As falhas devem ser identificadas e corrigidas, refletindo o
conhecimento, experiência e as lições aprendidas. Várias iterações do processo de testar
e refinar podem ser necessárias para o alcance de uma solução satisfatória. Por fim, a
solução pode ser implementada na organização, e para isso será utilizada a abordagem
definida na estratégia da fase Estabelecimento. Nesta etapa, os processos do Toolbox
que foram escolhidos serão implementados. Os templates da fase Ação são: estratégias
de implantação (produzido na fase Estabelecimento); planejamento de Ações (produzido
na fase Estabelecimento); plano de testes; e requisição de mudança.
Fase Aprendizado: O propósito da fase Aprendizado é continuar a aprimorar a
implementação de mudanças. A experiência na utilização do framework QoS-TI é
revisada para verificar o que foi alcançado, se o esforço atingiu os objetivos definidos, e
como a organização pode implementar futuras mudanças de maneira mais efetiva e
eficiente. Os registros devem ser mantidos ao longo da aplicação do ciclo de vida do
framework, tendo em vista a oportunidade de aprendizado e melhoria do processo de
implantação. A fase procura responder às seguintes perguntas: Conseguimos chegar? O
que aprendemos? O fluxo que representa a fase Aprendizado, Figura 6, é apresentado a
seguir.
Figura 6: Fluxo da fase Aprendizado do framework QoS-TI
O fluxo inicia com a coleta e análise dos resultados obtidos durante todo o ciclo
de vida do framework. Em seguida, é feita a comparação dos resultados obtidos para
verificar o que foi alcançado com o esforço realizado. Faz-se o registro das lições
aprendidas durante todo ciclo de vida, com a finalidade de realizar aperfeiçoamentos
para experiências futuras. Recomendações para melhorias futuras são desenvolvidas e
documentadas com base nos resultados e nas lições aprendidas. Caso necessário, inicia-
se um novo ciclo de vida em resposta às recomendações de melhorias futuras. Os
templates da fase aprendizado são: registro de lições aprendidas; e recomendações de
ações futuras.
4.2. Toolbox de Processos

O objetivo do Toolbox é apoiar a implantação e melhoria de centrais de serviços de TI
durante a execução das fases Estabelecimento e Ação do ciclo de vida. Para isso, possui
uma abordagem prática, apresentando vários processos distribuídos em uma estrutura
composta por dimensões. O Toolbox foi elaborado com base nos seguintes conceitos:
estrutura de melhoria baseada nas dimensões do Extended Process Maturity
318
Framework-EPMF (Rudd, 2010); estrutura de processos que apoiam a implantação das
fases do ciclo de vida; compatibilidade com a abordagem iterativa e incremental
(Krutchen, 2003).
O principal motivador para o desenvolvimento do Toolbox de processos foi a
dificuldade de encontrar orientações práticas que auxiliem a implantação e melhoria de
centrais de serviços de TI. A sua aplicação foi detalhada nas fases Estabelecimento e
Ação do ciclo de vida, apresentadas na seção 4.1. O Toolbox é composto por dimensões
e processos, conforme pode ser observado na Tabela 2.
Tabela 2. Dimensões, processos e objetivos do Toolbox
Dimensões Processos Objetivos

Construir um plano de melhoria contínua, constituído por um conjunto de metas
VG04 – Elaborar um Plano de e ações estabelecidas a partir de resultados obtidos com o processo de
Melhoria autoavaliação do serviço de suporte de TI.
Aumentar a probabilidade de alcance dos objetivos da organização, reduzindo
Visão e VG03 – Gerenciar Riscos os riscos a níveis aceitáveis.
VG02 – Demonstrar o Valor do
Governança
Demonstrar o valor do serviço para a organização.
Serviço
VG01 – Garantir o Apoio da Alta Garantir o apoio dos integrantes da alta direção na implantação e manutenção
Administração da Central de Serviços de TI.
OE04 – Realizar Auditorias Estabelecer revisões ou auditorias internas para verificar a eficiência, eficácia e
Regulares o cumprimento das atividades de melhoria.
OE03 – Definir Indicadores para Definir indicadores de desempenho para medir os objetivos estabelecidos.
Orientação e Medir os Objetivos
Estratégia OE02 – Definir Arquitetura e Definir a arquitetura da Central de Serviços e os níveis de atendimento ao
Níveis de Suporte usuário.
OE01 – Estabelecer Objetivos e Estabelecer objetivos para a Central de Serviços de TI, com metas formalmente
Metas definidas.
Minimizar o impacto adverso de incidentes e problemas decorrentes de erros
PR04 – Gerenciar Problema conhecidos relacionados com a infraestrutura de TI e prevenir a reincidência
desses erros.
PR03 – Gerenciar Acordo de Nível Garantir que todos os serviços de suporte de TI sejam entregues dentro de metas
Processos de Serviço (ANS) atingíveis acordadas, fomentando medidas corretivas quando necessário.
Restaurar a operação normal do serviço o mais rápido possível e minimizar o
PR02 – Gerenciar Incidentes impacto adverso sobre as operações da organização.
Manter a satisfação do usuário através do processo de gerenciamento do ciclo
PR01 – Gerenciar Requisições de vida de todas as requisições de serviço realizadas.
PS04 – Monitorar e Comunicar o Monitorar e comunicar a execução e o desempenho do serviço às partes
Desempenho do Serviço interessadas para apoiar a tomada de decisão.
PS03 – Definir e Formalizar as Definir e descrever os papéis e responsabilidades dos profissionais da Central
Responsabilidades de Serviços de TI.
Pessoas
PS02 – Estabelecer um Programa Estabelecer um programa de treinamento para aperfeiçoar as habilidades e
de Treinamento competências da equipe da Central de Serviços.
Selecionar profissionais com habilidades e capacidades adequadas ao
PS01 – Recrutar Pessoal cumprimento das funções da Central de Serviços.
TC04 – Implantar o Permitir que o usuário busque soluções e orientações por conta própria, a fim de
Autoatendimento aumentar o acesso à informação e diminuir o tempo de resolução de problemas.
Permitir ao provedor de serviços ser mais eficiente, melhorar a qualidade do
TC03 – Estabelecer a Base de serviço e aumentar a satisfação do cliente por meio da redução da necessidade
Produtos, Conhecimento de redescobrir conhecimento.
Tecnologia e
Ferramentas TC02 – Criar e Manter um Banco Garantir que a informação precisa e confiável sobre os ativos de serviço esteja
de Dados de Gerenciamento de disponível quando necessária.
Configuração (CMDB)
TC01 – Analisar e Selecionar Analisar e selecionar tecnologias de apoio aos processos e à operação de
Tecnologias serviços.
319
Dimensões Processos Objetivos
CT04 – Estabelecer a Cultura de Disseminar premissas e práticas de melhoria contínua na Central de Serviços de
Melhoria Contínua TI.
Obter o entendimento da demanda exigida e garantir que a Central de Serviços
CT03 – Gerenciar Demandas tenha capacidade suficiente para atendê-la.
Cultura, Serviço
e Atitude CT02 – Avaliar a Satisfação do Avaliar o serviço prestado, conforme a percepção do usuário, permitindo a
Usuário identificação de possíveis falhas para que melhorias sejam realizadas.
CT01 – Gerenciar Recursos Melhorar os resultados da Central de Serviços de TI através do gerenciamento

Humanos do recurso humano.
OR04 – Gerenciar o Manter um relacionamento positivo com os clientes, em torno do atendimento
Relacionamento com o Cliente dos requisitos organizacionais.
OR03 – Identificar e Categorizar Identificar e categorizar os clientes de acordo com a criticidade dos serviços
Organização, oferecidos, a fim de orientar a priorização do atendimento.
Clientes
Comunicação e
Relacionamento OR02 – Elaborar o Catálogo de Criar e manter um Catálogo de Serviços com informações sobre todos os
Serviços serviços de TI em produção e aqueles disponíveis para implantação.
OR01 – Identificar e Gerenciar as Tem como objetivo identificar, qualificar e gerenciar as partes interessadas da
Partes Interessadas Central de Serviços de TI.
O Toolbox contém 28 processos1 distribuídos entre sete dimensões. Cada

processo possui: objetivo, responsável, entradas, tarefas, técnicas e ferramentas,
métricas e indicadores, saídas e referências. Eventualmente, podem ser apresentados
detalhamentos adicionais, como fluxos ou estratégias. Os processos do Toolbox
incorporam diversas práticas de gerenciamento de serviços de TI e gestão da qualidade,
as normas e modelos estão referenciadas em cada processo.
5. Avaliação do Framework QoS-TI

Esta seção descreve a avaliação do framework QoS-TI por especialistas dos Institutos
Federais. O procedimento de avaliação compreendeu as seguintes etapas: definição do
método de avaliação; teste piloto; execução da avaliação; análise e apresentação de
resultados.
O instrumento de avaliação foi a aplicação de um questionário através de um
survey, desenvolvido para obter a percepção dos especialistas em relação aos seguintes
aspectos do framework: clareza, foco na qualidade, utilidade, adaptabilidade, entrega de
resultado, adequação e abrangência, e flexibilidade. O questionário foi formado por dois
blocos, com dez itens no total: o bloco I capturou o perfil do respondente; o bloco II foi
composto por perguntas que medem o nível de concordância ou não em relação aos
aspectos do framework, através da escolha de uma das seguintes opções da escala de
Likert: discordo totalmente; discordo em parte; não concordo, nem discordo; concordo
em parte ou concordo totalmente. A opinião “não sei responder” foi disponibilizada
apenas para a questão três, pois exigia do respondente o conhecimento prévio sobre
normas e modelos de gerenciamento de serviços.
A Tabela 3 demonstra os aspectos avaliados e suas respectivas questões. Para a
criação das questões levamos em consideração algumas características de modelos de
gerenciamento de serviços de TI (foco na qualidade, entrega de resultados) e os
princípios do framework.
1
O conteúdo dos processos do Toolbox está disponível no seguinte endereço eletrônico:
https://sites.google.com/site/frameworkqosti/toolbox-de-processos/estrutura.
320
Tabela 3. Aspectos avaliados no framework e suas respectivas questões
Aspectos Questões
Q1 As atividades e os artefatos de cada fase do ciclo de vida estão claros e compreensíveis?
Clareza
Q2 A arquitetura do Toolbox, composta por dimensões e processos, está clara e compreensível?
Foco na O framework QoS-TI pode ser utilizado em conjunto com as melhores práticas de gerenciamento de
Q3
Qualidade serviços de TI (ITIL, ISO/IEC 20.000, CMMI for services, MR-MPS serviços, dentre outras)?
A estrutura apresentada pelo framework QoS-TI facilita a implantação ou a melhoria de uma Central
Utilidade Q4
de Serviços de TI?
O framework QoS-TI é adaptável, ou seja, pode ser utilizado para implantar uma central de serviços
Adaptabilidade Q5
de TI do “zero” ou implementar melhorias em uma já existente?
Entrega de O framework QoS-TI permite agregar valor ao cliente no decurso da realização do projeto, através
Q6
Resultado da execução das fases e dos processos?
O framework QoS-TI pode ser aplicado para melhorar a qualidade do serviço de suporte de TI na
Q7
Adequação e instituição onde trabalho?
Abrangência Recomendaria o framework QoS-TI para outras instituições que necessitam implantar uma Central
Q8
de Serviços de TI?
Utilizaria o framework QoS-TI como apoio ao processo de contratação, no caso de uma decisão
Flexibilidade Q9
estratégica pela terceirização do serviço de operação de uma central de serviços de TI?
O framework ficou disponível para análise dos especialistas no seguinte

endereço eletrônico: https://sites.google.com/site/frameworkqosti/.
Antes da aplicação definitiva da avaliação foi realizado um teste-piloto. O teste
foi concebido para permitir um processo gradual de aperfeiçoamento do questionário.
Pelo caráter experimental, o teste foi aplicado a uma amostra de oito profissionais com
experiência no suporte de TI. Foram avaliados os seguintes aspectos: orientações,
clareza das perguntas, o tempo necessário para conhecer o framework e responder o
questionário, estrutura e organização, diagramação e pertinência.
A estratégia adotada para a avaliação do framework foi o envio do convite para a
lista de e-mails do Fórum de TI dos IFs – FORTI, dos quais os diretores de TI fazem
parte. Além disso, a pesquisa foi divulgada à comunidade de profissionais de TI dos IFs
no grupo gsti-if@googlegroups.com. A participação dos especialistas envolveu as
seguintes etapas: acessar e conhecer o framework QoS-TI, responder o questionário. Foi
disponibilizado contato para que os especialistas pudessem esclarecer dúvidas sobre o
funcionamento do framework. Foram realizadas 51 avaliações, no período de 10 a 19 de
maio de 2017, por especialistas distribuídos em 19 Institutos Federais, o que representou
50% do total de IFs.
5.1. Resultados da Avaliação com Especialistas

Os especialistas são profissionais que trabalham nos Institutos Federais e possuem
experiência com o serviço de suporte de TI. Foi observado que 82% dos especialistas
possuem mais de três anos de experiência com o serviço de suporte de TI, 12% possuem
de um a três anos, e apenas 6% possuem até um ano de experiência.
Podemos observar na Figura 7, que a maioria dos especialistas concordou
totalmente sobre os aspectos do framework avaliados, o que correspondeu a 59% das
respostas. Um percentual significativo concordou em parte, representando 32% das
respostas, 7% das respostas relataram a opinião “não concordo, nem discordo” e apenas
1% das respostas assinalaram a opção “discordo em parte”, não tivemos nenhuma
resposta “discordo totalmente”. Diante dessa avaliação, entendemos que o framework
321
foi muito bem conceituado pelos especialistas. A seguir apresenta-se o detalhamento da
avaliação por questão.
A respeito do aspecto “clareza” das atividades e artefatos das fases do ciclo de
vida, 47% dos especialistas concordam totalmente, outros 47% concordam em parte, 4%
não concordam e nem discordam, e apenas 2% discordaram parcialmente, ver Figura 8.
Figura 7: Percentual de respostas por Figura 8: Resultados sobre a clareza das

Opinião atividades e artefatos
Quando se trata da clareza do Toolbox de processos o percentual de especialistas
que concordaram totalmente sobe para 49%, seguido de 37% que concordaram em
parte, ver Figura 9. Com relação ao “foco na qualidade”, podemos observar na Figura 10
que 64,70% dos especialistas concordaram totalmente sobre a possibilidade do
framework ser utilizado em conjunto com outras normas e modelos de qualidade, o que
evidencia também a característica de compatibilidade.
Figura 9: Resultados sobre a clareza do Figura 10: Resultados acerca do foco na

Toolbox qualidade
Sobre o aspecto “utilidade”, 65% dos especialistas acreditam que o framework

facilita a implantação ou melhoria de Centrais de Serviços, o que demonstra uma
relevante indicação dos benefícios do framework, ver Figura 11. Acerca do aspecto
“adaptabilidade”, predominou a opinião de que o framework pode ser utilizado para
implantar uma Central de Serviços do “zero” ou também para implementar melhorias
em uma Central já em operação, sendo que 59% dos especialistas concordam
totalmente, e 37% concordam em parte, ver Figura 12.
Figura 11: Resultados em relação à Figura 12: Resultados acerca da

utilidade adaptabilidade
322
Podemos observar na Figura 13 que os resultados da avaliação reforçam um dos
princípios do framework a “entrega de resultado”, pois 65% dos especialistas
concordam totalmente sobre a agregação de valor ao cliente no decurso da realização do
projeto, e 31% concordam em parte. O aspecto “adequação e abrangência” foi o melhor
avaliado entre os especialistas, 69% concordaram totalmente sobre a possibilidade de o
framework ser aplicado para melhorar a qualidade do serviço de suporte de TI na
instituição onde trabalha, ver Figura 14.
Figura 13: Resultados em relação à Figura 14: Resultados sobre a

entrega de resultados adequação
Ainda sobre o aspecto adequação e abrangência, 69% dos respondentes
afirmaram que concordam totalmente sobre a recomendação do framework para outras
instituições que necessitam implantar uma Central de Serviços, e 25% concordam em
parte, ver Figura 15. Sobre a utilização do framework como apoio ao processo de
contratação, no caso de uma decisão estratégica pela terceirização, 45% dos
especialistas opinaram concordo totalmente e 39% concordo em parte, ver Figura 16.
Destacamos o percentual de opiniões “não concordo, nem discordo”, o que é
justificável, pois o framework oferece apoio ao processo de contratação, todavia tem o
foco no processo de implantação e melhoria.
Figura 15: Resultados acerca da Figura 16: Resultados sobre a utilização

abrangência do framework no caso de terceirização
Em relação aos pontos fortes do framework, os especialistas relataram: ciclo de
vida bem definido; organização e clareza; incorpora conceitos de modelos de referência
amplamente utilizados no mercado; adaptável e flexível; foco prático; simplicidade;
facilidade de leitura e compreensão; possibilita ao gestor definir prioridades; Toolbox de
processos com abordagem prática; foco na qualidade e satisfação dos usuários; conceito
de melhoria contínua; adequado à realidade dos IFs; integração com outros modelos;
disponibiliza templates; possibilidade real de utilização; e apresenta uma proposta que
pode gerar impactos positivos e significativos para a estratégia organizacional.
Os especialistas ainda fizeram algumas observações, dentre as quais destacamos:
desenvolver uma versão resumida; incluir o processo gerenciar mudanças; necessidade
323
de detalhamento dos papéis e responsabilidades; criação de um mapa mental para
representar todo framework; a criação de vídeo aulas sobre a utilização do framework.
Concluiu-se que os resultados foram satisfatórios e que a avaliação do framework QoS-
TI, por especialistas, responde à questão de pesquisa definida na introdução desse
trabalho.
Após a realização da revisão da literatura, onde foram levantadas as melhores práticas
para serviços de TI, apresentamos neste trabalho o framework QoS-TI como proposta
para implantação e/ou melhoria de uma central de serviços de TI. Conforme avaliado
por especialistas, o framework mostrou-se em conformidade com seus propósitos,
dentre os quais destacamos o foco prático em “como fazer” e a adaptabilidade. Todos os
aspectos avaliados (clareza, foco na qualidade, utilidade, adaptabilidade, entrega de
resultado, adequação e abrangência, flexibilidade) receberam opiniões extremamente
positivas. Isso nos leva a compreender que a proposta atingiu o seu objetivo,
desenvolver o framework, e foi bem aceita na comunidade de especialistas.
Uma limitação que podemos destacar é que os especialistas não tiveram a
oportunidade de utilizar o framework na prática, o que poderia resultar em uma
avaliação mais apurada. Espera-se que o uso do framework nos IFs proporcione
impactos positivos na satisfação do usuário do serviço. Como trabalho futuro, propõe-se
a análise de viabilidade do framework em organizações privadas, e o seu
aperfeiçoamento através de automatização do processo de implantação e da agregação
de métodos para medir a maturidade da Central de Serviços.
Observamos que devido às características das Universidades Federais, que têm
uma estrutura parecida com a dos IFs, provavelmente o framework possa ser utilizado
com sucesso nestas instituições. Essa suposição é reforçada pelas características de
adaptabilidade e flexibilidade do framework, todavia precisam ser realizados
experimentos para comprová-la.
Referências
DE ARAUJO, L. L.; MOCNY, E. C.; ROCHA, A. R.; GONÇALVES, T.; SANTOS, G.
(2014) “Experiência de Implantação do MR-MPS-SV no Service Desk da ECO
Sistemas”, VIII Simpósio Brasileiro de Qualidade de Software, Blumenau, Brasil.
ABNT. NBR ISO 20000-1:2011. Tecnologia da Informação - Gestão de Serviços. Parte
1: Requisitos do sistema de gestão de serviços. Rio de Janeiro, 2011.
ABNT. NBR ISO 9001:2015. Sistemas de gestão da qualidade: Requisitos. Rio de
Janeiro, 2015.
BRASIL. 2015. Ministério da Educação. Expansão da Educação Superior e Profissional
Tecnológica. Disponível em URL: http://redefederal.mec.gov.br/expansao-da-rede-
federal Acesso em: 27 de julho de 2015.
BRIGANO,G.U.; BARROS,R.M.(2010) “A Implantação de um Service Desk: Um
Estudo de Caso Aplicando Conceitos do ITIL e do PMBOK”, IV Workshop Anual
do MPS, Campinas, Brasil.
324
CMMI Product Team. Cmmi for services, version 1.3 (cmu/sei-2010-tr-034). Technical
report, Software Engineering Institute, Carnegie Mellon University, 2010.
FEIGENBAUM, Armand Vallin. Total quality control: engineering and management,
the technical and managerial field for improving product quality, including its
reliability, and for reducing operating cost and losses. New York. McGraw-Hill.
1961.
FERNANDES, Aguinaldo Aragon; ABREU, Vladimir Ferraz de. Implantando a
governança de TI: da estratégia à gestão dos processos e serviços. Rio de Janeiro:
Brasport, 2014.
ISHIKAWA, Kaoru. Controle de Qualidade Total: à maneira japonesa. Rio de Janeiro:
Campus, 1993.
JÄNTTI, Marko; CATER-STEEL, Aileen; SHRESTHA, Anup. Towards an improved
IT service desk system and processes: a case study. International Journal on
Advances in Systems and Measurements, v. 5, n. 3 & 4, p. 203-215, 2012.
JURAN, Joseph M. A qualidade desde o projeto: Novos passos para o planejamento da
qualidade em produtos e serviços, São Paulo: Pioneira, 1992. 2ª Edição.
KELLER, Alexander; MIDBOE, Tyson. Implementing a service desk: A practitioner's
perspective. In: Network Operations and Management Symposium (NOMS), 2010
IEEE. p. 685-696.
KRUCHTEN, Philippe. Introdução ao RUP: Rational Unified Process. Rio de Janeiro:
Ciência Moderna, 2003.
MCFEELEY, B. IDEAL: A User’s Guide for Software Process Improvement. Software
Engineering Institute Handbook - sei.cmu.edu. Carnegie Mellon University
Pittsburgh, Pennsylvania, 1996.
OGC. Office of Government Commerce. ITIL – The Official Introduction to the ITIL
Service Lifecycle. London: TSO (The Stationary Office), 2007.
PMBOK, Guia. Um Guia do Conhecimento em Gerenciamento de Projetos. 5. ed.
Project Management Institute, 2013.
RODRIGUES,G.R.; SOUZA,A. S., OLIVEIRA,L.O.(2013) “Implementando o Nível G
do MR-MPS-SV com base no conceito de Central de Serviços”, IV Workshop Anual
do MPS, Campinas, Brasil.
RUDD, Collin. ITIL V3 Planning to Implement Service Management. TSO (The
Stationary Office), 2010.
SOFTEX. Associação para Promoção da Excelência do Software Brasileiro. MPS.BR –
Guia Geral MPS de Serviços: 2015. Disponível em:
<http://www.softex.br/mpsbr/guias/>. Acesso em: 21/12/2016.
TANG, X.; TODO, Y. (2013). A Study of Service Desk Setup in Implementing IT
Service Management in Enterprises. Technology and Investment, Vol.4 No.3.
Disponível em: http://www.scirp.org/journal/PaperInformation.aspx?PaperID=35498
325
MSECO-CERT: Uma Abordagem Baseada em Processo
para Apoiar a Certificação de Apps em Ecossistema de
Software Móvel
Awdren de Lima Fontão1, Arilo Claudio Dias-Neto1, Rodrigo Pereira dos Santos2
1
Programa de Pós-Graduação em Informática (PPGI)
Instituto de Computação (ICOMP) – Universidade Federal do Amazonas (UFAM)
Caixa Postal 6.200 – 69.077-000 – Manaus – AM – Brasil
{awdren,arilo}@icomp.ufam.edu.br
2
DIA – Universidade Federal do Estado do Rio de Janeiro (UNIRIO)
Caixa Postal 296 – 22.290-240 – Rio de Janeiro – RJ – Brasil
rps@uniriotec.br
Abstract. In a Mobile Software Ecosystem (MSECO), software organizations
have restructured their processes to developers aiming to achieve goals, such
as increasing the number of mobile applications (apps). However, the Quality
Barrier provided by the Apps Store does not set criteria that can ensure that
apps certified from them achieve the goals. It is necessary to consider the
quality of support offered to the developers through the processes, since
working in the processes (certification) can achieve the expected performance
for the apps. In this work, a process-based approach to app certification
(MSECO-CERT) was defined. The use of MSECO-CERT for app development
generated a growth coefficient of downloads 363% higher and average user
ratings 28% higher compared to an ad hoc approach.
Resumo. Em um Ecossistema de Software Móvel (MSECO), as organizações
de software passaram a reestruturar seus processos para desenvolvedores
visando atingir metas, como o aumento do número de aplicações móveis
(apps). No entanto, a “barreira” de qualidade provida pela Loja de Apps, não
define critérios que garantem que as apps certificadas a partir deles atinjam
as metas. É necessário considerar a qualidade de suporte oferecido aos
desenvolvedores por meio dos processos (certificação), para atingir o
desempenho esperado para as apps. Neste trabalho, foi definida uma
abordagem baseada em processos para certificação de apps (MSECO-CERT).
O uso da MSECO-CERT para desenvolvimento de apps gerou um coeficiente
de crescimento de downloads 363% maior e média de avaliações dos usuários
28% maior em comparação a uma abordagem ad hoc.
1. Introdução
Um Ecossistema de Software Móvel (MSECO) consiste de um sistema de evolução
cooperativa de aplicações móveis (apps), desenvolvedores e usuários que formam
complexos relacionamentos preenchendo nichos, competindo e cooperando, de uma
forma similar a ecossistemas biológicos [Lin e Ye, 2009]. Um MSECO é formado por
elementos que possuem responsabilidades distintas e que precisam se relacionar de
forma harmônica de forma a manter um equilíbrio. Dentre esses elementos, além da
326
App, desenvolvedores e usuários, citados anteriormente, podem ser incluídos: a
Organização Central, que é responsável pela orquestração do MSECO; os Evangelistas,
que são especialistas internos da organização alocados para dar suporte aos
desenvolvedores; e, a Loja de Apps, que consiste em um repositório de apps e que
possui um papel fundamental para o sucesso do MSECO, definindo políticas de
aceitação de apps que irão ser disponibilizadas aos usuários. O desempenho destes
elementos precisa ser acompanhado com o objetivo de identificar e prever áreas de
melhoria, ou seja, habilidade em suportar e permanecer variável e produtivo durante o
tempo. A análise da habilidade se refere ao conceito de “saúde” definido por Manikas e
Hansen (2013a).
De forma geral, o impacto de uma app no ecossistema só pode ser medido após
a sua publicação em uma loja. Não se pode garantir que apps aprovadas pelos critérios
de uma loja resultarão em um número alto de downloads e em avaliações positivas pelos
usuários. Desta forma, a submissão de uma app baseada somente em critérios da loja,
com foco somente na qualidade do produto, pode causar a “doença” em elementos do
MSECO. Isto desencadeia sintomas como a desmotivação dos desenvolvedores para
evoluir uma app e a adaptação constante de estratégias pela Organização Central para
manter a comunidade de usuários e de desenvolvedores. Então, a prevenção para não
gerar impacto negativo na “saúde” do MSECO não deve ser somente focada na
qualidade do produto, mas deve levar em consideração a qualidade dos processos
executados pelo desenvolvedor (criação e desenvolvimento da app), pela Organização
Central (orquestração do ecossistema) e pelo evangelista (suporte e elo entre a
organização e o desenvolvedor), uma vez que a “saúde” do MSECO é diretamente
influenciada pela saúde dos elementos que o compõe. O problema tratado como foco
neste trabalho é o impacto dos elementos para certificar uma app a partir da qualidade
dos processos que eles são responsáveis.
Neste trabalho, o conceito de certificação, baseado em Babiy et al. (2010), é
interpretado como atestar, por meio da utilização dos processos e do conjunto de
práticas/recomendações, que haverá um impacto positivo em indicadores de saúde como
a quantidade de downloads e de média de avaliação das apps. A saúde de cada
componente do MSECO tem uma relação com práticas de garantia de qualidade e a
organização central pode influenciar a garantia de qualidade por meio do
estabelecimento de regras e processos a serem seguidos [Axelsson e Skoglund 2016].
Assim, o objetivo deste trabalho é definir e avaliar uma abordagem de
certificação de qualidade de apps no contexto de MSECO por meio de processos,
recomendações, práticas e indicadores de saúde na fase de pré-publicação para uma loja
de apps. Essa abordagem envolve os elementos que compõem o MSECO
(desenvolvedor, evangelista, Organização Central, aplicação móvel e loja) a fim de
impactar positivamente a saúde do MSECO. Como contribuições para a comunidade
científica e para a indústria, apresenta-se os seguintes resultados: Definição da
abordagem MSECO-CERT, incluindo os processos de orquestração, desenvolvimento e
suporte; Mapeamento Sistemático da Literatura sobre MSECO, incluindo oportunidades
de pesquisa; Pacote de estudos experimentais no contexto de ecossistemas de software.
Este artigo é organizado como segue. A próxima seção apresenta a metodologia
de pesquisa adotada para a concepção e avaliação da abordagem proposta nesta
dissertação de mestrado. A Seção 3 descreve a abordagem MSECO-CERT e seus
327
componentes. Na Seção 4 são apresentados os estudos experimentais para a avaliação
da abordagem e os resultados obtidos. A Seção 5 apresenta as conclusões incluindo
limitações e trabalhos futuros. E, por fim, a seção 6 discorre sobre publicações
científicas geradas a partir desta dissertação.
2. Metodologia de pesquisa
A metodologia de pesquisa, baseada em Mafra et al. (2006), utilizada neste trabalho é
composta por duas fases: concepção, onde o foco é a definição e construção da
abordagem MSECO-CERT (Mobile Software Ecosystem App Certification), e;
avaliação, focada em avaliar a viabilidade e a utilização da abordagem. Na Figura 1 são
apresentadas as etapas dentro de cada fase. Nesta seção, são descritos os estudos que
estão inseridos na fase de concepção. Na Seção 4, os estudos da fase de avaliação são
apresentados.
Figura 1. Metodologia de pesquisa para definição da MSECO-CERT

Na fase de concepção os seguintes estudos foram realizados.
Revisão da Literatura: para esta atividade, foi realizado um mapeamento
sistemático com o objetivo de analisar o cenário de MSECO com o propósito de
caracterizar em relação aos benefícios, desafios, definições, processos, metodologias,
processos e abordagens do ponto de vista do pesquisador no contexto de pesquisas
acadêmicas em engenharia de software.
Este mapeamento sistemático, a partir da análise dos estudos selecionados, apontou a
necessidade por abordagens para apoiar atividades em MSECO. Os estudos
selecionados também foram analisados para extrair recomendações e práticas que
pudessem ser aplicados às atividades do processo definido nesta dissertação.
Definição dos Processos em MSECO: definição inicial dos processos que
estruturam as atividades dentro de um MSECO com o objetivo de entender as
atividades, elementos e artefatos envolvidos quando o cenário de desenvolvimento da
aplicação é um ecossistema. As atividades são compostas de:
328
o Definição de recomendações para cada atividade, como forma de suportar a
execução da atividade. Essas recomendações fazem parte da composição de
uma atividade em cada processo;
o Definição de práticas para cada atividade, com o objetivo de impactar
positivamente na saúde do MSECO. Essas práticas estão associadas à cada
atividade dentro dos processos
Esta etapa permitiu a definição inicial de três processos: MSECO-ORQ (processo de
orquestração), MSECO-SUP (processo de suporte) e MSECO-DEV (processo de
desenvolvimento). A notação utilizada para a modelagem dos processos foi baseada na
notação proposta por Villela et al. (2004).
Revisão por Pares dos Processos: realizada com especialistas (Organização
Central, evangelistas e desenvolvedores) para avaliar se os processos (orquestração,
suporte e construção) especificados neste trabalho estão adequados para atender às
necessidades de orquestração, desenvolvimento de aplicações móveis e evangelismo, do
ponto de vista de profissionais com experiência nas áreas de conhecimento dos
processos.
A revisão por pares auxiliou no levantamento de sugestões para a evolução dos
processos que compõem a MSECO-CERT. A maioria das sugestões (que foram
totalmente ou parcialmente aceitas) se concentrou em: descrição de atividades (11
sugestões – 28,95%), artefatos consumidos e produzidos por atividades (11 sugestões –
28,95%) e papéis participantes em atividades (8 sugestões – 21,05%). Dentro dos perfis
dos revisores foi possível perceber ainda a participação deles em mais de um MSECO,
logo a revisão pode partir da experiência de contribuições para MSECO da Google,
Microsoft, Apple, Nokia e Samsung.
Pesquisas de Opinião: baseando-se no relatório técnico publicado em
Travassos et al. (2002), pesquisas de opinião são estudos para analisar as atividades,
práticas e recomendações que compõem os processos de construção e de suporte. Nesta
atividade, foram realizadas as seguintes pesquisas de opinião:
o Com evangelistas para analisar práticas e recomendações que compõem o
processo de suporte com o propósito de caracterizar com respeito à
aplicabilidade do ponto de vista dos evangelistas no contexto de atividades
de engajamento e treinamento em MSECO;
Nenhuma prática foi removida, 7 novas práticas foram adicionadas e práticas e
recomendações associadas às atividades de evangelismo em MSECO foram ajustadas,
consolidando um processo de suporte com 43 práticas e 9 recomendações.
o Com desenvolvedores experientes para analisar as recomendações e práticas

que compõem o processo de construção com o propósito de caracterizar
com respeito à utilidade do ponto de vista de desenvolvedores experientes
no contexto de atividades de desenvolvimento em MSECO;
o Com desenvolvedores novatos para analisar um subconjunto de práticas e
atividades que compõem o processo de construção com o propósito de
caracterizar com respeito a utilidade e aplicabilidade do ponto de vista de
desenvolvedores novatos no contexto de atividades de desenvolvimento de
aplicações móveis em MSECO.
329
Do ponto de vista dos desenvolvedores experientes 4 práticas precisaram de ajustes que
foram realizados. Além disso, eles indicaram 3 novas práticas que envolvem uso de
bibliotecas de terceiros, experiência do usuário e análise de concorrentes. Os
desenvolvedores novatos indicaram a necessidade de ajuste na sequência das atividades
e que algumas práticas poderiam ser antecipadas.
Nesta seção foram descritos os estudos que ajudaram na concepção da MSECO-
CERT. Conforme descrito acima, quatro estudos foram realizados na fase de concepção:
mapeamento sistemático da literatura, revisão por pares, pesquisa de opinião com
evangelistas, pesquisa de opinião com desenvolvedores (experientes e novatos). Esses
estudos permitiram ajustes nas atividades (incluindo descrição, artefatos e critérios de
entrada e saída), nas práticas e nas recomendações. Além disso, esses estudos
permitiram adequar a abordagem ao cotidiano de evangelistas e desenvolvedores de
aplicações móveis. A próxima seção apresenta a MSECO-CERT na versão após as fases
de concepção e avaliação.
3. Abordagem MSECO-CERT
A abordagem MSECO-CERT (Figura 1) é composta por três processos MSECO-ORQ
(orquestração), MSECO-SUP (suporte) e MSECO-DEV (desenvolvimento), a descrição
completa dos processos está disponível no Capítulo 3 da dissertação.
Figura 2. Relação entre processos (Esq.) e estrutura da MSECO-CERT (Dir.)

Como mostrado na Figura 1, cada um dos processos é composto por atividades,
papéis o que envolve um fluxo de trabalho utiliza e produz artefatos. Para cada
atividade, foi associada uma recomendação, orientação para executá-la. Para cada
recomendação, práticas, que representam exercícios para atingir resultados concretos
nas metas organizacionais, foram associadas. As práticas só estão associadas às
atividades realizadas antes da submissão de uma app à loja, pois é quando o evangelista
pode intervir. A MSECO-CERT é composta como segue.
MSECO-ORQ: surge da interação entre a organização central e o evangelista, o
objetivo deste processo é preparar, gerenciar e coordenar alguns elementos
(desenvolvedor, evangelista e a app) [Jansen et al., 2009] e alguns de seus
relacionamentos. Além disso, visa fornecer diretrizes e guias necessários com o objetivo
de manter os indicadores de saúde de MSECO: robustez, produtividade e criação de
nicho. Possui nove atividades, nove artefatos, nove recomendações, nenhuma prática
(uma vez que não tem como gerar intervenção na orquestração a partir dos papéis de
evangelista e desenvolvedor).
330
Na Figura 2 e Tabela 1 é apresentado um exemplo de atividade que compõe o
MSECO-ORQ, especificamente a atividade 2: Disponibilizar os Guias de Interface. Os
documentos gerados ao final deste processo formam a base do MSECO, que compõem,
ao final do processo, o artefato Diretrizes do MSECO, que servirá para outros processos
que compõem esta abordagem. Esses documentos são: Especificação da Plataforma,
Guias de Design e Interface, Guias e Ferramentas de Marketing, Ferramentas de
Desenvolvimento, Central do Desenvolvedor, Loja de Aplicações, Critérios da Loja.
Figura 2. MSECO-ORQ: Processo de Orquestração
Tabela 1. MSECO-ORQ: Atividade 2

Atividade: 2 Disponibilizar Guias de Design e Interface de Usuário da Plataforma
A interface de usuário de uma plataforma é sua identidade. É importante divulgar guias
que ajudem os desenvolvedores a criar e desenvolver soluções que respeitem os padrões de
Descrição: design e interface da plataforma do MSECO. Essa atividade tem como objetivo
disponibilizar a base necessária para manter a boa interação com o usuário e o padrão da
plataforma do MSECO.
Critérios de
Ter-se a Especificação da Plataforma pronta ou atualizada.
Entrada:
Critérios de Saída: Documentos com especificação de interface e interação da plataforma criados e aprovados.
Responsável: Organização Central
Participantes: Equipe de Design e Equipe de UX (Experiência do Usuário) da Organização.
Artefatos
Especificação da Plataforma.
Requeridos:
Artefatos
Guias de Design e Interface de Usuário, e Aplicações Móveis de Referência.
Produzidos:
Deve-se levar em consideração as limitações e potencialidades da plataforma na execução
Recomendação:
desta atividade.
MSECO-SUP: o objetivo deste processo é prover o relacionamento entre a

organização central com os desenvolvedores. Para isso, o MSECO dispõe de um
elemento responsável por esta ligação: o evangelista. Contém nove atividades e
331
recomendações, seis artefatos, quarenta e quatro práticas. Na Figura 3 e Tabela 2 é
apresentado um exemplo de atividade deste processo.
Figura 3. MSECO-SUP: Processo de Suporte

As atividades visam estabelecer um procedimento para a execução do trabalho
dos evangelistas dentro dos padrões da organização, por meio do artefato Diretrizes do
MSECO. Os documentos gerados ao final deste processo formam a base de divulgação
do MSECO para os desenvolvedores externos e estabelecem procedimentos de
relacionamento com estes desenvolvedores.
Esta atividade visa ajudar na divulgação dos artefatos gerados ainda no processo
de orquestração, fazendo com que esses artefatos sejam facilmente acessados e
entendidos pelos desenvolvedores internos e os externos. A marcação diferenciada em
algumas atividades indica que pode-se intervir nas atividades com o objetivo de gerar
algum impacto na saúde do MSECO. Abaixo apresentamos um exemplo de atividade
que compõe o MSECO-SUP, especificamente a atividade 3: Gravar Vídeos baseados no
Material. A descrição de todo o processo está disponível no Capítulo 3, Seção 3.3.2 da
dissertação.
Tabela 2. MSECO-SUP: Atividade 3
Atividade: 3 Gravar Vídeos baseados no Material
Esta atividade tem como objetivo explicar conceitos, dicas, implementação e utilização de
Descrição:
ferramentas de uma forma mais interativa.
Deve-se definir um roteiro para a gravação do vídeo, pode ser ainda vídeos gerados em
Critérios de Entrada:
cima de material em Wiki ou blogs.
Critérios de Saída: O vídeo deve conter informações práticas e que possam ser replicadas.
Responsável: Evangelista.
Equipe de Marketing de Desenvolvedores. Algum outro desenvolvedor (interno ou
Participantes:
externo) pode participar.
Artefatos Requeridos: Diretrizes do MSECO, Material Técnico.
Artefatos Produzidos: Material Técnico.
Os vídeos devem fornecer experiência prática de algum conteúdo do MSECO. Algo que
Recomendação: possa ser seguido ou uma dica. É importante que no vídeo sejam ainda indicados links
para postagens e documentos referentes ou similares ao conteúdo do vídeo.
Como impactar na Produzir vídeos detalhados sobre código desenvolvido na Atividade 1 e sobre as
certificação de P19-S postagens feitas na Atividade 2 para guiar o desenvolvedor durante processo de
aplicações: desenvolvimento.
332
MSECO-DEV: o objetivo deste processo é que o desenvolvedor planeje e
construa uma app que será adicionada à loja de apps. Para isso, o desenvolvedor poderá
utilizar artefatos gerados tanto no MSECO-ORQ como no MSECO-SUP. Dessa forma,
ele pode contribuir com a produtividade e a criação de nicho do MSECO. Contém oito
atividades e recomendações, sete artefatos, dezesseis práticas.
Figura 3. MSECO-DEV: Processo de Desenvolvimento

Na Figura 3 e Tabela 3 é apresentado um exemplo de atividade que compõe o
MSECO-DEV, especificamente a atividade 5: Analisar o Pacote de Marketing. A
descrição de todo o processo está disponível no Capítulo 3, Seção 3.3.2 da dissertação.
Tabela 3. MSECO-DEV: Atividade 5
Atividade: 5 Analisar o Pacote de Marketing
Analisar o pacote de marketing preparado juntamente com o binário final da aplicação e
Descrição: guias de marketing do MSECO. Visa, assim, validar se houve alguma mudança na
aplicação durante a execução das Atividades 1.3 e 1.4.
Critérios de
A aplicação deve estar pronta e analisada sobre os critérios da loja.
Entrada:
Critérios de Saída: Pacote de Marketing da Aplicação consolidado.
Responsável: Desenvolvedor.
Participantes: Evangelista.
Artefatos
Material de Marketing da Aplicação, Material de Suporte e Binário da Aplicação móvel.
Requeridos:
Artefatos Pacote de Marketing da Aplicação.
Produzidos:
Nesta atividade, as imagens das telas da aplicação podem ser adicionadas ao pacote de
Recomendação:
marketing. Planejar estratégias de marketing.
Como impactar a
Utilizar um checklist para assegurar a completude do material de marketing
certificação de P16-C
gerado e sua adequação com os requisitos de marketing da loja.
aplicações:
Neste processo, as atividades estão relacionadas a prover informações e permitir

o desenvolvimento de uma aplicação móvel. Durante a execução das atividades, o
desenvolvedor pode contar ainda com a ajuda do evangelista.
Um exemplo de utilização da MSECO-CERT envolve o treinamento conduzido
por um evangelista que faz uso do MSECO-SUP para preparar códigos de exemplo,
realizar postagens, gravar vídeos, consolidar material de suporte, preparar ação (evento
ou treinamento), executar ação, analisar os resultados da ação, acompanhar os
333
participantes e atualizar relatórios de resultados. Os documentos gerados ao final
formam a base de divulgação do MSECO e fornecem procedimentos de relacionamento
com os desenvolvedores.
Os desenvolvedores utilizam o MSECO-DEV para definir o escopo da app,
desenvolve-la, preparar material de divulgação, analisar a app (critérios de qualidade da
loja), analisar pacote de marketing, submeter a app, acompanhar status de aprovação e
monitorar relatórios. O artefato gerado ao final desse processo deve ser um arquivo
publicável empacotado, usando o padrão definido pelo MSECO e que deve ser
suportado pela sua plataforma. Este artefato poderá ser embarcado no dispositivo de um
usuário, pois estará disponível na loja de apps.
4. Experimentos e Resultados
A abordagem, baseada em Shull et al. (2001), foi avaliada a partir de dois aspectos : 1)
Eficiência da abordagem (Estudo de viabilidade) – o propósito foi responder à
seguinte questão: “A utilização da MSECO-CERT para certificar apps desenvolvidas no
contexto de MSECO é viável analisando a sua eficiência em relação à quantidade de
downloads e à avaliação das apps desenvolvidas?”; 2) Adequação em um cenário
real (Estudo de observação) – a seguinte questão foi investigada: “A MSECO-CERT é
adequada no contexto real para o evangelismo e desenvolvimento de apps?”.
Tendo em vista que uma modificação na orquestração de um MSECO não é um
processo que pode ser executado rapidamente e está associado à estratégia da
organização central, não foi avaliado o uso do processo MSECO-ORQ nos
experimentos, pois o fluxo de atividades do processo permanece o mesmo em relação
aos três principais ecossistemas e não se modifica com frequência. Nos experimentos,
focou-se na avaliação dos processos MSECO-DEV e MSECO-SUP.
4.1. Estudo de viabilidade – Eficiência da abordagem
O objetivo é esquematizado a partir do paradigma GQM [Basili et al., 1994], como
segue: Analisar a aplicação da abordagem MSECO-CERT com o propósito de
caracterizá-la em relação à eficiência do ponto de vista dos pesquisadores no contexto
de engajamento e treinamento de desenvolvedores de aplicações móveis e evangelistas
no cumprimento de metas organizacionais em MSECO. Como forma de atingir esse
objetivo foram definidas as seguintes questões e métricas:
Q1. Qual é a eficiência da abordagem MSECO-CERT em relação a uma abordagem Ad
hoc no que diz respeito à quantidade de downloads de aplicações móveis?
Métrica: Quantidade de downloads de aplicações móveis desenvolvidas pelos
participantes;
Q2. Qual é a eficiência da abordagem MSECO-CERT em relação a uma abordagem Ad
hoc no que diz respeito à avaliação de aplicações móveis geradas?
Métrica: Média de avaliação de aplicações móveis desenvolvidas pelos
participantes.
Com os resultados obtidos por meio da execução do estudo de viabilidade foi
possível caracterizar a MSECO-CERT em relação a uma abordagem Ad hoc que foi
aplicada por não ter sido identificado na literatura outra abordagem similar à MSECO-
CERT. Este estudo envolveu dois evangelistas oficiais do MSECO gerenciado pela
334
Microsoft para a plataforma Windows Phone. Trinta desenvolvedores (divididos em dois
grupos com quinze participantes cada) foram provenientes dos cursos de Engenharia de
Software e Sistemas de Informação do Instituto de Ciências Exatas e Tecnologia da
UFAM. Apesar de o cenário envolver uma universidade, este é o cenário real, pois
organizações que treinam desenvolvedores buscam universidades para oferecer
treinamentos oficiais.
O estudo consistiu na execução do treinamento e acompanhamento dos
desenvolvedores. Para a execução do treinamento a plataforma utilizada foi a
Windows Phone 7.5, com o ambiente Visual Studio 2012. Desta forma, com a Turma 1
foi aplicada a abordagem MSECO-CERT, o evangelista utilizou o MSECO-SUP e os
desenvolvedores utilizaram o MSECO-DEV. Enquanto que com a Turma 2 a
abordagem Ad hoc foi utilizada, tanto para o evangelismo quanto o desenvolvimento. O
estudo em um ambiente acadêmico, está dentro do contexto real de uma atividade de
evangelismo e desenvolvimento em um MSECO, este cenário é o utilizado pelas
organizações em MSECO, o que caracteriza um ambiente real, com a mesma
infraestrutura, mesmas ferramentas e um evangelista para cada turma.
A mesma ementa de treinamento foi utilizada para as duas turmas, considerando
um curso básico: a) conceitos de desenvolvimento de aplicações móveis; b) ferramentas
de desenvolvimento; c) padrões de desenvolvimento; d) interface de usuário; e) classes,
métodos e comportamento da aplicação móvel; f) depuração de código; g)
empacotamento de aplicação móvel; h) publicação de aplicações móveis. E as duas
turmas tinham como meta o desenvolvimento e a publicação da aplicação móvel. A
carga horária de treinamento para as duas turmas foi de 18 horas. Após a execução do
treinamento, onde os desenvolvedores iniciaram a construção das suas aplicações
móveis, os desenvolvedores responderam ao Pós-Questionário para entender a mudança
em atitudes gerais e a comparação entre atitudes específicas de cada turma. Após isto,
os evangelistas iniciaram uma fase de acompanhamento dos desenvolvedores, durante
duas semanas após o treinamento. Para isto, dois grupos no WhatsApp e Facebook
foram criados para a Turma 1 e Turma 2. Os evangelistas ainda realizaram suporte por
e-mail. O acompanhamento foi realizado com o objetivo de concluir o desenvolvimento
de aplicações móveis e submete-las a loja de aplicações móveis
Os dados de quantidade de downloads foram coletados diretamente da Central
do Desenvolvedor1 durante um período de 30 a partir da publicação de cada aplicação
móvel. Este procedimento foi realizado para as duas turmas. Como forma de realizar
uma comparação entre as duas turmas, calculou-se a média diária de downloads das
aplicações móveis. Como esses valores foi gerada por dia a média acumulada, estes
dados são apresentados na Tabela 4. A partir dos resultados obtidos dos downloads, foi
realizada uma comparação entre as funções que descrevem o crescimento do número de
downloads do conjunto de aplicações de cada turma, onde f(x) = 8,809x-3,8138 (Turma
1) e g(x) = 1,9591x-1,2322 (Turma 2). Uma vez que uma função afim pode ser descrita
como ℎ 𝑥 = 𝑥 + , onde é o coeficiente de crescimento da reta, podemos observar
que o coeficiente de crescimento da função da turma 1 (8,80) é 363% maior que o da
turma 2 (1,95). Isto aponta uma diferença entre o indicador de downloads, no qual a
turma 1 obteve uma média acumulada maior.
1
https://developer.microsoft.com/pt-br/dashboard/apps/overview
335
Tabela 4. Média acumulada por dia de downloads
Turma Turma Turma
Dia Dia Dia
1 2 1 2 1 2
1° 4 2 11° 93 20 21° 181 40
2° 11 5 12° 103 21 22° 188 42
3° 18 6 13° 113 22 23° 196 43
4° 28 8 14° 122 24 24° 207 45
5° 38 9 15° 132 25 25° 214 49
6° 49 10 16° 141 27 26° 221 51
7° 61 13 17° 149 33 27° 230 53
8° 68 14 18° 158 34 28° 241 55
9° 76 16 19° 166 37 29° 252 56
10° 84 18 20° 173 38 30° 267 58
Como forma de testar a hipótese nula A (H0 A: A quantidade de downloads das

aplicações móveis desenvolvidas utilizando a abordagem MSECO-CERT em
comparação com quantidade de downloads das aplicações desenvolvidas com a
abordagem Ad hoc são similares), seguiram-se os procedimentos para testes estatísticos.
Os dados seguem distribuição normal a partir do teste de normalidade Shapiro-Wilk.
Considerando um nível de confiança de 95% ( = 0,05), utilizou-se o teste t-student
(pareado e bicaudal) para testar a hipótese. O p-value é menor que 0.00001, logo
resultado é significante para 𝑝 < 0.05 e a hipótese H0 A é rejeitada (a comparação da
quantidade de downloads entre as duas turmas não é similar). Para analisar a média das
avaliações de cada turma, foram levadas em consideração as avaliações das aplicações
móveis que obtiveram alguma classificação pelos usuários. Com esta informação,
calculou-se a média, mediana de avaliação para cada turma e o desvio padrão. O desvio-
padrão da avaliação de aplicações da Turma 1 (0,5) é menor que a da turma 2 (1,7).
Quando se volta a atenção para a tendência das avaliações, as avaliações da turma 1 são
mais próximas de 4,5. Já as avaliações da Turma 2 se dividem em uma aproximação
entre 4,3 e 2,5.
Em relação a análise qualitativa, na seção 5.5.2 da dissertação são apresentados
detalhes da análise da planilha de acompanhamento do processo de desenvolvimento
utilizado pelos desenvolvedores da turma 1, das anotações durante a utilização do
processo MSECO-SUP pelo evangelista da turma 1, incluindo observações acerca do
MSECO-DEV a partir da observação deste evangelista. Ainda foram analisas
qualitativamente as respostas de uma entrevista semiestruturada com o evangelista da
turma 2 após o treinamento e o acompanhamento dos desenvolvedores, as respostas do
formulário pós-treinamento tanto da turma 1 quanto da turma 2, e conversas por e-mail,
WhatsApp e Facebook, a partir da visão de DX (Experiência de Desenvolvedor).
Mesmo com os resultados viáveis e que confirmam a aplicabilidade da
abordagem, percebeu-se a necessidade de refinar a forma de apresentar a abordagem e,
também, de refinar a sequência de práticas e descrição de atividades, assim como,
disponibilizar o conjunto de artefatos necessários para a utilização da abordagem.
4.2. Estudo de observação – Adequação em um cenário real
O objetivo deste estudo estruturado com o GQM foi de: Analisar a aplicação da
abordagem MSECO-CERT com o propósito de avaliar em relação à adequação em um
contexto real do ponto de vista dos desenvolvedores e do evangelista no contexto de
336
engajamento e treinamento de desenvolvedores de aplicações móveis e evangelistas no
cumprimento de metas organizacionais em MSECO.
No estudo de observação, como forma de inserir a utilização da abordagem em
um cenário real da indústria, o objetivo não foi comparar com a utilização de uma outra
abordagem, mas sim obter informações sobre as dificuldades dos participantes e realizar
uma análise qualitativa da utilização da MSECO-CERT. Neste estudo, ainda no
MSECO Windows Phone, a plataforma utilizada foi a Windows Universal Platform
(UWP), optou-se pela mudança para analisar a adequação da abordagem em um cenário
onde é comum a atualização das plataformas. Destaca-se o fato de que o evangelista
participante é líder da comunidade de desenvolvedores Windows e Android e possui
nível alto de experiência (inclusive na indústria) em projeto, desenvolvimento e
publicação de apps, assim como, em evangelismo de comunidades de desenvolvedores.
O evangelista foi questionado sobre o grau de dificuldade da utilização do
MSECO-SUP para o evangelismo no contexto de MSECO. Este evangelista classificou
a utilização como fácil e em relação aos aspectos que tornam o MSECO-SUP de fácil
aplicação comentou: “Fácil de usar por ser de fácil entendimento, por tornar o
processo de desenvolvimento de apps mais organizado e estabelecer uma metodologia
durante todo o trabalho. De primeira a gente sente um pouco de dificuldade em seguir,
mas é questão de costume, sempre fazemos de qualquer jeito. ”. Quando questionado
acerca de que maneira o MSECO-SUP o auxiliou no evangelismo comentou:
“Positivamente. O MSECO-SUP me auxiliou no evangelismo de desenvolvedores que
executaram atividades de desenvolvimento, publicação e acompanhamento de uma app.
Talvez não tivesse chegado ao mesmo resultado se não tivesse o utilizado. ”.
Os desenvolvedores também classificaram o grau de dificuldade da aplicação
do processo MSECO-DEV, sete (70%) deles consideram fácil enquanto que 3 (30%)
acharam difícil. Entretanto, quando questionados sobre de que maneira o MSECO-DEV
o auxiliou no desenvolvimento, publicação e acompanhamento da sua app, todos os dez
desenvolvedores (100%) responderam que foi de forma positiva, ou seja, o MSECO-
DEV auxiliou no desenvolvimento, publicação e acompanhamento da aplicação móvel e
que talvez não tivessem chegado ao mesmo resultado se não tivesse o utilizado. E todos
os desenvolvedores complementaram informando que utilizariam o MSECO-DEV para
desenvolver suas aplicações móveis futuras.
5. Considerações finais
A organização central deve fazer com que o MSECO permaneça saudável, ou seja,
produtivo, favorecendo a criação de nichos de usuários e desenvolvedores e que suporte
variações de mercado. Para ter controle sobre a análise da saúde, a organização central
dispõe de indicadores de saúde como: quantidade de downloads e avaliação média de
aplicações móveis por usuários na loja de aplicações móveis. Desta forma o evangelista
deve ajudar o desenvolvedor a contribuir para um impacto positivo nesses indicadores,
o que impactará positivamente a saúde do MSECO.
Tendo em vista o cenário apresentado, este trabalho de pesquisa definiu e
avaliou uma abordagem baseada em processo para apoiar a certificação de aplicações
móveis em MSECO. Neste trabalho certificação está associada a utilização dos
processos para o evangelismo de desenvolvedores e desenvolvimento de aplicações
móveis. Três processos com um conjunto de recomendações associadas às atividades
337
foram definidos: MSECO-ORQ (orquestração, seguido pela organização central),
MSECO-SUP (suporte, seguido pelo evangelista) e MSECO-DEV (construção, seguido
pelo desenvolvedor). Todos passaram por revisão por pares com especialistas, onde foi
possível perceber que somente no MSECO-SUP e no MSECO-DEV seria possível
intervir para gerar algum impacto nos indicadores de saúde.
Para o MSECO-SUP e o MSECO-DEV foi definido ainda um conjunto de
práticas como forma de gerar um resultado concreto (impacto positivo) nos indicadores
de saúde do MSECO. Esses dois processos foram analisados por meio de pesquisas de
opinião, o MSECO-SUP com evangelistas dos três principais MSECOs (Android, iOS e
Windows Phone) e o MSECO-DEV por desenvolvedores novatos e experientes. Estas
pesquisas de opinião apoiaram no ajuste de atividades, recomendações e práticas.
Com isso a abordagem MSECO-CERT saiu da etapa de concepção para ser,
inicialmente, caracterizada em relação a viabilidade dos resultados produzidos. Um
estudo de viabilidade foi executado e percebeu-se que a utilização da abordagem
MSECO-CERT em comparação a uma abordagem Ad hoc, produz impactos notáveis na
quantidade de downloads e na média de avaliações das aplicações móveis. Foi possível
ainda perceber a mudança de atitudes positivas dos desenvolvedores que utilizaram a
abordagem MSECO-CERT. Este estudo ajudou, também, no refinamento da MSECO-
CERT.
Após o estudo de viabilidade, um estudo de observação foi executado para
identificar as possíveis dificuldades da utilização da abordagem no cenário real. Neste
estudo os participantes, evangelista e desenvolvedores, confirmaram que a utilização da
abordagem os ajudou positivamente e que talvez não chegassem nos mesmos resultados
caso não tivessem a utilizado. Os participantes ainda afirmaram que utilizariam a
abordagem para suas próximas atividades (evangelismo e desenvolvimento de
aplicações móveis).
Além da experiência relatada para definição e avaliação dos processos, que pode
servir de base para outras pesquisas em Ecossistemas de Software, as principais
contribuições desta pesquisa são: (1) Definição da abordagem MSECO-CERT; (2) A
análise de métricas, extraídas de um conjunto indicado pela literatura existente, para
analisar indicadores de saúde de MSECO; (3) Mapeamento Sistemático da Literatura
sobre MSECO, incluindo oportunidades de pesquisa; (4) Pacote de estudos
experimentais no contexto de ecossistemas de software. A parceria com a indústria
desse trabalho se mostra presente com o treinamento de plataformas da Microsoft, em
ambientes reais de treinamento, e o envolvimento de evangelistas da Apple, Google e
Microsoft em fases de concepção e/ou avaliação da MSECO-CERT.
As limitações desta pesquisa estão relacionadas ao tipo de MSECO, comunidade
de desenvolvedores e perfis dos evangelistas, como segue: Os estudos foram realizados
apenas no MSECO Windows Phone, então há a necessidade de realizar estudos nos
MSECOs Android (em andamento como colaboração) e iOS; Os evangelistas
participantes são oficiais do MSECO Windows Phone e um é evangelista oficial do
Android, no entanto é necessário ainda avaliar a utilização da abordagem com diferentes
níveis de perfil técnico quanto de temperamento psicológico. Apesar de o perfil técnico
básico de um evangelista nos três principais MSECOs ser similar.
338
6. Publicações e Colaboração
Este trabalho gerou cinco publicações de autoria própria e sete publicações em
colaboração com outras instituições em conferências e, também, participações em
orientação de quatro Trabalhos de Conclusão de Curso. Alguns dos artigos: Mobile
Software Ecosystems (MSECO): a systematic mapping study (COMPSAC 2015 –
Qualis A2); MSECO-SUP: Support Process in Mobile Software Ecosystems (SBES
2015 – Qualis B2); MSECO-DEV: Application Development Process in Mobile
Software Ecosystems (SEKE 2016 – Qualis B1); MSECO Skill: Construção de
Competências de Desenvolvedores em Ecossistemas de Software Móvel (CIbSE 2014 –
Qualis B4); Research Opportunities for Mobile Software Ecosystems (WDES 2015 –
Qualis B5).
Além disso três artigos para periódicos ou conferências em processo de
finalização para submissão: An Empirical Evaluation of a Process-Based Approach to
Certify Apps in Mobile Software Ecosystems (será submetido ao Journal Information
and Software Technology – Qualis A2); A Family of Experiments to Concept and
Evaluate a Mobile Application Certification Approach (será submetido ao Empirical
Software Engineering – Qualis B1); Mobile Application Development Training in
Mobile Software Ecosystem (MSECO): Investigating the Developer Experience
(submetido ao SBIE – Qualis B1).
Referências
Axelsson, J. and Skoglund, M. (2016). Quality assurance in software ecosystems: A
systematic literature mapping and research agenda. In: Journal of Systems and
Software, v. 114, n. 1, p. 69–81.
Babiy, V., Janicki, R., Wassyng, A., Bogobowicz, A. D. and Wyszynski, S. (2010).
Selecting the best strategy in a software certification process. In: Proceedings of the
International Multiconference on Computer Science and Information Technology,
pp. 53-58.
Jansen, S., Brinkkemper, S. and Finkelstein, A. (2009). Business Network Management
as a Survival Strategy: A Tale of Two Software Ecosystems. n. 2, pp. 34–48.
Lin, F. L. F. and Ye, W. Y. W. (2009). Operating System Battle in the Ecosystem of
Smartphone Industry. In: Proceedings of the International Symposium on
Information Engineering and Electronic Commerce, pp. 617-621.
Mafra, S., Barcelos, R., Travassos, G. (2006). Aplicando uma metodologia baseada em
evidência na definição de novas tecnologias de software. In: Proceedings of the 20th
Brazilian Symposium on Software Engineering, pp. 239-254.
Manikas, K. and Hansen, K. M. (2013). Reviewing the Health of Software Ecosystems
– A Conceptual Framework Proposal. In: Proceedings of the 5th International
Workshop on Software Ecosystems, pp. 33-44.
Shull, F., Carver, J. and Travassos, G. H. (2001). An Empirical Methodology for
Introducing Software Processes. In: Proceedings of European Software Engineering
Conference, pp. 288-296.
Villela, K., Travassos, G. H. and Regina, A. (2004). Definição e Construção de
Ambientes de Desenvolvimento de Software Orientados a Organização. In:
Proceedings of the Brazilian Symposium on Software Quality, pp. 32-46.
339
Organização do Corpo de Conhecimento sobre Dívida
Técnica: Tipos, Indicadores, Estratégias de Gerenciamento e
Causas
Nicolli Souza Rios Alves1,2 e Rodrigo Oliveira Spínola2,3
1
Programa de Pós-Graduação em Ciência da Computação – Universidade Federal da
Bahia (UFBA) – Salvador – BA – Brasil
2
Programa de Pós-Graduação em Sistemas e Computação – Universidade Salvador
(UNIFACS) – Salvador – BA – Brasil
3
Centro de Projetos Fraunhofer para Engenharia de Software e Sistemas
Salvador – BA – Brasil
nicollirioss@gmail.com, rodrigo.spinola@pro.unifacs.br
Abstract. The identification and management of technical debt (TD) improve

the software quality and the productivity of its development. However, before
identifying or managing it, it is necessary to know its different types, the
indicators of its presence, available techniques for its management, and the
causes for its occurrence. The goal of this work is to organize a body of
knowledge on TD considering this set of information. For this, we performed
(i) a systematic mapping study of the literature that resulted in the analysis of
100 primary studies and (ii) an interview study that considered 30 units of
analysis. The main results of this work are the organization of a body of
knowledge on TD and its sharing through the TD Wiki infrastructure.
Resumo. A identificação e gerenciamento da dívida técnica (DT) resulta em

maior qualidade e produtividade na construção do software. No entanto, antes
de identificar ou gerenciar a dívida, é necessário conhecer seus diferentes
tipos, os indicadores de sua presença, as técnicas para seu gerenciamento e as
causas para a sua ocorrência. O objetivo deste trabalho é organizar um corpo
de conhecimento sobre DT considerando esse conjunto de informações. Para
isso, foram realizados um mapeamento sistemático da literatura que resultou
na análise de 100 estudos primários e um estudo de entrevista que considerou
30 unidades de análise. Como resultado, o corpo de conhecimento foi
organizado e compartilhado através da infraestrutura TD Wiki.
1. Introdução
Durante o desenvolvimento, a qualidade do software diminui quando se considera
aspectos como sua estrutura interna, adesão a normas, documentação e facilidade de
entendimento para futuras manutenções [Lientz et al. 1978][Lehman e Belady 1985]
[Parnas 1994]. Um motivo para isso acontecer é que as atividades de desenvolvimento
são frequentemente realizadas sob forte restrição de tempo e recursos, sendo muitas
vezes investida a quantidade mínima de esforço e tempo necessários para sua realização.
340
Esse cenário traz, por exemplo, impactos na produtividade uma vez que uma
modificação em um software de baixa qualidade geralmente é mais difícil de ser
realizada do que em um de alta qualidade [Lehman e Belady 1985].
Lidar com essa questão considerando o conceito de Dívida Técnica (DT) tem
ajudado profissionais e pesquisadores a debaterem problemas associados ao
desenvolvimento do software. DT descreve o efeito de artefatos imaturos no
desenvolvimento do software, que traz um benefício a curto prazo para o projeto em
termos de maior produtividade e menor esforço, mas que poderão ter de ser ajustados
com juros (esforço extra necessário para ajustar o item da dívida ou realizar atividades
de desenvolvimento em um software com sua qualidade interna degenerada) mais tarde
[Seaman e Guo 2011][Kruchten et al. 2012]. A consequência desses problemas é
observada em atrasos inesperados na realização de modificações necessárias e na
dificuldade em atingir os critérios de qualidade acordados para o projeto [Spínola et al.
2013][Zazworka et al. 2013].
É comum que um projeto de software incorra em dívidas durante seu processo de
desenvolvimento. No entanto, sua presença traz riscos para o projeto e dificulta sua
gestão uma vez que os gerentes também terão que decidir se a dívida será paga e, em
caso positivo, quanto dela deve ser paga e quando. A identificação, medição e
gerenciamento da DT ajudaria os gestores a tomarem decisões fundamentadas,
resultando em maior qualidade do software e maior produtividade na execução das
atividades de desenvolvimento [Guo et al. 2014]. No entanto, antes de identificar, medir
ou gerenciar a dívida, é necessário entender quais são os tipos de dívida que podem
afetar os projetos, os indicadores de sua presença, as técnicas que têm sido propostas
para o seu gerenciamento e o que leva equipes a incorrerem a dívida. A organização
destas informações permitiria que equipes trabalhassem de forma mais controlada em
atividades de prevenção, monitoramento e gerenciamento da dívida, além de estabelecer
um arcabouço bem fundamentado sobre o qual novas pesquisas possam ser realizadas.
Este cenário motivou estes pesquisadores a organizarem um corpo de
conhecimento sobre DT considerando em sua estrutura os seguintes itens: tipos de
dívida, indicadores de sua presença, estratégias de gerenciamento e causas para a sua
ocorrência. Assim, buscou-se responder as seguintes questões de pesquisa principais:
(RQ1) Quais tipos de DT podem afetar projetos de software?; (RQ2) Quais são as
estratégias que têm sido propostas para identificar ou gerenciar a DT em projetos de
software?; (RQ3) Quais causas levam à ocorrência de DT?
Com a finalidade de atingir o objetivo do trabalho e responder às questões de
pesquisa, uma metodologia foi definida baseada no paradigma da engenharia de
software experimental [Basili 1992] e considerou a execução de dois estudos: (i) um
mapeamento sistemático da literatura para responder às RQs 1 e 2, e (ii) um estudo de
entrevista para responder à RQ3. Como resultado, este trabalho organizou os tipos de
dívida em uma taxonomia [Alves et at. 2014], mapeou estratégias de identificação e
gerenciamento da DT [Alves et al. 2016], identificou um conjunto de causas que levam
equipes de desenvolvimento a incorrerem DT em seus projetos [Alves et al. 2017] e
341
organizou e compartilhou todo este conhecimento em TD Wiki 1 [Alves et al. 2015], de
forma que as informações sejam facilmente acessadas por pesquisadores e profissionais.
Além desta introdução, este artigo está estruturado em mais sete seções. Na
Seção 2 é apresentada uma fundamentação teórica sobre DT. A Seção 3 apresenta a
metodologia empregada e os resultados alcançados nesta pesquisa. Em seguida, a Seção
4 discute o objetivo, metodologia e resultados alcançados do mapeamento sistemático
da literatura executado. A Seção 5 apresenta a taxonomia de tipos de DT organizada.
Em seguida, a Seção 6 discute o objetivo, metodologia e resultados do estudo de
entrevista realizado. A Seção 7 apresenta como o corpo de conhecimento organizado foi
disponibilizado na infraestrutura TD Wiki. Finalmente, a Seção 8 apresenta as
considerações finais deste trabalho.
2. Dívida Técnica
Desde sua citação inicial por Cunningham (1992), que utilizou o termo "going into
debt" para explicar que uma pequena dívida pode acelerar o desenvolvimento de
software, mas que cada minuto extra gasto com o código mal construído conta como
juros sobre essa dívida, o conceito de DT tem se expandindo e abrange, atualmente,
diferentes artefatos gerados ao longo do ciclo de desenvolvimento do software. Nesse
sentido, pesquisas têm sido realizadas para tratar a DT sob diferentes perspectivas
[Kruchten et al. 2012] [Zazworka et al. 2013] [Guo et al. 2014]: estratégias de
gerenciamento, identificação, quantificação, aspectos financeiros, entre outros.
Existem algumas iniciativas com o objetivo de organizar os diferentes tipos de
DT que podem afetar um projeto. Fowler (2003) classificou as dívidas considerando as
características: imprudente/prudente e deliberado/inadvertido. Estas características
permitem classificar a dívida quanto ao fato dela ter sido inserida de forma intencional
ou não e, para ambos os casos, se ela pode ser considerada o resultado de uma falta de
cuidado ou foi inserida com cautela. Próxima à classificação de Fowler, McConnell
(2007) classificou a dívida em dois grupos: intencional e não intencional. A dívida não
intencional ocorre devido a uma falta de atenção ou desconhecimento sobre a forma
mais correta de desempenhar uma tarefa. Já a dívida intencional é originada de forma
proativa por razões táticas ou estratégicas com o objetivo de cumprir o prazo de entrega.
Para que seja possível tornar a DT explícita e gerenciável, o primeiro passo é
identificá-la. Estudos têm demonstrado que diferentes estratégias automatizadas podem
ser utilizadas para apoiar a identificação da DT [Schumacher et al. 2010]. Também já se
tem evidência de que mesmo utilizando soluções automatizadas, é importante considerar
a percepção humana no processo de identificação uma vez que ela permite agregar
informações contextuais a cada instância de DT encontrada e, dessa forma, aperfeiçoar a
avaliação feita por ferramentas automatizadas [Zazworka et al. 2013].
Associada à atividade de identificação da dívida, estratégias de gerenciamento de
DT também têm sido propostas [Guo et al. 2014]. Elas buscam identificar e monitorar
os itens de DT inseridos no projeto de forma que eles estejam explícitos e sejam pagos
no momento oportuno para evitar transtornos maiores.
1
www.tdwiki.com
342
Entre as razões para incorrer em DT podem estar prazos muitos apertados, falta
de recursos e metas com alto custo [Buschmann 2011]. Embora relevante para apoiar a
gestão da DT sob uma perspectiva preventiva, a identificação de causas que levam à
ocorrência da DT ainda é um assunto pouco explorado na literatura técnica.
3. Metodologia e Resultados da Pesquisa

A metodologia utilizada neste trabalho foi fundamentada no paradigma da Engenharia
de Software Experimental [Basili 1992], que busca aprimorar a engenharia de software
aplicando a abordagem científica na construção e/ou evolução de métodos, teorias e
técnicas, sejam eles novos ou já existentes, para apoiar as atividades de
desenvolvimento.
A Figura 1 apresenta as atividades realizadas, sendo que para cada uma delas são
descritos os respectivos objetivos, resultados e publicações obtidas. Conforme pode ser
observado, dois estudos experimentais (destacados em cinza escuro) foram executados:
um mapeamento sistemático da literatura e um estudo de entrevista. O planejamento do
mapeamento sistemático foi fundamento na revisão informal da literatura realizada na
atividade 1 e, além de seus próprios resultados [Alves et al. 2016], possibilitou a
definição de uma taxonomia de tipos de DT [Alves et al. 2014] na atividade 3. Já o
estudo de entrevista executado na atividade 4 possibilitou investigar uma lacuna
observada durante a execução do mapeamento: a identificação de causas que levam à
ocorrência da DT [Alves et al. 2017]. Os resultados de todos esses estudos permitiram
organizar um corpo de conhecimento sobre DT que foi estruturado e compartilhado na
infraestrutura TD Wiki [Alves et al. 2015] elaborada na atividade 5.
Uma descrição mais aprofundada sobre as atividades 2, 3, 4 e 5 considerando
seus objetivos, metodologia e resumo dos resultados alcançados será apresentada,
respectivamente, nas Seções 4, 5, 6 e 7 deste artigo.
Figura 1. Metodologia e resultados da pesquisa.
343
4. Identificação e Gerenciamento da Dívida Técnica: Um Mapeamento
Sistemático da Literatura
4.1 Objetivo
Esta seção apresenta os resultados de um mapeamento sistemático da literatura
conduzido com o objetivo de responder a seguinte questão de pesquisa: "Quais são as
estratégias que têm sido propostas para identificar ou gerenciar a DT em projetos de
software?". As seguintes questões complementares foram derivadas da questão
principal:
• (Q1) Quais são os tipos de DT?
• (Q2) Quais são as estratégias propostas para identificar a DT?
o(Q2.1) Quais avaliações experimentais foram realizadas?
o(Q2.2) Quais são as fontes de dados e artefatos que têm sido propostos para
identificar a DT?
o(Q2.3) Quais técnicas de visualização de software têm sido propostas para
apoiar a identificação de DT?
• (Q3) Quais estratégias têm sido propostas para apoiar o gerenciamento da DT?
o(Q3.1) Quais avaliações experimentais foram realizadas?
o(Q3.2) Quais técnicas de visualização de software têm sido propostas para
apoiar o gerenciamento da DT?
Ao responder estas questões, foram identificados os tipos de DT, os indicadores
de sua existência em projetos e as estratégias que têm sido desenvolvidas para apoiar a
gestão dessa dívida. Além disso, o grau de maturidade das propostas existentes foi
investigado através de uma análise das avaliações experimentais que foram realizadas.
Também foi pesquisado como recursos de visualização de software têm sido utilizados
para apoiar a identificação e monitoramento da DT, identificando quais metáforas
visuais têm sido propostas e quais são as plataformas que estão sendo usadas para
apresentar os diferentes tipos de dívida.
4.2 Metodologia
O mapeamento sistemático da literatura fornece um meio para realizar revisões de
literatura abrangentes e imparciais, proporcionando valor científico. Ele é um tipo de
estudo secundário que tem como objetivo caracterizar uma determinada área de pesquisa
através de um procedimento sistemático que visa identificar a extensão e a natureza dos
principais estudos disponíveis na área [Budgen et al. 2008]. No mapeamento realizado
neste trabalho, seguiu-se um processo baseado no definido por Peterson et al. (2008),
que considera as seguintes atividades: definição das questões de pesquisa, definição das
fontes de dados, condução da busca, seleção dos estudos, extração de dados e
mapeamento dos resultados. Maiores detalhes sobre o planejamento do estudo podem
ser encontrados em [Alves et al. 2016].
A identificação e a filtragem dos artigos foram realizadas em cinco etapas
(Figura 2). A primeira consistiu na busca por artigos em cada uma das bibliotecas
digitais selecionadas para este estudo (ACM Digital Library, IEEE Xplore, Science
Direct, Engenharia Village, Springer Link, Scopus, CiteSeer e DBLP). No segundo
passo, um pesquisador realizou a primeira filtragem utilizando os critérios de exclusão.
344
Esse processo resultou na exclusão de todos os relatórios de workshops/conferências,
apresentações em Power Point e artigos duplicados.
Na terceira etapa, cada artigo foi analisado por dois pesquisadores e, no caso de
conflito, um terceiro analisaria e tomaria a decisão de incluir ou não o estudo. A
filtragem ocorreu através da leitura dos títulos, abstracts e introdução usando os critérios
de inclusão e exclusão. Após esta etapa, 100 estudos foram selecionados para o próximo
estágio de filtragem. Na quarta etapa, o último filtro foi aplicado. Desta vez, os
trabalhos selecionados foram lidos na íntegra. Ao final desta fase, mais 12 artigos foram
excluídos por não possuírem informações suficientes sobre identificação ou
gerenciamento de DT. Finalmente, na quinta etapa foi aplicado o snowballing,
verificando as referências de cada estudo selecionado. Ao final, 100 estudos foram
selecionados para extrair as informações e responder às questões de pesquisa.
Figura 2. Processo de filtragem dos artigos

4.3 Resumo dos Resultados
A Figura 3 representa uma visão consolidada do estudo realizado considerando a relação
entre o número de artigos analisados por assunto (indicadores, artefatos, fontes de
dados, estratégia de gerenciamento, visualização de software), os tipos de DT
identificados e a quantidade de estudos experimentais realizados. Pode-se observar que
a maioria dos estudos lida com DT no nível de código fonte, ou seja, dívida de projeto,
defeito, código e arquitetura (área superior esquerda do gráfico de bolhas).
Também é possível observar a existência de tipos de dívida (ex.: requisitos,
código, teste) ao longo de todo o ciclo de desenvolvimento do software. Assim, garantir
a qualidade do código fonte não é a única maneira de melhorar a qualidade do projeto.
Apesar disso, grande parte dos estudos identificados se concentram em analisar os
problemas existentes no código. Essa ênfase pode ser explicada pelo fato de que já há
um conjunto considerável de métricas e ferramentas que permitem extrair informações
do código que podem ser utilizadas como indicadores da presença da dívida.
Este trabalho também identificou vários estudos sobre estratégias de
gerenciamento da DT. No entanto, embora diferentes estratégias tenham sido
identificadas, apenas cinco delas (Abordagem de Portfólio, Análise de Custo-Benefício,
Processo Analítico Hierárquico, Cálculo do DT-principal, e Marcação das dependências
e problemas de código) foram citadas em mais de dois trabalhos e somente algumas
delas foram avaliadas. Isso mostra que a maioria dos autores propuseram novas
estratégias, mas poucos estão realizando estudos para avaliar a sua aplicabilidade.
Também é possível observar na Figura 3 que ainda são poucos os estudos
realizados sobre o uso de técnicas de visualização de software para apoiar as atividades
relacionadas à DT. Além disso, quando se observa o lado direito do gráfico, onde os
estudos experimentais identificados são apresentados, é possível notar que o
conhecimento sobre os benefícios e limitações do que tem sido proposto pela
comunidade de pesquisa ainda é limitado.
345
Figura 3. Visualização dos resultados do mapeamento sistemático
Este mapeamento sistemático buscou, principalmente, orientar futuras pesquisas
sobre identificação e gerenciamento de DT. Entretanto, seus resultados também têm
implicações importantes para profissionais, particularmente para aqueles que buscam na
literatura orientação sobre como gerenciar DT em projetos reais:
• DT pode ser encontrada em diferentes artefatos. Assim, várias estratégias devem
ser empregadas se o objetivo é encontrar todos os tipos de DT que podem trazer
um impacto negativo para o projeto;
• Existem diferentes indicadores para cada tipo de DT. Assim, os desenvolvedores
possuem opções para definir uma estratégia para identificar e rastrear a DT em
seus projetos, e deveriam definir critérios para a escolha dos mais adequados;
• A maioria das pesquisas sobre identificação de DT é relacionada a dívida de
código. Isto poderia sugerir que se concentrar em atividades de identificação de
DT considerando, inicialmente, a dívida relacionada com código faria sentido.
No entanto, este tipo de decisão deve ser assumido como sendo um risco porque
a dívida pode estar oculta no projeto de formas diferentes e aquelas não
relacionadas a código também podem trazer impactos negativos significativos.
Assim, sugere-se evitar limitar o escopo da identificação da dívida àquelas
346
relacionadas apenas a código;
• Foram identificadas diferentes estratégias de gestão de DT. A maioria delas
ainda requer uma investigação mais aprofundada e avaliação experimental. No
entanto, elas podem ser um ponto de partida para a customização ou a definição
de uma estratégia de gerenciamento de DT em um projeto de software real.
Para pesquisadores, os resultados do estudo trazem as seguintes implicações:
• Existem diferentes tipos de DT e alguns indicadores para cada um deles, mas
não foi identificada nenhuma evidência sobre como utilizar este conjunto de
informações para orientar iniciativas de identificação de DT em situações reais.
Apesar dos progressos em diferentes áreas da DT, ainda há uma necessidade de
analisar o todo e investigar abordagens holísticas para gerir de forma eficaz a DT
na indústria de software;
• Poucos estudos experimentais foram realizados em ambientes reais. Este é um
indicador de que, em algumas áreas, ainda não é possível entender
completamente todos os custos ou benefícios dos indicadores de DT e estratégias
de gerenciamento propostas. Algumas delas foram apenas citadas;
• A pesquisa sobre DT é altamente concentrada em alguns tipos de dívida (projeto,
arquitetura, código e defeito). Isto indica uma lacuna que pode ser explorada nos
próximos anos.
Os resultados obtidos também indicaram que DT é uma área de pesquisa ativa e
produtiva, que continua a crescer e que ainda necessita de maior maturidade em termos
de conceitos consolidados e novas avaliações experimentais.
5. Taxonomia de Tipos de Dívida Técnica

5.1 Objetivo
Esta seção apresenta a definição de uma taxonomia para organizar os diferentes tipos de
DT. Depois de definida, a taxonomia foi avaliada em duas etapas. Na primeira delas,
critérios de qualidade adaptados de Gruber (1995) foram considerados. Em um segundo
momento, um especialista da área, que não participou do desenvolvimento da
taxonomia, fez uma avaliação do conhecimento organizado.
5.2 Metodologia
A construção de taxonomias não é uma tarefa simples e deve ser apoiada por práticas da
engenharia de software. Neste trabalho foi utilizado um processo estruturado para guiar
a sua definição. O processo foi uma adaptação da abordagem SABiO definida por Falbo
et al. (1998) para apoiar a construção de ontologias. Embora existam abordagens
específicas para apoiar a definição de taxonomias, SABiO foi escolhida por já ter sido
utilizada no apoio à definição de diferentes vocabulários de conhecimento. As seguintes
atividades foram desempenhadas:
• Identificação de Propósitos e Especificação de Requisitos: neste trabalho, o
propósito da taxonomia é organizar os diferentes tipos de DT considerando sua
natureza como critério de classificação;
• Captura e Formalização da Taxonomia: os tipos de DT definidos na
taxonomia, assim como suas definições, foram identificados a partir do resultado
347
do mapeamento sistemático apresentado na seção 4. Associadas a cada um dos
tipos, outras informações também foram especificadas: indicadores que podem
ser utilizados para identificar a DT em projetos e referências de onde as
informações foram extraídas. Uma vez capturados os conceitos que definiam a
taxonomia, realizou-se sua formalização na linguagem OWL.
• Avaliação da Taxonomia: a taxonomia definida foi avaliada em duas etapas:
oAvaliação a partir dos critérios de qualidade [Gruber 1995]: para a
primeira etapa, a taxonomia foi enviada para dois pesquisadores do grupo
de pesquisa sobre dívida técnica TDResearchTeam 2. Os pesquisadores
foram convidados a avaliá-la considerando os seguintes critérios:
Clareza, Extensibilidade, Viés de codificação mínimo e Compromissos
mínimos. No geral, alguns pequenos ajustes foram solicitados de forma a
tornar mais clara a diferença entre alguns tipos de DT e melhorar a
definição de alguns exemplos;
oAvaliação por um especialista na área: A segunda etapa da avaliação
considerou as recomendações de Gruber (1995), que indica que
representações de conhecimento devem ser embasadas no consenso de
um grupo de especialistas da área. Neste trabalho, esta atividade foi
desempenhada por um especialista na área de DT. Para isso, os tipos
identificados e suas respectivas definições foram organizados em um
formulário e enviados para avaliação. O especialista que participou desta
etapa é um pesquisador sênior sendo, atualmente, um dos mais atuantes
na área de DT e estudos qualitativos em engenharia de software
experimental. Como resultado da avaliação, um conjunto de ajustes foi
sugerido no sentido de tornar mais claras algumas definições que, em
alguns casos, estavam descritas sob diferentes perspectivas. Além disso,
foi indicado também que os tipos identificados faziam sentido, nenhum
novo tipo foi sugerido.
Os tipos de DT estruturados na taxonomia foram [Alves et al. 2014]:
• Dívida de Arquitetura: refere-se a problemas encontrados na arquitetura do
software que podem afetar os requisitos arquiteturais do projeto;
• Dívida de Automação de Testes: refere-se ao trabalho envolvido na
automatização de testes de funcionalidades previamente desenvolvidas para
apoiar a integração contínua e ciclos mais rápidos de desenvolvimento;
• Dívida de Build (Construção): refere-se a questões que tornam a tarefa de
compilação mais difícil e desnecessariamente demorada;
• Dívida de Código: refere-se a problemas encontrados no código que podem
afetar negativamente a legibilidade do código tornando-o mais difícil de manter;
• Dívida de Defeito: refere-se a defeitos conhecidos que o comitê de controle de
configuração concorda que devem ser reparados, mas que devido a prioridades
concorrentes e recursos limitados, têm de ser adiados para mais tarde;
• Dívida de Documentação: refere-se a problemas encontrados na documentação
2
www.tdresearchteam.com
348
como documentação inexistente, inadequada ou incompleta;
• Dívida de Infraestrutura: refere-se a questões de infraestrutura que podem
atrasar ou impedir algumas atividades de desenvolvimento;
• Dívida de Pessoas: refere-se a questões relacionadas a pessoas que podem
atrasar ou impedir a realização de algumas atividades de desenvolvimento;
• Dívida de Processo: refere-se a processos ineficientes;
• Dívida de Projeto: pode ser descoberta através da análise do código fonte e
identificação de violações de princípios da orientação a objetos;
• Dívida de Requisitos: refere-se a decisões sobre quais requisitos a equipe de
desenvolvimento precisa implementar ou como implementá-los;
• Dívida de Serviço: refere-se à seleção e substituição inadequada de serviços
web que levam à incompatibilidade entre as características do serviço e os
requisitos da aplicação;
• Dívida de Teste: refere-se a problemas (ex.: baixa cobertura dos testes)
encontrados em atividades de teste que podem afetar sua qualidade;
• Dívida de Usabilidade: refere-se a decisões inadequadas de usabilidade que
terão de ser ajustadas mais tarde;
• Dívida de Versionamento: refere-se a problemas de versionamento do código
fonte, como uso desnecessário de forks.
A taxonomia definida permite o compartilhamento de um vocabulário comum
para comunidade de pesquisa em DT e profissionais da área. Embora ela seja uma
tentativa inicial de organizar os tipos de dívida, a lista de tipos pode não ser completa,
podendo levar à necessidade de exclusão de alguns deles ou inclusão novos tipos. Para
obter uma taxonomia melhor definida, a colaboração entre diferentes especialistas
precisa ser estimulada, de forma que que eles participem de seu desenvolvimento. Para
isso, foi desenvolvida uma infraestrutura (apresentada na Seção 7) para permitir o
compartilhamento e evolução colaborativa desse conhecimento.
6. Causas que Levam à Inserção da DT: Um Estudo de Entrevista

6.1 Objetivo
O estudo de entrevista foi conduzido com o objetivo de analisar os diferentes tipos de
DT, com o propósito de caracterizar, com respeito às causas que levam a sua inserção,
no contexto de projetos de desenvolvimento de software sob o ponto de vista de
profissionais da área [Alves et al. 2017]. Alinhado a este objetivo, foram definidas as
seguintes questões de pesquisa: (Q1) Quais causas levam à ocorrência de dívida
técnica?; (Q2) As causas ocorrem de forma encadeada ou isolada?; (Q3) A dívida
técnica pode ser evitada?; (Q4) Em termos de esforço, é melhor evitar a dívida ou
incorrê-la para pagar depois?
6.2 Metodologia
O estudo de entrevista foi planejado e executado considerando profissionais da área. A
escolha dos participantes foi realizada por conveniência e considerou dois parceiros da
indústria: Centro de Projetos Fraunhofer para Engenharia de Software e Sistemas e
SENAI Cimatec. Ao total, 10 engenheiros de software foram convidados a participar do
estudo via e-mail e foram entrevistados presencialmente.
349
Antes de realizar a entrevista, um formulário de caracterização e consentimento
foi preenchido pelos participantes do estudo. O resultado dessa caracterização foi
utilizado para apoiar a escolha dos tipos de dívida sobre os quais cada participante
deveria responder. As entrevistas foram realizadas individualmente, sendo que cada
entrevistado respondeu às perguntas sobre três tipos de dívida. Como cada entrevistado
respondeu a cada pergunta três vezes (cada uma para um tipo de dívida) e o estudo
contou com a participação de 10 engenheiros de software, ao final, 30 respostas foram
obtidas para cada questão realizada.
No início de cada entrevista foi realizada uma breve apresentação do tema DT,
que durou cerca de 10 minutos. Em seguida, para cada tipo de dívida definido para o
entrevistado, os passos apresentados a seguir foram considerados:
1. A definição do tipo de dívida selecionado foi apresentada;
2. Foi pedido ao entrevistado que ele fornecesse um exemplo, com base em sua
experiência, do tipo de dívida que estava sendo discutido, para confirmar o
entendimento do entrevistado sobre o tipo considerado;
2.1. Se o entrevistado desse um exemplo que não fosse do tipo de dívida em
discussão, seria pedido um segundo exemplo explicando novamente a definição
daquele tipo;
2.1.1. Se o entrevistado não conseguisse pensar em um exemplo sobre o tipo de
dívida escolhido, este tipo deveria ser substituído por um outro tipo.
2.2. Se o entrevistado apresentasse um exemplo que representasse o tipo de dívida
discutido, a entrevista prosseguia para o próximo passo;
3. Foi perguntado ao entrevistado o que levou a equipe de desenvolvimento a inserir o
item de dívida descrito em seu exemplo;
3.1. Em seguida, foi perguntado se algum outro motivo teria levado ou contribuído
para o motivo citado. Esta pergunta foi realizada repetidas vezes de forma que
detalhes mais específicos sobre o que poderia ter levado a equipe a incorrer na
dívida fosse identificado (o objetivo aqui foi fugir do óbvio e tentar entender se
as causas para a inserção da dívida ocorrem em cadeia);
4. Foi perguntado ao entrevistado o que, na opinião dele, teria evitado a DT;
4.1.Em seguida, foi perguntado se valeria a pena ter investido na prevenção da
dívida considerando o que ele indicou na pergunta anterior ou se fazer isso seria
mais caro do que incorrer na própria dívida.
As entrevistas foram gravadas com autorização dos participantes. Depois de

realizadas, elas foram transcritas para que a análise dos dados pudesse ser realizada. Os
textos transcritos das entrevistas passaram por um processo de codificação e, então, as
evidências coletadas foram avaliadas frente às questões de pesquisa.
A codificação foi realizada por um pesquisador e, depois, avaliada por um
segundo de acordo com o esquema de codificação definido. Este esquema partiu de um
conjunto inicial de códigos e evoluiu à medida que a análise dos dados foi realizada. Os
resultados do estudo foram formulados com base na síntese dos fragmentos codificados
de cada questão. Assim, os resultados foram fundamentados nos dados do estudo, em
vez de formulados anteriormente e validados através dos dados.
350
Ao total foram identificadas 84 causas distintas (Q1). Destas, as mais citadas foram
prazo (13 citações), custo (5 citações), documentação inexistente (4 citações) e alta
rotatividade na equipe (4 citações). Foi possível observar também que a maioria das
causas estavam associadas a um tipo de dívida. A presença de causas compartilhadas e
específicas indica que ações para prevenir a dívida podem ter um efeito específico ou
contribuírem para o tratamento de diferentes tipos de dívida.
Em relação à Q2, no geral, os resultados indicaram que uma série de fatores leva
à presença da dívida no projeto. Embora as causas possam afetar o projeto de forma
isolada, quando ocorrem em cadeia a consequência é potencializada. Além disso, as
causas podem possuir pesos diferentes na contribuição para a ocorrência da dívida. Para
questão de pesquisa Q3, os entrevistados indicaram em sua maioria que a DT poderia
ser evitada. Apenas dois participantes indicaram que a dívida não poderia ser evitada.
Para aqueles que indicaram que a dívida não poderia ser evitada totalmente, o motivo
estava associado à existência de uma causa que não poderia ser tratada.
Por fim, em relação à Q4, os resultados indicaram que é melhor e mais barato
investir na prevenção da dívida do que incorrê-la e pagá-la depois. Foi possível observar
também que alguns fatores pesam positivamente na decisão de prevenir a dívida: custo
da correção tardia dos problemas inseridos no projeto, nível de retrabalhado necessário
para eliminar a dívida e a motivação da equipe. Os dois últimos fatores impactam
diretamente na produtividade da equipe de desenvolvimento. Por outro lado, podem
existir situações em que é melhor incorrer a dívida e pagá-la depois, como o que ocorre
quando o custo de evitar a dívida é maior do que o de inseri-la.
7. TD Wiki: Compartilhamento e Evolução do Conhecimento sobre DT

TD Wiki é uma infraestrutura computacional de apoio ao compartilhamento e evolução
colaborativa do conhecimento sobre DT disponibilizada na web [Alves et al. 2015]. No
contexto deste trabalho, as seguintes informações foram organizadas para compor a base
de conhecimento: tipos de dívida técnica, indicadores, causas e estudos de avaliação.
Existem duas expectativas principais para esta infraestrutura: (1) criar um canal para que
o assunto DT seja efetivamente tratado na indústria de software através do
compartilhamento das informações em um formato adequado para uso por profissionais;
(2) permitir a evolução do conhecimento de forma colaborativa.
Em TD Wiki, o conhecimento foi organizado em duas camadas: visão geral e
visão detalhada. A camada de visão geral está representada na página inicial (Figura 4 –
imagem superior), na qual são apresentadas uma breve descrição de cada tipo de dívida
e alguns de seus indicadores. Para isso, os tipos de dívida foram representados em uma
árvore (quanto mais espessas forem as linhas, mas evidências já foram coletadas sobre
aquele tipo de dívida). É a partir dessa árvore que o usuário pode obter mais detalhes
sobre cada tipo.
Já na camada de visão detalhada (Figura 4 – imagem inferior), o usuário tem
acesso aos indicadores conhecidos de cada tipo de dívida, as causas que podem levar à
sua ocorrência, estudos de avaliação realizados e algumas referências. Nesta página, os
usuários também podem indicar que tipo de DT eles estão trabalhando e quais
351
indicadores são mais adequados para a identificação daquele tipo. Também é possível
indicar quais são as principais causas que contribuem para que um determinado tipo de
dívida seja inserido no projeto. Essas informações coletadas dos usuários são utilizadas
pela infraestrutura para representar a relevância dos indicadores e causas.
Além do acesso às informações, TD Wiki também permite a evolução
colaborativa do conhecimento, possibilitando que usuários registrados adicionem novos
tipos de dívida, indicadores, causas e referências. Para cada uma dessas funcionalidades,
um grupo de três moderadores avalia as informações fornecidas. Se aprovada, a nova
informação é incorporada à base de conhecimento e disponibilizada para visualização.
Figura 4. TD Wiki
Este trabalho organizou um corpo de conhecimento sobre DT considerando seus tipos,
indicadores, estratégias de gerenciamento e causas para sua ocorrência. Em
complemento, as informações organizadas foram disponibilizadas através da
infraestrutura TD Wiki. Para alcançar estes resultados, a pesquisa seguiu duas linhas de
trabalho: (1) realização de um mapeamento sistemático da literatura complementado por
um estudo de entrevista para a coleta de evidências; (2) estruturação das informações
identificadas em uma taxonomia de tipos de dívida e em uma infraestrutura que apoia o
compartilhamento e evolução colaborativa do conhecimento.
Ao analisar as questões de pesquisa principais definidas para este trabalho e
descritas na Seção 1, os seguintes resultados e contribuições foram obtidos: (i)
Organização de um corpo de conhecimento sobre dívida técnica [Alves et al. 2016], (ii)
Estruturação do corpo de conhecimento organizado [Alves et al. 2014], (iii)
Identificação de causas que levam equipes de desenvolvimento a inserirem a dívida em
seus projetos [Alves et al. 2017], e (iv) Compartilhamento do corpo de conhecimento
organizado [Alves et al. 2015]. Em conjunto, estes resultados contribuem para a
evolução do Technical Debt Landscape [Izurieta et al. 2012] [Kruchten et al. 2012].
352
Ainda há muito a ser pesquisado e explorado sobre DT. Considerando este
trabalho como ponto de partida, algumas perspectivas futuras de trabalho são: (i) ainda
não se sabe como as causas identificadas estão relacionadas a indicadores de presença
da dívida. Algumas relações entre causas e indicadores parecem ser justificadas
logicamente, por exemplo: falta de experiência dos desenvolvedores e violação de
modularidade; falta de experiência dos desenvolvedores e dependências estruturais. No
entanto, uma investigação aprofundada do tipo de relação (causa - consequência) ainda
pode ser considerada uma área em aberto; (ii) realizar avaliação experimental da
infraestrutura TD Wiki de modo que sua aplicabilidade seja avaliada, e; (iii) replicar o
estudo de entrevista executado. Essa replicação permitirá que os resultados sejam mais
generalizáveis e permitirá que análises específicas (por exemplo, por tipo de dívida)
sejam realizadas.
Atualmente, os autores deste trabalho estão envolvidos em um projeto de
pesquisa que busca investigar causas e efeitos que a dívida pode trazer em projetos de
software. O trabalho tem sido realizado no contexto da pesquisa de doutorado da
primeira autora deste artigo.
7. Agradecimentos
Agradecemos à CAPES e ao CNPq (Universal 458261/2014-9) pelo apoio financeiro
para a realização deste trabalho. Agradecemos também aos demais membros do
TDResearchTeam.com que contribuíram com esta pesquisa.
Referências
Alves, N.S.R., Araújo, R.S. and Spínola, R.O. (2015) A Collaborative Computational
Infrastructure for Supporting Technical Debt Knowledge Sharing and Evolution. In:
Americas Conference on Information Systems, Puerto Rico.
Alves, N.S.R., Mendes, T.S., Mendonça, M.G., Spínola, R.O., Shull, F. and Seaman, C.
(2016) Identification and Management of Technical Debt: A Systematic Mapping
Study. Information and Software Technology, 70, 100 – 121. DOI:
https://doi.org/10.1016/j.infsof.2015.10.008
Alves, N.S.R., Spínola, R.O., Mendonça, M.G. and Seaman, C. (2017) A study of
factors that lead development teams to incur technical debt in software projects.
Submetido em abril de 2017 para o Empirical Software Engineering Journal.
Alves, N.S.R., Ribeiro, L. F., Caires, V., Mendes, T.S. and Spínola, R.O. (2014)
“Towards an Ontology of Terms on Technical Debt”. In Proc. of the Sixth Int. Work.
on Managing Technical Debt. IEEE Comp Society, Washington, USA, 1-7. DOI:
10.1109/MTD.2014.9
Basili, V.R. (1992) The Experimental Paradigm in Software Engineering. In Proc. of the
International Workshop on Experimental Software Engineering Issues: Critical
Assessment and Future Directions. Springer-Verlag, London, UK, UK, 3-12.
Budgen, D., Turner, M., Brereton, P. and Kitchenham, B. (2008) Using Mapping
Studies in Software Engineering. In the Proceedings of PPIG Psychology of
Programming Interest Group, Lancaster University, UK, pp. 195–204.
353
Buschmann, F. (2011) “To pay or not to pay technical debt,” IEEE Software, v. 28, n. 6,
p. 29-31.
Cunningham, W. (1992) The WyCash portfolio management system. ACM SIGPLAN
OOPS Messenger, 4(2), 29-30.
Falbo, R.A., Menezes, C.S. and Rocha, A.R.C. (1998) A systematic approach for
building ontologies. In Ibero-American Conference on Artificial Intelligence (pp.
349-360). Springer Berlin Heidelberg.
Fowler, M. (2003) Technical Debt. Available:
http://www.martinfowler.com/bliki/TechnicalDebt.html
Gruber, T.R. (1995) “Toward Principles For The Design Of Ontologies Used For
Knowledge Sharing,” Int. Journal Human-Computer Studies, 43(5/6), p. 907-928.
Guo, Y., Spínola, R.O. and Seaman, C. (2014) Exploring the costs of technical debt
management – a case study, Empirical Software Engineering, 1-24.
Izurieta, C., Vetro, A., Zazworka, N., Cai, Y., Seaman, C. and Shull, F. (2012)
Organizing the technical debt landscape, in Third International Workshop on
Managing Technical Debt (MTD), pp. 23-26.
Kruchten, P., Nord, R. and Ozkaya, I. (2012) Technical Debt: From Metaphor to Theory
and Practice, Software, IEEE 29(6), 18-21.
Lehman, M.M. and Belady, L.A. (1985) Program evolution: processes of software
change. Academic Press Professional, Inc.
Lientz, B.P., Swanson, E.B. and Tompkins, G.E. (1978) Characteristics of application
software maintenance. Communications of the ACM, 21(6), 466-471.
Mcconnell, S. (2007) Technical Debt. 10x Software Development [Blog]. Available at:
http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx.
Parnas, D.L. (1994) Software aging. In Proceedings of the 16th international conference
on Software engineering (pp. 279-287). IEEE Computer Society Press.
Petersen, K., Feldt, R., Mujtaba, S. and Mattson, M. (2008) Systematic mapping studies
in software engineering. In the 12th International Conference on Evaluation and
Assessment in Software Engineering, University of Bari, Italy.
Schumacher, J.; Zazworka, N.; Shull, F.; Seaman, C. and Shaw, M. (2010) Building
empirical support for automated code smell detection, ESEM’10: Proceedings of the
2010 ACM-IEEE Int. Symp. on Empirical Software Engineering and Measurement.
Seaman, C. and Guo, Y. (2011) Measuring and Monitoring Technical Debt, Advances
in Computers 82, 25-46.
Spínola, R., Zazworka, N., Vetro`, A., Seaman, C. and Shull, F. (2013) Investigating
technical debt folklore: Shedding some light on technical debt opinion, in Managing
Technical Debt (MTD), 2013 4th International Workshop on, pp. 1-7.
Zazworka, N., Spínola, R.O., Vetro, A., Shull, F. and Seaman, C. (2013) A case study
on effectively identifying technical debt, EASE 13: Proceedings of the 17th
International Conference on Evaluation and Assessment in Software Engineering.
354
Infraestrutura para um Corpo de Conhecimento em
Melhoria de Processos de Software Baseado no MR-MPS-SW
Peter P. Lupo1, Marcos Kalinowski2, Ana Regina C. da Rocha1
1
COPPE/UFRJ – Universidade Federal do Rio de Janeiro – Caixa Postal 68511 –
CEP 21.941-972 – Rio de Janeiro, RJ – Brazil
2
Instituto de Computação – Universidade Federal Fluminense (UFF)
Rua Passos da Pátria 156, 24.220-240 – Niterói – RJ – Brazil
{pplupo, darocha}@cos.ufrj.br, kalinowski@ic.uff.br
Abstract. Software development organizations commonly follow maturity

models to guide their software process improvement initiatives, being respon-
sible for identifying and choosing the technologies to address these models’
requirements. This paper proposes an infrastructure to organize a body of
knowledge of technologies that support the implementation of the MR-MPS-
SW focused on the software process improvement professionals’ needs.
Resumo. Organizações desenvolvedoras de software comumente fazem uso de

modelos de maturidade para orientar a melhoria de seus processos, sendo
responsabilidade destas organizações identificar e escolher as tecnologias pa-
ra apoiar o atendimento dos requisitos destes modelos. Este trabalho propõe
uma infraestrutura para organizar um corpo de conhecimento de tecnologias
que apoiam a implementação do MR-MPS-SW voltado para as necessidades
dos profissionais de melhoria de processos.
1. Introdução
Diferentes fatores motivam as organizações a realizarem melhorias em seus processos
de desenvolvimento de software. Muitas vezes estas melhorias são realizadas com o
apoio de modelos de maturidade como o CMMI-DEV [CMMI Product Team 2010] e o
MR-MPS-SW (Modelo de Referência MPS para Software) [Softex 2016]. Modelos de
maturidade são comumente descritos na forma de objetivos ou resultados esperados com
a execução dos processos da organização. Estes resultados são decorrência da utilização
de boas práticas. A adoção destas boas práticas, por sua vez, pode fazer uso de diferen-
tes tecnologias (métodos, técnicas e ferramentas) [CMMI Product Team 2010; Softex
2016].
Dentre os modelos de maturidade de processos de Engenharia de Software, o
MR-MPS-SW se destaca no âmbito nacional, apresentando inclusive maior adoção que
o CMMI-DEV [Kalinowski et al. 2014]. Também é interessante ressaltar que a adoção
do MR-MPS-SW pela indústria tem sido relacionada com benefícios para as organiza-
ções como o crescimento organizacional, aumento da quantidade de projetos, aumento
da quantidade de clientes e aumento da quantidade de funcionários contratados
[Travassos and Kalinowski 2014].
Nas organizações que utilizam o MR-MPS-SW, a busca e seleção de tecnologias
que apoiem as melhores práticas para o atendimento dos requisitos do modelo são res-
355
ponsabilidade de cada organização. O modelo indica “o que deve ser feito”, mas não
“como deve ser feito”. Esta seleção deve, portanto, ser feita de maneira compatível com
o contexto, os objetivos estratégicos da organização e a cultura organizacional, o que
exige conhecimento tanto nos processos a serem melhorados quanto nas tecnologias de
Engenharia de Software [Cerdeiral 2014; Kalinowski et al. 2010; Santos et al. 2012].
A busca por conhecimento a respeito de tecnologias de Engenharia de Software
que apoiem a melhoria de processos é essencial podendo levar as organizações a realiza-
rem treinamentos, contratarem novos colaboradores, consultorias, participarem de con-
gressos ou recorrerem à literatura para alcançar seus objetivos e maximizar seu retorno
de investimento [Cerdeiral 2014; Kalinowski et al. 2010; Montoni 2010]. É possível
encontrar na literatura estudos investigando tecnologias, com resultados de pesquisas da
academia e de aplicações na indústria. Este conhecimento está disponível em diferentes
bases científicas, sendo algumas de acesso restrito. Tem-se, portanto, conhecimento
gerado, mas ele se encontra disperso e nem sempre é de fácil acesso.
De acordo com KUHRMANN et al. [Kuhrmann et al. 2015], apesar de haver ex-
tenso conhecimento sobre melhoria de processos de software, é difícil responder a ques-
tões como “O que existe?”, e “Qual o estado atual da área e pesquisas relacionadas?”.
Além disto, os conhecimentos sobre tecnologias relatados na literatura dificilmente al-
cançam os profissionais que atuam na indústria, sendo necessário adaptar o formato de
apresentação das informações para melhor apoiar tomadores de decisão [Jedlitschka et
al. 2014].
Uma alternativa para sintetizar conhecimento sobre tecnologias que apoiam a
melhoria de processos e apresentá-lo de maneira organizada e estruturada é a organiza-
ção de um corpo de conhecimento (BoK – Body of Knowledge), que poderia auxiliar
profissionais facilitando o acesso ao conhecimento e ajudando a promover sua utilização
efetiva. Um BoK é um conjunto estruturado de conhecimentos em um domínio de inte-
resse que sejam aceitos, acordados e utilizados por profissionais que atuam neste domí-
nio [Chinn and Kramer 1995; Oliver 2012; Ören 2005].
Este artigo descreve uma infraestrutura que permite a organização de um BoK
sobre tecnologias que podem ser utilizadas na melhoria de processos de software com
base no MR-MPS-SW, o MPS-BoK. O propósito do MPS-BoK é permitir organizar
conhecimento sobre tecnologias (utilizadas na indústria e/ou avaliadas através de estu-
dos experimentais) e disponibilizá-lo de maneira que possa ser utilizado por profissio-
nais que realizam melhoria de processos com base no MR-MPS-SW. A infraestrutura
foi projetada para permitir a organização do MPS-BoK de maneira incremental e cola-
borativa através de um processo para atualizá-lo, o MPS-BoK-P, e de uma ferramenta
que automatiza a organização do conhecimento extraído neste processo e o disponibiliza
no MPS-BoK, oferecendo uma possível vantagem aos tradicionais guias de implemen-
tação que normalmente apenas são atualizados juntamente com as atualizações do mo-
delo. Os achados das avaliações realizadas fornecem indícios de sua viabilidade de utili-
zação e subsídios relevantes para sua melhoria.
O restante deste artigo está organizado da seguinte forma. A Seção 2 descreve a
fundamentação teórica a respeito de corpos de conhecimento. A Seção 3 apresenta os
requisitos para a infraestrutura. A Seção 4 descreve a infraestrutura em si. As avaliações
realizadas são detalhadas na Seção 5. Por fim, a Seção 6 apresenta as considerações fi-
nais do artigo.
356
2. Corpos de Conhecimento e sua Organização
Na Engenharia de Software pesquisadores constantemente desenvolvem novas tecnolo-
gias, realizam experimentos e publicam resultados. É importante que o conhecimento
sobre estas tecnologias seja organizado para que seja difundido e utilizado na prática.
Uma forma de se realizar esta organização e estruturação de conhecimento que possa
permitir uma generalização é a organização de corpos de conhecimento (Body of Kno-
wledge – BoK) [Shull et al. 2003].
Um BoK pode ser definido como um conjunto estruturado de conhecimentos em
um domínio de interesse que sejam aceitos, acordados e utilizados por profissionais que
atuam neste domínio [Chinn and Kramer 1995; Ören 2005]. A percepção da importância
da criação de corpos de conhecimento em uma área relativamente recente como a Enge-
nharia de Software está representada na construção de diversos corpos de conhecimento.
Em uma revisão informal da literatura foi possível identificar 15 corpos de conhecimen-
to na área de Engenharia de Software e áreas relacionadas, como gerência de projetos e
engenharia de sistemas (e.g., SWEBOK, SWE-BoK, PMBoK, SEBoK, PSP BoK, TSP
BoK) e analisados em detalhes [Lupo 2016].
Uma processo para a organização de BoKs a partir de informações provenientes
de publicações científicas que pode ser aplicado de maneira colaborativa é o SKE (Sys-
tematic Knowledge Engineering) [Biffl et al. 2014a; Biffl et al. 2014b]. SKE é um pro-
cesso sistemático de engenharia de conhecimento definido com base nas diretrizes para
revisões sistemáticas da literatura [Kitchenham and Charters 2007]. SKE apoia a orga-
nização de corpos de conhecimento a partir de estudos empíricos de publicações cientí-
ficas e já foi utilizado para gerar corpos de conhecimento com evidências de estudos
empíricos em inspeção [Biffl et al. 2014a] e em outras áreas, como ameaças à validade e
ações de controle em experimentos controlados e linhas de produtos de software [Biffl
et al. 2014b]. A Figura 1 apresenta uma visão geral do processo SKE.
Uma descrição detalhada do processo pode ser encontrada em [Biffl et al.
2014b]. A descrição resumida de suas fases visando fornecer a fundamentação para a
compreensão do trabalho descrito neste artigo é apresentada a seguir.
Na primeira fase do SKE, um protocolo é construído baseado em uma configu-
ração específica da estratégia PICO (Population, Intervention, Comparison, Outcome)
[Richardson et al. 1995] para derivar questões de pesquisa que possam ser aplicadas a
bibliotecas digitais no formato “P and I and C and O”. A segunda fase do SKE compre-
ende a criação de um modelo de domínio para a base de conhecimento. A terceira fase
do SKE compreende a extração de informações dos trabalhos encontrados através de
buscas realizadas utilizando o protocolo criado na primeira fase e a quarta fase compre-
ende a integração destas informações à base de conhecimento criada na segunda fase.
Também está na quarta fase a criação de um mecanismo de consulta a esta base de co-
nhecimento.
3. Requisitos para a Infraestrutura para a Organização do MPS-BoK

A partir do conhecimento obtido na revisão da literatura e da experiência dos autores em
melhoria de processos de software, foram definidos requisitos para o MPS-BoK, bus-
cando o atendimento das necessidades dos profissionais que realizam melhoria de pro-
cessos de software com base no MR-MPS-SW. Destes requisitos foram então derivados
requisitos para a infraestrutura que apoia a organização do MPS-BoK. Um detalhamento
destes requisitos segue.
357
Figura 1 – Processo SKE, adaptado de Biffl et al. [2014b].
3.1 Organizar conhecimento sobre tecnologias de acordo com a estrutura do MR-

MPS-SW
Sendo o público-alvo do MPS-BoK composto por profissionais interessados na melho-
ria de processos com base no MR-MPS-SW, é de se supor que conheçam os resultados
esperados exigidos pelo modelo. Assim, recuperar os conhecimentos do BoK relaciona-
dos diretamente aos resultados esperados é um mecanismo simples que utiliza um voca-
bulário conhecido pelos usuários, sem a necessidade da organização de consultas mais
complexas.
Como o MR-MPS-SW [Softex 2016] está organizado em processos de Engenha-
ria de Software, o MPS-BoK deve ser organizado segundo os mesmos processos de En-
genharia de Software encontrados no modelo. Para isto, o MR-MPS-SW foi analisado
quanto à sua estrutura, que pode ser vista na Figura 2.
Cada nível do MR-MPS-SW agrupa processos com objetivos e escopo claramen-
te definidos através de um propósito e resultados esperados. Além dos processos, cada
nível possui atributos de processo (AP), que são acrescentados conforme os níveis de
maturidade ascendem, e determinam a capacidade com a qual cada processo é executa-
do.
3.2 Disponibilizar conhecimento sobre as tecnologias de forma a apoiar os profissi-

onais na tomada de decisão
O corpo de conhecimento deve poder ser utilizado como referência pelos profissionais
para tomada de decisão sobre tecnologias a serem adotadas em iniciativas de melhoria
de processos. Desta forma, é importante que o MPS-BoK seja capaz de capturar conhe-
cimento que apoie a tomada de decisão. Este conhecimento envolve informações sobre a
tecnologia, o contexto em que ela pode ser utilizada e o seu impacto [Jedlitschka et al.
2014]. Neste sentido, um conjunto de informações sobre tecnologias para satisfazer as
358
necessidades de informação de profissionais foi identificado [Jedlitschka et al. 2014]. A
infraestrutura deve ser capaz de armazenar conhecimento que contenha estas informa-
ções sobre as tecnologias.
Figura 2 – Estrutura do MR-MPS-SW. Adaptado de [Softex 2016].
Atualmente existe muito conhecimento sobre tecnologias em melhoria de pro-

cessos de software descrito na literatura sob a forma de relatos de experiência, relatórios
técnicos, artigos, teses, etc. É bastante relevante que o conhecimento sobre estas tecno-
logias, desde que tenham sido aplicadas e avaliadas, possa ser utilizado para compor o
MPS-BoK. Assim, é importante que a infraestrutura proposta não faça restrições quanto
ao tipo de evidência ou de publicação da qual o conhecimento será extraído desde que
suas contribuições sejam referentes a modelos, teorias, frameworks, guias e ferramentas,
de acordo com a classificação de Kuhrmann et al. [Kuhrmann et al. 2015].
A principal forma de disponibilização deste conhecimento deve ser através da
navegação pela estrutura do MR-MPS-SW. Além deste mecanismo, para facilitar a sua
utilização, a infraestrutura deve fornecer um mecanismo de busca por palavras chave em
cima das informações (tecnologia, contexto e impacto) contidas no MPS-BoK, permi-
tindo a rápida recuperação do conhecimento desejado.
3.3 Fornecer apoio para a atualização do conhecimento

A infraestrutura deve prover uma forma que permita a atualização do conhecimento de
maneira colaborativa e incremental, de forma que vários pesquisadores possam contri-
buir integrando novos conhecimentos ao MPS-BoK.
4. A Infraestrutura para o MPS-BoK

A infraestrutura foi definida objetivando o atendimento dos requisitos e é composta por
dois componentes principais. O processo MPS-BOK-P, que visa permitir a organização
do MPS-BoK de maneira incremental e uma ferramenta que apoia a organização do co-
nhecimento extraído neste processo e o disponibiliza no MPS-BoK.
4.1 Definição do MPS-BoK-P

O MPS-BoK-P foi definido através de uma especialização do SKE realizada a partir da
análise de como suas atividades poderiam ser preparadas e otimizadas para o caso espe-
cífico de elaborar o MPS-BoK que pode ser vista com detalhes em Lupo [2016]. Esta
359
análise foi realizada em todas as fases do SKE, consistindo na execução integral ou par-
cial de algumas de suas atividades visando a sua otimização.
Durante esta execução do processo, conforme previsto em SKE, foi concebido
um modelo de domínio. Para o caso específico do MPS-BoK o modelo contempla a
estrutura do MR-MPS-SW e permite vincular a ela informações sobre tecnologias que
apoiam profissionais na tomada de decisão, de acordo com o modelo de informações
definido por [Jedlitschka et al. 2014] (e.g., tecnologia, contexto e impacto). O modelo
resultante pode ser visto na Figura 3. É importante ressaltar que, apesar de ter sido cons-
truído com foco no MR-MPS-SW, este modelo é compatível com todos os modelos da
família MPS e modelos com estrutura similar como o CMMI-DEV e outros. Neste mo-
delo, além da estrutura fixa do MR-MPS-SW a entidade Tag permite associar palavras-
chave relacionadas com os elementos do MR-MPS-SW para facilitar buscas futuras.
Tecnologias de relacionadas a um resultado são retornadas quando uma palavra chave
associada a este resultado é utilizada na busca. As palavras chave foram identificadas a
partir da leitura do modelo por um dos autores e associadas a atributos de processo após
a revisão por outro autor. Este modelo representa o conhecimento que será agregado ao
MPS-BoK através da execução do processo MPS-BoK-P.
Figura 3 – Modelo de Domínio do MPS-BoK.
Apenas aquelas atividades cujos resultados variam para cada atualização do

MPS-BoK estão presentes no MPS-BoK-P. As atividades do MPS-BoK-P podem ser
vistas na Figura 4 e suas descrições se encontram a seguir.
Figura 4 – Atividades do MPS-BoK-P.

Atividade 1 - Especificar o processo alvo. A primeira atividade do MPS-BoK-P
é selecionar o processo para o qual conhecimento deve ser incorporado ou atualizado no
BoK dentre os processos definidos no MR-MPS-SW. A partir desta seleção, pode ser
definido o protocolo de pesquisa.
Atividade 2 - Definir o protocolo de pesquisa e as fontes de publicações. A ativi-
dade de definição do protocolo de pesquisa deve ser feita com base em uma configura-
360
ção específica da estratégia PICO para derivar strings de pesquisa que possam ser apli-
cadas nas fontes de publicações.
Nesta configuração, a população representa o processo selecionado na primeira
atividade. A intervenção representa o alvo da investigação (apoios na forma de técnicas,
processos, métodos, metodologias, frameworks, componentes de processos ou ferramen-
tas). Como o MPS-BoK não se restringe a uma comparação específica entre tópicos, a
comparação é vazia e não será incluída na estratégia PICO. O resultado, apesar de repre-
sentar elementos de interesse obrigatórios a serem extraídos dos estudos (por ex., algum
tipo de melhoria de eficiência), não precisa ser definido, pois qualquer resultado é de
interesse para o MPS-BoK.
Em seguida, a consulta deve ser construída no formato “(P) AND (I)”. Este pro-
tocolo deve ser aplicado em uma ou mais fontes de publicações selecionadas, como bi-
bliotecas digitais, por exemplo. Adicionalmente, a estratégia de busca pode ser comple-
mentada com estratégias de busca de publicações adicionais a partir das já selecionadas,
como backward e forward snowballing.
Três critérios de inclusão obrigatórios devem ser respeitados:
1. Incluir apenas publicações relacionadas com o processo escolhido na primeira
atividade.
2. Incluir apenas publicações que relatem alguma utilização ou avaliação sobre a
tecnologia apresentada (e.g., experimento, survey). As publicações a serem in-
cluídas devem ser referentes a pesquisas do tipo (de acordo com KUHR-
MANN et al. [Kuhrmann et al. 2015]):
 Pesquisa de avaliação – implementada na prática, avaliação da implementa-
ção conduzida.
 Proposta de solução – proposta de solução para um problema incluindo de-
monstração de benefícios e/ou aplicação, por exemplo, através de experi-
mentos, estudo de caso ou avaliação com estudantes em laboratório.
3. Incluir apenas publicações cujas contribuições sejam sobre (de acordo com
KUHRMANN et al. [Kuhrmann et al. 2015]):
 Modelo – representação de realidade observada por conceitos.
 Teoria – constructo de relacionamento causa-efeito.
 Framework – frameworks/métodos relacionados à melhoria de processos de
software.
 Ferramenta – uma ferramenta para apoiar melhoria de processos de software
Atividade 3 - Extração de dados. A atividade de extração de dados segue as es-
tratégias de pesquisa, seleção, avaliação e extração de dados do protocolo. Para apoiar
esta atividade uma planilha de extração foi preparada para acumular dados de acordo
com um modelo de conhecimento definido, que caracteriza a tecnologia em relação à
estrutura do modelo MPS-SW e informações relevantes de acordo com o modelo de
informações definido por JEDLITSCHKA et al. [Jedlitschka et al. 2014]. Esta planilha
deve ser preenchida nesta fase com base nas informações disponíveis nas publicações
selecionadas.
Atividade 4 - Integração dos dados. A integração dos dados é realizada a partir
da submissão da planilha preenchida resultante da Atividade 3 para a importação e agre-
gação ao MPS-BoK. A funcionalidade de importação na base de conhecimento é provi-
da pela ferramenta de apoio ao MPS-BoK, detalhada na próxima seção. A partir da im-
portação os dados ficarão disponíveis para consulta no MPS-BoK.
361
4.2 Ferramenta de Apoio ao MPS-BoK
O acesso ao MPS-BoK é operacionalizado por uma ferramenta de apoio online que
permite que seu conteúdo seja consultado e que novos conhecimentos sobre tecnologias
sejam incorporados ao corpo já existente. Neste artigo são apresentadas informações
gerais sobre a ferramenta, descrita em detalhes por Lupo [2016].
A ferramenta de apoio ao MPS-BoK possui dois mecanismos a partir dos quais
se pode efetuar buscas por conhecimento. Um destes mecanismos é uma Full Text Se-
arch (pesquisa em texto integral), através da qual uma string de consulta pode ser in-
formada e a ferramenta busca os conhecimentos associados. Para aumentar a flexibili-
dade da busca, o MR-MPS-SW foi lido e palavras-chave relacionadas ao contexto de
cada resultado esperado ou atributo de processo foram identificadas. Em seguida, essas
palavras chave foram associadas a todos os resultados e atributos em que apareceram.
Essa informação adicional marca os resultados e atributos como etiquetas e são utiliza-
das nas buscas realizadas por este mecanismo.
Este mecanismo de busca pode ser visto na Figura 5, cujas características de cor
originais foram alteradas para melhorar a visibilidade. Esta figura apresenta, na sua parte
superior, uma caixa de texto que permite que o conhecimento seja buscado. Ao inserir
uma string de consulta, o MPS-BoK apresenta na parte inferior uma tabela com o resul-
tado da busca realizada.
Figura 5 – Tela de consulta do MPS-BoK.

Outro mecanismo de busca presente na ferramenta é através da estrutura do MR-
MPS-SW. Assim, na ferramenta é possível navegar por níveis, processos e resultados
esperados ou atributos de processo. Ao selecionar um resultado esperado ou atributo de
processo, os conhecimentos associados ao elemento selecionado são retornados pela
ferramenta. Na Figura 6 é possível ver os resultados esperados do processo Gerência de
Projetos no nível G. Também é possível ver os outros processos e atributos de processos
introduzidos neste nível.
Informações adicionais sobre a tecnologia são referentes ao contexto de utiliza-
ção e ao impacto da utilização. Estas informações são específicas da utilização relatada
na publicação e, portanto, estão fortemente associadas a ela. Para representar esta asso-
362
ciação, estas informações são apresentadas como detalhes da publicação. Desta forma,
uma mesma tecnologia pode ser identificada em mais de uma publicação e cada publi-
cação pode trazer informações diferentes sobre contexto e impacto da utilização da tec-
nologia. As Figuras 7 e 8 apresentam, respectivamente, os detalhes da tecnologia e os
detalhes da publicação (contexto e ao impacto de utilização da tecnologia).
Figura 6 – Tela de consulta do MPS-BoK – detalhe da estrutura do MR-MPS-SW
Figura 7 – Detalhes da tecnologia no MPS-BoK.
As informações apresentadas são provenientes da importação das informações de

planilhas resultantes de execuções do MPS-BoK-P. Esta importação é realizada através
de uma funcionalidade cujo acesso é restrito às pessoas responsáveis pela manutenção
do MPS-BoK, através de usuário e senha. Esta funcionalidade permite a importação
automática da planilha através de upload.
Tecnologias que possuem o mesmo nome agregam todas as publicações relacio-
nadas. A ferramenta identifica um nome da tecnologia para realizar esta agregação au-
tomática como sendo o mesmo após a aplicação de técnicas de tratamento de texto. Uma
bag of words [Harris 1981] foi construída retirando-se as stop words [Rajaraman and
Ullman 2011] e comparando as palavras na ordem, sendo consideradas palavras iguais
as que possuírem a distância Levenshtein menor ou igual a 2 [Levenshtein 1966].
363
Figura 8 – Detalhes do contexto e impacto de utilização da tecnologia.
5. Avaliação da infraestrutura proposta para o MPS-BoK

A extração de conhecimento por pesquisadores para posterior adição ao MPS-BoK foi
avaliada por ter sido considerada parte fundamental do MPS-BoK-P. Outra avaliação
teve como foco a utilização da ferramenta de apoio ao MPS-BoK por profissionais en-
volvidos com melhoria de processos de software em organizações que desenvolvem
software. Neste artigo um resumo destas avaliações é apresentado, cujos detalhes podem
ser vistos em Lupo [2016].
Para estas avaliações foram definidos os objetivos de acordo com o “G”oal da
abordagem Goal/Question/Metric (GQM) [Basili et al. 1994]. Esta abordagem apresenta
uma estrutura para a definição de objetivos considerada adequada para este trabalho.
Esta estrutura é definida como “Analisar o <objeto de estudo> com a finalidade de <ob-
jetivo> com respeito à <foco da qualidade> do ponto de vista de <perspectiva> no con-
texto de <contexto>”.
Além disso, foram formulados questionários baseados no TAM. O TAM
(Technology Acceptance Model) [Davis 1989; Davis et al. 1989] foi utilizado por ser
considerado adequado para medir a aceitação e a intenção de uso de novas tecnologias
[Turner et al. 2010]. Assim, as perguntas foram definidas de acordo com o TAM e fo-
ram respondidas com a utilização de uma escala Likert [Likert 1932], suprimida a opção
“neutro” (central) para evitar que neutralidades em um pequeno grupo de respondentes
inviabilizem conclusões. Também foram incorporados mecanismos para que os partici-
pantes dessem sua opinião sobre cada um dos aspectos avaliados no TAM.
5.1 Avaliação TAM da planilha de extração do conhecimento

O objetivo desta avaliação foi: “Analisar a planilha de extração de informação com a
finalidade de caracterizar com respeito à utilidade percebida, ao esforço da adoção e à
intenção de adoção do ponto de vista do pesquisador no contexto da atividade Extração
de dados do MPS-BoK-P a partir de artigos científicos”.
Pela definição do perfil do usuário que executa esta atividade, de acordo com o
MPS-BoK-P, os participantes devem ser pesquisadores com conhecimento do MR-
MPS-SW. Esta qualificação representa a caracterização necessária. Assim, tendo em
vista a caracterização precisa, a técnica de seleção da amostra foi convenience sampling.
364
Os participantes convidados foram todos doutores na área de Engenharia de Software e
avaliadores do MR-MPS-SW.
Durante a operação, um artigo [Pinheiro et al. 2015] foi fornecido para a extra-
ção das informações para a planilha, o formulário foi preenchido e as respostas foram
agregadas. É importante ressaltar que o objetivo da realização da extração foi que os
participantes pudessem responder às questões de posse de uma experiência real, não
caracterizando um experimento, mas uma experiência de uso para que pudessem opinar
na avaliação. Ao todo 7 pesquisadores foram convidados a participar do estudo e 5 acei-
taram.
Após a extração e o preenchimento da planilha, cada participante respondeu ao
questionário posicionando-se em relação às perguntas e, a seu critério, fornecendo deta-
lhamentos adicionais nos campos de observações. Os tempos de execução das atividades
por cada um dos participantes, incluindo o tempo de extração das informações, foram
1h20min, 1h21min, 1h50min, 2h15min e 2h25min. Os resultados da avaliação em rela-
ção às dimensões do TAM (utilidade percebida, esforço de adoção e intenção de uso)
estão sumarizados a seguir.
Utilidade Percebida. As respostas sobre a utilidade percebida se posicionaram de
maneira equilibrada em todas as perguntas com a dificuldade de compreensão dos cam-
pos tendo sido consistentemente considerada nos comentários como um fator que con-
tribuiu negativamente no resultado.
Esforço da Adoção. Quanto ao esforço de adoção, as respostas foram relativa-
mente homogêneas tendendo levemente a resultados positivos, valendo ressaltar que
houve diversos comentários relacionados à dificuldade de compreensão dos campos a
serem preenchidos e de utilização da planilha devido à formatação e à validação, que
precisam ser tratados como insumos para melhorias futuras.
Intenção de Uso. Apesar das respostas indicarem uma percepção majoritariamen-
te negativa dos participantes em relação à intenção de uso, os comentários mostram que
dois responderam de forma negativa por não possuírem familiaridade com o MPS-BoK
e os outros dois citam que os fatores impeditivos são os problemas relacionados ao en-
tendimento dos campos, formatação e restrições de edição impostas pela validação que
influenciaram negativamente suas respostas. Estes problemas precisam ser mitigados
através de melhorias na planilha e de um melhor esclarecimento quanto ao propósito de
sua utilização.
5.2 Avaliação TAM da ferramenta de apoio ao MPS-BoK

O objetivo desta avaliação foi: “Analisar a ferramenta de apoio ao MPS-BoK com a
finalidade de caracterizar com respeito à utilidade percebida, esforço da adoção e inten-
ção de adoção do ponto de vista do profissional de melhoria de processos de software
familiarizado com o MR-MPS-SW no contexto da utilização da ferramenta na execução
de uma atividade relacionada à busca de conhecimento para melhoria de um processo de
medição aderente ao MR-MPS-SW”. Novamente um questionário foi construído a partir
do TAM para capturar a percepção do praticante.
Tendo a necessidade de envolver profissionais de melhoria de processos familia-
rizados com o MR-MPS-SW, a amostra foi selecionada utilizando convenience sam-
pling. A caracterização dos participantes foi realizada através de um questionário espe-
365
cífico com a intenção de avaliar a experiência atuando com melhoria de processos e
conhecimento do MR-MPS-SW.
Para a execução desta avaliação foi construído um cenário no qual uma organi-
zação fictícia precisa melhorar um processo de medição. A necessidade de melhoria do
processo foi descrita e os participantes solicitados a executar uma atividade na forma de
passos a serem seguidos na ferramenta visando chegar a um conhecimento que os apoie
na tomada de decisão para o alcance da melhoria desejada. Novamente, o objetivo da
realização da atividade foi que os participantes pudessem responder às questões familia-
rizados com a ferramenta e sua utilização, não caracterizando um experimento.
Com o propósito de alimentar o MPS-BoK com conhecimento sobre o processo
Medição do MR-MPS-SW, o MPS-BoK-P foi executado pelo primeiro autor. Ao todo
foram extraídas informações de 10 tecnologias a partir de 9 artigos associados com o
processo Medição identificados entre os anos de 2003 a 2015 nos anais do Simpósio
Brasileiro de Qualidade de Software (SBQS) e do Workshop Anual do MPS (WAMPS).
O formulário de caracterização e o do TAM foram preenchidos pelos participan-
tes após a conclusão da tarefa de uso da ferramenta. Foram obtidas respostas de 4 pro-
fissionais que atuam na área de melhoria de processos de software de organizações dife-
rentes, sendo duas grandes empresas (um banco e uma empresa do setor de energia) e
duas médias (uma fábrica de testes e uma fábrica de software) e que possuem conheci-
mento do MR-MPS-SW (todos são ou já foram avaliadores do modelo). A caracteriza-
ção dos participantes pode ser vista na Figura 9. É possível observar que se trata de pro-
fissionais extremamente experientes e realmente atuantes com melhoria de processos,
representando uma amostra apropriada da população alvo do estudo. Os resultados em
relação às dimensões do TAM se encontram sumarizados a seguir.
Utilidade Percebida. No geral as respostas sobre a utilidade percebida foram
consideradas positivas, sendo frequentes os comentários sobre campos não preenchidos
e questões relacionadas ao contexto específico de um dos participantes que podem ter
contribuído negativamente.
Esforço da Adoção. Todos os participantes deram respostas positivas em todas as per-
guntas relacionadas ao esforço de adoção, com comentários também positivos.
366
Figura 9 – Caracterização dos Participantes.
Intenção de Uso. A avaliação da utilidade da ferramenta foi uma das perguntas

com mais dispersão nas respostas. A única avaliação negativa, no entanto, se deve ao
participante C, que justifica sua avaliação dizendo que no seu trabalho atual não há o
costume de se realizar melhorias em processos com base em conhecimento externo à
organização. Os outros participantes indicaram uma percepção positiva da utilidade da
ferramenta de acesso ao MPS-BoK e forneceram sugestões sobre o tipo de conhecimen-
to que a tornaria ainda mais útil e informações a serem apresentadas em associação com
o conhecimento. Estas sugestões podem ser alvo de trabalhos futuros.
Neste artigo foi descrita uma infraestrutura para a organização de um BoK sobre tecno-
logias que podem ser utilizadas na melhoria de processos de software com base no MR-
MPS-SW, o MPS-BoK. A infraestrutura foi projetada para permitir a organização do
MPS-BoK de maneira incremental e colaborativa através de um processo para atualizá-
lo, o MPS-BoK-P, e de uma ferramenta que automatiza a organização do conhecimento
extraído neste processo e o disponibiliza no MPS-BoK.
As principais contribuições referentes à concepção da infraestrutura apresentada
neste trabalho são: (i) um processo simples que permite a atualização do conhecimento
de maneira incremental, o MPS-BoK-P, definido através de uma especialização do SKE
[Biffl and Kalinowski and Rabiser and et al. 2014] combinada com definições forneci-
das por KUHRMANN et al. [Kuhrmann et al. 2015]; (ii) um modelo de domínio capaz
de representar o MR-MPS-SW e informações associados aos seus elementos de modo a
satisfazer as necessidades de profissionais (conforme definido em [Jedlitschka et al.
2014]); (iv) uma planilha para extração das informações das publicações de acordo com
o modelo definido (ativo do processo MPS-BoK-P); e (v) uma ferramenta para organi-
zar e disponibilizar conhecimento resultante de diferentes execuções deste processo,
integrando informações sobre as tecnologias automaticamente e provendo mecanismos
de busca textual utilizando recursos de operadores booleanos além de consulta através
dos elementos do MR-MPS-SW.
No contexto das avaliações, o MPS-BoK-P foi executado pelo primeiro autor
para preencher o MPS-BoK com conhecimento a respeito de tecnologias referentes ao
processo de medição de software provenientes de artigos do SBQS e do WAMPS. Fo-
ram realizadas avaliações sobre elementos-chave da proposta através de questionários
elaborados a partir do TAM direcionados ao público alvo. Estas avaliações fornecem
indícios preliminares de viabilidade e elementos importantes para subsidiar trabalhos
futuros. Os trabalhos futuros compreendem a realização dos ajustes e melhorias identifi-
cados nas avaliações para a disponibilização final do MPS-BoK, a generalização da so-
lução para outros modelos de maturidade e novas avaliações.
É importante ressaltar que o interesse dos profissionais no MPS-BoK está asso-
ciado aos conhecimentos incorporados pelos pesquisadores. Desta forma, o sucesso do
BoK depende diretamente do engajamento da comunidade científica na contribuição de
conteúdo através da execução do MPS-BoK-P.
Referências
Basili, V. R., Caldiera, G. and Rombach, H. D. (1994). The Goal Question Metric
367
Approach. Wiley.
Biffl, S., Kalinowski, M., Ekaputra, F. J., Serral, E. E. and Winkler, D. (2014). Building
Empirical Software Engineering Bodies of Knowledge with Systematic Knowledge
Engineering. In International Conference on Software Engineering and Knowledge
Engineering (SEKE).
Biffl, S., Kalinowski, M., Rabiser, R., Ekaputra, F. and Winkler, D. (29 dec 2014).
Systematic Knowledge Engineering: Building Bodies of Knowledge from Published
Research. International Journal of Software Engineering and Knowledge Engineering,
v. 24, n. 10, p. 1533–1571.
Cerdeiral, C. T. (2014). Implantação de Inovações Tecnológicas e de Processo em
Organizações de Software. Tese de Doutorado. UFRJ.
Chinn, P. L. and Kramer, M. K. (1995). Theory and nursing: a systematic approach.
Mosby.
CMMI Product Team (2010). CMMI for Development, Version 1.3. Carnegie Mellon
University. http://repository.cmu.edu/sei/287/.
Davis, F. D. (sep 1989). Perceived Usefulness, Perceived Ease of Use, and User
Acceptance of Information Technology. MIS Quarterly, v. 13, n. 3, p. 319.
Davis, F. D., Bagozzi, R. P. and Warshaw, P. R. (aug 1989). User Acceptance of
Computer Technology: A Comparison of Two Theoretical Models. Management
Science, v. 35, n. 8, p. 982–1003.
Harris, Z. S. (1981). Distributional Structure. Dordrecht: Springer Netherlands.
Jedlitschka, A., Juristo, N. and Rombach, D. (11 dec 2014). Reporting experiments to
satisfy professionals’ information needs. Empirical Software Engineering, v. 19, n. 6, p.
1921–1955.
Kalinowski, M., Santos, G., Reinehr, S., et al. (2010). MPS . BR : Promovendo a
Adoção de Boas Práticas de Engenharia de Software pela Indústria Brasileira. In XIII
Congreso Iberoamericano en“ Software Engineering”(CIBSE). .
http://www.softex.br/mpsbr/_guias/default.asp.
Kalinowski, M., Weber, K., Franco, N., et al. (2014). Results of 10 years of software
process improvement in Brazil based on the MPS-SW model. Proceedings - 2014 9th
International Conference on the Quality of Information and Communications
Technology, QUATIC 2014, n. December 2003, p. 28–37.
Kitchenham, B. and Charters, S. (2007). Guidelines for performing Systematic
Literature Reviews in Software Engineering. Engineering, v. 2, p. 1051.
Kuhrmann, M., Konopka, C., Nellemann, P., Diebold, P. and Münch, J. (aug 2015).
Software process improvement: where is the evidence? Initial findings from a
systematic mapping study. In Proceedings of the 2015 International Conference on
Software and System Process - ICSSP 2015. . ACM Press.
http://dl.acm.org/citation.cfm?doid=2785592.2785600.
Levenshtein, V. (1966). Binary Codes Capable of Correcting Deletions, Insertions and
Reversals. Soviet Physics Doklady, v. 10, p. 707.
368
Likert, R. (1932). A technique for the measurement of attitudes. Archives of Psychology,
Lupo, P. P. (2016). MPS BOK – Infraestrutura para a Construção de um Corpo de
Conhecimento em Melhoria de Processos de Software. Dissertação de Mestrado. UFRJ.
Montoni, M. A. (2010). Uma investigação sobre os fatores críticos de sucesso em
iniciativas de melhorias de processos de software. Tese de Doutorado. UFRJ.
Oliver, G. R. (2012). Foundations of the Assumed Business Operations and Strategy
Body of Knowledge (BOSBOK): An Outline of Shareable Knowledge. Darlington Press.
Ören, T. I. (2005). Toward the Body of Knowledge of Modeling and Simulation. In
Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC) 2005. .
http://www.site.uottawa.ca/~oren/pubs-pres/2005/pub-0513-MSBOK-IITSEC.pdf.
Pinheiro, G., Souza, P. J. S. De, Ronaldo, S. and Oliveira, B. (2015). Spider-
MsControl : Uma Ferramenta para Apoio ao Processo de Medição usando a Abordagem
GQIM. In Workshop Anual do MPS.
Rajaraman, A. and Ullman, J. D. (2011). Data Mining. Cambridge: Cambridge
University Press.
Richardson, W. S., Wilson, M. C., Nishikawa, J. and Hayward, R. S. (jan 1995). The
well-built clinical question: a key to evidence-based decisions. ACP journal club, v.
123, n. 3, p. A12-3.
Santos, G., Kalinowski, M., Rocha, A. R., et al. (2012). MPS.BR program and MPS
model: Main results, benefits and beneficiaries of software process improvement in
Brazil. Proceedings - 2012 8th International Conference on the Quality of Information
and Communications Technology, QUATIC 2012, p. 137–142.
Shull, F., Carver, J., Travassos, G. H., et al. (2003). Replicated Studies: Building a Body
of Knowledge about Software Reading Techniques. Lecture Notes on Empirical
Software Engineering. WORLD SCIENTIFIC. p. 39–84.
Softex (2016). Guia Geral MPS de Software. Associação para Promoção da Excelência
do Software Brasileiro – SOFTEX.
Travassos, G. H. and Kalinowski, M. (2014). iMPS 2013: Evidências Sobre o
Desempenho das Empresas que Adotaram o Modelo MPS-SW. Campinas, SP: Softex –
Associação para Promoção da Excelência do Software Brasileiro.
Turner, M., Kitchenham, B., Brereton, P., Charters, S. and Budgen, D. (may 2010).
Does the technology acceptance model predict actual use? A systematic literature
review. Information and Software Technology, v. 52, n. 5, p. 463–479.
369
SINIS – A method to support defining goals, strategies and indicators for IT
Services
Bianca Trinkenreich1, Gleison Santos1, Monalessa Perini Barcellos2

1
Programa de Pós-Graduação em Informática, Departamento de Informática Aplicada,
Universidade Federal do Estado do Rio de Janeiro (UNIRIO), Rio de Janeiro, Brasil
2
Núcleo de Estudos em Modelagem Conceitual e Ontologias (NEMO), Departamento de
Informáica, Universidade Federal do Espírito Santo (UFES), Vitória, ES, Brasil
{bianca.trinkenreich, gleison.santos}@uniriotec.br,
monalessa@inf.ufes.br
Abstract. Measurement is a key process to support organizations in

management and improvement of processes, products and services. IT services
literature states that indicators need to be aligned with goals and critical
business processes to proper support decision-making. However, IT service
departments often spend time and effort measuring without being sure about
what the measurement results represent. In this paper, we present SINIS, a
method to support defining goals, strategies and indicators for IT Services. We
designed SINIS through incremental learning cycles during multiple
qualitative studies and applied it in IT Security area of a global large
company By using SINIS, organization could better align goals, strategies and
indicators, and discard those not considered useful.
1. Introduction
A service is about delivering value to customers by facilitating results customers want to
achieve, without the ownership of specific costs and risks. IT service management is a
set of specialized organizational capabilities for providing value to customers through
services. Its practice has been growing by adopting an IT management service-oriented
approach to support applications, infrastructure and processes [TSO, 2011].
Guidance on how to develop and improve IT service maturity practices is a key
factor to improve service performance and customer satisfaction [FORRESTER et. al.,
2010) . CMMI-SVC [FORRESTER et. al., 2010) and MR-MPS-SV [SOFTEX, 2015]
models were created to attend this need and are based on more traditional models like
ITIL [TSO, 2011] and international standards such as ISO/IEC 20000 [ISO, 2001].
These models require appropriate measures to be identified to monitor various processes
executed for service delivering to customers. Thus, selection of sub-processes to be
measured must be aligned with organizational goals so measurements results are able to
deliver relevant information for decision making and business support. However, there
is no clear direction or strict suggestion about which business processes and measures
should be considered.
Considering that an indicator is a measure that embodies a strategic objective
and measures performance against a goal [BARCELLOS et. al, 2012], even having a list
of measures, it is still not easy to align them to goals and define indicators for IT
370
services [PARMENTER, D., 2015]. Alignment demands understanding stakeholders’
information needs and the way IT services processes were designed and are executed in
the organization, detecting IT services critical processes and choosing strategies that
should be followed by IT services to achieve established goals. Therefore, a method that
includes a measure database for reuse can reduce effort and speedup selection
[KANEKO et al, 2011] [JANTTI et al, 2010] [KILPI, T., 2001]. One of the seven
foundation stones that need to be laid before a successful measurement initiative is to
measure only what matters [PARMENTER, D., 2015]. In this sense, we developed
SINIS (Select Indicators for IT Services), a method to support selection of indicators for
IT services aligned with organization goals. SINIS is based on GQM+Strategies
[BASILI et. al., 2005], COBIT Goal Cascade [ISACA, 2012], business process
modeling of IT services, a list of measures for IT services [TRINKENREICH et al,
2015a] and a Reference Software Measurement Ontology [BARCELLOS et al, 2012].
In this paper we present SINIS and some relevant aspects about its development
and use. Section 2 provides a theoretical framework, Section 3 describes the followed
research method, Section 4 presents SINIS, Section 5 describes the action research,
Section 6 discusses some Related Works and Section 7 presents our final considerations.
2. IT Service Quality and Measurement

Service quality is an abstract concept due to the nature of "service" term, which is
intangible, non-homogeneous and its consumption and production are inseparable. It can
be understood as a measure about how much a service level meets or does not meet
customers’ requirements and expectations. The intangibility of services makes it
difficult to understand how customers observe and evaluate their services quality
[SOFTEX, 2015].
To offer quality, the supplier must continually assess the way in which services
are provided and what customers expect in the future. Customers will be unsatisfied
with IT service providers who occasionally exceeds expectations, but at other times they
disappoint. Measurement plays a key role in process quality improvement initiatives.
Through process and products data collection and analysis, measurements can
quantitatively demonstrate their quality and decision making support. Being able to
control and predict processes future behavior allows the supplier to increase probability
of achieving the expected IT service quality.
IT service literature does not provide a strict direction about which processes and
measures should be considered for measurement. Moreover, properly selecting measures
and indicators is not a trivial task. Even if a measures database is available, it is still not
easy to select the proper ones and identify indicators for IT services [PARMENTER, D.,
2015]. Some factors contribute to the difficulty in selecting measures and indicators for
IT services, such as: (i) lack of approaches to guide IT services indicators selection, (ii)
lack of practical examples involving IT service indicators, and (iii) lack of measurement
capabilities in IT supporting tools [JÄNTTI et al., 2010] [LEPMETS et al., 2014]. An
available list of indicators can help being a start point for insights during measurement
selection [TRINKENREICH et al, 2015a].
There are some approaches that deal with this issue. COBIT Goals Cascade
[ISACA, 2012] provides a catalog with 17 enterprise goals and IT-related goals and
371
more than 100 indicators to be reused. However, as different market situations and
environments require different measures, COBIT recommends each enterprise should
build its own cascade, compare it with COBIT and then refine it [ISACA, 2012].
Balanced Scorecard (BSC) [KAPLAN AND NORTON, 1996] applies measurement to
verify if organization activities meet its goals with respect to vision and strategy. BSC
does not provide an explicit way to define goals, strategies and indicators related to
different organizational levels, being more used at higher levels. GQM+Strategies
[BASILI et. al., 2005] is an extension of the GQM [SOLIGEN AND BERGHOUT,
1999], and takes strategies and measures as input for a model from the business level
down to project and operational levels and back up. In that sense, GQM+Strategies
focuses on filling organizations vertical gaps and helps creation of goals and strategies
and deriving indicators that are aligned with high-level business goals. It also provides a
mechanism to monitor success and failure of goals and strategies through measurement.
The main components introduced by this approach [BASILI et. al., 2005] are:
Organization goals (what the organization wants to achieve), Strategies (how to achieve
goals), Context Factors (external and internal environments), Assumptions (unknown
estimations), GQM graphs [SOLIGEN AND BERGHOUT, 1999] (how to measure if
goals were reached and strategies succeed or failed) and Interpretation Model
(consolidation of entire process of deriving business goals and GQM graphs [SOLIGEN
AND BERGHOUT, 1999].
3. The Research Method Followed to Create SINIS

Primary research approach used is Design Science Research, which is the design and
investigation of artifacts in context, designed to interact and improve something in that
context (WIERINGA, 2014). Figure 1 depicts the Design Science Research Map of this
researchThe proposed artifact is a method called SINIS, which in addition to the method
itself, provides procedures, checklists, templates and examples that help its application.
Steps followed to develop this research were:
i. Literature investigation to acquire knowledge about the research topic in order to
identify the problem and delimit the research scope;
ii. Execution of design and investigative activities in incremental learning cycles aiming
to obtain useful knowledge to develop SINIS:
ii.1. Systematic Mapping to find measures suitable for IT Services measurement
initiatives (TRINKENREICH et al., 2015a);
ii.2. Action Research about IT Services Measurement Process and Measures
(TRINKENREICH and SANTOS, 2014);
ii.3. Case Study to evaluate Measures found in by the Systematic Mapping and to
investigate impact among IT Services processes (TRINKENREICH and SANTOS,
2015a);
ii.4. Case Study about using Business Process Intelligence for critical process analysis
(TRINKENREICH et al., 2015b);
ii.5. Action Research about using critical process mapping and expected results of MR-
MPS-SV to evaluate an IT Services process and select indicators at different levels by
using GQM+Strategies (TRINKENREICH and SANTOS, 2015b);
372
ii.6. Case Study involving Qualitative Analysis to find about how operational actions,
projects or initiatives are defined to achieve IT Services indicators.
iii. Development of the first version of the proposed solution and evaluation through a
case study (TRINKENREICH et. al, 2015c);
iv. Evolution of the proposed solution and evaluation through an action research.
Requirements were established based on aspects pointed out in the literature. R1
was based on [KANEKO et al, 2011], [JANTTI et al, 2010] and [KILPI, T., 2001],
which state that indicators selection can take a long time and suggest that reusing
existent indicators can save cost and time and, also, inspire creating new ones. R2 and
R3 were defined based on [BASILI et. al., 2005], which emphasizes that measurement
must be aligned to organizational goals and that it is necessary to cover several
organizational levels to provide useful information for each one of them and for the
organization as a whole. Besides, the authors advocate the use of strategies as a way of
achieving the established goals and the implementation of a measurement system to
verify goals achievement and strategies failure or success. R4 was based on works that
recommend the use of instruments to support measurement-related activities execution.
BASILI et al. [BASILI et. al., 2005] suggest using questions for goals elicitation and
categories for classifying goals. PETERSEN et al. [PETERSEN et. al, 2015], in turn,
suggest semi-structured interviews as a complementary way to templates and notations
for getting information regarding goals, strategies or indicators. Finally, R5 considered
the works by BARCELLOS et al. [BARCELLOS et al, 2012], which discuss problems
in measurement terminologies and point out the need of using a consistent terminology
to promote common understanding.
373
Figure 1 - Design Science Research Map and Dissertation Structure (based on [31])
4. SINIS – A method to support defining goals, strategies and indicators for

IT Services
SINIS is a method to help organizations in defining goals and indicators for IT services
in alignment to business goals. By doing that, the method provides information about
strategies, projects, initiatives or actions that contribute to goals achievement. As
discussed in the previous sections, SINIS reuses knowledge provided by other proposals
and it is mainly based on the GQM+Strategies (BASILI et al., 2005) and COBIT Goals
Cascade [ISACA, 2012]. SINIS consists of a process containing a set of activities to be
accomplished to select relevant IT service indicators, and a set of templates, checklists
and examples to support activities execution. Figure 2 shows a summarized overview
of SINIS, composed of four phases. As follows we describe SINIS phases and activities.
[TRINKENREICH et.al, 2015c]
(i) Elicit IT Services Context Factors and Assumptions: Both IT Service Goals and
Strategies are defined in organization context, where options are limited by organization
specific capabilities, issues or constraints. We start method by collecting context factors
and assumptions for specified organization, to use them since the beginning for aligning
IT service goals and strategies [BASILI et. al., 2005]. Context factors are aspects
factually known (e.g., organization X needs to improve service availability) and
assumptions are aspects believed to be true but have little or no evidence about (e.g., in
374
organization X IT Services costs cannot be increased). Organization's business plans and
current budget, goals and objectives set by business, targets and thresholds to maintain
or achieve service levels and service level agreements are some of the various sources of
information that are relevant to IT Services measurement process [BROOKS, P., 2006].
Several sources can be used as critical success factors, vision and mission statements,
organizational goals, internal and external constraints, market trends, opportunities, staff
competences, technological advances, contacts and infrastructure. If documents are not
available, meetings with organization stakeholders can be used to gather information.
Figure 2 - SINIS
(ii) Review and Define IT Service Goals: This phase concerns about gathering, creating
and reviewing IT services goals based on the organizational goals. Moreover, it
addresses the definition of indicators to monitor the identified IT service goals. If
Organization does already have a list of existent IT Service Goals and just need to
associate indicators to goals, goal are gathered and reviewed. If not, they are defined. IT
service goals should be defined to be Measurable and Achievable [BASILI et. al., 2005],
and also Specific, Relevant and Time Sensitive, following all five SMART principles
[DRUCKER, P., 1954]. Goals cannot be broad or vague, need to be broken down into
specific results, written using words that clearly describe results that are trying to be
achievable, which are going to be evidenced by indicators results [BARR, S., 2014].
During this activity, context factors and assumptions are used to support definition of IT
Services goals. To reduce effort, saving cost and time, reuse is supported by consulting
COBIT IT-related goals [ISACA, 2012] to verify whether they are applicable or can
inspire new ones. Template is based on GQM+Strategies [BASILI et. al., 2005] and also
requires information regarding the BSC dimensions related to the recorded goal. BSC
dimensions were included in the template mainly because next activities involve
searching for COBIT management practices and indicators, and COBIT Cascade Goals
considers goal classification per BSC dimension.
(iii) Review and Define Indicators for IT Service Goals: During this phase, all
indicators in use by organization are listed and briefly described to provide an initial
375
understanding about their meaning. Indicators can be rewritten to have a clearer
meaning and those ones not associated to any goal are discarded. Considering that
indicators are already being collected and analyzed, data should be gathered from
existent measurement documentation and meetings. If needed news indicators to
measure a service goal achievement must be defined.
(iv) Review and Elicit Strategies to Achieve IT services goals: This phase concerns on
providing strategies to achieve IT service goals. If the organization already has a list of
existent IT service strategies, projects, initiatives or operational actions planned or in
course to achieve IT services goals, they are gathered and reviewed. This activity can be
executed by documentation analysis and open interview meetings with IT Services
department manager and team. If not, they are going to be defined.
SINIS uses critical IT services process analysis to support definition of strategies
to achieve IT service goals. Processes identified in last phase as being related to IT
service goals are mapped and analyzed to find the critical processes to be focused by
strategies. Besides the processes themselves, relationships between it and other
processes are analyzed to help finding cause and effect for difficulties that the
organization is having to achieve IT service goals.
Root cause analysis, sensitivity analysis, or process performance model can help
to identify sub-processes that contribute the most to achieving goals (FORRESTER et.
al., 2010). For example, if we need to reduce incident resolution time, besides doing
process quality investigation, it would be useful to check incidents reports. Like that it
would be possible to get which applications are causing the largest number of incidents,
or incidents that had taken longer to be solved, to be addressed first. Since the use of
Pareto diagrams is related to a known list of causes, problem and causes must be defined
first.
Considering results of root-cause for qualitative processes analysis, strategies are
established to achieve the IT Service goals. Established strategies will be implemented
in projects, initiatives or even simple activities. General context factors and assumptions
for IT Services were defined in SINIS’ first activity. Now we elicit specific context
factors and assumptions for strategies, and compare them with general context factors
and assumptions to check if there is any incoherence that needs to be adjusted.
(v) Review and Define Indicators for IT Service Strategies: Similarly to activity (iii)
Review and Define Indicators for IT Service Goals, strategies are made measurable by
specifying appropriate questions and measurement plans to define indicators and how
their data collection must be performed. Analogously to the cited activity, to reduce
effort, saving time and cost, reuse is supported by consulting two sources: COBIT
Process sample measures and IT Services list of measures to verify whether they are
applicable or can inspire new ones. During this phase, all indicators in use by the
organization to measure IT Service for Strategies are listed and described. Indicators can
be rewritten for clearer meaning and those not associated to any goal are discarded. If
organization finds that any new indicator is needed to measure a strategy achievement,
they must be defined.
(vi) Define Interpretation Models for IT Service Goals and Strategies Indicators:
During this phase, Interpretation models are defined to determine how data collected for
376
the defined indicators should be interpreted to support informed decisions about
strategies and IT services goals achievement. Targets can be defined based on previous
service level agreement contracts and reports or business’s needs. Some aspects that can
be considered when defining Interpretation Models are expected result for this indicator
to achieve related goal, between which range is the result considered as achieved, if the
result is up/below the range considered as achieved, should it be interpreted as good or
bad, how/when should the indicator be interpreted.
(vii) Build, review and adjust GQM+Strategies Grid: During this phase, context
factors, assumptions, goals, strategies and indicators are organized in a GQM+Strategies
grid aiming to provide an overview of IT services measurement and help validation and
identification of review needs. Ideally, the grid must present the cleanest possible view.
We provide SINIS template grid in Figure 2. We designed the template in a way to
facilitate viewing different levels goals, strategies and indicators in a single page. In
addition, general context factors and assumptions were disposed in this same single
page, allowing to verify if they are current or changed. If it is necessary to change
context factors and assumptions, the grid provide an easy view of goals, strategies and
indicators that are impacted by the changes and might change. Although using the
template we can show the grid in a single page, if there are many context factors,
assumptions, goals, strategies and indicators and it is not viable to represent them in a
single page, they can be organized in more than one by following the same proposed
structure.
Figure 2 - SINIS template for GQM+Strategies grid [TRINKENREICH et.al, 2015c]
GQM+Strategies Grid and Interpretation Models must be presented to all

stakeholders through meetings in which information sources, context factors and
assumptions must be validated, and applicability, completeness, accuracy and
consistency of goals, strategies and indicators must be evaluated. Also, discussions can
point out potential findings and improvement opportunities. It is recommended to
include people who were not involved in SINIS application, but will be eventually
involved in established strategies, executing or being impacted by execution or results.
During this phase, if any definition needs to be adjusted, it is possible to get back to
where is necessary to make changes and then continue following method from that point
until the end again. For example, if an IT service goal needs to be changed, the related
measurement plan needs to be adjusted to reflect changes, respective interpretation
model, and also strategies created to attend that goal need to be revisited (and of course
377
respective measurement plan and interpretation models). Which mean that traceability is
done to keep everything consistent after a change.
5. Applying SINIS through an Action Research Action research (AR) is an

approach to take action and also build knowledge about that action. An Action Research
cycle is composed by a preliminary phase to understand context and objectives; a main
stage to collect, validate and analyze data, plan, implement and evaluate actions; and a
central phase to monitor all the work [COUGHLAN AND COUGHLAN, 2002].
5.1. Action Research Motivation and Preliminary Phase

This preliminary phase aimed at identifying the research context and purpose. This work
took place within IT Security department of a large global organization A. IT Security
Department provides IT services for all other departments of organization following
ITIL practices [TSO, 2011]
IT Security department scenario motivated the SINIS evolving, since the first
version was not completely suitable for an organization that had already started
measurement. SINIS was created to allow IT Services departments review existent
indicators, goals and strategies and discard indicators and strategies not aligned to goals,
reducing waste of time and cost. IT Security manager informed his team spend too much
effort to perform measurements not aligned to strategic organizational goals. Thus, team
members didn’t know why they are spending so much time on measurement activities
and were losing motivation and trust on measurement results. Although the team had a
large list of measures collected, members didn’t know how these measures were related
to the any goal, and neither how to interpret measurement results.
The researcher that conducted the action research study works in the IT Services
directory but in Hosting department, a different subarea, being external to the context.
The following phases proposed by Action-Research method were performed: data
gathering, feedback and analysis; action planning, implementation and evaluation.
5.2. Action Research Main Phase

This study attended a request from the IT Security manager to review existent
indicators. At that time, researcher had created first version of SINIS and was studying
possible improvements to SINIS. Data gathering, actions planning and execution will be
distributed through SINIS procedures as follows. Feedback and lessons learned will be
presented in Action Research Feedback and Lessons Learned section.
(i) Elicit IT Services Context Factors and Assumptions: Relevant context factors and
assumptions were identified from organizational goals and provided department
documents. Context factor 1 was that Organization A first goal is to reduce costs.
Related assumption was that IT Security cannot increase costs. Context factor 2 was that
IT Security Area does not have people dedicated to measurement activities, and related
assumption was Members of IT Security area will responsible for collecting and storing
data for indicators and present results in weekly meeting to manager.
(ii) Review and Define IT Service Goals: IT Security area did not have a list
documented IT services goals. IT Security manager wanted the team to define their own
IT security goals and review existent indicators, and present him to validate. The team
378
was not used to think about goals, they were used to collect and report operational
measures. There was not a list of IT Service Goals to be used and there were defined.
This was the longest activity because team was not used to think about goals. SINIS
questions to support elicitation of IT Service Goals were used to guide brainstorms and
10 IT services goals were documented: Reduce the cost with IT Security incidents
solution; Reduce the resolution time for IT Security incidents; Increase efficiency in
controls execution; Reduce number of users with elevated access to Internet; Increase
efficiency of blocking malware messages; Reduce the number of users with SAP SOD
conflict; Increase IT Security team productivity; Maintain applications adherence to IT
Security policies; Increase vulnerability detection and remediation and Increase
efficiency of workstations and servers protection. An example of one of those IT
services goals created was “Reduce the Cost with IT Security Incidents Solution”.
(iii) Review and Define Indicators for IT Services: IT Security coordinator provided a
list of 39 existent measures being collected in the department at the time, with no
measurement plan or interpretation model. Although IT Security coordinator called this
list as Indicators List, it should be a Measures List, as there was not any alignment
between measures and goals. Next step was to find connection between each indicator
and an IT Service Goal. One example of how association was the indicator “Manual
resolution rate” associated to IT security goals “Reduce the cost with IT Security
incidents solution” and “Reduce the Resolution Time for IT Security Incidents”.
Indicators and goals were reviewed to discard those ones not associated to any goal.
Seven indicators without any associated goal were discarded, no longer measured and
existing indicators were renamed and documented following SINIS template.
(iv) Review and Elicit Strategies to Achieve IT Service Goals: IT Security coordinator
did not have a list of documented strategies being executed to achieve IT services goals.
The researcher considered this as expected, because the team did not have a defined list
of goals to be achieved. The process mapping for processes related to IT services goals
was the first step carried out in this activity. IT services goal indicator “Percentage of
antivirus incidents where field intervention was necessary to solve the issue
(manual/total)” was selected to have strategies defined during this research.
By using process mapping, we could already find that incident manual resolution
happens when IT Security is not able to automatically remove a threat and neither
remotely solve it. Those two are the unwanted conditions to be focused during root-
cause analysis. According to investigation, cause of not being able to perform remote
access is related to an error default installation of users’ workstations, which is missing
to enable Remote Procedure Call. Root-cause was focused by strategies in next activity.
The antivirus expert informed he contacted the area responsible for installing
users’ workstations about the issue and the strategy will consist of providing (i) a new
installation image, and (i) a script to enable and start Remote Procedure Call in every
restart s. Strategy was documented following SINIS Template for Strategies
(v) Review and Define Indicators for IT Service Strategies: Information needed was
number of times that remote support was not done in default workstations caused by
Remote Procedure Call not being enabled. COBIT Process sample measures and IT
Services list of measures were consulted, but there was no available measure for reuse.
379
(vi) Create or Review Interpretation Models for all Indicators: Interpretation models
for related indicators were created, as shown in Table 6, to determine how collected data
should be interpreted and drive decision-making.
Table 6 - SINIS Interpretation Model for IT Services’ Goal and Strategy Indicators
SINIS Interpretation Model for IT SINIS Interpretation Model for
Services’ Goal Strategy Indicator
Indicator Percentage of antivirus incidents where field Percentage of manual antivirus incidents
related intervention was necessary to solve the issue where remote support failed due to
(manual/total) Remote Procedure Call was not enabled
Target 20% 10%
Range Reduction Reduction
Baseline 60% last year 40% last year
Model If value is 5% over target, only verify isolated If value is 5% over target, only verify
cases. If value is more than 6% over target, isolated cases. If value is more than 6%
review root-cause and strategies in place. over target, review implemented strategy.
Responsible IT Security antivirus responsible IT Security antivirus responsible
Moment Every month, starting one month after End Every month, starting one month after End
User team completes strategy User team completes strategy
Periodicity Every month, current value is compared to Every month, current value is compared to
target and to previous month as a reference. In target and to previous month as a
the end of the year, total value is compared to reference to verify if strategy was
total value in the previous year. successful.
(vii). Build, review and adjust GQM+Strategies Grid: The researcher organized
context factors, assumptions, goals, strategies and indicators in a GQM+Strategies grid
and presented it to all IT Security team to gather members’ opinion and concerns and
extend the work to all other indicators with respective responsible (Figure 3).
Figure 33 - GQM+Strategies grid
5.3. Action Research Threats to Validity

We now discuss some threats to validity, following concepts of Conclusion Threats,
Internal Threats, Construction Threats and External Threats [WOHLIN et al., 2012].
An external threat is about the number of cases we applied the method. SINIS was
applied in only two scenarios: First version was applied in IT Infrastructure department
380
(TRINKENREICH et.al, 2015c), we have evolved based on feedbacks and presented the
second version in this paper, applying to IT Security department. This can affect
generalizing results as SINIS was not applied to several scenarios. The manager had a
short due date given by director and IT Security team did not have enough available
time to completely execute SINIS. Only one strategy and respective indicator and
interpretation model were created during the experience. During process mapping,
Measurement, Method and Manpower causes were not investigated. This was
considered an internal threat because the moment when researcher applied the method to
IT Security team could be not very appropriated, as the team was on a rush to review
indicators as requested by director. A conclusion threat was related to researcher. Even
being another department, she works in the same Organization, and so has already a
previous knowledge about business goals and general processes and also could have
manipulated any data. In order to minimize those threats, we have fully created an
interpretation model for selected strategy indicator and related IT Service goal, IT
Security members learned about SINIS concepts and procedures to replicate and define
for all others indicators. Besides that, SINIS includes instruments (procedures,
checklists, templates and examples) to guide execution by other researchers, being
possible to replicate results in other Organizations by other researchers. An internal
threat was about defining targets for indicators. IT Security manager asked the team to
decide about indicators targets. The usage of indicators’ targets was a new concept for
IT Security members and they were afraid of increasing workload. In order to minimize
this threat, IT Security manager decided to review targets and to use this opportunity to
discuss workloads with the team. A construction threat was about using COBIT Goals
Cascade. Examples for reuse were consulted but not used, so we could validate if they
are really useful or can provide insights and reduce time during indicators selection.
5.4. Action Research Feedback and Lessons Learned

IT Security coordinator was stated that after IT Security team is now more dedicated to
measurement activities, as they understand the relationship with IT services goals. Also,
he informed that interpretation models and strategies were new concepts for him and for
the team, and that team was motivated to complete the creation of respective indicators
(following what was done by the antivirus responsible), although he showed concern on
the amount of required time to dedicate on that.
During the case study the researcher observed positive and negative lesson learned.
Although reusing IT services goals provides inspiration for an organization not used to
think about goals to be achieved, searching a catalog wasis not effective for an
organization withthat does already have a large list of measures in place and needings
to reduce time and cost during indicators selection. Having root cause investigation to
derive goals in strategies is effective to select actions that can directly solve issues,
instead of working in many possible (and not targeted) initiatives. But SINIS do not
explicitly support choosing the most suitable root-cause technique. Therefore, future
SINIS versions should contemplate it. We found that SINIS templates and examples
helped and saved execution time, but more information might be needed for a person
not very familiar to IT services process when applying SINIS data collection. As future
work, we intend to create checklists and a case tool with forms based on templates and
tips based on those checklists and examples to facilitate following SINIS procedures.
381
6. RELATED WORKS
COBIT Goals Cascade provides a large catalog of goals and indicators to be reused for
IT Services organizations. However, COBIT Goals Cascade recommends that each
organization should build its own goals cascade, compare it with COBIT Goals
Cascade’s and then refine it [ISACA, 2012], and does not provide a mechanism to drive
this building. SINIS is covering this gap by providing procedures, checklists, templates
and examples to be followed for an IT Services organization to define its own goals and
indicators, while accessing COBIT Goal Cascade catalog for reuse. GQM+Strategies
indicates that goals, measures and strategies should be aligned and modeled in a grid is
to support making goals and strategies explicit for an organization and to provide a clear
correlation of all measurement initiatives [BASILI et al., 2005]. However,
GQM+Strategies does not detail how to identify critical processes to be considered in
strategies or how to define proper strategies and measures. SINIS is covering this gap by
providing analysis of critical processes, which includes mapping and identifying critical
sub-processes in processes related to IT services goals and finding root-cause for issues.
We could not find an approach that instantiates building GQM+Strategies grid
specifically for IT Services with a macro-process, procedures, checklists, templates and
examples like SINIS, but there are other researches that also apply GQM+Strategies and
discuss gaps that were addressed by SINIS. There are some proposals that although not
devoted to IT services, can be used in this context. LÓPEZ et al. (2016), KANEKO et
al. (2011) provide lessons learned, results and experiences from applying
GQM+Strategies approach in industry, but authors did not suggest any kind of method,
neither procedures to be used when applying GQM+Strategies to other cases.
ASGHARI (2012) used action research and proposed an elicitation approach to support
collecting information for goals and strategies to apply GQM+Strategies in an
organization. Author considered that there is a need to conduct more empirical research
on GQM+Strategies as the approach so far was evaluated in few cases.
Even not related to GQM+Strategies, we could not find many other researches
that also address selection of indicators for IT services measurement. A framework for
measuring IT services was presented by LEPMETS et al. (2011) and validated in
industry [LEPMETS et al., 2014], but only a catalog is provided, not a method to define
and select measures, and align them to business goals. Authors state that alignment
between business objectives and IT services industry needs to be studied and could
provide additional support for their framework. JÄNTTI et al. (2011) presented a
support system to IT Services Measurement. In addition to a well-designed and easy to
use measuring tool, there is a need for a systematic measurement process, and measures
need to be based on business goals.
7. FINAL CONSIDERATIONS
This paper presented SINIS, a method to help organizations select indicators for IT
services in multiple levels in alignment to business goals and to support organizations
on measuring only what matters, abandoning ineffective measurements. SINIS can be
used either when organization has an existent group of indicators in place or not. When
it has , SINIS can support to review and align those indicators to goals, and then be able
to report correct data to the more appropriated stakeholder for decision-making.
382
SINIS was applied to IT Security area of a global large company in which a large
set of measures was being collected, but the manager was not sure about their utility in
decision-making. Research question “How to support alignment of IT services
indicators with organization goals to measure only what really matters?” was answered
by using SINIS, because IT Security area could better understand and document
indicators, associate them to business goals and strategies, discard those ones that were
not considered useful, create new ones, building the GQM+Strategies grid. Even having
only one experience and not being able to statistically and effectively prove SINIS
applicability, there is evidence that the method is able to provide support during
indicators definition for IT Services departments. Researcher collected lessons learned
to validate some decisions about SINIS procedures and improve SINIS in future.
Acknowledgements
Authors thank CAPES, FAPERJ (E-26/210.643/2016, E-211.174/2016), CNPq (Process
461777/2014-2) and UNIRIO (project PQ-UNIRIO 01/2016 and 01/2017) for their
financial support.
References
BARCELLOS, M. P., FALBO, R.D., ROCHA, A.R., 2012, “Using a Reference Domain
Ontology for Developing a Software Measurement Strategy for High Maturity
Organizations” 16th IEEE International Enterprise Distributed Object Computing
Conference p.114
BARR, S., 2014, “Practical Performance Measurement Using the PuMP Blueprint for
Fast, Easy and Engaging Performance Measures
BASILI, V., TRENDOWICZ, A., KOWALCZYK, M., HEIDRICH, J., SEAMAN, C.,
MÜNCH, J., ROMBACH D., 2005, “Aligning Organizations Through
Measurement - The GQM+Strategies Approach” Springer
BROOKS, P., 2006, “Measures for IT Service Management”. Van Haren, UK
COUGHLAN, P., COUGHLAN, D., 2002 “Action research for operations
management”. International journal of operations & production management, v22
DRUCKER, P. F., 1954, “The Practice of Management”. Harper Collins, New York
FORRESTER, E., BUTEAU, B., SHRUM, S., 2010, “CMMI For Services, Guidelines
for Superior Service. CMMI-SVC Version 1.3”, - 2nd Edition. SEI. Addison-
Wesley Professional
JÄNTTI , M., LAHTELA, A., KAUKOLA, J., 2010, “Establishing a Measurement
System for IT Service Management Processes: A Case Study”. International
Journal on Advances in Systems and Measurements, vol 3 no 3 & 4
KANEKO, T., KATAHIRA, M., MIYAMOTO, Y., KOWALCZYK, M., 2011,
“Application of GQM+Strategies in the Japanese Space Industry” International
Workshop on Software Measurement
KAPLAN, R., NORTON, D.P., 1996, “The Balanced Scorecard Translating Strategy
Into Action”. Havard Business School Press, Boston
383
KILPI, T., 2001, “Implementing a software measures program at Nokia”, IEEE
Software. Volume18, issue 6, pp. 72–77. ISSN: 0740-7459
LEPMETS, M., RAS, E., & RENAULT, A., 2011, “A Quality Measurement Framework
for IT Services”. In Annual SRII Global Conference, San Jose, CA. pp. 767-774
PARMENTER, D., 2015, “Key Performance Indicators – Developing, Implementing
and Using Winning KPIs” 3rd Edition Wiley
PETERSEN, K., GENCEL, C., ASGHARI, N., BETZ, S., 2015, An elicitation
instrument for operationalizing GQM+Strategies (GQM+S-EI)”. Empirical
Software Engineering, vol. 20 no. 4
SANTOS, THIAGO MARCONDES, 2015, “Computação Ubíqua para apoiar a
educação musical: explorações com o Makey Makey”. Master Degree
Dissertation, UNIRIO. 195pp.
SOFTEX, 2015. “MPS.BR – Guia Geral MPS de Serviços”. www.softex.br
TSO. ITIL Service Operation, 2011.
TRINKENREICH, B., SANTOS, G., 2014, “Evaluation of measurement process for
incidents, continuity and availability management under the light of MR-MPS-SV
maturity model”, 10th Annual workshop for software and services Quality
improvement (WAMPS), Campinas, Brazil
TRINKENREICH, B., SANTOS, G., BARCELLOS, M., 2015a, “Measures to Support
IT Service Maturity Models – A Systematic Mapping Study”, 17th International
Conference on Enterprise Information Systems (ICEIS), Barcelona, Spain
TRINKENREICH, B., SANTOS, G., 2015a “Measures to Support IT Service Maturity
Models – A Case Study”, 17th International Conference on Enterprise
Information Systems (ICEIS), Barcelona, Spain
TRINKENREICH, B., SANTOS, G., CONFORT, V., SANTORO, F., 2015b, “Toward
using Business Process Intelligence to Support Incident Management Measures
Selection and Service Improvement”. 27th International Conference Software
Engineering Knowledge Engineering, Pittsburg, USA
TRINKENREICH, B., SANTOS, G., 2015b, “Evaluation of incident management
process under the light of MR-MPS-SV maturity model and measurement to
support IT Service quality improvement”, 14th Software Quality Brazilian
Conference (SBQS), Manaus, Brazil
TRINKENREICH, B., SANTOS, G., BARCELLOS, M., 2015c, “SINIS - A Method to
Select Indicators for IT Services”, 16th International Conference on Product-
Focused Software Process Improvement (PROFES), Bolzano, Italy.
WOHLIN, C., RUNESON, P., HÖST, M., REGNELL, B., WESSLÉN, 2012.
Experimentation in Software Engineering, Springer, ISBN: 978-3642290435.
384
Medidas para Avaliação da Manutenibilidade do Modelo de
Features de Linhas de Produto de Software Tradicionais e
Dinâmicas
Carla I. M. Bezerra 1,2,3 , Rossana M. C. Andrade 1,2∗, José Maria Monteiro 1
1
MDCC – Mestrado e Doutorado em Ciências da Computação
Universidade Federal do Ceará (UFC) Fortaleza – CE - Brasil
2
GREat - Grupo de Redes de Computadores e Engenharia de Software
3
Campus Quixadá - Universidade Federal do Ceará (UFC)
carlailane@ufc.br, rossana@ufc.br, monteiro@dc.ufc.br
Abstract. This research aims to investigate the feature models maintainability

and to propose solutions to evaluate using measures. To do that, it is necessary
to built a quality measures catalog and, to support the catalog usage, to develop
a tool, which allows the automatic collection of measurements belonging to this
catalog. To validation was realized an exploratory study that investigates the
impact of the feature models evolution in the maintainability of these models; an
exploratory case study that explores the relationships among the maintainability
measures; and a study for aggregating measures, especially related to DSPLs,
using fuzzy logic. The results of this thesis suggest the quality measures can be
effectively used to support the feature models maintainability.
Resumo. Este trabalho tem por objetivo investigar a manutenibilidade e pro-

por soluções para avaliar o modelo de features utilizando medidas. Para atingir
esse objetivo, foi elaborado um catálogo de medidas de qualidade de manuteni-
bilidade, e para apoiar o uso do catálogo, foi desenvolvida uma ferramenta,
que permite a coleta automática de medições pertencentes a este catálogo.
Para validação foi realizado um estudo exploratório que investiga o impacto
da evolução dos modelos de features na manutenibilidade; um estudo de caso
exploratório efetuado com o intuito de explorar os relacionamentos entre as me-
didas de manutenibilidade; e um estudo com o propósito de agregar medidas,
relacionadas à LPSDs, por meio da utilização de lógica fuzzy. Os resultados
desta tese sugerem que as medidas de qualidade podem ser efetivamente utili-
zadas para apoiar a avaliação da manutenibilidade de modelos de features.
1. Introdução
O paradigma de Linha de Produtos de Software (LPS) tem sido considerado, tanto
pela indústria quanto pela academia, uma estratégia eficiente para lidar com as di-
ferentes necessidades dos usuários, uma vez que torna possı́vel personalizar um
produto de software por meio da seleção das variabilidades antes mesmo da sua
implantação. Todavia, as aplicações sensı́veis ao contexto e/ou baseadas em computação
∗
Bolsa de pesquisa - DT Level 2, financiada pelo CNPq
385
ubı́qua/pervasiva requerem variabilidades dinâmicas, ou seja, resolvidas em tempo de
execução [Hallsteinsen et al. 2008]. Neste cenário, surgiu o paradigma denominado Li-
nhas de produtos de software dinâmicas (LPSD) [Hallsteinsen et al. 2008]. Uma LPSD
tem por finalidade produzir software capaz de se adaptar de acordo com as necessidades
de usuários e restrições de recursos em tempo de execução. As LPSDs podem vincu-
lar pontos de variação quando o software é iniciado para se adaptar ao ambiente (con-
texto) atual, bem como durante sua operação para se adaptar às mudanças no ambiente
[Capilla et al. 2013]. Desta forma, LPSDs podem apresentar caracterı́sticas de sistemas
autônomos, autoadaptáveis ou sensı́veis ao contexto.
Um dos importantes ativos de uma linha de produto é o modelo de features1 .
Este modelo representa as features do domı́nio e a variabilidade da linha. Já as features
descrevem as funcionalidades e as caracterı́sticas de qualidade de um produto de software.
Desta forma, Um modelo de features modela todos os produtos possı́veis de uma LPS
[Benavides et al. 2010]. Por outro lado, uma LPSD deve ser ciente do estado de um
ambiente (contexto), percebendo suas mudanças. Por este motivo, os modelos de features
de LPSDs devem representar também a variabilidade dinâmica. Neste cenário, o modelo
de features de LPSDs envolvem a definição das features de contexto e das restrições de
contexto [Capilla et al. 2014].
A avaliação da qualidade é uma atividade essencial em uma linha de produtos, uma
vez que um erro ou inconsistência em um artefato pode ser propagado para todos os seus
produtos [Montagud and Abrahão 2009]. No entanto, a avaliação da qualidade de todos
os artefatos e produtos de software de uma determinada linha revela-se impraticável, tanto
por razões econômicas quanto pelo esforço necessário [Etxeberria and Sagardui 2008a].
Desta forma, uma alternativa eficiente e econômica consiste em avaliar somente os ar-
tefatos mais relevantes. Neste sentido, como o modelo de features é um dos principais
artefatos de uma linha de produto, avaliar a sua qualidade torna-se de fundamental im-
portância. Por outro lado, uma estratégia bastante popular para avaliar a qualidade de
um produto (i.e., software) consiste na utilização de medidas. Uma medida é o mapea-
mento de uma entidade para um número ou um sı́mbolo com o objetivo de caracterizar
uma propriedade da entidade [ISO/IEC 2014]. Vale destacar que a avaliação da qualidade
do modelo de features em LPSDs envolvem uma maior complexidade, por ser necessário
modelar e representar as diversas adaptações de contexto, as features de contexto e as
restrições relacionadas a esses contextos.
Recentemente, diversos trabalhos têm discutido e apresentado medidas para a
avaliação da qualidade do modelo de features em LPSs [Thörn 2010, Bagheri 2011,
Montagud et al. 2012, Berger 2014]. Contudo, na maioria desses trabalhos, as definições
das medidas apresentam diferentes problemas, tais como: ausência da fórmula de cálculo,
falta de uma semântica clara, entre outros. Além disso, essas medidas foram avaliadas a
partir de sua aplicação em um número pequeno de modelos de features. Já no contexto
de LPSDs, poucos trabalhos têm sido propostos com o objetivo de indicar medidas para
a avaliação da qualidade do modelo de features [Bagheri 2011, Montagud et al. 2012,
Berger 2014]. Porém, as poucas medidas propostas para LPSDs apresentam os mesmos
1
Neste trabalho a palavra “feature model” foi traduzida para “modelo de features”, e não “modelo de
caracterı́sticas”, pois como é tratado nesta tese o conceito de caracterı́sticas de qualidade, a tradução para
modelo de caracterı́sticas poderia confundir os conceitos.
386
problemas encontrados na literatura para LPSs. A maior parte dos trabalhos relaciona-
dos à avaliação da qualidade de LPSDs concentra-se na verificação e validação da vari-
abilidade dinâmica do modelo de features [Capilla and Bosch 2011, Marinho et al. 2012,
Alférez et al. 2014]. Além disso, a manutenibilidade do modelo de features é fator crı́tico.
Isso ocorre devido o domı́nio das LPSs e LPSDs se modificarem constantemente e a
mudança da estrutura do modelo de features impacta fortemente na sua manutenibilidade
[Bagheri 2011, Bezerra et al. 2013, Berger 2014]. Desta forma, foi identificada, então,
uma lacuna na área de avaliação da manutenibilidade do modelo de features em LPSs e
LPSDs.
Neste cenário, este trabalho propõe um suporte para avaliação da qualidade do
modelo de features em LPSs e LPSDs, composto por: (i) COfFEE, um catálogo de carac-
terı́sticas, subcaracterı́sticas e medidas para avaliação da qualidade do modelo de features
de LPSs e LPSDs; (ii) DyMMer, uma ferramenta para suportar a avaliação da qualidade
do modelo de features, possibilitando a coleta automática das medidas do catálogo e a
modelagem dos modelos de features de LPSDs [Bezerra et al. 2016b]; e (iii) três datasets
(AFFOgaTO, MAcchiATO, ESPREssO), com coleta das medidas em modelos de features
extraı́dos do S.P.L.O.T. e da literatura, para auxiliar na investigação da pesquisa.
Além disso, foram realizados três estudos para análise da utilização das medi-
das na avaliação da qualidade do modelo de features de LPSs e LPSDs, que são: (i)
um estudo exploratório utilizando medidas de manutenibilidade para avaliar à qualidade
da evolução dos modelos de features de LPSs [Bezerra et al. 2016c]; (ii) um estudo de
caso para investigar a aplicação das medidas de LPSs, analisando a correlação entre es-
sas medidas, agrupando as medidas e definindo thresholds para as medidas agrupadas
[Bezerra et al. 2016a]; e (iii) a agregação de medidas utilizando lógica fuzzy, gerando no-
vas medidas relacionadas ao tamanho, estabilidade, flexibilidade e dinamicidade de mo-
delos de features de LPSDs. Devido a restrições de tamanho do artigo, será apresentado
apenas o estudo (ii).
2. Fundamentacao Teórica
A avaliação da qualidade no contexto de Linha de Produto de Software é essencial, uma
vez que um erro ou uma incompatibilidade em um ativo reutilizável pode ser propa-
gado para um lote de produtos. Neste sentido, a avaliação da qualidade em LPSs pos-
sui alguns desafios que não estão presentes no desenvolvimento de software tradicional
[Etxeberria and Sagardui 2008b]. Neste contexto, muitas abordagens de avaliação da qua-
lidade em LPSs têm sido propostas ao longo dos últimos anos [Olumofin and Mišić 2007,
Benavides Cuevas et al. 2007, Kim et al. 2008, Mendonca et al. 2009, Bagheri 2011].
Montagud e Abrahão (2009) executaram uma revisão sistemática compilando
o conhecimento sobre avaliação da qualidade em LPSs [Montagud and Abrahão 2009].
Dentre os dados extraı́dos dos estudos primários identificados nesta revisão tem-se as
abordagens de avaliação da qualidade, as fases do ciclo de vida, os artefatos avali-
ados, os mecanismos usados para capturar os atributos de qualidade, o tipo de atri-
buto de qualidade avaliado, a conformidade com padrões de qualidade, o suporte a
avaliação e o procedimento de avaliação. Nesse estudo foi verificado que a maior
parte dos modelos de avaliação da qualidade se concentram na fase de arquitetura
da engenharia de domı́nio da LPS [Olumofin and Mišić 2007, Kim et al. 2008], pou-
387
cos estudos tem avaliado o modelo de features [Trinidad et al. 2008, Bagheri 2011].
Poucas ferramentas de suporte a avaliação da qualidade foram identificadas na re-
visão (e.g., [Benavides Cuevas et al. 2007, Trinidad et al. 2008, Mendonca et al. 2009]),
e algumas ferramentas identificadas apenas suportam a análise semi-automática da
avaliação da arquitetura. A maior parte dos estudos também não utiliza padrões e nor-
mas de conformidade, como o SQuaRE [ISO/IEC 2014], para avaliação da qualidade
[Olumofin and Mišić 2007, Trinidad et al. 2008, Mendonca et al. 2009].
Thüm et al. (2014) elaboraram um survey que abordam estratégias de análise
de linhas de produto de software [Thüm et al. 2014]. Nesse estudo, algumas aborda-
gens identificadas estão relacionadas à abordagens e estudos sobre testes em LPSs. Ou-
tras abordagens identificadas no survey e na literatura estão relacionadas à verificação
e análise automática do modelo de features [Benavides et al. 2010, Marinho et al. 2012,
Asadi et al. 2016]. Além disso, outros estudos identificados apresentam medidas para
avaliar o modelo de features de LPSs [Bagheri 2011, Montagud et al. 2012, Berger 2014,
Oliinyk et al. 2015, Bezerra et al. 2015].
A avaliação da qualidade em LPSDs ainda é um tema recente e possui maio-
res desafios que a avaliação da qualidade em LPSs, devido à variabilidade dinâmica das
LPSDs. Foram identificados na literatura alguns estudos que tratam da verificação das
LPSDs em tempo de execução [Pascual et al. 2015, Lochau et al. 2015]. Também fo-
ram identificados outros estudos que propuseram abordagens para o modelo de features
em LPSDs e avaliaram essas abordagens com medidas especı́ficas [Cetina et al. 2009,
Saller et al. 2013, Alférez et al. 2014]. No entanto, não foram identificadas na literatura
abordagens de avaliação da qualidade para o modelo de features de LPSDs.
3. Metodologia
A pesquisa realizada neste trabalho adota a metodologia ilustrada na Figura 1. As ativi-
dades realizadas durante a execução desta pesquisa são detalhadas a seguir:
• Estudo do Referencial Teórico: estudo dos principais conceitos relacionados a
LPS tradicional e dinâmica,modelo de features, avaliação da qualidade de produto
e medição de software.
• Definição do catálogo COfFEE: realização de uma ampla revisão da literatura
com o objetivo de identificar, classificar e catalogar medidas que têm sido utiliza-
das para avaliar a qualidade de modelos de features.
• Construção da ferramenta DyMMer e datasets: construir uma ferramenta para
a coleta automática das medidas catalogadas e desenvolver datasets para apoiar a
Figura 1. Metodologia da pesquisa
388
utilização e avaliação dessas medidas.
• Estudo exploratório sobre o modelo de features: realizar um estudo explo-
ratório sobre o impacto da evolução dos modelos de features do ponto de vista
de manutenibilidade.
• Estudo de caso exploratório para investigação do uso das medidas: realizar
um estudo de caso exploratório com a finalidade de investigar a utilização de três
técnicas de análise de dados para identificar correlações entre as medidas, agrupar
as medidas e definir limites superiores e inferiores para estas medidas.
• Agregação das medidas utilizando lógica fuzzy: realizar um estudo exploratório
que buscou utilizar Lógica Fuzzy com a finalidade de agregar medidas de qualida-
des voltadas para a avaliação da qualidade do modelo de features em LPSDs.
4. COfFEE: Um Catálogo de Caracterı́sticas, Subcaracterı́sticas e Medidas

para Avaliação da Manutenibilidade do Modelo de Features
Com o objetivo de identificar um conjunto de caracterı́sticas, subcaracterı́sticas e me-

didas de qualidade que possam ser utilizadas para suportar a avaliação da qualidade de
modelos de features em LPSs, foi realizado um mapeamento sistemático o qual foi pu-
blicado em [Bezerra et al. 2015, Bezerra et al. 2016a]. Além disso, foi realizado uma
revisão da literatura complementar ao mapeamento sistemático com a finalidade de iden-
tificar caracterı́sticas, subcaracterı́sticas e medidas de qualidade voltadas especificamente
para modelos de features de LPSDs. A partir desses dois estudos, buscou-se catalogar as
medidas de qualidade encontradas na literatura com a finalidade de suportar a avaliação
do modelo de features, além de averiguar se essas medidas possuem ou não procedimen-
tos operacionais de coleta e análise. Inicialmente foram identificadas medidas para várias
caracterı́sticas de qualidade compatı́veis com a norma SQuaRE [ISO/IEC 2014], como:
adequação funcional, manutenibilidade, usabilidade, eficiência de desempenho, portabi-
lidade, confiabilidade e segurança. No entanto, a maior parte das medidas identificadas
estavam relacionadas à caracterı́stica de manutenibilidade.
Com isso, foi possı́vel compilar um catálogo de medidas de qualidade que pode ser
utilizado na avaliação da manutenibilidade de modelos de features, denominado COfFEE
(CatalOg of measures for Feature modEl quality Evaluation), o qual é composto por
40 medidas de qualidade para caracterı́stica de qualidade de manutenibilidade. Essas
medidas foram ilustradas na Tabela 1. As medidas estão associadas à subcaracterı́sticas
de qualidade. As subcaracterı́sticas em negrito são especı́ficas do modelo de features e
foram propostas no trabalho.
As fórmulas de cálculo das 40 medidas do catálogo COfFEE são apresentadas na
Tabela 3. As fórmulas de cálculo das medidas estão descritas de acordo com as descrições
dos artigos originais.
O catálogo de medidas COfFEE é uma contribuição desta tese, e suas medidas
foram implementadas em uma ferramenta desenvolvida neste trabalho para que o Enge-
nheiro de Domı́nio possa realizar de forma automática a coleta das medidas em modelos
de features de LPSs e LPSDs para suportar a avaliação do modelo com base nas medidas
e propor melhorias no modelo. As medidas do catálogo sertão utilizadas como base para
os estudos realizados nesta tese.
389
Tabela 1. Catálogo COfFEE - Um catálogo de medidas de qualidade para suportar
a avaliação da manutenibilidade do modelo de features.
Caracterı́stica Subcaracterı́sticas Medidas

Manutenibilidade Analisabilidade Número de features folhas (NLeaf)
Complexidade Cognitiva Complexidade Cognitiva do Modelo de Features (CogC)
/ Entendabilidade
Extensibilidade Extensibilidade da Feature (FEX)
Flexibilidade Flexibilidade da Configuração (FoC)
Modularidade Features Dependentes Cı́clicas Únicas (SCDF); Features Dependentes
Cı́clicas Múltiplas (MCDF)
Complexidade Estrutu- Número de Features (NF); Número de Features Mandatórias (NM);
ral Número de Features Top (NTop); Profundidade da Árvore (DT Max,
DT Mean and DT Median); Complexidade Ciclomática (CyC); Com-
plexidade Composta (ComC); Restrições Cross-tree (CTC); Restrições
Variáveis Cross-tree (CTCV); Taxa de Conectividade do Grafo (RCon);
Densidade do Grafo (RDen); Coeficiente de Densidade da Conectivi-
dade (CoC); Número de Features Agrupadas (NGF); Número de Filhos
por Feature (BF Max)
Variabilidade Estática Número de Features Opcionais (NO); Single Hotspot Features (SHoF);
Multiple Hotspot Features (MHoF); Rigid Nohotspot Features (RNoF);
Número de Features Variáveis (NVF); Número de Configurações
Válidas (NVC); Taxa de Variabilidade (RoV); Número de Grupos Or
(NGOr); Número de Grupos XOr (NGXOr); Taxa de Features Or
(ROr); Taxa de Features XOr (RXOr)
Variabilidade Dinâmica Número de Contextos (NC); Número de Features Desativadas (NDF);
Número de Features Ativadas (NAF); Features de Contextos em
Restrições (CFC); Número de Restrições de Contexto (NCC); Número
de Features de Contextos (CF); Número de Features Ativadas por Con-
texto (AFCA); Número de Features Desativadas por Contexto (DFCA)
5. A Ferramenta DyMMer
Baseado no catálogo de medidas COfFEE, foi implementada uma ferramenta denomi-
nada DyMMer (Dynamic feature Model tool based on Measures). A ferramenta DyM-
Mer suporta a edição de modelos de features e a extração automática das 40 medidas de
qualidade que compõem o catálogo COfFEE.
A ferramenta DyMMer foi desenvolvida para extrair medidas de modelos de fe-
atures representados segundo o formato XML proposto pelo repositório de modelo de
features S.P.L.O.T. Desta forma, inicialmente, a DyMMer recebe como entrada um con-
junto de modelos de features, onde cada modelo de features é representado por um arquivo
XML. Em seguida, cada arquivo XML é processado individualmente e uma estrutura in-
terna em memória principal (objeto Java) é criada para representá-lo. Assim, para cada
modelo de features teremos um arquivo XML e uma representação interna. Utilizando es-
sas estruturas internas, a DyMMer calcula, automaticamente, para cada modelo de featu-
res, os valores das 40 medidas de qualidade presentes no catálogo COfFEE. A ferramenta
DyMMer e sua documentação estão disponı́veis on-line 2 .
As principais funcionalidades da ferramenta DyMMer ilustradas na Figura 2, são:
• Importação de um Modelo de Features: A DyMMer, diferentemente de outras

ferramentas, não foi concebida com o objetivo de ser um editor de modelos de
features, mas uma ferramenta para extração automática de medidas de qualidade.
Desta forma, a DyMMer importa modelos de features já existentes, descritos no
2
https://github.com/DyMMerProject/DyMMerV2
390
Tabela 3. Catálogo COfFEE: Fórmulas de cálculo das medidas.
Acrônimo Nome da Medida Fórmula de Cálculo
NF Número de Features Quantidade de features do modelo
NO Número de Features Opcionais Quantidade de features opcionais do modelo
NM Número de Features Mandatórias Quantidade de features mandatórias do modelo
NTop Número de Features Top Quantidade de features descendentes da raiz da árvore
NLeaf Número de Features Folhas Quantidade de features sem filhos da árvore
DT Max Profundidade Máxima Número de features do caminho mais longo a partir da raiz do modelo
de features
DT Mean Profundidade Média Número de features do caminho médio a partir da raiz do modelo de
features
DT Median Profundidade Mediana Número de features do caminho mediano a partir da raiz do modelo de
features
CogC Complexidade Cognitiva Número de Pontos de Variação
FEX Extensibilidade da Feature NLeaf + SCDF + MCDF
FoC Flexibilidade da Configuração P
NO/NF
SCDF Features Dependentes Cı́clicas (#Features participantes de restrições e que são filhas de pontos de
Únicas P
variação com cardinalidade [1..1])
MCDF Features Dependentes Cı́clicas (#Features participantes de restrições e que são filhas de pontos de
Múltiplas variação com cardinalidade [1..*])
CyC Complexidade Ciclomática Quantidade de restrições de integridade
ComC Complexidade Composta NF2 + (NM2 + 2*NOr2 + 3*NXOr2 + 3*NGF2 + 3*R2 )/9
R = NGF + CyC
NGF Número de Agrupamento de Featu- Número de agrupamentos de relações Or e XOr
res
CTCV Restrições Variáveis de Cross-Tree Número de variáveis distintas em restrições cross-tree
CTCR Taxa de Restrições Cross-Tree NFRI∗ /NF ∗ Número de features envolvidas em restrições de integri-
dade
RCon Taxa de Conectividade do Grafo Conectividade de grafo de dependência, o qual é a taxa de features que
referenciam outras features (exceto pais) em suas restrições
RDen Densidade do grafo Média do número de features não-pais que são referenciadas em
restrições
CoC Coeficiente de Densidade de Co- (Número de arestas)/NF
nectividade
NVF Features Variáveis NA + NO
SHoF Single Hotspot Features Número de features filhas de pontos de variação com cardinalidade
[1..1]
MHoF Multiple Hotspot Features Número de features filhas de pontos de variação com cardinalidade
[1..*]
RNoF Rigid Nohotspot Features P
Número de features não filhas de pontos de variação
RoV Taxa de Variabilidade (Média do número de filhas dos nós)
NVC Nùmero de Configurações Válidas Número de possı́veis configurações válidas do modelo de features
BF Max Fator de Ramificação Máximo Nùmero máximo de filhos por feature
NGOr Número de Grupos Or Número de pontos de variação com relacionamentos Or
NGXOr Número de Grupos XOr Número de pontos de variação com relacionamentos XOr
ROr Taxa de Features Or Taxa de features filhas de um relacionamento Or
RXOr Taxa de Features XOr Taxa de features filhas de um relacionamento XOr
NC Número de Contextos Número de contextos do modelo de features
NAF Número de Features Ativadas Número de features ativadas em cada contexto
NDF Número de Features Desativadas Número de features desativadas em cada contexto
NCC Número de Restrições de Contexto Número de restrições de um contexto
CF Número de Features de Contextos Número de features que estão sempre presentes nos contextos ativos do
modelo de features
CFC Features de Contextos em Número de features que estão presentes nos contextos e nas restrições
Restrições do modelo de features
AFCA Número de Features Ativadas por Número de features ativadas em cada contexto / NC
Contexto
DFCA Número de Features Desativadas Número de features desativadas em cada contexto / NC
por Contexto
formato XML definido pelo repositório S.P.L.O.T., processa esses modelos e cria,
para cada um deles, uma representação interna em memória principal.
• Visualização de um Modelo de Features: A DyMMer torna possı́vel visualizar e
analisar um modelo de features especı́fico, previamente importado. Para os mode-
391
Figura 2. Visão geral da Ferramenta DyMMER
los de features que já possuem adaptações de contextos, é possı́vel visualizar, para
cada contexto, as features ativadas e desativadas, de acordo com suas restrições.
Além de visualizar a estrutura do modelo de features, a ferramenta DyMMer per-
mite, por meio da aba de medidas, selecionar um subconjunto das medidas de
qualidades suportadas, computar e visualizar os valores dessas medidas.
• Edição de um Modelo de Features: Além possibilitar a importação e
visualização de modelos de features, a ferramenta DyMMer permite também a
edição desses modelos, tornado possı́vel, por exemplo, adicionar informações de
contexto (em modelos de features sem contexto), por meio da adição ou remoção
de features ou restrições de contexto, ou ainda pela inclusão de informações sobre
a ativação e desativação de features de contexto. Vale destacar que em LPSDs
um modelo de features pode conter um ou mais contextos. Esta funcionalidade
possibilita que o engenheiro de domı́nio possa lidar com modelos de features de
LPSDs, já que o S.P.L.O.T. não suporta a modelagem deste tipo de modelo. A
Figura 2 ilustra a edição de um modelo de features na ferramenta DyMMer.
• Exportação de Medidas: Na DyMMer é possı́vel exportar, de forma automática,
os valores das medidas de qualidade para uma planilha no formato Microsoft Of-
fice Excel. O engenheiro de domı́nio pode exportar todas as medidas de uma só vez
para um ou mais modelos de features. Essa é uma grande vantagem da ferramenta
DyMMer, pois possibilita a análise de vários modelos de features em conjunto.
A DyMMer permite também que o engenheiro de domı́nio exporte apenas um
subconjunto das 40 medidas de qualidade suportadas.
6. Datasets
Neste trabalho foram desenvolvidos três datasets de medidas de qualidade para avaliação
do modelo de features, denominados: MAcchiATO, AFFOgaTO e ESPREssO. Esses da-
tasets foram construı́dos a partir das medidas do catálogo COfFEE e de um conjunto de
modelos de features extraı́dos do repositório S.P.L.O.T [Mendonca et al. 2009] e da li-
392
teratura. Com a finalidade de apoiar a construção destes três datasets, foi desenvolvida
uma ferramenta, denominada DyMMer. A ferramenta DyMMer possibilita a edição de
modelos de features e a extração automática das 40 medidas de qualidade que compõem
o catálogo COfFEE.
MAcchiATO (MeAsures dATaset for feaTure mOdel) - tem a finalidade de su-
portar a avaliação da qualidade de modelos de features de LPSs. O dataset MAcchiATO
contém os valores de 32 medidas pertencentes ao catálogo COfFEE computadas para 218
modelos de features de LPSs extraı́dos do repositório S.P.L.O.T. Essas 32 medidas foram
selecionadas por não envolverem informações de contexto, uma vez que o objetivo deste
dataset é auxiliar a avaliação de modelos de features de LPSs, e não de LPSDs. O data-
set MAcchiATO3 está disponı́vel de forma online e pode ser utilizado gratuitamente pela
comunidade de engenharia de software.
AFFOgaTO (dAtaset For the Feature mOdel evoluTiOn) - tem por finalidade
possibilitar o estudo do impacto do processo de evolução dos modelos de features na qua-
lidade destes modelos. Por este motivo, o dataset AFFOgaTO é composto por: (i) um
conjunto de 16 modelos de features, com suas respectivas versões, obtidos a partir do
repositório S.P.L.O.T.; e (ii) uma planilha compilada contendo os valores de 21 medidas
estruturais, para cada versão de cada um dos 16 modelos selecionados. O dataset AFFO-
gaTO 4 está disponı́vel para download e pode ser usado livremente pela comunidade de
engenharia de software.
ESPREssO (mEasures dataSet for dsPl featuRE mOdel) - foi concebido para su-
portar a avaliação da qualidade de modelos de features de LPSDs. O dataset ESPREssO5
está disponı́vel online e pode ser utilizado gratuitamente pela comunidade de engenha-
ria de software. O dataset ESPREssO é composto por: (i) um conjunto de 30 modelos
de features de LPSDs, extraı́dos da literatura; e (ii) uma planilha compilada contendo
os valores de 13 medidas de qualidade, para cada um dos 30 modelos selecionados. As
13 medidas que compõem o dataset ESPREssO foram selecionadas a partir do catálogo
COfFEE, sendo 9 medidas voltadas para LPSs e 4 especı́ficas para LPSD.
7. Estudo de Caso
Um dos objetivos deste estudo de caso exploratório é investigar como as medidas de qua-
lidade do catálogo COfFEE podem ser aplicadas com a finalidade de suportar a avaliação
da qualidade do modelo de features em LPSs. Para isso, foi utilizado o dataset MAcchi-
ATO. O dataset MAcchiATO contém os valores de 32 medidas pertencentes ao catálogo
COfFEE computadas para 218 modelos de features de LPSs extraı́dos do repositório
S.P.L.O.T. Essas 32 medidas foram selecionadas por poderem ser computadas para LPSs,
foco deste estudo de caso. Esse estudo foi publicado em [Bezerra et al. 2016a], e os de-
talhes da execução do estudo podem ser consultados no artigo.
Para atingir o objetivo proposto, foram definidas três questões de pesquisa:
• QP1: Existem correlações entre as medidas utilizadas para avaliar a qualidade
dos modelos de features em LPSs? Respondendo a QP1, será possı́vel reduzir
3
http://carlabezerra.great.ufc.br/macchiato
4
https://goo.gl/gye5ma
5
https://goo.gl/ONfTL3
393
a quantidade de medidas a serem utilizadas para avaliar a manutenibilidade de
modelos de features.
• QP2: Como agrupar as medidas relacionadas? Respondendo a QP2, será possı́vel
agrupar medidas que cobrem aspectos semelhantes e, consequentemente, reduzir
a quantidade de medidas a serem utilizadas para avaliar a manutenibilidade de
modelos de features.
• QP3: Como definir thresholds para uma determinada medida? Responder a QP3
é essencial para permitir que as medidas sejam utilizadas na prática, ou seja, em
cenários reais.
7.1. Seleção dos Objetivos

A fim de especificar o contexto para a realização deste estudo de caso, foram selecionadas
as medidas de qualidade e os modelos de features a serem utilizados. Esta seleção foi
baseada no método de amostragem de conveniência [Wohlin et al. 2012], que é um tipo
de técnica de amostragem não probabilı́stica com base no julgamento do pesquisador. Este
método foi utilizado devido ao fato das medidas serem selecionadas com base em revisões
da literatura e os modelos de features terem sido extraı́dos de um repositório público.
Assim, o dataset MAcchiATO foi concebido por meio da utilização deste método.
7.2. Procedimentos para Coleta e Análise de Dados

Neste estudo de caso, foi utilizada uma combinação de dados qualitativos e quantitati-
vos, que é conhecido como método misto [Runeson 2009]. A análise dos dados é exe-
cutada de forma distinta para os dados quantitativos e qualitativos. A análise dos dados
quantitativos, em geral, envolve métodos baseados em estatı́stica descritiva e análise de
correlação. Os métodos de estatı́stica descritiva envolvem médias, desvios-padrão, his-
togramas e gráficos de dispersão, com a finalidade de facilitar a compreensão dos dados
coletados. A análise de correlação é realizada com o objetivo de descrever a forma como
uma medida se relaciona com outra. Para os dados qualitativos, o principal objetivo da
análise é extrair conclusões, mantendo uma clara cadeia de provas. Isto é, um leitor deve
ser capaz de seguir a derivação dos resultados e chegar às conclusões a partir dos dados
coletados. Além disso, os avanços das técnicas de aprendizagem de máquina e análise de
dados têm fornecido meios eficazes de extrair informações úteis e conhecimento a par-
tir dos dados. Neste estudo de caso exploratório foram utilizadas diferentes técnicas de
análise de dados, tais como: estatı́stica descritiva, análise de correlação, PCA (Análise de
Componentes Principais), além de métodos paramétricos e não paramétricos para definir
os thresholds.
7.3. Resultados
Para responder as questões de pesquisa do estudo de caso, foram obtidos os resultados
detalhados a seguir.
QP1 - Para responder essa questão de pesquisa, foi realizada a análise de
correlação utilizando o coeficiente de correlação de Spearman (com nı́vel de significância
de 0.05) para as 32 medidas do dataset MAcchiATO, normalizando os dados. A análise
da correlação entre duas medidas é importante para descobrir se estas cobrem aspectos
similares do modelo de features. Como resultado da análise de correlação, pode-se argu-
mentar que não é necessário o uso das 32 medidas, a fim de avaliar a manutenibilidade
394
do modelo feature. Seria suficiente usar o conjunto composto por 15 medidas: NF, NM,
NLeaf, NTop, DTMax, CogC, FEX, FoC, SCDF, MCDF, RDen, RoV, NVC, NGOR e
NGXOr.
QP2 - Para responder essa questão de pesquisa, foi utilizada neste trabalho a
técnica de agrupamento denominada Análise de Componentes Principais (PCA), por ser
uma técnica bastante utilizada pela comunidade acadêmica para agrupamento de dados.
Com o PCA, um número de combinações de medidas não correlacionadas são seleciona-
das para capturar informações sobre o modelo de features como um todo. PCA é um pro-
cedimento matemático que utiliza transformação ortogonal para converter um conjunto
de variáveis (dimensões), possivelmente correlacionadas, para um conjunto de variáveis
não correlacionadas linearmente chamadas de componentes principais (PCs). Como re-
sultado da execução do PCA foram selecionados 9 PCs selecionados para as 15 medidas
de qualidade selecionadas na análise de correlação. Cada PC representa o agrupamento
das 15 medidas, compondo as novas medidas agrupadas (9 PCs).
QP3 - Por último, para responder a QP3, foram definidos thresholds para cada
um dos 9 PCs selecionados. Para definir os thresholds, foi utilizada a técnica de intervalo
de tolerância. Em estatı́stica, um intervalo de tolerância é um intervalo estatı́stico em
que uma determinada proporção de uma amostra de população cai com algum nı́vel de
confiança. Assim, neste trabalho foi utilizado um intervalo de tolerância de 95%, que
é um valor tı́pico para problemas semelhantes [Altman et al. 2013]. Foram definidos o
limite superior, a média e o limite inferior de cada PC. Esses thresholds podem ajudar a
avaliações de qualidade inicial dos modelos de features em LPSs. No entanto, um valor
diferente pode ser escolhido pelo engenheiro de domı́nio (especialista em LPS).
7.4. Implicações para os Pesquisadores e Engenheiros de Domı́nio

Os resultados do estudo mostraram que as correlações entre as medidas de qualidade
existem. Assim, nem todas as medidas são necessárias para revelar as caracterı́sticas de
qualidade de um modelo de features. Além disso, as constatações obtidas neste trabalho
indicam que a técnica de PCA pode ser usada para construção de novas medidas agrupadas
mais representativas do que as medidas individuais. Finalmente, se a inspeção manual nos
modelos de features para definir thresholds não é possı́vel, estratégias centradas em dados
podem ser aplicadas. Entretanto, se os thresholds não estão devidamente definidos, é
difı́cil realmente saber se um determinado valor da medida indica um problema potencial
no modelo de features.
Uma vez que tenha sido estabelecido que as correlações entre as medidas de qua-
lidade existem, acredita-se que as abordagens de seleção de caracterı́stica podem ser usa-
das para selecionar um subconjunto de medidas relevantes de qualidade (também conhe-
cidas em aprendizagem de máquina e estatı́sticas como caracterı́stica, subcaracterı́stica
ou variável), a fim de construir um modelo (por exemplo, um modelo de previsão). As
abordagens de seleção de caracterı́stica são utilizados por três razões: simplificação de
modelos, menor tempo de treinamento e redução à sobreposição. A premissa principal
quando se utiliza uma abordagem de seleção de caracterı́sticas é que os dados contém
muitas caracterı́sticas que são redundantes ou irrelevantes, e assim pode ser removido
sem muita perda de informações, que foi exatamente o que aconteceu no estudo.
O processo de projeto e execução do trabalho de investigação necessário para
395
este estudo resultou em importantes reflexões sobre muitos aspectos da realização da
investigação empı́rica sobre o campo de LPSs. O primeiro desafio enfrentado foi obter um
conjunto de modelos de features de LPSs bem estabelecidas e acessı́veis ao público. Foi
encontrado apenas um repositório público, o S.P.L.O.T. No entanto, a maioria dos mode-
los de features compartilhados foram concebidos para fins acadêmicos e de investigação.
É fundamental reunir os modelos de features industriais e reais dentro desses repositórios
para fortalecer estudos empı́ricos futuros e avaliações. Para trabalhos futuros, o ideal se-
ria selecionar modelos de features em escala real e industriais. O segundo desafio foi no
que diz respeito à complexidade das medidas estruturais. Os resultados apoiam a ideia
de que medidas simples, que são correlacionadas com medidas complexas, são bastante
úteis para indicar atributos de qualidade externos. O terceiro desafio está relacionado com
a ausência do grau de qualidade nos modelos de features, em outras palavras, se cada mo-
delo de features tivesse, pelo menos, uma indicação de qualidade como boa ou má, seria
possı́vel usar algoritmos mais sofisticados de aprendizagem de máquina para definir os
thresholds das medidas ou classificar novos modelos de features.
Por último, de acordo com os resultados deste trabalho, não é possı́vel provar que
a melhoria da qualidade dos modelos de features implica em uma melhor reutilização de
software. Para isso, é necessário monitorar a qualidade e o nı́vel de reutilização de LPSs
reais. Além disso, este trabalho não forneceu diretrizes para melhoria da qualidade dos
modelos de features. Estes aspectos serão investigados em trabalhos futuros.
7.5. Ameaças à Validade
Validade Interna. Para aumentar a validade interna, foram coletadas todas as medidas
automaticamente utilizando a ferramenta DyMMer. Além disso, foi realizada a análise de
correlação seguindo um processo de cálculo padrão do coeficiente de correlação de Spe-
arman e foram escolhidas apenas os resultados com significância estatı́stica (p < 0,05)
para análise. No entanto, não se pode garantir que os resultados da análise do expe-
rimento deste estudo dependem de definições especı́ficas das medidas de qualidade no
catálogo COfFEE. O repositório S.P.L.O.T. possui muitos modelos de features que foram
projetados para fins acadêmicos e de investigação (exemplos fictı́cios). Este fator pode in-
fluenciar nos thresholds definidos. Além disso, as medidas no catálogo COfFEE possuem
diferentes distribuições probabilı́sticas.
Validade de Construção. A validade de construção está preocupada com a relação
entre a teoria e a observação. Neste contexto, a principal preocupação do estudo é a
redução do número de medidas de qualidade executadas na etapa de análise de correlação,
a partir das 32 medidas iniciais no catálogo COfFEE para 15 medidas. Este conjunto re-
sultante de 15 medidas de qualidade foi usado como entrada na etapa PCA. Este processo
de seleção foi realizado manualmente e com base nas subcaracterı́sticas qualidade. O
resultado de um conjunto diferente de medidas resultou em diferentes componentes prin-
cipais.
Validade Externa. Os resultados do estudo de caso válido externamente podem
ser generalizados e aplicados com segurança para a prática de engenharia de software
e serem recomendados como padrões para avaliação da qualidade do modelo de featu-
res. Para mitigar esta ameaça, foi utilizado um grande conjunto de modelos de features,
incluindo modelos de features com diferentes tamanhos e complexidades. Além disso, to-
das as medidas de qualidade utilizadas neste trabalho foram extraı́das a partir da literatura
396
existente. No entanto, os resultados dos experimentos deste estudo não são automatica-
mente transferı́veis para todos os outros datasets de modelos de features.
Validade de Conclusão. A validade de conclusão é a extensão em que as con-
clusões sobre a presença de uma relação estatisticamente significativa entre os tratamentos
e os resultados são válidos. Para mitigar as ameaças à validade da conclusão e aumentar
a confiabilidade deste estudo de caso exploratório, foi utilizada a técnica de validação
cruzada, com 10 rodadas. Esta validação é importante para avaliar como a abordagem
proposta vai generalizar para um dataset independente.
8. Conclusões
Os principais resultados desta pesquisa de doutorado foram: (i) um catálogo de medidas
de qualidade denominado COfFEE, o qual contém 40 medidas relacionadas à manuteni-
bilidade do modelo de features; (ii) uma ferramenta, denominada DyMMer, para suportar
a avaliação da qualidade do modelo de features, possibilitando a coleta automática das
medidas pertencentes ao catálogo COfFEE e a modelagem das informações de contexto
utilizadas nos modelos de features de LPSDs; e (iii) a construção de três datasets, deno-
minados AFFOgaTO, MAcchiATO e ESPREssO, que podem ser utilizados para auxiliar
a avaliação da manutenibilidade de modelos de features. Para avaliação das medidas de
manutenibilidade do modelo de features foi realizado um estudo de caso para investigar a
aplicação das medidas voltadas para LPSs, por meio da análise da correlação entre essas
medidas, agrupamento dessas medidas e da definição de thresholds para as medidas.
Como trabalhos futuros foram identificadas as seguintes oportunidades de pes-
quisa: definir uma abordagem de avaliação da qualidade do modelo de features; estender
o calálogo COfFEE para outras caracterı́sticas, subcaracterı́sticas e medidas; construir um
dataset com modelos de features de LPSs e LPSDs reais; elaborar diretrizes para melhoria
do modelo de features; e utilizar técnicas de aprendizagem de máquina para classificação
dos modelos de features.
Referências
Alférez, G. H., Pelechano, V., Mazo, R., Salinesi, C., and Diaz, D. (2014). Dynamic
adaptation of service compositions with variability models. Journal of Systems and
Software, 91:24–47.
Altman, D., Machin, D., Bryant, T., and Gardner, M. (2013). Statistics with confidence:
confidence intervals and statistical guidelines. John Wiley & Sons.
Asadi, M., Gröner, G., Mohabbati, B., and Gašević, D. (2016). Goal-oriented mode-
ling and verification of feature-oriented product lines. Software & Systems Modeling,
15(1):257–279.
Bagheri, E. e Gasevic, D. (2011). Assessing the maintainability of software product line
feature models using structural metrics. Software Quality Control, 19(3):579–612.
Benavides, D., Segura, S., and Ruiz-Cortés, A. (2010). Automated analysis of feature
models 20 years later: A literature review. Information Systems, 35(6):615–636.
Benavides Cuevas, D. F., Segura Rueda, S., Trinidad Martı́n Arroyo, P., and Ruiz Cortés,
A. (2007). Fama: Tooling a framework for the automated analysis of feature models.
397
Berger, T. e Guo, J. (2014). Towards system analysis with variability model metrics.
In Proceedings of the Eighth International Workshop on Variability Modelling of
Software-Intensive Systems, page 23. ACM.
Bezerra, C. I., Andrade, R. M., and Monteiro, J. M. (2016a). Exploring quality measures
for the evaluation of feature models: A case study. Journal of Systems and Software.
Bezerra, C. I., Barbosa, J., Freires, J. H., Andrade, R., and Monteiro, J. M. (2016b). Dym-
mer: a measurement-based tool to support quality evaluation of dspl feature models. In
Proceedings of the 20th International Systems and Software Product Line Conference,
pages 314–317. ACM.
Bezerra, C. I., Monteiro, J. M., Andrade, R., and Rocha, L. S. (2016c). Analyzing the
feature models maintainability over their evolution process: An exploratory study. In
Proceedings of the Tenth International Workshop on Variability Modelling of Software-
intensive Systems, pages 17–24. ACM.
Bezerra, C. I., Monteiro, J. M. S., and Andrade, R. (2013). Avaliação da qualidade do
modelo de Features em linhas de produto de software utilizando medidas. In Simpósio
Brasileiro de Qualidade de Software, page 15.
Bezerra, C. I. M., Andrade, R. M. C., and Monteiro, J. M. (2015). Measures for quality
evaluation of feature models. In Software Reuse for Dynamic Systems in the Cloud
and Beyond - 14th International Conference on Software Reuse, ICSR 2015, Miami,
FL, USA, January 4-6, 2015. Proceedings, pages 282–297.
Capilla, R. and Bosch, J. (2011). The promise and challenge of runtime variability. Com-
puter, 44(12):93–95.
Capilla, R., Bosch, J., and Kang, K.-C. (2013). Systems and software variability manage-
ment. Springer.
Capilla, R., Bosch, J., Trinidad, P., Ruiz-Cortés, A., and Hinchey, M. (2014). An overview
of dynamic software product line architectures and techniques: Observations from re-
search and industry. Journal of Systems and Software, 91:3–23.
Cetina, C., Giner, P., Fons, J., and Pelechano, V. (2009). Using feature models for deve-
loping self-configuring smart homes. In Autonomic and Autonomous Systems, 2009.
ICAS’09. Fifth International Conference on, pages 179–188. IEEE.
Etxeberria, L. and Sagardui, G. (2008a). Quality assessment in software product lines. In
High Confidence Software Reuse in Large Systems, pages 178–181. Springer.
Etxeberria, L. and Sagardui, G. (2008b). Variability driven quality evaluation in software
product lines. In Software Product Line Conference, 2008. SPLC’08. 12th Internatio-
nal, pages 243–252. IEEE.
Hallsteinsen, S., Hinchey, M., Park, S., and Schmid, K. (2008). Dynamic software product
lines. Computer, 41(4):93–95.
ISO/IEC (2014). Iso/iec 25000 - systems and software engineering – systems and software
quality requirements and evaluation (square) – guide to square. Technical report.
Kim, T., Ko, I. Y., Kang, S. W., and Lee, D. H. (2008). Extending atam to assess pro-
duct line architecture. In Computer and Information Technology. CIT 2008. 8th IEEE
International Conference on, pages 790–797. IEEE.
398
Lochau, M., Bürdek, J., Hölzle, S., and Schürr, A. (2015). Specification and automa-
ted validation of staged reconfiguration processes for dynamic software product lines.
Software & Systems Modeling, pages 1–28.
Marinho, F. G., Maia, P. H., Andrade, R., Vidal, V. M., Costa, P. A., and Werner, C.
(2012). Safe adaptation in context-aware feature models. In Proceedings of the
4th International Workshop on Feature-Oriented Software Development, pages 54–61.
ACM.
Mendonca, M., Branco, M., and Cowan, D. (2009). S.p.l.o.t.: Software product lines
online tools. In Proceedings of the 24th ACM SIGPLAN Conference Companion on
Object Oriented Programming Systems Languages and Applications, OOPSLA ’09,
pages 761–762, New York, NY, USA. ACM.
Montagud, S., Abrahão, S., and Insfran, E. (2012). A systematic review of quality attribu-
tes and measures for software product lines. Software Quality Journal, 20(3-4):425–
486.
Montagud, S. and Abrahão, S. (2009). Gathering current knowledge about quality eva-
luation in software product lines. In Proceedings of the 13th International Software
Product Line Conference, SPLC ’09, pages 91–100, Pittsburgh, PA, USA. Carnegie
Mellon University.
Oliinyk, O., Petersen, K., Schoelzke, M., Becker, M., and Schneickert, S. (2015). Metrics
for the evaluation of feature models in an industrial context: A case study at opel.
In International Working Conference on Requirements Engineering: Foundation for
Software Quality, pages 33–48. Springer.
Olumofin, F. G. and Mišić, V. B. (2007). A holistic architecture assessment method for
software product lines. Information and Software Technology, 49(4):309–323.
Pascual, G. G., Lopez-Herrejon, R. E., Pinto, M., Fuentes, L., and Egyed, A. (2015).
Applying multiobjective evolutionary algorithms to dynamic software product lines
for reconfiguring mobile applications. Journal of Systems and Software, 103:392–411.
Runeson, P. e Höst, M. (2009). Guidelines for conducting and reporting case study rese-
arch in software engineering. Empirical software engineering, 14(2):131–164.
Saller, K., Lochau, M., and Reimund, I. (2013). Context-aware dspls: model-based run-
time adaptation for resource-constrained systems. In Proceedings of the 17th Internati-
onal Software Product Line Conference co-located workshops, pages 106–113. ACM.
Thörn, C. (2010). On the quality of feature models.
Thüm, T., Apel, S., Kästner, C., Schaefer, I., and Saake, G. (2014). A classification
and survey of analysis strategies for software product lines. ACM Computing Surveys
(CSUR), 47(1):6.
Trinidad, P., Benavides, D., Durán, A., Ruiz-Cortés, A., and Toro, M. (2008). Automated
error analysis for the agilization of feature modeling. Journal of Systems and Software,
81(6):883–896.
Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., Regnell, B., and Wesslén, A. (2012).
Experimentation in software engineering. Springer Science & Business Media.
399
Canopus: A Domain-Specific Modeling Language
for Performance Testing
Maicon Bernardino1 , Avelino Francisco Zorzo1
1
Postgraduate Program in Computer Science – Faculty of Informatics (FACIN)
Pontifical Catholic University of Rio Grande do Sul (PUCRS)
Av. Ipiranga, 6681 – Partenon, 90619-900 – Porto Alegre – RS – Brazil
bernardino@acm.org, avelino.zorzo@pucrs.br
Abstract. Despite all the efforts to reduce the cost of the testing phase in soft-
ware development, this is still one of the most expensive phases. In order to
continue to minimize those costs, in this paper, we propose a Domain-Specific
Language (DSL), built on top of MetaEdit+ language workbench, to model per-
formance testing for Web applications. Our DSL, called Canopus, was devel-
oped in the context of a collaboration between our university and a Technology
Development Laboratory from an Information Technology (IT) company. It is
presented, in this paper, the overview of Canopus, including: metamodels, its
domain analysis, a process that integrates Canopus to Model-Based Testing,
and applied it to an industrial case study. Furthermore, we also carried out a
controlled empirical experiment to evaluate the effort (time spent), when com-
paring Canopus with another approach widely used by industry - UML.
Resumo. Apesar de todos os esforços para reduzir o custo do testes de software

na fase de desenvolvimento, esta ainda é uma das fases mais caras. Para contin-
uar a minimizar esses custos, neste artigo, propõe-se uma linguagem especı́fica
de domı́nio (Domain-Specific Language - DSL), desenvolvida usando a ferra-
menta MetaEdit+, para modelar testes de desempenho para aplicações Web. A
DSL, chamada Canopus, foi desenvolvida no contexto de uma colaboração en-
tre a universidade e um laboratório de desenvolvimento de tecnologia de uma
empresa de Tecnologia da Informação (TI). Apresenta-se, neste artigo, a visão
geral da Canopus, incluindo: metamodelos, sua análise de domı́nio, um pro-
cesso que integra a Canopus ao teste baseado em modelos, bem como sua
aplicação a um estudo de caso industrial. Além disso, realizou-se um exper-
imento empı́rico controlado para avaliar o esforço (tempo gasto), ao comparar
Canopus com outra abordagem amplamente usada pela indústria - UML.
1. Introduction
It is well-known that the testing phase is one of the most time-consuming and laborious
phases of a software development process [Yang et al. 2008]. Depending on the desired
level of quality for the target application, and also its complexity, the testing phase may
have a high cost. Normally, defining, designing, writing and executing tests requires a
large amount of resources, e.g. skilled human resources and supporting tools. In order
to mitigate these issues, it would be relevant to define and design the test activity using a
well-defined model or language and to allow the representation of the domain at a high
400
level of abstraction. Furthermore, it would be considerable to adopt some technique or
strategy to automate the writing and execution of the tests from this test model or lan-
guage. One of the most promising techniques to automate the testing process from the
system models is Model-Based Testing (MBT) [Utting and Legeard 2006].
MBT provides support to automate several activities of a testing process, e.g. test
cases and scripts generation. In addition, the adoption of an MBT approach provides
other benefits, such as a better understanding on the application, its behavior and test
environment, since it provides a graphical representation about the System Under Test
(SUT). Although MBT is a well-defined and applied technique to automate some testing
levels, it is not fully explored to test non-functional requirements of an application, e.g.
performance testing. There are some works proposing models or languages to support the
design of performance models. For instance, the SPT UML profile relies on the use of tex-
tual annotations on models, e.g. stereotypes and tagged values to support the modeling of
performance aspects of an application. Another example is the Gatling Domain-Specific
Language (DSL), which provides an environment to write textual representation of an
internal DSL based on industrial needs and tied to a testing tool.
Although these models and languages are useful to support the design of perfor-
mance models and also to support testing automation, there are a few limitations that
restrict their integration in a testing process using an MBT approach. Despite the benefits
of using an UML profile to model specific needs of the performance testing domain, its
use may lead to some limitations. For instance, most of the available UML design tools
do not provide support to work with a well-defined set of UML elements, which is needed
when working with a restricted and specialized language. Thus, the presence of several
unnecessary modeling elements may result in an error-prone and complex activity.
Most of these issues could be mitigated by the definition and implementation of
a graphical and textual DSL for the performance testing domain. However, to the best of
our knowledge, there is little investigation on applying DSL for the performance testing
domain. Therefore, it would be relevant to develop a graphical modeling language for the
performance testing domain to mitigate some of the limitations mentioned earlier. In this
paper, we propose Canopus, a DSL that aims to provide a graphical and textual way to
support the design of performance models, and that can be applied in a model-based per-
formance testing approach. Hence, our DSL scope is to support the performance testing
modeling activity, aggregating information about the problem domain to provide better
knowledge sharing among testing teams and stakeholders, and centralizing the perfor-
mance testing documentation. Moreover, our DSL will be used within an MBT context
to generate performance test scripts and scenarios for third-party tools/load generators.
Consequently, the research problem is the lack of a modeling standard and/or
language that aims at meet the particular needs of the performance testing domain for Web
applications. This way, this study seeks to research a modeling standard for performance
testing, i.e. to develop a DSL that meets the specific needs of the domain for modeling
performance testing in a Web application, as well as its use in the MBT approach. It is
highlighted that a DSL can be represented graphically, i.e. using graphs and diagrams, and
when it is applied to the context of software testing, enables the use of the MBT approach
for generating test artifacts. Hence, to formalize the exposed problem, a research question
is defined to guide the research methodology.
401
Research Question (RQ): “RQ0. How to improve model-based performance test-
ing using a domain-specific language in Web applications?”
The RQ is in line with some of the achievements, challenges, and dreams pre-
sented by Bertolino [Bertolino 2007] in the software testing research roadmap. The au-
thor asserts that both MBT and DSL are promising approaches and in actual research
expansion. Together they define the dream of test-based modeling and the proposal to
hold 100% automatic testing. Domain-Specific Testing (DST) is a defined term by the
author as an efficient solution to allow that domain experts can express abstract specifica-
tions, e.g. models or languages, to be automated in their process, having as its focus on
transforming the domain knowledge to improve the testing process.
From the industry perspective, the performance testing process is usually very ex-
pensive, regarding infrastructure resources and generation of test scenarios and scripts.
Another significant gap to be highlighted is the lack of non-functional performance re-
quirements in the system analysis, in addition to the absence of a standard documentation
among the stakeholders about the problem domain, allowing a common understanding
and interpretation of goals and aims of the system.
Regarding academia, several types of research are evolving for the purpose of au-
tomating the testing process with the aim of reducing the cost and effort applied in the
activity of the generation of test scenarios and script activities, which would consequently
improve the software quality. To support this challenge, one way to operationalize this
process is through the MBT adoption, with the intention of sharing among stakeholders
the project information regarding system behavior. Thus, it enables functional require-
ments and, mainly, non-functional performance requirements to be contemplated, anno-
tated and documented into the system models on the early cycle of software development.
1.1. Objectives
The main goal of this research is to propose a domain-specific language for modeling
performance testing in a Web application. To achieve the research goal, we derived the
following objectives: i) Deepening the background concerning models and formalisms
for performance testing; ii) Studying the models and formalisms for model-based testing;
iii) Conceiving a DSL for modeling performance testing, characterized by the follow-
ing representation factors of performance testing [Woodside et al. 2007]: a) Represent-
ing their features; b) Identifying their goals; c) Measuring their performance counters;
d) Modeling their different user profiles as well as their behavior. iv) Validating the DSL
for modeling performance testing proposed using a controlled experiment, in comparison
with usual approaches for performance modeling; v) Evaluating the DSL proposed by
professionals or expert groups in the field whereby the empirical study; vi) Documenting
and reporting the study results, publishing them in scientific conferences, in addition to
the technology and knowledge transfer to industry.
This paper is organized as follows. Section 2 describes the research methodology
applied in this study. Section 3 presents the metamodels and how they are related one
each other, as well as describes a model-based performance testing process. Section 4
shows the results of how we applied Canopus in a case study. Besides it, also reports the
outcomes of a controlled experiment. Section 5 concludes the paper with highlights of re-
search contributions, limitations, future directions, and points out academic publications.
402
2. Research Methodology
The knowledge is considered scientific if techniques that allow its verification can be
applied, i.e., determining the research methods that achieved such knowledge. We can
define a method as a way to reach a purpose. Thus, the scientific research depends on
a set of intellectual and technical procedures so that its goals are achieved, i.e., research
methodology. Hence, research methodology is a set of process and mental operations that
had to apply in the research. In that sense, this section presents a research methodology
that was planned and applied in this study developed.
This research is exploratory. Exploratory research enables to define a problem and
formulate hypotheses about the topic under study [Yin 2013]. Besides, it aims to examine
an issue or a non-studied problem, which has not been discussed previously by other
studies. Exploratory research allows the researcher to determine a set of data collection
techniques to conduct the study. In this research, we choose to use as main methods:
literature review, case study, and controlled empirical experiment. Next, we present how
each method will be applied in the context of the research design.
The research developed follows the objectives defined in Section 1. Thereby, we
classified the nature of our proposal in applied research, with a strategy quantitative of
the exploratory research type, having as its base the experimental research design. The
empirical experiment method having been applied, we follow the protocol proposed by
Wholin [Wohlin et al. 2012], using the instruments of quantitative and qualitative data
collection. For this reason, it is an experimental research, developed in a laboratory,
i.e., in vitro. The choice to apply an empirical experiment should be in fact that the
study proposal makes “how” and “why” questions, due to needs of validation of the DSL
proposed to compare its performance with other approaches already used by industry.
To develop the research project proposed, we planned a research methodol-
ogy organized in three phases: Conception, Validation, Knowledge and
Technology Transfer; according to the presented research design in Figure 1. Each
phase is described in details as follows:
(1) Conception: The first phase is divided in two blocks: Theoretical Base
and Development. The former block includes the idea definition, the research ques-
tion, as well as its strategy, the research design, besides a literature review in order to
establish the theoretical basis to main research topics such as performance test modeling,
model-based testing, and domain-specific language. This block is also responsible for
defining the requirements of the DSL, and consequently, the design decisions based on
these requirements. The latter block exerts the function to identify, analyze and imple-
ment the domain, in addition to studying the different frameworks and Language Work-
benches (LW) [Erdweg, S. [et al.] 2013] for creating domain-specific languages, and also
for elaborating the mechanisms to translate the visual model in a textual language, i.e.
the generator module; (2) Validation: The second phase is divided in two blocks:
Utilization and Experiment. The first block is responsible for applying our
DSL in two Web applications: one simple and didactic, known by academic commu-
nity, TPC-W, and the other more complex and robust, based on an industrial environment,
henceforth Changepoint. The second block is part of the validation of a proper ap-
proach. Therefore, we intend to conduct a controlled empirical experiment with inex-
perienced and experienced subjects, with the purpose to plan, execute, collect data, and
403
Figure 1. Research design
analyze the experiment results comparing our DSL with another approach applied by in-
dustry. Based on the enrollment context and the previously conducted research, we chose
comparing our DSL with the UML approach; (3) Knowledge and Technology
Transfer: The last phase is responsible for producing scientific essays to the academic
community, as well as transferring the technology developed to our partner with the in-
tention that it adopts our solution to improve its testing process.
Regarding data analysis, we intend to apply statistical methods such as average,

median, and standard deviation, among others based on descriptive statistics proposed by
Oates [Oates 2006], in order to measure the efficiency and effectiveness of the proposed
DSL to answer the research questions. However, we intend to perform advanced statis-
tical techniques to evaluate, for instance, the normal distribution and quality of our data.
However, it depends on the number of experiment subjects. Table 1 presents a synthesis
of the research methodology.
Table 1. Synthesis of the research methodology

Subject Performance Testing
Topic Performance Test Modeling
Research How to improve model-based performance testing using the domain-specific lan-
Question guage in Web applications?
Hypothesis The performance test modeling through of a domain-specific language in Web
applications can improve the quality, cost and effectiveness of performance testing.
Main Goal To develop a domain-specific language for modeling performance testing in Web
applications.
404
3. Canopus
In this section we present Canopus, the metamodels that compose our DSL, and describe
our model-based performance testing process using Canopus to support the design of
performance testing modeling of Web applications.
It is important to mention that during the design and development of our DSL,
we also considered some requirements from a Technology Development Lab (hereafter
referred to as TDL) of an industrial partner, in the context of a collaboration project to
investigate performance testing automation. These requirements were: a) the DSL had to
allow for representing the performance testing features; b) The technique for developing
our DSL had to be based on Language Workbenches (LW); c) The DSL had to support a
graphical representation of the performance testing features; d) The DSL had to support
a textual representation; e) The DSL had to include features that illustrate performance
counters (metrics, e.g. CPU, memory); f) The DSL had to allow the modeling of the
behavior of different user profiles; g) Traceability links between graphical and textual
representations should require minimal human intervention; h) The DSL had to be able
to export models to specific technologies, e.g. HP LoadRunner, MS Visual Studio; i) The
DSL had to generate model information in an eXtensible Markup Language (XML) file;
j) The DSL had to represent different performance test elements in test scripts; and, k) The
DSL had to allow the modeling of multiple performance test scenarios.
The rational and design decisions for our DSL are described in
[Bernardino et al. 2014]. Furthermore, in that paper we discuss the performance
testing domain and describe how the metamodels were structured to compose our DSL.
Besides, we also present how Canopus was designed to be applied with an MBT approach
to automatically generate performance test scenarios and scripts. To demonstrate how
our DSL could be used in practice, we applied it draft version of Canopus throughout an
exemple of use for the TPC-W e-commerce Web application.
3.1. The Language

Canopus is composed of three main parts: monitoring, scenario, and scripting.
Monitoring: the performance monitoring part is responsible for determining all
servers used in the performance testing environment. For each server (i.e., application,
databases, or even the load generator), information on the actual testing environment has
to be included, e.g., IP address or host name. It is worth mentioning that even the load
generator has to be described in our DSL, since we can also monitor the performance of
the load generator. Sometimes, the load generator has to be split into several servers if
we really want to stress the application or database server. For each host, it is possible to
indicate the performance counters that will be monitored. This monitoring part requires
that at least two servers have to be described: one that hosts the application (SUT) and
another to generate the workload and to monitor the performance counters of the SUT.
Scenario: the performance scenario part allows setting user and workload profiles.
Each user profile is associated to test scripts. If a user profile is associated with more than
one test script, a percentage is attributed between the user profile and each test script,
i.e., it describes the percentage that that test script is executed. In addition to setting
user profiles, in this part, it also is important to set one or more workload profiles. Each
workload profile is composed of several elements, defined as follows: a) Virtual users
405
(VU): refers to the number of VU who will make requests to the SUT; b) Ramp up time:
defines the time it takes for each set of ramp up users to access the SUT; c) Ramp up
users: defines the number of VU who will access the SUT during each ramp up time
interval; d) Test duration: refers to the total time of performance test execution for a given
workload; e) Ramp down users: defines the number of VU who will leave the SUT on
each ramp down time; f) Ramp down time: defines the time it takes for a given ramp down
user to stop the testing.
Scripting: the performance script part represents each of the test scripts from the
user profiles in the scenarios part. This part is responsible for determining the behavior
of the interaction between VU and SUT. Each test script includes activities, such as trans-
action control or think time between activities. The same way as there is a percentage
for executing a test script, which is defined in the scenarios part, each test script can also
contain branches that will have a user distribution associated to each path to be executed,
i.e., the number of users that will follow each path.
Figure 2. Canopus package diagram
To support the creation of our DSL with these parts, we chose MetaEdit+,
one of the first successful commercial tools. MetaEdit+ supports the creation and
evolution of each of the Graph, Object, Port, Property, Relationship and Role (GOP-
PRR) [Kelly and Tolvanen 2007] metatypes. Canopus has 7 metamodels represented by
7 packages (see Figure 2). The main metamodels that compose our DSL are Canopus
Performance Monitoring (CPMon), Canopus Performance Scenario
(CPSce), and Canopus Performance Scripting (CPScr), which together
compose the Canopus Performance Model. Complementing the structure, the
following metamodels Canopus Performance Metric (CPMet), Canopus
Performance Workload (CPWl), Canopus Performance External
File (CPExF) are extended, respectively, by each one of main metamodels.
3.2. A Model-Based Performance Testing Process
The aim of our Domain-Specific Modeling (DSM) process, using Canopus, is to improve
a performance testing process to take advantage of MBT. Figure 3 shows our process for
modeling performance testing using Canopus. This process incorporates a set of activi-
ties that have to be performed by two different parties: Canopus and Third-Party.
Besides, our DSM process is composed for seven main activities described in details next.
406
Figure 3. Model-based performance testing process using Canopus
Model Performance Monitoring: the designing of the first activity of our process is ex-
ecuted by the Canopus party. In this activity, the SUT, monitor servers and performance
metrics that will be measured are defined. The milestone of this activity is the generation
of a CPMon. This model is composed of SUT, Load Generator (LG) and Monitor objects.
A Monitor object is enabled to monitor the SUT and LG objects; this object is controlled
by a CPMet that can be associated with one or more of these objects. A CPMet model
represents a set of predefined metrics, e.g., memory or processor. Each one of them is
associated with a metric counter, which in turn is linked to a criterion and a threshold.
Model Performance Scenario: the next activity of our process consists of modeling the
performance test scenario. The CPSce model is the output of this activity. This model is
composed of user profiles that represent VU that can be associated with one or more script
objects. Each one of these scripts represents a functional requirement of the system from
the user profile point of view. Furthermore, a script is a detailed VU profile behavior,
which is decomposed into a CPScr model. Besides, each scenario allows modelling
several workloads in a same model. A workload (CPWl) is constituted of setup objects of
test scenario, i.e. ramp up, ramp down, test duration (time) and number of VU.
Model Performance Scripting: in this activity, each script object, modeled in the CPSce
model, mimics (step-by-step) the dynamic interaction by VU with the SUT. This activity
generates a CPScr model that is composed of several objects, such as, activity or think
time. It is important to notice that two objects, i.e. activity and data table, can be de-
composed into new sub-models. The former can be linked to a CPScr model that allows
encapsulating a set of activities to propose its reuse into other models. The latter is as-
sociated with a CPExF that fills a dynamic model with external test data provided by a
performance engineer. After the three first activities from our process, the performance
engineers have to decide whether they generate a textual representation from the designed
Canopus Performance models, an input for a third-party tool, or even a generic XML
representation that might be integrated to any other tool that accepts XML as input.
407
Generate Textual Representation: this activity consists of generating
a textual representation in a semi-natural language, a DSL-based on the
Gherkin [Wynne and Hellesøy 2012] language that extends it to include performance
testing information. Our design decision to deploy this feature in Canopus is to facilitate
the documentation and understanding among development and testing teams.
Generate Third-Party Scripts: Canopus was designed to work also as a front-end to
third-party performance tools. Therefore, even though we can generate a ”generic” textual
representation, our process allows integration of new features in Canopus to generate
input for any testing tool. Hence, it can be integrated with different load generator tools.
Generate Canopus XML: this activity is responsible for generating a Canopus XML file.
We included this feature to support the integration of Canopus with other technologies or
IDEs. Hence, Canopus can export entire performance testing information from Canopus
Performance models to an XML file.
Third-Party: the other three activities, shown in Figure 3, are not part of the Canopus
process, depending on the third-party tool that is used, such as HP LoadRunner, MS Vi-
sual Studio or Neo Load. The Execute Generated Scripts activity consists of
executing the performance scenarios and scripts generated for a third-party tool. Dur-
ing the execution of this activity the load generator consumes the test data mentioned
in the data table object in CPScr model; Monitor Performance Counters ac-
tivity is executed if the third-party tool has a monitoring module; and, Report Test
Results activity is also only executed if the performance tool has an analysis module.
4. Empirical Studies Evidences

This section will present the achieved results of empirical evidences conduted during this
research aiming to validate and to evaluate Canopus.
4.1. Case Study

We applied Canopus to model an application in an industrial case study, in the context of
a project of collaboration between a Technology Development Lab (TDL) of Dell Com-
puter Brazil and our university [Bernardino et al. 2016a]. Thereunto, to demonstrate how
our DSL can be used in practice, we applied it throughout the Changepoint Web appli-
cation, in which Canopus is used to model performance testing information supported by
the model-based performance testing process. Changepoint is a commercial solution to
support portfolio and investment planning, project and application management.
In short, we aim to explore two Research Questions (RQ) applying this case study:
RQ1. How useful is it to design performance testing using a graphical DSL?
RQ2. How intuitive is a DSL to model a performance testing domain?
We investigated and answered each one of the RQ based on the results of our case
study and interviews conducted with a performance testing team. The performance testing
team was formed by three performance engineers. Moreover, a Web-based survey was
answered by fifteen performance test experts. The purpose of this survey was to evaluate
the graphical elements and their representativeness to symbolize performance elements
that compose each Canopus Performance metamodel (Scripting, Scenario, Monitoring).
The subjects answered a Web-based survey composed of:
408
(a) Statements to find whether the element is representative for a specific metamodel,
based on a five points Likert scale: Disagree Completely (DC), Disagree Some-
what (DS), Neither Agree Nor Disagree (NAND), Agree Somewhat (AS) and
Agree Completely (AC);
(b) Open questions to extract their opinions on each metamodel.
Scripting 1.95.3 7.1

Metamodels
18.1 67.6
Scenario 2.7
0.7 6 17.3 73.3
Monitoring 3.6 7.7 7.2 21 60.5
0 10 20 30 40 50 60 70 80 90 100
Disagree Completely (DC) Disagree Somewhat (DS)
Neither Agree nor Disagree (NAND) Agree Somewhat (AS)
Agree Completely (AC)
Figure 4. Frequency diagram of the graphical elements grouped by metamodel
The answers were summarized in the frequency diagram shown in Figure 4. The
numbers in this figure are based on the evaluation of 37 elements: 13 elements for the
CPScr metamodel, 10 for CPSce metamodel and 14 for CPMon metamodel. The fre-
quency diagram presents the results grouped by each set of elements evaluated for each
metamodel. As can be seen in Figure 4, 81.5% (60.5% AC + 21% AS) of the answers
agree that the Monitoring elements are representative for the CPMon metamodel. For
the CPSce metamodel, 90.6% (73.3% AC + 17.3% AS) agree that the elements for that
metamodel are representative. Finally, 85.7% (67.6% AC + 18.1% AS) agree that the
elements represent the features they intend for the CPScr metamodel. These results are
used as part of the evaluation of Canopus.
Each of the research questions mentioned in Section 4.1, are answered next.
RQ1. The graphical representation of a notation, language or model is useful
to better explain issues to non-technical stakeholders. This was also confirmed by the
performance team that reported that using our approach, it is possible to start the test
modeling in early phases of the development process. Furthermore, it would be possible
to engage other teams during all process, mainly the Business System Analyst (BSA).
The BSA is responsible to intermediate the business layer between the developer team
and the product owner. Another interesting result pointed out by the subjects is that the
textual representation is also very appropriate, since it allows to replace the performance
testing specification. However, as expected, there is a steep curve on the understanding
of the DSL notation and an initial overhead when starting using an MBT-based approach
instead of a Capture and Replay (CR)-based approach.
RQ2. The case study execution indicates that the use of Canopus is quite intuitive,
since the performance testing domain is represented throughout graphs, objects, relation-
ships and properties. Visually, for instance, the scripting model can show the different
flows that have been solved in several test cases on the fly, and also the decomposition
and explosion features that can map objects into other graphs. This feature is also re-
lated to the reuse of partial models, characteristic of a DSL that allows to improve the
productivity and to reduce the time spent on performance testing modeling activity.
409
4.2. Controlled Experiment
This section reports the results of a controlled empirical experiment. Thus, to support
our partner company in the decision process to replace UML by a DSL, we designed and
conducted an experimental study to provide evidence about the benefits and drawbacks
when using UML or DSL for modeling performance testing.
We evaluate Canopus presenting an in vitro experiment, where the subjects an-
alyze the design of annotated UML models and Canopus Performance models. Hence,
twenty-six subjects were assigned and randomized with two groups (13 subjects per
group): experienced and inexperienced. Each group started the execution of one of the
two treatments (UML or DSL). This is for the purpose of evaluation with respect to the
effort and suitability, from the perspective of the performance testers and engineers in
the context of industry and academic environments for modeling performance testing.
A complete experiment design can be found in [Bernardino et al. 2016b]. Our statistical
analysis indicate that the results were valid, i.e., that to design performance testing models
using our DSL the effort using a DSL was lower than using UML.
To achieve our objective and purpose, we stated the following research questions:
RQ3. What is the effort to design a performance testing model when using UML or DSL?
RQ4. How effective is it to design a performance testing model when using UML or DSL?
Hence, we discuss the data collected to answer each one research questions.
RQ3. Table 2 presents the summarized effort data (time spent) to perform each
task using each approach. In the table, the columns Scenario and Scripting present the
average time per blocks and treatments, respectively. Based on the results summarized,
the average effort using Canopus was lower than with UML in all scenarios, either to
experienced or inexperienced subjects. The average time spent to design the performance
testing modeling using Canopus was lower than with UML (51.08 min vs 63.69 min).
Table 2. Summarized data of the effort (minutes)
Blocks Average Time Treatments Average Time
Treatments Blocks
Scenario Scripting Total Scenario Scripting Total
Inexperienced 15.69 52.62 68.31
UML 13.62 50.08 63.69
Experienced 11.54 47.54 59.08
Inexperienced 10.54 39.31 49.85
DSL 10.23 40.85 51.08
Experienced 9.92 42.38 52.31
Figure 5 depicts the box plot graph of the Scenario Task data set, represented by
UMLScenario and DSLScenario boxes. In the Scenario Task, the median of execution time
with UML was 12.5 minutes and with Canopus it was 10 minutes. Moreover, the UML
standard deviation (Std Dev) was 5.02 minutes, against 3.43 minutes for Canopus. It is
important to highlight that there is one outlier in the data set for Canopus that took 17
minutes. From another point of view, Figure 5 also presents the box plot graph of the
Scripting Task. This task is represented by UMLScripting and DSLScripting boxes, where
the median time to execute the UML treatment was 50.5 minutes, while for Canopus it
was 39.5 minutes. Moreover, the UML Std Dev was 11.84 minutes, greater than the 7.12
minutes for Canopus. Again, notice that there is one outlier in the data set for Canopus
that took 23 minutes. Figure 5 also shows the box plot graph of the summarized data set,
i.e., the sum of Scenario and Scripting tasks, identified by UMLT otal and DSLT otal boxes.
410
Here, the median of execution time with UML was 62.5 minutes, inasmuch as Canopus
was 48.5. It is important to highlight that the Canopus Std Dev (9.46 minutes) represents
66.8% of variation of the UML treatment (14.16 minutes). Once again, notice that there
is one outlier in the data set for Canopus treatment that took 28 minutes.
100
80
minutes
60
40
20
0
UMLScenario DSLScenario UMLScripting DSLScripting UMLTotal DSLTotal
Figure 5. Box plot - treatments per task
As for hypothesis testing, we performed the Kolmogorov-Smirnov test to verify

the normality of data distribution. In this context, we followed the best practice in Statis-
tics and chose a significance level of α = 0.05. Although, almost all results had a normal
distribution, there was one exception, i.e., the Scenario data set, that showed a p-value
(0.355835174) greater than α. For this reason, we assumed that the distribution was not
normal. Therefore, we applied a non-parametric test: Wilcoxon signed rank test. We
applied a non-parametric test since it uses the median instead of average as used in para-
metric test, and this solves the problem with outliers. For each data set, we applied the
statistical test to the paired samples, i.e. to compare the effort spent to model performance
using UML or DSL (RQ3). Hence, for all samples pairs, the results of the Wilcoxon test
reject the null hypothesis. Therefore, we can conclude that there is, statistically, a no-
ticeable difference in effort to design a performance testing model when using UML and
DSL. Thus, for all data sets we confirmed the alternative hypothesis.
Expressiveness 11.5 27 61.5

Representativeness 15.4 34.6 50
Easy to Design 3.8 65.4 30.8
Intuitiveness 19.2 26.9 53.9
0 10 20 30 40 50 60 70 80 90 100
Strongly Disagree (SD) Disagree (D) Neither Agree nor Disagree (NAD)
Agree (A) Strongly Agree (SA)
Figure 6. Frequency diagram of the Canopus
RQ4. After designing the performance models using both approaches, the sub-
jects answered a survey composed of: (a) statements to survey how much they concur
with our Canopus features; (b) open questions to extract their opinions. The answers
can be seen in the frequency diagram shown in Figure 6. As can be seen in the figure,
411
the statement most accepted is that the Canopus has Expressiveness (61.5% SA, 27% A
and 11.5% NAD), followed by that it has Representativeness (50% SA, 34.6% A, 15.4%
NAD) and Easy to Design (30.8% SA, 65.4% A, 3.8% NAD). The statement that received
the worst mark was Intuitiveness (53.9% A, 26.9% NAD and 19.2% D).
5. Final Remarks
The final remarks section is organized as follows. Section 5.1 revisits the achieved study
contributions that support answering such a RQ. Section 5.2 summarizes the study limi-
tations, and also sketches ongoing research and planned future work. Finally, Section 5.3
describes the academic contribution of the author in terms of publication.
5.1. Research Contributions
This section states the achievements and outcomes of this research as follows.
A pioneer graphical DSL for performance testing: we proposed, designed and devel-
oped Canopus, a graphical and textual language to model performance testing. MetaEdit+
was the LW applied to implement Canopus. Thereby, to design our textual representation,
we extend the Gherkin [Wynne and Hellesøy 2012] language to include performance test-
ing information. We chose to design both graphical and textual languages, because even
though graphical may be more rich visually, not all information can be represented.
Mechanisms to easily support the integration with third-party performance tools:
the MetaEdit+ have a feature that allows applying model transformation between the mod-
els instantiated from metamodels to code generation. Canopus was proposed to support
dual output, graphical and textual representation. Therefore, we proposed an XML struc-
ture as another output option. The idea is applying this strategy to integrate Canopus
with other load generators technologies, e.g. HP LoadRunner. Even so, a particular script
generation for each technology as a new feature of Canopus can be also implemented.
Model-based performance testing process: our DSL was designed to integrate with an
MBT approach. Thus, we propose a model-based performance testing process, which
uses Canopus as a modeling tool. The process incorporates a set of activities that have
to be performed by two distinct parties: Canopus and a Third-Party. Among of the set of
activities, we highlighted the design, graphically, of the Canopus Performance models, as
well as the following generations: textual representation, XML, and third-party scripts.
Industrial case study evaluation: we evaluated Canopus in an industrial case study.
This case study applied the model-based performance testing process proposed. Thus,
an experience with real-world applications - Changepoint - within an IT corporation was
reported. This case study provided evidence that Canopus is feasible in real and less con-
trolled contexts. Moreover, an analysis of a Web-based survey to evaluate the graphical
elements and their representativeness, intuitiveness, and usefulness to symbolize perfor-
mance elements, was answered by fifteen performance test experts.
Experimental evaluation: we conducted a controlled experiment to compare two ap-
proaches for modeling performance testing. We analyze the design of annotated UML
and Canopus models for the purpose of evaluation with respect to the effort and the suit-
ability, from the perspective of the performance testers and engineers in the context of
industry and academia environments for modeling performance testing. Our findings in-
dicate that, statistically, the effort of using a DSL was lower than that of using UML.
412
5.2. Limitations and Future Works
Despite this study having presented real contributions to the performance testing, MBT,
and DSL areas, we identified limitations of the study contributions that can be dealt with
in the future. Hence, we herein describe broader limitations to be overcome as well as
opportunities for future works made during short and medium term research.
Limitations of the Canopus metamodels: the architecture of Canopus is composed of
three main metamodels: monitoring, scenario, and scripting. Each one of theses meta-
models requires improvements in its properties, graphical elements, or even the translation
to textual representation. At first, the Monitoring metamodel needs to add new properties
to some elements. Another limitation is regarding the metrics, in which the solution de-
signed is dependent of each type of metrics instead of an abstract and generic solution.
Next, the Scenario metamodel does not provide the decomposition feature among scenar-
ios. Our industrial experience points out that this feature is necessary to express a real
synthetic workload. Finally, our empirical evidences, some limitations on the Scripting
metamodel were identified some graphical elements. Further investigations into strategies
for designing these graphical elements can shed some light on this topic.
Canopus is not exclusive to performance testing: foremost, our intention was to design
the DSL to support performance testing. Nevertheless, the proposed DSL is not restricted
only to this scope. In future work, we may extend Canopus for other contexts or, who
knows, to other testing paradigms, e.g. functional testing or security testing.
Replication of controlled experiment: in the experiment conducted, the most interesting
dimensions were the effort dedicated to the subjects for performance testing modeling
both approaches. However, we were aware that it was necessary to evaluate the deviation
of the error rate from the models designed. Hence, we would ensure more precisely that
time is spent meaningfully when compared with both approaches. Therefore, we are
planning the replication of the experiment with a large sample of experiment subjects.
Comparison of Canopus and Capture & Replay (CR) techniques: we performed an
experiment to compare UML and DSL models for modeling performance testing. How-
ever, for most of the industry players, MBT is not yet a standard. Therefore, for this
reason, we believe that an empirical study comparing a CR-based [El Ariss et al. 2010]
and DSL-based techniques require investigation and evidences.
Human-Computer Interaction (HCI) evaluation of the Canopus: although we per-
formed two empirical studies that perform qualitative analyzes based on survey results,
our approach does not apply a rigorous method supported by a widely known technique.
Therefore, we already began to investigate how to conduct a heuristic evaluation for us-
ability in HCI for user interface design of the Canopus.
5.3. Publications
During the development of this study we presented and discussed our research results
in the following papers: [Bernardino et al. 2014]: the requirements analysis and de-
sign decisions (ICSEA); [Bernardino et al. 2016a]: the canopus language and an indus-
trial case study (ICST); [Bernardino et al. 2016b]: an empirical experiment evaluation
(SAC); [Bernardino et al. 2017]: a systematic mapping study on model-based testing
(IET Software).
413
References
Bernardino, M., Rodrigues, E., and Zorzo, A. (2016a). Performance Testing Modeling:
an empirical evaluation of DSL and UML-based approaches. In 31st ACM Symposium
on Applied Computing, pages 1660–1665, New York, NY, USA. ACM.
Bernardino, M., Rodrigues, E., Zorzo, A., and Marchezan, L. (2017). A Systematic
Mapping Study on Model-Based Testing: Tools and Models. IET Software.
Bernardino, M., Zorzo, A., and Rodrigues, E. (2016b). Canopus: A Domain-Specific Lan-
guage for Modeling Performance Testing. In 9th International Conference on Software
Testing, Verification and Validation, pages 157–167, Washington, DC, USA. IEEE.
Bernardino, M., Zorzo, A. F., Rodrigues, E., de Oliveira, F. M., and Saad, R. (2014). A
Domain-Specific Language for Modeling Performance Testing: Requirements Analy-
sis and Design Decisions. In 9th International Conference on Software Engineering
Advances, pages 609–614, Wilmington, DE, USA. IARIA.
Bertolino, A. (2007). Software Testing Research: Achievements, Challenges, Dreams. In
Future of Software Engineering, pages 85–103, Washington, DC, USA. IEEE.
El Ariss, O., Xu, D., Dandey, S., Vender, B., McClean, P., and Slator, B. (2010). A
Systematic Capture and Replay Strategy for Testing Complex GUI Based Java Appli-
cations. In 7th International Conference on Information Technology: New Generations,
pages 1038–1043, Washington, DC, USA. IEEE.
Erdweg, S. [et al.] (2013). The State of the Art in Language Workbenches. In Erwig, M.,
Paige, R., and Wyk, E., editors, Software Language Engineering, volume 8225, pages
197–217. Springer International Publishing.
Kelly, S. and Tolvanen, J.-P. (2007). Domain-Specific Modeling: Enabling Full Code
Generation. John Wiley & Sons, New York, NY, USA.
Oates, B. J. (2006). Researching Information Systems and Computing. SAGE Publica-
tions, London, UK.
Utting, M. and Legeard, B. (2006). Practical Model-Based Testing: A Tools Approach.
Morgan Kaufmann, San Francisco, CA, USA.
Wohlin, C., Runeson, P., Höst, M., Ohlsson, M. C., and Regnell, B. (2012). Experimen-
tation in Software Engineering. Springer–Verlag, Berlin, Germany, 1st edition.
Woodside, M., Franks, G., and Petriu, D. C. (2007). The Future of Software Performance
Engineering. In Future of Software Engineering, pages 171–187, Washington, DC,
USA. IEEE.
Wynne, M. and Hellesøy, A. (2012). The Cucumber Book: Behaviour-Driven Develop-
ment for Testers and Developers. The Pragmatic Bookshelf.
Yang, Y., He, M., Li, M., Wang, Q., and Boehm, B. (2008). Phase Distribution of Soft-
ware Development Effort. In 2nd ACM-IEEE International Symposium on Empirical
Software Engineering and Measurement, pages 61–69, New York, NY, USA. ACM.
Yin, R. (2013). Case Study Research: Design and Methods. SAGE Publications, London,
UK, 5th edition.
414

Anais Do SBQS 2017 - Rio de Janeiro PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Anais Do SBQS 2017 - Rio de Janeiro PDF

Transféré par

Droits d'auteur :

Formats disponibles

XVI SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE – SBQS 2017

Rio de Janeiro/RJ – Brasil

SBC – Sociedade Brasileira de Computação

UNIRIO – Universidade Federal do Estado do Rio de Janeiro

Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES)

Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq)

Andreia Malucelli (PUCPR)

Sheila Reinehr (PUCPR)

Gleison Santos (UNIRIO)

Andreia Malucelli (PUCPR)

Sheila Reinehr (PUCPR)

Simpósio Brasileiro de Qualidade de Software (16.:2017 ago.28-30: Rio de Janeiro)

Conhecido também como SBQS 2017

1. Engenharia de Software. 2. Qualidade de Software. I. Reinehr, Sheila. II. Malucelli,

Capa: Leonardo Mendes Cabral

Sheila Reinehr (Pontifícia Universidade Católica do Paraná – PUCPR)

Andreia Malucelli (Pontifícia Universidade Católica do Paraná – PUCPR)

É com grande satisfação que, em nome do Comitê de Programa e do Comitê Organizador,

Este é um evento promovido anualmente pela Sociedade Brasileira de Computação (SBC). O

O SBQS foi iniciado em 2002, com o reconhecimento da SBC do crescimento contínuo, em

Paralelamente ao SBQS 2017, têm-se os seguintes eventos: XVI Concurso de Teses e

Rio de Janeiro, Agosto de 2017.

Coordenação do Comitê Organizador

Gleison Santos (UNIRIO)

Coordenação do Comitê de Programa

Trilha de Trabalhos Técnicos

Sheila Reinehr (PUCPR)

Trilha de Relatos de Experiência

Andreia Malucelli (PUCPR)

Adriano Bessa Albuquerque (UNIFOR)

Ana Regina Cavalcanti da Rocha (COPPE/UFRJ)

Andreia Malucelli (PUCPR)

Gleison Santos (UNIRIO)

Marcello Thiry (UNIVALI)

Monalessa Perini Barcellos (UFES)

Sheila Reinehr (PUCPR)

Tayana Conte (UFAM)

Ana Regina Rocha (COPPE-UFRJ)

Cristina Cerdeiral (UNIRIO)

Adenilso Simão - ICMC-USP

Adriano Albuquerque - UNIFOR

Alexandre Vasconcelos - UFPE

Alfredo Goldman - IME/USP

Aline Vasconcelos - IFFluminense

Ana Liddy Magalhães - UFMG/FUMEC

Ana Paula Bacelo - PUCRS

Ana Regina Rocha - COPPE/UFRJ

André Menolli - UENP

Andreia Malucelli - PUCPR

Auri Marcelo Rizzo Vincenzi - UFG

Breno França - COPPE/UFRJ

Carla Lima Reis - UFPA

Christiane Gresse von Wangenheim - UFSC

Cláudio Sant`Anna - UFBA

Cristina Cerdeiral - UNIRIO

Daniel Lucrédio - UFSCar

Davi Viana - UFMA

Débora Paiva - UFMS

Edson Oliveira Jr - UEM

Fernanda Campos - UFJF

Glauco Carneiro – UNIFACS

Gleison Santos - Unirio

Guilherme Travassos - COPPE/UFRJ