Titulo

Abstract
Contexto: enfrentar com xito as preocupaes das partes interessadas que esto relacionados ao
desenvolvimento de sistemas de software e operao fundamental para alcanar as metas de
desenvolvimento. A importncia da utilizao de uma abordagem sistemtica para abordar essas
preocupaes ao longo do ciclo de vida de desenvolvimento de software est crescendo medida
que mais e mais sistemas so empregados para lidar com tarefas crticas. Objetivo: O
objetivo deste estudo fornecer uma viso geral de endereamento preocupaes em todo o ciclo de
vida de desenvolvimento de software. Mtodo: estudo de mapeamento sistemtico foi realizado
utilizando um pr-definida protocolo. Quatro bancos de dados digitais foram procurados para
pesquisa estudos da literatura e primrios foram selecionados aps trs rodada processo de seleo
realizada por vrios investigadores. Resultados: A dados extrados so processadas e os resultados
so apresentados a partir de diferentes pontos de vista. Os resultados so tambm analisados contra
nosso objetivos da pesquisa. Concluso: Mostra-se que h uma considervel variao no uso de
terminologias e preocupaes abordando em diferentes fases do ciclo de vida de desenvolvimento
de software.
Introduo:
Todo sistema de software tem um conjunto designado de funes primrias que foi concebido para
executar. O trabalho realizado por eles o razo para construir o sistema em primeiro lugar. No
entanto, funcionalidade por si s no vai garantir o comportamento desejado do sistema.
Dependendo do contexto, o sistema dever manter vrias caractersticas para alm de exercer as
suas funes bsicas. Mesmo que tenha havido um nfase na assimtrica funcionalidade do sistema,
essencialmente, a utilidade do sistema determinada tanto a sua funcionalidade e as suas outras
caractersticas [3]. O desenvolvimento de sistemas de software dias modernos operado em crtica
domnios um desafio, porque vrias preocupaes devem ser tomadas em considerao durante o
desenvolvimento do sistema.
A preocupao um termo geral que pode ser usado para indicar qualquer interesse particular. No
entanto, no contexto de sistemas de software desenvolvimento, a preocupao utilizado para
denotar um interesse que se refere ao desenvolvimento do sistema, o seu funcionamento, ou
qualquer outro aspecto que relevante para uma ou mais partes interessadas [4]. O alcance e a
natureza intuitiva da definio permitir que qualquer interesse relacionados com o sistema,
incluindo funcionalidades do sistema, para ser classificado como um preocupao. No entanto, uma
vez que as funcionalidades so especficas do sistema, apenas as caractersticas gerais do sistema
so considerados como preocupaes durante este estudo. Alm das preocupaes de ordem geral e
as funcionalidades do sistema, um sistema ainda pode ter vrios outros aspectos, que so especficos
para um dado sistema e seu ambiente operacional.
Quando comeamos a estudar arquitetura de software de design de tomada de decises no contexto
de mltiplas preocupaes, percebemos que os conceitos relacionados a preocupaes no domnio
de engenharia de software so ampla e vaga. Eles esto abertos para significativamente diferente
interpretaes de diferentes pontos de vista. O objetivo deste estudo o de superar esses desafios,
mapeando o estado da arte na resposta s preocupaes em todo o ciclo de vida de desenvolvimento
de software. Apesar de paradigmas de desenvolvimento de software, tais como desenvolvimento de
software orientado a aspectos tm tentado lidar com as preocupaes de forma sistemtica, a sua
influncia no desenvolvimento de software ainda limitada a certas fases. Temos notado que h
vrios termos que so usados para se referir a preocupaes em geral, um tipo de preocupao, ou
uma associao com preocupaes. Os mesmos termos de identificao usados em diferentes fases

da vida de desenvolvimento de software ciclo fundamental para alcanar o objetivo acima.

Cada tipo de modelo de desenvolvimento de software, que vo desde modelos de ciclo de vida
tradicionais, como a cachoeira e a espiral modelos para evolutiva modelos de desenvolvimento, tais
como o gil modelo de desenvolvimento de software, lida com preocupaes durante a vida ciclo.
Existem variaes do ciclo de vida de desenvolvimento de software fases, dependendo do modelo
de desenvolvimento utilizado. Neste estudo, Usamos cinco software principal fases do ciclo de vida
de desenvolvimento anlise de requisitos, design de software, implementao, teste e manuteno que so visveis na maior parte dos amplamente utilizados modelos de desenvolvimento de software
[9]. A realizao de uma sistemtica estudo de mapeamento tem sido reconhecida como um ponto
de partida, que pode ajudar os pesquisadores a estabelecer uma linha de base para novas pesquisas
atividades [5]. Assim, nosso objetivo usar o resultado deste estudo como um base para nossa
pesquisa planejada em arquitetura de software de design tomando uma deciso.
Este trabalho de pesquisa apresenta um estudo de mapeamento sistemtico realizado para identificar
vrios aspectos de lidar com as preocupaes em toda o ciclo de vida de desenvolvimento de
software. Aps a introduo, seco 2 descreve o processo para o mapeamento de desenvolvimento
de protocolo para classificao e extrao de dados em detalhe. Seo 3 apresenta os resultados do
estudo e brevemente analis-los contra as perguntas da pesquisa, enquanto a seco 4 discute as
possveis ameaas validade do estudo. Finalmente, a seo 5 conclui o artigo destacando os
elementos importantes do estudo, as lies aprendidas e as eventuais prorrogaes.
2. SYSTEMATIC MAPPING STUDY:
Um estudo de mapeamento sistemtico pode ser considerado como uma reviso sistemtica da
literatura leve, com um escopo diferente. Apesar de poderem ser utilizados complementares um do
outro, existem diferenas em meta, processo, largura, profundidade e [5]. Fornecendo uma
classificao e realizao de uma anlise temtica esto entre os principais objetivos de um estudo
de mapeamento sistemtico. Embora exista menos nfase na qualidade da literatura, a extrao de
dados tambm limitada a dados que necessrio para a realizao de uma anlise temtica
prevista. Um estudo de mapeamento tambm pode ser realizado em um campo maior, como no h
necessidade de uma avaliao detalhada da literatura. Uma vez que nosso objetivo estudar
literatura de pesquisa que abrange a totalidade do ciclo de vida de desenvolvimento de software e
para classificar e analis-los com base em diferentes pontos de vista relacionados com problemas,
ns pensamos que um estudo de mapeamento sistemtico bem adequado para os nossos objetivos.
2.1 Mapping Study Process
O processo de mapeamento sistemtico descrito em [5] e sistemtica orientaes avaliao
fornecidos em [6] so adaptados para desenvolver o e o processo de mapeamento sistemtico
protocolo seguido neste estudo. Os principais passos seguidos durante o estudo so:
1 - Definir questes de pesquisa
2 - Desenvolver protocolo de mapeamento
3 - Buscar literatura
4 - Selecione estudos primrios
5 - Criar sistema de classificao
6 - Extrair dados
7 - Os resultados do relatrio
Os passos foram seguidos sequencialmente durante o estudo, mesmo embora os resultados de
algumas etapas foram refinados de forma iterativa usando o resultados das etapas posteriores.

2.2 Research Questions

Questes de pesquisa em estudos de mapeamento so geralmente menos especfico e tambm
desempenham um papel trivial em moldar-se uma estratgia de busca em comparao com revises
sistemticas. Mas ainda assim, questes de investigao definida a base para o estudo.
Classificao, anlise e gerao de relatrios so todos construdos em torno da questo de
pesquisa. Os seguintes questes de pesquisa esto definidos no contexto do presente estudo.
* RQ1: Qual a terminologia utilizada em associao com preocupaes em desenvolvimento de
software?
* RQ2: Quais so as preocupaes mais considerada em desenvolvimento de software?
* RQ3: Como que a terminologia e as preocupaes variam entre as diferentes fases do
desenvolvimento de software vida til?
2.3 Mapping Protocol
Ao seguir um protocolo pr-definido rigorosamente ao longo do estudo, uma reviso sistemtica da
literatura aumenta a integridade do estudo, reduzindo a possibilidade de vis. Uma vez que o
protocolo seguido tambm includos no relatrio do estudo, se necessrio, possvel validar o
estudo replicando as etapas do protocolo. Definir explicitamente os processos de busca e os critrios
de incluso / excluso no protocolo e report-lo como uma parte do resultado uma das principais
caractersticas que distinguem as revises sistemticas e estudos de mapeamento a partir de
comentrios tradicionais [2]. Desde um processo de mapeamento sistemtico no necessrio seguir
todos os elementos em protocolos de reviso sistemtica, adaptamos o protocolo de reviso
sistemtica fornecida por [6] para construir um protocolo para este estudo. O protocolo criado
objetivos includos da pesquisa, questes de investigao, pesquisa estratgias, seleo dos estudos
primrios, incluindo incluso / excluso critrios e processos de seleo, classificao e extrao de
dados mecanismos e relatrios. O protocolo foi revisto vrias vezes usando um estudo piloto com
base em uma amostra de quarenta pesquisa papis antes de realizar o estudo real.
2.4 Search for Literature
Com base nas recomendaes [1] e dos pesquisadores anterior experincia, quatro bancos de dados
digitais foram selecionados como literatura fontes: Biblioteca Digital ACM, IEEE Xplore,
ScienceDirect, e Scopus. O prximo passo do processo de pesquisa foi a formulao de sequncias
de pesquisa. Fizemos vrias tentativas de construir cadeias de pesquisa usando diferentes termos
relacionados com a rea de pesquisa. depois de pilotar muitos termos, percebemos alguns deles deu
uma insuficiente quantidade de resultados, enquanto outros causou uma grande quantidade de
resultados que no podia ser tratado dentro do mbito do presente estudo. Desde identificar
terminologias e todas as preocupaes envolvidas era um objetivo principal do estudo, restringindo
nossa busca a apenas um limitado nmero de termos conhecidos iria dificultar o processo Por isso,
decidimos realizar a pesquisa de forma to ampla quanto possvel e filtrar irrelevante papis durante
o processo de seleo. Por fim, concordou em usar tanto "Desenvolvimento de software" e
"preocupao" como termos de busca, porque eles deram uma quantidade razovel de resultados em
um escopo mais amplo. No limitaes foram aplicados sobre os fruns publicados, como faz-lo
teria limitado o escopo da literatura. Mas desde que nosso estudo baseou-se no domnio de
engenharia de software, quando o procura de interface suportado ele, a pesquisa se restringiu apenas
ao o domnio de engenharia de software. No h restries foram aplicadas em relao ao ano de
publicao.

2.5 Primary Study Selection

Aps a realizao da pesquisa, os resultados foram enviados para RefWorks [8]. A seleo do
estudo preliminar foi realizado em trs rounds. Em cada rodada, dois pesquisadores usaram um
conjunto de selecionados sees dos jornais disponveis na rodada e assinalados cada papel como
quer "aceitar", "rejeitar", ou "no pode decidir", baseado no critrios pr-definido de incluso /
excluso mostrados na Tabela 1. O critrios de incluso / excluso foram projetados para ser
reduzida em cada rodada medida que mais informaes se tornaram disponveis.
Table 1. Inclusion/exclusion criteria used during selection(:))
A primeira rodada de seleo foi feita com base nos metadados de cada papel recolhido durante a
busca. As duplicatas, os tipos de contedo que no foram considerados neste estudo, e os papis que
estavam a partir das fontes que no eram relevantes para o domnio de engenharia de software
foram filtrados nesta rodada. RefWorks foi utilizado para identificar duplicatas, mas os artigos
identificados foram verificados manualmente antes da remoo para evitar falsas bandeiras. Os
pesquisadores passaram os ttulos dos trabalhos na prxima rodada e os resumos na terceira
rodadas.
Uma vez que todos os papis na rodada foram marcados de forma independente por cada
pesquisador, as listas foram combinados e a deciso de incluir ou excluir o trabalho foi feito com
base no combinado resultado. Quando ambos os pesquisadores concordaram em aceitar ou rejeitar
um papel, ou um dos pesquisadores marcado como "no pode decidir", enquanto o outro tomou
uma deciso, a aceitao ou rejeio do trabalho foi feita de imediato. Se eles discordavam ou de
ambos no poderia decidir, foi marcado como um conflito. Aps cada rodada, um conflito reunio
de resoluo foi realizada para resolver conflitos. Se os investigadores foram incapazes de chegar a
acordo sobre um papel, ele foi levado para a prxima fase de seleo, juntamente com os trabalhos
selecionados. Aps o terceiro e a rodada final, um terceiro pesquisador participou no conflito
reunio de resoluo para resolver os conflitos remanescentes.
2.6 Classification and Data Extraction
Desenvolver esquema classificao adequada contribui no s para extrair dados corretos, mas
tambm para relatar os resultados do estudo em um forma eficaz. Com base nas questes de
pesquisa abordadas em Neste estudo, trs esquemas de classificao foram obtidos: fase do software
ciclo de vida de desenvolvimento, os tipos de preocupaes abordadas em as pesquisas e termos
usados para se referir a preocupaes. Para alm do esquemas de classificao principais, outros
regimes de classificao tambm surgiu durante a realizao do estudo.
Com base no sistema de classificao, os seguintes dados foram extrados de trabalhos de pesquisa
selecionados para anlise e declarante: ttulo do trabalho, autor (es), ano de publicao, tipo (s) das
preocupaes abordadas, fase (s) de vida de desenvolvimento de software ciclo, e termo (s)
utilizado para se referir a preocupaes. Os dados extrados foram armazenados em um arquivo do
Excel para posterior processamento. Para certificar-se que a extrao de dados foi feito
corretamente, dois pesquisadores realizada de forma independente de extrao de dados em uma
amostra selecionada de 100 artigos, o que era 24% da quantidade total de papis. O resultados
foram comparados para identificar se havia alguma inconsistncia. Uma vez que no houve grandes
diferenas entre os resultados, a nico pesquisador completou extrao de dados a partir do resto do
trabalhos de pesquisa com base no processo acordado.

3. RESULTS
O objetivo principal da comunicao de resultados responder s questes de pesquisa e descobrir
outras informaes possvel. Ao mesmo tempo, atravs da combinao dos protocolos descritos
com os dados que so apresentados, possvel validar que o estudo foi conduzido tal como
reivindicado.
3.1 Selection Process Results
A pesquisa inicial foi realizada nas quatro bancos de dados selecionados usando as seqncias de
pesquisa que so definidos com base no escopo do estudo. Como mostrado na Tabela 2, que trouxe
2.711 documentos que contm as cordas determinada pesquisa no ttulo, o resumo, ou as palavraschave. Scopus teve o maior nmero de trabalhos enquanto ScienceDirect, a menor. No final das trs
fases de seleco, 421 trabalhos, 16% dos resultados da pesquisa inicial, foram selecionados como
os estudos preliminares para a extrao de dados. A lista dos estudos primrios selecionados est
disponvel aqui: http://dasanayake.com/EASE2014.pdf.
Tablw
3.2 Extracted Results
Informaes extradas durante o estudo apresentada e analisada a partir de diferentes pontos de
vista para fornecer as respostas para a pesquisa perguntas.
3.2.1 Terminology used
Como mencionado anteriormente, identificando terminologia associada preocupaes um dos
objetivos do estudo. Durante o estudo, foi observou que, embora alguns trabalhos de pesquisa
utilizados vrios termos para se referir s preocupaes, alguns papis s usou o termo
"preocupao". Outro observao foi que um termo nico foi utilizada para expressar diferentes
significados em diferentes papis. Por exemplo, embora o maioria dos trabalhos utilizou o termo
"aspecto" para se referir a transversalidade preocupaes, havia muitos papis onde era utilizada
para se referir a preocupaes em geral ou algum outro tipo de preocupao.
De acordo com os resultados do estudo, "aspecto" foi o mais termo comum usado para associar
preocupaes. O segundo mais frequentemente termo utilizado foi "requisito no funcional." Uma
vez que um termo comumente usado em engenharia de software, que se esperava ter uma
contagem maior do que o estudo resultou contagem. A sua falta de associao com o termo
"preocupao" pode ser vista como uma razo para que. "Atributo Qualidade" foi o outro termo que
ocorreu com frequncia. Embora houvesse muitos termos que foram usados menos frequentemente,
a maioria deles eram diferentes combinaes de palavras como a qualidade, no funcional, aspecto,
propriedade ou atributo.
3.2.2 Concerns addressed
Como esperado, nos deparamos com uma srie de preocupaes durante o estudo. Enquanto a
maioria deles so qualidades comuns de software sistemas, havia preocupaes de sistemas de
software muitos especficos tambm. Uma vez que alguns estudos tinham usado o termo
"preocupao" para se referir a propriedades funcionais do sistema, a maior parte do sistema de
software preocupaes especficas foram preocupaes funcionais. Como mostrado na Tabela 3, a
segurana, capacidade de reutilizao, e manuteno so mais comumente preocupaes
consideradas nos estudos selecionados. Capacidade de evoluir e desempenho tambm esto entre os

top 5 preocupaes. Preocupaes como reutilizao, facilidade de manuteno, rastreabilidade e

modularidade pode ser colocado numa categoria especial, uma vez que so as preocupaes que
pode ser tratadas por meio de separao de interesses.
3.2.3 Variation in the software development life cycle
A Figura 1 mostra uma viso geral das questes que abordam compacto durante todo o ciclo de vida
de desenvolvimento de software. Como se mostra a, concepo e implementao so as fases onde
a maioria da preocupaes so abordados. O uso ativo de software orientado a aspectos paradigma
de desenvolvimento durante a concepo e execuo pode ser a principal razo para lidar com a
maioria das preocupaes nestes fases. Uma vez que o projeto uma fase inicial do software ciclo
de vida de desenvolvimento, se as preocupaes so tratadas no projeto fase, que afeta a maioria das
partes do ciclo de vida. A variao de terminologias e preocupaes especficas entre as diferentes
fases so em grande parte, proporcional variao global preocupao, e eles vo continuar a ser
analisados em um estudo detalhado.
4. THREATS TO VALIDITY
Apesar de seguir um processo rigoroso ao longo do estudo, no h so algumas questes que podem
ser consideradas como ameaas validade dos a investigao. A nossa seleo termo pesquisado
pode ser visto como uma desvantagem do estudo. Em vez de limitar ao termo "preocupao", que
pudemos usaram termos como "aspectos", "no-funcionais requisitos "e" atributos de qualidade ",
que descreveram preocupaes ou alguns aspectos de preocupaes. Mesmo que isso pode
aumentar a Pesquisa qualidade resultado, ao mesmo tempo, que poderia tambm pr nmero sem
precedentes de resultados de pesquisa que no pode ser tratada dentro do mbito do presente estudo.
Ento, tivemos que fazer um trade-off entre o uso desses termos e cobrindo a totalidade de software
ciclos de vida de desenvolvimento. Ter um grande nmero de primrio estudos tambm podem
representar uma ameaa para a validade da pesquisa, uma vez que faz com que o processo de
extraco propenso a erros. Para minimizar esse ameaa, dois pesquisadores realizaram
independentemente de extrao de dados em uma amostra selecionada e as questes identificadas
foram esclarecidas antes de realizar a extrao de dados final.
5. CONCLUSION
Este estudo foi conduzido como o primeiro passo de uma pesquisa centrou-se sobre tomada de
decises projeto de arquitetura de software no contexto de vrias preocupaes. O objetivo deste
estudo foi o de fornecer uma Resumo dos problemas de endereamento em diferentes fases do
software ciclo de vida de desenvolvimento, enquanto especialmente com foco no terminologia e
tipo de preocupaes. Assim, os resultados do estudo Pode ser usado como base para a construo
de uma viso unificada do preocupaes. O estudo responderam s questes de pesquisa,
fornecendo uma viso geral sobre a terminologia utilizada em associao com preocupaes, as
preocupaes mais considerado e sua variao no ciclo de vida de desenvolvimento de software.
Para alm de atingir o desejado objetivos, muitos outros resultados tambm foram produzidas
durante o estudo. Especialmente, vrias foram as lies aprendidas relacionadas com a rea de
pesquisa bem como o processo de realizao de estudos sistemticos literatura.
Durante a realizao do estudo, ns nos concentramos em duas reas principais que foram
reconhecidos como os elementos mais importantes de um bem-sucedido estudo de mapeamento
sistemtico. Uma rea foi os resultados, e a outra foi o processo. Embora o objetivo principal do
estudo foi responder s questes de investigao, a validade da pesquisa seria estar em dvida se
um processo sistemtico apropriados no foram seguidos durante o estudo. Por outro lado, a seguir

o melhor possvel processo no seria til, sem obter resultados interessantes. Ns tentamos
encontrar o equilbrio entre esses dois elementos por na sequncia de um processo sistemtico
rigorosa, mantendo o nosso foco sobre os objetivos do estudo. Finalmente, os resultados produzidos
neste estudo pode ser utilizado para realizar novos estudos com foco em diferentes preocupaes e
fases do ciclo de vida de desenvolvimento de software.
6. AGRADECIMENTOS
Este trabalho financiado pelo ITEA2 e Tekes - O Financiamento finlands Agncia de Tecnologia
e Inovao, atravs do projecto MERGE. Gostaramos tambm de agradecer ao Prof. junho Verner
para orientao e o feedback apresentado durante este estudo.