[pt] Adicionar requisitos de segurança às arquiteturas de software após elas terem sido construídas é uma tarefa bastante difícil. Conceitos de segurança devem permear todo o ciclo de desenvolvimento do software, desde a engenharia de requisitos, passando por desenho (design), implementação, testes e distribuição. Este trabalho apresenta uma abordagem para modelagem de requisitos de segurança, especialmente os requisitos de confidencialidade e consistência das informações, baseada em estratégias orientadas a metas, trazendo a questão da segurança para o início do ciclo de desenvolvimento de software. São apresentados também os resultados da aplicação desta abordagem em um estudo de caso. / [en] Adding security requirements to software architectures after they are built is a hard work. Security concepts have to cross the whole software development cycle, from requirement engineering to deployment, passing by design, coding and test. This work presents an approach to security requirements modeling, mainly the information confidentiality and consistency, based on goal oriented strategies, bringing the security issues to the beginning of the software development cycle. It also presents the results of this approach in a case study.

[pt] O desenvolvimento de ambientes femto-celulares traz um considerável aumento geral na capacidade de sistemas heterogêneos, porque a distância entre o transmissor e receptor é pequena em comparação ao clássico desenvolvimento macro-celular. Mas as aplicações e serviços que estão vindo, precisam de ainda mais capacidade. Na procura desse ganho na capacidade, se criam técnicas e procedimentos que trabalham principalmente na camada física e MAC. Entre elas temos o reuso de frequência unitário, o qual não se logra explodir toda a capacidade do sistema, por isso implementamos o reuso de frequência fracionário que encara diretamente os problemas de interferência co-layer (entre femto-estações) e cross-layer (entre macro e femto estações). Este reuso fracionário de frequência se da só a nível de femto-estações, deixando à macro-estação que utilize toda a banda de frequência atribuída para a macro-célula. Os claros resultados obtidos no nível do SINR, mostram as melhoras. Tomando como base a plataforma anterior de reuso fracionário, analisamos as estrategias de programação do recurso frente a uma aplicação de vídeo. As estrategias pesquisadas são classificadas em: aquelas que tomam em consideração a qualidade do canal e aquelas que além da qualidade do canal consideram dentro da sua métrica requerimentos QoS, em especial o retardo máximo. Estas ultimas são as mais adequadas quando se opera com aplicações de tempo real (vídeo conferência e VoIP). Para contemplar a faixa de funcionamento das melhoras obtidas, todos os cenários de simulação foram sometidos a três intensidades de trafego (leve, médio e pesado). Medidas feitas da vazão, retardo, perda de pacotes e níveis de justiça na repartição mostram os benefícios do efeito combinado do reuso fracionário como o algoritmo de programação utilizado. Com os resultados obtidos fazemos uma escolha do padrão de reuso mais adequado junto com o algoritmo que proporcionam o melhor rendimento, dependendo do cenário (familiares ou empresariais) e da aplicação a utilizar. / [en] The development of femtocells environments brings a considerable increase in the capacity of the heterogeneous systems, because the distance between the transmitter and the receptor is smaller than the classic macrocell development. But the applications and services that are coming need more capacity yet. Looking for that gain of capacity, has been created techniques and methods that work mainly in the physical and MAC layer. Among them, the unitary frequency reuse, that does not achieve to exploit all the system s capacity. Hence we have implemented the fractional frequency reuse that aim directly the problems of co-layer interference (Between femto base stations) and cross-layer interference (Between macro and femto base stations). This fractional reuse of frequency is only among femto-stations, leaving the macro-station that use all the frequency band given for the macro cell. The bright results obtained in the SINR level show the improvements. Based on previous platform of fractional reuse, we analyze the scheduling strategies of the resource with a video application. The studied strategies are classified in: those that consider the quality of the channel and those that beyond the quality of channel consider QoS requirements in its metric, specially the maximum delay time. The last are more adequate when operating with video applications in real time (Video conference, VoIP). To see the operating range of the obtained improvements, all the simulation scenarios were submitted to three intensities of traffic (light, medium and heavy). Measurements of throughput, delay, packet loss ratio and fair levels in the distribution show the benefits of the joint effects of the fractional reuse as the scheduling algorithm used. With the obtained results, we do a selection of the more adequate reuse pattern together with the algorithm that provides the best performance, depending of the scenario (home or business environment) and the applications to use.

[pt] A definição dos requisitos do software, onde os engenheiros interagem com os clientes para conhecerem as atividades da organização e entenderem suas necessidades, é um processo chave para o sucesso dos sistemas de informação. Portanto, requisitos definidos de maneira clara e de acordo com as necessidades dos clientes são condições fundamentais para o desenvolvimento de sistemas de informações úteis para a organização. Nessa dissertação propomos um método que visa auxiliar o engenheiro de requisitos na tarefa de elicitação de requisitos mais aderentes ao negocio e com isto conseguir desenvolver melhores sistemas de informação para as organizações.O método proposto parte do princípio que, integrando conhecimentos adquiridos com o modelo de processo do negócio, e o modelo ontológico do negócio, podemos produzir uma sólida fonte de conhecimentos. O uso dessa fonte de conhecimentos na elicitação dos requisitos do sistema de informação da organização objetiva prover aos engenheiros de requisitos uma sólida base para a definição de requisitos aderentes ao negócio da organização. A integração da perspectiva ontológica com a perspectiva de processos é detalhada e exemplificada através de um estudo de caso. / [en] Requirements definition, where engineers interact with clients to better know the organization`s activities and understand their needs, is a key process to the success of an information system. As such, requirements defined with clarity and according to the client`s needs are fundamental to the development of effective information systems for the organization. This dissertation proposes a method to help requirements engineers in the task of eliciting requirements. These requirements must be in accordance with the business as to improve the quality of the organization`s information systems. The proposed method integrates process modeling and business ontology. The work assumes that the integration of these perspectives provides a solid source of organization knowledge. Using this knowledge source, requirements engineers are empowered to define requirements that better fits the organization business. The integration of process modeling and business ontology is described in detail and exemplified by a case study.

[pt] Modelos orientados a metas tornaram-se ferramentas importantes para a Engenharia de Requisitos Não Funcionais (RNF). Porém, o tratamento de RNFs é uma tarefa não trivial, visto que esta classe de requisitos abrange as características de qualidade de um sistema. Isso implica que, ao lidar com requisitos subjetivos, precisamos nos concentrar em mecanismos que possam enriquecer a semântica de sua representação. É o caso da atribuição e propagação de rótulos na análise de modelos orientados a metas. A definição de rótulos nos modelos de metas, realizada pelos métodos de análises qualitativos existentes, tem baixa granularidade e muitas vezes falha em refletir o potencial informativo que esse tipo de artefato pode oferecer. Esse é o caso do NFR Framework. A propagação no modelo ocorre de baixo para cima (bottom-up) e o entendimento sobre o grau de satisfação de uma meta torna-se difícil. Este trabalho explora uma lógica para aumentar o poder informativo dos rótulos atribuídos as metas flexíveis, utilizando conceitos de colorimetria em modelos do tipo SIG (Softgoal Interdependency Graph). Investigamos como o uso de cores mitiga o desafio de aumentar a granularidade da análise dos modelos de metas, melhorando assim o entendimento sobre o grau de satisfação a contento definido para os RNFs analisados. / [en] Goal-oriented models have become important tools for the analysis of non-functional requirements (NFRs). However, the treatment of NFRs is a non-trivial task, considering that this class of requirements covers quality characteristics. This implies that when dealing with subjective requirements, we need to focus on mechanisms that can enrich the semantics of their representation. This is the case of assigning and propagating labels in the evaluation of goal-oriented models. The definition of labels in the goal models, carried out by the existing qualitative analysis methods, has low granularity and often fails to reflect the information potential that this type of artifact may offer. This is the case of the NFR Framework. Propagation in the model is bottom-up and understanding the degree of goal satisficing becomes difficult. This paper explores a rationale to increase the informative power of the labels assigned to the goals, using the concepts of colorimetry in the SIG (Softgoal Interdependency Graph). We discuss how color mitigates the challenge of increasing the granularity of goal models analysis, thus improving the evaluation of these models.

[pt] Em geral, os Requisitos Não-funcionais (RNFs) só são tratados nas atividades relacionadas à arquitetura do software, e, muitas vezes, apenas durante a implementação. Essa situação resulta em custos mais altos e menor qualidade do software. Este trabalho estuda mecanismos para ressaltar os RNFs durante as atividades de construção de requisitos. A escolha dos requisitos pelos diversos interessados, dentro do processo de elicitação de requisitos do software através do consenso, é um problema complexo. Representar e estruturar dinâmicas de grupos, que são compostas por ações humanas, é um desafio. Durante o processo de decisão em grupo ocorre o debate de um conjunto de idéias, nem sempre expostas de maneira clara e nem sempre entendidas por todos da mesma forma. O debate envolve vários perfis de participantes, com pontos de vista distintos, e por vezes conflitantes. Sendo tais diferenças, em contra partida, fundamentais para a qualidade da decisão em grupo, pois as ideias são analisadas sob vários ângulos. Um processo colaborativo de construção de RNFs e seu suporte computacional são propostos. A abordagem de Negociação - Colaboração é reutilizada para trabalhar especificamente RNFs. Leva em consideração não apenas a construção dos RNFs em si, mas também a construção de suas interdependências. Tais interdependências entre os requisitos impactam a própria decisão sobre os RNFs a serem construídos. A avaliação do processo foi apoiada por um software desenvolvido para suporte, ao mesmo tempo, de mecanismos de Negociação-Colaboração e de atividades de especificação de RNFs. O software é assíncrono e distribuído geograficamente, facilitando a comunicação em grupo, mesmo que com membros distantes fisicamente. Foram realizadas três atividades avaliativas e os resultados produzidos demonstraram indícios positivos ao uso do processo na construção de RNFs. Para cada um dos projetos usados nas avaliações, foi produzida uma lista de RNFs cujo a consistência foi julgada pelos participantes envolvidos como suficientemente satisfatória. O número de RNFs foi dobrado nas três atividades de construção, revelando uma maior cobertura relativa aos atributos de qualidade inicialmente elencados para os softwares. / [en] Non-Functional Requirements (NFRs) are often managed late, either during design or, more often, just at implementation. This trend results in higher costs and low-quality software. Our work studies mechanisms to support RNFs, based on the collaborative dynamics of a negotiation process, during the requirements construction activities As such, we created a collaborative strategy for the construction of NFRs. An evaluation was conducted using a tailored tool built to implement the proposed Negotiation-Collaboration mechanisms. The choice of requirements by various stakeholders, within the process of eliciting software requirements through consensus, is a complex problem. Representing and structuring group dynamics, which are composed of human actions, is a challenge. During the group decision-making process, a set of ideas is debated, not always clearly expressed and not always understood by everyone in the same way. The debate involves several profilesq of participants, with different and sometimes conflicting points of view. Such differences, however, are fundamental to the quality of the group decision, as the ideas are analyzed from various perspectives. A collaborative strategy for building RNFs and their computational support is proposed. The Negotiation-Collaboration approach is reused to work specifically with RNFs. It takes into account not only the construction of the RNFs themselves, but also the construction of their interdependencies. Such interdependencies between the requirements impact the decision on the RNFs to be built. The strategy evaluation was supported by software developed to support, at the same time, Negotiation-Collaboration mechanisms and RNFs specification activities. The software is asynchronous and geographically distributed, facilitating group communication, even with physically distant members. Three evaluative activities were carried out, and the results showed positive indications for the use of the strategy in the construction of RNFs. For each of the projects used in the evaluations, a list of RNFs was produced, whose consistency was judged by the participants involved to be sufficiently satisfactory. The number of RNFs was duplicated in the three construction activities, revealing greater coverage regarding the quality attributes initially listed for the software.

[pt] O projeto de software resulta das decisões ao longo do seu desenvolvimento. Algumas dessas decisões podem levar a problemas de projeto, afetando negativamente os requisitos não funcionais (RNFs). Embora seja crucial identificar esses problemas, essa é uma tarefa complexa, especialmente quando o código-fonte é o único artefato disponível. Nessa tarefa, os desenvolvedores podem ter que considerar vários sintomas (por exemplo, anomalias de código) para identificar até mesmo um único problema de projeto. Estudos anteriores sugerem que usar um único sintoma pode ser inadequado para identificar tais problemas. Portanto, nesta tese, investigamos como múltiplos sintomas podem ser usados nessa identificação. Em nosso primeiro estudo, nos concentramos em investigar o uso de anomalias de código bem conhecidos (anomalias de manutenabilidade). Nós identificamos que os desenvolvedores podem se beneficiar desse tipo de sintoma quando as ocorrências das anomalias afetam a mesma localização do programa e formam um padrão, podendo indicar melhor a presença de um problema de projeto. No entanto, também revelamos as limitações ao depender exclusivamente desse tipo de sintoma, destacando a necessidade de contexto adicional. Isso nos levou ao segundo estudo, onde investigamos um tipo adicional de sintoma, anomalias de robustez, e seu uso combinado com anumalias de manutenabilidade. Nós identificamos que ambos os tipos de anomalia de código podem ajudar os desenvolvedores na identificação de problemas de projeto principalmente relacionados à má modularização do sistema. Através desses dois estudos, observamos a necessidade de compreender as perspectivas e estratégias dos desenvolvedores em relação aos RNFs do sistema. Ao fazê-lo, podemos potencialmente entender quem são os desenvolvedores mais capazes de prevenir, discutir e identificar problemas de projeto. Isso nos levou ao terceiro estudo, onde investigamos como os desenvolvedores discutem e abordam RNFs em seus sistemas, revelando estratégias comuns em relação a esses requisitos. Esses resultados nos proporcionaram uma compreensão mais abrangente de como os desenvolvedores podem combinar diferentes sintomas e como percebem sua importância dentro de seus sistemas. / [en] Software design results from stakeholder decisions made through software development. Some of these decisions may lead to design problems, negatively impacting non-functional requirements (NFRs). Even though identifying design problems is crucial, this is a complex task, especially when the source code is the only artifact available. Along this task, developers may have to reason about multiple symptoms (e.g., code smells and nonconformities with NFRs) to identify even a single design problem. In fact, previous studies suggest that relying on a single symptom may be inadequate for the design problem identification. Thus, in this thesis, we investigate the role that the use of multiple symptoms may have on the identification of design problems. In our first study, we focused on investigating the use of well-known code smells (called here maintainability smells) to support this task. Our results indicated that developers could benefit from this type of symptom when smell occurrences affect the same program location and form a pattern; i.e., a set of co-occurring maintainability smells may better indicate the presence of a design problem. Nevertheless, we also reveal the limitations of relying solely on this type of symptom, highlighting the need for additional context. This leads us to the second study, where we investigate an additional type of symptom, robustness smells, and its combined use with maintainability smells. Our results indicated that the use of both types of smells can help developers in the identification of design problems mainly related to bad modularization of the system (e.g. excess of responsibilities assigned to the same component). Through these two studies, we observed the need to understand the perspectives and strategies of developers toward the NFRs of the system. In doing so, we can potentially understand who are the developers better able to prevent, discuss and identify design problems. That led us to our third study, where we investigated how developers discuss and address NFRs in their systems, uncovering common strategies toward these requirements. These results led us to a more comprehensive understanding of how developers can combine different symptoms and how they perceive their significance within their systems.

[pt] Os defeitos nas especificações de requisitos podem ter consequências graves durante o ciclo de vida de desenvolvimento de software. Alguns deles resultam em uma falha geral do projeto devido a características de qualidade incorretas ou ausentes, como segurança. Existem várias preocupações que tornam a segurança difícil de lidar; por exemplo, (1) quando as partes interessadas discutem os requisitos gerais nas reuniões, muitas vezes não estão cientes que também devem discutir tópicos relacionados à segurança. (2) Normalmente as equipes de desenvolvimento não possuem conhecimentos de segurança suficientes. Isto geralmente leva a aspectos de segurança não especificados ou mal definidos. Essas preocupações tornam-se ainda mais desafiadoras em contextos de desenvolvimento ágil, nos quais a documentação leve geralmente está envolvida. O objetivo desta dissertação é projetar e avaliar uma abordagem para suportar a revisão de aspectos relacionados à segurança em especificações de requisitos ágeis de aplicativos web. A abordagem projetada considera estórias de usuário e especificações de segurança como entradas e relaciona essas estórias de usuário a propriedades de segurança através de técnicas de Processamento de Linguagem Natural. Com base nas propriedades de segurança relacionadas, nossa abordagem identifica os requisitos de segurança de alto nível do OWASP (Open Web Application Security Project) a serem verificados e gera uma técnica de leitura focada para dar suporte aos revisores na detecção de defeitos. Avaliamos nossa abordagem rodando dois experimentos controlados. Comparamos a eficácia e a eficiência de inspetores novatos que verificam aspectos de segurança em requisitos ágeis usando nossa técnica de leitura contra o uso da lista completa de requisitos de segurança de alto nível do OWASP. Os resultados (estatisticamente significativos) indicam que o uso da nossa abordagem tem um impacto positivo (com tamanho de efeito muito grande) no desempenho dos inspetores em termos de eficácia e eficiência. / [en] Defects in requirements specifications can have severe consequences during the software development life cycle. Some of them result in overall project failure due to incorrect or missing quality characteristics such as security. There are several concerns that make security difficult to deal with; for instance, (1) when stakeholders discuss general requirements in (review) meetings, they are often not aware that they should also discuss security-related topics, and (2) they typically do not have enough expertise in security. This often leads to unspecified or ill-defined security aspects. These concerns become even more challenging in agile development contexts, where lightweight documentation is typically involved. The goal of this dissertation is to design and evaluate an approach to support reviewing security-related aspects in agile requirements specifications of web applications. The designed approach considers user stories and security specifications as input and relates those user stories to security properties via Natural Language Processing (NLP). Based on the related security properties, our approach then identifies high-level security requirements from the Open Web Application Security Project (OWASP) to be verified and generates a focused reading technique to support reviewers in detecting defects. We evaluate our approach via two controlled experiment trials. We compare the effectiveness and efficiency of novice inspectors verifying security aspects in agile requirements using our reading technique against using the complete list of OWASP high-level security requirements. The (statistically significant) results indicate that using our approach has a positive impact (with very large effect size) on the performance of inspectors in terms of effectiveness and efficiency.

[pt] Com o aumento da complexidade dos SMA´s governados por leis, tornouse mais difícil projetar e implementar requisitos referentes à tolerância a falhas, principalmente por não existir nenhum ponto de controle sobre tais sistemas. E, apesar disto, não são conhecidas soluções que abordem tais questões na literatura de governança de SMA´s baseados em leis. Contudo, existe uma técnica de tolerância a falhas, chamada Replicação de Agentes, que propõe reutilizar os conceitos de recuperação em sistemas distribuídos através da tolerância a falhas para a recuperação de agentes baseando- se em informações que identifiquem suas criticalidades. Entretanto, apesar de existirem algumas estratégias de estimativa de criticalidade de agentes, nenhuma apresenta o grau de granularidade suficiente para o monitoramento de SMA´s abertos governados por leis. Desta forma, o trabalho aqui proposto tem como objetivo apresentar um mecanismo de configuração de variação de criticalidade de agentes que interagem em SMA´s abertos. Para isto é proposta uma arquitetura para desenvolvimento de SMA´s abertos governados por leis tolerantes a falhas e uma abordagem para projetar tais mecanismos com simplicidade, modularidade e reuso. Este trabalho apresenta três contribuições principais: a extensão no modelo conceitual da linguagem declarativa de especificação de lei XMLaw com elementos para monitoramento da criticalidade dos agentes; a integração dos frameworks de governança de SMA´s abertos (M-Law) e de adaptação dinâmica de replicação de agentes (DIMAX); e a proposição de uma forma de documentação e derivação das leis. Por fim são apresentadas planilhas de resultados da aplicação do mecanismo proposto em dois estudos de caso. / [en] With law-governed multi-agent systems complexity growth, it is harder to design and implement requirements related to dependability mainly because there is no control point over such systems. Despite the great importance of those problems, there is no solution that fully addresses those issues in the context of law-governed multi-agent systems. However, there is a fault tolerant technique called Agent Replication that proposes the reuse of some recovery concepts of distributed systems through a fault tolerance based approach on some data that helps the identification of critical agent. And, besides the existents strategies of agents´ criticality estimation, none of them presents the granularity degree necessary for the monitoring of law- governed open MAS´s. Due to it, the goal of this work is to present a mechanism of the configuration variation of the agents´ criticality that interacts in open MAS´s. To achieve this goal, an architecture to support the development of fault tolerant law-governed open MAS and an approach to design such mechanisms with simplicity, modularity and reuse were proposed. This work has three main contributions: an extension on the conceptual model of the law- specification declarative language XMLaw within new elements to monitor the agents´ criticality; the integration of two frameworks: one is for law-enforcement (M-Law), and the other one is for a dynamic and adaptative agents´ replication (DimaX); and a proposal of a means to document and derive the laws. Finally, we present some sheets of the results of the proposed mechanism application in two case studies.

[pt] Em função do ritmo acelerado com que tem surgido inovações de mercado, com as incertezas econômicas, a ascensão de mídias sociais, violações cibernéticas, e diversos outros fatores, os riscos organizacionais tem se tornado cada vez mais complexos e difíceis de serem geridos. É necessário que pensemos em modelos mais completos de representação de informações que possam interpretar os riscos aos quais as empresas estão expostas da maneira mais clara e detalhada possível. A modelagem i-estrela permite que informações sejam representadas sem que sejam excluídos detalhes relevantes para a gestão de riscos das organizações. Este artigo propõe uma modelagem de gestão de riscos por meio do modelo i-estrela, de forma a atender a necessidade de representação de informações complexas no atual ambiente de negócios empresarial. / [en] Due to the accelerated pace with which market innovations have emerged, with economic uncertainties, the rise of social media, security issues, and many other factors, organizational risks have become increasingly complex and challenging to manage. It is essential to think about more complete models of information representation that can interpret the risks to which companies are exposed, as clearly, and detailed as possible. The intentional modeling approach allows information to be represented without excluding details relevant to organizations risk management. This paper proposes a risk management modeling strategy using the iStar language to address the need for enhanced information representation in today s enterprise business environment.

[pt] Mesmo com o processo de refatoração sendo investigado cada vez mais nos últimos anos, muitas de suas características se mantém pouco compreendidas. Refatoração de software é o processo de melhorar a manutenibilidade de um sistema por meio de mudanças estruturais que não alteram seu comportamento. Estudos recentes revelaram que projetos de software frequentemente recebem refatorações compostas. Em tais refatorações, desenvolvedores aplicam uma série de transformações únicas em conjunção e em um único commit, e se espera que estas refatorações tenham um efeito maior e mais positivo do que refatorações singulares. Porém, refatorações frequentemente causam mudanças que ou mantém a qualidade do software da mesma forma, ou causam a piora do mesmo, levando trabalhos recentes a procurar causas em potencial para este comportamento. Porém, o porquê da complexidade destas mudanças compostas frequentemente afetarem seus resultados de alguma forma positiva ou (inesperadamente) negativa continua não investigado. O mesmo ocorre com o potencial efeito das preocupações dos desenvolvedores durante a aplicação de refatorações. Sobre estas preocupações, alguns trabalhos anteriores foram desenvolvidos em torno da caracterização e detecção de discussões de desenvolvedores relacionadas a refatorações. Porém, não se sabe se e como estas preocupações de desenvolvedores com refatorações, tornando-se explícitas em tais discussões, podem influenciar os efeitos de refatorações em um sistema. Portanto, este trabalho apresenta dois estudos com o objetivo de preencher a lacuna no conhecimento de que causas levam aos efeitos não-positivos frequentemente encontrados em refatorações, procurando entender: (i) se refatorações mais complexas realmente são mais efetivas do que refatorações simples, como esperado; (ii) em que situações desenvolvedores tendem a explicitar suas preocupações com refatoração do código; e (iii) qual é o impacto de tais preocupações na efetividade de uma refatoração em melhorar a qualidade estrutural do código. Nós analisamos estas características e atingimos os seguintes resultados: Primeiro, conforme a complexidade das refatorações aumenta, a efetividade das mesmas aumenta conjuntamente. Segundo, há uma relação entre a efetividade de refatorações e preocupações explícitas com refatorações, onde a possibilidade de efeitos negativos é menor quando desenvolvedores estão explicitamente preocupados com refatoração. Finalmente, desenvolvedores tendem a explicitar mais frequentemente suas preocupações com o processo de refatoração quando deparados com tarefas de refatoração mais complexas. / [en] Even though the refactoring process has been increasingly investigated in the last years, many of its characteristics remain poorly understood. Software refactoring is the process of improving the maintainability of a system through structural changes that do not alter its behaviour. Recent studies revealed that software projects frequently have to undergo composite refactorings. In such refactorings, developers perform a series of single transformations in conjunction and in a single commit, which are expected to have a larger and more positive impact than single refactorings. However, refactorings frequently cause changes that either keep the software quality the same, or cause it to worsen, which lead recent works to look for potential causes of this behavior. However, the complexity of these composite changes often affecting their outcomes in some positive or (unexpectedly) negative way remains not investigated, much like the developers concerns while performing refactoring. For the latter, some previous work was performed around characterizing and detecting refactoring-related developer discussions. However, it is unknown whether and how developers refactoring concerns made explicit in such discussions can influence the refactorings effects on a system. Thus, this work reports two studies aimed at bridging some of those gaps in knowledge in which causes lead to the non-positive effects frequently found in refactoring, by understanding: (i) if more complex refactorings are indeed more effective than simple refactorings, as one would expect; (ii) in which situations developers tend to have explicit concerns while refactoring the code; and (iii) what is the impact of such concerns on the effectiveness of a refactoring to improve structural quality. We analyze these characteristics and reach the following results: First, as refactoring complexity increases, the effectiveness of such refactorings increases as well. Second, there is a relationship between refactoring effectiveness and explicit refactoring concerns, in which the possibility of negative effects is lower when developers are explicitly concerned about refactoring. Finally, developers tend to be more explicit about their concerns on the refactoring process when they are faced with more complex refactoring tasks.