1 |
[en] ANALYSIS OF GOAL MODELS BASED ON COLORIMETRY / [pt] ANÁLISE DE MODELOS DE METAS BASEADA EM COLORIMETRIAROMEU FERREIRA DE OLIVEIRA 13 November 2023 (has links)
[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.
|
2 |
[en] COLLABORATIVE CONSTRUCTION OF QUALITY REQUIREMENTS / [pt] CONSTRUÇÃO COLABORATIVA DE REQUISITOS DE QUALIDADEGIOVANA BRANDAO RIBEIRO LINHARES 20 December 2020 (has links)
[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.
|
3 |
[pt] COMPREENDENDO A IDENTIFICAÇÃO DE PROBLEMAS DE PROJETO: COMBINANDO MULTIPLOS SINTOMAS / [en] UNVEILING DESIGN PROBLEMS IDENTIFICATION: COMBINING MULTIPLE SYMPTOMSANDERSON JOSE SILVA DE OLIVEIRA 02 January 2024 (has links)
[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.
|
4 |
[en] ALIGNING DEVELOPER QUALITY CONCERNS, REFACTORING APPLICATIONS, AND THEIR EFFECTS / [pt] ALINHANDO PREOCUPAÇÕES DE QUALIDADE DE DESENVOLVEDORES A APLICAÇÕES DE REFATORAÇÕES E SEUS EFEITOSVINICIUS PASSOS DE OLIVEIRA SOARES 25 November 2021 (has links)
[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.
|
5 |
[pt] O USO DA LINGUAGEM INTENCIONAL PARA APOIAR A GESTÃO DE RISCOS EMPRESARIAL / [en] USING INTENTIONAL MODELING TO ENHANCE ENTERPRISE RISK MANAGEMENTRAFAEL DE SIQUEIRA T CAVALCANTI 19 May 2021 (has links)
[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.
|
6 |
[pt] ACELERANDO A ELICITAÇÃO DE REQUISITOS NÃO FUNCIONAIS / [en] SPEEDING UP NON FUNCTIONAL REQUIREMENTS ELICITATIONROXANA LISETTE QUINTANILLA PORTUGAL 14 August 2020 (has links)
[pt] Considerando a disponibilidade do Big Data para engenharia de software, como no caso do GitHub, a semi-automação da elicitação de requisitos não funcionais (NFRs) é uma estratégia fundamental para a definição de requisitos. Como tal, a elicitação de NFRs, dentro da automação da leitura de documentos, pode gerenciar a massa de informações valiosas existentes nos dados disponíveis. Esta tese explora esse contexto em três partes, a escolha de fontes apropriadas de informação, uma elicitação de descoberta de fatos e a identificação de NFRs. As avaliações realizadas mostraram que a automação enfrenta um balance entre eficiência e eficácia. Esse equilíbrio é detalhado com diferentes estratégias inovadoras. O conhecimento adquirido é organizado como um catálogo SIG (Softgoal Interdependence Graph). / [en] Considering the availability of Big Data for software engineering, as the case of GitHub, the semi-automation of non-functional requirements (NFRs) elicitation is a key strategy towards requirements definition. As such, NFRs elicitation, within the automation of document reading, can manage the mass of valuable information existing in available data. This thesis explores this context in three parts, the choice of proper sources of information, a fact-finding elicitation, and NFRs identification. The assessments performed showed that the automation faces a trade-off between efficiency and efficacy. This trade-off is detailed with different novel strategies. The acquired knowledge is organized as a SIG (Softgoal Interdependence Graph) catalog.
|
Page generated in 0.0455 seconds